Network Working Group M. Dai, Ed. Internet-Draft Y. Rekhter Intended status: Best Current Practice E. Aries Expires: September 10, 2015 Facebook Muhammad Nauman Chaudhry Verizon Communications March 9, 2015 MPLS RSVP-TE MBB Label Reuse draft-dai-mpls-rsvp-te-mbb-label-reuse-00 Abstract The concept of "make-before-break (MBB)" while rerouting MPLS RSVP-TE tunnels is discussed in [RFC3209]. In the procedure that is outlined, the behavior of downstream label assignment for the new LSP (new tunnel instance) is not well defined. As a general practice, a different label is assigned by each downstream router and advertised to the upstream router in the RESV message for the new LSP; this results in a separate end-to-end data-plane path for the new LSP (with the exception of PHP LSPs or UHP LSP with explicit label on the last hop). This practice allows independent end to end LSP path data-plane verification for each tunnel instance. The consequence of this practice is that the label entry gets added/deleted in the LFIB at every non-ingress router along the LSP path during MBB. Also, the ingress router would need to update all the applications using this LSP when switching to the new tunnel instance, as the new tunnel instance uses different outgoing label. This in turn may also cause other elements of the network which are dependent on the LSP to do the update. Such network churn can be avoided/minimized if the same label can be re-used (kept intact) wherever it is affecting neither the routing functionalities nor the data path verification of each instance. In addition, whenever label is reused, the setup time for the new tunnel instance would be faster because there is no need for the transit routers along the path of the new LSP to wait for the new LFIB entry to be added. This document proposes a set of procedures to facilitate label reuse when there is a total or partial path overlap between the two tunnel instances during MBB. Dai, et al. Expires September 10, 2015 [Page 1] Internet-Draft MPLS RSVP-TE MBB Label Reuse March 2015 Requirements Language 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 RFC 2119 [RFC2119]. 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/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 10, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Common LSP MBB triggers . . . . . . . . . . . . . . . . . 3 2. Recommended conditions for label reuse . . . . . . . . . . . 3 3. Control of label-reuse behavior . . . . . . . . . . . . . . . 4 3.1. Enable/Disable label-reuse capability . . . . . . . . . . 4 3.2. Prefer overlapping path to facilitate label-reuse . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 Dai, et al. Expires September 10, 2015 [Page 2] Internet-Draft MPLS RSVP-TE MBB Label Reuse March 2015 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction MPLS RSVP-TE make-before-break (MBB) procedure is defined in [RFC3209]. The behavior of downstream label assignment for the new LSP (new tunnel instance) is not well-defined in this procedure. In most MBB implementations, a different label is assigned by each downstream router and advertised to upstream router in the RESV message for the new Label Switched Path (LSP). This means a separate end-to-end data-plane path for the new tunnel instance (with the exception of PHP LSPs or UHP LSPs with explicit NULL label at the last hop). Although this allows for independent end-to-end path verification for each tunnel instance, it requires an LFIB entry add/ delete at every non-ingress router along the path of the LSP during MBB even if the paths for the new tunnel instance and the old tunnel instance might be partially or totally overlapping. Label reuse under partial or total overlap condition reduces unnecessary LFIB update, reduces the possibility of errors and improves network convergence latency. In cases where there is a total overlap of paths between the two tunnel instances and the label is reused at each hop along the overlapping path, the necessity of data plane verification for the new tunnel instance is no longer needed. 1.1. Common LSP MBB triggers The MBB procedure can be triggered because of a change to any property of the RSVP-TE tunnel. The most common case is a change to the bandwidth requirement, especially with the widely implemented auto-bandwidth feature, which dynamically adjusts the LSP bandwidth based on traffic-monitoring feedback. With CSPF commonly used to compute path to meet the new bandwidth requirements, it is possible that the existing path is still one of the best paths which can satisfy the new requirements. This provides the opportunity to reuse labels to maximize the benefits described. If given the choice and the goal of selecting the best path is not the highest priority, CSPF can also prefer the existing path to other possible paths to take full advantage of the label reuse as long as the requirements are still met by the existing path. 2. Recommended conditions for label reuse The notion of "Label reuse" can be applied for both point-to-point (P2P) LSP and point-to-multipoint (P2MP) LSP, but due to the complexity of P2MP and many possible variations of the solutions, this document will only focus on the recommendations for P2P LSPs. Dai, et al. Expires September 10, 2015 [Page 3] Internet-Draft MPLS RSVP-TE MBB Label Reuse March 2015 Labels can be reused when the primary paths of the two tunnel instances have complete overlap starting from a certain point in the paths and going all the way to the egress router of the LSP. The best case scenario is complete overlap of the two paths end to end; in which case there is no need for any label changes and LFIB updates, both in the transit as well as in the ingress routers. In this scenario there is also no need to perform data plane verification for the new tunnel instance. For the case where the two paths overlaps only from a certain transit router (rather than from the ingress), label reuse starts at that router and continues all the way to the egress router. In this case the existing data plane verification method can still be used to verify new tunnel instance as before. Data traversing on either instance will take a different label path from the ingress to this transit router and from then on the traffic will merge into the shared label switched path towards the egress router. The conditions under which label reuse can be applied are as following: o Egress router of LSP: Reuse-label functionality can always be applied. o Transit routers of the LSP: For any given transit router of P2P LSP, label can be reused if the following conditions are met: (a) Downstream label received is the same (b) NHOP is the same o Ingress router of the LSP: When the same conditions as listed under transit router are met, instead of no label change, there is no need for ingress route update for LSP to applications depending on it. The label reuse procedure starts from the egress of the LSP as RESV traverses upstream towards the ingress of the LSP; it terminates at the first transit router where paths of the two tunnel instances diverge towards the ingress of the LSP or at the transit router which doesn't support label reuse. 3. Control of label-reuse behavior 3.1. Enable/Disable label-reuse capability This document recommends enabling "label-reuse" capability by default. Allow it to be disabled if needed by changing configuration. Dai, et al. Expires September 10, 2015 [Page 4] Internet-Draft MPLS RSVP-TE MBB Label Reuse March 2015 3.2. Prefer overlapping path to facilitate label-reuse In order to take full advantage of the label-reuse capability, path computation for the new tunnel instance may seek to maximize path overlap. This can be achieved through two approaches. o The first approach is to select from the best paths available the path which has the most path overlap with the existing path starting from the egress router. o The second approach is to prefer the existing path if it still satisfies the new requirement, even though it might not be the best path. The choice between the approaches is a matter of local computation policy and can be different for different types of MBB trigger. 4. IANA Considerations This document makes no request for IANA action. 5. Security Considerations This document does not introduce new security issues. 6. Acknowledgements The authors wish to thank Vishnu Pavan Beeram for his input, feedback, and helpful suggestions. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. Authors' Addresses Minjie Dai (editor) Juniper Networks Email: mdai@juniper.net Dai, et al. Expires September 10, 2015 [Page 5] Internet-Draft MPLS RSVP-TE MBB Label Reuse March 2015 Yakov Richter Juniper Networks Email: yakov@juniper.net Ebben Aries Facebook 1 Hacker Way Menlo Park, CA 94025 US Email: exa@fb.com Muhammad Nauman Chaudhry Verizon Communications Email: muhammd.n.chaudhry@verizon.com Raveendra Torvi Juniper Networks Email: rtorvi@juniper.net Markus Work Juniper Networks Email: mjork@juniper.net Yimin Shen Juniper Networks Email: yshen@juniper.net Natrajan Venkatraman Juniper Networks Email: natv@juniper.net Harish Sitaraman Juniper Networks Email: hsitaraman@juniper.net Dai, et al. Expires September 10, 2015 [Page 6] Internet-Draft MPLS RSVP-TE MBB Label Reuse March 2015 Dai, et al. Expires September 10, 2015 [Page 7]