idnits 2.17.1 draft-dai-mpls-rsvp-te-mbb-label-reuse-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3209]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2015) is 3330 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Dai, Ed. 3 Internet-Draft Y. Rekhter 4 Intended status: Best Current Practice E. Aries 5 Expires: September 10, 2015 Facebook 6 Muhammad Nauman Chaudhry 7 Verizon Communications 9 March 9, 2015 11 MPLS RSVP-TE MBB Label Reuse 12 draft-dai-mpls-rsvp-te-mbb-label-reuse-00 14 Abstract 16 The concept of "make-before-break (MBB)" while rerouting MPLS RSVP-TE 17 tunnels is discussed in [RFC3209]. In the procedure that is 18 outlined, the behavior of downstream label assignment for the new LSP 19 (new tunnel instance) is not well defined. As a general practice, a 20 different label is assigned by each downstream router and advertised 21 to the upstream router in the RESV message for the new LSP; this 22 results in a separate end-to-end data-plane path for the new LSP 23 (with the exception of PHP LSPs or UHP LSP with explicit label on the 24 last hop). This practice allows independent end to end LSP path 25 data-plane verification for each tunnel instance. The consequence of 26 this practice is that the label entry gets added/deleted in the LFIB 27 at every non-ingress router along the LSP path during MBB. Also, the 28 ingress router would need to update all the applications using this 29 LSP when switching to the new tunnel instance, as the new tunnel 30 instance uses different outgoing label. This in turn may also cause 31 other elements of the network which are dependent on the LSP to do 32 the update. 34 Such network churn can be avoided/minimized if the same label can be 35 re-used (kept intact) wherever it is affecting neither the routing 36 functionalities nor the data path verification of each instance. In 37 addition, whenever label is reused, the setup time for the new tunnel 38 instance would be faster because there is no need for the transit 39 routers along the path of the new LSP to wait for the new LFIB entry 40 to be added. This document proposes a set of procedures to 41 facilitate label reuse when there is a total or partial path overlap 42 between the two tunnel instances during MBB. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on September 10, 2015. 67 Copyright Notice 69 Copyright (c) 2015 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 1.1. Common LSP MBB triggers . . . . . . . . . . . . . . . . . 3 86 2. Recommended conditions for label reuse . . . . . . . . . . . 3 87 3. Control of label-reuse behavior . . . . . . . . . . . . . . . 4 88 3.1. Enable/Disable label-reuse capability . . . . . . . . . . 4 89 3.2. Prefer overlapping path to facilitate label-reuse . . . . 5 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 93 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 96 1. Introduction 98 MPLS RSVP-TE make-before-break (MBB) procedure is defined in 99 [RFC3209]. The behavior of downstream label assignment for the new 100 LSP (new tunnel instance) is not well-defined in this procedure. In 101 most MBB implementations, a different label is assigned by each 102 downstream router and advertised to upstream router in the RESV 103 message for the new Label Switched Path (LSP). This means a separate 104 end-to-end data-plane path for the new tunnel instance (with the 105 exception of PHP LSPs or UHP LSPs with explicit NULL label at the 106 last hop). Although this allows for independent end-to-end path 107 verification for each tunnel instance, it requires an LFIB entry add/ 108 delete at every non-ingress router along the path of the LSP during 109 MBB even if the paths for the new tunnel instance and the old tunnel 110 instance might be partially or totally overlapping. Label reuse 111 under partial or total overlap condition reduces unnecessary LFIB 112 update, reduces the possibility of errors and improves network 113 convergence latency. In cases where there is a total overlap of 114 paths between the two tunnel instances and the label is reused at 115 each hop along the overlapping path, the necessity of data plane 116 verification for the new tunnel instance is no longer needed. 118 1.1. Common LSP MBB triggers 120 The MBB procedure can be triggered because of a change to any 121 property of the RSVP-TE tunnel. The most common case is a change to 122 the bandwidth requirement, especially with the widely implemented 123 auto-bandwidth feature, which dynamically adjusts the LSP bandwidth 124 based on traffic-monitoring feedback. With CSPF commonly used to 125 compute path to meet the new bandwidth requirements, it is possible 126 that the existing path is still one of the best paths which can 127 satisfy the new requirements. This provides the opportunity to reuse 128 labels to maximize the benefits described. If given the choice and 129 the goal of selecting the best path is not the highest priority, CSPF 130 can also prefer the existing path to other possible paths to take 131 full advantage of the label reuse as long as the requirements are 132 still met by the existing path. 134 2. Recommended conditions for label reuse 136 The notion of "Label reuse" can be applied for both point-to-point 137 (P2P) LSP and point-to-multipoint (P2MP) LSP, but due to the 138 complexity of P2MP and many possible variations of the solutions, 139 this document will only focus on the recommendations for P2P LSPs. 141 Labels can be reused when the primary paths of the two tunnel 142 instances have complete overlap starting from a certain point in the 143 paths and going all the way to the egress router of the LSP. The 144 best case scenario is complete overlap of the two paths end to end; 145 in which case there is no need for any label changes and LFIB 146 updates, both in the transit as well as in the ingress routers. In 147 this scenario there is also no need to perform data plane 148 verification for the new tunnel instance. For the case where the two 149 paths overlaps only from a certain transit router (rather than from 150 the ingress), label reuse starts at that router and continues all the 151 way to the egress router. In this case the existing data plane 152 verification method can still be used to verify new tunnel instance 153 as before. Data traversing on either instance will take a different 154 label path from the ingress to this transit router and from then on 155 the traffic will merge into the shared label switched path towards 156 the egress router. 158 The conditions under which label reuse can be applied are as 159 following: 161 o Egress router of LSP: Reuse-label functionality can always be 162 applied. 164 o Transit routers of the LSP: For any given transit router of P2P 165 LSP, label can be reused if the following conditions are met: 167 (a) Downstream label received is the same 169 (b) NHOP is the same 171 o Ingress router of the LSP: When the same conditions as listed 172 under transit router are met, instead of no label change, there is 173 no need for ingress route update for LSP to applications depending 174 on it. 176 The label reuse procedure starts from the egress of the LSP as RESV 177 traverses upstream towards the ingress of the LSP; it terminates at 178 the first transit router where paths of the two tunnel instances 179 diverge towards the ingress of the LSP or at the transit router which 180 doesn't support label reuse. 182 3. Control of label-reuse behavior 184 3.1. Enable/Disable label-reuse capability 186 This document recommends enabling "label-reuse" capability by 187 default. Allow it to be disabled if needed by changing 188 configuration. 190 3.2. Prefer overlapping path to facilitate label-reuse 192 In order to take full advantage of the label-reuse capability, path 193 computation for the new tunnel instance may seek to maximize path 194 overlap. This can be achieved through two approaches. 196 o The first approach is to select from the best paths available the 197 path which has the most path overlap with the existing path 198 starting from the egress router. 200 o The second approach is to prefer the existing path if it still 201 satisfies the new requirement, even though it might not be the 202 best path. 204 The choice between the approaches is a matter of local computation 205 policy and can be different for different types of MBB trigger. 207 4. IANA Considerations 209 This document makes no request for IANA action. 211 5. Security Considerations 213 This document does not introduce new security issues. 215 6. Acknowledgements 217 The authors wish to thank Vishnu Pavan Beeram for his input, 218 feedback, and helpful suggestions. 220 7. Normative References 222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 223 Requirement Levels", BCP 14, RFC 2119, March 1997. 225 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 226 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 227 Tunnels", RFC 3209, December 2001. 229 Authors' Addresses 231 Minjie Dai (editor) 232 Juniper Networks 233 Email: mdai@juniper.net 234 Yakov Richter 235 Juniper Networks 236 Email: yakov@juniper.net 238 Ebben Aries 239 Facebook 240 1 Hacker Way 241 Menlo Park, CA 94025 242 US 243 Email: exa@fb.com 245 Muhammad Nauman Chaudhry 246 Verizon Communications 247 Email: muhammd.n.chaudhry@verizon.com 249 Raveendra Torvi 250 Juniper Networks 251 Email: rtorvi@juniper.net 253 Markus Work 254 Juniper Networks 255 Email: mjork@juniper.net 257 Yimin Shen 258 Juniper Networks 259 Email: yshen@juniper.net 261 Natrajan Venkatraman 262 Juniper Networks 263 Email: natv@juniper.net 265 Harish Sitaraman 266 Juniper Networks 267 Email: hsitaraman@juniper.net