idnits 2.17.1 draft-tsaad-mpls-p2mp-loose-path-reopt-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2014) is 3566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Tarek Saad, Ed. 3 Internet-Draft Rakesh Gandhi, Ed. 4 Intended status: Standards Track Zafar Ali 5 Expires: January 22, 2015 Cisco Systems, Inc. 6 Robert H. Venator 7 Defense Information Systems Agency 8 Yuji Kamite 9 NTT Communications Corporation 10 July 21, 2014 12 Reoptimization of Point-to-Multipoint Traffic Engineering 13 Loosely Routed LSPs 14 draft-tsaad-mpls-p2mp-loose-path-reopt-03 16 Abstract 18 For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label 19 Switched Path (LSP), it is preferable in some cases to re-evaluate 20 and re-optimize the entire P2MP-TE LSP by re-signaling all its S2L 21 sub-LSP(s). Existing mechanisms allow the path re-evaluation and the 22 signaling of a the notification of preferred path exists for a single 23 S2L sub-LSP only. 25 This document defines RSVP-TE signaling extensions to allow an 26 ingress Label Switching Router (LSR) of a P2MP-TE LSP to trigger the 27 re-evaluation of the entire LSP tree containing one or more S2L sub- 28 LSPs whose paths are loose (or abstract) hop expanded, and for a mid- 29 point LSR to signal to the ingress LSR that a better tree exists for 30 the entire P2MP-TE LSP. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Nomenclatures . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Conventions used in this document . . . . . . . . . . . . 5 69 3. Signaling Procedure For Loosely Routed P2MP-TE LSP 70 Reoptimization . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. RSVP Signaling Extensions . . . . . . . . . . . . . . . . . . 6 72 4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 6 73 4.2. Preferable P2MP-TE Tree Exists Path Error sub-code . . . . 6 74 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 8 78 7.2. Preferable P2MP-TE Tree Exists Path Error sub-code . . . . 8 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 This document defines Resource Reservation Protocol - Traffic 88 Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for 89 re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic 90 Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an 91 Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) 92 networks. 94 A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) 95 sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one 96 whose path does not contain the full explicit route identifying each 97 node along the path to the egress node at the time of its signaling 98 by the ingress node. Such an S2L sub-LSP is signaled with no 99 Explicit Route Object (ERO) [RFC3209], or with an ERO that contains 100 at least one loose hop, or with an ERO that contains an abstract node 101 that is not a simple abstract node (that is, an abstract node that 102 identifies more than one node). This is often the case with 103 inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not 104 used [RFC5440]. 106 As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE 107 LSP by re-signaling all its S2L sub-LSP(s) or may re-optimize 108 individual S2L sub-LSP(s) i.e. individual destination(s). 110 [RFC4736] defines RSVP signaling extensions for re-optimizing loosely 111 routed P2P TE LSP(s) as follows. 113 - A mid-point LSR that expands loose next-hop(s) MAY send a solicited 114 or unsolicited PathErr with the Notify error code (25 as defined in 115 [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" to 116 the ingress node. 118 - An ingress node MAY trigger a path re-evaluation request at all 119 mid-point LSR(s) that expands loose next-hop(s) by setting the "Path 120 Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES object in 121 the Path message. 123 - The ingress node upon receiving this PathErr either solicited or 124 unsolicited initiates re-optimization of the LSP. 126 [RFC4736] does not define signaling extensions specific for re- 127 optimizing entire P2MP-TE LSP tree. Mechanisms defined in [RFC4736] 128 can be used for signaling the re-optimization of individual S2L sub- 129 LSP(s). However, to use [RFC4736] mechanisms for re-optimizing an 130 entire P2MP-TE LSP tree, an ingress node needs to send the path re- 131 evaluation requests on all (typically 100s of) S2L sub-LSPs and the 132 mid-point LSR to notify PathErrs for all S2L sub-LSPs. Such a 133 procedure may lead to the following issues: 135 - A mid-point LSR that expands loose next-hop(s) may have to 136 accumulate the received path re-evaluation request(s) for all S2L 137 sub-LSPs (e.g, by using a wait timer) and interpret them as a re- 138 optimization request for the whole P2MP-TE LSP tree. Otherwise, A 139 mid-point LSR may prematurely notify "Preferable Path Exists" for one 140 or a sub-set of S2L sub-LSPs. 142 - The ingress LSR that receives (un)solicited PathErr notification(s) 143 for individual S2L sub-LSP(s), may prematurely start re-optimizing 144 the sub-set of S2L sub-LSPs. However, as mentioned in [RFC4875] 145 Section 14.2, such re-optimization procedure may result in data 146 duplication that can be avoided if the entire P2MP-TE LSP tree is re- 147 optimized, especially if the ingress node eventually receives PathErr 148 notifications for all S2L sub-LSPs of the P2MP-TE LSP tree. 150 - The ingress node may have to heuristically determine when to 151 perform entire P2MP-TE LSP tree re-optimization versus per S2L sub- 152 LSP re-optimization, for example, to delay re-optimization long 153 enough to allow all PathErr(s) to be received. Once all PathErr(s) 154 are received, the ingress node has to accumulate them to see if re- 155 optimization of the entire P2MP-TE is necessary. Such procedures may 156 produce undesired results due to timing related issues. This may be 157 easily avoided by the RSVP signaling messages defined in this 158 document. 160 This document defines RSVP-TE signaling extensions for the head-end 161 LSR of a P2MP-TE LSP to trigger the re-evaluation of the P2MP tree on 162 every hop that has a next hop defined as a loose or abstract hop for 163 one or more S2L sub-LSP path, and a mid-point LSR to signal to the 164 head-end LSR that a better tree exists (compared to the current path) 165 or that the whole P2MP-TE LSP must be re-optimized (because of 166 maintenance required on the TE LSP path). 168 2. Terminology 170 2.1. Abbreviations 172 ABR: Area Border Router. 174 AS: Autonomous System. 176 ERO: Explicit Route Object. 178 TE LSP: Traffic Engineering Label Switched Path. 180 TE LSP ingress: head/source of the TE LSP. 182 TE LSP egress: tail/destination of the TE LSP. 184 2.2. Nomenclatures 186 Domain: Routing or administrative domain such as an IGP area and an 187 autonomous system. 189 Interior Gateway Protocol Area (IGP Area): OSPF Area or IS-IS level. 191 Inter-area TE LSP: A TE LSP whose path transits across at least two 192 different IGP areas. 194 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 195 two different Autonomous Systems (ASes) or sub-ASes (BGP 196 confederations). 198 S2L sub-LSP: Source-to-leaf sub Label Switched Path. 200 2.3. Conventions used in this document 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. The reader 205 is assumed to be familiar with the terminology in [RFC4875] and 206 [RFC4736]. 208 3. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-Optimization 210 It might be preferable, as per [RFC4875], to re-optimize the entire 211 P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, 212 "Make-before- Break") or re-optimize individual S2L sub-LSP(s) i.e. 213 individual destination(s) (Section 14.2 "Sub-Group-Based Re- 214 Optimization"). This can be achieved by using the procedures defined 215 in [RFC4736] to individually re-optimize the S2L sub-LSP(s) of a 216 P2MP-TE LSP. 218 To evaluate an entire P2MP-TE LSP tree on mid-point LSRs that expand 219 loose next-hop(s), an ingress node may send a Path message with 220 "P2MP-TE Tree Re-evaluation Request" defined in this document. An 221 ingress node may select one or more S2L sub-LSP of the P2MP-TE LSP 222 tree to trigger the re-evaluation request(s). 224 A mid-point LSR that expands loose next-hop(s) for one or more S2L 225 sub-LSP path(s), and that receives a Path message with the "P2MP-TE 226 Tree Re-evaluation Request" bit set, checks for a preferable P2MP-TE 227 LSP tree by re-evaluating all S2L sub-LSP(s) expanded paths of the 228 P2MP-TE LSP. If a preferable P2MP-TE LSP tree is found, the mid- 229 point LSR sends an RSVP PathErr to the ingress node with Error code 230 25 (Notify defined in [RFC3209] and Error sub-code defined in this 231 document "Preferable P2MP-TE Tree Exists". The mid-point LSR, in 232 turn, does not propagate the "P2MP-TE Tree Re-evaluation Request" bit 233 in subsequent RSVP Path messages sent downstream for the re-evaluated 234 P2MP-TE LSP. The sending of an RSVP PathErr Notify message 235 "Preferable P2MP-TE Tree Exists" to the ingress node will notify the 236 ingress node of the existence of a preferable P2MP-TE LSP tree. In 237 addition, a mid-point LSR may send an unsolicited PathErr message 238 with "Preferable P2MP-TE Tree Exists" PathErr code 25 to the ingress 239 node to notify of a preferred the P2MP-TE LSP tree when it determines 240 it exists. In this case, the mid-point LSR that expands loose next- 241 hop(s) for one or more S2L sub-LSP path(s) may select one or more S2L 242 sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to 243 the ingress node. 245 If no preferable tree for P2MP-TE LSP can be found, the recommended 246 mode is for the mid-point LSR that expands loose next-hop(s) for one 247 or more S2L sub-LSP path(s) to propagate the request downstream by 248 setting the "P2MP-TE Tree Re-evaluation Request" bit in the 249 LSP_ATTRIBUTES object of RSVP Path message. 251 4. RSVP Signaling Extensions 253 4.1. P2MP-TE Tree Re-evaluation Request Flag 255 In order to trigger a tree re-evaluation request, a new flag is 256 defined in Attributes Flags TLV of the LSP_ATTRIBUTES object 257 [RFC5420] as follows: 259 Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation 260 Request flag 262 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 263 message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node. 265 4.2. Preferable P2MP-TE Tree Exists Path Error sub-code 267 In order to indicate to an ingress node that a preferable P2MP-TE LSP 268 tree exists, the following new sub-code for PathErr code 25 (Notify 269 Error) [RFC3209] is defined: 271 Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists 272 sub-code 274 When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR 275 sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 276 PathErr notification to the ingress node of the P2MP-TE LSP. 278 5. Compatibility 280 The LSP_ATTRIBUTES object has been defined in [RFC5420] with class 281 numbers in the form 11bbbbbb, which ensures compatibility with 282 non-supporting nodes. Per [RFC2205], nodes not supporting this 283 extension will ignore the new flag defined in this document but 284 forward it without modification. 286 6. Security Considerations 288 This document defines a mechanism for a mid-point LSR to notify the 289 ingress node of a P2MP-TE LSP of the existence of a preferable tree. 290 As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning 291 multiple domains, it may be desirable for a a mid-point LSR to modify 292 the RSVP PathErr message defined in this document to maintain 293 confidentiality across different domains. Furthermore, an ingress 294 node may decide to ignore this PathErr message coming from a mid- 295 point LSR residing in another domain. Similarly, an mid-point LSR 296 may decide to ignore the tree re-evaluation request originating from 297 another ingress domain. 299 7. IANA Considerations 301 IANA maintains a name space for RSVP-TE TE parameters "Resource 302 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters". From 303 the registries in this name space "Attribute Flags" allocation of new 304 flag is requested (Section 4.1). 306 IANA also maintains a name space for RSVP protocol parameters 307 "Resource Reservation Protocol (RSVP) Parameters". From the sub- 308 registry "Sub-Codes - 25 Notify Error" in registry "Error Codes and 309 Globally-Defined Error Value Sub-Codes" allocation of a new error 310 code is requested (Section 4.2). 312 7.1. P2MP-TE Tree Re-evaluation Request Flag 314 The following new flag is defined for the Attributes Flags TLV in the 315 LSP_ATTRIBUTES object [RFC5420]. The numeric value is to be assigned 316 by IANA. 318 o P2MP-TE Tree Re-evaluation Request Flag: 320 +--------+---------------+---------+---------+---------+------------+ 321 | Bit No | Attribute | Carried | Carried | Carried | Reference | 322 | | Flag Name | in Path | in Resv | in RRO | | 323 +--------+---------------+---------+---------+---------+------------+ 324 | TBA by | P2MP-TE Tree | Yes | No | No | This | 325 | IANA | Re-evaluation | | | | document | 326 +--------+---------------+---------+---------+---------+------------+ 328 7.2. Preferable P2MP-TE Tree Exists Path Error sub-code 330 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object 331 corresponds to a Notify Error PathErr. This document adds a new 332 sub-code as follows for this PathErr: 334 o Preferable P2MP-TE Tree Exists sub-code: 336 +----------+--------------------+---------+---------+-----------+ 337 | Sub-code | Sub-code | PathErr | PathErr | Reference | 338 | value | Name | Code | Name | | 339 +----------+--------------------+---------+---------+-----------+ 340 | TBA by | Preferable P2MP-TE | 25 | Notify | This | 341 | IANA | Tree Exists | | error | document | 342 +----------+--------------------+---------+---------+-----------+ 344 8. Acknowledgments 346 The authors would like to thank Loa Andersson for reviewing this 347 document. 349 9. References 351 9.1. Normative References 353 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 354 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 355 Functional Specification", RFC 2205, September 1997. 357 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 358 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 359 Tunnels", RFC 3209, December 2001. 361 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 362 "Extensions to Resource Reservation Protocol Traffic 363 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 364 Switched Paths (LSPs)", RFC 4875, May 2007. 366 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 367 Ayyangarps, "Encoding of Attributes for MPLS LSP 368 Establishment Using Resource Reservation Protocol Traffic 369 Engineering (RSVP-TE)", RFC 5420, February 2009. 371 9.2. Informative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 377 Multiprotocol Label Switching (MPLS) Traffic Engineering 378 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 379 November 2006. 381 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 382 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 383 March 2009. 385 Author's Addresses 387 Tarek Saad (editor) 388 Cisco Systems 390 Email: tsaad@cisco.com 392 Rakesh Gandhi (editor) 393 Cisco Systems 395 Email: rgandhi@cisco.com 397 Zafar Ali 398 Cisco Systems 400 Email: zali@cisco.com 402 Robert H. Venator 403 Defense Information Systems Agency 405 Email: robert.h.venator.civ@mail.mil 407 Yuji Kamite 408 NTT Communications Corporation 410 Email: y.kamite@ntt.com