TEAS Working Group                                        V. Beeram, Ed.
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                                I. Minei
Expires: February 11, March 31, 2018                                        R. Shakir
                                                             Google, Inc
                                                              D. Pacella
                                                                 Verizon
                                                                 T. Saad
                                                           Cisco Systems
                                                         August 10,
                                                      September 27, 2017

  Implementation Recommendations

   Techniques to Improve the Scalability of RSVP-TE RSVP Traffic Engineering
                              Deployments
                 draft-ietf-teas-rsvp-te-scaling-rec-06
                 draft-ietf-teas-rsvp-te-scaling-rec-07

Abstract

   The scale at

   At the time of writing, networks which RSVP-TE utilize RSVP Traffic
   Engineering (RSVP-TE) Label Switched Paths (LSPs) get deployed
   is growing continually and are encountering
   limitations in the onus is on RSVP-TE ability of implementations
   across the board to keep up with this increasing demand. support the growth
   in the number of LSPs deployed.

   This document introduces a couple of techniques - defines two techniques, "Refresh-Interval Independent
   RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - Flow-Control", that reduce the number
   of processing cycles required to help maintain RSVP-TE deployments push the envelope on scaling. LSP state in Label
   Switching Routers (LSRs) and hence allow implementations to support
   larger scale deployments.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 11, March 31, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions used in this document . . . . . . . . . . . .   3
   2.  Recommendations . . . . . . . .  Requirement for RFC2961 Support . . . . . . . . . . . . . . .   3
     2.1.  "RFC2961 Specific" Recommendations  . . . . . . . . . . .   3
       2.1.1.  Basic Prerequisites . . . . . . . . . . . . . . .  Required Functionality from RFC2961 to be Implemented . .   3
       2.1.2.
     2.2.  Making Acknowledgements Mandatory . . . . . . . . . . . .   4
       2.1.3.
     2.3.  Clarifications On Reaching Rapid Retry Limit (Rl) . . . .   4
     2.2.
   3.  Refresh-Interval Independent RSVP . . . (RI-RSVP) . . . . . . . . .   5
       2.2.1.
     3.1.  Capability Advertisement  . . . . . . . . . . . . . .   5
       2.2.2. . .   6
     3.2.  Compatibility . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.
   4.  Per-Peer RSVP Flow-Control  . . . . . . . . . . . . . . . . .   6
       2.3.1.
     4.1.  Capability Advertisement  . . . . . . . . . . . . . . . .   7
       2.3.2.
     4.2.  Compatibility . . . . . . . . . . . . . . . . . . . . . .   7
   3.
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   4.
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     5.1.
     7.1.  Capability Object Values  . . . . . . . . . . . . . . . .   8
   6.
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Recommended Defaults . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The scale at

   At the time of writing, networks which RSVP-TE utilize RSVP Traffic
   Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) get
   deployed is growing continually and there is considerable onus on
   RSVP-TE implementations across are
   encountering limitations in the board ability of implementations to keep up with this
   increasing demand support
   the growth in scale. the number of LSPs deployed.

   The set of RSVP Refresh Overhead Reduction procedures [RFC2961]
   serves as a powerful toolkit for RSVP-TE implementations to help
   cover a majority of the concerns about soft-state scaling.  However,
   even with these tools in the toolkit, analysis of existing
   implementations [RFC5439] indicates that the processing required
   under
   beyond a certain scale may still cause significant disruption to an LSR. a
   Label Switching Router (LSR).

   This document builds on the scaling work and analysis that has been
   done so far and makes a set of concrete implementation
   recommendations defines protocol extensions to help RSVP-TE
   deployments push the envelope further on scaling - push higher by increasing the
   threshold above which an LSR struggles to achieve sufficient
   processing to maintain LSP state.

   This document advocates the use of a couple of techniques - "Refresh-
   Interval defines two techniques, "Refresh-Interval Independent
   RSVP (RI-RSVP)" and "Per-Peer Flow-Control" -
   for significantly cutting Flow-Control", that cut down the amount number
   of processing cycles required to maintain LSP state.  "RI-RSVP" helps
   completely eliminate RSVP's reliance on refreshes and refresh-timeouts refresh-
   timeouts while "Per-Peer Flow-Control" enables a busy RSVP speaker to
   apply back pressure to its peer(s).  This document defines a unique
   RSVP Capability [RFC5063] for each technique.  Note that the "Per-
   Peer Flow-Control" technique requires the "RI-RSVP" technique as a
   prerequisite.  In order to reap maximum scaling benefits, it is
   strongly RECOMMENDED recommended that implementations support both the
   techniques.

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document  Both the techniques are to fully backward compatible and
   can be interpreted as described in [RFC2119]. deployed incrementally.

2.  Recommendations

2.1.  "RFC2961 Specific" Recommendations  Requirement for RFC2961 Support

   The implementation recommendations discussed techniques defined in this section Section 3 and Section 4 are based on the
   proposals made in [RFC2961] [RFC2961].  Implementations of these techniques
   will need to support the RSVP messages and act procedures defined in
   [RFC2961] as prerequisites for
   implementing the techniques discussed set out in Sections 2.2 Section 2.1 with some minor modifications and
   alterations to recommended time intervals and 2.3.

2.1.1.  Basic Prerequisites iteration counts as
   defined in the remainder of this section.

2.1.  Required Functionality from RFC2961 to be Implemented

   An implementation that supports the techniques discussed in Sections
   2.2 Section 3
   and 2.3 Section 4 must meet certain basic prerequisites. support the functionality described in [RFC2961]
   as follows:

   o  It MUST indicate support for RSVP Refresh Overhead Reduction
      extensions (as specified in Section 2 of [RFC2961]).

   o  It MUST support receipt of any RSVP Refresh Overhead Reduction
      message as defined in [RFC2961].

   o  It SHOULD MUST initiate all RSVP Refresh Overhead Reduction mechanisms as
      defined in [RFC2961] (including the SRefresh message) with the
      default behavior being to initiate the mechanisms but offering a
      configuration override.

   o  It MUST support reliable delivery of Path/Resv and the
      corresponding Tear/Err messages (as specified in Section 4 of
      [RFC2961]).

   o  It MUST support retransmission of all unacknowledged RSVP-TE
      messages using exponential-backoff (as specified in Section 6 of
      [RFC2961]).

2.1.2.

2.2.  Making Acknowledgements Mandatory

   The reliable message delivery mechanism specified in [RFC2961] states
   that "Nodes receiving a non-out of order message containing a
   MESSAGE_ID object with the ACK_Desired flag set, SHOULD respond with
   a MESSAGE_ID_ACK object."

   In an implementation that supports the techniques discussed in
   Sections 2.2
   Section 3 and 2.3, Section 4, nodes receiving a non-out of order message
   containing a MESSAGE ID MESSAGE_ID object with the ACK-Desired flag set, MUST
   respond with a MESSAGE_ID_ACK object.  This MESSAGE_ID_ACK object can
   be packed along with other MESSAGE_ID_ACK or MESSAGE_ID_NACK objects
   and sent in an Ack message (or piggy-backed in any other RSVP
   message).  This improvement to the predictability of the system in
   terms of reliable message delivery is key for being able to take any
   action based on a non-receipt of an ACK.

2.1.3.

2.3.  Clarifications On Reaching Rapid Retry Limit (Rl)

   According to section 6 of [RFC2961] "The staged retransmission will
   continue until either an appropriate MESSAGE_ID_ACK object is
   received, or the rapid retry limit, Rl, has been reached."  The
   following clarifies what actions, if any, a router should take once
   Rl has been reached.

   If Rl has been reached for the retransmission of a message that is
   neither a Path nor a Resv message, then the router need not take any
   further action.  If Rl has been reached for the retransmission of a
   Path or a Resv message, then the router starts periodic
   retransmission of these on a slower timer.  The retransmitted
   messages MUST carry MESSAGE_ID object with ACK_Desired flag set.
   This periodic retransmission SHOULD continue until an appropriate
   MESSAGE_ID_ACK object is received indicating acknowledgement of the
   (retransmitted) Path/Resv message.  The configurable periodic
   retransmission interval for this slower timer SHOULD be less than the
   regular refresh interval.  A default periodic retransmission interval
   interval
   (for this slower timer) of 30 seconds is RECOMMENDED by this
   document.

2.2.

3.  Refresh-Interval Independent RSVP (RI-RSVP)

   The RSVP protocol relies on periodic refreshes for state
   synchronization between RSVP neighbors and for recovery from lost
   RSVP messages.  It relies on refresh timeout for stale state cleanup.
   The primary motivation behind introducing the notion of "Refresh
   Interval Independent RSVP" (RI-RSVP) is to completely eliminate
   RSVP's reliance on refreshes and refresh timeouts.  This is done by
   simply increasing the refresh interval to a fairly large value.
   [RFC2961] and [RFC5439] do talk about increasing the value of the
   refresh-interval
   refresh interval to provide linear improvement on of transmission
   overhead, but also point out the degree of functionality that is lost
   by doing so.  This section revisits this notion, but also proposes
   sufficient recommendations sets out
   additional requirements to make sure that there is no loss of
   functionality incurred by increasing the value of the refresh
   interval.

   An implementation that supports RI-RSVP:

   o  MUST support all the recommendations made requirements specified in Section 2.1. 2.

   o  MUST make the default value of the configurable refresh interval
      be a large value (10s of minutes).  A default value of 20 minutes
      is RECOMMENDED by this document.

   o  MUST implement coupling the state of individual LSPs with the
      state of the corresponding RSVP-TE signaling adjacency.  When an
      RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the
      speaker MUST act as if all the Path and Resv states learnt via the
      failed signaling adjacency have timed out.

   o  MUST make use of Node-ID based Hello Session ([RFC3209],
      [RFC4558]) for detection of RSVP-TE signaling adjacency failures;
      A default value of 9 seconds is RECOMMENDED by this document for
      the configurable node hello interval (as opposed to the 5ms
      default value proposed in Section 5.3 of [RFC3209]).

   o  MUST indicate support for RI-RSVP via the CAPABILITY object
      [RFC5063] in Hello messages.

2.2.1.

3.1.  Capability Advertisement

   An implementation supporting the RI-RSVP recommendations technique MUST set a new
   flag "RI-RSVP Capable" in the CAPABILITY object signaled in Hello
   messages.

   Bit Number TBA1 (TBA2) - RI-RSVP Capable (I-bit):

   Indicates that the sender supports RI-RSVP.

   Any node that sets the new I-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 I-bit in the CAPABILITY object
   but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP
   functionality MUST NOT be activated for that peer.

2.2.2.

3.2.  Compatibility

   The RI-RSVP functionality MUST NOT be activated with a peer that does
   not indicate support for this functionality.

2.3.

4.  Per-Peer RSVP Flow-Control

   The set of recommendations functionality discussed in this section provide provides an RSVP speaker
   with the ability to apply back pressure to its peer(s) to
   reduce/eliminate reduce/
   eliminate a significant portion of the RSVP-TE control plane congestion. message load.

   An implementation that supports "Per-Peer RSVP Flow-Control":

   o  MUST support all the recommendations made requirements specified in Sections 2.1 and 2.2. Section 2.

   o  MUST support "RI-RSVP" (Section 3).

   o  MUST treat lack of ACKs from a peer as an indication of peer's
      RSVP-TE control plane congestion.  If congestion is detected, the
      local system MUST throttle RSVP-TE messages to the affected peer.
      This MUST be done on a per-peer basis.  (Per-peer throttling MAY
      be implemented by a traffic shaping mechanism that proportionally
      reduces the RSVP signaling packet rate as the number of
      outstanding Acks increases.  And when the number of outstanding
      Acks decreases, the send rate would be adjusted up again.)

   o  SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of
      [RFC2961], suggests using 3).

   o  SHOULD prioritize Hello messages and messages carrying
      Acknowledgements over other RSVP messages.

   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 all recommendations in this section technique via the CAPABILITY object
      [RFC5063] in Hello messages.

2.3.1.

4.1.  Capability Advertisement

   An implementation supporting the "Per-Peer Flow-Control"
   recommendations technique
   MUST set a new flag "Per-Peer Flow-Control Capable" in the CAPABILITY
   object signaled in Hello messages.

   Bit Number TBA3 (TBA4) - Per-Peer Flow-Control Capable (F-bit):

   Indicates that the sender supports Per-Peer RSVP Flow-Control.

   Any node that sets the new F-bit in its CAPABILITY object MUST also
   set Refresh-Reduction-Capable bit in 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.

2.3.2.

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 MESSAGE_ID
   object with the ACK-Desired flag set.

3.

5.  Acknowledgements

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

4.

6.  Contributors

   Markus Jork
   Juniper Networks
   Email: mjork@juniper.net

   Ebben Aries
   Juniper Networks
   Email: exa@juniper.net

5.

7.  IANA Considerations

5.1.

7.1.  Capability Object Values

   IANA maintains all the registries associated with "Resource
   Reservation Protocol (RSVP) Paramaters" (see
   http://www.iana.org/assignments/rsvp-parameters/rsvp-
   parameters.xhtml).  "Capability Object Values" Registry (introduced
   by [RFC5063]) is one of them.

   IANA is requested to assign two new Capability Object Value bit flags
   as follows:

      Bit      Hex     Name                                Reference
      Number   Value
      ------------------------------------------------------------------
      TBA1     TBA2    RI-RSVP Capable (I)                 Section 2.2.1 3
      TBA3     TBA4    Per-Peer Flow-Control Capable (F)   Section 2.3.1

6. 4

8.  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.

9.  References

7.1.

9.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,
              <http://www.rfc-editor.org/info/rfc2119>. <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, <http://www.rfc-editor.org/info/rfc2205>. <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,
              <http://www.rfc-editor.org/info/rfc2961>.
              <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,
              <http://www.rfc-editor.org/info/rfc3209>.
              <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,
              <http://www.rfc-editor.org/info/rfc4558>. <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,
              <http://www.rfc-editor.org/info/rfc5063>.

7.2.
              <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>.

9.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,
              <http://www.rfc-editor.org/info/rfc5439>. <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,
              <http://www.rfc-editor.org/info/rfc5920>.
              <https://www.rfc-editor.org/info/rfc5920>.

Appendix A.  Recommended Defaults

      (a) Refresh-Interval (R)- 20 minutes (Section 2.2). 3).
      Given that an implementation supporting RI-RSVP doesn't rely on
      refreshes for state sync between peers, the function of RSVP
      refresh interval is analogous to that of IGP refresh interval (the
      default of which is typically in the order of 10s 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 2.2). 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 2.3). 4).
      Choosing 7 as the retry-limit results in an overall rapid
      retransmit phase of 31.5 seconds.  This matches up with the 31.5
      seconds hello timeout.

      (d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3). 2.3).
      If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7
      rapid retransmit steps to max out (The last delay from message 6
      to message 7 is 16 seconds).  After the 7 rapid retransmit steps
      are maxed out, the router starts periodic retransmission on a
      slower timer.  This document recommends the use of the traditional
      default refresh interval value of 30 seconds for this periodic
      retransmission interval.

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