draft-ietf-teas-rsvp-te-scaling-rec-05.txt   draft-ietf-teas-rsvp-te-scaling-rec-06.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: January 3, 2018 R. Shakir Expires: February 11, 2018 R. Shakir
Google, Inc Google, Inc
D. Pacella D. Pacella
Verizon Verizon
T. Saad T. Saad
Cisco Systems Cisco Systems
July 2, 2017 August 10, 2017
Implementation Recommendations to Improve the Scalability of RSVP-TE Implementation Recommendations to Improve the Scalability of RSVP-TE
Deployments Deployments
draft-ietf-teas-rsvp-te-scaling-rec-05 draft-ietf-teas-rsvp-te-scaling-rec-06
Abstract Abstract
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
is growing continually and the onus is on RSVP-TE implementations is growing continually and the onus is on RSVP-TE implementations
across the board to keep up with this increasing demand. across the board to keep up with this increasing demand.
This document introduces a couple of techniques - "Refresh-Interval This document introduces a couple of techniques - "Refresh-Interval
Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help Independent RSVP (RI-RSVP)" and "Per-Peer Flow-Control" - to help
RSVP-TE deployments push the envelope on scaling. RSVP-TE deployments push the envelope on scaling.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 January 3, 2018. This Internet-Draft will expire on February 11, 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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer RSVP's reliance on refreshes and refresh-timeouts while "Per-Peer
Flow-Control" enables a busy RSVP speaker to apply back pressure to Flow-Control" enables a busy RSVP speaker to apply back pressure to
its peer(s). In order to reap maximum scaling benefits, it is its peer(s). In order to reap maximum scaling benefits, it is
strongly RECOMMENDED that implementations support both the strongly RECOMMENDED that implementations support both the
techniques. techniques.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119].
2. Recommendations 2. Recommendations
2.1. "RFC2961 Specific" Recommendations 2.1. "RFC2961 Specific" Recommendations
The implementation recommendations discussed in this section are The implementation recommendations discussed in this section are
based on the proposals made in [RFC2961] and act as prerequisites for based on the proposals made in [RFC2961] and act as prerequisites for
implementing the techniques discussed in Sections 2.2 and 2.3. implementing the techniques discussed in Sections 2.2 and 2.3.
2.1.1. Basic Prerequisites 2.1.1. Basic Prerequisites
skipping to change at page 5, line 33 skipping to change at page 5, line 33
o MUST support all the recommendations made in Section 2.1. o MUST support all the recommendations made in Section 2.1.
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 be a large value (10s of minutes). A default value of 20 minutes
is RECOMMENDED by this document. 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 the all the Path and Resv state learnt via speaker MUST act as if all the Path and Resv states learnt via the
the failed signaling adjacency has 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
the configurable node hello interval (as opposed to the 5ms the configurable node hello interval (as opposed to the 5ms
default value proposed in Section 5.3 of [RFC3209]). default value proposed in Section 5.3 of [RFC3209]).
o MUST indicate support for RI-RSVP via the CAPABILITY object in o MUST indicate support for RI-RSVP via the CAPABILITY object in
Hello messages. Hello messages.
skipping to change at page 6, line 29 skipping to change at page 6, line 29
The set of recommendations discussed in this section provide an RSVP The set of recommendations discussed in this section provide an RSVP
speaker with the ability to apply back pressure to its peer(s) to speaker with the ability to apply back pressure to its peer(s) to
reduce/eliminate RSVP-TE control plane congestion. reduce/eliminate RSVP-TE control plane congestion.
An implementation that supports "Per-Peer RSVP Flow-Control": An implementation that supports "Per-Peer RSVP Flow-Control":
o MUST support all the recommendations made in Sections 2.1 and 2.2. o MUST support all the recommendations made in Sections 2.1 and 2.2.
o MUST treat lack of ACKs from a peer as an indication of peer's 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 RSVP-TE control plane congestion. If congestion is detected, the
local system MUST throttle RSVP-TE messages to the affected peer. local system MUST throttle RSVP-TE messages to the affected peer.
This MUST be done on a per-peer basis. (Per-peer throttling MAY This MUST be done on a per-peer basis. (Per-peer throttling MAY
be implemented by a traffic shaping mechanism that proportionally be implemented by a traffic shaping mechanism that proportionally
reduces the RSVP signaling packet rate as the number of reduces the RSVP signaling packet rate as the number of
outstanding Acks increases. And when the number of outstanding outstanding Acks increases. And when the number of outstanding
Acks decreases, the send rate would be adjusted up again.) Acks decreases, the send rate would be adjusted up again.)
o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of o SHOULD use a Retry Limit (Rl) value of 7 (Section 6.2 of
[RFC2961], suggests using 3). [RFC2961], suggests using 3).
skipping to change at page 7, line 26 skipping to change at page 7, line 26
set Refresh-Reduction-Capable bit in common header of all RSVP-TE 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 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- not set the Refresh-Reduction-Capable bit, then the Per-Peer Flow-
Control functionality MUST NOT be activated for that peer. Control functionality MUST NOT be activated for that peer.
2.3.2. Compatibility 2.3.2. Compatibility
The Per-Peer Flow-Control functionality MUST NOT be activated with a The Per-Peer Flow-Control functionality MUST NOT be activated with a
peer that does not indicate support for this functionality. If 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 hasn't indicated that it is capable of participating in "Per-
Peer Flow-Control", then it is risky to assume 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.
3. Acknowledgements 3. 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 recommendations made in this many discussions that led to the recommendations made in this
document. They would also like to thank Adrian Farrel and Lou Berger document. They would also like to thank Adrian Farrel and Lou Berger
skipping to change at page 9, line 34 skipping to change at page 9, line 34
Scaling Issues in MPLS-TE Core Networks", RFC 5439, Scaling Issues in MPLS-TE Core Networks", RFC 5439,
DOI 10.17487/RFC5439, February 2009, DOI 10.17487/RFC5439, February 2009,
<http://www.rfc-editor.org/info/rfc5439>. <http://www.rfc-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,
<http://www.rfc-editor.org/info/rfc5920>. <http://www.rfc-editor.org/info/rfc5920>.
Appendix A. Recommended Defaults Appendix A. Recommended Defaults
(a) Refresh-Interval (R)- 20 minutes (Section 2.2) Given that an (a) Refresh-Interval (R)- 20 minutes (Section 2.2).
implementation supporting RI-RSVP doesn't rely on refreshes for Given that an implementation supporting RI-RSVP doesn't rely on
state sync between peers, the RSVP refresh interval is sort of refreshes for state sync between peers, the function of RSVP
analogous to IGP refresh interval, the default of which is refresh interval is analogous to that of IGP refresh interval (the
typically in the order of 10s of minutes. Choosing a default of default of which is typically in the order of 10s of minutes).
20 minutes allows the refresh timer to be randomly set to a value Choosing a default of 20 minutes allows the refresh timer to be
in the range [10 minutes (0.5R), 30 minutes (1.5R)]. 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) [RFC3209] (b) Node Hello-Interval - 9 Seconds (Section 2.2).
defines the hello timeout as 3.5 times the hello interval. [RFC3209] defines the hello timeout as 3.5 times the hello
Choosing 9 seconds for the node hello-interval gives a hello interval. Choosing 9 seconds for the node hello-interval gives a
timeout of 3.5*9 = 31.5 seconds. This puts the hello timeout hello timeout of 3.5*9 = 31.5 seconds. This puts the hello
value to be in the same ballpark as the IGP hello timeout value. timeout value in the vicinity of the IGP hello timeout value.
(c) Retry-Limit (Rl) - 7 (Section 2.3) Choosing 7 as the retry- (c) Retry-Limit (Rl) - 7 (Section 2.3).
limit results in an overall rapid retransmit phase of 31.5 Choosing 7 as the retry-limit results in an overall rapid
seconds. This nicely matches up with the 31.5 seconds hello retransmit phase of 31.5 seconds. This matches up with the 31.5
timeout. seconds 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 31.5 seconds for the 7
precise) seconds for the 7 rapid retransmit steps to max out. rapid retransmit steps to max out (The last delay from message 6
(The last delay from message 6 to message 7 is 16 seconds). The to message 7 is 16 seconds). After the 7 rapid retransmit steps
30 seconds interval also matches the traditional default refresh are maxed out, the router starts periodic retransmission on a
time. slower timer. This document recommends the use of the traditional
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. 12 change blocks. 
31 lines changed or deleted 34 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/