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