< draft-ietf-mpls-summary-frr-rsvpte-04.txt   draft-ietf-mpls-summary-frr-rsvpte-05.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: November 23, 2019 Juniper Networks Expires: January 5, 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
May 22, 2019 July 04, 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-04 draft-ietf-mpls-summary-frr-rsvpte-05
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 November 23, 2019. This Internet-Draft will expire on January 5, 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . 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 . . . . . . . . 6
3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 6 3.1.1. IPv4 B-SFRR-Ready IPv4 Extended ASSOCIATION ID . . . 6
3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 7 3.1.2. IPv6 B-SFRR-Ready IPv6 Extended ASSOCIATION ID . . . 7
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 . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 4. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 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
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
resources. This condition is exacerbated when the failure affects resources. This condition is exacerbated when the failure affects
large number of protected LSPs that traverse the same PLR and Merge large number of protected LSPs that traverse the same PLR and Merge
Point (MP) nodes. Point (MP) nodes.
For example, in a large scale RSVP-TE LSPs deployment, a single LSR For example, in a large scale RSVP-TE LSPs deployment, a single LSR
acting as a PLR node may host tens of thousands of protected RSVP-TE acting as a PLR node may host tens of thousands of protected RSVP-TE
LSPs egressing the same link, and also act as a MP node for similar LSPs egressing the same link, and also act as a MP node for similar
number of LSPs ingressing the same link. In the event of the failure number of LSPs that ingress on the same link. In the event of the
of the link or neighbor node, the RSVP-TE control plane of the node failure of the link or neighbor node, the RSVP-TE control plane of
when acting as PLR becomes busy rerouting protected LSPs signaling the node when acting as PLR becomes busy rerouting protected LSPs
over the bypass tunnel(s) in one direction, and when acting as an MP signaling over the bypass tunnel(s) in one direction, and when acting
node becomes busy merging RSVP states from signaling received over as an MP node becomes busy merging RSVP states from signaling
bypass tunnels for LSP(s) in the reverse direction. Subsequently, received over bypass tunnels for LSP(s) in the reverse direction.
the head-end LER(s) that are notified of the local repair at Subsequently, the head-end LER(s) that are notified of the local
downstream LSR will attempt to (re)converge affected RSVP- TE LSPs repair at downstream LSR will attempt to (re)converge affected RSVP-
onto newly computed paths - possibly traversing the same previously TE LSPs onto newly computed paths - possibly traversing the same
affected LSR(s). As a result, the RSVP-TE control plane at the PLR previously affected LSR(s). As a result, the RSVP-TE control plane
and MP becomes overwhelmed by the amount of FRR RSVP-TE processing at the PLR and MP becomes overwhelmed by the amount of FRR RSVP-TE
overhead following the link or node failure, and the competing other processing overhead following the link or node failure, and the
control plane protocol(s) (e.g. the IGP) that undergo their competing other control plane protocol(s) (e.g. the IGP) that undergo
convergence at the same time. their 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
skipping to change at page 5, line 13 skipping to change at page 5, line 13
Association ID field. Association ID field.
This document proposes the use of the Extended ASSOCIATION object to This document proposes 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 The PLR creates and manages the Summary FRR LSP groups (identified by
(Bypass_Group_Identifiers) and shares them with the MP via signaling. Bypass_Group_Identifiers) and shares the group identifier(s) with the
Protected LSPs sharing the same egress link and bypass assignment are MP via signaling.
grouped together and are assigned the same group. The MP maintains
the PLR group assignments learned via signaling, and acknowledges the The PLR SHOULD assign the same Bypass_Group_Identifier to all
group assignments via signaling. Once the PLR receives the protected LSPs that share the egress link, and bypass tunnel as long
acknowledgment, FRR signaling can proceed as group based. as the protected LSP(s) have the common group attributes, including
the modified tunnel sender address used for backup path
identification as described in [RFC4090].
The MP maintains the PLR group assignments learned via signaling, and
acknowledges the group assignments via signaling. Once the PLR
receives the acknowledgment, FRR signaling can proceed as group
based.
The PLR node that supports Summary FRR procedures adds the Extended The PLR node that supports Summary FRR procedures adds the Extended
ASSOCIATION object with Type B-SFRR-Ready and respective Extended ASSOCIATION object with Type B-SFRR-Ready and respective Extended
Association ID in the RSVP Path message of the protected LSP to Association ID in the RSVP Path message of the protected LSP to
inform the MP of the PLR's assigned bypass tunnel, Summary FRR inform the MP of the PLR's assigned bypass tunnel, Summary FRR
Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to
refresh the protected LSP PATH state after FRR occurs. refresh the protected LSP PATH state after FRR occurs.
The MP node that supports Summary FRR procedures adds the B-SFRR- The MP node that supports Summary FRR procedures adds the B-SFRR-
Ready Extended ASSOCIATION object and respective Extended Association Ready Extended ASSOCIATION object and respective Extended Association
skipping to change at page 12, line 14 skipping to change at page 12, line 14
TIME_VALUES object: Class 5, as defined by [RFC2205] TIME_VALUES object: Class 5, as defined by [RFC2205]
Replacement TIME_VALUES object to be applied to all LSPs Replacement TIME_VALUES object to be applied to all LSPs
associated with each of the following Bypass_Group_Identifiers associated with each of the following Bypass_Group_Identifiers
after receiving the B-SFRR-Active Extended ASSOCIATION Object. after receiving the B-SFRR-Active Extended ASSOCIATION Object.
IPv4 tunnel sender address: IPv4 tunnel sender address:
The IPv4 address that the PLR sets to identify backup path(s) as The IPv4 address that the PLR sets to identify backup path(s) as
described in Section 6.1.1 of [RFC4090]. described in Section 6.1.1 of [RFC4090]. This address is
applicable to all groups identified by Bypass_Group_Identifier(s)
carried in the B-SFRR-Active Extended ASSOCIATION ID.
3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID 3.2.2. IPv6 B-SFRR-Active Extended ASSOCIATION ID
The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association The IPv6 Extended ASSOCIATION ID for the B-SFRR-Active association
type is carried inside the IPv6 Extended ASSOCIATION object and has type is carried inside the IPv6 Extended ASSOCIATION object and has
the following format: the following format:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 31 skipping to change at page 13, line 34
TIME_VALUES object: Class 5, as defined by [RFC2205] TIME_VALUES object: Class 5, as defined by [RFC2205]
Replacement TIME_VALUES object to be applied to all LSPs Replacement TIME_VALUES object to be applied to all LSPs
associated with each of the following Bypass_Group_Identifiers associated with each of the following Bypass_Group_Identifiers
after receiving the B-SFRR-Active Extended ASSOCIATION Object. after receiving the B-SFRR-Active Extended ASSOCIATION Object.
IPv6 tunnel sender address: IPv6 tunnel sender address:
The IPv6 address that the PLR sets to identify backup path(s) as The IPv6 address that the PLR sets to identify backup path(s) as
described in Section 6.1.1 of [RFC4090]. described in Section 6.1.1 of [RFC4090]. This address is
applicable to all groups identified by Bypass_Group_Identifier(s)
carried in the B-SFRR-Active Extended ASSOCIATION ID.
3.3. Signaling Procedures Prior to Failure 3.3. Signaling Procedures Prior to Failure
Before Summary FRR procedures can be used, a handshake MUST be Before Summary FRR procedures can be used, a handshake MUST be
completed between the PLR and MP. This handshake is performed using completed between the PLR and MP. This handshake is performed using
Extended ASSOCIATION object that carries the B-SFRR-Ready Extended Extended ASSOCIATION object that carries the B-SFRR-Ready Extended
Association ID in both the RSVP Path and Resv messages of the Association ID in both the RSVP Path and Resv messages of the
protected LSP. protected LSP.
When using procedures defined in this document, the PLR MUST ensure When using procedures defined in this document, the PLR MUST ensure
skipping to change at page 14, line 8 skipping to change at page 14, line 14
3.3.1. PLR Signaling Procedure 3.3.1. PLR Signaling Procedure
The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in The B-SFRR-Ready Extended ASSOCIATION object is added by each PLR in
the RSVP Path message of the protected LSP to record the bypass the RSVP Path message of the protected LSP to record the bypass
tunnel assignment. This object is updated every time the PLR updates tunnel assignment. This object is updated every time the PLR updates
the bypass tunnel assignment and that triggers an RSVP Path change the bypass tunnel assignment and that triggers an RSVP Path change
message. message.
Upon receiving an RSVP Resv message with B-SFRR-Ready Extended Upon receiving an RSVP Resv message with B-SFRR-Ready Extended
ASSOCIATION object, the PLR node checks if the expected subobjects ASSOCIATION object, the PLR node checks if the expected sub-objects
from the B-SFRR-Ready ASSOCIATION ID are present. If present, the from the B-SFRR-Ready ASSOCIATION ID are present. If present, the
PLR determines if the MP has acknowledged the current PLR assignment. PLR determines if the MP has acknowledged the current PLR assignment.
To be a valid acknowledgement, the received B-SFRR-Ready ASSOCIATION To be a valid acknowledgement, the received B-SFRR-Ready ASSOCIATION
ID contents within the RSVP Resv message of the protected LSP MUST ID contents within the RSVP Resv message of the protected LSP MUST
match the latest B-SFRR-Ready Extended ASSOCIATION object and match the latest B-SFRR-Ready Extended ASSOCIATION object and
Association ID contents that the PLR node had sent within the RSVP Association ID contents that the PLR node had sent within the RSVP
Path message (with exception of the MESSAGE_ID). Path message (with exception of the MESSAGE_ID).
Note, when forwarding an RSVP Resv message upstream, the PLR node Note, when forwarding an RSVP Resv message upstream, the PLR node
skipping to change at page 15, line 44 skipping to change at page 15, line 49
the RSVP Path message of the RSVP session of the bypass tunnel. the RSVP Path message of the RSVP session of the bypass tunnel.
The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION
ID is set to the common RSVP_HOP that was used by the PLR in ID is set to the common RSVP_HOP that was used by the PLR in
Section 3.4 of this document. Section 3.4 of this document.
The previously received MESSAGE_ID from the MP is activated. As a The previously received MESSAGE_ID from the MP is activated. As a
result, the MP may refresh the protected rerouted RESV state using result, the MP may refresh the protected rerouted RESV state using
Summary Refresh procedures. Summary Refresh procedures.
For each affected Summary FRR group, its Bypass_Group_Identifier is The PLR adds the Bypass_Group_Identifier(s) of group(s) that have
added to B-SFRR-Active Extended ASSOCIATION ID. common group attributes, including the tunnel sender address, to the
same B-SFRR-Active Extended ASSOCIATION ID. Note that multiple
ASSOCIATION objects, each carrying a B-SFRR-Active Extended
ASSOCIATION ID, can be carried within a single RSVP Path message of
the bypass LSP and sent towards the MP as described in [RFC6780].
3.4.2. MP Signaling Procedure 3.4.2. MP Signaling Procedure
Upon receiving an RSVP Path message with a B-SFRR-Active Extended Upon receiving an RSVP Path message with a B-SFRR-Active Extended
Association object, the MP performs normal merge point processing for Association object, the MP performs normal merge point processing for
each protected LSP associated with each Bypass_Group_Identifier, as each protected LSP associated with each Bypass_Group_Identifier, as
if it received individual RSVP Path messages for the LSP. if it received individual RSVP Path messages for the LSP.
For each Summary FRR LSP being merged, the MP first modifies the Path For each Summary FRR LSP being merged, the MP first modifies the Path
state as follows: state as follows:
skipping to change at page 17, line 19 skipping to change at page 17, line 26
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 (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" 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 IANA also maintains and assigns the values for the RSVP-TE protocol
 End of changes. 16 change blocks. 
38 lines changed or deleted 53 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/