idnits 2.17.1 draft-dugeon-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 (March 04, 2019) is 1879 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) == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-07 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-17 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 Summary: 0 errors (**), 0 flaws (~~), 4 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: September 5, 2019 Y. Lee 6 Huawei Technologies 7 D. Ceccarelli 8 Ericsson 9 March 04, 2019 11 PCEP Extension for Stateful Inter-Domain Tunnels 12 draft-dugeon-pce-stateful-interdomain-02 14 Abstract 16 This document proposes to combine a Backward Recursive or 17 Hierarchical method in Stateful PCE with PCInitiate message to setup 18 independent paths per domain, and combine these different paths 19 together in order to operate them as end-to-end inter-domain paths 20 without the need of signaling session between AS border routers. A 21 new Stitching Label is defined, new Path Setup Types and a new 22 Association Type are considered for that purpose. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 5, 2019. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. General assumptions . . . . . . . . . . . . . . . . . . . 5 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 67 2. Stitching Label . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.2. Inter-domain LSP-TYPE . . . . . . . . . . . . . . . . . . 8 70 3. Backward Recursive PCInitiate procedure . . . . . . . . . . . 9 71 3.1. Mode of operation . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.3. Inter-domain LSP setup procedure completion failure . . . 13 74 4. Hierarchical PCInitiate procedure . . . . . . . . . . . . . . 14 75 4.1. Mode of operation . . . . . . . . . . . . . . . . . . . . 14 76 4.2. Inter-domain LSP setup procedure completion failure . . . 16 77 4.3. Example for Stateful H-PCE Stiching procedure . . . . . . 17 78 5. Inter-domain LSP Management . . . . . . . . . . . . . . . . . 21 79 5.1. Identification of inter-domain tunnels . . . . . . . . . 21 80 5.2. Inter-domain association group . . . . . . . . . . . . . 21 81 5.3. Inter-domain LSP management . . . . . . . . . . . . . . . 22 82 5.4. Modification of inter-domain LSP . . . . . . . . . . . . 23 83 5.5. Removal of inter-domain LSP . . . . . . . . . . . . . . . 23 84 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 24 85 6.1. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 6.2. Segment Routing . . . . . . . . . . . . . . . . . . . . . 24 87 6.3. Mixing technology . . . . . . . . . . . . . . . . . . . . 25 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 7.1. Path Setup Type values . . . . . . . . . . . . . . . . . 26 90 7.2. Association Type value . . . . . . . . . . . . . . . . . 27 91 7.3. PCEP Error values . . . . . . . . . . . . . . . . . . . . 27 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 94 10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 97 11.2. Informative References . . . . . . . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 The Path Computation Element (PCE) working group (WG) has produced a 103 set of RFCs to standardize the behavior of the Path Computation 104 Element as a tool to help MPLS-TE, GMPLS LSP tunnels and Segment 105 Routing paths placement. This also includes the ability to compute 106 inter-domain LSPs or Segment Routing paths following a distributed or 107 hierarchical approach. To complement the original stateless mode, a 108 stateful mode has been added. In particular, the new PCInitiate 109 message allows a PCE to directly ask a PCC to setup an MPLS-TE, GMPLS 110 LSP tunnel or a Segment Routing path. However, once computed, the 111 inter-domain LSPs or Segment Routing path are hard to setup in the 112 underlying network. Especially, in operational network, RSVP-TE 113 signaling is not enabled between AS border routers. But, such RSVP- 114 TE signaling is mandatory to setup contiguous LSP tunnels or to 115 stitch or nest independent LSP tunnels to form the end-to-end inter- 116 domain paths. 118 Looking to the different RFCs that describe the PCE architecture and 119 in particular PCE based architecture [RFC4655], PCE protocol 120 [RFC5440], BRPC [RFC5441] and H-PCE [RFC6805], the Path Computation 121 Element (PCE) is able to compute inter-domain paths in complement to 122 intra-domain computation. Such inter-domain paths could then serve 123 as the Explicit Route Object input for the RSVP-TE signaling to setup 124 the tunnels within the underlying network. Three kinds of inter- 125 domain paths could be established: 127 o Contiguous tunnel ([RFC3209] and [RFC3473]): The RSVP-TE signaling 128 crosses the boundary between two domains, e.g. between two AS 129 Border Routers (ASBRs) as if they were two routers of the same 130 domain. This kind of tunnel is not recommended mostly for 131 security and scalability purpose. In addition, the initiating 132 domain imposes huge constraints on subsequent domains, because 133 they undergo the tunnel request without being able to control it. 135 o Stitching tunnel ([RFC5150]): Each domain establishes in its own 136 network the corresponding part of the inter-domain path 137 independently. Then, a second end-to-end RSVP-TE Path message is 138 sent by the initiating domain to stitch the different tunnel parts 139 to form the inter-domain path. In fact, this second RSVP-TE Path 140 message is used by border nodes to exchange the label that must be 141 used by the previous domain to send the traffic in order that the 142 MPLS packets follow the next LSP tunnel in the following domain. 143 These labels are conveyed in the RSVP-TE Resv message. 145 o Nesting tunnel ([RFC4206]): This is similar to the stitching mode 146 but, this time, with the possibility to setup tunnel hierarchy. 147 For example, an LSP tunnel between two edge domains crossing a 148 transit domain could be carried over a tunnel of a higher level in 149 the transit domain. Again, a second end-to-end RSVP-TE Path 150 message is sent from the source to the destination. Labels that 151 must be used by the ASBRs of transit domains to identify flows to 152 be nested are carried by the RSVP-TE Resv message. 154 In all case, RSVP-TE signaling must be exchanged between the 155 different domains. However, from an operational point of view, 156 looking to different networks under the responsibility of different 157 administrative entities, only BGP sessions are setup and configured 158 between ASBRs. Technologically speaking, this is possible and many 159 RFCs describe how to use RSVP-TE for inter-domain. But, due to 160 security, scalability, management and contract constraints, RSVP-TE 161 is not exposed at the network boundary. To circumvent some of the 162 security issues, RSVP-TE can be carried inside an IPsec tunnel 163 between ASBRs, but, this does not eliminate the scalability aspect 164 nor the constraints imposed by setting up inter-domain paths. 166 The purpose of this memo is to take the benefit of PCE Stateful 167 [RFC8231] and PCE Initiated [RFC8281] modes to stitch or nest inter- 168 domain paths directly using PCEP between domains' PCEs instead of 169 using RSVP-TE signaling at the inter-domain border nodes, while 170 keeping each operator free to independently setup their respective 171 part of the inter-domain paths. PCInitiate message is used in a 172 Backward Recursive way like the PCReq message in BRPC [RFC5441], to 173 recursively setup the end-to-end tunnel. PCRep message is used to 174 automatically stitch or nest the different local LSP tunnels. And, 175 PCRep in conjunction of PCUpd messages are used to maintain, modify 176 and remove inter-domain paths. This method is also applicable to 177 Segment Routing to build inter-domain segment paths. 179 H-PCE [RFC6805] describes a Hierarchical PCE architecture which can 180 be used for computing end-to-end paths for inter-domain MPLS Traffic 181 Engineering (TE) and GMPLS Label Switched Paths (LSPs). Within this 182 architecture, the Parent PCE (P-PCE) is used to compute a multi- 183 domain path based on the domain connectivity information. A Child 184 PCE (C-PCE) may be responsible for a single domain or multiple 185 domains, it is used to compute the intra-domain path based on its 186 domain topology information. 188 Stateful H-PCE [I-D.ietf-pce-stateful-hpce] presents general 189 considerations for stateful PCE(s) in hierarchical PCE architecture. 191 In particular, the behavior changes and additions to the existing 192 stateful PCE mechanisms (including PCE-initiated LSP setup and active 193 PCE usage) in the context of networks using the H-PCE architecture. 194 Section 3.3.1 [I-D.ietf-pce-stateful-hpce] describes the per domain 195 stitched LSP mode, where the individual per domain LSP are stitched 196 together. PCInitiate message is also used to stitch the end-to-end 197 tunnel. See section 4 for details. 199 1.1. General assumptions 201 In the rest of this document, we used the same references as per BRPC 202 [RFC5441] and make the following set of assumptions (see figure 203 below): 205 o Domain refers to an IGP area or an Autonomous System (AS). 207 o Inter-domain path is used to refer to a path that cross two or 208 more different domains as defined previously, 210 o At least, one PCE is deployed in each domain. These PCE are all 211 stateful active capable and could request to enforce LSP tunnels 212 in their respective domain by means of PCInitiate messages. 214 o LSRs, including border nodes, are PCC enable and support stateful 215 active mode. PCEP sessions is established between these routers 216 and their domains' PCE. 218 o Each PCE establishes a PCEP session with its respective neighbor 219 domain's PCE. The way a PCE discover its neighboring PCE is out 220 of scope of this draft. These information could be fulfill 221 administratively or automatically discovered through, for example 222 per draft 'BGP Extensions for Path Computation Element (PCE) 223 Discovery' [I-D.dong-pce-discovery-proto-bgp]. 225 o PCEs are able to compute and end-o-end path as per BRPC procedure 226 [RFC5441] or as per H-PCE procedure (stateless [RFC6805] or 227 stateful [I-D.ietf-pce-stateful-hpce]). 229 o Tunnels refer to LSPs setup by mean of RSVP-TE or Segment Path in 230 a Segment Routing network. 232 +----------------+ +----------------+ 233 | Domain (B) | | Domain (C) | 234 | | | | 235 | /-------|---PCEP---|--------\ | 236 | / | | \ | 237 | (PCE) | | (PCE) | 238 | / (BN)<------>(BN) | 239 | / | Inter | | 240 +---|--(BN)------+ Domain +----------------+ 241 | ^ Link 242 PCEP | 243 | | Inter-domain Link 244 | v 245 +---|--(BN)------+ 246 | | | 247 | | Domain (A) | 248 | \ | 249 | (PCE) | 250 | | 251 | | 252 +----------------+ 254 Example of the representation of 3 domains with 3 PCEs 256 1.2. Terminology 258 ABR: Area Border Routers. Routers used to connect two IGP areas 259 (areas in OSPF or levels in IS-IS). 261 AS: Autonomous System 263 ASBR: Autonomous System Border Router. Router used to connect 264 together ASes of the same or different service providers via one or 265 more inter-AS links. 267 Border Node (BN): a boundary node is either an ABR in the context of 268 inter-area Traffic Engineering or an ASBR in the context of inter-AS 269 Traffic Engineering. 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 serves to identify which of the multiple links will be used for the 293 inter-domain LSP setup. 295 Local LSP tunnel: A LSP tunnel that do not cross a domain. It is 296 setup between entry BN-en to output BN-ex, any source to output BN-ex 297 or entry BN-en to any destination of the same domain. This LSP could 298 be enforce by means of RSVP-TE signaling or Segment Routing labels 299 stack. 301 Local LSP tunnel(i): A local LSP tunnel of domain(i) 303 PLSP-ID(i): A PLSP-ID that identify the local tunnel part of an 304 inter-domain tunnel in the domain(i). 306 PCE: Path Computation Element. An entity (component, application, or 307 network node) that is capable of computing a network path or route 308 based on a network graph and applying computational constraints. 310 PCE(i) is a PCE with the scope of domain(i). 312 PST: Path Setup Type 314 R(i,j): The router j of domain i 316 Stitching Label (SL): A dedicated label that is used to stitch two 317 RSVP-TE tunnels or two Segment Routing paths. 319 SL(i): A Stitching Label that link domain(i-1) to domain(i). 321 2. Stitching Label 323 This section introduce the concept of Stitching Label that allows 324 stitching and nesting of local LSP tunnels in order to form inter- 325 domain path that cross several different domains. 327 2.1. Definition 329 The operation of stitch or nest a local LSP tunnel(i) to a local LSP 330 tunnel(i+1) in order to form and inter-domain path simply consist in 331 defining the label that the output BN-ex(i) will use to send its 332 traffic to the entry BN-en(i+1). Indeed, the entry BN-en(i+1) needs 333 to identify the incoming traffic i.e. IP packets, in order to know if 334 this traffic must follow the local LSP tunnel(i+1) or not. 335 Forwarding Equivalent Class (FEC) could be used for that purpose. 336 But, when stitching or nesting tunnels, the FEC is reduce to the 337 incoming label that the entry BN-en(i+1) as chosen for the local LSP 338 tunnel(i+1). 340 In this memo, we introduce the named of 'Stitching Label (SL)' to 341 designate this label. Such label is usually exchange between output 342 BN-ex(i) and entry BN-en(i+1) with the RSVP-TE signaling. But, as we 343 want to avoid to use RSVP-TE signaling due to operational 344 constraints, this Stitching Label will be convey by PCEP protocol. 345 In fact, the Explicit Route Object (ERO) and the Record Route Object 346 (RRO) are defined in order to transport this Stitching Label in the 347 RSVP-TE signaling. As PCEP protocol used RSVP-TE Objects, and in 348 particular the ERO and RRO, it is able to convey the Stitching Label 349 without any modification of the PCEP protocol nor the PCE or RSVP-TE 350 Objects. 352 As per RFC4003 [RFC4003], the Stitching Label will be convey as a 353 companion of an IP address. In our case, this is one of the IP 354 address of the link LK(i) which connects BN-ex(i) to BN-en(i+1) and 355 carries the traffic from the domain(i) to domain(i+1). It is left to 356 implementation to select which of the two IP address of the link 357 LK(i) is used. 359 2.2. Inter-domain LSP-TYPE 361 However, even if PCEP could convey the Stitching Label, a PCC is not 362 aware that a PCE requests or provides such label. For that purpose, 363 this memo propose to use the PST as defined in [RFC8408] with new 364 values (See IANA section of this memo) defined as follow: 366 o TBD1: Inter-Domain Traffic engineering end-to-end path is setup 367 using Backward Recursive or Hierarchical method. This new PST 368 value MUST be set in a PCInitiate messages sends by a PCE(i) to 369 its neighbor PCE(i+1) in the Backward Recursive method or by the 370 Parent PCE to the Child PCE(i) to initiate a new inter-domain 371 path. In turn, neighbor PCE(i+1) or Child PCE(i) MUST return a 372 Stitching Label SL with the IP address of the associated link in 373 the RRO of the PCRpt message to PCE(i) or Parent PCE. 375 o TBD2: Inter-Domain Traffic engineering local path is setup using 376 RSVP-TE. This new PST value MUST be set in the PCInitiate message 377 sends by a PCE(i) requesting to a PCC of domain(i) to initiate a 378 new local LSP tunnel(i) which is part of an inter-domain path. 379 This PST value MUST be used by the PCE(i) only after receiving a 380 PCInitiate message with an PST equal to TBD1 from a neighbor 381 PCE(i+1) in the Backward Recursive method or Parent PCE in the 382 Hierarchical method. In turn, the PCC of domain(i) MUST return a 383 Stitching Label SL with the IP address of associated link in the 384 RRO of the PCRpt message. 386 o TBD3: Inter-Domain Traffic engineering local path is setup using 387 Segment Routing. This new PST value MUST be set in the PCInitiate 388 message sends by a PCE(i) requesting to a PCC of domain(i) to 389 initiate a new Segment Routing path which is part of and inter- 390 domain Segment Routing path. This PST value MUST be used by the 391 PCE(i) only after receiving a PCInitiate message with an PST equal 392 to TBD1 from a neighbor PCE(i+1). In turn, the PCC MUST return a 393 Stitching Label SL with the IP address of the associated link in 394 the RRO of the PCRpt message. 396 3. Backward Recursive PCInitiate procedure 398 This section describes how to setup inter-domain paths than cross 399 several different domains by using a Backward Recursive method which 400 is compatible to inter-domain path computation by means of the BRPC 401 procedure as describe in RFC5441 [RFC5441]. 403 3.1. Mode of operation 405 This section describes how PCInitiate and PCRpt messages are combined 406 between PCE in order to setup inter-domain paths between a source 407 domain(1) to a destination domain(n). S and D are respectively the 408 source and destination of the inter-domain path. Domain(1) and 409 domain(n) are different and connected through 0 or more intermediate 410 domains denoted domain(i) with i = (2, n-1). Domains are directly 411 connected when n = 2. 413 First, the PCE(1) runs standard BRPC algorithm as per RFC5441 414 [RFC5441] with its neighbor PCEs in order to compute the inter-domain 415 path from S to D, where S and D are respectively a node in the 416 domain(1) and domain(n). Path Key confidentiality as per RFC5520 417 [RFC5520] SHOULD be used to obfuscate the detailed ERO(i) of the 418 different domains(i). The resulting ERO is of the form {S, PKS(1), 419 BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), ..., BN-en(n), PKS(n), D} 420 when Path Key is used and of the form {S, R(1,1), ..., R(1,k), BN- 421 ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), BN-ex(i), ..., BN-en(n), 422 R(n,1), ..., R(n,m), D} otherwise . As subsequent domains are not 423 aware about the final computed ERO in case of multiple VSPTs, the 424 final ERO selected by the PCE(1) MUST be sent in the PCInitiate 425 message to indicate to the subsequent PCEs which solution has been 426 finally chosen. PCE(1) MUST ensure that this ERO is self 427 comprehensive by subsequent PCEs. Indeed, when a PCE(i) receives the 428 ERO, it MUST be able to verify that it is in the scope of this ERO 429 and to determine the PCE(i+1). When Path Key is used, PCEs MUST 430 encode the Path Key with a reachable IP address in order for previous 431 PCEs in the AS chain to join them. When Path Key is not used, the 432 PCEs MUST be able to retrieve IP address of the next PCE from the 433 ERO. 435 The complete procedure with Path Key follow the different steps 436 described below: 438 Steps 1: Initialization 440 Once ERO(S, D) is computed, PCE(1) sends a PCInitiate message to 441 PCE(2) containing an ERO equal to {S, PKS(2), ..., PKS(i), ..., 442 PKS(n), D}, PST = TBD1 and End-Points Object = (S, D). The ERO 443 corresponds to the one PCE(1) has received from PCE(2) during the 444 BRPC process in which only Path Key are kept. In case of multiple 445 EROs, i.e. VSPT, PCE(1) has chosen one of them and used the selected 446 one for the PCInitiate message. PKS(i) could be replaced by the full 447 ERO description if Path Key is not used by PCE(i). 449 When PCE(i) receives a PCInitiate message from domain(i-1) with PST = 450 TBD1 and ERO = {PKS(i), PKS(i+1), ..., PKS(n), D)}, it sends a 451 PCInitiate message to PCE(i+1) with a popped ERO and records its 452 received PKS(i) part. All PCE(i)s generate the appropriate 453 PCInitiate message to PCE(i+1) up to PCE(n), i.e. to the destination 454 domain(n). 456 Steps 2: Actions taken at the destination domain(n) by PCE(n) 458 When PCInitiate message propagation reach the destination domain(n), 459 PCE(n) retrieves the ERO from the PKS(n) if necessary and sends to 460 BN-en(n) a PCInitiate message with the ERO(n) = {BN-en(n), ..., D}, 461 PST = TBD2 and End-Points Object = {BN(n), D} in order to inform the 462 PCC BN-en(n) that this local LSP tunnel(n) is part of an inter-domain 463 path. When the PCC BN-en(n) received the PCInitiate message from its 464 PCE(n), it setup the local LSP tunnels from entry BN-en(n) to D by 465 means of RSVP-TE signaling with the given ERO(n). Once the tunnel 466 setup, it chooses a free label for the Stitching Label SL(n) and add 467 a new entry in its MPLS L(F)IB with this SL(n) label. Then, it sends 468 a PCRpt message to its PCE(n) with an RRO equal to {[LK(n), SL(n)], 469 RRO(n)} and PLSP-ID(n). Once PCE(n) receives the PCRpt from the PCC 470 BN-en(n) with the RRO, PLSP-ID and PST = TBD2, it sends to the 471 PCE(n-1) a PCRpt containing the RRO equal to {[LK(n), SL(n)]} and 472 PLSP-ID(n). PCE(n) MAY add {PKS(n), D} in the RRO. 474 Steps i: Actions performed by all intermediate domains(i), for i = 2 475 to n-1 477 1. When the PCE(i) receives a PCRpt message from domain(i+1) with 478 PST = TBD1, RRO = {[LK(i+1), SL(i+1)]} and PLSP-ID(i+1), it 479 retrieves the ERO(i) from the PKS(i), recorded in step 1, and 480 sends to the PCC BN-en(i) a PCInitiate message with ERO = 481 {ERO(i), [LK(i+1), SL(i+1)]}, PST = TBD2 and End-Points Object = 482 {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) that 483 this local LSP tunnel(i) is part of an inter-domain path. 485 2. When the PCC BN-en(i) received the PCInitiate message from its 486 PCE(i), it setup the local LSP tunnels from BN-en(i) to BN-ex(i) 487 by means of RSVP-TE signaling with the given ERO(i). 489 3. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 490 is used to instruct the egress node of domain(i), i.e. BN-ex(i), 491 to forward packets belonging to this tunnel with the Stitching 492 Label. Both Stitching Label and IP address of outgoing interface 493 are carried in the ERO = {..., [LK(i+1), SL(i+1)]} as the last 494 SubObject in conformance to [RFC4003]. So that, BN-ex(i) 495 installs in its MPLS L(F)IB the SWAP instruction to label SL(i+1) 496 with forward to LK(i+1). 498 4. Once the tunnel setup, PCC BN-en(i) chooses a free label for the 499 Stitching Label SL(i) and adds a new entry in its MPLS L(F)IB 500 with this SL(i) label. Then, it sends a PCRpt message to its 501 PCE(i) with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP- 502 ID(i). 504 5. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 505 and PST = TBD2, it sends to the PCE(i-1) a PCRpt message 506 containing the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). 507 PCE(i) MAY add {PKS(i), ..., PKS(n)} in the RRO. 509 Steps n: Actions performed at the source domain(1) by PCE(1) 511 Once PCE(1) received the PCRpt message from PCE(2) with the RRO 512 containing the label SL(2), it sends a PCInitiate message to PCC node 513 S with ERO equal to {ERO(1), [LK(2), SL(2)]}, PST = 0 and End-Points 514 Object = {S, BN-ex(1)}. This time, the PST is equal to 0 as the PCC S 515 does not need to return a Stitching Label SL, i.e. it is the head-end 516 of the inter-domain path. Standard PCRpt message is sent back to 517 PCE(1) by the PCC node S. 519 3.2. Example 521 In the figure below, two different domains S and D are interconnected 522 through BN respectively BN-S and BN-D. PE-S and PE-D are edge 523 routers. All routers in the figure are connected to their respective 524 PCE through PCEP protocol. In this example, PCE(S) would setup an 525 inter-domain path between PE-S and PE-D acting as source and 526 destination of the tunnel. Intermediate routers between (PE-S, BN- 527 S), (BN-D and PE-D) as well as RSVP-TE messages are not represented 528 to simplify the figure. But they are all presents. The following 529 notation is used in the figure (note that, in this example, we use 530 the PKS for the sake of simplicity): 532 o PKS(D) = Path Key corresponding to the path from BN(D) to PE-D 534 o ERO(D) = Explicit Route Object corresponding to the path from 535 BN(D) to PE-D retrieves from PKS(D) 537 o RRO(D) = Record Route Object of local LSP tunnel(D) from BN(D) to 538 PE-D 540 o SL(D) = Stitching Label for local LSP tunnel from BN(D) to PE-D 542 o ERO(S) = Explicit Route Object corresponding to the path from PE-S 543 to BN(S) 545 o RRO(S) = Record Route Object of local LSP tunnel(S) from PE-S to 546 BN(S) 548 PE-S PCE-S BN-D PCE-D 549 | | | | 550 | [ -------- Standard BRPC exchange ------------] 551 | | | | 552 | | PCInitiate(ERO={PKS(D)}, PST = TBD1) 553 | | --------------------------------------> | 554 | | | | 555 | | PCInitiate(ERO = ERO(D), PST = TBD2) 556 | | | <------- | 557 | | | | 558 | | PCRpt(RRO = {SL(D), RRO(D)}, PST = TBD2) 559 | | | ------> | 560 | | | | 561 | PCRpt(RRO = {SL(D), PKS(D)}, PST = TBD1, PLSP-ID(D)) 562 | | <-------------------------------------- | 563 | | | | 564 | PCInitiate(ERO={ERO(S), SL(D), BN(D)}, PST = 0) 565 | <------- | | | 566 | | | | 567 | PCRpt(RRO={RRO(S)}, PST = 0) | | 568 | -------> | | | 569 | | | | 571 +----------------------+ +----------------------+ 572 | | | | 573 | +------+ | PCEP | +------+ | 574 | +---->|PCE(S)|<-------------------------------->|PCE(D)| | 575 | | +------+ | | +------+ | 576 | | ^ | | ^ ^ | 577 | | | | | | | | 578 | |PCEP | | | | | | 579 | | |PCEP | | PCEP | | PCEP | 580 | v | | | | | | 581 (PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D) 582 | | Inter-Domain | | 583 | Domain (S) | Link | Domain (D) | 584 +----------------------+ +----------------------+ 586 [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---] 588 Example of inter-domain path setup between two domains 590 3.3. Inter-domain LSP setup procedure completion failure 592 In case of error during LSP setup, PCRpt and or PCErr messages MUST 593 be used to signal the problem to the neighbor PCE domain backward. 594 In particular, if new PST values defined in this memo are not 595 supported by the neighbor PCE or the PCC, the PCE, receptively the 596 PCC, MUST return a PCErr message with Error-Type = 21 (Traffic 597 engineering path setup error) and Error-Value = 1 (Unsupported path 598 setup type) to its neighbor PCE. If a PCE(i) receives a PCInitiate 599 message from its peer PCE(i-1) without PST set to TBD1 or PST set to 600 a value different from TBD1, it MUST return a PCErr message with 601 Error-Type = 21 (Traffic engineering path setup error) and Error- 602 Value = 1 (Unsupported path setup type) to its peer PCE(i-1). 604 If a PCC or a PCE don't return an RRO or an RRO without the Stitching 605 Label SL with the IP address of the associated link following a 606 PCInitiate message with PST set to TBD1, the PCE MUST return a PCErr 607 message with Error-Type = 21 (Traffic engineering path setup error) 608 and Error-Value = TBD5 (No Mandatory Stitching Label is present in 609 the RRO). 611 In case of completion failure, the PCE(i) MUST propagate the PCErr 612 message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate 613 message (R flag set in the SRP Object as per draft pce initiated lsp 614 [RFC8281]) to delete this inter-domain path to its neighbor PCEs. 615 PCE(i) MUST propagate the PCInitiate message and remove their local 616 LSP tunnel by means of PCInitiate message to their PCC BN-en(i) and 617 send back PCRpt message to PCE(i-1). 619 In case of error in domain(i+1), PCE(i) MAY add the AS number of 620 domain(i+1) in the RRO to identify the faulty domain. 622 4. Hierarchical PCInitiate procedure 624 This section describes how to setup inter-domain paths than cross 625 several different domains by using a Hierarchical method which is 626 compatible to inter-domain path computation as describe in [RFC6805]. 628 4.1. Mode of operation 630 This section describes how PCInitiate and PCRpt messages are combined 631 between PCE in order to setup inter-domain paths between a source 632 domain(1) to a destination domain(n). S and D are respectively the 633 source and destination of the inter-domain path. Domain(1) and 634 domain(n) are different and connected through 0 or more intermediate 635 domains denoted domain(i) with i = (2, n-1). Domains are directly 636 connected when n = 2. 638 First, the Parent PCE contacts its Child PCE as per [RFC6805] in 639 order to compute the inter-domain path from S to D, where S and D are 640 respectively a node in the domain(1) and domain(n). Path Key 641 confidentiality as per RFC5520 [RFC5520] SHOULD be used to obfuscate 642 the detailed ERO(i) of the different domains(i). The resulting ERO 643 is of the form (S, PKS(1), BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), 644 ..., BN-en(n), PKS(n), D) when Path Key is used and of the form {S, 645 R(1,1), ..., R(1,k), BN-ex(1), ..., BN-en(i), R(i,1), ..., R(i,l), 646 BN-ex(i), ..., BN-en(n), R(n,1), ..., R(n,m), D} otherwise. 648 The complete procedure with Path Key follow the different steps 649 described below: 651 Step 1: Initialization 653 Parent PCE sends a PCInitiate message to child PCE(n) with an ERO = 654 {PKS(n)} and End-Points = {BN-en(n), D}. Then, PCE(n) retrieves the 655 ERO from the PKS(n) if necessary and sends to BN-en(n) a PCInitiate 656 message with the ERO(n) = {BN-en(n), ..., D}, PST = TBD2 and End- 657 Points Object = {BN-en(n), D} in order to inform the PCC BN-en(n) 658 that this local LSP tunnel(n) is part of an inter-domain path. When 659 the PCC BN-en(n) received the PCInitiate message from its PCE(n), it 660 setup the local LSP tunnel from entry BN-en(n) to D by means of RSVP- 661 TE signaling with the given ERO(n). Once the tunnel setup, it 662 chooses a free label for the Stitching Label SL(n) and add a new 663 entry in its MPLS L(F)IB with this SL(n) label. Then, it sends a 664 PCRpt message to its PCE(n) with an RRO equal to {[LK(n), SL(n)], 665 RRO(n)} and PLSP-ID(n). Once PCE(n) receives the PCRpt from the PCC 666 BN-en(n) with the RRO, PLSP-ID and PST = TBD2, it sends to its Parent 667 PCE a PCRpt containing the RRO equal to {[LK(n), SL(n)]} and PLSP- 668 ID(n). PCE(n) MAY add PKS(n) in the RRO. 670 Steps i: Actions performed for all intermediate domains(i), for i = 671 n-1 to 2 673 1. Parent PCE sends a PCInitiate message to Child PCE(i) with PST = 674 TBD1, ERO = {PKS(i), [LK(i+1), SL(i+1)]} and End-Points = {BN- 675 en(i), BN-ex(i)} 677 2. Then, PCE(i) retrieves the ERO from the PKS(i) if necessary and 678 sends to the PCC BN-en(i) a PCInitiate message with ERO = 679 {ERO(i), [LK(i+1), SL(i+1)]}, PST = TBD2 and End-Points Object = 680 {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) that 681 this local LSP tunnel(i) is part of an inter-domain path. 683 3. When the PCC BN-en(i) received the PCInitiate message from its 684 PCE(i), it setup the local LSP tunnel from BN-en(i) to BN-ex(i) 685 by means of RSVP-TE signaling with the given ERO(i). 687 4. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 688 is used to instruct the egress node of domain(i), i.e. BN-ex(i) 689 to forward packets belonging to this tunnel with the Stitching 690 Label. Both Label Stitching and IP address of outgoing interface 691 are carried in the ERO = {..., [LK(i+1), SL(i+1)]} as the last 692 SubObject in conformance to [RFC4003]. So that, BN-ex(i) 693 installs in its MPLS L(F)IB the SWAP instruction to label SL(i+1) 694 with forward to LK(i+1) instead of the usual POP instruction. 696 5. Once the tunnel setup, PCC BN-en(i) chooses a free label for the 697 Stitching Label SL(i) and add a new entry in its MPLS L(F)IB with 698 this SL(i) label. Then, it sends a PCRpt message to its PCE(i) 699 with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP-ID(i). 701 6. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 702 and PST = TBD2, it sends to its Parent PCE a PCRpt message 703 containing the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). 704 PCE(i) MAY add PKS(i) in the RRO. 706 7. Once Parent PCE receives the PCRpt from the Child PCE(i), it 707 stores the corresponding PLSP-ID for this inter-domain tunnel 708 part 710 Steps n: Actions performed to the source domain(1) 712 Finally, Parent PCE sends a last PCInitiate message to Child PCE(1) 713 with PST = TBD1, ERO = {PKS(1), [LK(2), SL(2)]} and End-Points = {S, 714 BN-ex(1)}. In turn, Child PCE(1) sends a PCInitiate message to PCC 715 node S with ERO equal to {ERO(1), [LK(2), SL(2)]}, PST = 0 and End- 716 Points Object = {S, BN-ex(1)}. This time, the PST is equal to 0 as 717 the PCC S does not need to return a Stitching Label SL, i.e. it is 718 the head-end of the inter-domain path. Standard PCRpt message is 719 sent back to PCE(1) by the PCC node S. In turn, Child PCE(1) send a 720 final PCRpt message to the Parent PCE with the PSLP-ID(1). PCE(1) 721 MAY adds {S, BN-ex(1)} in the RRO as loose path. 723 4.2. Inter-domain LSP setup procedure completion failure 725 In case of error during LSP setup, PCRpt and or PCError messages MUST 726 be used to signal the problem to the Parent PCE. In particular, if 727 new PST values defined in this memo are not supported by the Child 728 PCE or the PCC, the Child PCE, receptively the PCC, MUST return a 729 PCErr message with Error-Type = 21 (Traffic engineering path setup 730 error) and Error-Value = 1 (Unsupported path setup type) to its 731 Parent PCE. If Child PCE(i) receives a PCInitiate message from its 732 Parent PCE without PST set to TBD1 or PST set to a value different 733 from TBD1, it MUST return a PCErr message with Error-Type = 21 734 (Traffic engineering path setup error) and Error-Value = 1 735 (Unsupported path setup type) to its Parent PCE. 737 If a Child PCE or a PCC don't return an RRO or an RRO without the 738 Stitching Label SL with the IP address of the associated link 739 following a PCInitiate message with PST set to TBD1, the Parent PCE, 740 respectively the Child PCE, MUST return a PCErr message with Error- 741 Type = 21 (Traffic engineering path setup error) and Error-Value = 742 TBD5 (No Mandatory Stitching Label is present in the RRO). 744 In case of completion failure, the Parent PCE MUST MUST send a 745 PCInitate message (R flag set in the SRP Object as per draft pce 746 initiated lsp [RFC8281]) to delete this inter-domain path to the 747 Child PCEs that already setup their respective part of the inter- 748 domain tunnel. Child PCE(i) MUST remove their local LSP tunnel by 749 means of PCInitiate message with R flag set to 1 to their PCC BN- 750 en(i) and send back PCRpt message to the Parent PCE. 752 4.3. Example for Stateful H-PCE Stiching procedure 754 Taking the sample hierarchical domain topology example from [RFC6805] 755 as the reference topology for the entirety of this section. 757 ----------------------------------------------------------------- 758 | Domain 5 | 759 | ----- | 760 | |PCE 5| | 761 | ----- | 762 | | 763 | ---------------- ---------------- ---------------- | 764 | | Domain 1 | | Domain 2 | | Domain 3 | | 765 | | | | | | | | 766 | | ----- | | ----- | | ----- | | 767 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 768 | | ----- | | ----- | | ----- | | 769 | | | | | | | | 770 | | ----| |---- ----| |---- | | 771 | | |BN11+---+BN21| |BN23+---+BN31| | | 772 | | - ----| |---- ----| |---- - | | 773 | | |S| | | | | |D| | | 774 | | - ----| |---- ----| |---- - | | 775 | | |BN12+---+BN22| |BN24+---+BN32| | | 776 | | ----| |---- ----| |---- | | 777 | | | | | | | | 778 | | ---- | | | | ---- | | 779 | | |BN13| | | | | |BN33| | | 780 | -----------+---- ---------------- ----+----------- | 781 | \ / | 782 | \ ---------------- / | 783 | \ | | / | 784 | \ |---- ----| / | 785 | ----+BN41| |BN42+---- | 786 | |---- ----| | 787 | | | | 788 | | ----- | | 789 | | |PCE 4| | | 790 | | ----- | | 791 | | | | 792 | | Domain 4 | | 793 | ---------------- | 794 | | 795 ----------------------------------------------------------------- 797 Hierarchical domain topology from RFC6805 799 Section 3.3.1 of [I-D.ietf-pce-stateful-hpce] describes the per- 800 domain stitched LSP mode and list all the steps needed. To support 801 SL based stitching, using the reference architecture described in 802 Figure above, the steps are modified as follows (note that we do not 803 use PKS in this example for simplicity): 805 Step 1: initialization 807 The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 of 808 section 4.6.2 of [RFC6805] are executed to determine the end to end 809 path, which are broken into per-domain LSPs e.g. {S-BN41, BN41-BN33, 810 BN33-D} 812 Step 2: LSP (BN33-D) at PCE3: 814 1. The P-PCE (PCE5) sends the initiate request to the child PCE 815 (PCE3) via PCInitiate message for LSP (BN33-D) with ERO=(BN33..D) 816 and PST = TBD1 818 2. The PCE3 further propagates the initiate message to BN33 with the 819 ERO and PST = TBD2/TBD3 based on setup type 821 3. BN33 initiates the setup of the LSP as per the path and reports 822 to the PCE3 the LSP status ("GOING-UP") 824 4. The PCE3 further reports the status of the LSP to the P-PCE 825 (PCE5) 827 5. The node BN33 notifies the LSP state to PCE3 when the state is 828 "UP" it also carry the stitching label (SL33) in RRO as 829 (SL33,BN33..D) 831 6. The PCE3 further reports the status of the LSP to the P-PCE 832 (PCE5) as well as carry the stitching label (SL33) in RRO as 833 (LK33,SL33,BN33..D) 835 Step 3: LSP (BN41-BN33) at PCE4 837 1. The P-PCE (PCE5) sends the initiate request to the child PCE 838 (PCE4) via PCInitiate message for LSP (BN41-BN33) with 839 ERO=(BN41..BN42,LK33,SL33,BN33) and PST = TBD1 841 2. The PCE4 further propagates the initiate message to BN41 with the 842 ERO and PST = TBD2/TBD3 based on setup type. In case of RSVP_TE, 843 the node BN41 encode the stitching label SL33 as part of the ERO 844 to make sure the node BN42 uses the label SL33 towards node BN33. 845 In case of SR, the label SL33 is part of the label stack pushed 846 at node BN41 848 3. BN41 initiates the setup of the LSP as per the path and reports 849 to the PCE4 the LSP status ("GOING-UP") 851 4. The PCE4 further reports the status of the LSP to the P-PCE 852 (PCE5) 854 5. The node BN41 notifies the LSP state to PCE4 when the state is 855 "UP" it also carry the stitching label (SL41) in RRO as 856 (LK41,SL41,BN41..BN33) 858 6. The PCE4 further reports the status of the LSP to the P-PCE 859 (PCE5) as well as carry the stitching label (SL41) in RRO as 860 (LK41,SL41,BN41..BN33) 862 Step 3: LSP (S-BN41) for PCE1 864 1. The P-PCE (PCE5) sends the initiate request to the child PCE 865 (PCE1) via PCInitiate message for LSP (S-BN41) with 866 ERO=(S..BN13,LK41,SL41,BN41) 868 2. The PCE1 further propagates the initiate message to node S with 869 the ERO. In case of RSVP_TE, the node S encode the stitching 870 label SL41 as part of the ERO to make sure the node BN13 uses the 871 label SL41 towards node BN41. In case of SR, the label SL41 is 872 part of the label stack pushed at node S 874 3. S initiates the setup of the LSP as per the path and reports to 875 the PCE1 the LSP status ("GOING-UP") 877 4. The PCE1 further reports the status of the LSP to the P-PCE 878 (PCE5) 880 5. The node S notifies the LSP state to PCE1 when the state is"UP" 882 6. The PCE1 further reports the status of the LSP to the P-PCE 883 (PCE5) 885 In this way, per-domain LSP are stitched together using the stitching 886 label (SL). The per-domain LSP MUST be setup from the destination 887 domain towards the source domain one after the other. 889 Once the per-domain LSP is setup, the entry BN chooses a free label 890 for the Stitching Label SL and add a new entry in its MPLS L(F)IB 891 with this SL label. The SL from the destination domain is propagated 892 to adjacent transit domain, towards the source domain at each step. 893 This happens through the entry BN to C-PCE to the P-PCE and vice- 894 versa. In case of RSVP-TE, the entry BN further propagates the SL 895 label to the exit BN via RSVP-TE. In case of SR, the SL label is 896 pushed as part of the SR label stack. 898 5. Inter-domain LSP Management 900 This section describe how inter-domain LSPs could be manage. 902 5.1. Identification of inter-domain tunnels 904 First, in order to manage inter-domain tunnels composed by the 905 stitching or nesting of local tunnels, it is important to identify 906 them. For this purpose, PLSP-ID managed by PCEs are combined to one 907 provided by PCCs to form global identifier as follow: 909 o PCE(i) in the Backward Recursive method or the Child PCE in 910 Hierarchical method MUST create a new unique PLSP-ID for this 911 inter-domain LSP part and MUST send it in the PCRpt message, to 912 the PCE(i-1), respectively the Parent PCE. In addition this new 913 PLSP-ID MUST be associated to the one received from the PCC that 914 instantiate the local tunnel part for further reference. 916 o In Hierarchical mode, Parent PCE MUST store and associate the 917 different PLSP-ID(i)s received from the different Child PCE(i)s in 918 order to identify the different part of the inter-domain paths. 920 o In Backward Recursive method, PCE(i) MUST store and associate its 921 PLSP-ID(i) and the PLSP-ID(i+1) it received from the PCE(i+1). 922 PCE(n) i.e. the last one in the chain, don't need to perform such 923 association. 925 Further reference to the inter-domain tunnel will use this PLSP- 926 ID(i). In Backward Recursive method, PCE(i) MUST replace the PLSP- 927 ID(i) by PLSP-ID(i+1) in the PCUpd, PCRpt or PCinitiate message 928 before propagating it to PCE(i+1) and PCE(i) MUST replace the PLSP- 929 ID(i+1) by PLSP-ID(i) in the PCRpt message before propagating it to 930 the PCE(i-1). In Hierarchical method, Parent PCE MUST use the 931 corresponding PLSP-ID(i) of the Child PCE(i). 933 5.2. Inter-domain association group 935 In case of failure, a PCE(i) will received PCRpt messages from its 936 PCCs and neighbors PCE(i+1) to synchronize the Inter-domain LSPs. In 937 addition, it may received PCInitiate messages from its previous 938 neighbors PCE(i-1) to re-initiate inter-domain tunnel part. As the 939 PCE(i) may loose the PLSP-ID association, a new association group 940 (within Association Object) is used to ease the association of the 941 different part of the inter-domain tunnel: the local parts and the 942 PCE to PCE parts. The use of the Association Object is MANDATORY in 943 the Backward Recursive method and OPTIONAL in the Hierarchical 944 method. 946 For that purpose, a new Inter-Domain Association Type with value TBD4 947 is defined. The first PCE in the Backward Recursive chain (the one 948 which received the initial request) MUST send the PCInitiate message 949 with an Association Object as follows: 951 o Association Type field MUST be set to new value TBD4 953 o Association ID MUST be set to a unique value. In case of 954 Association ID field is too short or wraps, the first PCE MAY use 955 the Extended Association ID to increase the number of association 956 groups. The Association ID is managed locally by the PCE and does 957 not need to be coordinated with neighbor or remote PCEs. 959 o IPV4 or IPv6 association source MUST be set to the IP address 960 which identifies PCE(1) in domain(1). 962 o The Global Association Source TLV MUST be present and set with the 963 ASN number of domain(1). It allows to create a globally unique 964 association scope without putting constraint on operator's IP 965 association source. Thus the IP Association Source is associated 966 with the Global Association source to form a unique identifier. 968 o Extended Association ID MAY be present and MANDATORY if 969 association ID is too short or wraps. 971 Subsequent PCE(i) for i = 2 to n, MUST send this Association Object 972 as is to the local PCC and the neighbor PCE(i+1). 974 In case of error with the association group, PCErr message MUST be 975 raised with Error = 26 (Association Error) and Error value set 976 accordingly. A new Error value TBD6 is defined to identify 977 association of inter-domain LSPs. 979 In Hierarchical method, parent PCE MAY act as initiator of the 980 Association and send to the Child PCEs an Association Object that 981 follows the same rules as for the Backward Recursive method. In 982 turn, Child PCEs MUST propagate the Association Object to the local 983 PCCs as is. 985 5.3. Inter-domain LSP management 987 For the Backward Recursive method, each domain manages their 988 respective local LSP tunnel part of an inter-domain path 989 independently of each other. In particular, Stitching Label(i) is 990 managed by domain(i) and is of interest of domain(i-1) only. Thus, 991 Stitching Label SL(i) is not supposed to be propagated to other 992 domains. The same behavior apply to PLSP-ID(i). In Hierarchical 993 method, the Parent PCE MUST ensure the correct distribution of 994 Stitching Label SL(i) to Child PCE(i-1. The PLSP-ID(i) is kept for 995 the usage of the Parent PCE and thus is not propagated. Only the 996 Association Object defined in section 5.2 is propagated if it is 997 present. 999 If a PCE(i) needs to modify its local LSP tunnel(i) with a PCUpd 1000 message to the PCC BN-en(i), once PCRpt message received by the PCC 1001 BN-en(i), it MUST sends a new PCRpt message to its neighbor PCE(i-1) 1002 in Backward Recursive method, respectively to Parent PCE in 1003 Hierarchical method, to advertise PCE(i-1) of the modification. In 1004 this case PLSP-ID(i) is used to identify the inter-domain tunnel. 1005 PCE(i-1), respectively the Parent PCE, MUST propagate the PCRpt 1006 message if the modification imply the previous domain e.g. if the 1007 PCRpt indicates that the Stitching Label SL(i) has changed. 1009 PCE(1), respectively Parent PCE, could modify the inter-domain path. 1010 For that purpose, it MUST sends a PCUpd message to its neighbor PCEs, 1011 respectively Child PCE, using the PLSP-ID it received. Each PCE(i) 1012 MUST process PCUpd message the same way they process PCInitiate 1013 message as define in section 3.1 for Backward Recursive method and in 1014 section 4.1 for Hierarchical method. 1016 In case a failure appear in domain(i), e.g. tunnel becoming down, 1017 PCE(i) MUST sends a PCRpt message to its neighbor PCE(i-1), 1018 respectively its Parent PCE to advertise it of the problem in its 1019 local part of the inter-domain path. Once PCE(1), respectively 1020 Parent PCE, receives this PCRpt message indicating that the tunnel is 1021 down, it is up to the PCE(1), respectively Parent PCE to take 1022 appropriate correction e.g. start a new path computation to update 1023 the ERO. 1025 5.4. Modification of inter-domain LSP 1027 Modification of local LSP tunnel, BN-en(i) and BN-ex(i) is left for 1028 further study. 1030 5.5. Removal of inter-domain LSP 1032 Deletion of inter-domain LSP is only possible by the inter-domain 1033 tunnel initiator i.e. PCE(1). For Backward Recursive method, 1034 PCInitiate message with R flag set to 1, PLSP-ID set accordingly to 1035 section 5.1 and the Association Object with R flag set to 1, is sent 1036 by PCE(1) to PCE(n) through PCE(i) and process the same way as 1037 describe in section 3.1. For Hierarchical method, PCInitiate message 1038 with R flag set to 1 is sent by the Parent PCE to each Child PCE(i) 1039 with corresponding PLSP-ID(i) and process accordingly to section 4.1. 1040 Each domain PCE(i) is responsible to delete its part of the tunnel 1041 and PCC MUST remove the Stitching label SL in its L(F)IB in addition 1042 to the tunnel when it receives the PCInitiate message with the R flag 1043 set to 1 and corresponding PLSP-ID. The Association Group MUST also 1044 be removed by the PCC and PCE(i). 1046 6. Applicability 1048 The newly introduce Stitching Label SL serves to stitch or nest part 1049 of local LSP tunnels to form an inter-domain path. Each domain is 1050 free to decide if the tunnel is stitched or nested and how the tunnel 1051 is enforced e.g. tough RSVP-TE or Segment Routing. However, the 1052 Stitching Label principle is only compatible with MPLS data plane. 1053 At the peering point, the Border Node BN-ex(i) MUST encapsulated the 1054 packet with the Stitching Label i.e. the MPLS label prior to send 1055 them to the next Border Node BN-en(i+1). Thus, only RSVP-TE and 1056 Segment Routing over MPLS technology are detailed in the following 1057 sections. 1059 6.1. RSVP-TE 1061 In case of RSVP-TE, the Border Node BN-ex(i) needs to received the 1062 Stitching Label through the RSVP-TE message and install in its L(F)IB 1063 a SWAP instruction to the Stitching Label and forward it to the next 1064 Border Node BN-en(i+1). For that purpose, the Egress Control 1065 mechanism, as per RFC4003 section 2.1 [RFC4003], is RECOMMENDED to 1066 instruct the Border Node BN-ex(i) of this action. Other mechanisms 1067 to program the L(F)IB could be used e.g. NetConf. 1069 As the Stitching Label could serves to stitch or nest tunnels, a 1070 domain(i) may decided to nest the incoming local LSP tunnel into a 1071 higher hierarchy of tunnel for Traffic Engineering purpose. A PCE(i) 1072 may also decided to group local LSP tunnels part of inter-domain 1073 paths into a higher hierarchical tunnel to carry all these local LSP 1074 tunnels from one BN-en(i) to one BN-ex(i). 1076 6.2. Segment Routing 1078 To use Segment Routing instead of RSVP-TE to setup the local LSP 1079 tunnels as defined in draft pce segment routing 1080 [I-D.ietf-pce-segment-routing], PCE(i) MUST send PCInitiate message 1081 with PST = TBD3 instead of TBD2 to advertise their respective PCC 1082 that the local LSP tunnels is enforce by means of Segment Routing. 1084 Stitching Label SL(i) will be inserted in the label stack in order to 1085 become the top label in the stack when the packet reach BN-en(i+1): 1086 Thus, the Stitching Label SL(i) serves as entry FEC for BN-en(i+1) to 1087 identify the packets that follow the next Segment Path. For that 1088 purpose, BN-en(i+1) MUST install in its MPLS L(F)IB an instruction to 1089 replace the incoming Stitching Label SL(i) by the label stack given 1090 by the ERO(i+1) plus the Stitching Label SL(i+1). When a packet 1091 reaches BN-ex(i), the last label in the stack before the label 1092 SL(i+1) corresponds to a SID that allows to reach BN-en(i+1). 1094 However, BN-ex(i) needs to know how to send the packets to BN- 1095 en(i+1), in particular when there are multiple interfaces between 1096 Border Nodes. Similar to the Egress Control mechanism used with 1097 RSVP-TE, it is RECOMMENDED to used the inter-domain SID defined as 1098 per draft Egress Peer Engineering 1099 [I-D.ietf-idr-bgpls-segment-routing-epe] for that purpose. The 1100 inter-domain SID is announced by BN-ex(i) to PCE(i) through BGP-LS 1101 for each interface that connect BN-ex(i) to neighbors BN-en(i+1). 1102 Thus, the label stack will end with {BN-ex(i) SID, Inter-Domain SID, 1103 SL(i+1)} and processes as follows: 1105 o Penultimate router pops its node SID, and sends the packet to the 1106 next node designated by the top label in the label stack i.e. the 1107 node SID of BN-ex(i) 1109 o BN-ex(i) pops its node SID and looks up the next label in the 1110 stack, i.e. the inter-domain SID which corresponds to the 1111 interface to BN-en(i+1). BN-ex(i) pops again this inter-domain 1112 SID and send the packet to BN-ex(i) through the interface that 1113 correspond to the inter-domain SID. 1115 o BN-en(i+1) pops the Stitching Label SL(i+1) and replaces it by the 1116 sub-sequent label stack. 1118 Other mechanisms, e.g. NetConf, could be used to configure the 1119 inter-domain SID on exit Border Nodes. 1121 6.3. Mixing technology 1123 During the instantiation procedure, if PCE(i) decides to reuse a 1124 local tunnel which is not yet part of an inter-domain tunnel, it 1125 SHOULD send a PCUpd message with PST = TBD2 to the PCC BN-en(i) in 1126 order to request a Stitching Label SL(i) and new ERO(i) to include 1127 the Stitching Label SL(i+1) and the associated link to the previous 1128 ERO. 1130 [RFC8453] describes framework for Abstraction and Control of TE 1131 Networks (ACTN), where each Physical Network Controller (PNC) is 1132 equivalent to C-PCE and P-PCE is the Multi-Domain Service Coordinator 1133 (MDSC). The Per domain stitched LSP as per the Hierarchical PCE 1134 architecture described in Section 3.3.1 and Section 4.1 of 1135 [I-D.ietf-pce-stateful-hpce] is well suited for ACTN. The stitching 1136 label (SL) mechanism as described in this document is well suited for 1137 ACTN when per domain LSP needs to be stitched to form an E2E tunnel 1138 or a VN Member. It is to be noted that certain VNs require isolation 1139 from other clients. The stitching label mechanism described in this 1140 document can be applicable to the VN isolation use-case by uniquely 1141 identifying the concatenated stitching labels across multi-domain 1142 only to a certain VN member or an E2E tunnel. 1144 As each operator is free to enforce the tunnel with its technology 1145 choice, it is a local policy decision for PCE(i) to instantiate the 1146 local part of the end to end tunnel by either RSVP-TE or Segment 1147 Routing. Thus, the PST value (i.e. TBD2 or TBD3) used in the 1148 PCinitiate message sends by the PCE(i) to the local PCC is determined 1149 by the local policy. How the local policy decision is set in PCE is 1150 out of scope of this memo. This flexibility is allowed because the 1151 stitching label principle allows to mix (data plane) technologies 1152 between domains. For example, a domain(i) could used RSVP-TE while 1153 domain(i+1) used Segment Routing, reciprocally. The Stitching Label 1154 SL could serves to stitch indifferently Segment Path and RSVP-TE 1155 tunnel. Indeed, Stitching Label SL will be part of the label stack 1156 in order to become the top label in the stack when reaching the BN- 1157 en(i+1). This Stitching Label could be swap as usual if the next 1158 domain uses RSVP-TE tunnel. When the previous domain uses a RSVP-TE 1159 tunnel, the Stitching Label will serve as key for the BN-en(i+1) to 1160 determine which label stack it must use on top of the packet for a 1161 Segment Routing path. 1163 7. IANA Considerations 1165 7.1. Path Setup Type values 1167 [RFC8408] defines the PATH-SETUP-TYPE TLV and requests that IANA 1168 creates a registry to manage the value of the PATH_SETUP_TYPE TLV's 1169 PST field. IANA is requested to allocate a new code point in the 1170 PCEP PATH_SETUP_TYPE TLV PST field registry, as follows: 1172 +-------+-----------------------------------------------+-----------+ 1173 | Value | Description | Reference | 1174 +-------+-----------------------------------------------+-----------+ 1175 | TBD1 | Inter-Domain Traffic engineering end-to-end | This | 1176 | | path is setup using Backward Recursive method | Document | 1177 | TBD2 | Inter-Domain Traffic engineering local path | This | 1178 | | is setup using RSVP-TE | Document | 1179 | TBD3 | Inter-Domain Traffic engineering local path | This | 1180 | | is setup using Segment Routing | Document | 1181 +-------+-----------------------------------------------+-----------+ 1183 7.2. Association Type value 1185 Draft pce association group [I-D.ietf-pce-association-group] defines 1186 the ASSOCIATION Object and requests that IANA creates a registry to 1187 manage the value of the Association Type value. IANA is requested to 1188 allocate a new code point in the PCEP ASSOCIATION GROUP TLV 1189 Association Type field registry, as follows: 1191 +------------------+--------------------------------+ 1192 | Association Type | Description | 1193 +------------------+--------------------------------+ 1194 | TBD4 | Inter-domain Association Group | 1195 +------------------+--------------------------------+ 1197 7.3. PCEP Error values 1199 IANA is requested to allocate code-points in the PCEP-ERROR Object 1200 Error Values registry for a new error-value of Error-Type 21 Invalid 1201 traffic engineering path setup and new error-value of Error-Type 26 1202 Association Error: 1204 +------------+-------------+----------------------------------------+ 1205 | Error-Type | Error-Value | Description | 1206 +------------+-------------+----------------------------------------+ 1207 | 21 | TBD5 | Missing Mandatory Stitching Label in | 1208 | | | RRO | 1209 | 26 | TBD6 | Error in association of Inter-domain | 1210 | | | LSPs | 1211 +------------+-------------+----------------------------------------+ 1213 8. Security Considerations 1215 No modification of PCE protocol (PCEP) has been requested by this 1216 draft which not introduce any issue regarding security. Concerning 1217 the PCEP session between PCEs, authors recommend to use the secure 1218 version of PCEP as defined in PCEPS [RFC8253] or use any other secure 1219 tunnel mechanism e.g. IPsec tunnel to transport PCEP session between 1220 PCE. 1222 9. Acknowledgements 1224 The authors want to thanks PCE's WG members, and in particular Dhruv 1225 Dhody who greatly contributed to the Hierarchical section of this 1226 document. 1228 10. Disclaimer 1230 This work has been performed in the framework of the H2020-ICT-2014 1231 project 5GEx (Grant Agreement no. 671636), which is partially funded 1232 by the European Commission. This information reflects the 1233 consortium's view, but neither the consortium nor the European 1234 Commission are liable for any use that may be done of the information 1235 contained therein. 1237 11. References 1239 11.1. Normative References 1241 [I-D.ietf-pce-association-group] 1242 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1243 Dhody, D., and Y. Tanaka, "PCEP Extensions for 1244 Establishing Relationships Between Sets of LSPs", draft- 1245 ietf-pce-association-group-07 (work in progress), December 1246 2018. 1248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1249 Requirement Levels", BCP 14, RFC 2119, 1250 DOI 10.17487/RFC2119, March 1997, . 1253 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1254 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1255 DOI 10.17487/RFC5440, March 2009, . 1258 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1259 "A Backward-Recursive PCE-Based Computation (BRPC) 1260 Procedure to Compute Shortest Constrained Inter-Domain 1261 Traffic Engineering Label Switched Paths", RFC 5441, 1262 DOI 10.17487/RFC5441, April 2009, . 1265 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1266 Computation Element Communication Protocol (PCEP) 1267 Extensions for Stateful PCE", RFC 8231, 1268 DOI 10.17487/RFC8231, September 2017, . 1271 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1272 Computation Element Communication Protocol (PCEP) 1273 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1274 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1275 . 1277 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1278 Hardwick, "Conveying Path Setup Type in PCE Communication 1279 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1280 July 2018, . 1282 11.2. Informative References 1284 [I-D.dong-pce-discovery-proto-bgp] 1285 Dong, J., Chen, M., Dhody, D., Tantsura, J., Kumaki, K., 1286 and T. Murai, "BGP Extensions for Path Computation Element 1287 (PCE) Discovery", draft-dong-pce-discovery-proto-bgp-07 1288 (work in progress), July 2017. 1290 [I-D.ietf-idr-bgpls-segment-routing-epe] 1291 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 1292 S., and J. Dong, "BGP-LS extensions for Segment Routing 1293 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 1294 segment-routing-epe-17 (work in progress), October 2018. 1296 [I-D.ietf-pce-segment-routing] 1297 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1298 and J. Hardwick, "PCEP Extensions for Segment Routing", 1299 draft-ietf-pce-segment-routing-16 (work in progress), 1300 March 2019. 1302 [I-D.ietf-pce-stateful-hpce] 1303 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 1304 and O. Dios, "Hierarchical Stateful Path Computation 1305 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 1306 progress), October 2018. 1308 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1309 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1310 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1311 . 1313 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1314 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1315 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1316 DOI 10.17487/RFC3473, January 2003, . 1319 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1320 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1321 . 1323 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1324 Hierarchy with Generalized Multi-Protocol Label Switching 1325 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1326 DOI 10.17487/RFC4206, October 2005, . 1329 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1330 Element (PCE)-Based Architecture", RFC 4655, 1331 DOI 10.17487/RFC4655, August 2006, . 1334 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 1335 "Label Switched Path Stitching with Generalized 1336 Multiprotocol Label Switching Traffic Engineering (GMPLS 1337 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 1338 . 1340 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1341 "Preserving Topology Confidentiality in Inter-Domain Path 1342 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1343 DOI 10.17487/RFC5520, April 2009, . 1346 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1347 Path Computation Element Architecture to the Determination 1348 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1349 DOI 10.17487/RFC6805, November 2012, . 1352 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1353 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1354 Path Computation Element Communication Protocol (PCEP)", 1355 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1356 . 1358 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1359 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1360 DOI 10.17487/RFC8453, August 2018, . 1363 Authors' Addresses 1364 Olivier Dugeon 1365 Orange Labs 1366 2, Avenue Pierre Marzin 1367 Lannion 22307 1368 France 1370 Email: olivier.dugeon@orange.com 1372 Julien Meuric 1373 Orange Labs 1374 2, Avenue Pierre Marzin 1375 Lannion 22307 1376 France 1378 Email: julien.meuric@orange.com 1380 Young Lee 1381 Huawei Technologies 1382 5340 Legacy Drive, Building 3 1383 Plano TX 75023 1384 USA 1386 Email: leeyoung@huwaei.com 1388 Daniele Ceccarelli 1389 Ericsson 1390 Torshamnsgatan, 48 1391 Stockholm 1392 Sweden 1394 Email: daniele.ceccarelli@ericsson.com