draft-ietf-teas-rsvp-te-scaling-rec-08.txt   draft-ietf-teas-rsvp-te-scaling-rec-09.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: May 3, 2018 R. Shakir Expires: August 18, 2018 R. Shakir
Google, Inc Google, Inc
D. Pacella D. Pacella
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
October 30, 2017 February 14, 2018
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-08 draft-ietf-teas-rsvp-te-scaling-rec-09
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 May 3, 2018. This Internet-Draft will expire on August 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 . . 4 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 3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 4
3. Refresh-Interval Independent RSVP (RI-RSVP) . . . . . . . . . 5 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . 10 Appendix A. Recommended Defaults . . . . . . . . . . . . . . . . 9
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 46 skipping to change at page 3, line 46
benefits, it is strongly recommended that implementations support benefits, it is strongly recommended that implementations support
both the techniques and have them enabled by default. Both the both the techniques and have them enabled by default. Both the
techniques are fully backward compatible and can be deployed techniques are fully backward compatible and can be deployed
incrementally. 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] with some minor modifications and alterations to
alterations to recommended time intervals and iteration counts (see recommended time intervals and iteration counts (see Appendix A for
Appendix A for the set of recommended defaults) as defined in the the set of recommended defaults).
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 4, line 47 skipping to change at page 4, line 47
In an implementation that supports the techniques discussed in In an implementation that supports the techniques discussed in
Section 3 and Section 4, nodes receiving a non-out of order message Section 3 and Section 4, nodes receiving a non-out of order message
containing a MESSAGE_ID object with the ACK-Desired flag set, MUST containing a MESSAGE_ID object with the ACK-Desired flag set, MUST
respond with a MESSAGE_ID_ACK object. This MESSAGE_ID_ACK object can 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 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 and sent in an Ack message (or piggy-backed in any other RSVP
message). This improvement to the predictability of the system in message). This improvement to the predictability of the system in
terms of reliable message delivery is key for being able to take any terms of reliable message delivery is key for being able to take any
action based on a non-receipt of an ACK. action based on a non-receipt of an ACK.
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 unacknowledged Path/Resv messages (uR)
SHOULD NOT be more than the regular Refresh Interval (R). A default
uR of 30 seconds is RECOMMENDED by this 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.
[RFC2961] and [RFC5439] do talk about increasing the value of the [RFC2961] and [RFC5439] do talk about increasing the value of the
skipping to change at page 5, line 42 skipping to change at page 5, line 20
by doing so. This section revisits this notion, but also sets out by doing so. This section revisits this notion, but also sets out
additional requirements to make sure that there is no loss of additional requirements to make sure that there is no loss of
functionality incurred by increasing the value of the refresh functionality incurred by increasing the value of the refresh
interval. interval.
An implementation that supports RI-RSVP: An implementation that supports RI-RSVP:
o MUST support all the requirements specified in Section 2. o MUST support all the requirements specified in Section 2.
o MUST make the default value of the configurable refresh interval o MUST make the default value of the configurable refresh interval
be a large value (10s of minutes). A default value of 20 minutes (R) be a large value (10s of minutes). A default value of 20
is RECOMMENDED by this document. minutes is RECOMMENDED by this document.
o MUST use a separate shorter refresh interval for refreshing state
associated with unacknowledged Path/Resv messages (uR). A default
value of 30 seconds is RECOMMENDED by this document.
o MUST implement coupling the state of individual LSPs with the o MUST implement coupling the state of individual LSPs with the
state of the corresponding RSVP-TE signaling adjacency. When an state of the corresponding RSVP-TE signaling adjacency. When an
RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the RSVP-TE speaker detects RSVP-TE signaling adjacency failure, the
speaker MUST act as if all the Path and Resv states learnt via the speaker MUST act as if all the Path and Resv states learnt via the
failed signaling adjacency have timed out. failed signaling adjacency have timed out.
o MUST make use of Node-ID based Hello Session ([RFC3209], o MUST make use of Node-ID based Hello Session ([RFC3209],
[RFC4558]) for detection of RSVP-TE signaling adjacency failures; [RFC4558]) for detection of RSVP-TE signaling adjacency failures;
A default value of 9 seconds is RECOMMENDED by this document for A default value of 9 seconds is RECOMMENDED by this document for
skipping to change at page 10, line 7 skipping to change at page 9, line 38
Scaling Issues in MPLS-TE Core Networks", RFC 5439, Scaling Issues in MPLS-TE Core Networks", RFC 5439,
DOI 10.17487/RFC5439, February 2009, <https://www.rfc- DOI 10.17487/RFC5439, February 2009, <https://www.rfc-
editor.org/info/rfc5439>. editor.org/info/rfc5439>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
Appendix A. Recommended Defaults Appendix A. Recommended Defaults
(a) Refresh-Interval (R)- 20 minutes (Section 3). (a) Refresh-Interval (R)- 20 minutes (Section 3):
Given that an implementation supporting RI-RSVP doesn't rely on Given that an implementation supporting RI-RSVP doesn't rely on
refreshes for state sync between peers, the function of RSVP refreshes for state sync between peers, the function of RSVP
refresh interval is analogous to that of IGP refresh interval (the refresh interval is analogous to that of IGP refresh interval (the
default of which is typically in the order of 10s of minutes). default of which is typically in the order of 10s of minutes).
Choosing a default of 20 minutes allows the refresh timer to be 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 randomly set to a value in the range [10 minutes (0.5R), 30
minutes (1.5R)]. minutes (1.5R)].
(b) Node Hello-Interval - 9 Seconds (Section 3). (b) Node Hello-Interval - 9 Seconds (Section 3):
[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 for unacknowledged Path/Resv (d) Refresh-Interval for refreshing state associated with
messages (uR) - 30 seconds (Section 2.3). unacknowledged Path/Resv messages (uR) - 30 seconds (Section 3):
If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the 7 The recommended refresh interval (R) value of 20 minutes (for an
rapid retransmit steps to max out (The last delay from message 6 implementation supporting RI-RSVP) can not be used for refreshing
to message 7 is 16 seconds). After the 7 rapid retransmit steps state associated with unacknowledged Path/Resv messages. This
are maxed out, the router starts periodic retransmission on a document recommends the use of the traditional default refresh
slower timer. This document recommends the use of the traditional interval value of 30 seconds for uR.
default refresh interval value of 30 seconds for this periodic
retransmission interval.
Authors' Addresses Authors' Addresses
Vishnu Pavan Beeram (editor) Vishnu Pavan Beeram (editor)
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Ina Minei Ina Minei
Google, Inc Google, Inc
 End of changes. 15 change blocks. 
49 lines changed or deleted 28 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/