draft-ietf-teas-rsvp-te-scaling-rec-07.txt   draft-ietf-teas-rsvp-te-scaling-rec-08.txt 
TEAS Working Group V. Beeram, Ed. TEAS Working Group V. Beeram, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: March 31, 2018 R. Shakir Expires: May 3, 2018 R. Shakir
Google, Inc Google, Inc
D. Pacella D. Pacella
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
September 27, 2017 October 30, 2017
Techniques to Improve the Scalability of RSVP Traffic Engineering Techniques to Improve the Scalability of RSVP Traffic Engineering
Deployments Deployments
draft-ietf-teas-rsvp-te-scaling-rec-07 draft-ietf-teas-rsvp-te-scaling-rec-08
Abstract Abstract
At the time of writing, networks which utilize RSVP Traffic At the time of writing, networks which utilize RSVP Traffic
Engineering (RSVP-TE) Label Switched Paths (LSPs) are encountering Engineering (RSVP-TE) Label Switched Paths (LSPs) are encountering
limitations in the ability of implementations to support the growth limitations in the ability of implementations to support the growth
in the number of LSPs deployed. in the number of LSPs deployed.
This document defines two techniques, "Refresh-Interval Independent This document defines two techniques, "Refresh-Interval Independent
RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that reduce the number RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that reduce the number
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirement for RFC2961 Support . . . . . . . . . . . . . . . 3 2. Requirement for RFC2961 Support . . . . . . . . . . . . . . . 3
2.1. Required Functionality from RFC2961 to be Implemented . . 3 2.1. Required Functionality from RFC2961 to be Implemented . . 4
2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4 2.2. Making Acknowledgements Mandatory . . . . . . . . . . . . 4
2.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . . . 4 2.3. Clarifications On Reaching Rapid Retry Limit (Rl) . . . . 4
3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5 3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5
3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 6
3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 6
4. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . . . 6 4. Per-Peer RSVP Flow-Control . . . . . . . . . . . . . . . . . 6
4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7 4.1. Capability Advertisement . . . . . . . . . . . . . . . . 7
4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Compatibility . . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. Capability Object Values . . . . . . . . . . . . . . . . 8 7.1. Capability Object Values . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
At the time of writing, networks which utilize RSVP Traffic At the time of writing, networks which utilize RSVP Traffic
Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are
encountering limitations in the ability of implementations to support encountering limitations in the ability of implementations to support
the growth in the number of LSPs deployed. the growth in the number of LSPs deployed.
The set of RSVP Refresh Overhead Reduction procedures [RFC2961] The set of RSVP Refresh Overhead Reduction procedures [RFC2961]
skipping to change at page 3, line 32 skipping to change at page 3, line 32
deployments push the envelope further on scaling by increasing the deployments push the envelope further on scaling by increasing the
threshold above which an LSR struggles to achieve sufficient threshold above which an LSR struggles to achieve sufficient
processing to maintain LSP state. processing to maintain LSP state.
This document defines two techniques, "Refresh-Interval Independent This document defines two techniques, "Refresh-Interval Independent
RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that cut down the number RSVP (RI-RSVP)" and "Per-Peer Flow-Control", that cut down the number
of processing cycles required to maintain LSP state. "RI-RSVP" helps of processing cycles required to maintain LSP state. "RI-RSVP" helps
completely eliminate RSVP's reliance on refreshes and refresh- completely eliminate RSVP's reliance on refreshes and refresh-
timeouts while "Per-Peer Flow-Control" enables a busy RSVP speaker to timeouts while "Per-Peer Flow-Control" enables a busy RSVP speaker to
apply back pressure to its peer(s). This document defines a unique apply back pressure to its peer(s). This document defines a unique
RSVP Capability [RFC5063] for each technique. Note that the "Per- RSVP Capability [RFC5063] for each technique (Support for CAPABILITY
Peer Flow-Control" technique requires the "RI-RSVP" technique as a object is a prerequisite for implementing these techniques). Note
prerequisite. In order to reap maximum scaling benefits, it is that the "Per-Peer Flow-Control" technique requires the "RI-RSVP"
strongly recommended that implementations support both the technique as a prerequisite. In order to reap maximum scaling
techniques. Both the techniques are fully backward compatible and benefits, it is strongly recommended that implementations support
can be deployed incrementally. both the techniques and have them enabled by default. Both the
techniques are fully backward compatible and can be deployed
incrementally.
2. Requirement for RFC2961 Support 2. Requirement for RFC2961 Support
The techniques defined in Section 3 and Section 4 are based on The techniques defined in Section 3 and Section 4 are based on
proposals made in [RFC2961]. Implementations of these techniques proposals made in [RFC2961]. Implementations of these techniques
will need to support the RSVP messages and procedures defined in will need to support the RSVP messages and procedures defined in
[RFC2961] as set out in Section 2.1 with some minor modifications and [RFC2961] as set out in Section 2.1 with some minor modifications and
alterations to recommended time intervals and iteration counts as alterations to recommended time intervals and iteration counts (see
defined in the remainder of this section. Appendix A for the set of recommended defaults) as defined in the
remainder of this section.
2.1. Required Functionality from RFC2961 to be Implemented 2.1. Required Functionality from RFC2961 to be Implemented
An implementation that supports the techniques discussed in Section 3 An implementation that supports the techniques discussed in Section 3
and Section 4 must support the functionality described in [RFC2961] and Section 4 must support the functionality described in [RFC2961]
as follows: as follows:
o It MUST indicate support for RSVP Refresh Overhead Reduction o It MUST indicate support for RSVP Refresh Overhead Reduction
extensions (as specified in Section 2 of [RFC2961]). extensions (as specified in Section 2 of [RFC2961]).
skipping to change at page 5, line 8 skipping to change at page 5, line 15
Rl has been reached. Rl has been reached.
If Rl has been reached for the retransmission of a message that is 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 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 further action. If Rl has been reached for the retransmission of a
Path or a Resv message, then the router starts periodic Path or a Resv message, then the router starts periodic
retransmission of these on a slower timer. The retransmitted retransmission of these on a slower timer. The retransmitted
messages MUST carry MESSAGE_ID object with ACK_Desired flag set. messages MUST carry MESSAGE_ID object with ACK_Desired flag set.
This periodic retransmission SHOULD continue until an appropriate This periodic retransmission SHOULD continue until an appropriate
MESSAGE_ID_ACK object is received indicating acknowledgement of the MESSAGE_ID_ACK object is received indicating acknowledgement of the
(retransmitted) Path/Resv message. The configurable periodic (retransmitted) Path/Resv message. The configurable Periodic
retransmission interval for this slower timer SHOULD be less than the Retransmission Interval for unacknowledged Path/Resv messages (uR)
regular refresh interval. A default periodic retransmission interval SHOULD NOT be more than the regular Refresh Interval (R). A default
(for this slower timer) of 30 seconds is RECOMMENDED by this uR of 30 seconds is RECOMMENDED by this document.
document.
3. Refresh-Interval Independent RSVP (RI-RSVP) 3. Refresh-Interval Independent RSVP (RI-RSVP)
The RSVP protocol relies on periodic refreshes for state The RSVP protocol relies on periodic refreshes for state
synchronization between RSVP neighbors and for recovery from lost synchronization between RSVP neighbors and for recovery from lost
RSVP messages. It relies on refresh timeout for stale state cleanup. RSVP messages. It relies on refresh timeout for stale state cleanup.
The primary motivation behind introducing the notion of "Refresh The primary motivation behind introducing the notion of "Refresh
Interval Independent RSVP" (RI-RSVP) is to completely eliminate Interval Independent RSVP" (RI-RSVP) is to completely eliminate
RSVP's reliance on refreshes and refresh timeouts. This is done by RSVP's reliance on refreshes and refresh timeouts. This is done by
simply increasing the refresh interval to a fairly large value. simply increasing the refresh interval to a fairly large value.
skipping to change at page 6, line 27 skipping to change at page 6, line 33
Any node that sets the new I-bit in its CAPABILITY object MUST also 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 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 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 but does not set the Refresh-Reduction-Capable bit, then the RI-RSVP
functionality MUST NOT be activated for that peer. functionality MUST NOT be activated for that peer.
3.2. Compatibility 3.2. Compatibility
The RI-RSVP functionality MUST NOT be activated with a peer that does The RI-RSVP functionality MUST NOT be activated with a peer that does
not indicate support for this functionality. not indicate support for this functionality. Inactivation of the RI-
RSVP functionality MUST result in the use of the traditional smaller
refresh interval [RFC2205].
4. Per-Peer RSVP Flow-Control 4. Per-Peer RSVP Flow-Control
The functionality discussed in this section provides an RSVP speaker The functionality discussed in this section provides an RSVP speaker
with the ability to apply back pressure to its peer(s) to reduce/ with the ability to apply back pressure to its peer(s) to reduce/
eliminate a significant portion of the RSVP-TE control message load. eliminate a significant portion of the RSVP-TE control message load.
An implementation that supports "Per-Peer RSVP Flow-Control": An implementation that supports "Per-Peer RSVP Flow-Control":
o MUST support all the requirements specified in Section 2. o MUST support all the requirements specified in Section 2.
skipping to change at page 7, line 46 skipping to change at page 8, line 5
Peer Flow-Control", then it SHOULD NOT be assumed that the peer would 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 always acknowledge a non-out of order message containing a MESSAGE_ID
object with the ACK-Desired flag set. object with the ACK-Desired flag set.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Yakov Rekhter for initiating this The authors would like to thank Yakov Rekhter for initiating this
work and providing valuable inputs. They would like to thank work and providing valuable inputs. They would like to thank
Raveendra Torvi and Chandra Ramachandran for participating in the Raveendra Torvi and Chandra Ramachandran for participating in the
many discussions that led to the techniques discussed in this many discussions that led to the techniques discussed in this
document. They would also like to thank Adrian Farrel and Lou Berger document. They would also like to thank Adrian Farrel, Lou Berger
for providing detailed review comments. and Elwyn Davies for providing detailed review comments and text
suggestions.
6. Contributors 6. Contributors
Markus Jork Markus Jork
Juniper Networks Juniper Networks
Email: mjork@juniper.net Email: mjork@juniper.net
Ebben Aries Ebben Aries
Juniper Networks Juniper Networks
Email: exa@juniper.net Email: exa@juniper.net
skipping to change at page 10, line 20 skipping to change at page 10, line 27
[RFC3209] defines the hello timeout as 3.5 times the hello [RFC3209] defines the hello timeout as 3.5 times the hello
interval. Choosing 9 seconds for the node hello-interval gives a interval. Choosing 9 seconds for the node hello-interval gives a
hello timeout of 3.5*9 = 31.5 seconds. This puts the hello hello timeout of 3.5*9 = 31.5 seconds. This puts the hello
timeout value in the vicinity of the IGP hello timeout value. timeout value in the vicinity of the IGP hello timeout value.
(c) Retry-Limit (Rl) - 7 (Section 4). (c) Retry-Limit (Rl) - 7 (Section 4).
Choosing 7 as the retry-limit results in an overall rapid Choosing 7 as the retry-limit results in an overall rapid
retransmit phase of 31.5 seconds. This matches up with the 31.5 retransmit phase of 31.5 seconds. This matches up with the 31.5
seconds hello timeout. seconds hello timeout.
(d) Periodic Retransmission Interval - 30 seconds (Section 2.3). (d) Periodic Retransmission Interval for unacknowledged Path/Resv
messages (uR) - 30 seconds (Section 2.3).
If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 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 rapid retransmit steps to max out (The last delay from message 6
to message 7 is 16 seconds). After the 7 rapid retransmit steps to message 7 is 16 seconds). After the 7 rapid retransmit steps
are maxed out, the router starts periodic retransmission on a are maxed out, the router starts periodic retransmission on a
slower timer. This document recommends the use of the traditional slower timer. This document recommends the use of the traditional
default refresh interval value of 30 seconds for this periodic default refresh interval value of 30 seconds for this periodic
retransmission interval. retransmission interval.
Authors' Addresses Authors' Addresses
 End of changes. 12 change blocks. 
23 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/