idnits 2.17.1 draft-ietf-mpls-p2mp-loose-path-reopt-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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A mid-point LSR that expands loose next-hop(s) for one or more S2L sub-LSP path(s), and that receives a Path message with the "P2MP-TE Tree Re-evaluation Request" bit set, SHOULD 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. If a preferable P2MP-TE LSP tree is found, the mid-point LSR MAY send an RSVP PathErr to the ingress node with Error code 25 (Notify defined in [RFC3209] and Error sub-code defined in this document "Preferable P2MP-TE Tree Exists". The mid-point LSR, in turn, SHOULD not propagate the "P2MP-TE Tree Re-evaluation Request" bit in subsequent RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP. The sending of an RSVP PathErr Notify message "Preferable P2MP-TE Tree Exists" to the ingress node SHALL notify the ingress node of the existence of a preferable P2MP-TE LSP tree. In addition, a mid-point LSR MAY send an unsolicited PathErr message with "Preferable P2MP-TE Tree Exists" PathErr code 25 to the ingress node to notify of a preferred the 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) SHOULD select one of the S2L sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the ingress node. -- The document date (September 30, 2014) is 3488 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: April 3, 2015 Cisco Systems, Inc. 6 Robert H. Venator 7 Defense Information Systems Agency 8 Yuji Kamite 9 NTT Communications Corporation 10 September 30, 2014 12 Extensions to Resource Reservation Protocol For Re-optimization 13 of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs 14 draft-ietf-mpls-p2mp-loose-path-reopt-01 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 21 Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism 22 for an ingress Label Switched Router (LSR) to trigger a new path re- 23 evaluation request and a mechanism for a mid-point LSR to notify an 24 availability of a preferred path, operate on an individual or a sub- 25 group of S2L sub-LSP(s) basis only. 27 This document defines RSVP-TE signaling extensions to allow an 28 ingress node of a P2MP-TE LSP to request the re-evaluation of the 29 entire LSP tree containing one or more S2L sub-LSPs whose paths are 30 loose (or abstract) hop expanded, and for a mid-point LSR to notify 31 to the ingress node that a preferable tree exists for the entire 32 P2MP-TE LSP. This document also defines markers to indicate 33 beginning and end of a S2L sub-LSP descriptor list when RSVP message 34 needs to be fragmented due to large number of S2L sub-LSPs when 35 performing re-optimization. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 Copyright Notice 54 Copyright (c) 2014 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Existing Mechanism For Re-optimizing Loosely Routed 71 P2MP-TE LSP . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Combining Multiple Path Messages for Re-optimization . . . 5 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 75 2.2. Nomenclatures . . . . . . . . . . . . . . . . . . . . . . 7 76 2.3. Conventions Used in This Document . . . . . . . . . . . . 7 77 3. Signaling Procedure For Loosely Routed P2MP-TE LSP 78 Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.1. Tree Based Re-optimization . . . . . . . . . . . . . . . . 8 80 3.2. Sub-group Based Re-optimization . . . . . . . . . . . . . 8 81 4. RSVP Signaling Extensions . . . . . . . . . . . . . . . . . . 9 82 4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 9 83 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 10 84 4.3. Markers For S2L sub-LSP Descriptor . . . . . . . . . . . . 10 85 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12 89 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 12 90 7.3. BEGIN and END Markers For S2L sub-LSP Descriptor . . . . . 12 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 94 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 95 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 This document defines Resource Reservation Protocol - Traffic 100 Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for 101 re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic 102 Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an 103 Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) 104 networks. 106 A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) 107 sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one 108 whose path does not contain the full explicit route identifying each 109 node along the path to the egress node at the time of its signaling 110 by the ingress node. Such an S2L sub-LSP is signaled with no 111 Explicit Route Object (ERO) [RFC3209], or with an ERO that contains 112 at least one loose hop, or with an ERO that contains an abstract node 113 that is not a simple abstract node (that is, an abstract node that 114 identifies more than one node). This is often the case with 115 inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not 116 used [RFC5440]. 118 As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE 119 LSP by re-signaling all its S2L sub-LSP(s) or may re-optimize 120 individual or group of S2L sub-LSP(s) i.e. individual or group of 121 destination(s). 123 1.1. Existing Mechanism For Re-optimizing Loosely Routed P2MP-TE LSP 125 [RFC4736] defines RSVP signaling extensions for re-optimizing loosely 126 routed P2P TE LSP(s) as follows. 128 - A mid-point LSR that expands loose next-hop(s) sends a solicited or 129 unsolicited PathErr with the Notify error code (25 as defined in 130 [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" to 131 the ingress node. 133 - An ingress node triggers a path re-evaluation request at all 134 mid-point LSR(s) that expands loose next-hop(s) by setting the "Path 135 Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES Object in 136 the Path message. 138 - The ingress node upon receiving this PathErr either solicited or 139 unsolicited initiates re-optimization of the LSP. 141 [RFC4736] does not define signaling extensions specific for 142 re-optimizing entire P2MP-TE LSP tree. Mechanisms defined in 144 [RFC4736] can be used for signaling the re-optimization of individual 145 or group of S2L sub-LSP(s). However, to use [RFC4736] mechanisms for 146 re-optimizing an entire P2MP-TE LSP tree, an ingress node needs to 147 send the path re-evaluation requests on all (typically 100s of) S2L 148 sub-LSPs and the mid-point LSR to notify PathErrs for all S2L 149 sub-LSPs. Such a procedure may lead to the following issues: 151 - A mid-point LSR that expands loose next-hop(s) may have to 152 accumulate the received path re-evaluation request(s) for all S2L 153 sub-LSPs (e.g, by using a wait timer) and interpret them as a 154 re-optimization request for the whole P2MP-TE LSP tree. Otherwise, a 155 mid-point LSR may prematurely notify "Preferable Path Exists" for one 156 or a sub-set of S2L sub-LSPs. 158 - The ingress node that receives (un)solicited PathErr 159 notification(s) for individual S2L sub-LSP(s), may prematurely start 160 re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in 161 [RFC4875] Section 14.2, such sub-group based re-optimization 162 procedure may result in data duplication that can be avoided if the 163 entire P2MP-TE LSP tree is re-optimized using a different LSP-ID, 164 especially if the ingress node eventually receives PathErr 165 notifications for all S2L sub-LSPs of the P2MP-TE LSP tree. 167 - The ingress node may have to heuristically determine when to 168 perform entire P2MP-TE LSP tree re-optimization versus per S2L sub- 169 LSP re-optimization, for example, to delay re-optimization long 170 enough to allow all PathErr(s) to be received. Once all PathErr(s) 171 are received, the ingress node has to accumulate them to see if re- 172 optimization of the entire P2MP-TE is necessary. Such procedures may 173 produce undesired results due to timing related issues. This may be 174 easily avoided by the RSVP signaling messages defined in this 175 document. 177 1.2. Combining Multiple Path Messages for Re-optimization 179 Based on [RFC4875] (Section 14.2 "Sub-Group-Based Re-Optimization"), 180 an ingress node may trigger path re-evaluation requests for a set of 181 S2L sub-LSPs by combining multiple Path messages using S2L sub-LSP 182 descriptor list. A mid-point LSR may send a PathErr message 183 containing a list of S2L sub-LSPs transiting through the LSR to 184 notify the ingress node. This method can alleviate the scale issue 185 associated with sending RSVP messages for individual S2L sub-LSPs. 186 This method is useful for re-optimizing a sub-group of S2L sub-LSPs 187 within an LSP tree. However, this procedure can lead to following 188 issues: 190 - Path message that is intended to carry the path re-evaluation 191 request as defined in [RFC4736] with a full list of S2L sub-LSPs in 192 S2L sub-LSPs descriptor list will be decomposed at branching LSRs, 193 and only a subset of the S2L sub-LSPs that are routed over the same 194 next-hop will be added in the descriptor list of the Path message 195 propagated to downstream mid-point LSRs. Consequently, when a 196 preferable path exists at such mid-point LSRs, the PathErr can only 197 include the sub-set of S2L sub-LSPs traversing the LSR. In this 198 case, at the ingress node there is no way to distinguish which mode 199 of re-optimization to invoke, i.e. sub-group based re-optimization 200 using the same LSP-ID or tree based re-optimization using a different 201 LSP-ID. 203 - An LSR may fragment a large RSVP message (when a combined message 204 may not be large enough to fit all S2L sub-LSPs). In this case, the 205 ingress node may receive multiple PathErrs with sub-sets of S2L 206 sub-LSPs in each (either due to the combined Path message got 207 fragmented or combined PathErr message got fragmented) and would 208 require additional logic to infer to re-optimize the tree (for 209 example, waiting for some time to aggregate all possible PathErr 210 messages before taking an action). 212 As discussed in Section 1.1 and Section 1.2 of this document, there 213 is a requirement to align re-optimization of P2MP-TE LSP with P2P LSP 214 [RFC4736] to have a mechanism to trigger re-optimization of the LSP 215 tree by re-signaling all S2L sub-LSPs with a different LSP-ID. There 216 is also a need to define markers to indicate beginning and end of the 217 S2L sub-LSP descriptor list when an RSVP message is fragmented due to 218 large number of S2L sub-LSPs in the message. 220 This document defines RSVP-TE signaling extensions for the ingress 221 node of a P2MP-TE LSP to trigger the re-evaluation of the P2MP LSP 222 tree on every hop that has a next hop defined as a loose or abstract 223 hop for one or more S2L sub-LSP path, and a mid-point LSR to signal 224 to the ingress node that a preferable LSP tree exists (compared to 225 the current path) or that the whole P2MP-TE LSP must be re-optimized 226 (because of maintenance required on the TE LSP path). This document 227 also defines markers to indicate beginning and end of a S2L sub-LSP 228 descriptor list when RSVP message needs to be fragmented due to large 229 number of S2L sub-LSPs when performing re-optimization. 231 2. Terminology 233 2.1. Abbreviations 235 ABR: Area Border Router. 237 AS: Autonomous System. 239 ERO: Explicit Route Object. 241 LSR: Label Switching Router. 243 TE LSP: Traffic Engineering Label Switched Path. 245 TE LSP ingress: Head-end/source of the TE LSP. 247 TE LSP egress: Tail-end/destination of the TE LSP. 249 2.2. Nomenclatures 251 Domain: Routing or administrative domain such as an IGP area and an 252 autonomous system. 254 Interior Gateway Protocol Area (IGP Area): OSPF Area or IS-IS level. 256 Inter-area TE LSP: A TE LSP whose path transits across at least two 257 different IGP areas. 259 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 260 two different Autonomous Systems (ASes) or sub-ASes (BGP 261 confederations). 263 S2L sub-LSP: Source-to-leaf sub Label Switched Path. 265 2.3. Conventions Used in This Document 267 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 268 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 269 document are to be interpreted as described in [RFC2119]. The reader 270 is assumed to be familiar with the terminology in [RFC4875] and 271 [RFC4736]. 273 3. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-optimization 275 3.1. Tree Based Re-optimization 277 To evaluate an entire P2MP-TE LSP tree on mid-point LSRs that expand 278 loose next-hop(s), an ingress node MAY send a Path message with 279 "P2MP-TE Tree Re-evaluation Request" defined in this document. An 280 ingress node SHOULD select one of the S2L sub-LSPs of the P2MP-TE LSP 281 tree transiting a mid-point LSR to trigger the re-evaluation request. 283 A mid-point LSR that expands loose next-hop(s) for one or more S2L 284 sub-LSP path(s), and that receives a Path message with the "P2MP-TE 285 Tree Re-evaluation Request" bit set, SHOULD check for a preferable 286 P2MP-TE LSP tree by re-evaluating all S2L sub-LSP(s) that are 287 expanded paths of the loose next-hops of the P2MP-TE LSP. If a 288 preferable P2MP-TE LSP tree is found, the mid-point LSR MAY send an 289 RSVP PathErr to the ingress node with Error code 25 (Notify defined 290 in [RFC3209] and Error sub-code defined in this document "Preferable 291 P2MP-TE Tree Exists". The mid-point LSR, in turn, SHOULD not 292 propagate the "P2MP-TE Tree Re-evaluation Request" bit in subsequent 293 RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP. 294 The sending of an RSVP PathErr Notify message "Preferable P2MP-TE 295 Tree Exists" to the ingress node SHALL notify the ingress node of the 296 existence of a preferable P2MP-TE LSP tree. In addition, a mid-point 297 LSR MAY send an unsolicited PathErr message with "Preferable P2MP-TE 298 Tree Exists" PathErr code 25 to the ingress node to notify of a 299 preferred the P2MP-TE LSP tree when it determines it exists. In this 300 case, the mid-point LSR that expands loose next-hop(s) for one or 301 more S2L sub-LSP path(s) SHOULD select one of the S2L sub-LSP(s) of 302 the P2MP-TE LSP tree to send this PathErr message to the ingress 303 node. 305 If no preferable tree for P2MP-TE LSP can be found, the recommended 306 mode is that the mid-point LSR that expands loose next-hop(s) for one 307 or more S2L sub-LSP path(s) SHOULD propagate the request downstream 308 by setting the "P2MP-TE Tree Re-evaluation Request" bit in the 309 LSP_ATTRIBUTES Object of RSVP Path message. 311 3.2. Sub-group Based Re-optimization 313 It might be preferable, as per [RFC4875], to re-optimize the entire 314 P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, 315 "Make-before-Break") or to re-optimize individual or group of S2L 316 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 317 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same 318 LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by 319 using the procedures defined in [RFC4736] to re-optimize one or more 320 S2L sub-LSP(s) of the P2MP-TE LSP. 322 An ingress node may trigger path re-evaluation requests for a set of 323 S2L sub-LSPs by combining multiple Path messages using S2L sub-LSP 324 descriptor list [RFC4875]. An S2L sub-LSP descriptor list is created 325 using a series of S2L_SUB_LSP Objects as defined in [RFC4875]. 326 Similarly, a mid-point LSR may send a PathErr message containing a 327 list of S2L sub-LSPs transiting through the LSR to notify the ingress 328 node of preferable paths available. 330 As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State 331 Information"), when a Path message is not large enough to fit all S2L 332 sub-LSPs in the descriptor list, an LSR may fragment the message. In 333 this case, the LSR MAY add S2L_SUB_LSP_MARKER_BEGIN and 334 S2L_SUB_LSP_MARKER_END Objects defined in this document at the 335 beginning and at the end of the S2L sub-LSP descriptor list, 336 respectively. 338 Both S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects 339 defined in this document are optional. However, a node MUST add the 340 S2L_SUB_LSP_MARKER_END Object if it has added 341 S2L_SUB_LSP_MARKER_BEGIN Object in the S2L sub-LSP descriptor list. 343 A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before 344 attempting to re-evaluate preferable path when a Path message for 345 "Path Re-evaluation Request" is received with 346 S2L_SUB_LSP_MARKER_BEGIN. An ingress node SHOULD wait to accumulate 347 all S2L sub-LSPs before attempting to trigger re-optimization when a 348 PathErr message with "Preferable Path Exists" is received with 349 S2L_SUB_LSP_MARKER_BEGIN. 351 New objects S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END 352 defined in this document have a wider applicability than the P2MP-TE 353 LSP re-optimization but it is outside the scope of this document. 355 4. RSVP Signaling Extensions 357 4.1. P2MP-TE Tree Re-evaluation Request Flag 359 In order to trigger a tree re-evaluation request, a new flag is 360 defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object 361 [RFC5420] as follows: 363 Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation 364 Request flag 366 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 367 message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node. 369 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 371 In order to indicate to an ingress node that a preferable P2MP-TE LSP 372 tree exists, the following new sub-code for PathErr code 25 (Notify 373 Error) [RFC3209] is defined: 375 Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists 376 sub-code 378 When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR 379 sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 380 PathErr notification to the ingress node of the P2MP-TE LSP. 382 4.3. Markers For S2L sub-LSP Descriptor 384 An S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP 385 belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is 386 created using a series of S2L_SUB_LSP Objects as defined in 387 [RFC4875]. 389 In order to indicate the beginning and end of the S2L sub-LSP 390 descriptor list when the RSVP message needs to be fragmented due to 391 large number of S2L sub-LSPs, the following new types are defined for 392 the S2L_SUB_LSP Object [RFC4875]. 394 S2L_SUB_LSP_MARKER_BEGIN : 396 Class-Num 50, C-Type TBA by IANA 398 +-----------------+---------------+--------------------------+ 399 | Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_BEGIN | 400 +-----------------+---------------+--------------------------+ 402 S2L_SUB_LSP_MARKER_END : 404 Class-Num 50, C-Type TBA by IANA 406 +-----------------+---------------+--------------------------+ 407 | Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_END | 408 +-----------------+---------------+--------------------------+ 410 The S2L_SUB_LSP_MARKER_BEGIN Object is added before adding the first 411 S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object and the 412 S2L_SUB_LSP_MARKER_END Object is added after adding the last 413 S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the S2L sub-LSP 414 descriptor list. 416 5. Compatibility 418 The LSP_ATTRIBUTES Object has been defined in [RFC5420] with class 419 numbers in the form 11bbbbbb, which ensures compatibility with 420 non-supporting nodes. Per [RFC2205], nodes not supporting this 421 extension will ignore the new flag defined in this document but 422 forward it without modification. 424 The S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects have 425 been defined with class numbers in the form 11bbbbbb, which ensures 426 compatibility with non-supporting nodes. Per [RFC2205], nodes not 427 supporting new S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END 428 Objects will ignore them but forward it without modification. 430 6. Security Considerations 432 This document defines a mechanism for a mid-point LSR to notify the 433 ingress node of a P2MP-TE LSP of the existence of a preferable tree. 434 As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning 435 multiple domains, it may be desirable for a mid-point LSR to modify 436 the RSVP PathErr message defined in this document to maintain 437 confidentiality across different domains. Furthermore, an ingress 438 node may decide to ignore this PathErr message coming from a 439 mid-point LSR residing in another domain. Similarly, an mid-point 440 LSR may decide to ignore the tree re-evaluation request originating 441 from another ingress domain. 443 7. IANA Considerations 445 IANA is requested to administer assignment of new values for 446 namespace defined in this document and summarized in this section. 448 IANA maintains a name space for RSVP-TE TE parameters "Resource 449 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see 450 http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te- 451 parameters.xml). From the registries in this name space "Attribute 452 Flags", allocation of new flag is requested (Section 4.1). 454 IANA also maintains a name space for RSVP protocol parameters 455 "Resource Reservation Protocol (RSVP) Parameters" (see 456 http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml). 457 From the sub-registry "Sub-Codes - 25 Notify Error" in registry 458 "Error Codes and Globally-Defined Error Value Sub-Codes", allocation 459 of a new error code is requested (Section 4.2). Also, from the 460 sub-registry "Class Types or C-Types 50 S2L_SUB_LSP" in registry 461 "Class Names, Class Numbers, and Class Types", allocation of new 462 C-Types is requested (Section 4.3). 464 7.1. P2MP-TE Tree Re-evaluation Request Flag 466 The following new flag is defined for the Attributes Flags TLV in the 467 LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned 468 by IANA. 470 o P2MP-TE Tree Re-evaluation Request Flag: 472 +--------+---------------+---------+---------+---------+------------+ 473 | Bit No | Attribute | Carried | Carried | Carried | Reference | 474 | | Flag Name | in Path | in Resv | in RRO | | 475 +--------+---------------+---------+---------+---------+------------+ 476 | TBA by | P2MP-TE Tree | Yes | No | No | This | 477 | IANA | Re-evaluation | | | | document | 478 +--------+---------------+---------+---------+---------+------------+ 480 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 482 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC Object 483 corresponds to a Notify Error PathErr. This document adds a new 484 sub-code as follows for this PathErr: 486 o Preferable P2MP-TE Tree Exists sub-code: 488 +----------+--------------------+---------+---------+-----------+ 489 | Sub-code | Sub-code | PathErr | PathErr | Reference | 490 | value | Description | Code | Name | | 491 +----------+--------------------+---------+---------+-----------+ 492 | TBA by | Preferable P2MP-TE | 25 | Notify | This | 493 | IANA | Tree Exists | | Error | document | 494 +----------+--------------------+---------+---------+-----------+ 496 7.3. BEGIN and END Markers For S2L sub-LSP Descriptor 498 As defined in [RFC4875], S2L_SUB_LSP Object is defined with 499 Class-Number 50 to identify a particular S2L sub-LSP belonging to the 500 P2MP-TE LSP. This document adds two new object types for this object 501 as follows: 503 o S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Object types: 505 +---------------+---------------------------+-----------------+ 506 | C-Type value | Description | Reference | 507 +---------------+---------------------------+-----------------+ 508 | TBA by IANA | S2L_SUB_LSP_MARKER_BEGIN | This document | 509 +---------------+---------------------------+-----------------+ 510 | TBA by IANA | S2L_SUB_LSP_MARKER_END | This document | 511 +---------------+---------------------------+-----------------+ 513 8. Acknowledgments 515 The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis 516 Villamizar, Dimitri Papadimitriou and Nobo Akiya for reviewing this 517 document. 519 9. References 521 9.1. Normative References 523 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 524 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 525 Functional Specification", RFC 2205, September 1997. 527 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 528 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 529 Tunnels", RFC 3209, December 2001. 531 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 532 "Extensions to Resource Reservation Protocol Traffic 533 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 534 Switched Paths (LSPs)", RFC 4875, May 2007. 536 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 537 Ayyangarps, "Encoding of Attributes for MPLS LSP 538 Establishment Using Resource Reservation Protocol Traffic 539 Engineering (RSVP-TE)", RFC 5420, February 2009. 541 9.2. Informative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 547 Multiprotocol Label Switching (MPLS) Traffic Engineering 548 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 549 November 2006. 551 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 552 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 553 March 2009. 555 Author's Addresses 557 Tarek Saad (editor) 558 Cisco Systems 560 Email: tsaad@cisco.com 562 Rakesh Gandhi (editor) 563 Cisco Systems 565 Email: rgandhi@cisco.com 567 Zafar Ali 568 Cisco Systems 570 Email: zali@cisco.com 572 Robert H. Venator 573 Defense Information Systems Agency 575 Email: robert.h.venator.civ@mail.mil 577 Yuji Kamite 578 NTT Communications Corporation 580 Email: y.kamite@ntt.com