Techniques to Improve the Scalability of RSVP-TE Deployments
RFC 8370

RFC 8370              RSVP-TE Scaling - Techniques              May 2018

   o  SHOULD prioritize Tear/Error over trigger Path/Resv (messages that
      bring up new LSP state) sent to a peer when the local system
      detects RSVP-TE control-plane congestion in the peer.

   o  MUST indicate support for this technique via the CAPABILITY object
      [RFC5063] in Hello messages.

4.1.  Capability Advertisement

   An implementation supporting the Per-Peer Flow-Control technique MUST
   set a new flag, Per-Peer Flow-Control Capable, in the CAPABILITY
   object signaled in Hello messages.  The following bit indicates that
   the sender supports Per-Peer Flow Control:

      Bit Number 27 (0x0010) - Per-Peer Flow-Control Capable (F-bit)

   Any node that sets the new F-bit in its CAPABILITY object MUST also
   set the Refresh-Reduction-Capable bit in the common header of all
   RSVP-TE messages.  If a peer sets the F-bit in the CAPABILITY object
   but does not set the Refresh-Reduction-Capable bit, then the Per-Peer
   Flow-Control functionality MUST NOT be activated for that peer.

4.2.  Compatibility

   The Per-Peer Flow-Control functionality MUST NOT be activated with a
   peer that does not indicate support for this functionality.  If a
   peer hasn't indicated that it is capable of participating in Per-Peer
   Flow Control, then it SHOULD NOT be assumed that the peer would
   always acknowledge a non-out-of-order message containing a MESSAGE_ID
   object with the ACK_Desired flag set.

5.  IANA Considerations

5.1.  Capability Object Values

   IANA maintains the "Capability Object values" subregistry [RFC5063]
   within the "Resource Reservation Protocol (RSVP) Parameters" registry
   <http://www.iana.org/assignments/rsvp-parameters>.  IANA has assigned
   two new Capability Object Value bit flags as follows:

      Bit      Hex     Name                                Reference
      Number   Value
      ------------------------------------------------------------------
        28     0x0008  RI-RSVP Capable (I)                 Section 3
        27     0x0010  Per-Peer Flow-Control Capable (F)   Section 4

Beeram, et al.               Standards Track                    [Page 7]
RFC 8370              RSVP-TE Scaling - Techniques              May 2018

6.  Security Considerations

   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC2205] and
   RSVP-TE [RFC3209], and those that are described in [RFC5920], remain
   relevant.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <https://www.rfc-editor.org/info/rfc2205>.

   [RFC2961]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F.,
              and S. Molendini, "RSVP Refresh Overhead Reduction
              Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001,
              <https://www.rfc-editor.org/info/rfc2961>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC4558]  Ali, Z., Rahman, R., Prairie, D., and D. Papadimitriou,
              "Node-ID Based Resource Reservation Protocol (RSVP) Hello:
              A Clarification Statement", RFC 4558,
              DOI 10.17487/RFC4558, June 2006,
              <https://www.rfc-editor.org/info/rfc4558>.

   [RFC5063]  Satyanarayana, A., Ed. and R. Rahman, Ed., "Extensions to
              GMPLS Resource Reservation Protocol (RSVP) Graceful
              Restart", RFC 5063, DOI 10.17487/RFC5063, October 2007,
              <https://www.rfc-editor.org/info/rfc5063>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Beeram, et al.               Standards Track                    [Page 8]
RFC 8370              RSVP-TE Scaling - Techniques              May 2018

7.2.  Informative References

   [RFC5439]  Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of
              Scaling Issues in MPLS-TE Core Networks", RFC 5439,
              DOI 10.17487/RFC5439, February 2009,
              <https://www.rfc-editor.org/info/rfc5439>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <https://www.rfc-editor.org/info/rfc5920>.

Beeram, et al.               Standards Track                    [Page 9]
RFC 8370              RSVP-TE Scaling - Techniques              May 2018

Appendix A.  Recommended Defaults

   a.  Refresh Interval (R) - 20 minutes (Section 3):
       Given that an implementation supporting RI-RSVP doesn't rely on
       refreshes for state sync between peers, the function of the RSVP
       refresh interval is analogous to that of IGP refresh interval
       (the default of which is typically in the order of tens of
       minutes).  Choosing a default of 20 minutes allows the refresh
       timer to be randomly set to a value in the range [10 minutes
       (0.5R), 30 minutes (1.5R)].

   b.  Node Hello Interval - 9 seconds (Section 3):

       [RFC3209] defines the hello timeout as 3.5 times the hello
       interval.  Choosing 9 seconds for the node hello interval gives a
       hello timeout of 3.5 * 9 = 31.5 seconds.  This puts the hello
       timeout value in the vicinity of the IGP hello timeout value.

   c.  Retry-Limit (Rl) - 7 (Section 4):
       Choosing 7 as the retry-limit results in an overall rapid
       retransmit phase of 31.5 seconds.  This matches up with the hello
       timeout of 31.5 seconds.

   d.  Refresh Interval for refreshing state associated with
       unacknowledged Path/Resv messages (uR) - 30 seconds (Section 3):
       The recommended refresh interval (R) value of 20 minutes (for an
       implementation supporting RI-RSVP) cannot be used for refreshing
       state associated with unacknowledged Path/Resv messages.  This
       document recommends the use of the traditional default refresh
       interval value of 30 seconds for uR.

Acknowledgements

   The authors would like to thank Yakov Rekhter for initiating this
   work and providing valuable input.  They would like to thank
   Raveendra Torvi and Chandra Ramachandran for participating in the
   many discussions that led to the techniques discussed in this
   document.  They would also like to thank Adrian Farrel, Lou Berger,
   and Elwyn Davies for providing detailed review comments and text
   suggestions.

Beeram, et al.               Standards Track                   [Page 10]
RFC 8370              RSVP-TE Scaling - Techniques              May 2018

Contributors

   Markus Jork
   Juniper Networks
   Email: mjork@juniper.net

   Ebben Aries
   Juniper Networks
   Email: exa@juniper.net

Authors' Addresses

   Vishnu Pavan Beeram (editor)
   Juniper Networks

   Email: vbeeram@juniper.net

   Ina Minei
   Google, Inc

   Email: inaminei@google.com

   Rob Shakir
   Google, Inc

   Email: rjs@rob.sh

   Dante Pacella
   Verizon

   Email: dante.j.pacella@verizon.com

   Tarek Saad
   Cisco Systems

   Email: tsaad@cisco.com

Beeram, et al.               Standards Track                   [Page 11]