idnits 2.17.1 draft-ietf-pce-stateful-interdomain-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 (4 March 2022) is 777 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: 'RFC8126' is mentioned on line 1465, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Computation Element Working Group O.D. Dugeon 3 Internet-Draft J.M. Meuric 4 Intended status: Standards Track Orange Labs 5 Expires: 5 September 2022 Y.L. Lee 6 Samsung Electronics 7 D.C. Ceccarelli 8 Ericsson 9 4 March 2022 11 PCEP Extension for Stateful Inter-Domain Tunnels 12 draft-ietf-pce-stateful-interdomain-03 14 Abstract 16 This document specifies how to use a Backward Recursive or 17 Hierarchical method to derive inter-domain paths in the context of 18 stateful Path Computation Element (PCE). The mechanism relies on the 19 PCInitiate message to set up independent paths per domain. Combining 20 these different paths together enables them to be operated as end-to- 21 end inter-domain paths, without the need for a signaling session 22 between inter-domain border routers. For this purpose, this document 23 defines a new Stitching Label, new Association Type, and a new PCEP 24 communication Protocol (PCEP) Capability. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 5 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 62 2. Stitching Label . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 64 2.2. Inter-domain traffic steering . . . . . . . . . . . . . . 8 65 2.2.1. Stitching RSVP-TE . . . . . . . . . . . . . . . . . . 9 66 2.2.2. Stitching Segment Routing . . . . . . . . . . . . . . 9 67 2.2.3. Strict traffic steering . . . . . . . . . . . . . . . 10 68 2.3. Inter-domain Flags for TE-PATH-BINDING TLV . . . . . . . 11 69 2.4. Operations . . . . . . . . . . . . . . . . . . . . . . . 11 70 3. Backward Recursive PCInitiate Procedure . . . . . . . . . . . 12 71 3.1. Mode of Operation . . . . . . . . . . . . . . . . . . . . 13 72 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 3.3. Completion Failure of Inter-domain Path Setup 74 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 18 75 4. Hierarchical PCInitiate Procedure . . . . . . . . . . . . . . 18 76 4.1. Mode of Operation . . . . . . . . . . . . . . . . . . . . 19 77 4.2. Completion Failure of Inter-domain Path Setup 78 Procedure . . . . . . . . . . . . . . . . . . . . . . . . 21 79 4.3. Example for Stateful H-PCE Stiching Procedure . . . . . . 22 80 5. Inter-domain Path Management . . . . . . . . . . . . . . . . 25 81 5.1. Stitching Label PCE Capabilities . . . . . . . . . . . . 25 82 5.2. Identification of Inter-domain Paths . . . . . . . . . . 26 83 5.3. Inter-domain Association Group . . . . . . . . . . . . . 27 84 5.4. Modification of Inter-domain Paths . . . . . . . . . . . 28 85 5.5. Modification of Local Paths . . . . . . . . . . . . . . . 29 86 5.6. Tear-Down of Inter-domain Paths . . . . . . . . . . . . . 29 87 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 29 88 6.1. Mixing Technologies . . . . . . . . . . . . . . . . . . . 30 89 6.2. Inter-Area . . . . . . . . . . . . . . . . . . . . . . . 30 90 6.3. Nested traffic . . . . . . . . . . . . . . . . . . . . . 31 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 92 7.1. TE-PATH-BINDING flag . . . . . . . . . . . . . . . . . . 31 93 7.2. Association Type Value . . . . . . . . . . . . . . . . . 32 94 7.3. PCEP Error Values . . . . . . . . . . . . . . . . . . . . 32 95 7.4. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 33 96 7.5. Stitching Label PCE Capability . . . . . . . . . . . . . 33 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 99 10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 34 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 101 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 102 11.2. Informative References . . . . . . . . . . . . . . . . . 35 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 105 1. Introduction 107 The PCE working group has produced a set of RFCs to standardize the 108 behavior of the Path Computation Element ([RFC4655] and [RFC5440]) as 109 a tool to help MultiProtocol Label Switching - Traffic Engineering 110 (MPLS-TE)/Generalized MPLS (GMPLS) Label Switched Paths (LSPs) and 111 Segment Routing paths placement. This also includes the ability to 112 compute inter-domain LSPs or Segment Routing paths following a 113 distributed BRPC [RFC5441] or hierarchical H-PCE [RFC6805] approach. 114 Such inter-domain paths could then serve as an Explicit Route Object 115 (ERO) input for the RSVP-TE signaling to set up the tunnels within 116 the underlying network. Three kinds of inter-domain paths could be 117 established: 119 * Contiguous tunnel ([RFC3209] and [RFC3473]): The RSVP-TE signaling 120 crosses the boundary between two domains. This kind of tunnel is 121 not recommended mostly for security and scalability purpose. In 122 addition, the initiating domain imposes huge constraints on 123 subsequent domains, because they undergo the tunnel request 124 without being able to control it. 126 * Stitching tunnel ([RFC5150]): Each domain establishes in its own 127 network the corresponding part of the inter-domain path 128 independently. Then, a second end-to-end RSVP-TE Path message is 129 sent by the initiating domain to stitch the different tunnel parts 130 to form the inter-domain path. 132 * Nesting tunnel ([RFC4206]): This is similar to the stitching mode 133 but, this time, with the possibility to set up tunnel hierarchy. 135 However, these inter-domain paths depend on signaling using RSVP-TE 136 to be set up, but it is not common to allow signaling across 137 administrative domain borders, especially in operational networks. 139 For Segment Routing, issues are different as there is no signaling 140 between routers. First, a segment path depends on a stack of segment 141 identifiers but, in an inter-domain path, this stack may become too 142 large with respect to hardware constraint. If Extensions for Segment 143 Routing [RFC8664] takes into account the Maximum Stack Depth (MSD), a 144 PCE may be unable to find a solution when it computes an end-to-end 145 inter-domain path. The second issue is related to the path 146 confidentiality because all Node-SID must be stacked by the head end 147 router while some of the Node-SIDs are associated to routers of the 148 next domains. It is clear that operators would not disclose details 149 of their network, which includes Node-SIDs. Thus, it is not possible 150 to stack remote labels for an end-to-end inter-domain path even if 151 MSD constraint is respected. 153 The purpose of this document is to take the benefit of Active 154 Stateful PCE [RFC8231] and PCE-Initiated [RFC8281] modes to stitch or 155 nest inter-domain paths directly using PCEP between domains' PCEs 156 while avoiding the use of another signaling between inter-domain 157 border nodes. The mechanism keeps each operator free to 158 independently set up their respective part of the inter-domain paths, 159 i.e. the signaling (for MPLS-TE and GMPLS) is scoped on a per domain 160 basis, individually. 162 The PCInitiate message is used from destination domain to source 163 domain, to recursively set up the end-to-end tunnel. Binding Label / 164 Segment Identifier (BSID) [I-D.ietf-pce-binding-label-sid] is used to 165 convey the specific labels or SIDs to automatically stitch or nest 166 the different local LSPs. And PCRep in conjunction with PCUpd 167 messages are used to report, maintain, modify and tear down inter- 168 domain paths. This method is also applicable to Segment Routing to 169 build inter-domain segment paths. To enable this mechanism, this 170 document defines a new Stitching Label, new Association Type, and a 171 new PCEP communication Protocol (PCEP) Capability. 173 1.1. General Assumptions 175 In the remainder of this document, the same references as per BRPC 176 [RFC5441] are used and the following set of assumptions are made (see 177 figure below): 179 * Domain refers to administrative partitions, i.e. an IGP area or an 180 Autonomous System (AS). 182 * Inter-domain path is used to refer to a path that crosses two or 183 more different domains as defined previously, 185 * At least one PCE is deployed in each domain. These PCEs are all 186 active stateful-capable and can request to enforce LSPs in their 187 respective domain by means of PCInitiate messages. 189 * LSRs, including border nodes, are PCC-enabled and support active 190 stateful mode. PCEP sessions are established between these 191 routers and their domains' PCE. 193 * Each PCE establishes a PCEP session with its respective neighbor 194 domains' PCEs. The way a PCE discovers its neighboring PCEs is 195 out of the scope of this document. 197 * Each PCC is able to configure a Binding Label/Segment Identifier 198 (BSID) and each PCE is able to request a BSID to a PCC or a 199 neighbor domains' PCE. 201 * PCEs are able to compute an end-to-end path as per BRPC procedure 202 [RFC5441] or as per H-PCE procedure (stateless [RFC6805] or 203 stateful [RFC8751]). 205 * "Path" is a generic term to refer to both LSP setup by mean of 206 RSVP-TE or Segment Path in a Segment Routing network. 208 ...(H-PCE)........................... 209 . . . 210 . . . 211 -------------- -------------- -------------- 212 |Domain-A . | | . Domain-B| | . Domain-C| 213 | . | | . | | . | 214 | PCE------+--PCEP---+---PCE--------+--PCEP---+---PCE | 215 | / | | / | | / | 216 | / | | / | | / | 217 | Src=========BNA-------BNB1===========BNB2------BNC=========Dst | 218 | | Inter- | | Inter- | | 219 -------------- Domain -------------- Domain -------------- 220 Link Link 222 Figure 1: Example of the representation of 3 domains with 3 PCEs 224 Operations, according to the figure above, are as follow: 226 1. The PCEs in Domain-A, Domain-B, and Domain-C communicate using 227 PCEP either directly, as shown, using BRPC or with a parent PCE 228 if using H-PCE. 230 2. The PCE in Domain-A selects an end-to-end domain path. It tells 231 the PCE in Domain-B that the path will be used, and that PCE 232 passes the information on to the PCE in Domain-C. 234 3. Each of the PCEs use PCEP to instruct the segment head ends 235 backward from destination to source: 237 a. In Domain-C, the PCE instructs the ingress Border Node, BNC, 238 with the path to reach the Destination. The instructions 239 also ask BNC to provide the incoming label or SID that will 240 be stitched to the intra-domain path. Once done, PCE reports 241 this label or SID to PCE of Domain-B. 243 b. In Domain-B, the PCE instructs the ingress Border Node, BNB1, 244 with the path to reach the egress Border Node, BNB2. The 245 instructions also tell BNB1 the label or SID to use on the 246 inter-domain link to BNC and ask to provide the incoming 247 label or SID that will be stitched to the intra-domain path. 248 Once done, PCE reports this label or SID to PCE of Domain-A. 250 c. In Domain-A, the PCE instructs the Source node with the path 251 to use to reach Border Node, BNA. The instructions also 252 include the label or SID to use on the inter-domain link to 253 BNB1. 255 1.2. Terminology 257 ABR: Area Border Routers. Routers used to connect two IGP areas 258 (areas in OSPF or levels in IS-IS). 260 AS: Autonomous System 262 ASBR: Autonomous System Border Router. Router used to connect 263 together ASes (of the same or different service providers) via one or 264 more inter-AS links. 266 BSID: Binding Label / Segment Identifier. 268 Border Node (BN): a boundary node is either an ABR in the context of 269 inter-area TE or an ASBR in the context of inter-AS TE. 271 BN-en(i): Entry BN of domain(i) connecting domain(i-1) to domain(i) 272 along a determined sequence of domains. Multiple entry BN-en(i) 273 could be used to connect domain(i-1) to domain(i). 275 BN-ex(i): Exit BN of domain(i) connecting domain(i) to domain(i+1) 276 along a determined sequence of domains. Multiple exit BN-ex(i) could 277 be used to connect domain(i) to domain(i+1). 279 Domains: Autonomous System (AS) or IGP Area. An Autonomous System is 280 composed by one or more IGP area. 282 ERO(i): The Explicit Route Object scoped to domain(i) 283 IGP-TE: Interior Gateway Protocol with Traffic Engineering support. 284 Both OSPF-TE and IS-IS-TE are identified in this category. 286 Inter-domain path: A path that crosses two or more domains through a 287 pair of Border Node (BN-ex, BN-en). 289 LK(i): A Link that connect BN-ex(i-1) to BN-en(i). Note that BN- 290 ex(i-1) could be connected to BN-en(i) by more than one link. LK(i) 291 identifies which of the multiple links will be used for the inter- 292 domain path setup. For inter-AS scenario, LK(i) represents the link 293 between ASBR of domain i to the ASBR of domain i-1. For inter-area 294 scenario, LK(i) is present only in IS-IS networks and represents the 295 link between ABR of region L1, reciprocally L2, to the ABR of region 296 L2, reciprocally L1. 298 Local path: A path that does not cross a domain border. It is set up 299 either from entry BN-en, to output BN-ex or between both. This path 300 could be enforce by means of RSVP-TE signaling or Segment Routing 301 labels stack. 303 Local path(i): A Local path of domain(i) 305 PLSP-ID(i): A PLSP-ID that identifies, in the domain(i), the local 306 part of an inter-domain path. 308 PCE: Path Computation Element. An entity (component, application, or 309 network node) that is capable of computing a network path or route 310 based on a network graph and applying computational constraints. 312 PCE(i) is a PCE within the scope of domain(i). 314 R(i,j): The router j of domain i 316 Stitching Label (SL): A dedicated label that is used to stitch two 317 RSVP-TE LSPs or two Segment Routing paths. 319 SL(i): A Stitching Label that links domain(i-1) to domain(i) and is 320 conveyed as an inter-domain BSID. 322 TPB(): An empty TE-PATH-BINDING TLV to request an inter-domain BSID 323 i.e. a Stitching Label. 325 TPB(i): A TE-PATH-BINDING TLV with an inter-domain Binding Value 326 equal to the Stitching Label SL(i). 328 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 329 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 330 document are to be interpreted as described in RFC 2119 [RFC2119]. 332 2. Stitching Label 334 This section introduces the concept of Stitching Label that allows 335 stitching and nesting of local paths in order to form an inter-domain 336 path that cross several different domains. 338 2.1. Definition 340 The operation of stitch or nest a local path(i) to a local path(i+1) 341 in order to form and inter-domain path mainly consists in defining 342 the label that the output BN-ex(i) will use to send its traffic to 343 the entry BN-en(i+1). Indeed, the entry BN-en(i+1) needs to identify 344 the incoming traffic (e.g. IP packets), in order to know if this 345 traffic must follow the local path(i+1) or not. Forwarding 346 Equivalent Class (FEC) could be used for that purpose. But, when 347 stitching or nesting tunnels, the FEC is reduced to the incoming 348 label that the entry BN-en(i+1) has chosen for the local path(i+1). 350 In this document, we introduce the term of "Stitching Label (SL)" to 351 refer to this label. Such label is usually exchanged between output 352 BN-ex(i) and entry BN-en(i+1) with the RSVP-TE signaling. But, as we 353 want to avoid to use RSVP-TE signaling due to operational 354 constraints, and allow compatibility support for Segment Routing, 355 this Stitching Label is here conveyed by PCEP. Binding Label / 356 Segment Identifier (BSID) [I-D.ietf-pce-binding-label-sid] defines a 357 new TE-PATH-BINDING TLV to exchange a Binding Segment / Label 358 Identifier (BSID) between a PCC and a PCE. This BSID is then used to 359 steer incoming traffic using this BSID into the associated path. 360 Thus, the Stitching Label defines in this draft is a particular use 361 case of BSID, named inter-domain BSID, and could be conveyed in the 362 TE-PATH-BINDING TLV of the LSP Object without any modification of 363 PCEP nor PCEP Objects. 365 2.2. Inter-domain traffic steering 367 If BSID allows to automatically steer traffic identified with this 368 BSID into the associated path, for inter-domain BSID, it is different 369 as the Stitching Label is associated to the inter-domain link LK(i+1) 370 i.e. the link between the border node BN-ex(i) of the domain(i) and 371 the border node BN-en(i+1) of the domain(i+1). Indeed, the Border 372 Node BN-en(i+1) needs to received the traffic identified by the 373 Stitching Label SL(i+1) from BN-ex(i). Thus, it is necessary to 374 instruct the border node BN-ex(i) to push the Stitching Label(i+1) on 375 top of the packets of traffic going from domain(i) to domain(i+1), 376 and send them to the border node BN-en(i+1) through the inter-domain 377 link LK(i+1). Depending of technology used by domain(i), RSVP-TE or 378 Segment Routing, the operation uses two different approaches. 380 .-,( ),-. .-,( ),-. 381 +----+ .-( ) +----+ LK(i+1) +----+ ( )-. 382 | BN |( Domain(i) )| BN |------------| BN |( Domain(i+1 ) 383 +----+ '-( ) +----+ SL(i+1) +----+ ( ).-' 384 | '-.( ).-' | | '-.( ).-' 385 BN-en(i) BN-ex(i) BN-en(i+1) 387 Figure 2: Inter-domain Link 389 2.2.1. Stitching RSVP-TE 391 In case of RSVP-TE, the Border Node BN-ex(i) needs to received the 392 Stitching Label from BN-en(i) through the RSVP-TE message and install 393 in its L(F)IB a SWAP instruction to the Stitching Label and forward 394 it to the next Border Node BN-en(i+1). For that purpose, the Egress 395 Control mechanism, as per RFC4003 section 2.1 [RFC4003], is 396 RECOMMENDED to instruct the Border Node BN-ex(i) of this action. 397 Other mechanisms to program the L(F)IB could be used, e.g. NETCONF. 399 Thus, PCE(i) SHOULD provide SL(i+1) and LK(i+1) to the PCC BN-en(i) 400 through the ERO = {..., [LK(i+1), SL(i+1)]} as the last SubObject in 401 conformance to [RFC4003]. As a result, BN-ex(i) installs in its MPLS 402 L(F)IB the SWAP instruction to label SL(i+1) with forward to LK(i+1). 403 It is left to implementation of PCE to get the LK(i+1) value. One 404 solution consist to retrieve it from the PKS(i) or the ERO previously 405 computed during the BRPC process. 407 2.2.2. Stitching Segment Routing 409 In case of Segment Routing, the Stitching Label SL(i+1) will be 410 inserted into the label stack in order to become the top label in the 411 stack when the packet reaches BN-en(i+1). Thus, the Stitching Label 412 SL(i+1) serves as a Binding SID entry for BN-en(i+1) to identify the 413 packets that follow the next Segment Path. For that purpose, BN- 414 en(i) MUST install in its MPLS L(F)IB an instruction to replace the 415 incoming Stitching Label SL(i) by the label stack given by the ERO(i) 416 plus the Stitching Label SL(i+1). 418 When a packet reaches BN-ex(i), the last label in the stack before 419 the label SL(i+1) corresponds to a SID that allows to reach BN- 420 en(i+1). When there are multiple interfaces between Border Nodes, 421 BN-ex(i) needs to know how to send the packets to BN-en(i+1). 422 Similarly to the Egress Control mechanism used with RSVP-TE, it is 423 RECOMMENDED to use the inter-domain SID defined as per draft Egress 424 Peer Engineering [RFC9086] for that purpose. The inter-domain SID 425 named here I-SID(i+1) is announced by BN-ex(i) to PCE(i) through BGP- 426 LS for each interface that connect BN-ex(i) to neighbors BN-en(i+1). 427 Thus, PCE(i) SHOULD provide SL(i+1) and I-SID(i+1) to the PCC BN- 428 en(i) through the EROso that the label stack will end with {BN-ex(i) 429 SID, I-SID(i+1), SL(i+1)} and should be processed as follows: 431 * The penultimate router of domain(i) pops its node SID, and sends 432 the packet to the next node designated by the top label in the 433 label stack, i.e. the node SID of BN-ex(i) or the adjacency SID of 434 the link between the router and BN-ex(i). 436 * BN-ex(i) pops its node SID or its adjacency SID and looks up the 437 next label in the stack, i.e. the inter-domain SID which 438 corresponds to the interface to BN-en(i+1). BN-ex(i) pops this 439 inter-domain SID as well and sends the packet to BN-ex(i) through 440 the corresponding interface. 442 * BN-en(i+1) looks up the top label which is the Stitching Label 443 SL(i+1), pops it and replaces it by the sub-sequent label stack. 445 Other mechanisms, e.g. NETCONF, could be used to configure the 446 inter-domain SID on exit Border Nodes. 448 2.2.3. Strict traffic steering 450 The Binding Label / Segment Identifier has been defined as a global 451 traffic steering identifier. Thus, if an entry border node BN-en(i) 452 is configured with a Stitching Label SL(i), any domain connected to 453 this border node through different interface could send traffic to 454 domain(i) and subsequent domains even if they are not part of the 455 inter-domain path. However, some operators would prefer to configure 456 a strict enforcement of traffic steering. In this case, the border 457 node BN-en(i) SHOULD restrict the MPLS L(F)IB configuration to accept 458 traffic with the Stitching Label SL(i) to the incoming link LK(i). 460 2.3. Inter-domain Flags for TE-PATH-BINDING TLV 462 In order to convey the Stitching Label and manage traffic steering at 463 inter-domain, this specification defines new flags (See IANA section 464 of this document) for the Binding Label / Segment Identifier. The 465 format of the TE-PATH-BINDING TLV is defined in Binding Label / 466 Segment Identifier (BSID) [I-D.ietf-pce-binding-label-sid] and 467 included here for easy reference with the addition of the new flags 468 as follow: 470 0 1 2 3 471 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Type = 55 | Length | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | BT |R|I|S| Flags | Reserved | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 ~ Binding Value (variable length) ~ 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 3: TE-PATH-BINDING TLV 482 * I flag: Inter-Domain Binding indicates that this Binding Value 483 corresponds to an inter-domain path, thus that this Binding Value 484 is a Stitching Label. 486 * S flag: Strict Binding indicates that the PCC MUST restrict the 487 Binding Value to the interface that corresponds to the domain 488 source End-Point of the associated path and MUST reject incoming 489 traffic with this Binding Value when it reaches the PCC through 490 another interface. 492 2.4. Operations 494 An empty TE-PATH-BINDING TLV with the I flag set to 1 MUST be present 495 in a PCInitiate messages sent by a PCE(i-1) to its neighbor PCE(i) in 496 the Backward Recursive method or by the Parent PCE to the Child 497 PCE(i) to initiate a new inter-domain path. In its response, the 498 neighbor PCE(i) or Child PCE(i) MUST return a Stitching Label SL in 499 the TE-PATH-BINDING TLV with the I flag set in the LSP object of the 500 PCRpt message to PCE(i-1) or the Parent PCE. PCE(i-1) MUST NOT 501 provide a Stitching Label as a Binding Value of the TE-PATH-BINDING 502 TLV to its neighbor PCE(i). 504 An empty TE-PATH-BINDING TLV with the I flag set to 1 MUST be present 505 in the PCInitiate message sent by a PCE(i) requesting to a PCC of 506 domain(i) to initiate a new local path(i) which is part of an inter- 507 domain path. The I flag MUST be set by the PCE(i) only after 508 receiving a PCInitiate message with an empty TE-PATH-BINDING with the 509 I flag set from a neighbor PCE(i-1) in the Backward Recursive method 510 or Parent PCE in the Hierarchical method. In its response, the PCC 511 of domain(i) MUST return a Stitching Label SL in the TE-PATH-BINDING 512 TLV with the I flag set in the LSP object of the PCRpt message. 513 Alternatively, the PCE(i) could provide a Stitching Label as a 514 Binding Value of the TE-PATH-BINDING TLV with the I flag set to the 515 PCC of the domain(i) when initiating a new local path(i) as per 516 section #8 of draft Binding Label / Segment Identifier (BSID) 517 [I-D.ietf-pce-binding-label-sid]. If the PCC is not able to allocate 518 a BSID for inter-domain, it MUST send a PCErr message with Error-Type 519 = "Binding label/SID failure" and Error-Value = "Unable to allocate a 520 new binding label/SID" defined in draft Binding Label / Segment 521 Identifier (BSID) [I-D.ietf-pce-binding-label-sid]. 523 If a PCE(i) receives a PCRpt without a TE-PATH-BENDING TLV while it 524 has requested a Stitching Label in the PCInitiate message, it MUST 525 send a PCErr message with Error-Type = "Mandatory Object missing"" 526 and Error-Value = TBD2. If a PCE(i) receives a PCRpt with a TE-PATH- 527 BENDING TLV with the I flag unset while it has requested a Stitching 528 Label in the PcInitiate message, it MUST send a PCErr message with 529 Error-Type = "Binding label/SID failure" and Error-Value = TBD3. 531 PCE(i) SHOULD set the S flag in addition to the I flag if it requests 532 traffic steering strictly coming from a given interface, i.e. 533 traffic using the BSID and coming from a different interface MUST be 534 rejected by the PCC. When the S flag is set, PCE(i) MUST set the 535 EndPoint source address of the requested local path with the IP 536 address of the interface where the traffic is strictly steered. When 537 the PCC receives an LSP object with an empty TE-PATH-BINDING TLV and 538 the S flag set, it MUST allocate a Binding Value and configure its 539 MPLS L(F)IB to accept traffic with this BSID only coming from the 540 interface identified by the source address of the EndPoint Object. 541 If the PCC is not be able to strictly steer traffic, it MUST send a 542 PCErr message with Error-Type = "Binding label/SID failure" and 543 Error-Value = "Unable to allocate a new binding label/SID". 545 3. Backward Recursive PCInitiate Procedure 547 This section describes how to set up inter-domain paths that cross 548 different domains by using a Backward Recursive method. It is 549 compatible with the inter-domain path computation by means of the 550 BRPC procedure as describe in RFC5441 [RFC5441]. 552 3.1. Mode of Operation 554 This section describes how PCInitiate and PCRpt messages are combined 555 between PCE in order to set up inter-domain paths between a source 556 domain(1) to a destination domain(n). S and D are respectively the 557 source and destination of the inter-domain path. Domain(1) and 558 domain(n) are different and connected through 0 (i.e. direct 559 connection when n = 2) or more intermediate domains denoted domain(i) 560 with i = [2, n-1]. 562 First, the PCE(1) runs standard BRPC algorithm as per RFC5441 563 [RFC5441] with its neighbor PCEs in order to compute the inter-domain 564 path from S to D, where S and D are respectively a node in the 565 domain(1) and domain(n). Path Key confidentiality as per RFC5520 566 [RFC5520] SHOULD be used to obfuscate the detailed ERO(i) of the 567 different domains(i). The resulting ERO is in the form {S, PKS(1), 568 BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), ..., BN-en(n), PKS(n), D} 569 when Path Key is used and of the form {S, R(1,1), ..., R(1,k), BN- 570 ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), BN-ex(i), ..., BN-en(n), 571 R(n,1), ..., R(n,m), D} otherwise . As subsequent domains are not 572 aware about the computed end-to-end ERO in case of Virtual Source 573 Path trees (VSPTs), the final ERO selected by the PCE(1) MUST be sent 574 in the PCInitiate message to indicate to the subsequent PCEs which 575 path has been finally chosen. PCE(1) MUST ensure that this ERO is 576 self comprehensive by subsequent PCEs. Indeed, when a PCE(i) 577 receives the ERO, it MUST be able to verify that this ERO matches its 578 own scope and be able to determine the next PCE(i+1). When Path Key 579 is used, PCEs MUST encode the Path Key with a reachable IP address so 580 that previous PCEs in the AS chain are able to join them. When Path 581 Key is not used, the PCEs MUST be able to retrieve an IP address of 582 the next PCE corresponding to the ERO (e.g., relying on a per prefix 583 table). 585 The complete procedure with Path Key follows the different steps 586 described below: 588 Steps 1: Initialization 590 Once ERO(S, D) is computed, PCE(1) sends a PCInitiate message to 591 PCE(2) containing an ERO equal to {S, PKS(2), ..., PKS(i), ..., 592 PKS(n), D}, an LSP Object containing an empty TE-PATH-BINDING TLV 593 with the I flag set and the End-Points Object = (S, D). The ERO 594 corresponds to the one PCE(1) has received from PCE(2) during the 595 BRPC process in which only Path Key are kept. In case of multiple 596 EROs, i.e. VSPT, PCE(1) has chosen one of them and used the selected 597 one for the PCInitiate message. PKS(i) could be replaced by the full 598 ERO description if Path Key is not used by PCE(i). 600 When PCE(i) receives a PCInitiate message from domain(i-1) with an 601 LSP containing an empty TE-PATH-BINDING TLV with I flag set and ERO = 602 {PKS(i), PKS(i+1), ..., PKS(n), D)}, it MUST sends the received 603 PCInitiate message to PCE(i+1) with a popped ERO and records its 604 received PKS(i) part. All PCE(i)s MUST generate the appropriate 605 PCInitiate message to PCE(i+1) up to PCE(n), i.e. to the destination 606 domain(n). 608 Steps 2: Actions taken at the destination domain(n) by PCE(n) 610 1. When a PCInitiate message reaches the destination domain(n), 611 PCE(n) retrieves the detailed ERO(n) from the PKS(n) if necessary 612 and MUST send to BN-en(n) a PCInitiate message with the ERO(n) = 613 {BN-en(n), ..., D}, an LSP containing an empty TE-PATH-BINDING 614 TLV with the I flag set and End-Points Object = {BN(n), D} in 615 order to inform the PCC BN-en(n) that this local path(n) is part 616 of an inter-domain service and that it MUST allocate a Binding 617 Value for this path. 619 2. When the PCC BN-en(n) receives the PCInitiate message from its 620 PCE(n), it sets up the local path from entry BN-en(n) to D by 621 means of RSVP-TE signaling or Segment Routing, accordingly to the 622 PST value, with the given ERO(n). 624 3. Once the tunnel is set up, BN-en(n) chooses a free label for the 625 Stitching Label SL(n) and adds a new entry in its MPLS L(F)IB 626 with this SL(n) label. Then, it MUST send a PCRpt message to its 627 PCE(n) including PLSP-ID(n) and a TE-PATH-BINDING TLV with the 628 Binding Value equal to SL(n) and the I flag set 630 4. Once PCE(n) receives the PCRpt from the PCC BN-en(n) with the 631 RRO, PLSP-ID and TE-PATH-BINDING TLV with the I flag set, it MUST 632 send to the PCE(n-1) a PCRpt containing the TE-PATH-BINDING TLV 633 it received from the PCC BN-en(n) and PLSP-ID(n). PCE(n) MAY add 634 {PKS(n), D} in the RRO. 636 Steps i: Actions performed by all intermediate domains(i), for i = 2 637 to n-1 639 1. When the PCE(i) receives a PCRpt message from domain(i+1) with an 640 LSP object containing PLSP-ID(i+1) and a Binding Value in the TE- 641 PATH-BINDIG TLV with the I flag set, it retrieves the detailed 642 ERO(i) from the PKS(i), recorded in step 1, if necessary. Then, 643 it MUST send to the PCC BN-en(i) a PCInitiate message with this 644 ERO(i), an LSP object containing an empty TE-PATH-BINDING TLV 645 with the I flag set and the End-Points Object = {BN-en(i), BN- 646 ex(i)} in order to inform the PCC BN-en(i) that this local 647 path(i) is part of an inter-domain path and that it MUST allocate 648 a Binding Value for this path. PCE(i) sets Path Setup Type (PST) 649 to 0, respectively to 1 to instruct the PCC to enforce the local 650 path by means of RSVP-TE respectively Segment Routing. 652 2. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003] 653 for RSVP-TE, respectively, Egress Peer Engineering [RFC9086] for 654 Segment Routing, is used to stitch and steer traffic between the 655 border node BN-ex(i) and BN-en(i+1). This allow PCE(i) to 656 instruct the egress node of domain(i), i.e. BN-ex(i), to forward 657 packets belonging to this tunnel with the Stitching Label. For 658 that purpose, PCE(i) should identify the link LK(i+1) by 659 retrieving from the PKS(i) the corresponding IP address of the 660 link LK(i+1) for RSVP-TE or from the BGP-LS the label that could 661 be use to reach link LK(i+1) for Segment Routing. As a result, 662 BN-ex(i) installs in its MPLS L(F)IB the SWAP instruction to 663 label SL(i+1) with forward to LK(i+1). Thus, PCE(i) MUST 664 complete the ERO(i), in order to provide the Stitching Label 665 SL(i+1) and Link identifier LK(i+1) to the PCC, as the last hop 666 of the local path i.e. ERO(i) = {ERO(i), [LK(i+1), SL(i+1)]}. 668 3. When the PCC BN-en(i) receives the PCInitiate message from its 669 PCE(i), it sets up the local path from BN-en(i) to BN-ex(i) by 670 means of RSVP-TE signaling or Segment Routing, accordingly to the 671 PST value, with the given ERO(i). 673 4. Once the tunnel is set up, PCC BN-en(i) chooses a free label for 674 the Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 675 with this SL(i) label. Then, it MUST send a PCRpt message to its 676 PCE(i) including PLSP-ID(i) and a TE-PATH-BINDING TLV with the I 677 flag set containing a Binding Value equal to SL(i). 679 5. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 680 PLSP-ID and TE-PATH-BINDING TLV with the I flag set, it MUST send 681 to the PCE(i-1) a PCRpt containing the TE-PATH-BINDING TLV it 682 received from the PCC BN-en(i) and the PLSP-ID(i). PCE(i) MAY 683 add {PKS(i), ..., PKS(n)} in the RRO. 685 Steps n: Actions performed at the source domain(1) by PCE(1) 687 Once PCE(1) receives the PCRpt message from PCE(2) with the TE-PATH- 688 BINDING TLV with the I flag set containing the Binding Value equal to 689 the Stitching Label SL(2), it MUST send a PCInitiate message to PCC 690 node S with ERO equal to {ERO(1), [LK(2), SL(2)]}, once retrieves the 691 identifier of link LK(2), and End-Points Object = {S, BN-ex(1)}. This 692 time, no TE-PATH-BINDING TLV is provided as the PCC S does not need 693 to return a Stitching Label SL, because it is the head-end of the 694 inter-domain path. A usual PCRpt message is sent back to PCE(1) by 695 the PCC node S. 697 3.2. Example 699 In the figure below, two different domains S and D are interconnected 700 through BN respectively BN-S and BN-D. PE-S and PE-D are edge 701 routers. All routers in the figure are connected to their respective 702 PCE through PCEP. In this example, we consider that PCE(S) needs to 703 set up an inter-domain path between PE-S and PE-D acting as source 704 and destination of the path. To simplify the figure, neither 705 intermediate routers between (PE-S, BN-S), (BN-D and PE-D), nor RSVP- 706 TE messages are represented, but they are all presents. The 707 following notation is used (in this example, we use the PKS for the 708 sake of simplicity): 710 * PKS(D) = Path Key corresponding to the path from BN(D) to PE-D 712 * ERO(D) = Explicit Route Object corresponding to the path from 713 BN(D) to PE-D, retrieved from PKS(D) 715 * RRO(D) = Record Route Object of the local path(D) from BN(D) to 716 PE-D 718 * SL(D) = Stitching Label for the local path from BN(D) to PE-D 720 * ERO(S) = Explicit Route Object corresponding to the path from PE-S 721 to BN(S) 723 * RRO(S) = Record Route Object of local path(S) from PE-S to BN(S) 725 * TPB(I) = Empty TE-PATH-BINDING TLV with the I flag set 727 * TPB(I, SL) = TE-PATH-BINDING TLV with Binding Value equal to 728 Stitching Label SL and the I flag set 730 PE-S PCE-S BN-D PCE-D 731 | | | | 732 | [ -------- Standard BRPC exchange ------------] 733 | | | | 734 | | PCInitiate(ERO={PKS(D)}, TPB(I) 735 | | --------------------------------------> | 736 | | | | 737 | | PCInitiate(ERO = ERO(D), TPB(I)) 738 | | | <------- | 739 | | | | 740 | | PCRpt(RRO = {RRO(D)}, TPB(I, SL)) 741 | | | ------> | 742 | | | | 743 | PCRpt(RRO = {PKS(D)}, TPB(I, SL), PLSP-ID(D)) 744 | | <-------------------------------------- | 745 | | | | 746 | PCInitiate(ERO={ERO(S), LK(D), SL(D), BN(D)}) | 747 | <------- | | | 748 | | | | 749 | PCRpt(RRO={RRO(S)}) | | 750 | -------> | | | 751 | | | | 753 +----------------------+ +----------------------+ 754 | | | | 755 | +------+ | PCEP | +------+ | 756 | +---->|PCE(S)|<-------------------------------->|PCE(D)| | 757 | | +------+ | | +------+ | 758 | | ^ | | ^ ^ | 759 | | | | | | | | 760 | |PCEP | | | | | | 761 | | |PCEP | | PCEP | | PCEP | 762 | v | | | | | | 763 (PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D) 764 | | Inter-Domain | | 765 | Domain (S) | Link | Domain (D) | 766 +----------------------+ +----------------------+ 768 [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---] 770 Figure 4: Example of inter-domain path setup between two domains 772 3.3. Completion Failure of Inter-domain Path Setup Procedure 774 In case of error during path setup, PCRpt and or PCErr messages MUST 775 be used to signal the problem to the neighbor PCE domain backward. 776 In particular, if the new I flag of the TE-PATH-BINDING TLV defined 777 in this document is not supported by the neighbor PCE or PCC, the 778 PCE, respectively PCC, MUST return a PCErr message with Error-Type = 779 "Binding label/SID failure" and Error-Value = "Unable to allocate a 780 new binding label/SID" (as per section #12 of draft Binding Label / 781 Segment Identifier (BSID) [I-D.ietf-pce-binding-label-sid]) to its 782 neighbor PCE respectively PCE. 784 If a PCE(i) receives a PCInitiate message from its peer PCE(i-1) 785 without an TE-PATH-BINDING with the I flag set in the LSP object, it 786 MUST return a PCErr message with Error-Type = 24 (LSP instantiation 787 error) and Error-Value = 1 (Unacceptable instantiation parameters) to 788 its peer PCE(i-1). 790 Following a PCInitiate message with an LSP object containing an empty 791 TE-PATH-BINDING TLV with the I flag set, if a neighbor PCE(i+1) or a 792 PCC returns no TE-PATH-BINDING TLV, or a TE-PATH-BINDING TLV without 793 the I flag set, the PCE(i), respectively the PCE(i), MUST return a 794 PCErr message with Error-Type = "Binding label/SID failure" and 795 Error-Value = "Unable to allocate a new binding label/SID". 797 In case of completion failure, the PCE(i) MUST propagate the PCErr 798 message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate 799 message (R flag set in the SRP Object as per [RFC8281]) to tear down 800 this inter-domain path from its neighbor PCEs. PCE(i) MUST propagate 801 the PCInitiate message and remove its local path by means of 802 PCInitiate message to its PCC BN-en(i) and send back PCRpt message to 803 PCE(i-1). 805 In case of error in domain(i+1), PCE(i) MAY add the AS number of 806 domain(i+1) in the RRO to identify the faulty domain. 808 4. Hierarchical PCInitiate Procedure 810 This section describes how to set up inter-domain paths that cross 811 different domains by using a hierarchical method. It is compatible 812 with inter-domain path computation as described in [RFC6805]. 814 4.1. Mode of Operation 816 This section describes how PCInitiate and PCRpt messages are combined 817 between PCEs in order to set up inter-domain paths between a source 818 domain(1) to a destination domain(n). S and D are respectively the 819 source and destination of the inter-domain path. Domain(1) and 820 domain(n) are different and connected through 0 or more intermediate 821 domains denoted domain(i) with i = (2, n-1). Domains are directly 822 connected when n = 2. 824 First, the Parent PCE contacts its Child PCE as per [RFC6805] in 825 order to compute the inter-domain path from S to D, where S and D are 826 respectively a node in the domain(1) and domain(n). Path Key 827 confidentiality as per RFC5520 [RFC5520] SHOULD be used to obfuscate 828 the detailed ERO(i) of the different domains(i). The resulting ERO 829 is of the form (S, PKS(1), BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), 830 ..., BN-en(n), PKS(n), D) when Path Key is used and of the form {S, 831 R(1,1), ..., R(1,k), BN-ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), 832 BN-ex(i), ..., BN-en(n), R(n,1), ..., R(n,m), D} otherwise. 834 The complete procedure with Path Key follow the different steps 835 described below: 837 Step 1: Initialization 839 1. The Parent PCE MUST send a PCInitiate message to Child PCE(n) 840 with an ERO = {PKS(n)} an LSP containing an empty TE-PATH-BINDING 841 TLV with the I flag set and End-Points = {BN-en(n), D}. Then, 842 PCE(n) retrieves the ERO from the PKS(n), if necessary, and MUST 843 send to BN-en(n) a PCInitiate message with the ERO(n) = {BN- 844 en(n), ..., D}, an LSP Object with empty TE-PATH-BINDING TLV with 845 the I flag set and End-Points Object = {BN-en(n), D} in order to 846 inform the PCC BN-en(n) that this local path(n) is part of an 847 inter-domain path and that it MUST allocate a Binding Value for 848 this path. 850 2. When the PCC BN-en(n) receives the PCInitiate message from its 851 PCE(n), it sets up the local path from the entry BN-en(n) to D by 852 means of RSVP-TE signaling or Segment Routing, accordingly to the 853 PST value, with the given ERO(n). 855 3. Once the path is set up, it chooses a free label for the 856 Stitching Label SL(n) and adds a new entry in its MPLS L(F)IB 857 with this SL(n) label. Then, it MUST send a PCRpt message to its 858 PCE(n) with PLSP-ID(n) and a TE-PATH-BINDING TLV with the I flag 859 set and a Binding Value equal to SL(n). 861 4. Once PCE(n) receives the PCRpt from the PCC BN-en(n) with the 862 RRO, PLSP-ID and TE-PATH-BINDING TLV with the I flag set, it MUST 863 send to its Parent PCE a PCRpt containing the TE-PATH-BINDING TLV 864 it received from the PCC BN-en(n) and PLSP-ID(n). PCE(n) MAY add 865 PKS(n) in the RRO. 867 Steps i: Actions performed for all intermediate domains(i), for i = 868 n-1 to 2 870 1. Once the Parent PCE receives a PcRpt from Child PCE(i+1), it MUST 871 send a PCInitiate message to Child PCE(i) with an LSP object 872 containing an empty TE-PATH-BINDING TLV with the I flag set, the 873 ERO(i) to which it appends the SL(i+1) i.e. ERO(i) = {PKS(i), 874 SL(i+1)} and End-Points = {BN-en(i), BN-ex(i)}. 876 2. When PCE(i) receives a PcInitiate message from its Parent PCE, it 877 retrieves the detailed ERO(i) from the PKS(i) if necessary. 878 Then, it MUST send to the PCC BN-en(i) a PCInitiate message with 879 an LSP object containing an empty TE-PATH-BINDIG TLV with the I 880 flag set, this ERO(i) and End-Points Object = {BN-en(i), BN- 881 ex(i)} in order to inform the PCC BN-en(i) that this local 882 path(i) is part of an inter-domain path and that it MUST allocate 883 a Binding Value for this path. PCE(i) sets Path Setup Type (PST) 884 to 0, respectively to 1 to instruct the PCC to enforce the local 885 path by means of RSVP-TE respectively Segment Routing. 887 3. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003] 888 for RSVP-TE, respectively, Egress Peer Engineering [RFC9086] for 889 Segment Routing, is used to stitch and steer traffic between the 890 border node BN-ex(i) and BN-en(i+1). This allow PCE(i) to 891 instruct the egress node of domain(i), i.e. BN-ex(i), to forward 892 packets belonging to this tunnel with the Stitching Label. For 893 that purpose, PCE(i) should identify the link LK(i+1) by 894 retrieving from the PKS(i) the corresponding IP address of the 895 link LK(i+1) for RSVP-TE or from the BGP-LS the label that could 896 be use to reach link LK(i+1) for Segment Routing. As a result, 897 BN-ex(i) installs in its MPLS L(F)IB the SWAP instruction to 898 label SL(i+1) with forward to LK(i+1). Thus, PCE(i) MUST 899 complete the ERO(i), in order to provide the Stitching Label 900 SL(i+1) and Link identifier LK(i+1) to the PCC, as the last hop 901 of the local path i.e. ERO(i) = {ERO(i), [LK(i+1), SL(i+1)]}. 903 4. When the PCC BN-en(i) receives the PCInitiate message from its 904 PCE(i), it sets up the local path from BN-en(i) to BN-ex(i) by 905 means of RSVP-TE signaling or Segment Routing, accordingly to the 906 PST value, with the given ERO(i). 908 5. Once the tunnel is set up, PCC BN-en(i) chooses a free label for 909 the Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 910 with this SL(i) label. Then, it MUST send a PCRpt message to its 911 PCE(i) with PLSP-ID(i) and a TE-PATH-BINDING TLV with I flag set 912 and a Binding Value equal to SL(i). 914 6. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the 915 RRO, PLSP-ID and TE-PATH-BINDING TLV with the I flag set, it MUST 916 send to its Parent PCE a PCRpt containing the TE-PATH-BINDING TLV 917 it received from the PCC BN-en(i) and the PLSP-ID(i). PCE(i) MAY 918 add {PKS(i), ..., PKS(n)} in the RRO. 920 7. Once the Parent PCE receives the PCRpt from the Child PCE(i), it 921 stores the corresponding PLSP-ID for this inter-domain path part. 923 Steps n: Actions performed to the source domain(1) 925 Finally, the Parent PCE MUST send a last PCInitiate message to its 926 Child PCE(1) with an LSP Object containing an empty TE-PATH-BINDING 927 TLV with the I flag set, ERO = {PKS(1), SL(2)} and End-Points = {S, 928 BN-ex(1)}. In turn, Child PCE(1) MUST send a PCInitiate message to 929 PCC node S with ERO equal to {ERO(1), [LK(2), SL(2)]} and End-Points 930 Object = {S, BN-ex(1)}. This time, no TE-PATH-BINDING TLV is provided 931 as the PCC S does not need to return a Stitching Label SL, because it 932 is the head-end of the inter-domain path. A usual PCRpt message is 933 sent back to PCE(1) by the PCC node S. In turn, Child PCE(1) sends a 934 final PCRpt message to the Parent PCE with the PSLP-ID(1). PCE(1) 935 MAY add {S, BN-ex(1)} in the RRO. 937 4.2. Completion Failure of Inter-domain Path Setup Procedure 939 In case of error during path set up, PCRpt and/or PCErr messages MUST 940 be used to signal the problem to the Parent PCE. In particular, if 941 the new I flag of the TE-PATH-BINDING TLV defined in this document is 942 not supported by the Child PCE or the PCC, the Child PCE, 943 respectively the PCC, MUST return a PCErr message with Error-Type = 944 "Binding label/SID failure" and Error-Value = "Unable to allocate a 945 new binding label/SID" (as per section #12 of draft Binding Label / 946 Segment Identifier (BSID) [I-D.ietf-pce-binding-label-sid]) to its 947 Parent PCE respectively PCE. 949 If a PCE(i) receives a PCInitiate message from its Parent PCE without 950 an TE-PATH-BINDING with the I flag set in the LSP, it MUST return a 951 PCErr message with Error-Type = 24 (LSP instantiation error) and 952 Error-Value = 1 (Unacceptable instantiation parameters) to its Parent 953 PCE. 955 Following a PCInitiate message with an LSP containing an empty TE- 956 PATH-BINDING TLV with the I flag set, if a Child PCE or a PCC returns 957 no TE-PATH-BINDING TLV, or a TE-PATH-BINDING TLV without the I flag 958 set, the Parent PCE, respectively the Child PCE, MUST return a PCErr 959 message with Error-Type = "Binding label/SID failure" and Error-Value 960 = "Unable to allocate a new binding label/SID". 962 In case of completion failure, the Parent PCE MUST send a PCInitate 963 message (R flag set in the SRP Object as per [RFC8281]) to tear down 964 this inter-domain path from the Child PCEs that already set up their 965 respective part of the inter-domain path. Child PCE(i) MUST remove 966 its local path by means of PCInitiate message with R flag set to 1 to 967 its PCC BN-en(i) and send back a PCRpt message to the Parent PCE. 969 In case of error during path setup, PCRpt and or PCErr messages MUST 970 be used to signal the problem to the neighbor PCE domain backward. 972 4.3. Example for Stateful H-PCE Stiching Procedure 974 Taking the sample hierarchical domain topology example from [RFC6805] 975 as the reference topology for the entirety of this section. 977 ----------------------------------------------------------------- 978 | Domain 5 | 979 | ------- | 980 | |P-PCE 5| | 981 | ------- | 982 | | 983 | ---------------- ---------------- ---------------- | 984 | | Domain 1 | | Domain 2 | | Domain 3 | | 985 | | | | | | | | 986 | | ------- | | ------- | | ------- | | 987 | | |C-PCE 1| | | |C-PCE 2| | | |C-PCE 3| | | 988 | | ------- | | ------- | | ------- | | 989 | | | | | | | | 990 | | ----| |---- ----| |---- | | 991 | | |BN11+---+BN21| |BN23+---+BN31| | | 992 | | - ----| |---- ----| |---- - | | 993 | | |S| | | | | |D| | | 994 | | - ----| |---- ----| |---- - | | 995 | | |BN12+---+BN22| |BN24+---+BN32| | | 996 | | ----| |---- ----| |---- | | 997 | | | | | | | | 998 | | ---- | | | | ---- | | 999 | | |BN13| | | | | |BN33| | | 1000 | -----------+---- ---------------- ----+----------- | 1001 | \ / | 1002 | \ ---------------- / | 1003 | \ | | / | 1004 | \ |---- ----| / | 1005 | ----+BN41| |BN42+---- | 1006 | |---- ----| | 1007 | | | | 1008 | | ------- | | 1009 | | |C-PCE 4| | | 1010 | | ------- | | 1011 | | | | 1012 | | Domain 4 | | 1013 | ---------------- | 1014 | | 1015 ----------------------------------------------------------------- 1017 Figure 5: Hierarchical domain topology from RFC6805 1019 Section 3.3.1 of [RFC8751] describes the per-domain stitched LSP mode 1020 and list all the steps needed. To support SL-based stitching, using 1021 the reference architecture described in the figure above, the steps 1022 are modified as follows (note that we do not use PKS in this example 1023 for simplicity): 1025 Step 1: initialization 1027 The P-PCE (PCE5) is requested to initiate a path. Steps 4 to 10 of 1028 section 4.6.2 of [RFC6805] are executed to determine the end-to-end 1029 path, which are split into per-domain paths, e.g. {S-BN41, 1030 BN41-BN33, BN33-D}. 1032 Step 2: Path (BN33-D) at C-PCE3: 1034 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 1035 (C-PCE3) via PCInitiate message for path (BN33-D) with 1036 ERO={BN33..D} and an LSP object containing an empty TE-PATH- 1037 BINDING TLV with the I flag set and PST = 0/1 based on the setup 1038 type. 1040 2. C-PCE3 further propagates the initiate message it receives from 1041 P-PCE to BN33. 1043 3. BN33 initiates the setup of the path and reports to the status 1044 ("GOING-UP") to C-PCE3. 1046 4. C-PCE3 further reports the status of the path to the P-PCE 1047 (P-PCE5) 1049 5. The node BN33 notifies the path state to C-PCE3 when the state is 1050 "UP"; it also sends the Stitching Label (SL33) as the Binding 1051 Value of the TE-PATH-BINDING TLV with the I flag set and the RRO 1052 through the PCRpt message. 1054 6. C-PCE3 further reports the PCRpt message it receives from BN33 to 1055 the P-PCE (P-PCE5). 1057 Step 3: Path (BN41-BN33) at C-PCE4 1059 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 1060 (C-PCE4) via PCInitiate message for path (BN41-BN33) with 1061 ERO={BN41..BN42,SL33,BN33} and an LSP object containing an empty 1062 TE-PATH-BINDING TLV with the I flag set and PST = 0/1 based on 1063 the setup type. 1065 2. C-PCE4 further propagates the initiate message it receives from 1066 P-PCE to BN41 once complete the the ERO with the Link Identifier 1067 LK33 i.e. ERO={BN41..BN42,LK33,SL33,BN33}. 1069 3. BN41 initiates the setup of the path and reports the path status 1070 ("GOING-UP") to C-PCE4. 1072 4. C-PCE4 further reports the status of the path to the P-PCE 1073 (P-PCE5). 1075 5. The node BN41 notifies the path state to C-PCE4 when the state is 1076 "UP"; it also sends the Stitching Label (SL41) as the Binding 1077 Value of the TE-PATH-BINDING TLV with the I flag set and the RRO 1078 through the PCRpt message. 1080 6. C-PCE4 further reports the PCRpt message it receives from BN41 to 1081 the P-PCE (P-PCE5). 1083 Step 3: Path (S-BN41) at C-PCE1 1085 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 1086 (C-PCE1) via PCInitiate message for path (S-BN41) with 1087 ERO={S..BN13,SL41,BN41} and an LSP object containing an empty TE- 1088 PATH-BINDING TLV with the I flag set and PST = 0/1 based on the 1089 setup type. 1091 2. C-PCE1 further propagates the initiate message it receives from 1092 P-PCE to node S once complete the the ERO with the Link 1093 Identifier LK41 i.e. ERO={S..BN13,LK41,SL41,BN41}. 1095 3. S initiates the setup of the path and reports the path status 1096 ("GOING-UP") to C-PCE1. 1098 4. C-PCE1 further reports the status of the path to the P-PCE 1099 (P-PCE5) 1101 5. The node S notifies the path state to C-PCE1 when the state is 1102 "UP". 1104 6. C-PCE1 further reports the PCRpt message it receives from node S 1105 to the P-PCE (P-PCE5). 1107 5. Inter-domain Path Management 1109 This section describes how inter-domain paths could be managed. 1111 5.1. Stitching Label PCE Capabilities 1113 A PCE needs to know if its neighbor PCEs as well as PCCs are able to 1114 configure and provide a Stitching Label. The STITCHING-LABEL-PCE- 1115 CAPABILITY TLV is an optional TLV for use in the OPEN object for 1116 Stitching Label PCE capability advertisement. Its format is shown in 1117 the following figure: 1119 0 1 2 3 1120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Type=TBD7 | Length=4 | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Flags |I| 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 Figure 6: STITCHING-LABEL-PCE-CAPABILITY TLV Format 1129 The Type (16 bits) of the TLV is TBD7. The Length field is 16 bits 1130 long and has a fixed value of 4. 1132 The value comprises a single 32 bits "Flags" field: 1134 I (INTER-DOMAIN-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 by a 1135 PCE, the I flag indicates that the domain is supporting Stitching 1136 Label to set up inter-domain paths. When set by a PCC, the I flag 1137 indicates the the PCC is able to provide a Stitching Label as value 1138 of TE-PATH-BINDING TLV. 1140 Unassigned bits are considered reserved. They MUST be set to 0 on 1141 transmission and MUST be ignored on receipt. 1143 PCC MUST set the I flag when adding the Stitching Label Capability to 1144 the PCEP Open Message when establishing a PCEP session with a PCE. 1146 A PCE MUST set the I flag when establishing a PCEP session with a 1147 neighbor PCE when adding Stitching Label Capability to the PCEP Open 1148 Message. 1150 5.2. Identification of Inter-domain Paths 1152 First, in order to manage inter-domain paths composed by the 1153 stitching or nesting of local paths, it is important to identify 1154 them. For this purpose, the PLSP-ID managed by the PCEs are combined 1155 to one provided by PCCs to form a global identifier as follow: 1157 * PCE(i) in the Backward Recursive method or the Child PCE in 1158 Hierarchical method MUST create a new unique PLSP-ID for this 1159 inter-domain path part and MUST send it in the PCRpt message, to 1160 the PCE(i-1), respectively the Parent PCE. In addition this new 1161 PLSP-ID MUST be associated to the one received from the PCC that 1162 instantiates the local path part for further reference. 1164 * In the Hierarchical mode, the Parent PCE MUST store and associate 1165 the different PLSP-ID(i)s received from the different Child 1166 PCE(i)s in order to identify the different part of the inter- 1167 domain paths. 1169 * In the Backward Recursive method, PCE(i) MUST store and associate 1170 its PLSP-ID(i) and the PLSP-ID(i+1) it received from the PCE(i+1). 1171 PCE(n), i.e. the last one in the chain, does not need to perform 1172 such association. 1174 Further reference to the inter-domain path will use this PLSP-ID(i). 1175 In the Backward Recursive method, PCE(i) MUST replace the PLSP-ID(i) 1176 by PLSP-ID(i+1) in the PCUpd, PCRpt or PCinitiate message before 1177 propagating it to PCE(i+1); and PCE(i) MUST replace the PLSP-ID(i+1) 1178 by PLSP-ID(i) in the PCRpt message before propagating it to the 1179 PCE(i-1). In the Hierarchical method, the Parent PCE MUST use the 1180 corresponding PLSP-ID(i) of the Child PCE(i). 1182 5.3. Inter-domain Association Group 1184 In case of failure, a PCE(i) will received PCRpt messages from its 1185 PCCs and neighbors PCE(i+1) to synchronize the Inter-domain paths. 1186 In addition, it may received PCInitiate messages from its previous 1187 neighbors PCE(i-1) to re-initiate its inter-domain path part. As the 1188 PCE(i) may loose the PLSP-ID association, a new association group 1189 (within Association Object) is used to ease the association of the 1190 different parts of the inter-domain path: the local part and the PCE- 1191 to-PCE part. The use of the Association Object is MANDATORY in the 1192 Backward Recursive method and OPTIONAL in the Hierarchical method. 1194 For that purpose, a new Inter-Domain Association Type with value TBD4 1195 is defined. The first PCE in the Backward Recursive chain (the one 1196 which received the initial request) MUST send the PCInitiate message 1197 with an Association Object as follows: 1199 * Association Type field MUST be set to new value TBD4 1201 * Association ID MUST be set to a unique value. In case the 1202 Association ID field is too short or wraps, the first PCE MAY use 1203 the Extended Association ID to increase the number of association 1204 groups. The Association ID is managed locally by the PCE and does 1205 not need to be coordinated with neighbor or remote PCEs. 1207 * IPV4 or IPv6 association source MUST be set to the IP address 1208 which identifies PCE(1) in domain(1). 1210 * The Global Association Source TLV MUST be present and set with the 1211 ASN number of domain(1). It allows to create a globally unique 1212 association scope without putting constraint on operator's IP 1213 association source. Thus the IP Association Source is associated 1214 with the Global Association source to form a unique identifier. 1216 * Extended Association ID MAY be present and MANDATORY if 1217 association ID is too short or wraps. 1219 Subsequent PCE(i), for i = 2 to n, MUST send this Association Object 1220 as is to the local PCC and the neighbor PCE(i+1). 1222 In case of error with the association group, a PCErr message MUST be 1223 raised with Error = 26 (Association Error) and Error value set 1224 accordingly. A new Error value TBD6 is defined to identify 1225 association of inter-domain paths. 1227 In the Hierarchical method, the Parent PCE MAY act as the initiator 1228 of the Association and send to the Child PCEs an Association Object 1229 that follows the same rules as for the Backward Recursive method. In 1230 turn, Child PCEs MUST propagate the Association Object to the local 1231 PCCs as is. 1233 5.4. Modification of Inter-domain Paths 1235 For the Backward Recursive method, each domain manages their 1236 respective local path part of an inter-domain path independently of 1237 each other. In particular, Stitching Label(i) is managed by 1238 domain(i) and is of interest of domain(i-1) only. Thus, Stitching 1239 Label SL(i) is not supposed to be propagated to other domains. The 1240 same behavior apply to PLSP-ID(i). In the Hierarchical method, the 1241 Parent PCE MUST ensure the correct distribution of Stitching Label 1242 SL(i) to Child PCE(i-1). The PLSP-ID(i) is kept for the usage of the 1243 Parent PCE and thus is not propagated. Only the Association Object 1244 defined in section 5.2 is propagated if it is present. 1246 If PCE(i) needs to modify its local path(i) with a PCUpd message to 1247 the PCC BN-en(i), once the PCRpt message received from the PCC BN- 1248 en(i), it MUST sends a new PCRpt message to advertise the 1249 modification. This message is targeted to its neighbor PCE(i-1) in 1250 the Backward Recursive method, respectively to the Parent PCE in the 1251 Hierarchical method. In this case PLSP-ID(i) is used to identify the 1252 inter-domain path. PCE(i-1), respectively the Parent PCE, MUST 1253 propagate the PCRpt message if the modification implies the upstream 1254 domain, e.g. if the PCRpt indicates that the Stitching Label SL(i) 1255 has changed. 1257 PCE(1), respectively the Parent PCE, could modify the inter-domain 1258 path. For that purpose, it MUST send a PCUpd message to its neighbor 1259 PCEs, respectively Child PCE, using the PLSP-ID it received. Each 1260 PCE(i) MUST process the PCUpd message the same way they process the 1261 PCInitiate message as define in section 3.1 for the Backward 1262 Recursive method and in section 4.1 for the Hierarchical method. 1264 In case a failure appear in domain(i), e.g. path becoming down, 1265 PCE(i) MUST sends a PCRpt message to its neighbor PCE(i-1), 1266 respectively its Parent PCE to advertise the problem in its local 1267 part of the inter-domain path. Once PCE(1), respectively the Parent 1268 PCE, receives this PCRpt message indicating that the path is down, it 1269 is up to the PCE(1), respectively the Parent PCE to take appropriate 1270 correction e.g. start a new path computation to update the ERO. 1272 5.5. Modification of Local Paths 1274 Modification of local paths, i.e. between BN-en(i) and BN-ex(i) is 1275 left for further study. 1277 5.6. Tear-Down of Inter-domain Paths 1279 The tear-down of an inter-domain path is only possible by the inter- 1280 domain path initiator i.e. PCE(1). For the Backward Recursive 1281 method, a PCInitiate message with R flag set to 1, PLSP-ID set 1282 accordingly to section 5.1 and the Association Object with R flag set 1283 to 1, is sent by PCE(1) to PCE(n) through PCE(i), and processed the 1284 same way as described in section 3.1. For the Hierarchical method, a 1285 PCInitiate message with R flag set to 1 is sent by the Parent PCE to 1286 each Child PCE(i) with corresponding PLSP-ID(i), and processed 1287 according to section 4.1. Each domain PCE(i) is responsible to tear 1288 down its part of the path and the PCC MUST release both the Stitching 1289 label SL(i) in its L(F)IB and the path when it receives the 1290 PCInitiate message with the R flag set to 1 and the corresponding 1291 PLSP-ID(i). The Association Group MUST also be removed by the PCC 1292 and PCE(i). 1294 6. Applicability 1296 The newly introduce Stitching Label SL serves to stitch or nest part 1297 of local paths to form an inter-domain path. Each domain is free to 1298 decide if the incoming path is stitched or nested and how the path is 1299 enforced, e.g. through RSVP-TE or Segment Routing. At the peering 1300 point, the Border Node BN-ex(i) MUST encapsulate the packet with the 1301 Stitching Label, i.e. the MPLS label prior to send them to the next 1302 Border Node BN-en(i+1). Thus, only IP/MPLS networks are supported by 1303 this specification. 1305 6.1. Mixing Technologies 1307 During the instantiation procedure, if PCE(i) decides to reuse a 1308 local tunnel which is not yet part of an inter-domain tunnel, it 1309 SHOULD send a PCUpd message with an LSP containing an empty TE-PATH- 1310 BINDING TLV with the I flag set to 1 to the PCC BN-en(i), in order to 1311 request a Stitching Label SL(i), and new ERO(i) to add the Stitching 1312 Label SL(i+1) and the associated link to the previous ERO. 1314 [RFC8453] describes framework for Abstraction and Control of TE 1315 Networks (ACTN), where each Physical Network Controller (PNC) is 1316 equivalent to C-PCE and the Multi-Domain Service Coordinator (MDSC) 1317 to the P-PCE. The per-domain stitched LSP as per the Hierarchical 1318 PCE architecture described in Section 3.3.1 and Section 4.1 of 1319 [RFC8751] is well suited for ACTN. The Stitching Label mechanism as 1320 described in this document is well suited for ACTN when per-domain 1321 LSPs need to be stitched to form an E2E tunnel or a VN Member. It is 1322 to be noted that certain VNs require isolation from other clients. 1323 The SL mechanism described in this document can be applicable to the 1324 VN isolation use-case by uniquely identifying the concatenated 1325 stitching labels across multi-domain only to a certain VN member or 1326 an E2E tunnel. 1328 As each operator is free to enforce the tunnel with its technology 1329 choice, it is a local policy decision for PCE(i) to instantiate the 1330 local part of the end-to-end tunnel by either RSVP-TE or Segment 1331 Routing. The PST value 0 or 1 used in the PCinitiate message sent by 1332 the PCE(i) to the local PCC is determined by the local policy. How 1333 the local policy decision is set in the PCE is out of the scope of 1334 this document. This flexibility is allowed because the SL principle 1335 allows to mix (data plane) technologies between domains. For 1336 example, a domain(i) could use RSVP-TE while domain(i+1) uses SR. 1337 The SL could serve to stitch indifferently Segment Paths and RSVP-TE 1338 tunnels. Indeed, the SL will be part of the label stack in order to 1339 become the top label in the stack when reaching the BN-en(i+1). This 1340 SL could be swapped as usual if the next domain uses RSVP-TE tunnels. 1341 When the upstream domain uses an RSVP-TE tunnel, the SL will serve as 1342 a key for the BN-en(i+1) to determine which label stack it must use 1343 on top of the packet for a Segment Routing path. Finally, PCE(i) 1344 MUST completes accordingly ERO(i) with the identifier of Link(i+1): 1345 IP address of link between BN-ex(i) and BN-en(i+1) for RSVP-TE or EPE 1346 label of link between BN-ex(i) and BN-en(i+1) for Segment Routing. 1348 6.2. Inter-Area 1350 If use cases for inter-AS are easily identifiable, this is less 1351 evident for inter-area. However, two scenarios have been identified: 1353 * Paths between levels for IS-IS networks. 1355 * Reduction of labels stack depth for Segment Routing. 1357 Thus, the SL could be used to stitch or nest independent tunnels 1358 deployed through different IS-IS levels, even if there are controlled 1359 by the same PCE. IS-IS levels are considered as domains but under 1360 the control of the same PCE. In this scenario, there is no exchange 1361 between PCEs (it remains internal and implementation matter) and new 1362 TLVs are only applicable between the PCE and PCCs. The PCE requests 1363 to the different PCCs it identifies (i.e. BNs of the different IS-IS 1364 levels) to set up SLs and propagated them. 1366 In large-scale networks, MSD could constraints the path computation 1367 in the possibility of path selection i.e. explicit expression of a 1368 path could exceeded the MSD. The SL could be used to split a too 1369 long explicit path regarding the MSD constraints. In this scenario, 1370 there is also no communications between PCEs and new TLVs are only 1371 used between PCE and PCCs. 1373 6.3. Nested traffic 1375 When a domain(i) would groups into the same local path all traffic 1376 that enter into the domain through the same border node BN-en(i) and 1377 exit by the same border node BN-ex(i), it could be useful to identify 1378 the different inter-domain paths within this local path. Indeed, 1379 traffic entering in this nested local path could goes to different 1380 domains or different destination of the same domain. Thus, it is 1381 mandatory to keep them perfectly identifiable through a dedicated 1382 Stitching Label. In this case, PCE(i) proceeds as if it nested 1383 internal traffic. Nested tunnel MUST be created in top of existing 1384 inter-domain local path. Subsequent inter-domain local path will 1385 follow this nested local path. As a consequence, PCE(i) MUST NOT 1386 request a second Stitching Label(i) for an existing inter-domain 1387 local path. 1389 7. IANA Considerations 1391 7.1. TE-PATH-BINDING flag 1393 Binding Label / Segment Identifier (BSID) 1394 [I-D.ietf-pce-binding-label-sid] defines the TE-PATH-BINDING TLV Flag 1395 field. IANA is requested to allocate new flag in the PCEP TE-PATH- 1396 BINDING TLV Flag field registry, as follows: 1398 +=====+===========================+===========+ 1399 | Bit | Description | Reference | 1400 +=====+===========================+===========+ 1401 | 1 | I (Inter-domain Binding | This | 1402 | | Label/Segment Identifier) | Document | 1403 +-----+---------------------------+-----------+ 1404 | 2 | S (Strictly steer | This | 1405 | | traffic) | Document | 1406 +-----+---------------------------+-----------+ 1408 Table 1 1410 7.2. Association Type Value 1412 PCE Association Group [RFC8697] defines the ASSOCIATION Object and 1413 requests that IANA creates a registry to manage the value of the 1414 Association Type value. IANA is requested to allocate a new code 1415 point in the PCEP ASSOCIATION GROUP TLV Association Type field 1416 registry, as follows: 1418 +==================+================================+ 1419 | Association Type | Description | 1420 +==================+================================+ 1421 | TBD1 | Inter-domain Association Group | 1422 +------------------+--------------------------------+ 1424 Table 2 1426 7.3. PCEP Error Values 1428 IANA is requested to allocate code-points in the PCEP-ERROR Object 1429 Error Values registry for a new error-value of Error-Type 6 Mandatory 1430 Object Missing Error and new error-value of Error-Type 26 Association 1431 Error: 1433 +============+=============+=================================+ 1434 | Error-Type | Error-Value | Description | 1435 +============+=============+=================================+ 1436 | 6 | TBD2 | LSP TE-PATH-BINDING missing TLV | 1437 +------------+-------------+---------------------------------+ 1438 | 26 | TBD3 | Error in association of Inter- | 1439 | | | domain LSPs | 1440 +------------+-------------+---------------------------------+ 1442 Table 3 1444 7.4. PCEP TLV Type Indicators 1446 IANA is requested to allocate a new TLV Type Indicator for the 1447 "Stitching Label PCE Capability" within the "PCEP TLV Type 1448 Indicators" sub-registry of the "Path Computation Element Protocol 1449 (PCEP) Numbers" registry: 1451 +=======+================================+===============+ 1452 | Value | Description | Reference | 1453 +=======+================================+===============+ 1454 | TBD4 | STITCHING-LABEL-PCE-CAPABILITY | This Document | 1455 +-------+--------------------------------+---------------+ 1457 Table 4 1459 7.5. Stitching Label PCE Capability 1461 IANA is requested to allocate a new sub-registry, named "STITCHING- 1462 LABEL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation 1463 Element Protocol (PCEP) Numbers" registry, to manage the Flag field 1464 in the STITCHING-LABEL-PCE-CAPABILITY TLV of the PCEP OPEN object 1465 (class = 1). New values are assigned by Standards Action [RFC8126]. 1466 Each bit should be tracked with the following qualities: 1468 * Bit number (counting from bit 0 as the most significant bit) 1470 * Capability description 1472 * Defining RFC 1474 +=======+===================================+===============+ 1475 | Value | Description | Reference | 1476 +=======+===================================+===============+ 1477 | 31 | INTER-DOMAIN-STITCHING-CAPABILITY | This Document | 1478 +-------+-----------------------------------+---------------+ 1480 Table 5 1482 8. Security Considerations 1484 No modification of PCE protocol (PCEP) has been requested by this 1485 draft which does not introduce any issue regarding security. 1486 Concerning the PCEP session between PCEs, authors recommend to use 1487 the secured version of PCEP as defined in PCEPS [RFC8253] or use any 1488 other secured tunnel mechanism, e.g. IPsec tunnel to transport PCEP 1489 session between PCEs. 1491 9. Acknowledgements 1493 The authors want to thanks PCE's WG members, and in particular Dhruv 1494 Dhody who greatly contributed to the Hierarchical section of this 1495 document and Quan Xiong for his advice. 1497 10. Disclaimer 1499 This work has been performed in the framework of the H2020-ICT-2014 1500 project 5GEx (Grant Agreement no. 671636), which is partially funded 1501 by the European Commission. This information reflects the 1502 consortium's view, but neither the consortium nor the European 1503 Commission are liable for any use that may be done of the information 1504 contained therein. 1506 11. References 1508 11.1. Normative References 1510 [I-D.ietf-pce-binding-label-sid] 1511 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1512 and C. L. (editor), "Carrying Binding Label/Segment 1513 Identifier (SID) in PCE-based Networks.", Work in 1514 Progress, Internet-Draft, draft-ietf-pce-binding-label- 1515 sid-14, 3 March 2022, . 1518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1519 Requirement Levels", BCP 14, RFC 2119, 1520 DOI 10.17487/RFC2119, March 1997, 1521 . 1523 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1524 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1525 DOI 10.17487/RFC5440, March 2009, 1526 . 1528 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1529 "A Backward-Recursive PCE-Based Computation (BRPC) 1530 Procedure to Compute Shortest Constrained Inter-Domain 1531 Traffic Engineering Label Switched Paths", RFC 5441, 1532 DOI 10.17487/RFC5441, April 2009, 1533 . 1535 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1536 Computation Element Communication Protocol (PCEP) 1537 Extensions for Stateful PCE", RFC 8231, 1538 DOI 10.17487/RFC8231, September 2017, 1539 . 1541 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1542 Computation Element Communication Protocol (PCEP) 1543 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1544 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1545 . 1547 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1548 Dhody, D., and Y. Tanaka, "Path Computation Element 1549 Communication Protocol (PCEP) Extensions for Establishing 1550 Relationships between Sets of Label Switched Paths 1551 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1552 . 1554 11.2. Informative References 1556 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1557 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1558 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1559 . 1561 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1562 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1563 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1564 DOI 10.17487/RFC3473, January 2003, 1565 . 1567 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1568 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1569 . 1571 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1572 Hierarchy with Generalized Multi-Protocol Label Switching 1573 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1574 DOI 10.17487/RFC4206, October 2005, 1575 . 1577 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1578 Computation Element (PCE)-Based Architecture", RFC 4655, 1579 DOI 10.17487/RFC4655, August 2006, 1580 . 1582 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 1583 "Label Switched Path Stitching with Generalized 1584 Multiprotocol Label Switching Traffic Engineering (GMPLS 1585 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 1586 . 1588 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1589 "Preserving Topology Confidentiality in Inter-Domain Path 1590 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1591 DOI 10.17487/RFC5520, April 2009, 1592 . 1594 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1595 Path Computation Element Architecture to the Determination 1596 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1597 DOI 10.17487/RFC6805, November 2012, 1598 . 1600 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1601 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1602 Path Computation Element Communication Protocol (PCEP)", 1603 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1604 . 1606 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1607 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1608 DOI 10.17487/RFC8453, August 2018, 1609 . 1611 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1612 and J. Hardwick, "Path Computation Element Communication 1613 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1614 DOI 10.17487/RFC8664, December 2019, 1615 . 1617 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 1618 "Hierarchical Stateful Path Computation Element (PCE)", 1619 RFC 8751, DOI 10.17487/RFC8751, March 2020, 1620 . 1622 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 1623 Ray, S., and J. Dong, "Border Gateway Protocol - Link 1624 State (BGP-LS) Extensions for Segment Routing BGP Egress 1625 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 1626 2021, . 1628 Authors' Addresses 1629 Olivier Dugeon 1630 Orange Labs 1631 2, Avenue Pierre Marzin 1632 22307 Lannion 1633 France 1634 Email: olivier.dugeon@orange.com 1636 Julien Meuric 1637 Orange Labs 1638 2, Avenue Pierre Marzin 1639 22307 Lannion 1640 France 1641 Email: julien.meuric@orange.com 1643 Young Lee 1644 Samsung Electronics 1645 Email: younglee.tx@gmail.com 1647 Daniele Ceccarelli 1648 Ericsson 1649 Torshamnsgatan, 48 1650 Stockholm 1651 Sweden 1652 Email: daniele.ceccarelli@ericsson.com