draft-ietf-teas-rsvp-te-scaling-rec-02.txt   draft-ietf-teas-rsvp-te-scaling-rec-03.txt 
TEAS Working Group Vishnu Pavan Beeram TEAS Working Group Vishnu Pavan Beeram
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Proposed Standard Ina Minei Intended status: Proposed Standard Ina Minei
Google, Inc Google, Inc
Rob Shakir Rob Shakir
Google, Inc Google, Inc
Dante Pacella Dante Pacella
Verizon Verizon
Tarek Saad Tarek Saad
Cisco Systems Cisco Systems
Expires: March 21, 2017 September 21, 2016
Implementation Recommendations to Improve the Scalability of RSVP-TE
Deployments
draft-ietf-teas-rsvp-te-scaling-rec-02
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Expires: April 30, 2017 October 30, 2016
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 21, 2017. Implementation Recommendations to Improve the Scalability of RSVP-TE
Deployments
draft-ietf-teas-rsvp-te-scaling-rec-03
Copyright Notice Status of this Memo
Copyright (c) 2016 IETF Trust and the persons identified as the This Internet-Draft is submitted in full conformance with the
document authors. All rights reserved. provisions of BCP 78 and BCP 79.
This document is subject to BCP 78 and the IETF Trust's Legal Internet-Drafts are working documents of the Internet Engineering
Provisions Relating to IETF Documents Task Force (IETF), its areas, and its working groups. Note that
(http://trustee.ietf.org/license-info) in effect on the date of other groups may also distribute working documents as Internet-
publication of this document. Please review these documents Drafts.
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.
Abstract 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."
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed The list of current Internet-Drafts can be accessed at
is growing continually and the onus is on RSVP-TE implementations http://www.ietf.org/ietf/1id-abstracts.txt
across the board to keep up with this increasing demand.
This document makes a set of implementation recommendations to help The list of Internet-Draft Shadow Directories can be accessed at
RSVP-TE deployments push the envelope on scaling and advocates the http://www.ietf.org/shadow.html
use of a couple of techniques - "Refresh Interval Independent RSVP
(RI-RSVP)" and "Per-Peer flow-control" - for improving scaling.
Conventions used in this document This Internet-Draft will expire on April 30, 2017.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Copyright Notice
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
1. Introduction...................................................3 This document is subject to BCP 78 and the IETF Trust's Legal
2. Recommendations................................................3 Provisions Relating to IETF Documents
2.1. "RFC2961 specific" Recommendations........................3 (http://trustee.ietf.org/license-info) in effect on the date of
2.1.1. Basic Pre-Requisites.................................4 publication of this document. Please review these documents
2.1.2. Making Acknowledgements mandatory....................4 carefully, as they describe your rights and restrictions with
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)....4 respect to this document. Code Components extracted from this
2.2. Refresh Interval Independent RSVP.........................5 document must include Simplified BSD License text as described in
2.2.1. Capability Advertisement.............................6 Section 4.e of the Trust Legal Provisions and are provided without
2.2.2. Compatibility........................................6 warranty as described in the Simplified BSD License.
2.3. Per-Peer RSVP Flow Control................................7
2.3.1. Capability Advertisement.............................7
2.3.2. Compatibility........................................8
2.4. Other Recommendations.....................................8
2.4.1. Summary FRR..........................................8
3. Security Considerations........................................8
4. IANA Considerations............................................9
4.1. Capability Object Values..................................9
5. References.....................................................9
5.1. Normative References......................................9
5.2. Informative References...................................10
6. Acknowledgments...............................................10
Appendix A. Recommended Defaults.................................10
Contributors.....................................................11
Authors' Addresses...............................................11
1. Introduction Abstract
The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
deployed is growing continually and there is considerable onus on is growing continually and the onus is on RSVP-TE implementations
RSVP-TE implementations across the board to keep up with this across the board to keep up with this increasing demand.
increasing demand in scale.
The set of RSVP Refresh Overhead Reduction procedures [RFC2961] This document makes a set of implementation recommendations to help
serves as a powerful toolkit for RSVP-TE implementations to help RSVP-TE deployments push the envelope on scaling and advocates the
cover a majority of the concerns about soft-state scaling. However, use of a couple of techniques - "Refresh Interval Independent RSVP
even with these tools in the toolkit, analysis of existing (RI-RSVP)" and "Per-Peer flow-control" - for improving scaling.
implementations [RFC5439] indicates that the processing required
under certain scale may still cause significant disruption to an
LSR.
This document builds on the scaling work and analysis that has been Conventions used in this document
done so far and makes a set of concrete implementation
recommendations to help RSVP-TE deployments push the envelope
further on scaling - push higher 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Interval Independent RSVP (RI-RSVP)" and "Per-Peer flow-control" - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
for significantly cutting down the amount of processing cycles document are to be interpreted as described in RFC-2119 [RFC2119].
required to maintain LSP state. "RI-RSVP" helps completely eliminate
RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer
Flow-Control" enables a busy RSVP speaker to apply back pressure to
its peer(s). In order to reap maximum scaling benefits, it is
strongly RECOMMENDED that implementations support both the
techniques, but it is possible for an implementation to support just
one but not the other.
2. Recommendations Table of Contents
2.1. "RFC2961 specific" Recommendations 1. Introduction...................................................3
2. Recommendations................................................3
2.1. "RFC2961 specific" Recommendations........................3
2.1.1. Basic Pre-Requisites.................................4
2.1.2. Making Acknowledgements mandatory....................4
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)....4
2.2. Refresh Interval Independent RSVP.........................5
2.2.1. Capability Advertisement.............................6
2.2.2. Compatibility........................................6
2.3. Per-Peer RSVP Flow Control................................6
2.3.1. Capability Advertisement.............................7
2.3.2. Compatibility........................................7
3. Security Considerations........................................8
4. IANA Considerations............................................8
4.1. Capability Object Values..................................8
5. References.....................................................8
5.1. Normative References......................................8
5.2. Informative References....................................9
The implementation recommendations discussed in this section are 6. Acknowledgments................................................9
based on the proposals made in [RFC2961] and act as pre-requisites Appendix A. Recommended Defaults..................................9
for implementing either or both of the techniques discussed in Contributors.....................................................10
Sections 2.2 and 2.3. Authors' Addresses...............................................10
2.1.1. Basic Pre-Requisites 1. Introduction
An implementation that supports either or both of the techniques The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get
discussed in Sections 2.2 and 2.3: deployed is growing continually and there is considerable onus on
RSVP-TE implementations across the board to keep up with this
increasing demand in scale.
- SHOULD indicate support for RSVP Refresh Overhead Reduction The set of RSVP Refresh Overhead Reduction procedures [RFC2961]
extensions (as specified in Section 2 of [RFC2961]) by default, serves as a powerful toolkit for RSVP-TE implementations to help
with the ability to override the default via configuration. 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 certain scale may still cause significant disruption to an
LSR.
- MUST support reliable delivery of Path/Resv and the corresponding This document builds on the scaling work and analysis that has been
Tear/Err messages using the procedures specified in [RFC2961]. done so far and makes a set of concrete implementation
recommendations to help RSVP-TE deployments push the envelope
further on scaling - push higher the threshold above which an LSR
struggles to achieve sufficient processing to maintain LSP state.
- MUST support retransmit of all RSVP-TE messages using exponential- This document advocates the use of a couple of techniques - "Refresh
backoff, as specified in Section 6 of [RFC2961]. Interval Independent RSVP (RI-RSVP)" and "Per-Peer flow-control" -
for significantly cutting down the amount of processing cycles
required to maintain LSP state. "RI-RSVP" helps completely eliminate
RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer
Flow-Control" enables a busy RSVP speaker to apply back pressure to
its peer(s). In order to reap maximum scaling benefits, it is
strongly RECOMMENDED that implementations support both the
techniques, but it is possible for an implementation to support just
one but not the other.
2.1.2. Making Acknowledgements mandatory 2. Recommendations
The reliable message delivery mechanism specified in [RFC2961] 2.1. "RFC2961 specific" Recommendations
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 either or both of the techniques The implementation recommendations discussed in this section are
discussed in Sections 2.2 and 2.3, nodes receiving a non-out of based on the proposals made in [RFC2961] and act as pre-requisites
order message containing a MESSAGE ID object with the ACK-Desired for implementing either or both of the techniques discussed in
flag set, MUST respond with a MESSAGE_ID_ACK object. This Sections 2.2 and 2.3.
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. Clarifications on reaching Rapid Retry Limit (Rl) 2.1.1. Basic Pre-Requisites
According to section 6 of [RFC2961] "The staged retransmission will An implementation that supports either or both of the techniques
continue until either an appropriate MESSAGE_ID_ACK object is discussed in Sections 2.2 and 2.3:
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 it is the retransmission of Tear/Err messages and Rl has been - SHOULD indicate support for RSVP Refresh Overhead Reduction
reached, the router need not take any further actions. If it is the extensions (as specified in Section 2 of [RFC2961]) by default,
retransmission of Path/Resv messages and Rl has been reached, then with the ability to override the default via configuration.
the router starts periodic retransmission of these messages. 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 SHOULD be less than
the regular refresh interval. A default periodic retransmission
interval of 30 seconds is RECOMMENDED by this document.
2.2. Refresh Interval Independent RSVP - MUST support reliable delivery of Path/Resv and the corresponding
Tear/Err messages using the procedures specified in [RFC2961].
The RSVP protocol relies on periodic refreshes for state - MUST support retransmit of all RSVP-TE messages using exponential-
synchronization between RSVP neighbors and for recovery from lost backoff, as specified in Section 6 of [RFC2961].
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 to provide linear improvement on 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 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: 2.1.2. Making Acknowledgements mandatory
- MUST support all the recommendations made in Section 2.1 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."
- MUST make the default value of the configurable refresh interval In an implementation that supports either or both of the techniques
be a large value (10s of minutes). A default value of 20 minutes discussed in Sections 2.2 and 2.3, nodes receiving a non-out of
is RECOMMENDED by this document. order message containing a MESSAGE ID object with the ACK-Desired
flag set, MUST respond with a MESSAGE_ID_ACK object. 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.
- MUST implement coupling the state of individual LSPs with the 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)
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 the all the Path and Resv state learnt via
the failed signaling adjacency has timed out.
- MUST make use of Node-ID based Hello Session ([RFC3209], According to section 6 of [RFC2961] "The staged retransmission will
[RFC4558]) for detection of RSVP-TE signaling adjacency failures; continue until either an appropriate MESSAGE_ID_ACK object is
A default value of 9 seconds is RECOMMENDED by this document for received, or the rapid retry limit, Rl, has been reached." The
the configurable node hello interval (as opposed to the 5ms following clarifies what actions, if any, a router should take once
default value proposed in Section 5.3 of [RFC3209]). Rl has been reached.
- (If Bypass FRR [RFC4090] is supported,) MUST implement procedures If it is the retransmission of Tear/Err messages and Rl has been
specified in [RI-RSVP-FRR] which describes methods to facilitate reached, the router need not take any further actions. If it is the
FRR that works independently of the refresh-interval. retransmission of Path/Resv messages and Rl has been reached, then
the router starts periodic retransmission of these messages. 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 SHOULD be less than
the regular refresh interval. A default periodic retransmission
interval of 30 seconds is RECOMMENDED by this document.
- MUST indicate support for RI-RSVP via the CAPABILITY object in 2.2. Refresh Interval Independent RSVP
Hello messages.
2.2.1. Capability Advertisement 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 to provide linear improvement on 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 to make sure that there is no
loss of functionality incurred by increasing the value of the
refresh interval.
An implementation supporting the RI-RSVP recommendations MUST set a An implementation that supports RI-RSVP:
new flag "RI-RSVP Capable" in the CAPABILITY object signaled in
Hello messages.
The new flag that will be introduced to CAPABILITY object is - MUST support all the recommendations made in Section 2.1
specified below.
0 1 2 3 - MUST make the default value of the configurable refresh interval
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 be a large value (10s of minutes). A default value of 20 minutes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ is RECOMMENDED by this document.
| Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit - 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 the all the Path and Resv state learnt via
the failed signaling adjacency has timed out.
Indicates that the sender supports RI-RSVP. - 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]).
Any node that sets the new I-bit in its CAPABILITY object MUST also - MUST indicate support for RI-RSVP via the CAPABILITY object in
set Refresh-Reduction-Capable bit in common header of all RSVP-TE Hello messages.
messages.
2.2.2. Compatibility 2.2.1. Capability Advertisement
The RI-RSVP functionality MUST be activated only between peers that An implementation supporting the RI-RSVP recommendations MUST set a
indicate their support for this functionality. The RI-RSVP specific new flag "RI-RSVP Capable" in the CAPABILITY object signaled in
Bypass FRR procedures discussed in [RI-RSVP-FRR] introduce a few new Hello messages.
protocol extensions and those MUST get activated only if the
participating nodes support RI-RSVP functionality.
2.3. Per-Peer RSVP Flow Control The new flag that will be introduced to CAPABILITY object is
specified below.
The set of recommendations discussed in this section provide an RSVP 0 1 2 3
speaker with the ability to apply back pressure to its peer(s) to 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
reduce/eliminate RSVP-TE control plane congestion. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An implementation that supports "Per-Peer RSVP Flow Control": I bit
- MUST support all the recommendations made in Section 2.1 Indicates that the sender supports RI-RSVP.
- MUST use lack of ACKs from a peer as an indication of peer's RSVP- Any node that sets the new I-bit in its CAPABILITY object MUST also
TE control plane congestion. If congestion is detected, the local set Refresh-Reduction-Capable bit in common header of all RSVP-TE
system MUST throttle RSVP-TE messages to the affected peer. This messages.
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.)
- SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of 2.2.2. Compatibility
[RFC2961], suggests using 3).
- SHOULD prioritize Tear/Error over trigger Path/Resv (messages that The RI-RSVP functionality MUST be activated only between peers that
bring up new LSP state) sent to a peer when the local system indicate their support for this functionality.
detects RSVP-TE control plane congestion in the peer.
- MUST indicate support for all recommendations in this section via 2.3. Per-Peer RSVP Flow Control
the CAPABILITY object in Hello messages.
2.3.1. Capability Advertisement The set of recommendations discussed in this section provide an RSVP
speaker with the ability to apply back pressure to its peer(s) to
reduce/eliminate RSVP-TE control plane congestion.
An implementation supporting the "Per-Peer Flow Control" An implementation that supports "Per-Peer RSVP Flow Control":
recommendations MUST set a new flag "Per-Peer Flow Control Capable"
in the CAPABILITY object signaled in Hello messages.
The new flag that will be introduced to CAPABILITY object is - MUST support all the recommendations made in Section 2.1
specified below.
0 1 2 3 - MUST use lack of ACKs from a peer as an indication of peer's RSVP-
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 TE control plane congestion. If congestion is detected, the local
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ system MUST throttle RSVP-TE messages to the affected peer. This
| Length | Class-Num(134)| C-Type (1) | MUST be done on a per-peer basis. (Per-peer throttling MAY be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ implemented by a traffic shaping mechanism that proportionally
| Reserved |F|I|T|R|S| 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.)
F bit - SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of
[RFC2961], suggests using 3).
Indicates that the sender supports Per-Peer RSVP Flow Control - 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.
Any node that sets the new I-bit in its CAPABILITY object MUST also - MUST indicate support for all recommendations in this section via
set Refresh-Reduction-Capable bit in common header of all RSVP-TE the CAPABILITY object in Hello messages.
messages.
2.3.2. Compatibility 2.3.1. Capability Advertisement
The "Per-Peer Flow Control" functionality MUST be activated only if An implementation supporting the "Per-Peer Flow Control"
both peers support it. If a peer hasn't indicated that it is capable recommendations MUST set a new flag "Per-Peer Flow Control Capable"
of participating in "Per-Peer Flow Control", then it is risky to in the CAPABILITY object signaled in Hello messages.
assume that the peer would always acknowledge a non-out of order
message containing a MESSAGE ID object with the ACK-Desired flag
set.
2.4. Other Recommendations The new flag that will be introduced to CAPABILITY object is
specified below.
The following scaling recommendations have no interdependency with 0 1 2 3
any of the techniques/recommendations specified in Sections 2.2 and 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
2.3. These are stand-alone functionalities that help improve RSVP-TE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
scalability. | Length | Class-Num(134)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |F|I|T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.4.1. Summary FRR F bit
If Bypass FRR [RFC4090] is supported by an implementation, it SHOULD Indicates that the sender supports Per-Peer RSVP Flow Control
support the procedures discussed in [SUMMARY-FRR]. These procedures
reduce the amount of RSVP signaling required for Fast Reroute
procedures and subsequently improve the scalability of RSVP-TE
signaling when undergoing FRR convergence post a link or node
failure.
3. Security Considerations Any node that sets the new I-bit in its CAPABILITY object MUST also
set Refresh-Reduction-Capable bit in common header of all RSVP-TE
messages.
This document does not introduce new security issues. The security 2.3.2. Compatibility
considerations pertaining to the original RSVP protocol [RFC2205]
and RSVP-TE [RFC3209] and those that are described in [RFC5920]
remain relevant.
4. IANA Considerations The "Per-Peer Flow Control" functionality MUST be activated only if
both peers support it. If a peer hasn't indicated that it is capable
of participating in "Per-Peer Flow Control", then it is risky to
assume that the peer would always acknowledge a non-out of order
message containing a MESSAGE ID object with the ACK-Desired flag
set.
4.1. Capability Object Values 3. Security Considerations
IANA maintains all the registries associated with "Resource This document does not introduce new security issues. The security
Reservation Protocol (RSVP) Paramaters" (see considerations pertaining to the original RSVP protocol [RFC2205]
http://www.iana.org/assignments/rsvp-parameters/rsvp- and RSVP-TE [RFC3209] and those that are described in [RFC5920]
parameters.xhtml). "Capability Object Values" Registry (introduced remain relevant.
by [RFC5063]) is one of them.
IANA is requested to assign two new Capability Object Value bit 4. IANA Considerations
flags as follows:
Bit Hex Name Reference 4.1. Capability Object Values
Number Value
--------------------------------------------------------------------
TBA TBA RI-RSVP Capable (I) Section 2.2.1
TBA TBA Per-Peer Flow Control Capable (F) Section 2.3.1
5. References 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.
5.1. Normative References IANA is requested to assign two new Capability Object Value bit
flags as follows:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Bit Hex Name Reference
Requirement Levels", BCP 14, RFC 2119, March 1997. Number Value
--------------------------------------------------------------------
TBA TBA RI-RSVP Capable (I) Section 2.2.1
TBA TBA Per-Peer Flow Control Capable (F) Section 2.3.1
[RFC2205] Braden, R., "Resource Reservation Protocol (RSVP)", 5. References
RFC 2205, September 1997.
[RFC2961] Berger, L., "RSVP Refresh Overhead Reduction 5.1. Normative References
Extensions", RFC 2961, April 2001.
[RFC3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Tunnels", RFC 3209, December 2001. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4090] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP [RFC2205] Braden, R., "Resource Reservation Protocol (RSVP)",
Tunnels", RFC 4090, May 2005. RFC 2205, September 1997.
[RFC4558] Ali, Z., "Node-ID Based Resource Reservation (RSVP) [RFC2961] Berger, L., "RSVP Refresh Overhead Reduction
Hello: A Clarification Statement", RFC 4558, June 2006. Extensions", RFC 2961, April 2001.
[RFC5063] Satyanarayana, A., "Extensions to GMPLS Resource [RFC3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP
Reservation Protocol Graceful Restart", RFC5063, October Tunnels", RFC 3209, December 2001.
2007.
[RI-RSVP-FRR] Ramachandran, C., "Refresh Interval Independent FRR [RFC4558] Ali, Z., "Node-ID Based Resource Reservation (RSVP)
Facility Protection", draft-ietf-mpls-ri-rsvp-frr, Hello: A Clarification Statement", RFC 4558, June 2006.
(work in progress)
[SUMMARY-FRR] Taillon, M., "RSVP-TE Summary Fast Reroute Extensions [RFC5063] Satyanarayana, A., "Extensions to GMPLS Resource
for LSP Tunnels", draft-mtaillon-mpls-summary-frr- Reservation Protocol Graceful Restart", RFC5063, October
rsvpte, (work in progress) 2007.
5.2. Informative References 5.2. Informative References
[RFC5439] Yasukawa, S., "An Analysis of Scaling Issues in MPLS-TE [RFC5439] Yasukawa, S., "An Analysis of Scaling Issues in MPLS-TE
Core Networks", RFC 5439, February 2009. Core Networks", RFC 5439, February 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC5920, July 2010. Networks", RFC5920, July 2010.
6. Acknowledgments 6. Acknowledgments
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 recommendations made in this many discussions that led to the recommendations made in this
document. They would also like to thank Adrian Farrel for providing document. They would also like to thank Adrian Farrel for providing
detailed review comments. detailed review comments.
Appendix A. Recommended Defaults Appendix A. Recommended Defaults
(a) Refresh-Interval (R)- 20 minutes (Section 2.2) (a) Refresh-Interval (R)- 20 minutes (Section 2.2)
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 RSVP refresh interval is refreshes for state sync between peers, the RSVP refresh interval is
sort of analogous to IGP refresh interval, the default of which is sort of analogous to IGP refresh interval, the default of which is
typically in the order of 10s of minutes. Choosing a default of 20 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 minutes allows the refresh timer to be randomly set to a value in
the range [10 minutes (0.5R), 30 minutes (1.5R)]. the range [10 minutes (0.5R), 30 minutes (1.5R)].
(b) Node Hello-Interval - 9 Seconds (Section 2.2) (b) Node Hello-Interval - 9 Seconds (Section 2.2)
[RFC3209] defines the hello timeout as 3.5 times the hello interval. [RFC3209] defines the hello timeout as 3.5 times the hello interval.
Choosing 9 seconds for the node hello-interval gives a hello timeout 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 to be in of 3.5*9 = 31.5 seconds. This puts the hello timeout value to be in
the same ballpark as the IGP hello timeout value. the same ballpark as the IGP hello timeout value.
(c) Retry-Limit (Rl) - 7 (Section 2.3) (c) Retry-Limit (Rl) - 7 (Section 2.3)
Choosing 7 as the retry-limit results in an overall rapid retransmit Choosing 7 as the retry-limit results in an overall rapid retransmit
phase of 31.5 seconds. This nicely matches up with the 31.5 seconds phase of 31.5 seconds. This nicely matches up with the 31.5 seconds
hello timeout. hello timeout.
(d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3) (d) Periodic Retransmission Interval - 30 seconds (Section 2.1.3)
If the Retry-Limit (Rl) is 7, then it takes about 30 (31.5 to be If the Retry-Limit (Rl) is 7, then it takes about 30 (31.5 to be
precise) seconds for the 7 rapid retransmit steps to max out. (The precise) seconds for the 7 rapid retransmit steps to max out. (The
last delay from message 6 to message 7 is 16 seconds). The 30 last delay from message 6 to message 7 is 16 seconds). The 30
seconds interval also matches the traditional default refresh time. seconds interval also matches the traditional default refresh time.
Contributors Contributors
Markus Jork Markus Jork
Juniper Networks Juniper Networks
Email: mjork@juniper.net Email: mjork@juniper.net
Ebben Aries Ebben Aries
Facebook Juniper Networks
Email: exa@juniper.net Email: exa@juniper.net
Authors' Addresses Authors' Addresses
Vishnu Pavan Beeram (Ed) Vishnu Pavan Beeram (Ed)
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
Ina Minei Ina Minei
Google, Inc Google, Inc
Email: inaminei@google.com Email: inaminei@google.com
Rob Shakir Rob Shakir
Google, Inc Google, Inc
Email: rjs@rob.sh Email: rjs@rob.sh
Dante Pacella Dante Pacella
Verizon Verizon
Email: dante.j.pacella@verizon.com Email: dante.j.pacella@verizon.com
Tarek Saad Tarek Saad
Cisco Systems Cisco Systems
Email: tsaad@cisco.com Email: tsaad@cisco.com
 End of changes. 108 change blocks. 
371 lines changed or deleted 336 lines changed or added

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