draft-ietf-teas-rsvp-te-scaling-rec-00.txt   draft-ietf-teas-rsvp-te-scaling-rec-01.txt 
TEAS Working Group Vishnu Pavan Beeram (Ed) 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
British Telecom Jive Communications
Ebben Aries
Facebook
Dante Pacella Dante Pacella
Verizon Verizon
Tarek Saad Tarek Saad
Cisco Systems Cisco Systems
Markus Jork
Juniper Networks
Expires: April 5, 2016 October 5, 2015 Expires: September 21, 2016 March 21, 2016
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-00 draft-ietf-teas-rsvp-te-scaling-rec-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 45 skipping to change at page 1, line 41
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 5, 2016. This Internet-Draft will expire on September 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 37 skipping to change at page 2, line 32
Conventions used in this document 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 RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Recommendations................................................4 2. Recommendations................................................3
2.1. "RFC2961 specific" Recommendations........................4 2.1. "RFC2961 specific" Recommendations........................3
2.1.1. Basic Pre-Requisites.................................4 2.1.1. Basic Pre-Requisites.................................4
2.1.2. Making Acknowledgements mandatory....................4 2.1.2. Making Acknowledgements mandatory....................4
2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)....4 2.1.3. Clarifications on reaching Rapid Retry Limit (Rl)....4
2.2. Refresh Interval Independent RSVP.........................5 2.2. Refresh Interval Independent RSVP.........................5
2.2.1. Capability Advertisement.............................6 2.2.1. Capability Advertisement.............................6
2.2.2. Compatibility........................................6 2.2.2. Compatibility........................................6
2.3. Per-Peer RSVP Flow Control................................7 2.3. Per-Peer RSVP Flow Control................................7
2.3.1. Capability Advertisement.............................7 2.3.1. Capability Advertisement.............................7
2.3.2. Compatibility........................................8 2.3.2. Compatibility........................................8
2.4. Other Recommendations.....................................8 2.4. Other Recommendations.....................................8
2.4.1. Summary FRR..........................................8 2.4.1. Summary FRR..........................................8
3. Security Considerations........................................8 3. Security Considerations........................................8
4. IANA Considerations............................................9 4. IANA Considerations............................................9
4.1. Capability Object Values..................................9 4.1. Capability Object Values..................................9
5. References.....................................................9 5. References.....................................................9
5.1. Normative References......................................9 5.1. Normative References......................................9
5.2. Informative References...................................10 5.2. Informative References...................................10
6. Acknowledgments...............................................10 6. Acknowledgments...............................................10
Appendix A. Recommended Defaults.................................10 Appendix A. Recommended Defaults.................................10
Contributors.....................................................11
Authors' Addresses...............................................11 Authors' Addresses...............................................11
1. Introduction 1. Introduction
The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get
deployed is growing continually and there is considerable onus on deployed is growing continually and there is considerable onus on
RSVP-TE implementations across the board to keep up with this RSVP-TE implementations across the board to keep up with this
increasing demand in scale. increasing demand in scale.
The set of RSVP Refresh Overhead Reduction procedures [RFC2961] The set of RSVP Refresh Overhead Reduction procedures [RFC2961]
skipping to change at page 9, line 9 skipping to change at page 9, line 9
This document does not introduce new security issues. The security This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205] considerations pertaining to the original RSVP protocol [RFC2205]
and RSVP-TE [RFC3209] and those that are described in [RFC5920] and RSVP-TE [RFC3209] and those that are described in [RFC5920]
remain relevant. remain relevant.
4. IANA Considerations 4. IANA Considerations
4.1. Capability Object Values 4.1. Capability Object Values
[RFC5063] defines the name space for RSVP Capability Object Values. IANA maintains all the registries associated with "Resource
The name space is managed by IANA. Reservation Protocol (RSVP) Paramaters" (see
http://www.iana.org/assignments/rsvp-parameters/rsvp-
IANA registry: RSVP PARAMETERS parameters.xhtml). "Capability Object Values" Registry (introduced
by [RFC5063]) is one of them.
Subsection: Capability Object Values
A Capability flag called "RI-RSVP Capable" is defined in Section IANA is requested to assign two new Capability Object Value bit
2.2.1 of this document. The bit number for this flag is TBD. flags as follows:
A Capability flag called "Per-Peer Flow Control Capable" is defined Bit Hex Name Reference
in Section 2.3.1 of this document. The bit number for this flag is Number Value
TBD. --------------------------------------------------------------------
TBA TBA RI-RSVP Capable (I) Section 2.2.1
TBA TBA Per-Peer Flow Control Capable (F) Section 2.3.1
5. References 5. References
5.1. Normative References 5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., "Resource Reservation Protocol (RSVP)", [RFC2205] Braden, R., "Resource Reservation Protocol (RSVP)",
RFC 2205, September 1997. RFC 2205, September 1997.
skipping to change at page 10, line 8 skipping to change at page 10, line 9
[RFC5063] Satyanarayana, A., "Extensions to GMPLS Resource [RFC5063] Satyanarayana, A., "Extensions to GMPLS Resource
Reservation Protocol Graceful Restart", RFC5063, October Reservation Protocol Graceful Restart", RFC5063, October
2007. 2007.
[RI-RSVP-FRR] Ramachandran, C., "Refresh Interval Independent FRR [RI-RSVP-FRR] Ramachandran, C., "Refresh Interval Independent FRR
Facility Protection", draft-chandra-mpls-ri-rsvp-frr, Facility Protection", draft-chandra-mpls-ri-rsvp-frr,
(work in progress) (work in progress)
[SUMMARY-FRR] Taillon, M., "RSVP-TE Summary Fast Reroute Extensions [SUMMARY-FRR] Taillon, M., "RSVP-TE Summary Fast Reroute Extensions
for LSP Tunnels", draft-mtaillon-mpls-summary-frr- for LSP Tunnels", draft-mtaillon-mpls-summary-frr-
rsvpte-00, (work in progress) rsvpte, (work in progress)
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
skipping to change at page 11, line 9 skipping to change at page 11, line 11
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
Markus Jork
Juniper Networks
Email: mjork@juniper.net
Ebben Aries
Juniper Networks
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
British Telecom Jive Communications, Inc
Email: rob.shakir@bt.com Email: rjs@rob.sh
Ebben Aries
Facebook
Email: exa@fb.com
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
Markus Jork
Juniper Networks
Email: mjork@juniper.net
 End of changes. 16 change blocks. 
30 lines changed or deleted 35 lines changed or added

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