idnits 2.17.1 draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-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 ([RFC4875]), 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 == Line 408 has weird spacing: '... the the no...' -- The document date (April 12, 2013) is 4030 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) == Missing Reference: 'RFC2119' is mentioned on line 248, but not defined == Missing Reference: 'RFC4874' is mentioned on line 320, but not defined == Missing Reference: 'RFC2205' is mentioned on line 565, but not defined == Unused Reference: 'RFC4726' is defined on line 686, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 5920 ** Downref: Normative reference to an Informational RFC: RFC 4736 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Zafar Ali 3 Internet-Draft Rakesh Gandhi 4 Intended status: Standards Track Tarek Saad 5 Expires: October 14, 2013 Cisco Systems, Inc. 6 Robert H. Venator 7 Defense Information Systems Agency 8 Yuji Kamite 9 NTT Communications Corporation 10 April 12, 2013 12 Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment 13 draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01 15 Abstract 17 Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and 18 Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE 19 LSPs) are established using signaling procedures defined in 20 [RFC4875]. However, [RFC4875] does not address several issues that 21 arise when a P2MP-TE LSP is signaled in inter-domain networks. One 22 such issue is the computation of a loosely routed inter-domain P2MP- 23 TE LSP paths that are re-merge free. Another issue is the 24 reoptimization of the inter-domain P2MP-TE LSP tree vs. an individual 25 destination(s), since the loosely routing domain ingress border node 26 is not aware of the reoptimization scope. This document defines the 27 required protocol extensions needed for establishing and reoptimizing 28 P2MP MPLS and GMPLS TE LSPs in inter-domain networks. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 14, 2013. 47 Copyright Notice 49 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Summary of Solutions . . . . . . . . . . . . . . . . . . . 5 66 1.2. Path Computation Techniques . . . . . . . . . . . . . . . 6 67 1.3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. Conventions used in this document . . . . . . . . . . . . . . 7 69 3. Control Plane Solution For Re-merge Handling . . . . . . . . . 7 70 3.1. Single Border Node For All S2Ls . . . . . . . . . . . . . 7 71 3.2. Crankback and PathErr Signaling Procedure . . . . . . . . 7 72 4. Data Plane Solution For Re-merge Handling . . . . . . . . . . 9 73 4.1. P2MP-TE Re-merge Recording Request Flag . . . . . . . . . 9 74 4.2. P2MP-TE Re-merge Present Flag . . . . . . . . . . . . . . 9 75 4.3. Signaling Procedure . . . . . . . . . . . . . . . . . . . 10 76 5. Intra-domain P2MP-TE LSP Re-merge Handling . . . . . . . . . . 11 77 6. Reoptimization Handling . . . . . . . . . . . . . . . . . . . 12 78 6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12 79 6.2. Preferable P2MP-TE Tree Exists sub-code . . . . . . . . . 12 80 6.3. Signaling Procedure . . . . . . . . . . . . . . . . . . . 12 81 7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 9.1 P2MP-TE Re-merge Recording Request Flag . . . . . . . . . . 14 85 9.2 P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . . 15 86 9.3 P2MP-TE Re-merge Present Flag . . . . . . . . . . . . . . . 15 87 9.4 Preferable P2MP-TE Tree Exists sub-code . . . . . . . . . . 15 88 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 91 11.2. Informative References . . . . . . . . . . . . . . . . . 16 92 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 [RFC4875] describes procedures to set up Point-to-Multipoint (P2MP) 97 Traffic Engineering Label Switched Paths (TE LSPs) for use in 98 MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 99 networks. 101 As with Point-to-Point (P2P) TE LSPs, P2MP TE LSP state is managed 102 using RSVP messages. While the use of RSVP messages is mostly similar 103 to their P2P counterpart, P2MP LSP state differs from P2P LSP in a 104 number of ways. In particular, the P2MP LSP must also handle the 105 "re-merge" problem described in [RFC4875] section 18. 107 The term "re-merge" refers to the situation when two source-to-leaf 108 (S2L) sub-LSPs branch at some point in the P2MP tree, and then 109 intersect again at a another node further downstream the tree. This 110 may occur due to discrepancies in the routing algorithms used by 111 different nodes, errors in path calculation or manual configuration, 112 or network topology changes during the establishment of the P2MP LSP. 113 Such re-merges are inefficient due to the unnecessary duplication of 114 data and also consume additional network resources. Consequently one 115 of the requirements for signaling P2MP LSPs is to choose a P2MP path 116 that is re-merge free. In some deployments, it may also be required 117 to signal P2MP-TE LSPs that are both re-merge and crossover free 118 [RFC4875]. 120 For the purposes of this document, a domain is considered to be any 121 collection of network elements within a common sphere of address 122 management or path computational responsibility. Examples of such 123 domains include Interior Gateway Protocol (IGP) areas and Autonomous 124 Systems (ASes). A border node is a node between different routing 125 domains. 127 The re-merge free requirement becomes more acute to address when P2MP 128 LSP spans multiple domains. This is because in an inter-domain 129 environment, the ingress node may not have topological visibility 130 into other domains to be able to compute and signal a re-merge free 131 P2MP LSP. In that case, the border node for a new domain will be 132 given loose next hops for one or more destinations in a P2MP LSP. A 133 border node computes paths in its domain by individually expanding 134 the loose next hops for the destinations when signaled to it. A 135 border node can ensure that it computes the re-merge free paths while 136 performing loose hop ERO expansions by individually grafting 137 destinations. Note that the computed P2MP tree by a border node in 138 this case may not be optimal. When processing a Path message, the 139 border node may not have knowledge of all the destinations of the 140 P2MP LSP; for example, in the case when not all S2L sub-LSPs pass 141 through this border node. In that case, existing protocol mechanisms 142 do not provide sufficient information for it to be able to expand the 143 loose hop(s) such that the overall P2MP LSP tree is guaranteed to be 144 re-merge free. 146 [RFC4875] specifies two approaches to handle re-merge conditions. The 147 first method is based on control plane handling the re-merge. In this 148 case the node detecting the re-merge condition, i.e. the re-merge 149 node initiates the removal of the re-merge sub-LSP(s) by sending a 150 PathErr message(s) towards the ingress node. However, this can lead 151 to a deadlock in setting up the P2MP LSP in certain cases; for 152 example, when the first S2L setup causes the re-merge with all 153 subsequent S2Ls in the tree. The second method is based on the data 154 plane handling the re-merge condition. In this case, the re-merge 155 node allows the re-merge condition to persist, but data from all but 156 one incoming interface is dropped at the re-merge node. This ensures 157 that duplicate data is not sent on any outgoing interface. However, 158 network resources (such as bandwidth capacity) are wasted as long as 159 re-merge condition persists which is inefficient. 161 [RFC4736] defines procedures and signaling extensions for 162 reoptimizing an inter-domain P2P LSP. Specifically, an ingress node 163 sends a "path re-evaluation request" to a border node by setting a 164 flag (0x20) in SESSION_ATTRIBUTES object in a Path message. A border 165 node sends a PathErr code 25 (notify error defined in [RFC3209]) with 166 sub-code 6 to indicate "preferable path exists" to the ingress node. 167 The ingress node upon receiving this PathErr may initiate 168 reoptimization of the LSP. [RFC4736] however does not define a 169 procedure to reoptimize the entire P2MP LSP as a whole tree. 171 As per [RFC4875] Section 14, for a P2MP LSP, an ingress node may 172 reoptimize the entire P2MP LSP by resignaling all destinations 173 (Section 14.1, "Make-before-Break") or may reoptimize individual the 174 destinations (Section 14.2 "Sub-Group-Based Re-Optimization"). 175 Generally speaking make-before-break is considered available for 176 "whole" P2MP LSP reoptimization, but it can also be used for 177 reoptimizing physical routes for specific sub-LSP(s). The 178 Sub-Group-Based reoptimization is not always applicable because it 179 can lead to data duplication inside the backbone. 181 1.1. Summary of Solutions 183 This document defines RSVP-TE signaling procedures for P2MP LSP to 184 handle the re-merge condition when using either the control plane or 185 data plane approach. The procedures are applicable to both MPLS TE 186 and GMPLS networks. 188 The control plane solution for the re-merge problem makes use of the 189 crankback signaling mechanism of the RSVP protocol. [RFC5151] 190 describes such mechanisms for applying crankback to inter-domain P2P 191 LSPs, but does not cover P2MP LSPs. Also, crankback mechanisms for 192 P2MP LSPs are not addressed by [RFC4875]. This document describes how 193 crankback signaling extensions for MPLS and GMPLS RSVP-TE defined in 194 [RFC4920] can be used for setting up P2MP TE LSPs to resolve 195 re-merges. 197 The data plane solution for the re-merge problem described in 198 [RFC4875] is extended by using a new flag in the LSP_ATTRIBUTES TLV 199 (in a Path message) and a new flag in RRO Attributes Sub-object (in a 200 Resv message) in RSVP. The LSP_ATTRIBUTES TLV (in a Path message) and 201 RRO Attributes Sub-object (in a Resv message) have been defined in 202 [RFC5420]. This document describes how these new flags can be used to 203 handle P2MP re-merge conditions efficiently. 205 For P2MP LSP, a border node may have loosely routed entire or part of 206 the P2MP LSP by expanding EROs in Path messages of the destinations. 207 Border node does not know with the signaling procedure defined in 208 [RFC4736] if an ingress node is requesting a reoptimization for an 209 individual destination(s) or reoptimization of the entire P2MP tree. 210 Signaling extension and procedure are defined in this document to 211 handle reoptimization of an individual destination(s) and the 212 reoptimization of the entire P2MP tree. Basically, a new query 213 message is defined in LSP_ATTRIBUTES TLV to request for a "P2MP-TE 214 Tree Re-evaluation" and a new sub-code is defined for PathErr message 215 to indicate "Preferable P2MP-TE Tree Exists". 217 1.2. Path Computation Techniques 219 This document focuses on the case where the ingress node does not 220 have full visibility of the topology of all domains and is therefore 221 not able to compute the complete P2MP tree. Rather, it includes loose 222 hops to traverse the domains for which it does not have full 223 visibility and ingress border nodes(s) of each transit domain is 224 responsible for expanding those loose hops. 226 The solution presented in this document do not guarantee optimization 227 of the overall P2MP tree across all domains. Path Computation Element 228 (PCE) can be used, instead, to address global optimization of the 229 overall P2MP tree. 231 1.3. Use cases 233 Service providers having a network with multiple routing domains are 234 interested to use the network for P2MP-TE LSPs. This allows the 235 service providers to use the network to carry multicast and broadcast 236 traffic (such as video). Service providers can deploy the VPLS and 237 MVPN services in the network using inter-domain P2MP TE LSPs. The use 238 case is for P2MP TE LSPs across multiple routing domains that belong 239 to a single administrative area. Use case for the Multiple 240 administrative domains (e.g. autonomous systems) is outside the scope 241 of this document. 243 2. Conventions used in this document 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in [RFC2119]. 249 3. Control Plane Solution For Re-merge Handling 251 It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs 252 traversing multiple domains. This is because border nodes that are 253 expanding loose hops are typically best placed to correct any re- 254 merge errors that occur within their domain, not the ingress node. 256 3.1. Single Border Node For All S2Ls 258 It is RECOMMENDED that the ingress node of a P2MP LSP selects the 259 same ingress border node in the loose hop ERO for all sibling S2L 260 sub-LSPs that transit through a given domain. The reason is that it 261 will increase the possibility of re-merge downstream if two or more 262 border nodes have roles simultaneously to expand loose EROs. An 263 ingress border node that performs the loose ERO expansion for 264 individual sub-LSP(s) has the necessary state information for the 265 destinations transiting through its domain to ensure computed P2MP 266 tree is re-merge free. 268 3.2. Crankback and PathErr Signaling Procedure 270 As mentioned in [RFC4875], in order to avoid duplicate traffic, the 271 re-merge node MAY initiate the removal of the re-merge S2L sub-LSPs 272 by sending a PathErr message to the ingress node of the S2L sub-LSP. 274 Crankback procedures for rerouting around failures for P2P RSVP-TE 275 LSPs are defined in [RFC4920]. These techniques can also be applied 276 to P2MP LSPs to handle re-merge conditions, as described in this 277 section. 279 If an ingress border node on the path of the P2MP LSP is unable to 280 find a route that can supply the required resources or that is re- 281 merge free, it MUST generate a PathErr message for the subset of the 282 S2L sub-LSPs which it is not able to route. For this purpose the 283 ingress border node SHOULD try to find a minimum subset of S2L sub- 284 LSPs for which the PathErr needs to be generated towards the ingress 285 node. These are the S2L sub-LSPs on an incoming interface that has 286 less number of S2L sub-LSPs compared to the second incoming interface 287 that is causing the re-merge condition. 289 The RSVP-TE Notify messages do not include S2L_SUB_LSP objects and 290 cannot be used to send errors for a subset of the S2L sub-LSPs in a 291 Path message. For that reason, the error generating node SHOULD use a 292 PathErr message rather than a Notify message to communicate the 293 error. In the case of a re-merge error, the node SHOULD use the error 294 code "Routing Problem" and the error value "ERO resulted in re-merge" 295 as specified in [RFC4875]. 297 A border node receiving a PathErr message for a set of S2L sub-LSPs 298 MAY hold the message and attempt to signal an alternate path that can 299 avoid re-merge through its domain for those S2L sub-LSPs that pass 300 through it. However, in the case of a re-merge error for which some 301 of the re-merging S2L sub-LSPs do not pass through the border node, 302 it SHOULD propagate the PathErr upstream towards the ingress node. If 303 the subsequent attempt by the border node is successful, the border 304 node discards the held PathErr and follows the crankback roles of 305 [RFC4920] and [RFC5151]. If repeated subsequent attempts by the 306 border node are unsuccessful, the border node MUST send the held 307 PathErr upstream towards the ingress node. 309 If the ingress node receives a PathErr message with error code 310 "Routing Problem" and error value "ERO resulted in re-merge", then it 311 SHOULD attempt to signal an alternate path through a different domain 312 or through a different border node for the affected S2L sub-LSPs. The 313 ingress node MAY use the error node information from the PathErr for 314 this purpose. 316 However, it may be that the ingress node or an ingress border node 317 does not have sufficient topology information to compute an Explicit 318 Route that is guaranteed to avoid the re-merge link or node. In this 319 case, Route Exclusions [RFC4874] may be particularly helpful. To 320 achieve this, [RFC4874] allows the re-merge information to be 321 presented as route exclusions to force avoidance of the re-merge link 322 or node. 324 As discussed in [RFC4920] section 3.3, border node MAY keep the 325 history of PathErrs. In case of P2MP LSPs, ingress node and border 326 nodes may keep re-merge PathErrs in history table until S2L sub-LSPs 327 have been successfully established or until local timer expires. 329 4. Data Plane Solution For Re-merge Handling 331 As mentioned in [RFC4875], a node may accept the re-merging S2Ls but 332 only send the data from one of these interfaces to its outgoing 333 interfaces. That is, the node MUST drop data from all but one 334 incoming interface causing the re-merge. This ensures that duplicate 335 data is not sent on any outgoing interface. Note that data plane may 336 be either programmed to drop the incoming traffic for the S2L sub-LSP 337 or not programmed at all. 339 It is desirable to avoid the persistent re-merge condition associated 340 with data plane based solution in the network in order to optimize 341 bandwidth resources in the network. 343 The following sections define the RSVP-TE signaling extensions for 344 "P2MP- TE Re-merge Recording Request" and "P2MP-TE Re-merge Present" 345 messages. 347 4.1. P2MP-TE Re-merge Recording Request Flag 349 In order to indicate to traversed nodes that P2MP-TE re-merge 350 recording is desired, a new flag in the Attribute Flags TLV of the 351 LSP_ATTRIBUTES object defined in [RFC5420] is defined as follows: 353 Bit Number (to be assigned by IANA): P2MP-TE Re-merge Recording 354 Request flag 356 The "P2MP-TE Re-merge Recording Request" flag is meaningful in a Path 357 message and is inserted by the ingress node or a border node in the 358 LSP_ATTRIBUTES object. 360 If the "P2MP-TE Re-merge Recording Request" Flag is set, it implies 361 that the "P2MP-TE Re-merge Present" flag defined in the next section 362 MUST be used to indicate to the ingress and ingress border nodes of 363 the transit domains that a re-merge condition is present for this S2L 364 sub-LSP but accepted, and that incoming traffic is being dropped for 365 this S2L sub-LSP. 367 The rules of the processing of the Attribute Flags TLV of the 368 LSP_ATTRIBUTES object follow [RFC5420]. 370 4.2. P2MP-TE Re-merge Present Flag 372 The "P2MP-TE Re-merge Present" Flag is the counter part of the 373 "P2MP-TE Re-merge Recording Request" flag defined above. 374 Specifically, RSVP signaling extension is defined to indicate to the 375 upstream node of the re-merge condition and that incoming traffic is 376 being dropped for the given S2L. 378 When a node accepts a re-merge condition by dropping traffic from an 379 incoming interface for an S2L due to the re-merge condition, and if 380 it understands the "P2MP-TE Re-merge Recording Request" in the 381 Attribute Flags TLV of the LSP_ATTRIBUTES object of the Path message, 382 the node MUST set the newly defined "P2MP-TE Re-merge Present" flag 383 in the RRO Attributes sub-object defined in [RFC5420] in RRO. 385 The following new flag for RRO Attributes Sub-object is defined as 386 follows: 388 Bit Number (same as bit number assigned for "P2MP-TE Re-merge 389 Recording Request" flag): P2MP-TE Re-merge Present flag 391 The "P2MP-TE Re-merge Present" flag indicates that the S2L is causing 392 a re-merge. The re-merge has been accepted but the incoming traffic 393 on this S2L is dropped by the reporting node. 395 The rules of the processing of the RRO Attribute Sub-object in the 396 Resv message follow [RFC5420]. 398 4.3. Signaling Procedure 400 When a node that does not support data plane based re-merge handling 401 receives an S2L sub-LSP Path message with LSP Attributes sub-object 402 that has "P2MP-TE Re-merge Recording Request" Flag set, and if the 403 S2L is causing a re-merge condition, the node MUST reject the S2L 404 sub-LSP Path message and send the PathErr with the error code 405 "Routing Problem" and the error value "ERO resulted in re-merge" as 406 specified in [RFC4875]. If a node is capable of data plane based re- 407 merge handling but operator may have disabled it via a configuration, 408 the the node MUST also reject the re-merge and send this PathErr. 410 When a Path message is received at a transit node for an S2L sub-LSP 411 and "P2MP-TE Re-merge Recording Request" Flag is set in the LSP 412 Attributes sub-object, the node MAY decide to accept the re-merge S2L 413 sub-LSP based on the local policy and node capability. In this case, 414 before the Resv message is sent to the upstream node for this S2L 415 sub-LSP, the node MUST add the RRO Attributes sub-object in the Resv 416 RRO if not already present and set the "P2MP-TE Re-merge Present" 417 Flag if traffic from the incoming interface of this S2L sub-LSP will 418 be dropped. This same incoming interface can still be used for a 419 different S2L sub-LSP in the P2MP LSP to forward traffic and "P2MP-TE 420 Re-merge Present" flag will not be set for that S2L sub-LSP. Note 421 that rules for adding or modifying the other RRO sub-objects do not 422 change due to this flag. 424 When a transit node receives a Resv message for an S2L that is 425 causing a re-merge condition, the node MUST set the "P2MP-TE Re-merge 426 Present" flag in the RRO Attributes sub-object in the Resv message if 427 it decides to drop the incoming traffic of this S2L. The "P2MP-TE Re- 428 merge Present" flag in RRO Attribute sub-object is not set for the 429 S2L(s) whose incoming interface is selected to receive and forward 430 the traffic. 432 An ingress node MAY immediately start sending traffic on all S2Ls in 433 up state even when re-merge conditions are present on some S2Ls of 434 the P2MP LSP. 436 The proposed signaling extensions allow an ingress node and an 437 ingress border node to have a complete view of the re-merge 438 conditions on the entire S2L path and on all S2Ls of the P2MP tree. 439 The ingress or ingress border node in this case can take appropriate 440 actions to resolve the re-merge conditions and optimize network 441 bandwidth resources usage. This can be achieved by computing and 442 selecting alternate path(s) for the S2L(s) bypassing the re-merge 443 node(s). 445 The proposed signaling extensions are equally applicable to single 446 domain scenarios. 448 A node where re-merge is present, may decide to select a different 449 incoming interface to forward traffic from in the future. In that 450 case, a Resv change message with updated "P2MP-TE Re-merge Present" 451 flag in the RRO is sent upstream for all effected S2Ls. For the new 452 set of S2L sub-LSPs whose traffic from the incoming interface is 453 dropped, "P2MP-TE Re-merge Present" flag will bet set. 455 A border node due to local policy MAY remove the record route object 456 from the Resv message of the S2L sub-LSP and propagate Resv message 457 towards the ingress node. When such a policy is provisioned, the 458 border node may attempt to correct the re-merge condition in its 459 domain. If the border node is not able to resolve the re-merge 460 condition, the border node SHOULD send the PathErr with the error 461 code "Routing Problem" and the error value "ERO resulted in re-merge" 462 as specified in [RFC4875]. 464 5. Intra-domain P2MP-TE LSP Re-merge Handling 466 Re-merges between S2Ls in a single domain can occur due to 467 provisioning errors or path computation errors in the environment 468 where IGP-TE or PCE is used. Re-merges can also happen in the 469 environment where static routing or static path selection policy is 470 applied at ingress (e.g., CSPF calculation is disabled due to some 471 operational reasons), regardless of using loose or static hops. In 472 either case, procedures described in this document are equally 473 applicable to the intra-domain (i.e. single domain) P2MP-TE LSPs. 475 6. Reoptimization Handling 477 6.1. P2MP-TE Tree Re-evaluation Request Flag 479 In order to query border nodes to check if a preferable P2MP tree 480 exists, a new flag is defined in Attributes Flags TLV of the 481 LSP_ATTRIBUTES object [RFC5420] as follows: 483 Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation 484 Request flag 486 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 487 message of an S2L sub-LSP and is inserted by the ingress node. 489 6.2. Preferable P2MP-TE Tree Exists sub-code 491 In order to indicate to an ingress node that a preferable P2MP-TE 492 tree is available, following new sub-code for PathErr code 25 (Notify 493 Error) [RFC3209] is defined: 495 Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists 496 sub-code 498 When a preferable P2MP-TE tree is found, the border node MUST send 499 "Preferable P2MP-TE Tree Exists" PathErr to the ingress node in order 500 to reoptimize the entire P2MP LSP. 502 6.3. Signaling Procedure 504 Using signaling procedure defined in [RFC4736], an ingress node MUST 505 initiate "path re-evaluation request" query to reoptimize a 506 destination in a P2MP LSP. Note that this message MUST be used to 507 reoptimize a single or a sub-set of the destinations in a P2MP LSP. 508 Ingress node MUST send this query in a Path message for each 509 destination it is reoptimizing. 511 When a Path message for a destination in a P2MP LSP with "path 512 re-evaluation request" flag [RFC4736] is received at the border node, 513 it MUST re-compute the loose-hop ERO to see if a preferable path 514 exists for that destination. A border node MUST send PathErr code 25 515 (notify error defined in [RFC3209]) with "preferable path exists" 516 sub-code to indicate that a preferable path exists for the requested 517 destination AND border node is capable of per destination 518 reoptimization. A border node MUST terminate the path query. 519 Alternatively, a border node not capable of per destination 520 reoptimization MAY respond with "Preferable P2MP-TE Tree Exists" 521 PathErr by checking for a preferable P2MP tree instead of a 522 preferable single destination. 524 It is often desired to reoptimize the entire P2MP LSP. In order to 525 query border nodes to check if a preferable P2MP tree exists, an 526 ingress node MUST send a Path message with "P2MP-TE Tree 527 Re-evaluation Request" defined in this document. An ingress node MAY 528 send this message for all destinations in a P2MP LSP or a sub-set of 529 the destinations. 531 A border node receiving the "P2MP-TE Tree Re-evaluation Request" MUST 532 check for a preferable P2MP LSP for the destinations it is loosely 533 routing by loose-hop ERO expansions. The border node if a preferable 534 P2MP-TE tree is found, MUST reply with "Preferable P2MP-TE Tree 535 Exists" sub-code defined in this document with PathErr 25 (notify 536 error defined in [RFC3209] and terminate the path query. 538 Note that a border node MAY send "Preferable P2MP-TE Tree Exists" 539 with PathErr code 25 to indicate the ingress node in order to 540 reoptimize the entire P2MP LSP message unsolicited or in a response 541 to "path re-evaluation query" for a destination or in a response to 542 "P2MP-TE Tree Re-evaluation Request" message. 544 If an ingress node initiated a "path re-evaluation request" query for 545 a single destination for per S2L sub-LSP reoptimization and receives 546 "Preferable P2MP-TE Tree Exists" PathErr, the ingress node MAY cancel 547 the per S2L reoptimization and initiate P2MP-TE tree reoptimization. 548 This may happen in case when a border node is not capable of per 549 destination reoptimization. 551 Note that even if per destination reoptimization, not whole P2MP LSP 552 Tree reoptimization, is sufficient, ingress node often needs to re- 553 signal whole P2MP LSP tree to complete route optimization for that 554 destination. In this case, make-before-break reoptimization scheme is 555 used (see [RFC4875] Section 14.1), and all S2L sub-LSPs are re- 556 signaled with a different LSP-ID. That is, the procedure of signaling 557 a re-optimization by an ingress node is separate from the matter if 558 PathErr reply was "Preferable Path Exists" or "Preferable P2MP-TE 559 Tree Exists". 561 7. Compatibility 563 The LSP_ATTRIBUTES TLV and RRO Attributes sub-object have been 564 defined [RFC5420] with class numbers in the form 11bbbbbb, which 565 ensures compatibility with non- supporting nodes. Per [RFC2205], 566 nodes not supporting this extension will ignore the TLV, sub-object 567 and the new flags defined in this document but forward it, unexamined 568 and unmodified, in all messages resulting from this message. 570 8. Security Considerations 572 This document does not introduce any additional security issues above 573 those identified in [RFC3209], [RFC4875], [RFC5151], [RFC4920] and 574 [RFC5920]. 576 9. IANA Considerations 578 IANA maintains a name space for RSVP-TE TE parameters "Resource 579 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters". From 580 the registries in this name space "Attribute Flags" and "Record Route 581 Object Sub-object Flags" allocation of new flags are requested 582 (sections 9.1 - 9.3). 584 IANA also maintains a name space for RSVP protocol parameters 585 "Resource Reservation Protocol (RSVP) Parameters". From the sub- 586 registry "Sub-Codes - 25 Notify Error" in registry "Error Codes and 587 Globally-Defined Error Value Sub-Codes" allocation of a new error 588 code is requested (section 9.4). 590 9.1 P2MP-TE Re-merge Recording Request Flag 592 The following new flag is defined for the Attributes Flags TLV in the 593 LSP_ATTRIBUTES object [RFC5420]. The numeric values are to be 594 assigned by IANA. 596 o P2MP-TE Re-merge Recording Request Flag: 598 - Bit Number: To be assigned by IANA. 600 - Attribute flag carried in Path message: Yes 602 - Attribute flag carried in Resv message: No 604 9.2 P2MP-TE Tree Re-evaluation Request Flag 606 The following new flag is defined for the Attributes Flags TLV in the 607 LSP_ATTRIBUTES object [RFC5420]. The numeric values are to be 608 assigned by IANA. 610 o P2MP-TE Tree Re-evaluation Request Flag: 612 - Bit Number: To be assigned by IANA. 614 - Attribute flag carried in Path message: Yes 616 - Attribute flag carried in Resv message: No 618 9.3 P2MP-TE Re-merge Present Flag 620 The following new flag is defined for the RRO Attributes sub-object 621 in the RECORD_ROUTE object [RFC5420]. The numeric values are to be 622 assigned by IANA. 624 o P2MP-TE Re-merge Present Flag: 626 - Bit Number: To be assigned by IANA. 628 - Attribute flag carried in Path message: No 630 - Attribute flag carried in RRO Attributes sub-object in RRO of 631 the Resv message: Yes 633 9.4 Preferable P2MP-TE Tree Exists sub-code 635 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC object 636 corresponds to a Notify Error PathErr. This document adds a new sub- 637 code as follows for this PathErr: 639 o Preferable P2MP-TE Tree Exists sub-code: 641 - Sub-code for Notify PathErr code 25. To be assigned by 642 IANA. 644 10. Acknowledgments 646 The authors would like to thank N. Neate for his contributions on the 647 draft. 649 11. References 651 11.1. Normative References 653 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 654 "Extensions to Resource Reservation Protocol Traffic 655 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 656 Switched Paths (LSPs)", RFC 4875, May 2007. 658 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 659 MPLS and GMPLS Traffic Engineering -- Resource Reservation 660 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 661 5151, February 2008. 663 [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and 664 G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS 665 RSVP-TE", RFC 4920, July 2007. 667 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS 668 Networks", RFC 5920, July 2010. 670 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 671 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 672 Tunnels", RFC 3209, December 2001. 674 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 675 Multiprotocol Label Switching (MPLS) Traffic Engineering 676 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 677 November 2006. 679 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 680 Ayyangarps, "Encoding of Attributes for MPLS LSP 681 Establishment Using Resource Reservation Protocol Traffic 682 Engineering (RSVP-TE)", RFC 5420, February 2009. 684 11.2. Informative References 686 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 687 Inter-Domain Multiprotocol Label Switching Traffic 688 Engineering", RFC 4726, November 2006. 690 Author's Addresses 692 Zafar Ali 693 Cisco Systems 695 Email: zali@cisco.com 697 Rakesh Gandhi 698 Cisco Systems 700 Email: rgandhi@cisco.com 702 Tarek Saad 703 Cisco Systems 705 Email: tsaad@cisco.com 707 Robert H. Venator 708 Defense Information Systems Agency 710 Email: robert.h.venator.civ@mail.mil 712 Yuji Kamite 713 NTT Communications Corporation 715 Email: y.kamite@ntt.com