idnits 2.17.1 draft-dai-mpls-rsvp-te-mbb-label-reuse-01.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 (September 9, 2015) is 3151 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 Juniper Networks 4 Intended status: Best Current Practice E. Aries 5 Expires: March 12, 2016 Facebook 6 M. Chaudhry 7 Verizon Communications 8 September 9, 2015 10 MPLS RSVP-TE MBB Label Reuse 11 draft-dai-mpls-rsvp-te-mbb-label-reuse-01 13 Abstract 15 The concept of "make-before-break (MBB)" while rerouting MPLS RSVP-TE 16 tunnels is discussed in [RFC3209]. In the procedure that is 17 outlined, the behaviour of downstream label assignment for the new 18 LSP (new tunnel instance) is not well defined. As a general 19 practice, a different label is assigned by each downstream router and 20 advertised to the upstream router in the RESV message for the new 21 LSP; this results in a separate end-to-end data-plane path for the 22 new LSP (with the exception of PHP LSPs or UHP LSP with explicit 23 label on the last hop). The consequence of this practice is that the 24 label entry gets added/deleted in the LFIB at every non-ingress 25 router along the LSP path during MBB. Also, the ingress router would 26 need to update all the applications using this LSP when switching to 27 the new tunnel instance, as the new tunnel instance uses different 28 outgoing label. This in turn may also cause other elements of the 29 network which are dependant on the LSP to do the update. 31 Such network churn can be avoided or reduced if the same label can 32 be re-used (kept intact) wherever it is affecting neither the routing 33 functionalities nor the data path verification of each instance. 34 This document proposes a set of procedures to facilitate label reuse 35 when there is a total or partial path overlap between the two tunnel 36 instances during MBB. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on March 12, 2016. 61 Copyright Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Common LSP MBB triggers . . . . . . . . . . . . . . . . . 3 80 2. Recommended conditions for label reuse . . . . . . . . . . . 3 81 3. Control of label-reuse behaviour . . . . . . . . . . . . . . 4 82 3.1. Enable/Disable label-reuse capability . . . . . . . . . . 4 83 3.2. Prefer overlapping path to facilitate label-reuse . . . . 4 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 87 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 90 1. Introduction 92 MPLS RSVP-TE make-before-break (MBB) procedure is defined in 93 [RFC3209]. The behaviour of downstream label assignment for the new 94 LSP (new tunnel instance) is not well-defined in this procedure. In 95 most MBB implementations, a different label is assigned by each 96 downstream router and advertised to upstream router in the RESV 97 message for the new Label Switched Path (LSP). This means a separate 98 end-to-end data-plane path for the new tunnel instance (with the 99 exception of PHP LSPs or UHP LSPs with explicit NULL label at the 100 last hop). Although this allows for independent end-to-end path 101 verification for each tunnel instance, it requires an LFIB entry add/ 102 delete at every non-ingress router along the path of the LSP during 103 MBB even if the paths for the new tunnel instance and the old tunnel 104 instance might be partially or totally overlapping. Label reuse 105 under partial or total overlap condition reduces unnecessary LFIB 106 update, reduces the possibility of errors and improves network 107 convergence latency. In addition, whenever label is reused, the 108 setup time for the new tunnel instance would be faster because there 109 is no need for the transit routers along the path of the new LSP to 110 wait for the new LFIB entry to be added. 112 1.1. Common LSP MBB triggers 114 The MBB procedure can be triggered because of a change to any 115 property of the RSVP-TE tunnel. The most common case is a change to 116 the bandwidth requirement, especially with the widely implemented 117 auto-bandwidth feature, which dynamically adjusts the LSP bandwidth 118 based on traffic-monitoring feedback. With CSPF commonly used to 119 compute path to meet the new bandwidth requirements, it is possible 120 that the existing path is still one of the best paths which can 121 satisfy the new requirements. This provides the opportunity to reuse 122 labels to achieve the benefits described. If given the choice and 123 the goal of selecting the best path is not the highest priority, CSPF 124 can also prefer the existing path to other possible paths to take 125 full advantage of the label reuse as long as the requirements are 126 still met by the existing path. 128 2. Recommended conditions for label reuse 130 The notion of "Label reuse" can be applied for both point-to-point 131 (P2P) LSP and point-to-multipoint (P2MP) LSP, but due to the 132 complexity of P2MP and many possible variations of the solutions, 133 this document will only focus on the recommendations for P2P LSPs. 135 Labels can be reused when the primary paths of the two tunnel 136 instances have complete overlap starting from a certain point in the 137 paths and going all the way to the egress router of the LSP. The 138 best case scenario is complete overlap of the two paths end to end; 139 in which case there is no need for any label changes and LFIB 140 updates, both in the transit as well as in the ingress routers. 141 Existing data plane verification method can be used to verify new 142 tunnel instance as before. Data traversing on either instance will 143 take a different label path from the ingress to this transit router 144 and from then on the traffic will merge into the shared label 145 switched path towards the egress router. 147 The conditions under which label reuse can be applied are as 148 following: 150 o Egress router of LSP: Reuse-label functionality can always be 151 applied. 153 o Transit routers of the LSP: For any given transit router of P2P 154 LSP, label can be reused if the following conditions are met: 156 (a) Downstream label received is the same 158 (b) NHOP is the same 160 o Ingress router of the LSP: When the same conditions as listed 161 under transit router are met, instead of no label change, there is 162 no need for ingress route update for LSP to applications depending 163 on it. 165 The label reuse procedure starts from the egress of the LSP as RESV 166 traverses upstream towards the ingress of the LSP; it terminates at 167 the first transit router where paths of the two tunnel instances 168 diverge towards the ingress of the LSP or at the transit router which 169 doesn't support label reuse. 171 3. Control of label-reuse behaviour 173 3.1. Enable/Disable label-reuse capability 175 This document recommends enabling "label-reuse" capability by 176 default. Allow it to be disabled if needed by changing 177 configuration. 179 3.2. Prefer overlapping path to facilitate label-reuse 181 In order to take full advantage of the label-reuse capability, path 182 computation for the new tunnel instance may seek to maximize path 183 overlap. This can be achieved through two approaches. 185 o The first approach is to select from the best paths available the 186 path which has the most path overlap with the existing path 187 starting from the egress router. 189 o The second approach is to prefer the existing path if it still 190 satisfies the new requirement, even though it might not be the 191 best path. 193 The choice between the approaches is a matter of local computation 194 policy and can be different for different types of MBB trigger. 196 4. IANA Considerations 198 This document makes no request for IANA action. 200 5. Security Considerations 202 This document does not introduce new security issues. 204 6. Acknowledgements 206 None. 208 7. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, 212 DOI 10.17487/RFC2119, March 1997, 213 . 215 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 216 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 217 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 218 . 220 Authors' Addresses 222 Minjie Dai (editor) 223 Juniper Networks 224 1194 N. Mathilda Ave 225 Sunnyvale, CA 94089 226 US 228 Email: mdai@juniper.net 229 Ebben Aries 230 Facebook 231 1 Hacker Way 232 Menlo Park, CA 94025 233 US 235 Email: exa@fb.com 237 Muhammad Nauman Chaudhry 238 Verizon Communications 240 Email: muhammad.n.chaudhry@verizon.com 242 Raveendra Torvi 243 Juniper Networks 245 Email: rtorvi@juniper.net 247 Markus Jork 248 Juniper Networks 250 Email: mjork@juniper.net 252 Yimin Shen 253 Juniper Networks 255 Email: yshen@juniper.net 257 Natrajan Venkataraman 258 Juniper Networks 260 Email: natv@juniper.net 262 Harish Sitaraman 263 Juniper Networks 265 Email: hsitaraman@juniper.net