idnits 2.17.1 draft-dugeon-pce-stateful-interdomain-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2020) is 1385 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 1341, 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: January 11, 2021 Y. Lee 6 Huawei Technologies 7 D. Ceccarelli 8 Ericsson 9 July 10, 2020 11 PCEP Extension for Stateful Inter-Domain Tunnels 12 draft-dugeon-pce-stateful-interdomain-04 14 Abstract 16 This document specifies how to combine a Backward Recursive or 17 Hierarchical method with inter-domain paths in the context of 18 stateful Path Computation Element (PCE). It relies on the PCInitiate 19 message to set up independent paths per domain. Combining these 20 different paths together enables to operate them as end-to-end inter- 21 domain paths without the need for a signaling session between inter- 22 domain border routers. A new Stitching Label is defined, new Path 23 Setup Types, a new Association Type and a new PCEP communication 24 Protocol (PCEP) Capability are considered for that purpose. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 11, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 5 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 2. Stitching Label . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 71 2.2. Inter-domain LSP-TYPE . . . . . . . . . . . . . . . . . . 9 72 3. Backward Recursive PCInitiate Procedure . . . . . . . . . . . 9 73 3.1. Mode of Operation . . . . . . . . . . . . . . . . . . . . 10 74 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.3. Completion Failure of Inter-domain Path Setup Procedure . 14 76 4. Hierarchical PCInitiate Procedure . . . . . . . . . . . . . . 14 77 4.1. Mode of Operation . . . . . . . . . . . . . . . . . . . . 14 78 4.2. Completion Failure of Inter-domain Path Setup Procedure . 17 79 4.3. Example for Stateful H-PCE Stiching Procedure . . . . . . 17 80 5. Inter-domain Path Management . . . . . . . . . . . . . . . . 21 81 5.1. Stitching Label PCE Capabilities . . . . . . . . . . . . 21 82 5.2. Identification of Inter-domain Paths . . . . . . . . . . 22 83 5.3. Inter-domain Association Group . . . . . . . . . . . . . 23 84 5.4. Modification of Inter-domain Paths . . . . . . . . . . . 24 85 5.5. Modification of Inter-domain Paths . . . . . . . . . . . 25 86 5.6. Tear-Down of Inter-domain Paths . . . . . . . . . . . . . 25 87 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 25 88 6.1. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 6.2. Segment Routing . . . . . . . . . . . . . . . . . . . . . 26 90 6.3. Mixing Technologies . . . . . . . . . . . . . . . . . . . 27 91 6.4. Inter-Area . . . . . . . . . . . . . . . . . . . . . . . 27 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 93 7.1. Path Setup Type Values . . . . . . . . . . . . . . . . . 28 94 7.2. Association Type Value . . . . . . . . . . . . . . . . . 28 95 7.3. PCEP Error Values . . . . . . . . . . . . . . . . . . . . 29 96 7.4. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 29 97 7.5. Stitching Label PCE Capability . . . . . . . . . . . . . 29 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 100 10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 103 11.2. Informative References . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 106 1. Introduction 108 The PCE working group has produced a set of RFCs to standardize the 109 behavior of the Path Computation Element as a tool to help 110 MultiProtocol Label Switching - Traffic Engineering (MPLS- 111 TE)/Generalized MPLS (GMPLS) Label Switched Paths (LSPs) and Segment 112 Routing paths placement. This also includes the ability to compute 113 inter-domain LSPs or Segment Routing paths following a distributed or 114 hierarchical approach. To complement the original stateless mode, a 115 stateful mode has been added and supports both passive and active 116 control models. In particular, the new PCInitiate message allows a 117 PCE to directly ask a PCC to set up an MPLS-TE/GMPLS LSP or a Segment 118 Routing path. However, once computed, the inter-domain LSPs or 119 Segment Routing paths are hard to set up in the underlying network. 120 Especially, in operational networks, RSVP-TE signaling is usually not 121 enabled between AS border routers. But, such RSVP-TE signaling is 122 mandatory to set up contiguous LSP tunnels or to stitch or nest 123 independent LSP tunnels to form the end-to-end inter-domain paths. 125 Looking at the different RFCs that describe the PCE architecture and 126 in particular the PCE-based architecture [RFC4655], the PCE 127 communication Protocol [RFC5440], BRPC [RFC5441] and H-PCE [RFC6805], 128 the PCE is able to compute inter-domain paths, thus complementing the 129 intra-domain computation. Such inter-domain paths could then serve 130 as an Explicit Route Object (ERO) input for the RSVP-TE signaling to 131 set up the tunnels within the underlying network. Three kinds of 132 inter-domain paths could be established: 134 o Contiguous tunnel ([RFC3209] and [RFC3473]): The RSVP-TE signaling 135 crosses the boundary between two domains, e.g. between two AS 136 Border Routers (ASBRs) as if they were two routers of the same 137 domain. This kind of tunnel is not recommended mostly for 138 security and scalability purpose. In addition, the initiating 139 domain imposes huge constraints on subsequent domains, because 140 they undergo the tunnel request without being able to control it. 142 o Stitching tunnel ([RFC5150]): Each domain establishes in its own 143 network the corresponding part of the inter-domain path 144 independently. Then, a second end-to-end RSVP-TE Path message is 145 sent by the initiating domain to stitch the different tunnel parts 146 to form the inter-domain path. In fact, this second RSVP-TE Path 147 message is used by border nodes to request the label that must be 148 used by the previous domain to send the traffic in order that the 149 MPLS packets follow the next LSP in the downstream domain. These 150 labels are conveyed in the RSVP-TE Resv message. 152 o Nesting tunnel ([RFC4206]): This is similar to the stitching mode 153 but, this time, with the possibility to set up tunnel hierarchy. 154 For example, an LSP between two edge domains crossing a transit 155 domain could be carried over a tunnel of a higher level in the 156 transit domain. Again, a second end-to-end RSVP-TE Path message 157 is sent from the source to the destination. Labels that must be 158 used by the ASBRs of transit domains to identify flows to be 159 nested are carried by the RSVP-TE Resv message. 161 In all cases, RSVP-TE signaling must be exchanged between the 162 different domains. However, from an operational point of view, 163 looking to different networks under the responsibility of different 164 administrative entities, typically only BGP sessions are set up and 165 configured between ASBRs. Technologically speaking, this is possible 166 and many RFCs describe how to use RSVP-TE for inter-domain. But, due 167 to security, scalability, management and contract constraints, RSVP- 168 TE is not exposed at the network boundary. To address some of the 169 security concerns, RSVP-TE can be carried inside an IPsec tunnel 170 between ASBRs, but, this does not eliminate the scalability aspect 171 nor the constraints imposed by setting up inter-domain paths. 173 For Segment Routing, issues are different as there is no signaling 174 between routers. Here, the main problem comes from label stacking. 175 The first issue concerns the size of the labels stack which is 176 limited due to hardware constraint. The PCEP Extensions for Segment 177 Routing [RFC8664] takes into account this limitation within the PCEP 178 Capability when the PCEP session is established. Thus, taking into 179 account Maximum Stack Depth (MSD), a PCE may be unable to find a 180 solution when it computes an end-to-end inter-domain path. The 181 second issue is related to the path confidentiality. With SR-TE, to 182 express an explicit path, all Node-SID must be stacked by the head 183 end router while some of the Node-SIDs are associated to routers of 184 the next domains. It is clear that operators would not disclose 185 details of their network, which includes Node-SIDs. Thus, it is not 186 possible to stack remote labels for an end-to-end inter-domain path 187 even if MSD constraint is respected. 189 The purpose of this memo is to take the benefit of active stateful 190 PCE [RFC8231] and PCE-Initiated [RFC8281] modes to stitch or nest 191 inter-domain paths directly using PCEP between domains' PCEs. This 192 avoids using another signaling (e.g. RSVP-TE) at the inter-domain 193 border nodes, while keeping each operator free to independently set 194 up their respective part of the inter-domain paths. The PCInitiate 195 message is used in a Backward Recursive way like the PCReq message in 196 BRPC [RFC5441], to recursively set up the end-to-end tunnel. PCRep 197 message is used to automatically stitch or nest the different local 198 LSPs. And, PCRep in conjunction with PCUpd messages are used to 199 report, maintain, modify and remove inter-domain paths. This method 200 is also applicable to Segment Routing to build inter-domain segment 201 paths. 203 H-PCE [RFC6805] describes a Hierarchical PCE architecture which can 204 be used for computing end-to-end paths for inter-domain MPLS-TE and 205 GMPLS LSPs. Within this architecture, the Parent PCE (P-PCE) is used 206 to compute a multi-domain path based on the domain connectivity 207 information. A Child PCE (C-PCE) may be responsible for a single 208 domain or multiple domains, it is used to compute the intra-domain 209 path based on its domain topology information. 211 Stateful H-PCE [RFC8751] presents general considerations for stateful 212 PCE(s) in the hierarchical PCE architecture. In particular, the 213 behavior extends the existing stateful PCE mechanisms (including PCE- 214 initiated LSP setup and active PCE usage) in the context of networks 215 using the H-PCE architecture. Section 3.3.1 [RFC8751] describes the 216 per-domain stitched LSP mode, where the individual per-domain LSPs 217 are stitched together. PCInitiate message is also used to stitch the 218 end-to-end tunnel. See section 4 for details. 220 1.1. General Assumptions 222 In the remainder of this document, the same references as per BRPC 223 [RFC5441] are used and the following set of assumptions are made (see 224 figure below): 226 o Domain refers to administrative partitions, i.e. an IGP area or an 227 Autonomous System (AS). 229 o Inter-domain path is used to refer to a path that crosses two or 230 more different domains as defined previously, 232 o At least one PCE is deployed in each domain. These PCEs are all 233 active stateful-capable and can request to enforce LSPs in their 234 respective domain by means of PCInitiate messages. 236 o LSRs, including border nodes, are PCC-enabled and support active 237 stateful mode. PCEP sessions are established between these 238 routers and their domains' PCE. 240 o Each PCE establishes a PCEP session with its respective neighbor 241 domains' PCEs. The way a PCE discovers its neighboring PCEs is 242 out of the scope of this document. This information could be 243 administratively configured or automatically discovered through, 244 for example, [I-D.dong-pce-discovery-proto-bgp]. 246 o PCEs are able to compute an end-o-end path as per BRPC procedure 247 [RFC5441] or as per H-PCE procedure (stateless [RFC6805] or 248 stateful [RFC8751]). 250 o "Path" is a generic term to refer to both LSP setup by mean of 251 RSVP-TE or Segment Path in a Segment Routing network. 253 +----------------+ +----------------+ 254 | Domain (B) | | Domain (C) | 255 | | | | 256 | /-------|---PCEP---|--------\ | 257 | / | | \ | 258 | (PCE) | | (PCE) | 259 | / (BN)<------>(BN) | 260 | / | Inter | | 261 +---|--(BN)------+ Domain +----------------+ 262 | ^ Link 263 PCEP | 264 | | Inter-domain Link 265 | v 266 +---|--(BN)------+ 267 | | | 268 | | Domain (A) | 269 | \ | 270 | (PCE) | 271 | | 272 | | 273 +----------------+ 275 Example of the representation of 3 domains with 3 PCEs 277 1.2. Terminology 279 ABR: Area Border Routers. Routers used to connect two IGP areas 280 (areas in OSPF or levels in IS-IS). 282 AS: Autonomous System 284 ASBR: Autonomous System Border Router. Router used to connect 285 together ASes (of the same or different service providers) via one or 286 more inter-AS links. 288 Border Node (BN): a boundary node is either an ABR in the context of 289 inter-area TE or an ASBR in the context of inter-AS TE. 291 BN-en(i): Entry BN of domain(i) connecting domain(i-1) to domain(i) 292 along a determined sequence of domains. Multiple entry BN-en(i) 293 could be used to connect domain(i-1) to domain(i). 295 BN-ex(i): Exit BN of domain(i) connecting domain(i) to domain(i+1) 296 along a determined sequence of domains. Multiple exit BN-ex(i) could 297 be used to connect domain(i) to domain(i+1). 299 Domains: Autonomous System (AS) or IGP Area. An Autonomous System is 300 composed by one or more IGP area. 302 ERO(i): The Explicit Route Object scoped to domain(i) 304 IGP-TE: Interior Gateway Protocol with Traffic Engineering support. 305 Both OSPF-TE and IS-IS-TE are identified in this category. 307 Inter-domain path: A path that crosses two or more domains through a 308 pair of Border Node (BN-ex, BN-en). 310 LK(i): A Link that connect BN-ex(i-1) to BN-en(i). Note that BN- 311 ex(i-1) could be connected to BN-en(i) by more than one link. LK(i) 312 identifies which of the multiple links will be used for the inter- 313 domain path setup. For inter-AS scenario, LK(i) represents the link 314 between ASBR of domain i to the ASBR of domain i-1. For inter-area 315 scenario, LK(i) is present only in IS-IS networks and represents the 316 link between ABR of region L1, reciprocally L2, to the ABR of region 317 L2, reciprocally L1. 319 Local path: A path that does not cross a domain border. It is set up 320 either from entry BN-en, to output BN-ex or between both. This path 321 could be enforce by means of RSVP-TE signaling or Segment Routing 322 labels stack. 324 Local path(i): A Local path of domain(i) 326 PLSP-ID(i): A PLSP-ID that identifies, in the domain(i), the local 327 part of an inter-domain path. 329 PCE: Path Computation Element. An entity (component, application, or 330 network node) that is capable of computing a network path or route 331 based on a network graph and applying computational constraints. 333 PCE(i) is a PCE within the scope of domain(i). 335 PST: Path Setup Type 336 R(i,j): The router j of domain i 338 Stitching Label (SL): A dedicated label that is used to stitch two 339 RSVP-TE LSPs or two Segment Routing paths. 341 SL(i): A Stitching Label that links domain(i-1) to domain(i). 343 2. Stitching Label 345 This section introduces the concept of Stitching Label that allows 346 stitching and nesting of local paths in order to form an inter-domain 347 path that cross several different domains. 349 2.1. Definition 351 The operation of stitch or nest a local path(i) to a local path(i+1) 352 in order to form and inter-domain path mainly consists in defining 353 the label that the output BN-ex(i) will use to send its traffic to 354 the entry BN-en(i+1). Indeed, the entry BN-en(i+1) needs to identify 355 the incoming traffic (e.g. IP packets), in order to know if this 356 traffic must follow the local path(i+1) or not. Forwarding 357 Equivalent Class (FEC) could be used for that purpose. But, when 358 stitching or nesting tunnels, the FEC is reduced to the incoming 359 label that the entry BN-en(i+1) has chosen for the local path(i+1). 361 In this memo, we introduce the term of "Stitching Label (SL)" to 362 refer to this label. Such label is usually exchanged between output 363 BN-ex(i) and entry BN-en(i+1) with the RSVP-TE signaling. But, as we 364 want to avoid to use RSVP-TE signaling due to operational 365 constraints, and allow compatibility support for Segment Routing, 366 this Stitching Label is here conveyed by PCEP. In fact, the Explicit 367 Route Object (ERO) and the Record Route Object (RRO) are already 368 defined in order to transport (G)MPLS labels (for RSVP-TE or Segment 369 Routing) in the PCEP signaling. Thus, the Stitching Label could be 370 conveyed in the ERO and RRO without any modification of PCEP nor PCEP 371 Objects. 373 As per RFC4003 [RFC4003], the Stitching Label will be conveyed as a 374 companion of a link identifier (e.g. an IP address for numbered 375 links). In our case, this is one of the endpoint IDs of the link 376 LK(i) which connects BN-ex(i) to BN-en(i+1) and carries the traffic 377 from the domain(i) to domain(i+1). It is left to implementation to 378 select which of the two endpoint IDs of the link LK(i) is used. 380 2.2. Inter-domain LSP-TYPE 382 Even if PCEP could convey the Stitching Label, a PCC is not aware 383 that a PCE requests or provides such a label. For that purpose, this 384 specification relies on the use of the PST as defined in [RFC8408] 385 with new values (See IANA section of this memo) defined as follow: 387 o TBD1: Inter-Domain TE end-to-end path is set up using Backward 388 Recursive or Hierarchical method. This new PST value MUST be set 389 in a PCInitiate messages sends by a PCE(i-1) to its neighbor 390 PCE(i) in the Backward Recursive method or by the Parent PCE to 391 the Child PCE(i) to initiate a new inter-domain path. In its 392 response, the neighbor PCE(1) or Child PCE(i) MUST return a 393 Stitching Label SL with an identifier of the associated link in 394 the RRO of the PCRpt message to PCE(i-1) or Parent PCE. 396 o TBD2: Inter-Domain TE local path is set up using RSVP-TE. This 397 new PST value MUST be set in the PCInitiate message sends by a 398 PCE(i) requesting to a PCC of domain(i) to initiate a new local 399 path(i) which is part of an inter-domain path. This PST value 400 MUST be used by the PCE(i) only after receiving a PCInitiate 401 message with an PST equal to TBD1 from a neighbor PCE(i-1) in the 402 Backward Recursive method or Parent PCE in the Hierarchical 403 method. In its response, the PCC of domain(i) MUST return a 404 Stitching Label SL with the an identifier of associated link in 405 the RRO of the PCRpt message. 407 o TBD3: Inter-Domain TE local path is set up using Segment Routing. 408 This new PST value MUST be set in the PCInitiate message sends by 409 a PCE(i) requesting to a PCC of domain(i) to initiate a new 410 Segment Routing path which is part of and inter-domain Segment 411 Routing path. This PST value MUST be used by the PCE(i) only 412 after receiving a PCInitiate message with an PST equal to TBD1 413 from a neighbor PCE(i-1). In its response, the PCC MUST return a 414 Stitching Label SL with an identifier of the associated link in 415 the RRO of the PCRpt message. 417 3. Backward Recursive PCInitiate Procedure 419 This section describes how to set up inter-domain paths that cross 420 different domains by using a Backward Recursive method. It is 421 compatible with the inter-domain path computation by means of the 422 BRPC procedure as describe in RFC5441 [RFC5441]. 424 3.1. Mode of Operation 426 This section describes how PCInitiate and PCRpt messages are combined 427 between PCE in order to set up inter-domain paths between a source 428 domain(1) to a destination domain(n). S and D are respectively the 429 source and destination of the inter-domain path. Domain(1) and 430 domain(n) are different and connected through 0 (i.e. direct 431 connection when n = 2) or more intermediate domains denoted domain(i) 432 with i = [2, n-1]. 434 First, the PCE(1) runs standard BRPC algorithm as per RFC5441 435 [RFC5441] with its neighbor PCEs in order to compute the inter-domain 436 path from S to D, where S and D are respectively a node in the 437 domain(1) and domain(n). Path Key confidentiality as per RFC5520 438 [RFC5520] SHOULD be used to obfuscate the detailed ERO(i) of the 439 different domains(i). The resulting ERO is in the form {S, PKS(1), 440 BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), ..., BN-en(n), PKS(n), D} 441 when Path Key is used and of the form {S, R(1,1), ..., R(1,k), BN- 442 ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), BN-ex(i), ..., BN-en(n), 443 R(n,1), ..., R(n,m), D} otherwise . As subsequent domains are not 444 aware about the computed end-to-end ERO in case of Virtual Source 445 Path trees (VSPTs), the final ERO selected by the PCE(1) MUST be sent 446 in the PCInitiate message to indicate to the subsequent PCEs which 447 path has been finally chosen. PCE(1) MUST ensure that this ERO is 448 self comprehensive by subsequent PCEs. Indeed, when a PCE(i) 449 receives the ERO, it MUST be able to verify that this ERO matches its 450 own scope and to determine the PCE(i+1). When Path Key is used, PCEs 451 MUST encode the Path Key with a reachable IP address so that previous 452 PCEs in the AS chain are able to join them. When Path Key is not 453 used, the PCEs MUST be able to retrieve an IP address of the next PCE 454 corresponding to the ERO (e.g., relying on a per prefix table). 456 The complete procedure with Path Key follows the different steps 457 described below: 459 Steps 1: Initialization 461 Once ERO(S, D) is computed, PCE(1) sends a PCInitiate message to 462 PCE(2) containing an ERO equal to {S, PKS(2), ..., PKS(i), ..., 463 PKS(n), D}, PST = TBD1 and End-Points Object = (S, D). The ERO 464 corresponds to the one PCE(1) has received from PCE(2) during the 465 BRPC process in which only Path Key are kept. In case of multiple 466 EROs, i.e. VSPT, PCE(1) has chosen one of them and used the selected 467 one for the PCInitiate message. PKS(i) could be replaced by the full 468 ERO description if Path Key is not used by PCE(i). 470 When PCE(i) receives a PCInitiate message from domain(i-1) with PST = 471 TBD1 and ERO = {PKS(i), PKS(i+1), ..., PKS(n), D)}, it sends a 472 PCInitiate message to PCE(i+1) with a popped ERO and records its 473 received PKS(i) part. All PCE(i)s generate the appropriate 474 PCInitiate message to PCE(i+1) up to PCE(n), i.e. to the destination 475 domain(n). 477 Steps 2: Actions taken at the destination domain(n) by PCE(n) 479 1. When a PCInitiate message reaches the destination domain(n), 480 PCE(n) retrieves the ERO from the PKS(n) if necessary and sends 481 to BN-en(n) a PCInitiate message with the ERO(n) = {BN-en(n), 482 ..., D}, PST = TBD2 and End-Points Object = {BN(n), D} in order 483 to inform the PCC BN-en(n) that this local path(n) is part of an 484 inter-domain path. 486 2. When the PCC BN-en(n) receives the PCInitiate message from its 487 PCE(n), it sets up the local path from entry BN-en(n) to D by 488 means of RSVP-TE signaling with the given ERO(n). 490 3. Once the tunnel is set up, BN-en(n) chooses a free label for the 491 Stitching Label SL(n) and adds a new entry in its MPLS L(F)IB 492 with this SL(n) label. Then, it sends a PCRpt message to its 493 PCE(n) with an RRO equal to {[LK(n), SL(n)], RRO(n)} and PLSP- 494 ID(n). 496 4. Once PCE(n) receives the PCRpt from the PCC BN-en(n) with the 497 RRO, PLSP-ID and PST = TBD2, it sends to the PCE(n-1) a PCRpt 498 containing the RRO equal to {[LK(n), SL(n)]} and PLSP-ID(n). 499 PCE(n) MAY add {PKS(n), D} in the RRO. 501 Steps i: Actions performed by all intermediate domains(i), for i = 2 502 to n-1 504 1. When the PCE(i) receives a PCRpt message from domain(i+1) with 505 PST = TBD1, RRO = {[LK(i+1), SL(i+1)]} and PLSP-ID(i+1), it 506 retrieves the ERO(i) from the PKS(i), recorded in step 1, and 507 sends to the PCC BN-en(i) a PCInitiate message with ERO = 508 {ERO(i), [LK(i+1), SL(i+1)]}, PST = TBD2 and End-Points Object = 509 {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) that 510 this local path(i) is part of an inter-domain path. 512 2. When the PCC BN-en(i) receives the PCInitiate message from its 513 PCE(i), it sets up the local path from BN-en(i) to BN-ex(i) by 514 means of RSVP-TE signaling with the given ERO(i). 516 3. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 517 is used to instruct the egress node of domain(i), i.e. BN-ex(i), 518 to forward packets belonging to this tunnel with the Stitching 519 Label. Both the Stitching Label and the identifier of the 520 interface are carried in the ERO = {..., [LK(i+1), SL(i+1)]} as 521 the last SubObject in conformance to [RFC4003]. As a result, BN- 522 ex(i) installs in its MPLS L(F)IB the SWAP instruction to label 523 SL(i+1) with forward to LK(i+1). 525 4. Once the tunnel is set up, PCC BN-en(i) chooses a free label for 526 the Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 527 with this SL(i) label. Then, it sends a PCRpt message to its 528 PCE(i) with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP- 529 ID(i). 531 5. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 532 and PST = TBD2, it sends to PCE(i-1) a PCRpt message containing 533 the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). PCE(i) MAY 534 add {PKS(i), ..., PKS(n)} in the RRO. 536 Steps n: Actions performed at the source domain(1) by PCE(1) 538 Once PCE(1) receives the PCRpt message from PCE(2) with the RRO 539 containing the label SL(2), it sends a PCInitiate message to PCC node 540 S with ERO equal to {ERO(1), [LK(2), SL(2)]}, PST = 0 and End-Points 541 Object = {S, BN-ex(1)}. This time, the PST is equal to 0 as the PCC S 542 does not need to return a Stitching Label SL, because it is the head- 543 end of the inter-domain path. A usual PCRpt message is sent back to 544 PCE(1) by the PCC node S. 546 3.2. Example 548 In the figure below, two different domains S and D are interconnected 549 through BN respectively BN-S and BN-D. PE-S and PE-D are edge 550 routers. All routers in the figure are connected to their respective 551 PCE through PCEP. In this example, we consider that PCE(S) needs to 552 set up an inter-domain path between PE-S and PE-D acting as source 553 and destination of the path. To simplify the figure, neither 554 intermediate routers between (PE-S, BN-S), (BN-D and PE-D), nor RSVP- 555 TE messages are represented, but they are all presents. The 556 following notation is used (in this example, we use the PKS for the 557 sake of simplicity): 559 o PKS(D) = Path Key corresponding to the path from BN(D) to PE-D 561 o ERO(D) = Explicit Route Object corresponding to the path from 562 BN(D) to PE-D, retrieved from PKS(D) 564 o RRO(D) = Record Route Object of the local path(D) from BN(D) to 565 PE-D 567 o SL(D) = Stitching Label for the local path from BN(D) to PE-D 568 o ERO(S) = Explicit Route Object corresponding to the path from PE-S 569 to BN(S) 571 o RRO(S) = Record Route Object of local path(S) from PE-S to BN(S) 573 PE-S PCE-S BN-D PCE-D 574 | | | | 575 | [ -------- Standard BRPC exchange ------------] 576 | | | | 577 | | PCInitiate(ERO={PKS(D)}, PST = TBD1) 578 | | --------------------------------------> | 579 | | | | 580 | | PCInitiate(ERO = ERO(D), PST = TBD2) 581 | | | <------- | 582 | | | | 583 | | PCRpt(RRO = {SL(D), RRO(D)}, PST = TBD2) 584 | | | ------> | 585 | | | | 586 | PCRpt(RRO = {SL(D), PKS(D)}, PST = TBD1, PLSP-ID(D)) 587 | | <-------------------------------------- | 588 | | | | 589 | PCInitiate(ERO={ERO(S), SL(D), BN(D)}, PST = 0) 590 | <------- | | | 591 | | | | 592 | PCRpt(RRO={RRO(S)}, PST = 0) | | 593 | -------> | | | 594 | | | | 596 +----------------------+ +----------------------+ 597 | | | | 598 | +------+ | PCEP | +------+ | 599 | +---->|PCE(S)|<-------------------------------->|PCE(D)| | 600 | | +------+ | | +------+ | 601 | | ^ | | ^ ^ | 602 | | | | | | | | 603 | |PCEP | | | | | | 604 | | |PCEP | | PCEP | | PCEP | 605 | v | | | | | | 606 (PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D) 607 | | Inter-Domain | | 608 | Domain (S) | Link | Domain (D) | 609 +----------------------+ +----------------------+ 611 [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---] 613 Example of inter-domain path setup between two domains 615 3.3. Completion Failure of Inter-domain Path Setup Procedure 617 In case of error during path setup, PCRpt and or PCErr messages MUST 618 be used to signal the problem to the neighbor PCE domain backward. 619 In particular, if the new PST values defined in this memo are not 620 supported by the neighbor PCE or the PCC, the PCE, respectively the 621 PCC, MUST return a PCErr message with Error-Type = 21 (TE path setup 622 error) and Error-Value = 1 (Unsupported path setup type) to its 623 neighbor PCE. If a PCE(i) receives a PCInitiate message from its 624 peer PCE(i-1) without PST set to TBD1 or PST set to a value different 625 from TBD1, it MUST return a PCErr message with Error-Type = 21 (TE 626 path setup error) and Error-Value = 1 (Unsupported path setup type) 627 to its peer PCE(i-1). 629 Following a PCInitiate message with PST set to TBD1, if a PCC or a 630 PCE returns no RRO, or an RRO without the Stitching Label SL and an 631 identifier of the associated link, the PCE MUST return a PCErr 632 message with Error-Type = 21 (TE path setup error) and Error-Value = 633 TBD5 (Mandatory Stitching Label missing in the RRO). 635 In case of completion failure, the PCE(i) MUST propagate the PCErr 636 message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate 637 message (R flag set in the SRP Object as per [RFC8281]) to tear down 638 this inter-domain path from its neighbor PCEs. PCE(i) MUST propagate 639 the PCInitiate message and remove its local path by means of 640 PCInitiate message to its PCC BN-en(i) and send back PCRpt message to 641 PCE(i-1). 643 In case of error in domain(i+1), PCE(i) MAY add the AS number of 644 domain(i+1) in the RRO to identify the faulty domain. 646 4. Hierarchical PCInitiate Procedure 648 This section describes how to set up inter-domain paths that cross 649 different domains by using a hierarchical method. It is compatible 650 with inter-domain path computation as described in [RFC6805]. 652 4.1. Mode of Operation 654 This section describes how PCInitiate and PCRpt messages are combined 655 between PCEs in order to set up inter-domain paths between a source 656 domain(1) to a destination domain(n). S and D are respectively the 657 source and destination of the inter-domain path. Domain(1) and 658 domain(n) are different and connected through 0 or more intermediate 659 domains denoted domain(i) with i = (2, n-1). Domains are directly 660 connected when n = 2. 662 First, the Parent PCE contacts its Child PCE as per [RFC6805] in 663 order to compute the inter-domain path from S to D, where S and D are 664 respectively a node in the domain(1) and domain(n). Path Key 665 confidentiality as per RFC5520 [RFC5520] SHOULD be used to obfuscate 666 the detailed ERO(i) of the different domains(i). The resulting ERO 667 is of the form (S, PKS(1), BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), 668 ..., BN-en(n), PKS(n), D) when Path Key is used and of the form {S, 669 R(1,1), ..., R(1,k), BN-ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), 670 BN-ex(i), ..., BN-en(n), R(n,1), ..., R(n,m), D} otherwise. 672 The complete procedure with Path Key follow the different steps 673 described below: 675 Step 1: Initialization 677 1. The Parent PCE sends a PCInitiate message to Child PCE(n) with an 678 ERO = {PKS(n)} and End-Points = {BN-en(n), D}. Then, PCE(n) 679 retrieves the ERO from the PKS(n) (if necessary) and sends to BN- 680 en(n) a PCInitiate message with the ERO(n) = {BN-en(n), ..., D}, 681 PST = TBD2 and End-Points Object = {BN-en(n), D} in order to 682 inform the PCC BN-en(n) that this local path(n) is part of an 683 inter-domain path. 685 2. When the PCC BN-en(n) receives the PCInitiate message from its 686 PCE(n), it sets up the local path from the entry BN-en(n) to D by 687 means of RSVP-TE signaling with the given ERO(n). 689 3. Once the path is set up, it chooses a free label for the 690 Stitching Label SL(n) and adds a new entry in its MPLS L(F)IB 691 with this SL(n) label. Then, it sends a PCRpt message to its 692 PCE(n) with an RRO equal to {[LK(n), SL(n)], RRO(n)} and PLSP- 693 ID(n). 695 4. Once PCE(n) receives the PCRpt from the PCC BN-en(n) with the 696 RRO, PLSP-ID and PST = TBD2, it sends to its Parent PCE a PCRpt 697 containing the RRO equal to {[LK(n), SL(n)]} and PLSP-ID(n). 698 PCE(n) MAY add PKS(n) in the RRO. 700 Steps i: Actions performed for all intermediate domains(i), for i = 701 n-1 to 2 703 1. The Parent PCE sends a PCInitiate message to Child PCE(i) with 704 PST = TBD1, ERO = {PKS(i), [LK(i+1), SL(i+1)]} and End-Points = 705 {BN-en(i), BN-ex(i)} 707 2. Then, PCE(i) retrieves the ERO from the PKS(i) if necessary and 708 sends to the PCC BN-en(i) a PCInitiate message with ERO = 709 {ERO(i), [LK(i+1), SL(i+1)]}, PST = TBD2 and End-Points Object = 710 {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) that 711 this local path(i) is part of an inter-domain path. 713 3. When the PCC BN-en(i) receives the PCInitiate message from its 714 PCE(i), it sets up the local path from BN-en(i) to BN-ex(i) by 715 means of RSVP-TE signaling with the given ERO(i). 717 4. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 718 is used to instruct the egress node of domain(i), i.e. BN-ex(i) 719 to forward packets belonging to this tunnel with the Stitching 720 Label. Both the Label Stitching and an identifier of the 721 outgoing interface are carried in the ERO = {..., [LK(i+1), 722 SL(i+1)]} as the last SubObject in conformance to [RFC4003]. So 723 that, BN-ex(i) installs in its MPLS L(F)IB the SWAP instruction 724 to label SL(i+1) with forward to LK(i+1) instead of the usual POP 725 instruction. 727 5. Once the tunnel is set up, PCC BN-en(i) chooses a free label for 728 the Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 729 with this SL(i) label. Then, it sends a PCRpt message to its 730 PCE(i) with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP- 731 ID(i). 733 6. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 734 and PST = TBD2, it sends to its Parent PCE a PCRpt message 735 containing the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). 736 PCE(i) MAY add PKS(i) in the RRO. 738 7. Once the Parent PCE receives the PCRpt from the Child PCE(i), it 739 stores the corresponding PLSP-ID for this inter-domain path part. 741 Steps n: Actions performed to the source domain(1) 743 Finally, the Parent PCE sends a last PCInitiate message to its Child 744 PCE(1) with PST = TBD1, ERO = {PKS(1), [LK(2), SL(2)]} and End-Points 745 = {S, BN-ex(1)}. In turn, Child PCE(1) sends a PCInitiate message to 746 PCC node S with ERO equal to {ERO(1), [LK(2), SL(2)]}, PST = 0 and 747 End-Points Object = {S, BN-ex(1)}. This time, the PST is equal to 0 748 as the PCC S does not need to return a Stitching Label SL, because it 749 is the head-end of the inter-domain path. A usual PCRpt message is 750 sent back to PCE(1) by the PCC node S. In turn, Child PCE(1) sends a 751 final PCRpt message to the Parent PCE with the PSLP-ID(1). PCE(1) 752 MAY add {S, BN-ex(1)} in the RRO as a loose path. 754 4.2. Completion Failure of Inter-domain Path Setup Procedure 756 In case of error during path set up, PCRpt and or PCError messages 757 MUST be used to signal the problem to the Parent PCE. In particular, 758 if the new PST values defined in this memo are not supported by the 759 Child PCE or the PCC, the Child PCE, respectively the PCC, MUST 760 return a PCErr message with Error-Type = 21 (TE path setup error) and 761 Error-Value = 1 (Unsupported path setup type) to its Parent PCE. If 762 Child PCE(i) receives a PCInitiate message from its Parent PCE 763 without PST set to TBD1 or PST set to a value different from TBD1, it 764 MUST return a PCErr message with Error-Type = 21 (TE path setup 765 error) and Error-Value = 1 (Unsupported path setup type) to its 766 Parent PCE. 768 Following a PCInitiate message with PST set to TBD1, if a Child PCE 769 or a PCC returns no RRO, or an RRO without the Stitching Label SL and 770 an identifier of the associated link, the Parent PCE, respectively 771 the Child PCE, MUST return a PCErr message with Error-Type = 21 (TE 772 path setup error) and Error-Value = TBD5 (Mandatory Stitching Label 773 missing in the RRO). 775 In case of completion failure, the Parent PCE MUST send a PCInitate 776 message (R flag set in the SRP Object as per [RFC8281]) to tear down 777 this inter-domain path from the Child PCEs that already set up their 778 respective part of the inter-domain path. Child PCE(i) MUST remove 779 its local path by means of PCInitiate message with R flag set to 1 to 780 its PCC BN-en(i) and send back a PCRpt message to the Parent PCE. 782 4.3. Example for Stateful H-PCE Stiching Procedure 784 Taking the sample hierarchical domain topology example from [RFC6805] 785 as the reference topology for the entirety of this section. 787 ----------------------------------------------------------------- 788 | Domain 5 | 789 | ------- | 790 | |P-PCE 5| | 791 | ------- | 792 | | 793 | ---------------- ---------------- ---------------- | 794 | | Domain 1 | | Domain 2 | | Domain 3 | | 795 | | | | | | | | 796 | | ------- | | ------- | | ------- | | 797 | | |C-PCE 1| | | |C-PCE 2| | | |C-PCE 3| | | 798 | | ------- | | ------- | | ------- | | 799 | | | | | | | | 800 | | ----| |---- ----| |---- | | 801 | | |BN11+---+BN21| |BN23+---+BN31| | | 802 | | - ----| |---- ----| |---- - | | 803 | | |S| | | | | |D| | | 804 | | - ----| |---- ----| |---- - | | 805 | | |BN12+---+BN22| |BN24+---+BN32| | | 806 | | ----| |---- ----| |---- | | 807 | | | | | | | | 808 | | ---- | | | | ---- | | 809 | | |BN13| | | | | |BN33| | | 810 | -----------+---- ---------------- ----+----------- | 811 | \ / | 812 | \ ---------------- / | 813 | \ | | / | 814 | \ |---- ----| / | 815 | ----+BN41| |BN42+---- | 816 | |---- ----| | 817 | | | | 818 | | ------- | | 819 | | |C-PCE 4| | | 820 | | ------- | | 821 | | | | 822 | | Domain 4 | | 823 | ---------------- | 824 | | 825 ----------------------------------------------------------------- 827 Hierarchical domain topology from RFC6805 829 Section 3.3.1 of [RFC8751] describes the per-domain stitched LSP mode 830 and list all the steps needed. To support SL-based stitching, using 831 the reference architecture described in the figure above, the steps 832 are modified as follows (note that we do not use PKS in this example 833 for simplicity): 835 Step 1: initialization 837 The P-PCE (PCE5) is requested to initiate a path. Steps 4 to 10 of 838 section 4.6.2 of [RFC6805] are executed to determine the end-to-end 839 path, which are split into per-domain paths, e.g. {S-BN41, 840 BN41-BN33, BN33-D}. 842 Step 2: Path (BN33-D) at C-PCE3: 844 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 845 (C-PCE3) via PCInitiate message for path (BN33-D) with 846 ERO={BN33..D} and PST = TBD1. 848 2. C-PCE3 further propagates the initiate message to BN33 with the 849 ERO and PST = TBD2/TBD3 based on the setup type. 851 3. BN33 initiates the setup of the path and reports to the status 852 ("GOING-UP") to C-PCE3. 854 4. C-PCE3 further reports the status of the path to the P-PCE 855 (P-PCE5) 857 5. The node BN33 notifies the path state to C-PCE3 when the state is 858 "UP"; it also sends the Stitching Label (SL33) in the RRO as 859 {SL33,BN33..D}. 861 6. C-PCE3 further reports the status of the path to the P-PCE 862 (P-PCE5) as well as sends the Stitching Label (SL33) in the RRO 863 as {LK33,SL33,BN33..D}. 865 Step 3: Path (BN41-BN33) at C-PCE4 867 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 868 (C-PCE4) via PCInitiate message for path (BN41-BN33) with 869 ERO={BN41..BN42,LK33,SL33,BN33} and PST = TBD1. 871 2. C-PCE4 further propagates the initiate message to BN41 with the 872 ERO and PST = TBD2/TBD3 based on the setup type. In case of 873 RSVP_TE, the node BN41 encode the Stitching Label SL33 as part of 874 the ERO to make sure the node BN42 uses the label SL33 towards 875 node BN33. In case of SR, the label SL33 is part of the label 876 stack pushed at node BN41. 878 3. BN41 initiates the setup of the path and reports the path status 879 ("GOING-UP") to C-PCE4. 881 4. C-PCE4 further reports the status of the path to the P-PCE 882 (P-PCE5). 884 5. The node BN41 notifies the path state to C-PCE4 when the state is 885 "UP"; it also sends the Stitching Label (SL41) in RRO as 886 {LK41,SL41,BN41..BN33}. 888 6. C-PCE4 further reports the status of the to the P-PCE (P-PCE5) as 889 well as sends the Stitching Label (SL41) in the RRO as 890 {LK41,SL41,BN41..BN33}. 892 Step 3: Path (S-BN41) at C-PCE1 894 1. The P-PCE (P-PCE5) sends the initiate request to the C-PCE 895 (C-PCE1) via PCInitiate message for path (S-BN41) with 896 ERO={S..BN13,LK41,SL41,BN41}. 898 2. C-PCE1 further propagates the initiate message to node S with the 899 ERO. In case of RSVP-TE, node S encodes the Stitching Label SL41 900 as part of the ERO to make sure the node BN13 uses the label SL41 901 towards node BN41. In case of SR, the label SL41 is part of the 902 label stack pushed at node S. 904 3. S initiates the setup of the path and reports the path status 905 ("GOING-UP") to C-PCE1. 907 4. C-PCE1 further reports the status of the path to the P-PCE 908 (P-PCE5) 910 5. The node S notifies the path state to C-PCE1 when the state is 911 "UP". 913 6. C-PCE1 further reports the status of the path to the P-PCE 914 (P-PCE5). 916 In this way, per-domain paths are stitched together using the 917 Stitching Label (SL). The per-domain paths MUST be set up from the 918 destination domain towards the source domain one after the other. 920 Once the per-domain path is set up, the entry BN chooses a free label 921 for the Stitching Label SL and adds a new entry in its MPLS L(F)IB 922 with this SL label. The SL from the destination domain is propagated 923 to adjacent transit domain, towards the source domain at each step. 924 This happens from the entry BN to C-PCE then to the P-PCE, and vice- 925 versa. In case of RSVP-TE, the entry BN further propagates the SL 926 label to the exit BN via RSVP-TE. In case of SR, the SL label is 927 pushed as part of the SR label stack. 929 5. Inter-domain Path Management 931 This section describes how inter-domain paths could be managed. 933 5.1. Stitching Label PCE Capabilities 935 A PCE needs to know if its neighbor PCEs as well as PCCs are able to 936 configure and provide a Stitching Label. The STITCHING-LABEL-PCE- 937 CAPABILITY TLV is an optional TLV for use in the OPEN object for 938 Stitching Label PCE capability advertisement. Its format is shown in 939 the following figure: 941 0 1 2 3 942 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 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Type=TBD7 | Length=4 | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Flags |I|R|S| 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 STITCHING-LABEL-PCE-CAPABILITY TLV Format 951 The Type (16 bits) of the TLV is TBD7. The Length field is 16 bits 952 long and has a fixed value of 4. 954 The value comprises a single 32 bits "Flags" field: 956 R (RSVP-TE-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 by a PCC, 957 the R flag indicates that the PCC is able to provide Stitching 958 Labels, for RSVP-TE inter-domain paths, when requested by a PCE. If 959 set to 1 by a PCE, the R flag indicates that the domain controlled by 960 this PCE is able to set up inter-domain paths by means of RSVP-TE 961 signaling. 963 S (SEGMENT-ROUTING-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 964 by a PCC, the S flag indicates that the PCC is able to provide 965 Stitching Labels, for Segment-Routing inter-domain paths, when 966 requested by a PCE. If set to 1 by a PCE, the R flag indicates that 967 the domain controlled by this PCE is able to set up inter-domain 968 paths by means of Segment Routing. 970 I (INTER-DOMAIN-STITCHING-LABEL-CAPABILITY - 1 bit): if set to 1 by a 971 PCE, the I flag indicates that the domain is supporting Stitching 972 Label to set up inter-domain paths. This flag is reserved for PCEP 973 session established between PCEs and MUST be kept unset by a PCC. 975 Unassigned bits are considered reserved. They MUST be set to 0 on 976 transmission and MUST be ignored on receipt. 978 PCCs MUST set the R and/or S flags and MUST NOT set the I flag when 979 adding the Stitching Label Capability to the PCEP Open Message. The 980 RSVP-TE-STITCHING-LABEL-CAPABILITY, respectively SEGMENT-ROUTING- 981 STITCHING-LABEL-CAPABILITY, flag must be set by both the PCC and PCE 982 in order to enable the configuration of Stitching Labels with RSVP- 983 TE, respectively with Segment-Routing. 985 A PCE MUST set the I flag when establishing a PCEP session with a 986 neighbor PCE when adding Stitching Label Capability to the PCEP Open 987 Message. It MAY set R and/or S flags depending if the operator would 988 like to keep confidential the technology used to set up inter-domain 989 paths or not. The INTER-DOMAIN-STITCHING-LABEL-CAPABILITY flag must 990 be set by both PCEs in order to enable inter-domain paths 991 instantiation by means of Stitching Label. 993 5.2. Identification of Inter-domain Paths 995 First, in order to manage inter-domain paths composed by the 996 stitching or nesting of local paths, it is important to identify 997 them. For this purpose, the PLSP-ID managed by the PCEs are combined 998 to one provided by PCCs to form a global identifier as follow: 1000 o PCE(i) in the Backward Recursive method or the Child PCE in 1001 Hierarchical method MUST create a new unique PLSP-ID for this 1002 inter-domain path part and MUST send it in the PCRpt message, to 1003 the PCE(i-1), respectively the Parent PCE. In addition this new 1004 PLSP-ID MUST be associated to the one received from the PCC that 1005 instantiates the local path part for further reference. 1007 o In the Hierarchical mode, the Parent PCE MUST store and associate 1008 the different PLSP-ID(i)s received from the different Child 1009 PCE(i)s in order to identify the different part of the inter- 1010 domain paths. 1012 o In the Backward Recursive method, PCE(i) MUST store and associate 1013 its PLSP-ID(i) and the PLSP-ID(i+1) it received from the PCE(i+1). 1014 PCE(n), i.e. the last one in the chain, does not need to perform 1015 such association. 1017 Further reference to the inter-domain path will use this PLSP-ID(i). 1018 In the Backward Recursive method, PCE(i) MUST replace the PLSP-ID(i) 1019 by PLSP-ID(i+1) in the PCUpd, PCRpt or PCinitiate message before 1020 propagating it to PCE(i+1); and PCE(i) MUST replace the PLSP-ID(i+1) 1021 by PLSP-ID(i) in the PCRpt message before propagating it to the 1022 PCE(i-1). In the Hierarchical method, the Parent PCE MUST use the 1023 corresponding PLSP-ID(i) of the Child PCE(i). 1025 5.3. Inter-domain Association Group 1027 In case of failure, a PCE(i) will received PCRpt messages from its 1028 PCCs and neighbors PCE(i+1) to synchronize the Inter-domain paths. 1029 In addition, it may received PCInitiate messages from its previous 1030 neighbors PCE(i-1) to re-initiate its inter-domain path part. As the 1031 PCE(i) may loose the PLSP-ID association, a new association group 1032 (within Association Object) is used to ease the association of the 1033 different parts of the inter-domain path: the local part and the PCE- 1034 to-PCE part. The use of the Association Object is MANDATORY in the 1035 Backward Recursive method and OPTIONAL in the Hierarchical method. 1037 For that purpose, a new Inter-Domain Association Type with value TBD4 1038 is defined. The first PCE in the Backward Recursive chain (the one 1039 which received the initial request) MUST send the PCInitiate message 1040 with an Association Object as follows: 1042 o Association Type field MUST be set to new value TBD4 1044 o Association ID MUST be set to a unique value. In case the 1045 Association ID field is too short or wraps, the first PCE MAY use 1046 the Extended Association ID to increase the number of association 1047 groups. The Association ID is managed locally by the PCE and does 1048 not need to be coordinated with neighbor or remote PCEs. 1050 o IPV4 or IPv6 association source MUST be set to the IP address 1051 which identifies PCE(1) in domain(1). 1053 o The Global Association Source TLV MUST be present and set with the 1054 ASN number of domain(1). It allows to create a globally unique 1055 association scope without putting constraint on operator's IP 1056 association source. Thus the IP Association Source is associated 1057 with the Global Association source to form a unique identifier. 1059 o Extended Association ID MAY be present and MANDATORY if 1060 association ID is too short or wraps. 1062 Subsequent PCE(i), for i = 2 to n, MUST send this Association Object 1063 as is to the local PCC and the neighbor PCE(i+1). 1065 In case of error with the association group, a PCErr message MUST be 1066 raised with Error = 26 (Association Error) and Error value set 1067 accordingly. A new Error value TBD6 is defined to identify 1068 association of inter-domain paths. 1070 In the Hierarchical method, the Parent PCE MAY act as the initiator 1071 of the Association and send to the Child PCEs an Association Object 1072 that follows the same rules as for the Backward Recursive method. In 1073 turn, Child PCEs MUST propagate the Association Object to the local 1074 PCCs as is. 1076 5.4. Modification of Inter-domain Paths 1078 For the Backward Recursive method, each domain manages their 1079 respective local path part of an inter-domain path independently of 1080 each other. In particular, Stitching Label(i) is managed by 1081 domain(i) and is of interest of domain(i-1) only. Thus, Stitching 1082 Label SL(i) is not supposed to be propagated to other domains. The 1083 same behavior apply to PLSP-ID(i). In the Hierarchical method, the 1084 Parent PCE MUST ensure the correct distribution of Stitching Label 1085 SL(i) to Child PCE(i-1). The PLSP-ID(i) is kept for the usage of the 1086 Parent PCE and thus is not propagated. Only the Association Object 1087 defined in section 5.2 is propagated if it is present. 1089 If PCE(i) needs to modify its local path(i) with a PCUpd message to 1090 the PCC BN-en(i), once the PCRpt message received from the PCC BN- 1091 en(i), it MUST sends a new PCRpt message to advertise the 1092 modification. This message is targeted to its neighbor PCE(i-1) in 1093 the Backward Recursive method, respectively to the Parent PCE in the 1094 Hierarchical method. In this case PLSP-ID(i) is used to identify the 1095 inter-domain path. PCE(i-1), respectively the Parent PCE, MUST 1096 propagate the PCRpt message if the modification implies the upstream 1097 domain, e.g. if the PCRpt indicates that the Stitching Label SL(i) 1098 has changed. 1100 PCE(1), respectively the Parent PCE, could modify the inter-domain 1101 path. For that purpose, it MUST send a PCUpd message to its neighbor 1102 PCEs, respectively Child PCE, using the PLSP-ID it received. Each 1103 PCE(i) MUST process the PCUpd message the same way they process the 1104 PCInitiate message as define in section 3.1 for the Backward 1105 Recursive method and in section 4.1 for the Hierarchical method. 1107 In case a failure appear in domain(i), e.g. path becoming down, 1108 PCE(i) MUST sends a PCRpt message to its neighbor PCE(i-1), 1109 respectively its Parent PCE to advertise the problem in its local 1110 part of the inter-domain path. Once PCE(1), respectively the Parent 1111 PCE, receives this PCRpt message indicating that the path is down, it 1112 is up to the PCE(1), respectively the Parent PCE to take appropriate 1113 correction e.g. start a new path computation to update the ERO. 1115 5.5. Modification of Inter-domain Paths 1117 Modification of local path, BN-en(i) and BN-ex(i) is left for further 1118 study. 1120 5.6. Tear-Down of Inter-domain Paths 1122 The tear-down of an inter-domain path is only possible by the inter- 1123 domain path initiator i.e. PCE(1). For the Backward Recursive 1124 method, a PCInitiate message with R flag set to 1, PLSP-ID set 1125 accordingly to section 5.1 and the Association Object with R flag set 1126 to 1, is sent by PCE(1) to PCE(n) through PCE(i), and processed the 1127 same way as described in section 3.1. For the Hierarchical method, a 1128 PCInitiate message with R flag set to 1 is sent by the Parent PCE to 1129 each Child PCE(i) with corresponding PLSP-ID(i), and processed 1130 according to section 4.1. Each domain PCE(i) is responsible to tear 1131 down its part of the path and the PCC MUST release both the Stitching 1132 label SL in its L(F)IB and the path when it receives the PCInitiate 1133 message with the R flag set to 1 and the corresponding PLSP-ID. The 1134 Association Group MUST also be removed by the PCC and PCE(i). 1136 6. Applicability 1138 The newly introduce Stitching Label SL serves to stitch or nest part 1139 of local paths to form an inter-domain path. Each domain is free to 1140 decide if the incoming path is stitched or nested and how the path is 1141 enforced, e.g. through RSVP-TE or Segment Routing. At the peering 1142 point, the Border Node BN-ex(i) MUST encapsulate the packet with the 1143 Stitching Label, i.e. the MPLS label prior to send them to the next 1144 Border Node BN-en(i+1). Thus, only RSVP-TE and Segment Routing over 1145 MPLS technology are detailed in the following sections. 1147 6.1. RSVP-TE 1149 In case of RSVP-TE, the Border Node BN-ex(i) needs to received the 1150 Stitching Label from BN-en(i) through the RSVP-TE message and install 1151 in its L(F)IB a SWAP instruction to the Stitching Label and forward 1152 it to the next Border Node BN-en(i+1). For that purpose, the Egress 1153 Control mechanism, as per RFC4003 section 2.1 [RFC4003], is 1154 RECOMMENDED to instruct the Border Node BN-ex(i) of this action. 1155 Other mechanisms to program the L(F)IB could be used, e.g. NETCONF. 1157 As the Stitching Label could serves to stitch or nest tunnels, a 1158 domain(i) may decide to nest the incoming LSPs into a higher 1159 hierarchy of LSPs for a Traffic Engineering purpose. A PCE(i) may 1160 also decide to group local LSPs part of inter-domain paths into a 1161 higher hierarchical LSP to carry all these local paths from a BN- 1162 en(i) to a BN-ex(i). 1164 6.2. Segment Routing 1166 To use Segment Routing instead of RSVP-TE to set up the local LSP 1167 tunnels as defined in [RFC8664], PCE(i) MUST send a PCInitiate 1168 message with PST = TBD3 instead of TBD2 to advertise its respective 1169 PCC that the local path is enforce by means of Segment Routing. 1171 The Stitching Label SL(i+1) will be inserted into the label stack in 1172 order to become the top label in the stack when the packet reaches 1173 BN-en(i+1). Thus, the Stitching Label SL(i+1) serves as a FEC entry 1174 for BN-en(i+1) to identify the packets that follow the next Segment 1175 Path. For that purpose, BN-en(i+1) MUST install in its MPLS L(F)IB 1176 an instruction to replace the incoming Stitching Label SL(i+1) by the 1177 label stack given by the ERO(i+1) plus the Stitching Label SL(i+2), 1178 if any. 1180 When a packet reaches BN-ex(i), the last label in the stack before 1181 the label SL(i+1) corresponds to a SID that allows to reach BN- 1182 en(i+1). When there are multiple interfaces between Border Nodes, 1183 BN-ex(i) needs to know how to send the packets to BN-en(i+1). 1184 Similarly to the Egress Control mechanism used with RSVP-TE, it is 1185 RECOMMENDED to use the inter-domain SID defined as per draft Egress 1186 Peer Engineering [I-D.ietf-idr-bgpls-segment-routing-epe] for that 1187 purpose. The inter-domain SID is announced by BN-ex(i) to PCE(i) 1188 through BGP-LS for each interface that connect BN-ex(i) to neighbors 1189 BN-en(i+1). Thus, the label stack will end with {BN-ex(i) SID, 1190 Inter-Domain SID, SL(i+1)} and should be processed as follows: 1192 o The penultimate router of domain(i) pops its node SID, and sends 1193 the packet to the next node designated by the top label in the 1194 label stack, i.e. the node SID of BN-ex(i) or the adjacency SID of 1195 the link between the router and BN-ex(i). 1197 o BN-ex(i) pops its node SID or its adjacency SID and looks up the 1198 next label in the stack, i.e. the inter-domain SID which 1199 corresponds to the interface to BN-en(i+1). BN-ex(i) pops this 1200 inter-domain SID as well and sends the packet to BN-ex(i) through 1201 the corresponding interface. 1203 o BN-en(i+1) looks up the top label which is the Stitching Label 1204 SL(i+1), pops it and replaces it by the sub-sequent label stack. 1206 Other mechanisms, e.g. NETCONF, could be used to configure the 1207 inter-domain SID on exit Border Nodes. 1209 6.3. Mixing Technologies 1211 During the instantiation procedure, if PCE(i) decides to reuse a 1212 local tunnel which is not yet part of an inter-domain tunnel, it 1213 SHOULD send a PCUpd message with PST = TBD2 to the PCC BN-en(i), in 1214 order to request a Stitching Label SL(i), and new ERO(i) to add the 1215 Stitching Label SL(i+1) and the associated link to the previous ERO. 1217 [RFC8453] describes framework for Abstraction and Control of TE 1218 Networks (ACTN), where each Physical Network Controller (PNC) is 1219 equivalent to C-PCE and the Multi-Domain Service Coordinator (MDSC) 1220 to the P-PCE. The per-domain stitched LSP as per the Hierarchical 1221 PCE architecture described in Section 3.3.1 and Section 4.1 of 1222 [RFC8751] is well suited for ACTN. The Stitching Label mechanism as 1223 described in this document is well suited for ACTN when per-domain 1224 LSPs need to be stitched to form an E2E tunnel or a VN Member. It is 1225 to be noted that certain VNs require isolation from other clients. 1226 The SL mechanism described in this document can be applicable to the 1227 VN isolation use-case by uniquely identifying the concatenated 1228 stitching labels across multi-domain only to a certain VN member or 1229 an E2E tunnel. 1231 As each operator is free to enforce the tunnel with its technology 1232 choice, it is a local policy decision for PCE(i) to instantiate the 1233 local part of the end-to-end tunnel by either RSVP-TE or Segment 1234 Routing. Thus, the PST value (i.e. TBD2 or TBD3) used in the 1235 PCinitiate message sent by the PCE(i) to the local PCC is determined 1236 by the local policy. How the local policy decision is set in the PCE 1237 is out of the scope of this memo. This flexibility is allowed 1238 because the SL principle allows to mix (data plane) technologies 1239 between domains. For example, a domain(i) could use RSVP-TE while 1240 domain(i+1) uses SR. The SL could serve to stitch indifferently 1241 Segment Paths and RSVP-TE tunnels. Indeed, the SL will be part of 1242 the label stack in order to become the top label in the stack when 1243 reaching the BN-en(i+1). This SL could be swapped as usual if the 1244 next domain uses RSVP-TE tunnels. When the upstream domain uses an 1245 RSVP-TE tunnel, the SL will serve as a key for the BN-en(i+1) to 1246 determine which label stack it must use on top of the packet for a 1247 Segment Routing path. 1249 6.4. Inter-Area 1251 If use cases for inter-AS are easily identifiable, this is less 1252 evident for inter-area. However, two scenarios have been identified: 1254 o Paths between levels for IS-IS networks. 1256 o Reduction of labels stack depth for Segment Routing. 1258 Thus, the SL could be used to stitch or nest independent tunnels 1259 deployed through different IS-IS levels, even if there are controlled 1260 by the same PCE. IS-IS levels are considered as domains but under 1261 the control of the same PCE. In this scenario, there is no exchange 1262 between PCEs (it remains internal and implementation matter) and new 1263 TLVs are only applicable between the PCE and PCCs. The PCE requests 1264 to the different PCCs it identifies (i.e. BNs of the different IS-IS 1265 levels) to set up SLs and propagated them. 1267 In large-scale networks, MSD could constraints the path computation 1268 in the possibility of path selection i.e. explicit expression of a 1269 path could exceeded the MSD. The SL could be used to split a too 1270 long explicit path regarding the MSD constraints. In this scenario, 1271 there is also no communications between PCEs and new TLVs are only 1272 used between PCE and PCCs. 1274 7. IANA Considerations 1276 7.1. Path Setup Type Values 1278 [RFC8408] defines the PATH-SETUP-TYPE TLV. IANA is requested to 1279 allocate new code points in the PCEP PATH-SETUP-TYPE TLV PST field 1280 registry, as follows: 1282 +-------+-----------------------------------------------+-----------+ 1283 | Value | Description | Reference | 1284 +-------+-----------------------------------------------+-----------+ 1285 | TBD1 | Inter-domain TE end-to-end path is set up | This | 1286 | | using the Backward Recursive method | Document | 1287 | TBD2 | Inter-domain TE local path is set up using | This | 1288 | | RSVP-TE signaling | Document | 1289 | TBD3 | Inter-domain TE local path is set up using | This | 1290 | | Segment Routing | Document | 1291 +-------+-----------------------------------------------+-----------+ 1293 7.2. Association Type Value 1295 PCE Association Group [RFC8697] defines the ASSOCIATION Object and 1296 requests that IANA creates a registry to manage the value of the 1297 Association Type value. IANA is requested to allocate a new code 1298 point in the PCEP ASSOCIATION GROUP TLV Association Type field 1299 registry, as follows: 1301 +------------------+--------------------------------+ 1302 | Association Type | Description | 1303 +------------------+--------------------------------+ 1304 | TBD4 | Inter-domain Association Group | 1305 +------------------+--------------------------------+ 1307 7.3. PCEP Error Values 1309 IANA is requested to allocate code-points in the PCEP-ERROR Object 1310 Error Values registry for a new error-value of Error-Type 21 Invalid 1311 TE path setup and new error-value of Error-Type 26 Association Error: 1313 +------------+-------------+----------------------------------------+ 1314 | Error-Type | Error-Value | Description | 1315 +------------+-------------+----------------------------------------+ 1316 | 21 | TBD5 | Mandatory Stitching Label missing in | 1317 | | | the RRO | 1318 | 26 | TBD6 | Error in association of Inter-domain | 1319 | | | LSPs | 1320 +------------+-------------+----------------------------------------+ 1322 7.4. PCEP TLV Type Indicators 1324 IANA is requested to allocate a new TLV Type Indicator for the 1325 "Stitching Label PCE Capability" within the "PCEP TLV Type 1326 Indicators" subregistry of the "Path Computation Element Protocol 1327 (PCEP) Numbers" registry: 1329 +-------+--------------------------------+---------------+ 1330 | Value | Description | Reference | 1331 +-------+--------------------------------+---------------+ 1332 | TBD7 | STITCHING-LABEL-PCE-CAPABILITY | This Document | 1333 +-------+--------------------------------+---------------+ 1335 7.5. Stitching Label PCE Capability 1337 IANA is requested to allocate a new subregistry, named "STITCHING- 1338 LABEL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation 1339 Element Protocol (PCEP) Numbers" registry, to manage the Flag field 1340 in the STITCHING-LABEL-PCE-CAPABILITY TLV of the PCEP OPEN object 1341 (class = 1). New values are assigned by Standards Action [RFC8126]. 1342 Each bit should be tracked with the following qualities: 1344 o Bit number (counting from bit 0 as the most significant bit) 1346 o Capability description 1348 o Defining RFC 1349 +-------+--------------------------------------+---------------+ 1350 | Value | Description | Reference | 1351 +-------+--------------------------------------+---------------+ 1352 | 31 | RSVP-TE-STITCHING-CAPABILITY | This Document | 1353 | 30 | SEGMENT-ROUTING-STITCHING-CAPABILITY | This Document | 1354 | 29 | INTER-DOMAIN-STITCHING-CAPABILITY | This Document | 1355 +-------+--------------------------------------+---------------+ 1357 8. Security Considerations 1359 No modification of PCE protocol (PCEP) has been requested by this 1360 draft which does not introduce any issue regarding security. 1361 Concerning the PCEP session between PCEs, authors recommend to use 1362 the secured version of PCEP as defined in PCEPS [RFC8253] or use any 1363 other secured tunnel mechanism, e.g. IPsec tunnel to transport PCEP 1364 session between PCEs. 1366 9. Acknowledgements 1368 The authors want to thanks PCE's WG members, and in particular Dhruv 1369 Dhody who greatly contributed to the Hierarchical section of this 1370 document and Quan Xiong for his advice. 1372 10. Disclaimer 1374 This work has been performed in the framework of the H2020-ICT-2014 1375 project 5GEx (Grant Agreement no. 671636), which is partially funded 1376 by the European Commission. This information reflects the 1377 consortium's view, but neither the consortium nor the European 1378 Commission are liable for any use that may be done of the information 1379 contained therein. 1381 11. References 1383 11.1. Normative References 1385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1386 Requirement Levels", BCP 14, RFC 2119, 1387 DOI 10.17487/RFC2119, March 1997, 1388 . 1390 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1391 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1392 DOI 10.17487/RFC5440, March 2009, 1393 . 1395 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1396 "A Backward-Recursive PCE-Based Computation (BRPC) 1397 Procedure to Compute Shortest Constrained Inter-Domain 1398 Traffic Engineering Label Switched Paths", RFC 5441, 1399 DOI 10.17487/RFC5441, April 2009, 1400 . 1402 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1403 Computation Element Communication Protocol (PCEP) 1404 Extensions for Stateful PCE", RFC 8231, 1405 DOI 10.17487/RFC8231, September 2017, 1406 . 1408 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1409 Computation Element Communication Protocol (PCEP) 1410 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1411 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1412 . 1414 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1415 Hardwick, "Conveying Path Setup Type in PCE Communication 1416 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1417 July 2018, . 1419 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1420 Dhody, D., and Y. Tanaka, "Path Computation Element 1421 Communication Protocol (PCEP) Extensions for Establishing 1422 Relationships between Sets of Label Switched Paths 1423 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1424 . 1426 11.2. Informative References 1428 [I-D.dong-pce-discovery-proto-bgp] 1429 Dong, J., Chen, M., Dhody, D., Tantsura, J., Kumaki, K., 1430 and T. Murai, "BGP Extensions for Path Computation Element 1431 (PCE) Discovery", draft-dong-pce-discovery-proto-bgp-07 1432 (work in progress), July 2017. 1434 [I-D.ietf-idr-bgpls-segment-routing-epe] 1435 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1436 S., and J. Dong, "BGP-LS extensions for Segment Routing 1437 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1438 segment-routing-epe-19 (work in progress), May 2019. 1440 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1441 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1442 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1443 . 1445 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1446 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1447 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1448 DOI 10.17487/RFC3473, January 2003, 1449 . 1451 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1452 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1453 . 1455 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1456 Hierarchy with Generalized Multi-Protocol Label Switching 1457 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1458 DOI 10.17487/RFC4206, October 2005, 1459 . 1461 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1462 Element (PCE)-Based Architecture", RFC 4655, 1463 DOI 10.17487/RFC4655, August 2006, 1464 . 1466 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 1467 "Label Switched Path Stitching with Generalized 1468 Multiprotocol Label Switching Traffic Engineering (GMPLS 1469 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 1470 . 1472 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1473 "Preserving Topology Confidentiality in Inter-Domain Path 1474 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1475 DOI 10.17487/RFC5520, April 2009, 1476 . 1478 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1479 Path Computation Element Architecture to the Determination 1480 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1481 DOI 10.17487/RFC6805, November 2012, 1482 . 1484 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1485 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1486 Path Computation Element Communication Protocol (PCEP)", 1487 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1488 . 1490 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1491 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1492 DOI 10.17487/RFC8453, August 2018, 1493 . 1495 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1496 and J. Hardwick, "Path Computation Element Communication 1497 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1498 DOI 10.17487/RFC8664, December 2019, 1499 . 1501 [RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 1502 "Hierarchical Stateful Path Computation Element (PCE)", 1503 RFC 8751, DOI 10.17487/RFC8751, March 2020, 1504 . 1506 Authors' Addresses 1508 Olivier Dugeon 1509 Orange Labs 1510 2, Avenue Pierre Marzin 1511 Lannion 22307 1512 France 1514 Email: olivier.dugeon@orange.com 1516 Julien Meuric 1517 Orange Labs 1518 2, Avenue Pierre Marzin 1519 Lannion 22307 1520 France 1522 Email: julien.meuric@orange.com 1523 Young Lee 1524 Huawei Technologies 1525 5340 Legacy Drive, Building 3 1526 Plano TX 75023 1527 USA 1529 Email: leeyoung@huwaei.com 1531 Daniele Ceccarelli 1532 Ericsson 1533 Torshamnsgatan, 48 1534 Stockholm 1535 Sweden 1537 Email: daniele.ceccarelli@ericsson.com