draft-ietf-mpls-summary-frr-rsvpte-02.txt   draft-ietf-mpls-summary-frr-rsvpte-03.txt 
MPLS Working Group M. Taillon MPLS Working Group M. Taillon
Internet-Draft T. Saad, Ed. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track R. Gandhi Intended status: Standards Track T. Saad, Ed.
Expires: May 7, 2019 Cisco Systems, Inc. Expires: November 3, 2019 Juniper Networks
R. Gandhi
Cisco Systems, Inc.
A. Deshmukh A. Deshmukh
Juniper Networks
M. Jork M. Jork
128 Technology
V. Beeram V. Beeram
Juniper Networks Juniper Networks
November 03, 2018 May 02, 2019
RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels
draft-ietf-mpls-summary-frr-rsvpte-02 draft-ietf-mpls-summary-frr-rsvpte-03
Abstract Abstract
This document defines Resource Reservation Protocol (RSVP) Traffic- This document defines Resource Reservation Protocol (RSVP) Traffic-
Engineering (TE) signaling extensions that reduce the amount of RSVP Engineering (TE) signaling extensions that reduce the amount of RSVP
signaling required for Fast Reroute (FRR) procedures and subsequently signaling required for Fast Reroute (FRR) procedures and subsequently
improve the scalability of the RSVP-TE signaling when undergoing FRR improve the scalability of the RSVP-TE signaling when undergoing FRR
convergence after a link or node failure. Such extensions allow the convergence after a link or node failure. Such extensions allow the
RSVP message exchange between the Point of Local Repair (PLR) and the RSVP message exchange between the Point of Local Repair (PLR) and the
Merge Point (MP) to be independent of the number of protected Label Merge Point (MP) to be independent of the number of protected Label
skipping to change at page 1, line 44 skipping to change at page 1, line 48
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 7, 2019. This Internet-Draft will expire on November 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4
3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 4 3. Extensions for Summary FRR Signaling . . . . . . . . . . . . 4
3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 5 3.1. B-SFRR-Ready Extended ASSOCIATION Object . . . . . . . . 5
3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 5 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 6
3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 6 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 7
3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 9 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 10
3.2.1. B-SFRR-Active Extended ASSOCIATION ID . . . . . . . . 10 3.2.1. B-SFRR-Active Extended ASSOCIATION ID . . . . . . . . 11
3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 11 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 12
3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 11 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 12
3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 11 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 12
3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 12 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 13
3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 12 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 13
3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 13 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 14
3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 14 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 15
4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Fast Reroute (FRR) procedures defined in [RFC4090] describe the The Fast Reroute (FRR) procedures defined in [RFC4090] describe the
mechanisms for the Point of Local Repair (PLR) to reroute traffic and mechanisms for the Point of Local Repair (PLR) to reroute traffic and
signaling of a protected RSVP-TE LSP onto the bypass tunnel in the signaling of a protected RSVP-TE LSP onto the bypass tunnel in the
event of a TE link or node failure. Such signaling procedures are event of a TE link or node failure. Such signaling procedures are
performed individually for each affected protected LSP. This may performed individually for each affected protected LSP. This may
eventually lead to control plane scalability and latency issues on eventually lead to control plane scalability and latency issues on
the PLR and/or the MP due to limited memory and CPU processing the PLR and/or the MP due to limited memory and CPU processing
skipping to change at page 3, line 40 skipping to change at page 3, line 40
affected LSR(s). As a result, the RSVP-TE control plane at the PLR affected LSR(s). As a result, the RSVP-TE control plane at the PLR
and MP becomes overwhelmed by the amount of FRR RSVP-TE processing and MP becomes overwhelmed by the amount of FRR RSVP-TE processing
overhead following the link or node failure, and the competing other overhead following the link or node failure, and the competing other
control plane protocol(s) (e.g. the IGP) that undergo their control plane protocol(s) (e.g. the IGP) that undergo their
convergence at the same time. convergence at the same time.
The extensions defined in this document enable a MP node to become The extensions defined in this document enable a MP node to become
aware of the PLR node's bypass tunnel assignment group and allow FRR aware of the PLR node's bypass tunnel assignment group and allow FRR
procedures between PLR node and MP node to be signaled and processed procedures between PLR node and MP node to be signaled and processed
on groups of LSPs. on groups of LSPs.
As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to As defined in [RFC2961], Summary Refresh procedures use MESSAGE_ID to
refresh the RSVP Path and Resv states to help with the scale. The refresh the RSVP Path and Resv states to help with the scale. The
MESSAGE_ID information for the rerouted PATH and RESV states are MESSAGE_ID information for the rerouted PATH and RESV states are
exchanged between PLR and MP nodes between PLR and MP nodes a priori exchanged between PLR and MP nodes between PLR and MP nodes a priori
to the fault such that Summary Refresh procedures defined in to the fault such that Summary Refresh procedures defined in
[RFC2961] can continue to be used to refresh the rerouted state(s) [RFC2961] can continue to be used to refresh the rerouted state(s)
after FRR has occurred. after FRR has occurred.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions
2.1. Terminology
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2.2. Terminology 2.2. Acronyms and Abbreviations
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with terms and abbreviations
[RFC3209] and [RFC4090]. used in [RFC3209] and [RFC4090].
The following abbreviations are also used in this document:
LSR: Label Switching Router
LER: Label Edge Router
MPLS: Multiprotocol Label Switching
LSP: Label Switched Path
MP: Merge Point node as defined in [RFC4090]
PLR: Point of Local Repair node as defined in [RFC4090]
FRR: Fast Reroute as defined in [RFC4090]
B-SFRR-Ready: Bypass Summary FRR Ready Extended ASSOCIATION
object. Added by the PLR for each LSP protected by the bypass
tunnel.
B-SFRR-Active: Bypass Summary FRR Active Extended ASSOCIATION
object. Used to notify the MP node of one ore more groups of
protected LSP(s) that are being protected by the specified bypass
tunnel are being rerouted.
3. Extensions for Summary FRR Signaling 3. Extensions for Summary FRR Signaling
The RSVP ASSOCIATION object is defined in [RFC4872] as a means to The RSVP ASSOCIATION object is defined in [RFC4872] as a means to
associate LSPs with each other. For example, in the context of associate LSPs with each other. For example, in the context of
GMPLS-controlled LSP(s), the object is used to associate recovery GMPLS-controlled LSP(s), the object is used to associate recovery
LSPs with the LSP they are protecting. The Extended ASSOCIATION LSPs with the LSP they are protecting. The Extended ASSOCIATION
object is introduced in [RFC6780] to expand on the possible usage of object is introduced in [RFC6780] to expand on the possible usage of
the ASSOCIATION object and generalize the definition of the Extended the ASSOCIATION object and generalize the definition of the Extended
Association ID field. Association ID field.
skipping to change at page 14, line 31 skipping to change at page 15, line 31
non-supporting node(s). Such nodes will ignore the object and non-supporting node(s). Such nodes will ignore the object and
forward it without modification. forward it without modification.
5. Security Considerations 5. Security Considerations
This document updates an existing RSVP object. Thus, in the event of This document updates an existing RSVP object. Thus, in the event of
the interception of a signaling message, a slightly more information the interception of a signaling message, a slightly more information
could be deduced about the state of the network than was previously could be deduced about the state of the network than was previously
the case. Existing mechanisms for maintaining the integrity and the case. Existing mechanisms for maintaining the integrity and
authenticity of RSVP protocol messages [RFC2747] can be applied. authenticity of RSVP protocol messages [RFC2747] can be applied.
Other considerations mentioned in [RFC4090] and [RFC5920] also apply.
6. IANA Considerations 6. IANA Considerations
IANA maintains the "Generalized Multi-Protocol Label Switching IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry (see (GMPLS) Signaling Parameters" registry (see
http://www.iana.org/assignments/gmpls-sig-parameters [1]). The http://www.iana.org/assignments/gmpls-sig-parameters [1]). The
"Association Type" subregistry is included in this registry. "Association Type" subregistry is included in this registry.
This registry has been updated by new Association Type for Extended This registry has been updated by new Association Type for Extended
ASSOCIATION Object defined in this document as follows: ASSOCIATION Object defined in this document as follows:
skipping to change at page 16, line 16 skipping to change at page 17, line 16
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>. <https://www.rfc-editor.org/info/rfc4872>.
[RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP [RFC6780] Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
ASSOCIATION Object Extensions", RFC 6780, ASSOCIATION Object Extensions", RFC 6780,
DOI 10.17487/RFC6780, October 2012, DOI 10.17487/RFC6780, October 2012,
<https://www.rfc-editor.org/info/rfc6780>. <https://www.rfc-editor.org/info/rfc6780>.
9.2. URIs 9.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
9.3. URIs
[1] http://www.iana.org/assignments/gmpls-sig-parameters [1] http://www.iana.org/assignments/gmpls-sig-parameters
Authors' Addresses Authors' Addresses
Mike Taillon Mike Taillon
Cisco Systems, Inc. Cisco Systems, Inc.
Email: mtaillon@cisco.com Email: mtaillon@cisco.com
Tarek Saad (editor) Tarek Saad (editor)
Cisco Systems, Inc. Juniper Networks
Email: tsaad@cisco.com Email: tsaad@juniper.net
Rakesh Gandhi Rakesh Gandhi
Cisco Systems, Inc. Cisco Systems, Inc.
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Abhishek Deshmukh Abhishek Deshmukh
Juniper Networks Juniper Networks
Email: adeshmukh@juniper.net Email: adeshmukh@juniper.net
skipping to change at page 16, line 41 skipping to change at page 18, line 4
Rakesh Gandhi Rakesh Gandhi
Cisco Systems, Inc. Cisco Systems, Inc.
Email: rgandhi@cisco.com Email: rgandhi@cisco.com
Abhishek Deshmukh Abhishek Deshmukh
Juniper Networks Juniper Networks
Email: adeshmukh@juniper.net Email: adeshmukh@juniper.net
Markus Jork Markus Jork
Juniper Networks 128 Technology
Email: mjork@128technology.com
Email: mjork@juniper.net
Vishnu Pavan Beeram Vishnu Pavan Beeram
Juniper Networks Juniper Networks
Email: vbeeram@juniper.net Email: vbeeram@juniper.net
 End of changes. 20 change blocks. 
40 lines changed or deleted 79 lines changed or added

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