--- 1/draft-ietf-teas-p2mp-loose-path-reopt-07.txt 2016-12-08 18:13:12.085063665 -0800 +++ 2/draft-ietf-teas-p2mp-loose-path-reopt-08.txt 2016-12-08 18:13:12.121064539 -0800 @@ -1,52 +1,41 @@ TEAS Working Group T. Saad, Ed. Internet-Draft R. Gandhi, Ed. Intended status: Standards Track Z. Ali -Expires: April 27, 2017 Cisco Systems, Inc. +Expires: June 11, 2017 Cisco Systems, Inc. R. Venator Defense Information Systems Agency Y. Kamite NTT Communications Corporation - October 24, 2016 + December 8, 2016 RSVP Extensions For Re-optimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) - draft-ietf-teas-p2mp-loose-path-reopt-07 + draft-ietf-teas-p2mp-loose-path-reopt-08 Abstract Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP) may be triggered based on the need to re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. - Mechanisms that facilitate path re-optimization of loosely routed - Point-to-Point (P2P) TE LSPs include a method for the ingress node to - trigger a new path re-evaluation request and a method for the mid- - point node to notify availability of a preferred path. This document - discusses the application of these mechanisms to the re-optimization - of loosely routed P2MP-TE LSPs, identifies issues in doing so and - proposes procedures to address them. - - This document defines Resource Reservation Protocol (RSVP) signaling - extensions to allow the ingress node of a loosely routed P2MP-TE LSP - to request the re-evaluation of the LSP tree downstream of the node, - and a mid-point node to notify to the ingress node that a preferable - tree for the P2MP-TE LSP exists. For re-optimizing a group of S2L + This document discusses the application of the existing mechanisms + for path re-optimization of loosely routed Point-to-Point (P2P) TE + LSPs to the P2MP-TE LSPs, identifies issues in doing so and defines + procedures to address them. When re-optimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-Based Re-optimization method, - an S2L sub-LSP descriptor list can be used to signal one or more S2L - sub-LSPs in an RSVP message. This RSVP message may need to be - semantically fragmented when large number of S2L sub-LSPs are added - to the descriptor list. This document introduces the notion of a - fragment identifier to help recipient nodes unambiguously reconstruct - the fragmented S2L sub-LSP descriptor list. + the S2L sub-LSP descriptor list may need to be semantically + fragmented. This document defines the notion of a fragment + identifier to help recipient nodes unambiguously reconstruct the + fragmented S2L sub-LSP descriptor list. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. @@ -69,41 +58,41 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 - 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 6 3.2. Existing Mechanism For Tree-Based P2MP-TE LSP - Re-optimization . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization . . . . . . . . . . . . . . . . . . . . . 7 - 4. Signaling Procedure For Loosely Routed P2MP-TE LSP - Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8 + 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP + Re-optimization . . . . . . . . . . . . . . . . . . . . . 8 + 4. Signaling Extensions For Loosely Routed P2MP-TE LSP + Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 9 4.2. Sub-Group-Based Re-optimization Using Fragment - Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 + Identifier . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Message and Object Definitions . . . . . . . . . . . . . . . . 11 5.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11 5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 11 - 5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11 - 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 12 + 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 13 - 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 13 + 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 14 7.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction @@ -120,34 +109,45 @@ node along the path to the egress node at the time of its signaling by the ingress node. Such an S2L sub-LSP is signaled with no Explicit Route Object (ERO) [RFC3209], or with an ERO that contains at least one loose next-hop, or with an ERO that contains an abstract node which identifies more than one node. This is often the case with inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not used [RFC5440]. As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE LSP tree by re-signaling all its S2L sub-LSP(s) using the - Make-Before-Break (MBB) method or may re-optimize individual or a set - of S2L sub-LSP(s) i.e. individual or a set of destination(s) using - the Sub-Group-Based re-optimization method. + Make-Before-Break (MBB) method or may re-optimize individual S2L sub- + LSP or a set of S2L sub-LSPs i.e. individual destination or a set of + destinations, both using the Sub-Group-Based Re-optimization method. - [RFC4736] defines RSVP signaling mechanisms for re-optimizing loosely - routed Point-to-Point (P2P) TE LSP(s). This document discusses the + [RFC4736] defines RSVP signaling procedure for re-optimizing the + path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). Those + mechanisms include a method for the ingress node to trigger a new + path re-evaluation request and a method for the mid-point node to + notify availability of a preferred path. This document discusses the application of those mechanisms to the re-optimization of loosely - routed P2MP-TE LSPs, identifies issues in doing so and proposes + routed P2MP-TE LSPs, identifies issues in doing so and defines procedures to address them. + For re-optimizing a group of S2L sub-LSPs in a tree using the Sub- + Group-Based Re-optimization method, an S2L sub-LSP descriptor list + can be used to signal one or more S2L sub-LSPs in an RSVP message. + This RSVP message may need to be semantically fragmented when large + number of S2L sub-LSPs are added to the descriptor list. This + document defines the notion of a fragment identifier to help + recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP + descriptor list. + 2. Conventions Used in This Document 2.1. Key Word Definitions - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Abbreviations ABR: Area Border Router. AS: Autonomous System. @@ -272,21 +272,22 @@ In order to address above mentioned issues and to align re-optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a need for a mechanism to trigger re-optimization of the LSP tree by re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this requirement, this document defines RSVP-TE signaling extensions for the ingress node to trigger the re-evaluation of the P2MP LSP tree on every hop that has a next-hop defined as a loose or abstract hop for one or more S2L sub-LSP path, and a mid-point LSR to signal to the ingress node that a preferable LSP tree exists (compared to the current path) or that the whole P2MP-TE LSP must be re-optimized - (because of maintenance required on the TE LSP path). + (because of maintenance required on the TE LSP path) (see Section + 4.1). 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization Applying the procedures discussed in RFC4736 in conjunction with the Sub-Group-Based Re-Optimization procedures ([RFC4875], Section 14.2), an ingress node MAY trigger path re-evaluation requests for a set of S2L sub-LSPs in a single Path message using S2L sub-LSP descriptor list. Similarly, a mid-point LSR may send a PathErr with the Notify error code 25 and sub-code 6 containing a list of S2L sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor list to @@ -316,71 +317,70 @@ sub-sets of S2L sub-LSPs in each (due to either the combined Path message getting fragmented or the combined PathErr message getting fragmented) and would require additional logic to determine how to re-optimize the LSP tree (for example, waiting for some time to aggregate all possible PathErr messages before taking an action). When fragmented, RSVP messages may arrive out of order, and the receiver has no way of knowing the beginning and end of the S2L sub-LSP list. In order to address the above mentioned issues caused by RSVP message - semantic fragmentation, this document proposes the use of fragment - identifier for the S2L sub-LSP descriptor list when combining large - number of S2L sub-LSPs in an RSVP message. + semantic fragmentation, this document defines new fragment identifier + object for the S2L sub-LSP descriptor list when combining large + number of S2L sub-LSPs in an RSVP message (see Section 4.2). -4. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-optimization +4. Signaling Extensions For Loosely Routed P2MP-TE LSP Re-optimization 4.1. Tree-Based Re-optimization To evaluate a P2MP-TE LSP tree on mid-point LSRs that expand loose next-hop(s), an ingress node MAY send a Path message with "P2MP-TE Tree Re-evaluation Request (value TBA1)" defined in this document. The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP tree transiting a mid-point LSR to trigger the re-evaluation request. The ingress node MAY send a re-evaluation request to each border LSR on the path of the LSP tree. A mid-point LSR that expands loose next-hop(s) for one or more S2L - sub-LSP path(s) SHOULD do the following upon receiving a Path message - with the "P2MP-TE Tree Re-evaluation Request" flag set: + sub-LSP path(s) does the following upon receiving a Path message with + the "P2MP-TE Tree Re-evaluation Request" flag set: - o The mid-point LSR SHOULD check for a preferable P2MP-TE LSP tree - by re-evaluating all S2L sub-LSP(s) that are expanded paths of the + o The mid-point LSR MUST check for a preferable P2MP-TE LSP tree by + re-evaluating all S2L sub-LSP(s) that are expanded paths of the loose next-hops of the P2MP-TE LSP. - o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MAY + o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MUST send an RSVP PathErr with the Notify error code 25 defined in [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists (value TBA2)" defined in this document to the ingress node. The mid- point LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re- evaluation Request" flag in the subsequent RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP. - o If no preferable tree for P2MP-TE LSP can be found, the - recommended mode is that the mid-point LSR that expands loose - next-hop(s) for one or more S2L sub-LSP path(s) SHOULD propagate - the request downstream by setting the "P2MP-TE Tree Re-evaluation - Request" flag in the LSP_ATTRIBUTES Object of the RSVP Path - message. + o If no preferable tree for P2MP-TE LSP can be found, the mid-point + LSR that expands loose next-hop(s) for one or more S2L sub-LSP + path(s) MUST propagate the request downstream by setting the + "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES + Object of the RSVP Path message. A mid-point LSR MAY send an unsolicited PathErr with the Notify error code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress node to notify of a preferred P2MP-TE LSP tree when it determines it exists. In this case, the mid-point LSR that expands loose next- hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the ingress node. The sending of an RSVP PathErr with the Notify error code and "Preferable P2MP-TE Tree Exists" sub-code to the ingress node notifies the ingress node of the existence of a preferable P2MP-TE - LSP tree and upon receiving this PathErr, the ingress node MAY + LSP tree and upon receiving this PathErr, the ingress node MUST trigger re-optimization of the LSP using the MBB method with a different LSP-ID. 4.2. Sub-Group-Based Re-optimization Using Fragment Identifier It might be preferable, as per [RFC4875], to re-optimize the entire P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, "Make-before-Break") or to re-optimize individual or group of S2L sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same @@ -602,31 +602,27 @@ 8. Security Considerations This document defines RSVP-TE signaling extensions to allow an ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP tree downstream of a node, and for a mid-point LSR to notify the ingress node of the existence of a preferable tree by sending a PathErr. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple domains, it may be desirable for a mid-point LSR to modify the RSVP PathErr message defined in this document to preserve - confidentiality across domains. Furthermore, an ingress node may - decide to ignore this PathErr message coming from a mid-point LSR - residing in another domain. Similarly, a mid-point LSR may decide to - ignore the P2MP-TE tree re-evaluation request originating from - another ingress domain. + confidentiality across domains. This document also defines fragment identifier for the S2L sub-LSP descriptor when combining large number of S2L sub-LSPs in an RSVP message and the message needs to be semantically fragmented. The introduction of the fragment identifier, by itself, introduces no - additional information to signaling. For a general discussions on + additional information to signaling. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -666,26 +662,26 @@ [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects", RFC 6510, February 2012. Acknowledgments The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis - Villamizar, Dimitri Papadimitriou, Nobo Akiya and Vishnu Pavan Beeram - for reviewing this document and providing many useful comments and - suggestions. The authors would also like to thank Ling Zeng with - Cisco Systems for implementing mechanisms defined in this document. - A special thanks to Adrian Farrel for his thorough review of this - document. + Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram + and Joel M. Halpern for reviewing this document and providing many + useful comments and suggestions. The authors would also like to + thank Ling Zeng with Cisco Systems for implementing mechanisms + defined in this document. A special thanks to Adrian Farrel for his + thorough review of this document. Author's Addresses Tarek Saad (editor) Cisco Systems EMail: tsaad@cisco.com Rakesh Gandhi (editor) Cisco Systems