idnits 2.17.1 draft-ietf-pce-stateful-interdomain-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 : ---------------------------------------------------------------------------- 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 (February 22, 2021) is 1153 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 1322, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Computation Element Working Group O. Dugeon 3 Internet-Draft J. Meuric 4 Intended status: Standards Track Orange Labs 5 Expires: August 26, 2021 Y. Lee 6 Samsung Electronics 7 D. Ceccarelli 8 Ericsson 9 February 22, 2021 11 PCEP Extension for Stateful Inter-Domain Tunnels 12 draft-ietf-pce-stateful-interdomain-01 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 Path Setup Types, new Association 24 Type, and a new PCEP 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 August 26, 2021. 43 Copyright Notice 45 Copyright (c) 2021 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 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 63 2. Stitching Label . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.2. Inter-domain LSP-TYPE . . . . . . . . . . . . . . . . . . 8 66 3. Backward Recursive PCInitiate Procedure . . . . . . . . . . . 9 67 3.1. Mode of Operation . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.3. Completion Failure of Inter-domain Path Setup Procedure . 13 70 4. Hierarchical PCInitiate Procedure . . . . . . . . . . . . . . 14 71 4.1. Mode of Operation . . . . . . . . . . . . . . . . . . . . 14 72 4.2. Completion Failure of Inter-domain Path Setup Procedure . 16 73 4.3. Example for Stateful H-PCE Stiching Procedure . . . . . . 17 74 5. Inter-domain Path Management . . . . . . . . . . . . . . . . 21 75 5.1. Stitching Label PCE Capabilities . . . . . . . . . . . . 21 76 5.2. Identification of Inter-domain Paths . . . . . . . . . . 22 77 5.3. Inter-domain Association Group . . . . . . . . . . . . . 23 78 5.4. Modification of Inter-domain Paths . . . . . . . . . . . 24 79 5.5. Modification of Inter-domain Paths . . . . . . . . . . . 25 80 5.6. Tear-Down of Inter-domain Paths . . . . . . . . . . . . . 25 81 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 25 82 6.1. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 6.2. Segment Routing . . . . . . . . . . . . . . . . . . . . . 26 84 6.3. Mixing Technologies . . . . . . . . . . . . . . . . . . . 27 85 6.4. Inter-Area . . . . . . . . . . . . . . . . . . . . . . . 27 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 7.1. Path Setup Type Values . . . . . . . . . . . . . . . . . 28 88 7.2. Association Type Value . . . . . . . . . . . . . . . . . 28 89 7.3. PCEP Error Values . . . . . . . . . . . . . . . . . . . . 29 90 7.4. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 29 91 7.5. Stitching Label PCE Capability . . . . . . . . . . . . . 29 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 94 10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 30 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 97 11.2. Informative References . . . . . . . . . . . . . . . . . 31 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 100 1. Introduction 102 The PCE working group has produced a set of RFCs to standardize the 103 behavior of the Path Computation Element ([RFC4655] and [RFC5440]) as 104 a tool to help MultiProtocol Label Switching - Traffic Engineering 105 (MPLS-TE)/Generalized MPLS (GMPLS) Label Switched Paths (LSPs) and 106 Segment Routing paths placement. This also includes the ability to 107 compute inter-domain LSPs or Segment Routing paths following a 108 distributed BRPC [RFC5441] or hierarchical H-PCE [RFC6805] approach. 109 Such inter-domain paths could then serve as an Explicit Route Object 110 (ERO) input for the RSVP-TE signaling to set up the tunnels within 111 the underlying network. Three kinds of inter-domain paths could be 112 established: 114 o Contiguous tunnel ([RFC3209] and [RFC3473]): The RSVP-TE signaling 115 crosses the boundary between two domains. This kind of tunnel is 116 not recommended mostly for security and scalability purpose. In 117 addition, the initiating domain imposes huge constraints on 118 subsequent domains, because they undergo the tunnel request 119 without being able to control it. 121 o Stitching tunnel ([RFC5150]): Each domain establishes in its own 122 network the corresponding part of the inter-domain path 123 independently. Then, a second end-to-end RSVP-TE Path message is 124 sent by the initiating domain to stitch the different tunnel parts 125 to form the inter-domain path. 127 o Nesting tunnel ([RFC4206]): This is similar to the stitching mode 128 but, this time, with the possibility to set up tunnel hierarchy. 130 However, these inter-domain paths depend on signaling using RSVP-TE 131 to be set up, but it is not common to allow signaling across 132 administrative domain borders, especially in operational networks. 134 For Segment Routing, issues are different as there is no signaling 135 between routers. First, a segment path depends on a stack of segment 136 identifiers but, in an inter-domain path, this stack may become too 137 large with respect to hardware constraint. If Extensions for Segment 138 Routing [RFC8664] takes into account the Maximum Stack Depth (MSD), a 139 PCE may be unable to find a solution when it computes an end-to-end 140 inter-domain path. The second issue is related to the path 141 confidentiality because all Node-SID must be stacked by the head end 142 router while some of the Node-SIDs are associated to routers of the 143 next domains. It is clear that operators would not disclose details 144 of their network, which includes Node-SIDs. Thus, it is not possible 145 to stack remote labels for an end-to-end inter-domain path even if 146 MSD constraint is respected. 148 The purpose of this document is to take the benefit of Active 149 Stateful PCE [RFC8231] and PCE-Initiated [RFC8281] modes to stitch or 150 nest inter-domain paths directly using PCEP between domains' PCEs 151 while avoiding the use of another signaling between inter-domain 152 border nodes. The mechanism keeps each operator free to 153 independently set up their respective part of the inter-domain paths, 154 i.e. the signaling (for MPLS-TE and GMPLS) is scoped on a per domain 155 basis, individually. 157 The PCInitiate message is used from destination domain to source 158 domain, to recursively set up the end-to-end tunnel. PCRep message 159 is used to convey the specific labels or SIDs to automatically stitch 160 or nest the different local LSPs. And PCRep in conjunction with 161 PCUpd messages are used to report, maintain, modify and tear down 162 inter-domain paths. This method is also applicable to Segment 163 Routing to build inter-domain segment paths. To enable this 164 mechanism, this document defines a new Stitching Label, new Path 165 Setup Types, new Association Type, and a new PCEP communication 166 Protocol (PCEP) Capability. 168 171 1.1. General Assumptions 173 In the remainder of this document, the same references as per BRPC 174 [RFC5441] are used and the following set of assumptions are made (see 175 figure below): 177 o Domain refers to administrative partitions, i.e. an IGP area or an 178 Autonomous System (AS). 180 o Inter-domain path is used to refer to a path that crosses two or 181 more different domains as defined previously, 183 o At least one PCE is deployed in each domain. These PCEs are all 184 active stateful-capable and can request to enforce LSPs in their 185 respective domain by means of PCInitiate messages. 187 o LSRs, including border nodes, are PCC-enabled and support active 188 stateful mode. PCEP sessions are established between these 189 routers and their domains' PCE. 191 o Each PCE establishes a PCEP session with its respective neighbor 192 domains' PCEs. The way a PCE discovers its neighboring PCEs is 193 out of the scope of this document. 195 o PCEs are able to compute an end-to-end path as per BRPC procedure 196 [RFC5441] or as per H-PCE procedure (stateless [RFC6805] or 197 stateful [RFC8751]). 199 o "Path" is a generic term to refer to both LSP setup by mean of 200 RSVP-TE or Segment Path in a Segment Routing network. 202 ...(H-PCE)........................... 203 . . . 204 . . . 205 -------------- -------------- -------------- 206 |Domain-A . | | . Domain-B| | . Domain-C| 207 | . | | . | | . | 208 | PCE------+--PCEP---+---PCE--------+--PCEP---+---PCE | 209 | / | | / | | / | 210 | / | | / | | / | 211 | Src=========BNA-------BNB1===========BNB2------BNC=========Dst | 212 | | Inter- | | Inter- | | 213 -------------- Domain -------------- Domain -------------- 214 Link Link 216 Example of the representation of 3 domains with 3 PCEs 218 Operations, according to the figure above, are as follow: 220 1. The PCEs in Domain-A, Domain-B, and Domain-C communicate using 221 PCEP either directly, as shown, using BRPC or with a parent PCE 222 if using H-PCE. 224 2. The PCE in Domain-A selects an end-to-end domain path. It tells 225 the PCE in Domain-B that the path will be used, and that PCE 226 passes the information on to the PCE in Domain-C. 228 3. Each of the PCEs use PCEP to instruct the segment head ends 229 backward from destination to source: 231 A. In Domain-C, the PCE instructs the ingress Border Node, BNC, 232 with the path to reach the Destination. The instructions 233 also ask BNC to provide the incoming label or SID that will 234 be stitched to the intra-domain path. Once done, PCE reports 235 this label or SID to PCE of Domain-B. 237 B. In Domain-B, the PCE instructs the ingress Border Node, BNB1, 238 with the path to reach the egress Border Node, BNB2. The 239 instructions also tell BNB1 the label or SID to use on the 240 inter-domain link to BNC and ask to provide the incoming 241 label or SID that will be stitched to the intra-domain path. 242 Once done, PCE reports this label or SID to PCE of Domain-A. 244 C. In Domain-A, the PCE instructs the Source node with the path 245 to use to reach Border Node, BNA. The instructions also 246 include the label or SID to use on the inter-domain link to 247 BNB1. 249 1.2. Terminology 251 ABR: Area Border Routers. Routers used to connect two IGP areas 252 (areas in OSPF or levels in IS-IS). 254 AS: Autonomous System 256 ASBR: Autonomous System Border Router. Router used to connect 257 together ASes (of the same or different service providers) via one or 258 more inter-AS links. 260 Border Node (BN): a boundary node is either an ABR in the context of 261 inter-area TE or an ASBR in the context of inter-AS TE. 263 BN-en(i): Entry BN of domain(i) connecting domain(i-1) to domain(i) 264 along a determined sequence of domains. Multiple entry BN-en(i) 265 could be used to connect domain(i-1) to domain(i). 267 BN-ex(i): Exit BN of domain(i) connecting domain(i) to domain(i+1) 268 along a determined sequence of domains. Multiple exit BN-ex(i) could 269 be used to connect domain(i) to domain(i+1). 271 Domains: Autonomous System (AS) or IGP Area. An Autonomous System is 272 composed by one or more IGP area. 274 ERO(i): The Explicit Route Object scoped to domain(i) 276 IGP-TE: Interior Gateway Protocol with Traffic Engineering support. 277 Both OSPF-TE and IS-IS-TE are identified in this category. 279 Inter-domain path: A path that crosses two or more domains through a 280 pair of Border Node (BN-ex, BN-en). 282 LK(i): A Link that connect BN-ex(i-1) to BN-en(i). Note that BN- 283 ex(i-1) could be connected to BN-en(i) by more than one link. LK(i) 284 identifies which of the multiple links will be used for the inter- 285 domain path setup. For inter-AS scenario, LK(i) represents the link 286 between ASBR of domain i to the ASBR of domain i-1. For inter-area 287 scenario, LK(i) is present only in IS-IS networks and represents the 288 link between ABR of region L1, reciprocally L2, to the ABR of region 289 L2, reciprocally L1. 291 Local path: A path that does not cross a domain border. It is set up 292 either from entry BN-en, to output BN-ex or between both. This path 293 could be enforce by means of RSVP-TE signaling or Segment Routing 294 labels stack. 296 Local path(i): A Local path of domain(i) 298 PLSP-ID(i): A PLSP-ID that identifies, in the domain(i), the local 299 part of an inter-domain path. 301 PCE: Path Computation Element. An entity (component, application, or 302 network node) that is capable of computing a network path or route 303 based on a network graph and applying computational constraints. 305 PCE(i) is a PCE within the scope of domain(i). 307 PST: Path Setup Type 309 R(i,j): The router j of domain i 311 Stitching Label (SL): A dedicated label that is used to stitch two 312 RSVP-TE LSPs or two Segment Routing paths. 314 SL(i): A Stitching Label that links domain(i-1) to domain(i). 316 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 317 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 318 document are to be interpreted as described in RFC 2119 [RFC2119]. 320 2. Stitching Label 322 This section introduces the concept of Stitching Label that allows 323 stitching and nesting of local paths in order to form an inter-domain 324 path that cross several different domains. 326 2.1. Definition 328 The operation of stitch or nest a local path(i) to a local path(i+1) 329 in order to form and inter-domain path mainly consists in defining 330 the label that the output BN-ex(i) will use to send its traffic to 331 the entry BN-en(i+1). Indeed, the entry BN-en(i+1) needs to identify 332 the incoming traffic (e.g. IP packets), in order to know if this 333 traffic must follow the local path(i+1) or not. Forwarding 334 Equivalent Class (FEC) could be used for that purpose. But, when 335 stitching or nesting tunnels, the FEC is reduced to the incoming 336 label that the entry BN-en(i+1) has chosen for the local path(i+1). 338 In this document, we introduce the term of "Stitching Label (SL)" to 339 refer to this label. Such label is usually exchanged between output 340 BN-ex(i) and entry BN-en(i+1) with the RSVP-TE signaling. But, as we 341 want to avoid to use RSVP-TE signaling due to operational 342 constraints, and allow compatibility support for Segment Routing, 343 this Stitching Label is here conveyed by PCEP. In fact, the Explicit 344 Route Object (ERO) and the Record Route Object (RRO) are already 345 defined in order to transport (G)MPLS labels (for RSVP-TE or Segment 346 Routing) in the PCEP signaling. Thus, the Stitching Label could be 347 conveyed in the ERO and RRO without any modification of PCEP nor PCEP 348 Objects. 350 As per RFC4003 [RFC4003], the Stitching Label will be conveyed as a 351 companion of a link identifier (e.g. an IP address for numbered 352 links). In our case, this is one of the endpoint IDs of the link 353 LK(i) which connects BN-ex(i) to BN-en(i+1) and carries the traffic 354 from the domain(i) to domain(i+1). It is left to implementation to 355 select which of the two endpoint IDs of the link LK(i) is used. 357 2.2. Inter-domain LSP-TYPE 359 Even if PCEP could convey the Stitching Label, a PCC is not aware 360 that a PCE requests or provides such a label. For that purpose, this 361 specification relies on the use of the PST as defined in [RFC8408] 362 with new values (See IANA section of this document) defined as 363 follow: 365 o TBD1: Inter-Domain TE end-to-end path is set up using Backward 366 Recursive or Hierarchical method. This new PST value MUST be set 367 in a PCInitiate messages sends by a PCE(i-1) to its neighbor 368 PCE(i) in the Backward Recursive method or by the Parent PCE to 369 the Child PCE(i) to initiate a new inter-domain path. In its 370 response, the neighbor PCE(1) or Child PCE(i) MUST return a 371 Stitching Label SL with an identifier of the associated link in 372 the RRO of the PCRpt message to PCE(i-1) or Parent PCE. 374 o TBD2: Inter-Domain TE local path is set up using RSVP-TE. This 375 new PST value MUST be set in the PCInitiate message sends by a 376 PCE(i) requesting to a PCC of domain(i) to initiate a new local 377 path(i) which is part of an inter-domain path. This PST value 378 MUST be used by the PCE(i) only after receiving a PCInitiate 379 message with an PST equal to TBD1 from a neighbor PCE(i-1) in the 380 Backward Recursive method or Parent PCE in the Hierarchical 381 method. In its response, the PCC of domain(i) MUST return a 382 Stitching Label SL with the an identifier of associated link in 383 the RRO of the PCRpt message. 385 o TBD3: Inter-Domain TE local path is set up using Segment Routing. 386 This new PST value MUST be set in the PCInitiate message sends by 387 a PCE(i) requesting to a PCC of domain(i) to initiate a new 388 Segment Routing path which is part of and inter-domain Segment 389 Routing path. This PST value MUST be used by the PCE(i) only 390 after receiving a PCInitiate message with an PST equal to TBD1 391 from a neighbor PCE(i-1). In its response, the PCC MUST return a 392 Stitching Label SL with an identifier of the associated link in 393 the RRO of the PCRpt message. 395 398 3. Backward Recursive PCInitiate Procedure 400 This section describes how to set up inter-domain paths that cross 401 different domains by using a Backward Recursive method. It is 402 compatible with the inter-domain path computation by means of the 403 BRPC procedure as describe in RFC5441 [RFC5441]. 405 3.1. Mode of Operation 407 This section describes how PCInitiate and PCRpt messages are combined 408 between PCE in order to set up inter-domain paths between a source 409 domain(1) to a destination domain(n). S and D are respectively the 410 source and destination of the inter-domain path. Domain(1) and 411 domain(n) are different and connected through 0 (i.e. direct 412 connection when n = 2) or more intermediate domains denoted domain(i) 413 with i = [2, n-1]. 415 First, the PCE(1) runs standard BRPC algorithm as per RFC5441 416 [RFC5441] with its neighbor PCEs in order to compute the inter-domain 417 path from S to D, where S and D are respectively a node in the 418 domain(1) and domain(n). Path Key confidentiality as per RFC5520 419 [RFC5520] SHOULD be used to obfuscate the detailed ERO(i) of the 420 different domains(i). The resulting ERO is in the form {S, PKS(1), 421 BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), ..., BN-en(n), PKS(n), D} 422 when Path Key is used and of the form {S, R(1,1), ..., R(1,k), BN- 423 ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), BN-ex(i), ..., BN-en(n), 424 R(n,1), ..., R(n,m), D} otherwise . As subsequent domains are not 425 aware about the computed end-to-end ERO in case of Virtual Source 426 Path trees (VSPTs), the final ERO selected by the PCE(1) MUST be sent 427 in the PCInitiate message to indicate to the subsequent PCEs which 428 path has been finally chosen. PCE(1) MUST ensure that this ERO is 429 self comprehensive by subsequent PCEs. Indeed, when a PCE(i) 430 receives the ERO, it MUST be able to verify that this ERO matches its 431 own scope and to determine the PCE(i+1). When Path Key is used, PCEs 432 MUST encode the Path Key with a reachable IP address so that previous 433 PCEs in the AS chain are able to join them. When Path Key is not 434 used, the PCEs MUST be able to retrieve an IP address of the next PCE 435 corresponding to the ERO (e.g., relying on a per prefix table). 437 The complete procedure with Path Key follows the different steps 438 described below: 440 Steps 1: Initialization 442 Once ERO(S, D) is computed, PCE(1) sends a PCInitiate message to 443 PCE(2) containing an ERO equal to {S, PKS(2), ..., PKS(i), ..., 444 PKS(n), D}, PST = TBD1 and End-Points Object = (S, D). The ERO 445 corresponds to the one PCE(1) has received from PCE(2) during the 446 BRPC process in which only Path Key are kept. In case of multiple 447 EROs, i.e. VSPT, PCE(1) has chosen one of them and used the selected 448 one for the PCInitiate message. PKS(i) could be replaced by the full 449 ERO description if Path Key is not used by PCE(i). 451 When PCE(i) receives a PCInitiate message from domain(i-1) with PST = 452 TBD1 and ERO = {PKS(i), PKS(i+1), ..., PKS(n), D)}, it sends a 453 PCInitiate message to PCE(i+1) with a popped ERO and records its 454 received PKS(i) part. All PCE(i)s generate the appropriate 455 PCInitiate message to PCE(i+1) up to PCE(n), i.e. to the destination 456 domain(n). 458 Steps 2: Actions taken at the destination domain(n) by PCE(n) 460 1. When a PCInitiate message reaches the destination domain(n), 461 PCE(n) retrieves the ERO from the PKS(n) if necessary and sends 462 to BN-en(n) a PCInitiate message with the ERO(n) = {BN-en(n), 463 ..., D}, PST = TBD2 and End-Points Object = {BN(n), D} in order 464 to inform the PCC BN-en(n) that this local path(n) is part of an 465 inter-domain path. 467 2. When the PCC BN-en(n) receives the PCInitiate message from its 468 PCE(n), it sets up the local path from entry BN-en(n) to D by 469 means of RSVP-TE signaling with the given ERO(n). 471 3. Once the tunnel is set up, BN-en(n) chooses a free label for the 472 Stitching Label SL(n) and adds a new entry in its MPLS L(F)IB 473 with this SL(n) label. Then, it sends a PCRpt message to its 474 PCE(n) with an RRO equal to {[LK(n), SL(n)], RRO(n)} and PLSP- 475 ID(n). 477 4. Once PCE(n) receives the PCRpt from the PCC BN-en(n) with the 478 RRO, PLSP-ID and PST = TBD2, it sends to the PCE(n-1) a PCRpt 479 containing the RRO equal to {[LK(n), SL(n)]} and PLSP-ID(n). 480 PCE(n) MAY add {PKS(n), D} in the RRO. 482 Steps i: Actions performed by all intermediate domains(i), for i = 2 483 to n-1 485 1. When the PCE(i) receives a PCRpt message from domain(i+1) with 486 PST = TBD1, RRO = {[LK(i+1), SL(i+1)]} and PLSP-ID(i+1), it 487 retrieves the ERO(i) from the PKS(i), recorded in step 1, and 488 sends to the PCC BN-en(i) a PCInitiate message with ERO = 489 {ERO(i), [LK(i+1), SL(i+1)]}, PST = TBD2 and End-Points Object = 490 {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) that 491 this local path(i) is part of an inter-domain path. 493 2. When the PCC BN-en(i) receives the PCInitiate message from its 494 PCE(i), it sets up the local path from BN-en(i) to BN-ex(i) by 495 means of RSVP-TE signaling with the given ERO(i). 497 3. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 498 is used to instruct the egress node of domain(i), i.e. BN-ex(i), 499 to forward packets belonging to this tunnel with the Stitching 500 Label. Both the Stitching Label and the identifier of the 501 interface are carried in the ERO = {..., [LK(i+1), SL(i+1)]} as 502 the last SubObject in conformance to [RFC4003]. As a result, BN- 503 ex(i) installs in its MPLS L(F)IB the SWAP instruction to label 504 SL(i+1) with forward to LK(i+1). 506 4. Once the tunnel is set up, PCC BN-en(i) chooses a free label for 507 the Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 508 with this SL(i) label. Then, it sends a PCRpt message to its 509 PCE(i) with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP- 510 ID(i). 512 5. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 513 and PST = TBD2, it sends to PCE(i-1) a PCRpt message containing 514 the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). PCE(i) MAY 515 add {PKS(i), ..., PKS(n)} in the RRO. 517 Steps n: Actions performed at the source domain(1) by PCE(1) 519 Once PCE(1) receives the PCRpt message from PCE(2) with the RRO 520 containing the label SL(2), it sends a PCInitiate message to PCC node 521 S with ERO equal to {ERO(1), [LK(2), SL(2)]}, PST = 0 and End-Points 522 Object = {S, BN-ex(1)}. This time, the PST is equal to 0 as the PCC S 523 does not need to return a Stitching Label SL, because it is the head- 524 end of the inter-domain path. A usual PCRpt message is sent back to 525 PCE(1) by the PCC node S. 527 3.2. Example 529 In the figure below, two different domains S and D are interconnected 530 through BN respectively BN-S and BN-D. PE-S and PE-D are edge 531 routers. All routers in the figure are connected to their respective 532 PCE through PCEP. In this example, we consider that PCE(S) needs to 533 set up an inter-domain path between PE-S and PE-D acting as source 534 and destination of the path. To simplify the figure, neither 535 intermediate routers between (PE-S, BN-S), (BN-D and PE-D), nor RSVP- 536 TE messages are represented, but they are all presents. The 537 following notation is used (in this example, we use the PKS for the 538 sake of simplicity): 540 o PKS(D) = Path Key corresponding to the path from BN(D) to PE-D 542 o ERO(D) = Explicit Route Object corresponding to the path from 543 BN(D) to PE-D, retrieved from PKS(D) 545 o RRO(D) = Record Route Object of the local path(D) from BN(D) to 546 PE-D 548 o SL(D) = Stitching Label for the local path from BN(D) to PE-D 550 o ERO(S) = Explicit Route Object corresponding to the path from PE-S 551 to BN(S) 553 o RRO(S) = Record Route Object of local path(S) from PE-S to BN(S) 554 PE-S PCE-S BN-D PCE-D 555 | | | | 556 | [ -------- Standard BRPC exchange ------------] 557 | | | | 558 | | PCInitiate(ERO={PKS(D)}, PST = TBD1) 559 | | --------------------------------------> | 560 | | | | 561 | | PCInitiate(ERO = ERO(D), PST = TBD2) 562 | | | <------- | 563 | | | | 564 | | PCRpt(RRO = {SL(D), RRO(D)}, PST = TBD2) 565 | | | ------> | 566 | | | | 567 | PCRpt(RRO = {SL(D), PKS(D)}, PST = TBD1, PLSP-ID(D)) 568 | | <-------------------------------------- | 569 | | | | 570 | PCInitiate(ERO={ERO(S), SL(D), BN(D)}, PST = 0) 571 | <------- | | | 572 | | | | 573 | PCRpt(RRO={RRO(S)}, PST = 0) | | 574 | -------> | | | 575 | | | | 577 +----------------------+ +----------------------+ 578 | | | | 579 | +------+ | PCEP | +------+ | 580 | +---->|PCE(S)|<-------------------------------->|PCE(D)| | 581 | | +------+ | | +------+ | 582 | | ^ | | ^ ^ | 583 | | | | | | | | 584 | |PCEP | | | | | | 585 | | |PCEP | | PCEP | | PCEP | 586 | v | | | | | | 587 (PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D) 588 | | Inter-Domain | | 589 | Domain (S) | Link | Domain (D) | 590 +----------------------+ +----------------------+ 592 [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---] 594 Example of inter-domain path setup between two domains 596 3.3. Completion Failure of Inter-domain Path Setup Procedure 598 In case of error during path setup, PCRpt and or PCErr messages MUST 599 be used to signal the problem to the neighbor PCE domain backward. 600 In particular, if the new PST values defined in this document are not 601 supported by the neighbor PCE or the PCC, the PCE, respectively the 602 PCC, MUST return a PCErr message with Error-Type = 21 (TE path setup 603 error) and Error-Value = 1 (Unsupported path setup type) to its 604 neighbor PCE. If a PCE(i) receives a PCInitiate message from its 605 peer PCE(i-1) without PST set to TBD1 or PST set to a value different 606 from TBD1, it MUST return a PCErr message with Error-Type = 21 (TE 607 path setup error) and Error-Value = 1 (Unsupported path setup type) 608 to its peer PCE(i-1). 610 Following a PCInitiate message with PST set to TBD1, if a PCC or a 611 PCE returns no RRO, or an RRO without the Stitching Label SL and an 612 identifier of the associated link, the PCE MUST return a PCErr 613 message with Error-Type = 21 (TE path setup error) and Error-Value = 614 TBD5 (Mandatory Stitching Label missing in the RRO). 616 In case of completion failure, the PCE(i) MUST propagate the PCErr 617 message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate 618 message (R flag set in the SRP Object as per [RFC8281]) to tear down 619 this inter-domain path from its neighbor PCEs. PCE(i) MUST propagate 620 the PCInitiate message and remove its local path by means of 621 PCInitiate message to its PCC BN-en(i) and send back PCRpt message to 622 PCE(i-1). 624 In case of error in domain(i+1), PCE(i) MAY add the AS number of 625 domain(i+1) in the RRO to identify the faulty domain. 627 4. Hierarchical PCInitiate Procedure 629 This section describes how to set up inter-domain paths that cross 630 different domains by using a hierarchical method. It is compatible 631 with inter-domain path computation as described in [RFC6805]. 633 4.1. Mode of Operation 635 This section describes how PCInitiate and PCRpt messages are combined 636 between PCEs in order to set up inter-domain paths between a source 637 domain(1) to a destination domain(n). S and D are respectively the 638 source and destination of the inter-domain path. Domain(1) and 639 domain(n) are different and connected through 0 or more intermediate 640 domains denoted domain(i) with i = (2, n-1). Domains are directly 641 connected when n = 2. 643 First, the Parent PCE contacts its Child PCE as per [RFC6805] in 644 order to compute the inter-domain path from S to D, where S and D are 645 respectively a node in the domain(1) and domain(n). Path Key 646 confidentiality as per RFC5520 [RFC5520] SHOULD be used to obfuscate 647 the detailed ERO(i) of the different domains(i). The resulting ERO 648 is of the form (S, PKS(1), BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), 649 ..., BN-en(n), PKS(n), D) when Path Key is used and of the form {S, 650 R(1,1), ..., R(1,k), BN-ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), 651 BN-ex(i), ..., BN-en(n), R(n,1), ..., R(n,m), D} otherwise. 653 The complete procedure with Path Key follow the different steps 654 described below: 656 Step 1: Initialization 658 1. The Parent PCE sends a PCInitiate message to Child PCE(n) with an 659 ERO = {PKS(n)} and End-Points = {BN-en(n), D}. Then, PCE(n) 660 retrieves the ERO from the PKS(n) (if necessary) and sends to BN- 661 en(n) a PCInitiate message with the ERO(n) = {BN-en(n), ..., D}, 662 PST = TBD2 and End-Points Object = {BN-en(n), D} in order to 663 inform the PCC BN-en(n) that this local path(n) is part of an 664 inter-domain path. 666 2. When the PCC BN-en(n) receives the PCInitiate message from its 667 PCE(n), it sets up the local path from the entry BN-en(n) to D by 668 means of RSVP-TE signaling with the given ERO(n). 670 3. Once the path is set up, it chooses a free label for the 671 Stitching Label SL(n) and adds a new entry in its MPLS L(F)IB 672 with this SL(n) label. Then, it sends a PCRpt message to its 673 PCE(n) with an RRO equal to {[LK(n), SL(n)], RRO(n)} and PLSP- 674 ID(n). 676 4. Once PCE(n) receives the PCRpt from the PCC BN-en(n) with the 677 RRO, PLSP-ID and PST = TBD2, it sends to its Parent PCE a PCRpt 678 containing the RRO equal to {[LK(n), SL(n)]} and PLSP-ID(n). 679 PCE(n) MAY add PKS(n) in the RRO. 681 Steps i: Actions performed for all intermediate domains(i), for i = 682 n-1 to 2 684 1. The Parent PCE sends a PCInitiate message to Child PCE(i) with 685 PST = TBD1, ERO = {PKS(i), [LK(i+1), SL(i+1)]} and End-Points = 686 {BN-en(i), BN-ex(i)} 688 2. Then, PCE(i) retrieves the ERO from the PKS(i) if necessary and 689 sends to the PCC BN-en(i) a PCInitiate message with ERO = 690 {ERO(i), [LK(i+1), SL(i+1)]}, PST = TBD2 and End-Points Object = 691 {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) that 692 this local path(i) is part of an inter-domain path. 694 3. When the PCC BN-en(i) receives the PCInitiate message from its 695 PCE(i), it sets up the local path from BN-en(i) to BN-ex(i) by 696 means of RSVP-TE signaling with the given ERO(i). 698 4. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 699 is used to instruct the egress node of domain(i), i.e. BN-ex(i) 700 to forward packets belonging to this tunnel with the Stitching 701 Label. Both the Label Stitching and an identifier of the 702 outgoing interface are carried in the ERO = {..., [LK(i+1), 703 SL(i+1)]} as the last SubObject in conformance to [RFC4003]. So 704 that, BN-ex(i) installs in its MPLS L(F)IB the SWAP instruction 705 to label SL(i+1) with forward to LK(i+1) instead of the usual POP 706 instruction. 708 5. Once the tunnel is set up, PCC BN-en(i) chooses a free label for 709 the Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 710 with this SL(i) label. Then, it sends a PCRpt message to its 711 PCE(i) with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP- 712 ID(i). 714 6. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 715 and PST = TBD2, it sends to its Parent PCE a PCRpt message 716 containing the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). 717 PCE(i) MAY add PKS(i) in the RRO. 719 7. Once the Parent PCE receives the PCRpt from the Child PCE(i), it 720 stores the corresponding PLSP-ID for this inter-domain path part. 722 Steps n: Actions performed to the source domain(1) 724 Finally, the Parent PCE sends a last PCInitiate message to its Child 725 PCE(1) with PST = TBD1, ERO = {PKS(1), [LK(2), SL(2)]} and End-Points 726 = {S, BN-ex(1)}. In turn, Child PCE(1) sends a PCInitiate message to 727 PCC node S with ERO equal to {ERO(1), [LK(2), SL(2)]}, PST = 0 and 728 End-Points Object = {S, BN-ex(1)}. This time, the PST is equal to 0 729 as the PCC S does not need to return a Stitching Label SL, because it 730 is the head-end of the inter-domain path. A usual PCRpt message is 731 sent back to PCE(1) by the PCC node S. In turn, Child PCE(1) sends a 732 final PCRpt message to the Parent PCE with the PSLP-ID(1). PCE(1) 733 MAY add {S, BN-ex(1)} in the RRO as a loose path. 735 4.2. Completion Failure of Inter-domain Path Setup Procedure 737 In case of error during path set up, PCRpt and or PCError messages 738 MUST be used to signal the problem to the Parent PCE. In particular, 739 if the new PST values defined in this document are not supported by 740 the Child PCE or the PCC, the Child PCE, respectively the PCC, MUST 741 return a PCErr message with Error-Type = 21 (TE path setup error) and 742 Error-Value = 1 (Unsupported path setup type) to its Parent PCE. If 743 Child PCE(i) receives a PCInitiate message from its Parent PCE 744 without PST set to TBD1 or PST set to a value different from TBD1, it 745 MUST return a PCErr message with Error-Type = 21 (TE path setup 746 error) and Error-Value = 1 (Unsupported path setup type) to its 747 Parent PCE. 749 Following a PCInitiate message with PST set to TBD1, if a Child PCE 750 or a PCC returns no RRO, or an RRO without the Stitching Label SL and 751 an identifier of the associated link, the Parent PCE, respectively 752 the Child PCE, MUST return a PCErr message with Error-Type = 21 (TE 753 path setup error) and Error-Value = TBD5 (Mandatory Stitching Label 754 missing in the RRO). 756 In case of completion failure, the Parent PCE MUST send a PCInitate 757 message (R flag set in the SRP Object as per [RFC8281]) to tear down 758 this inter-domain path from the Child PCEs that already set up their 759 respective part of the inter-domain path. Child PCE(i) MUST remove 760 its local path by means of PCInitiate message with R flag set to 1 to 761 its PCC BN-en(i) and send back a PCRpt message to the Parent PCE. 763 4.3. Example for Stateful H-PCE Stiching Procedure 765 Taking the sample hierarchical domain topology example from [RFC6805] 766 as the reference topology for the entirety of this section. 768 ----------------------------------------------------------------- 769 | Domain 5 | 770 | ------- | 771 | |P-PCE 5| | 772 | ------- | 773 | | 774 | ---------------- ---------------- ---------------- | 775 | | Domain 1 | | Domain 2 | | Domain 3 | | 776 | | | | | | | | 777 | | ------- | | ------- | | ------- | | 778 | | |C-PCE 1| | | |C-PCE 2| | | |C-PCE 3| | | 779 | | ------- | | ------- | | ------- | | 780 | | | | | | | | 781 | | ----| |---- ----| |---- | | 782 | | |BN11+---+BN21| |BN23+---+BN31| | | 783 | | - ----| |---- ----| |---- - | | 784 | | |S| | | | | |D| | | 785 | | - ----| |---- ----| |---- - | | 786 | | |BN12+---+BN22| |BN24+---+BN32| | | 787 | | ----| |---- ----| |---- | | 788 | | | | | | | | 789 | | ---- | | | | ---- | | 790 | | |BN13| | | | | |BN33| | | 791 | -----------+---- ---------------- ----+----------- | 792 | \ / | 793 | \ ---------------- / | 794 | \ | | / | 795 | \ |---- ----| / | 796 | ----+BN41| |BN42+---- | 797 | |---- ----| | 798 | | | | 799 | | ------- | | 800 | | |C-PCE 4| | | 801 | | ------- | | 802 | | | | 803 | | Domain 4 | | 804 | ---------------- | 805 | | 806 ----------------------------------------------------------------- 808 Hierarchical domain topology from RFC6805 810 Section 3.3.1 of [RFC8751] describes the per-domain stitched LSP mode 811 and list all the steps needed. To support SL-based stitching, using 812 the reference architecture described in the figure above, the steps 813 are modified as follows (note that we do not use PKS in this example 814 for simplicity): 816 Step 1: initialization 818 The P-PCE (PCE5) is requested to initiate a path. Steps 4 to 10 of 819 section 4.6.2 of [RFC6805] are executed to determine the end-to-end 820 path, which are split into per-domain paths, e.g. {S-BN41, 821 BN41-BN33, BN33-D}. 823 Step 2: Path (BN33-D) at C-PCE3: 825 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 826 (C-PCE3) via PCInitiate message for path (BN33-D) with 827 ERO={BN33..D} and PST = TBD1. 829 2. C-PCE3 further propagates the initiate message to BN33 with the 830 ERO and PST = TBD2/TBD3 based on the setup type. 832 3. BN33 initiates the setup of the path and reports to the status 833 ("GOING-UP") to C-PCE3. 835 4. C-PCE3 further reports the status of the path to the P-PCE 836 (P-PCE5) 838 5. The node BN33 notifies the path state to C-PCE3 when the state is 839 "UP"; it also sends the Stitching Label (SL33) in the RRO as 840 {SL33,BN33..D}. 842 6. C-PCE3 further reports the status of the path to the P-PCE 843 (P-PCE5) as well as sends the Stitching Label (SL33) in the RRO 844 as {LK33,SL33,BN33..D}. 846 Step 3: Path (BN41-BN33) at C-PCE4 848 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 849 (C-PCE4) via PCInitiate message for path (BN41-BN33) with 850 ERO={BN41..BN42,LK33,SL33,BN33} and PST = TBD1. 852 2. C-PCE4 further propagates the initiate message to BN41 with the 853 ERO and PST = TBD2/TBD3 based on the setup type. In case of 854 RSVP_TE, the node BN41 encode the Stitching Label SL33 as part of 855 the ERO to make sure the node BN42 uses the label SL33 towards 856 node BN33. In case of SR, the label SL33 is part of the label 857 stack pushed at node BN41. 859 3. BN41 initiates the setup of the path and reports the path status 860 ("GOING-UP") to C-PCE4. 862 4. C-PCE4 further reports the status of the path to the P-PCE 863 (P-PCE5). 865 5. The node BN41 notifies the path state to C-PCE4 when the state is 866 "UP"; it also sends the Stitching Label (SL41) in RRO as 867 {LK41,SL41,BN41..BN33}. 869 6. C-PCE4 further reports the status of the to the P-PCE (P-PCE5) as 870 well as sends the Stitching Label (SL41) in the RRO as 871 {LK41,SL41,BN41..BN33}. 873 Step 3: Path (S-BN41) at C-PCE1 875 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 876 (C-PCE1) via PCInitiate message for path (S-BN41) with 877 ERO={S..BN13,LK41,SL41,BN41}. 879 2. C-PCE1 further propagates the initiate message to node S with the 880 ERO. In case of RSVP-TE, node S encodes the Stitching Label SL41 881 as part of the ERO to make sure the node BN13 uses the label SL41 882 towards node BN41. In case of SR, the label SL41 is part of the 883 label stack pushed at node S. 885 3. S initiates the setup of the path and reports the path status 886 ("GOING-UP") to C-PCE1. 888 4. C-PCE1 further reports the status of the path to the P-PCE 889 (P-PCE5) 891 5. The node S notifies the path state to C-PCE1 when the state is 892 "UP". 894 6. C-PCE1 further reports the status of the path to the P-PCE 895 (P-PCE5). 897 In this way, per-domain paths are stitched together using the 898 Stitching Label (SL). The per-domain paths MUST be set up from the 899 destination domain towards the source domain one after the other. 901 Once the per-domain path is set up, the entry BN chooses a free label 902 for the Stitching Label SL and adds a new entry in its MPLS L(F)IB 903 with this SL label. The SL from the destination domain is propagated 904 to adjacent transit domain, towards the source domain at each step. 905 This happens from the entry BN to C-PCE then to the P-PCE, and vice- 906 versa. In case of RSVP-TE, the entry BN further propagates the SL 907 label to the exit BN via RSVP-TE. In case of SR, the SL label is 908 pushed as part of the SR label stack. 910 5. Inter-domain Path Management 912 This section describes how inter-domain paths could be managed. 914 5.1. Stitching Label PCE Capabilities 916 A PCE needs to know if its neighbor PCEs as well as PCCs are able to 917 configure and provide a Stitching Label. The STITCHING-LABEL-PCE- 918 CAPABILITY TLV is an optional TLV for use in the OPEN object for 919 Stitching Label PCE capability advertisement. Its format is shown in 920 the following figure: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type=TBD7 | Length=4 | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Flags |I|R|S| 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 STITCHING-LABEL-PCE-CAPABILITY TLV Format 932 The Type (16 bits) of the TLV is TBD7. The Length field is 16 bits 933 long and has a fixed value of 4. 935 The value comprises a single 32 bits "Flags" field: 937 R (RSVP-TE-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 by a PCC, 938 the R flag indicates that the PCC is able to provide Stitching 939 Labels, for RSVP-TE inter-domain paths, when requested by a PCE. If 940 set to 1 by a PCE, the R flag indicates that the domain controlled by 941 this PCE is able to set up inter-domain paths by means of RSVP-TE 942 signaling. 944 S (SEGMENT-ROUTING-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 945 by a PCC, the S flag indicates that the PCC is able to provide 946 Stitching Labels, for Segment-Routing inter-domain paths, when 947 requested by a PCE. If set to 1 by a PCE, the R flag indicates that 948 the domain controlled by this PCE is able to set up inter-domain 949 paths by means of Segment Routing. 951 I (INTER-DOMAIN-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 by a 952 PCE, the I flag indicates that the domain is supporting Stitching 953 Label to set up inter-domain paths. This flag is reserved for PCEP 954 session established between PCEs and MUST be kept unset by a PCC. 956 Unassigned bits are considered reserved. They MUST be set to 0 on 957 transmission and MUST be ignored on receipt. 959 PCCs MUST set the R and/or S flags and MUST NOT set the I flag when 960 adding the Stitching Label Capability to the PCEP Open Message. The 961 RSVP-TE-STITCHING-LABEL-CAPABILITY, respectively SEGMENT-ROUTING- 962 STITCHING-LABEL-CAPABILITY, flag must be set by both the PCC and PCE 963 in order to enable the configuration of Stitching Labels with RSVP- 964 TE, respectively with Segment-Routing. 966 A PCE MUST set the I flag when establishing a PCEP session with a 967 neighbor PCE when adding Stitching Label Capability to the PCEP Open 968 Message. It MAY set R and/or S flags depending if the operator would 969 like to keep confidential the technology used to set up inter-domain 970 paths or not. The INTER-DOMAIN-STITCHING-LABEL-CAPABILITY flag must 971 be set by both PCEs in order to enable inter-domain paths 972 instantiation by means of Stitching Label. 974 5.2. Identification of Inter-domain Paths 976 First, in order to manage inter-domain paths composed by the 977 stitching or nesting of local paths, it is important to identify 978 them. For this purpose, the PLSP-ID managed by the PCEs are combined 979 to one provided by PCCs to form a global identifier as follow: 981 o PCE(i) in the Backward Recursive method or the Child PCE in 982 Hierarchical method MUST create a new unique PLSP-ID for this 983 inter-domain path part and MUST send it in the PCRpt message, to 984 the PCE(i-1), respectively the Parent PCE. In addition this new 985 PLSP-ID MUST be associated to the one received from the PCC that 986 instantiates the local path part for further reference. 988 o In the Hierarchical mode, the Parent PCE MUST store and associate 989 the different PLSP-ID(i)s received from the different Child 990 PCE(i)s in order to identify the different part of the inter- 991 domain paths. 993 o In the Backward Recursive method, PCE(i) MUST store and associate 994 its PLSP-ID(i) and the PLSP-ID(i+1) it received from the PCE(i+1). 995 PCE(n), i.e. the last one in the chain, does not need to perform 996 such association. 998 Further reference to the inter-domain path will use this PLSP-ID(i). 999 In the Backward Recursive method, PCE(i) MUST replace the PLSP-ID(i) 1000 by PLSP-ID(i+1) in the PCUpd, PCRpt or PCinitiate message before 1001 propagating it to PCE(i+1); and PCE(i) MUST replace the PLSP-ID(i+1) 1002 by PLSP-ID(i) in the PCRpt message before propagating it to the 1003 PCE(i-1). In the Hierarchical method, the Parent PCE MUST use the 1004 corresponding PLSP-ID(i) of the Child PCE(i). 1006 5.3. Inter-domain Association Group 1008 In case of failure, a PCE(i) will received PCRpt messages from its 1009 PCCs and neighbors PCE(i+1) to synchronize the Inter-domain paths. 1010 In addition, it may received PCInitiate messages from its previous 1011 neighbors PCE(i-1) to re-initiate its inter-domain path part. As the 1012 PCE(i) may loose the PLSP-ID association, a new association group 1013 (within Association Object) is used to ease the association of the 1014 different parts of the inter-domain path: the local part and the PCE- 1015 to-PCE part. The use of the Association Object is MANDATORY in the 1016 Backward Recursive method and OPTIONAL in the Hierarchical method. 1018 For that purpose, a new Inter-Domain Association Type with value TBD4 1019 is defined. The first PCE in the Backward Recursive chain (the one 1020 which received the initial request) MUST send the PCInitiate message 1021 with an Association Object as follows: 1023 o Association Type field MUST be set to new value TBD4 1025 o Association ID MUST be set to a unique value. In case the 1026 Association ID field is too short or wraps, the first PCE MAY use 1027 the Extended Association ID to increase the number of association 1028 groups. The Association ID is managed locally by the PCE and does 1029 not need to be coordinated with neighbor or remote PCEs. 1031 o IPV4 or IPv6 association source MUST be set to the IP address 1032 which identifies PCE(1) in domain(1). 1034 o The Global Association Source TLV MUST be present and set with the 1035 ASN number of domain(1). It allows to create a globally unique 1036 association scope without putting constraint on operator's IP 1037 association source. Thus the IP Association Source is associated 1038 with the Global Association source to form a unique identifier. 1040 o Extended Association ID MAY be present and MANDATORY if 1041 association ID is too short or wraps. 1043 Subsequent PCE(i), for i = 2 to n, MUST send this Association Object 1044 as is to the local PCC and the neighbor PCE(i+1). 1046 In case of error with the association group, a PCErr message MUST be 1047 raised with Error = 26 (Association Error) and Error value set 1048 accordingly. A new Error value TBD6 is defined to identify 1049 association of inter-domain paths. 1051 In the Hierarchical method, the Parent PCE MAY act as the initiator 1052 of the Association and send to the Child PCEs an Association Object 1053 that follows the same rules as for the Backward Recursive method. In 1054 turn, Child PCEs MUST propagate the Association Object to the local 1055 PCCs as is. 1057 5.4. Modification of Inter-domain Paths 1059 For the Backward Recursive method, each domain manages their 1060 respective local path part of an inter-domain path independently of 1061 each other. In particular, Stitching Label(i) is managed by 1062 domain(i) and is of interest of domain(i-1) only. Thus, Stitching 1063 Label SL(i) is not supposed to be propagated to other domains. The 1064 same behavior apply to PLSP-ID(i). In the Hierarchical method, the 1065 Parent PCE MUST ensure the correct distribution of Stitching Label 1066 SL(i) to Child PCE(i-1). The PLSP-ID(i) is kept for the usage of the 1067 Parent PCE and thus is not propagated. Only the Association Object 1068 defined in section 5.2 is propagated if it is present. 1070 If PCE(i) needs to modify its local path(i) with a PCUpd message to 1071 the PCC BN-en(i), once the PCRpt message received from the PCC BN- 1072 en(i), it MUST sends a new PCRpt message to advertise the 1073 modification. This message is targeted to its neighbor PCE(i-1) in 1074 the Backward Recursive method, respectively to the Parent PCE in the 1075 Hierarchical method. In this case PLSP-ID(i) is used to identify the 1076 inter-domain path. PCE(i-1), respectively the Parent PCE, MUST 1077 propagate the PCRpt message if the modification implies the upstream 1078 domain, e.g. if the PCRpt indicates that the Stitching Label SL(i) 1079 has changed. 1081 PCE(1), respectively the Parent PCE, could modify the inter-domain 1082 path. For that purpose, it MUST send a PCUpd message to its neighbor 1083 PCEs, respectively Child PCE, using the PLSP-ID it received. Each 1084 PCE(i) MUST process the PCUpd message the same way they process the 1085 PCInitiate message as define in section 3.1 for the Backward 1086 Recursive method and in section 4.1 for the Hierarchical method. 1088 In case a failure appear in domain(i), e.g. path becoming down, 1089 PCE(i) MUST sends a PCRpt message to its neighbor PCE(i-1), 1090 respectively its Parent PCE to advertise the problem in its local 1091 part of the inter-domain path. Once PCE(1), respectively the Parent 1092 PCE, receives this PCRpt message indicating that the path is down, it 1093 is up to the PCE(1), respectively the Parent PCE to take appropriate 1094 correction e.g. start a new path computation to update the ERO. 1096 5.5. Modification of Inter-domain Paths 1098 Modification of local path, BN-en(i) and BN-ex(i) is left for further 1099 study. 1101 5.6. Tear-Down of Inter-domain Paths 1103 The tear-down of an inter-domain path is only possible by the inter- 1104 domain path initiator i.e. PCE(1). For the Backward Recursive 1105 method, a PCInitiate message with R flag set to 1, PLSP-ID set 1106 accordingly to section 5.1 and the Association Object with R flag set 1107 to 1, is sent by PCE(1) to PCE(n) through PCE(i), and processed the 1108 same way as described in section 3.1. For the Hierarchical method, a 1109 PCInitiate message with R flag set to 1 is sent by the Parent PCE to 1110 each Child PCE(i) with corresponding PLSP-ID(i), and processed 1111 according to section 4.1. Each domain PCE(i) is responsible to tear 1112 down its part of the path and the PCC MUST release both the Stitching 1113 label SL in its L(F)IB and the path when it receives the PCInitiate 1114 message with the R flag set to 1 and the corresponding PLSP-ID. The 1115 Association Group MUST also be removed by the PCC and PCE(i). 1117 6. Applicability 1119 The newly introduce Stitching Label SL serves to stitch or nest part 1120 of local paths to form an inter-domain path. Each domain is free to 1121 decide if the incoming path is stitched or nested and how the path is 1122 enforced, e.g. through RSVP-TE or Segment Routing. At the peering 1123 point, the Border Node BN-ex(i) MUST encapsulate the packet with the 1124 Stitching Label, i.e. the MPLS label prior to send them to the next 1125 Border Node BN-en(i+1). Thus, only RSVP-TE and Segment Routing over 1126 MPLS technology are detailed in the following sections. 1128 6.1. RSVP-TE 1130 In case of RSVP-TE, the Border Node BN-ex(i) needs to received the 1131 Stitching Label from BN-en(i) through the RSVP-TE message and install 1132 in its L(F)IB a SWAP instruction to the Stitching Label and forward 1133 it to the next Border Node BN-en(i+1). For that purpose, the Egress 1134 Control mechanism, as per RFC4003 section 2.1 [RFC4003], is 1135 RECOMMENDED to instruct the Border Node BN-ex(i) of this action. 1136 Other mechanisms to program the L(F)IB could be used, e.g. NETCONF. 1138 As the Stitching Label could serves to stitch or nest tunnels, a 1139 domain(i) may decide to nest the incoming LSPs into a higher 1140 hierarchy of LSPs for a Traffic Engineering purpose. A PCE(i) may 1141 also decide to group local LSPs part of inter-domain paths into a 1142 higher hierarchical LSP to carry all these local paths from a BN- 1143 en(i) to a BN-ex(i). 1145 6.2. Segment Routing 1147 To use Segment Routing instead of RSVP-TE to set up the local LSP 1148 tunnels as defined in [RFC8664], PCE(i) MUST send a PCInitiate 1149 message with PST = TBD3 instead of TBD2 to advertise its respective 1150 PCC that the local path is enforce by means of Segment Routing. 1152 The Stitching Label SL(i+1) will be inserted into the label stack in 1153 order to become the top label in the stack when the packet reaches 1154 BN-en(i+1). Thus, the Stitching Label SL(i+1) serves as a FEC entry 1155 for BN-en(i+1) to identify the packets that follow the next Segment 1156 Path. For that purpose, BN-en(i+1) MUST install in its MPLS L(F)IB 1157 an instruction to replace the incoming Stitching Label SL(i+1) by the 1158 label stack given by the ERO(i+1) plus the Stitching Label SL(i+2), 1159 if any. 1161 When a packet reaches BN-ex(i), the last label in the stack before 1162 the label SL(i+1) corresponds to a SID that allows to reach BN- 1163 en(i+1). When there are multiple interfaces between Border Nodes, 1164 BN-ex(i) needs to know how to send the packets to BN-en(i+1). 1165 Similarly to the Egress Control mechanism used with RSVP-TE, it is 1166 RECOMMENDED to use the inter-domain SID defined as per draft Egress 1167 Peer Engineering [I-D.ietf-idr-bgpls-segment-routing-epe] for that 1168 purpose. The inter-domain SID is announced by BN-ex(i) to PCE(i) 1169 through BGP-LS for each interface that connect BN-ex(i) to neighbors 1170 BN-en(i+1). Thus, the label stack will end with {BN-ex(i) SID, 1171 Inter-Domain SID, SL(i+1)} and should be processed as follows: 1173 o The penultimate router of domain(i) pops its node SID, and sends 1174 the packet to the next node designated by the top label in the 1175 label stack, i.e. the node SID of BN-ex(i) or the adjacency SID of 1176 the link between the router and BN-ex(i). 1178 o BN-ex(i) pops its node SID or its adjacency SID and looks up the 1179 next label in the stack, i.e. the inter-domain SID which 1180 corresponds to the interface to BN-en(i+1). BN-ex(i) pops this 1181 inter-domain SID as well and sends the packet to BN-ex(i) through 1182 the corresponding interface. 1184 o BN-en(i+1) looks up the top label which is the Stitching Label 1185 SL(i+1), pops it and replaces it by the sub-sequent label stack. 1187 Other mechanisms, e.g. NETCONF, could be used to configure the 1188 inter-domain SID on exit Border Nodes. 1190 6.3. Mixing Technologies 1192 During the instantiation procedure, if PCE(i) decides to reuse a 1193 local tunnel which is not yet part of an inter-domain tunnel, it 1194 SHOULD send a PCUpd message with PST = TBD2 to the PCC BN-en(i), in 1195 order to request a Stitching Label SL(i), and new ERO(i) to add the 1196 Stitching Label SL(i+1) and the associated link to the previous ERO. 1198 [RFC8453] describes framework for Abstraction and Control of TE 1199 Networks (ACTN), where each Physical Network Controller (PNC) is 1200 equivalent to C-PCE and the Multi-Domain Service Coordinator (MDSC) 1201 to the P-PCE. The per-domain stitched LSP as per the Hierarchical 1202 PCE architecture described in Section 3.3.1 and Section 4.1 of 1203 [RFC8751] is well suited for ACTN. The Stitching Label mechanism as 1204 described in this document is well suited for ACTN when per-domain 1205 LSPs need to be stitched to form an E2E tunnel or a VN Member. It is 1206 to be noted that certain VNs require isolation from other clients. 1207 The SL mechanism described in this document can be applicable to the 1208 VN isolation use-case by uniquely identifying the concatenated 1209 stitching labels across multi-domain only to a certain VN member or 1210 an E2E tunnel. 1212 As each operator is free to enforce the tunnel with its technology 1213 choice, it is a local policy decision for PCE(i) to instantiate the 1214 local part of the end-to-end tunnel by either RSVP-TE or Segment 1215 Routing. Thus, the PST value (i.e. TBD2 or TBD3) used in the 1216 PCinitiate message sent by the PCE(i) to the local PCC is determined 1217 by the local policy. How the local policy decision is set in the PCE 1218 is out of the scope of this document. This flexibility is allowed 1219 because the SL principle allows to mix (data plane) technologies 1220 between domains. For example, a domain(i) could use RSVP-TE while 1221 domain(i+1) uses SR. The SL could serve to stitch indifferently 1222 Segment Paths and RSVP-TE tunnels. Indeed, the SL will be part of 1223 the label stack in order to become the top label in the stack when 1224 reaching the BN-en(i+1). This SL could be swapped as usual if the 1225 next domain uses RSVP-TE tunnels. When the upstream domain uses an 1226 RSVP-TE tunnel, the SL will serve as a key for the BN-en(i+1) to 1227 determine which label stack it must use on top of the packet for a 1228 Segment Routing path. 1230 6.4. Inter-Area 1232 If use cases for inter-AS are easily identifiable, this is less 1233 evident for inter-area. However, two scenarios have been identified: 1235 o Paths between levels for IS-IS networks. 1237 o Reduction of labels stack depth for Segment Routing. 1239 Thus, the SL could be used to stitch or nest independent tunnels 1240 deployed through different IS-IS levels, even if there are controlled 1241 by the same PCE. IS-IS levels are considered as domains but under 1242 the control of the same PCE. In this scenario, there is no exchange 1243 between PCEs (it remains internal and implementation matter) and new 1244 TLVs are only applicable between the PCE and PCCs. The PCE requests 1245 to the different PCCs it identifies (i.e. BNs of the different IS-IS 1246 levels) to set up SLs and propagated them. 1248 In large-scale networks, MSD could constraints the path computation 1249 in the possibility of path selection i.e. explicit expression of a 1250 path could exceeded the MSD. The SL could be used to split a too 1251 long explicit path regarding the MSD constraints. In this scenario, 1252 there is also no communications between PCEs and new TLVs are only 1253 used between PCE and PCCs. 1255 7. IANA Considerations 1257 7.1. Path Setup Type Values 1259 [RFC8408] defines the PATH-SETUP-TYPE TLV. IANA is requested to 1260 allocate new code points in the PCEP PATH-SETUP-TYPE TLV PST field 1261 registry, as follows: 1263 +-------+-----------------------------------------------+-----------+ 1264 | Value | Description | Reference | 1265 +-------+-----------------------------------------------+-----------+ 1266 | TBD1 | Inter-domain TE end-to-end path is set up | This | 1267 | | using the Backward Recursive method | Document | 1268 | TBD2 | Inter-domain TE local path is set up using | This | 1269 | | RSVP-TE signaling | Document | 1270 | TBD3 | Inter-domain TE local path is set up using | This | 1271 | | Segment Routing | Document | 1272 +-------+-----------------------------------------------+-----------+ 1274 7.2. Association Type Value 1276 PCE Association Group [RFC8697] defines the ASSOCIATION Object and 1277 requests that IANA creates a registry to manage the value of the 1278 Association Type value. IANA is requested to allocate a new code 1279 point in the PCEP ASSOCIATION GROUP TLV Association Type field 1280 registry, as follows: 1282 +------------------+--------------------------------+ 1283 | Association Type | Description | 1284 +------------------+--------------------------------+ 1285 | TBD4 | Inter-domain Association Group | 1286 +------------------+--------------------------------+ 1288 7.3. PCEP Error Values 1290 IANA is requested to allocate code-points in the PCEP-ERROR Object 1291 Error Values registry for a new error-value of Error-Type 21 Invalid 1292 TE path setup and new error-value of Error-Type 26 Association Error: 1294 +------------+-------------+----------------------------------------+ 1295 | Error-Type | Error-Value | Description | 1296 +------------+-------------+----------------------------------------+ 1297 | 21 | TBD5 | Mandatory Stitching Label missing in | 1298 | | | the RRO | 1299 | 26 | TBD6 | Error in association of Inter-domain | 1300 | | | LSPs | 1301 +------------+-------------+----------------------------------------+ 1303 7.4. PCEP TLV Type Indicators 1305 IANA is requested to allocate a new TLV Type Indicator for the 1306 "Stitching Label PCE Capability" within the "PCEP TLV Type 1307 Indicators" subregistry of the "Path Computation Element Protocol 1308 (PCEP) Numbers" registry: 1310 +-------+--------------------------------+---------------+ 1311 | Value | Description | Reference | 1312 +-------+--------------------------------+---------------+ 1313 | TBD7 | STITCHING-LABEL-PCE-CAPABILITY | This Document | 1314 +-------+--------------------------------+---------------+ 1316 7.5. Stitching Label PCE Capability 1318 IANA is requested to allocate a new subregistry, named "STITCHING- 1319 LABEL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation 1320 Element Protocol (PCEP) Numbers" registry, to manage the Flag field 1321 in the STITCHING-LABEL-PCE-CAPABILITY TLV of the PCEP OPEN object 1322 (class = 1). New values are assigned by Standards Action [RFC8126]. 1323 Each bit should be tracked with the following qualities: 1325 o Bit number (counting from bit 0 as the most significant bit) 1327 o Capability description 1329 o Defining RFC 1330 +-------+--------------------------------------+---------------+ 1331 | Value | Description | Reference | 1332 +-------+--------------------------------------+---------------+ 1333 | 31 | RSVP-TE-STITCHING-CAPABILITY | This Document | 1334 | 30 | SEGMENT-ROUTING-STITCHING-CAPABILITY | This Document | 1335 | 29 | INTER-DOMAIN-STITCHING-CAPABILITY | This Document | 1336 +-------+--------------------------------------+---------------+ 1338 8. Security Considerations 1340 No modification of PCE protocol (PCEP) has been requested by this 1341 draft which does not introduce any issue regarding security. 1342 Concerning the PCEP session between PCEs, authors recommend to use 1343 the secured version of PCEP as defined in PCEPS [RFC8253] or use any 1344 other secured tunnel mechanism, e.g. IPsec tunnel to transport PCEP 1345 session between PCEs. 1347 9. Acknowledgements 1349 The authors want to thanks PCE's WG members, and in particular Dhruv 1350 Dhody who greatly contributed to the Hierarchical section of this 1351 document and Quan Xiong for his advice. 1353 10. Disclaimer 1355 This work has been performed in the framework of the H2020-ICT-2014 1356 project 5GEx (Grant Agreement no. 671636), which is partially funded 1357 by the European Commission. This information reflects the 1358 consortium's view, but neither the consortium nor the European 1359 Commission are liable for any use that may be done of the information 1360 contained therein. 1362 11. References 1364 11.1. Normative References 1366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1367 Requirement Levels", BCP 14, RFC 2119, 1368 DOI 10.17487/RFC2119, March 1997, 1369 . 1371 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1372 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1373 DOI 10.17487/RFC5440, March 2009, 1374 . 1376 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1377 "A Backward-Recursive PCE-Based Computation (BRPC) 1378 Procedure to Compute Shortest Constrained Inter-Domain 1379 Traffic Engineering Label Switched Paths", RFC 5441, 1380 DOI 10.17487/RFC5441, April 2009, 1381 . 1383 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1384 Computation Element Communication Protocol (PCEP) 1385 Extensions for Stateful PCE", RFC 8231, 1386 DOI 10.17487/RFC8231, September 2017, 1387 . 1389 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1390 Computation Element Communication Protocol (PCEP) 1391 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1392 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1393 . 1395 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1396 Hardwick, "Conveying Path Setup Type in PCE Communication 1397 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1398 July 2018, . 1400 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1401 Dhody, D., and Y. Tanaka, "Path Computation Element 1402 Communication Protocol (PCEP) Extensions for Establishing 1403 Relationships between Sets of Label Switched Paths 1404 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1405 . 1407 11.2. Informative References 1409 [I-D.ietf-idr-bgpls-segment-routing-epe] 1410 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1411 S., and J. Dong, "BGP-LS extensions for Segment Routing 1412 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1413 segment-routing-epe-19 (work in progress), May 2019. 1415 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1416 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1417 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1418 . 1420 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1421 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1422 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1423 DOI 10.17487/RFC3473, January 2003, 1424 . 1426 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1427 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1428 . 1430 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1431 Hierarchy with Generalized Multi-Protocol Label Switching 1432 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1433 DOI 10.17487/RFC4206, October 2005, 1434 . 1436 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1437 Element (PCE)-Based Architecture", RFC 4655, 1438 DOI 10.17487/RFC4655, August 2006, 1439 . 1441 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 1442 "Label Switched Path Stitching with Generalized 1443 Multiprotocol Label Switching Traffic Engineering (GMPLS 1444 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 1445 . 1447 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1448 "Preserving Topology Confidentiality in Inter-Domain Path 1449 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1450 DOI 10.17487/RFC5520, April 2009, 1451 . 1453 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1454 Path Computation Element Architecture to the Determination 1455 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1456 DOI 10.17487/RFC6805, November 2012, 1457 . 1459 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1460 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1461 Path Computation Element Communication Protocol (PCEP)", 1462 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1463 . 1465 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1466 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1467 DOI 10.17487/RFC8453, August 2018, 1468 . 1470 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1471 and J. Hardwick, "Path Computation Element Communication 1472 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1473 DOI 10.17487/RFC8664, December 2019, 1474 . 1476 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 1477 "Hierarchical Stateful Path Computation Element (PCE)", 1478 RFC 8751, DOI 10.17487/RFC8751, March 2020, 1479 . 1481 Authors' Addresses 1483 Olivier Dugeon 1484 Orange Labs 1485 2, Avenue Pierre Marzin 1486 Lannion 22307 1487 France 1489 Email: olivier.dugeon@orange.com 1491 Julien Meuric 1492 Orange Labs 1493 2, Avenue Pierre Marzin 1494 Lannion 22307 1495 France 1497 Email: julien.meuric@orange.com 1499 Young Lee 1500 Samsung Electronics 1502 Email: younglee.tx@gmail.com 1503 Daniele Ceccarelli 1504 Ericsson 1505 Torshamnsgatan, 48 1506 Stockholm 1507 Sweden 1509 Email: daniele.ceccarelli@ericsson.com