draft-ietf-mpls-summary-frr-rsvpte-05.txt   draft-ietf-mpls-summary-frr-rsvpte-06.txt 
MPLS Working Group M. Taillon MPLS Working Group M. Taillon
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track T. Saad, Ed. Intended status: Standards Track T. Saad, Ed.
Expires: January 5, 2020 Juniper Networks Expires: May 21, 2020 Juniper Networks
R. Gandhi R. Gandhi
Cisco Systems, Inc. Cisco Systems, Inc.
A. Deshmukh A. Deshmukh
Juniper Networks Juniper Networks
M. Jork M. Jork
128 Technology 128 Technology
V. Beeram V. Beeram
Juniper Networks Juniper Networks
July 04, 2019 November 18, 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-05 draft-ietf-mpls-summary-frr-rsvpte-06
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 48 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 January 5, 2020. This Internet-Draft will expire on May 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 10 3.2. B-SFRR-Active Extended ASSOCIATION Object . . . . . . . . 10
3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID . . . . . 11 3.2.1. IPv4 B-SFRR-Active Extended ASSOCIATION ID . . . . . 11
3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID . . . . . 12 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID . . . . . 12
3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 13 3.3. Signaling Procedures Prior to Failure . . . . . . . . . . 13
3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 14 3.3.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 14
3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 14 3.3.2. MP Signaling Procedure . . . . . . . . . . . . . . . 14
3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 15 3.4. Signaling Procedures Post Failure . . . . . . . . . . . . 15
3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 15 3.4.1. PLR Signaling Procedure . . . . . . . . . . . . . . . 15
3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 16 3.4.2. MP Signaling Procedure . . . . . . . . . . . . . . . 16
3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 16 3.5. Refreshing Summary FRR Active LSPs . . . . . . . . . . . 16
4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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. Terminology 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in BCP 14, RFC 2119 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.2. Acronyms and Abbreviations 2.2. Acronyms and Abbreviations
The reader is assumed to be familiar with terms and abbreviations The reader is assumed to be familiar with terms and abbreviations
used in [RFC3209] and [RFC4090]. used in [RFC3209] and [RFC4090].
The following abbreviations are also used in this document: The following abbreviations are also used in this document:
LSR: Label Switching Router LSR: Label Switching Router
skipping to change at page 5, line 5 skipping to change at page 5, line 7
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.
This document proposes the use of the Extended ASSOCIATION object to This document defines the use of the Extended ASSOCIATION object to
carry the Summary FRR information and associate the protected LSP(s) carry the Summary FRR information and associate the protected LSP(s)
with the bypass tunnel that protects them. Two new Association Types with the bypass tunnel that protects them. Two new Association Types
for the Extended ASSOCIATION object, and new Extended Association IDs for the Extended ASSOCIATION object, and new Extended Association IDs
are proposed in this draft to describe the Bypass Summary FRR Ready are proposed in this draft to describe the Bypass Summary FRR Ready
(B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active) (B-SFRR-Ready) and the Bypass Summary FRR Active (B-SFRR-Active)
associations. associations.
The PLR creates and manages the Summary FRR LSP groups (identified by The PLR creates and manages the Summary FRR LSP groups (identified by
Bypass_Group_Identifiers) and shares the group identifier(s) with the Bypass_Group_Identifiers) and shares the group identifier(s) with the
MP via signaling. MP via signaling.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
A MESSAGE_ID object as defined by [RFC2961]. A MESSAGE_ID object as defined by [RFC2961].
The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each The PLR assigns a bypass tunnel and Bypass_Group_Identifier for each
protected LSP. The same Bypass_Group_Identifier is used for the set protected LSP. The same Bypass_Group_Identifier is used for the set
of protected LSPs that share the same bypass tunnel and traverse the of protected LSPs that share the same bypass tunnel and traverse the
same egress link and are not already rerouted. The PLR also same egress link and are not already rerouted. The PLR also
generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and
Message_Identifier MUST be set according to [RFC2961]). Message_Identifier MUST be set according to [RFC2961]).
The PLR MUST generate a new Message_Identifier each time the contents The PLR MUST generate a new Message_Identifier each time the contents
of the B-SFRR-Ready Extended ASSOCIATION ID changes; for example, of the B-SFRR-Ready Extended ASSOCIATION ID changes (e.g. when PLR
when PLR node changes the bypass tunnel assignment. node changes the bypass tunnel assignment).
The PLR node notifies the MP node of the bypass tunnel assignment via The PLR node notifies the MP node of the bypass tunnel assignment via
adding a B-SFRR-Ready Extended ASSOCIATION object and Association ID adding a B-SFRR-Ready Extended ASSOCIATION object and Association ID
in the RSVP Path message for the protected LSP using procedures in the RSVP Path message for the protected LSP using procedures
described in Section 3.4. described in Section 3.4.
The MP node acknowledges the PLR node assignment by signaling the B- The MP node acknowledges the PLR node assignment by signaling the B-
SFRR-Ready Extended ASSOCIATION object and Association ID within the SFRR-Ready Extended ASSOCIATION object and Association ID within the
RSVP Resv message of the protected LSP. With exception of the RSVP Resv message of the protected LSP. With exception of the
MESSAGE_ID objects, all other fields of the received in the B-SFRR- MESSAGE_ID objects, all other fields of the received in the B-SFRR-
skipping to change at page 17, line 5 skipping to change at page 17, line 5
An individual RSVP Resv message for each successfully merged Summary An individual RSVP Resv message for each successfully merged Summary
FRR LSP is not signaled. The MP node SHOULD immediately use Summary FRR LSP is not signaled. The MP node SHOULD immediately use Summary
Refresh procedures to refresh the protected LSP RESV state. Refresh procedures to refresh the protected LSP RESV state.
3.5. Refreshing Summary FRR Active LSPs 3.5. Refreshing Summary FRR Active LSPs
Refreshing of Summary FRR active LSPs is performed using Summary Refreshing of Summary FRR active LSPs is performed using Summary
Refresh as defined by [RFC2961]. Refresh as defined by [RFC2961].
4. Compatibility 4. Backwards Compatibility
The (Extended) ASSOCIATION object is defined in [RFC4872] with a The (Extended) ASSOCIATION object is defined in [RFC4872] with a
class number in the form 11bbbbbb, which ensures compatibility with class number in the form 11bbbbbb, which ensures compatibility with
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, 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. 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. The "Association Type" sub-
http://www.iana.org/assignments/gmpls-sig-parameters [1]). The registry is included in this registry.
"Association Type" sub-registry 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:
Value Name Reference Value Name Reference
----- ---- --------- ----- ---- ---------
TBD-1 B-SFRR-Ready Association Section 3.1 TBD-1 B-SFRR-Ready Association Section 3.1
TBD-2 B-SFRR-Active Association Section 3.2 TBD-2 B-SFRR-Active Association Section 3.2
IANA also maintains and assigns the values for the RSVP-TE protocol
parameters "Resource Reservation Protocol (RSVP) Parameters" (see
http://www.iana.org/assignments/rsvp-parameters).
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Alexander Okonnikov, Loa Andersson, The authors would like to thank Alexander Okonnikov, Loa Andersson,
Lou Berger, Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and Lou Berger, Eric Osborne, Gregory Mirsky, Mach Chen for reviewing and
providing valuable comments to this document. providing valuable comments to this document.
8. Contributors 8. Contributors
Nicholas Tan Nicholas Tan
Arista Networks Arista Networks
skipping to change at page 19, line 5 skipping to change at page 18, line 46
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[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>.
9.3. URIs
[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)
Juniper Networks Juniper Networks
 End of changes. 16 change blocks. 
26 lines changed or deleted 21 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/