idnits 2.17.1 draft-dugeon-pce-stateful-interdomain-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2119 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: 'PCE-B' is mentioned on line 232, but not defined == Missing Reference: 'PCE-C' is mentioned on line 232, but not defined == Missing Reference: 'PCE-A' is mentioned on line 244, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-05 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-stateful-hpce (ref. 'I-D.ietf-pce-stateful-hpce') ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 6805 == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 Summary: 4 errors (**), 0 flaws (~~), 7 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 3, 2019 Y. Lee 6 D. Dhody 7 Huawei Technologies 8 D. Ceccarelli 9 Ericsson 10 July 02, 2018 12 PCEP Extension for Stateful Inter-Domain Tunnels 13 draft-dugeon-pce-stateful-interdomain-01 15 Abstract 17 This document proposes to combine a Backward Recursive or 18 Hierarchical method in Stateful PCE with PCInitiate message to setup 19 independent paths per domain, and combine these different paths 20 together in order to operate them as end-to-end inter-domain paths 21 without the need of signaling session between AS border routers. A 22 new Stitching Label is defined and new LSP-TYPE code points are 23 considered for that purpose. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. General assumptions . . . . . . . . . . . . . . . . . . . 5 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. Stitching Label . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 7 70 2.2. Inter-domain LSP-TYPE . . . . . . . . . . . . . . . . . . 8 71 3. Backward Recursive PCInitiate procedure . . . . . . . . . . . 9 72 3.1. Mode of operation . . . . . . . . . . . . . . . . . . . . 9 73 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.3. Inter-domain LSP setup procedure completion failure . . . 13 75 4. Hierarchical PCInitiate procedure . . . . . . . . . . . . . . 14 76 4.1. Mode of operation . . . . . . . . . . . . . . . . . . . . 14 77 4.2. Inter-domain LSP setup procedure completion failure . . . 16 78 4.3. Example for Stateful H-PCE Stiching procedure . . . . . . 17 79 5. Inter-domain LSP Management . . . . . . . . . . . . . . . . . 21 80 5.1. Identification of inter-domain tunnels . . . . . . . . . 21 81 5.2. Inter-domain LSP management . . . . . . . . . . . . . . . 21 82 5.3. Modification of inter-domain LSP . . . . . . . . . . . . 22 83 5.4. Removal of inter-domain LSP . . . . . . . . . . . . . . . 22 84 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 23 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 7.1. LSP-TYPE values . . . . . . . . . . . . . . . . . . . . . 24 87 7.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 24 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 90 10. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 93 11.2. Informative References . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Problem Statement 98 The Path Computation Element (PCE) working group (WG) has produced a 99 set of RFCs to standardize the behavior of the Path Computation 100 Element as a tool to help MPLS-TE, GMPLS LSP tunnels and Segment 101 Routing paths placement. This also includes the ability to compute 102 inter-domain LSPs or Segment Routing paths following a distributed or 103 hierarchical approach. To complement the original stateless mode, a 104 stateful mode has been added. In particular, the new PCInitiate 105 message allows a PCE to directly ask a PCC to setup an MPLS-TE, GMPLS 106 LSP tunnel or a Segment Routing path. However, once computed, the 107 inter-domain LSPs or Segment Routing path are hard to setup in the 108 underlying network. Especially, in operational network, RSVP-TE 109 signaling is not enabled between AS border routers. But, such RSVP- 110 TE signaling is mandatory to setup contiguous LSP tunnels or to 111 stitch or nest independent LSP tunnels to form the end-to-end inter- 112 domain paths. 114 Looking to the different RFCs that describe the PCE architecture and 115 in particular PCE based architecture [RFC4655], PCE protocol 116 [RFC5440], BRPC [RFC5441] and H-PCE [RFC6805], the Path Computation 117 Element (PCE) is able to compute inter-domain paths in complement to 118 intra-domain computation. Such inter-domain paths could then serve 119 as the Explicit Route Object input for the RSVP-TE signaling to setup 120 the tunnels within the underlying network. Three kinds of inter- 121 domain paths could be established: 123 o Contiguous tunnel ([RFC3209] and [RFC3473]): The RSVP-TE signaling 124 crosses the boundary between two domains, e.g. between two AS 125 Border Routers (ASBRs) as if they were two routers of the same 126 domain. This kind of tunnel is not recommended mostly for 127 security and scalability purpose. In addition, the initiating 128 domain imposes huge constraints on subsequent domains, because 129 they undergo the tunnel request without being able to control it. 131 o Stitching tunnel ([RFC5150]): Each domain establishes in its own 132 network the corresponding part of the inter-domain path 133 independently. Then, a second end-to-end RSVP-TE Path message is 134 sent by the initiating domain to stitch the different tunnel parts 135 to form the inter-domain path. In fact, this second RSVP-TE Path 136 message is used by border nodes to exchange the label that must be 137 used by the previous domain to send the traffic in order that the 138 MPLS packets follow the next LSP tunnel in the following domain. 139 These labels are conveyed in the RSVP-TE Resv message. 141 o Nesting tunnel ([RFC4206]): This is similar to the stitching mode 142 but, this time, with the possibility to setup tunnel hierarchy. 143 For example, an LSP tunnel between two edge domains crossing a 144 transit domain could be carried over a tunnel of a higher level in 145 the transit domain. Again, a second end-to-end RSVP-TE Path 146 message is sent from the source to the destination. Labels that 147 must be used by the ASBRs of transit domains to identify flows to 148 be nested are carried by the RSVP-TE Resv message. 150 In all case, RSVP-TE signaling must be exchanged between the 151 different domains. However, from an operational point of view, 152 looking to different networks under the responsibility of different 153 administrative entities, only BGP sessions are setup and configured 154 between ASBRs. Technologically speaking, this is possible and many 155 RFCs describe how to use RSVP-TE for inter-domain. But, due to 156 security, scalability, management and contract constraints, RSVP-TE 157 is not exposed at the network boundary. To circumvent some of the 158 security issues, RSVP-TE can be carried inside an IPsec tunnel 159 between ASBRs, but, this does not eliminate the scalability aspect 160 nor the constraints imposed by setting up inter-domain paths. 162 The purpose of this memo is to take the benefit of PCE Stateful 163 [RFC8231] and PCE Initiated [RFC8281] modes to stitch or nest inter- 164 domain paths directly using PCEP between domains' PCEs instead of 165 using RSVP-TE signaling at the inter-domain border nodes, while 166 keeping each operator free to independently setup their respective 167 part of the inter-domain paths. PCInitiate message is used in a 168 Backward Recursive way like the PCReq message in BRPC [RFC5441], to 169 recursively setup the end-to-end tunnel. PCRep message is used to 170 automatically stitch or nest the different local LSP tunnels. And, 171 PCRep in conjunction of PCUpd messages are used to maintain, modify 172 and remove inter-domain paths. This method is also applicable to 173 Segment Routing to build inter-domain segment paths. 175 H-PCE [RFC6805] describes a Hierarchical PCE architecture which can 176 be used for computing end-to-end paths for inter-domain MPLS Traffic 177 Engineering (TE) and GMPLS Label Switched Paths (LSPs). Within this 178 architecture, the Parent PCE (P-PCE) is used to compute a multi- 179 domain path based on the domain connectivity information. A Child 180 PCE (C-PCE) may be responsible for a single domain or multiple 181 domains, it is used to compute the intra-domain path based on its 182 domain topology information. 184 Stateful H-PCE [I-D.ietf-pce-stateful-hpce] presents general 185 considerations for stateful PCE(s) in hierarchical PCE architecture. 186 In particular, the behavior changes and additions to the existing 187 stateful PCE mechanisms (including PCE-initiated LSP setup and active 188 PCE usage) in the context of networks using the H-PCE architecture. 189 Section 3.3.1 [I-D.ietf-pce-stateful-hpce]describes the per domain 190 stitched LSP mode, where the individual per domain LSP are stitched 191 together. PCInitiate message is also used to stitch the end-to-end 192 tunnel. See section 4 for details. 194 1.1. General assumptions 196 In the rest of this document, we used the same references as per BRPC 197 [RFC5441] and make the following set of assumptions (see figure 198 below): 200 o Domain refers to an IGP area or an Autonomous System (AS). 202 o Inter-domain path is used to refer to a path that cross two or 203 more different domains as defined previously, 205 o At least, one PCE is deployed in each domain. These PCE are all 206 stateful active capable and could request to enforce LSP tunnels 207 in their respective domain by means of PCInitiate messages. 209 o LSRs, including border nodes, are PCC enable and support stateful 210 active mode. PCEP sessions is established between these routers 211 and their domains' PCE. 213 o Each PCE establishes a PCEP session with its respective neighbor 214 domain's PCE. The way a PCE discover its neighboring PCE is out 215 of scope of this draft. These information could be fulfill 216 administratively or automatically discovered through, for example 217 per draft 'BGP Extensions for Path Computation Element (PCE) 218 Discovery' [I-D.dong-pce-discovery-proto-bgp]. 220 o PCEs are able to compute and end-o-end path as per BRPC procedure 221 [RFC5441] or as per H-PCE procedure (stateless [RFC6805] or 222 stateful [I-D.ietf-pce-stateful-hpce]). 224 o Tunnels refer to LSPs setup by mean of RSVP-TE or Segment Path in 225 a Segment Routing network. 227 +----------------+ +----------------+ 228 | Domain (B) | | Domain (C) | 229 | | | | 230 | /-------|---PCEP---|--------\ | 231 | / | | \ | 232 | [PCE-B] | | [PCE-C] | 233 | / (BN)<------>(BN) | 234 | / | Inter | | 235 +---|--(BN)------+ Domain +----------------+ 236 | ^ Link 237 PCEP | 238 | | Inter-domain Link 239 | v 240 +---|--(BN)------+ 241 | | | 242 | | Domain (A) | 243 | \ | 244 | [PCE-A] | 245 | | 246 | | 247 +----------------+ 249 Example of the representation of 3 domains with 3 PCEs 251 1.2. Terminology 253 ABR: Area Border Routers. Routers used to connect two IGP areas 254 (areas in OSPF or levels in IS-IS). 256 ASBR: Autonomous System Border Router. Router used to connect 257 together ASes of the same or different service providers via one or 258 more inter-AS links. 260 AS: Autonomous System 262 Border Node (BN): a boundary node is either an ABR in the context of 263 inter-area Traffic Engineering or an ASBR in the context of inter-AS 264 Traffic Engineering. 266 Domains: Autonomous System (AS) or IGP Area. An Autonomous System is 267 composed by one or more IGP area. 269 BN-en(i): Entry BN of domain(i) connecting domain(i-1) to domain(i) 270 along a determined sequence of domains. Multiple entry BN-en(i) 271 could be used to connect domain(i-1) to domain(i). 273 BN-ex(i): Exit BN of domain(i) connecting domain(i) to domain(i+1) 274 along a determined sequence of domains. Multiple exit BN-ex(i) could 275 be used to connect domain(i) to domain(i+1). 277 Inter-domain path: A path that crosses two or more domains through a 278 pair of Border Node (BN-ex, BN-en). 280 Local LSP tunnel: A LSP tunnel that do not cross a domain. It is 281 setup between entry BN-en to output BN-ex, any source to output BN-ex 282 or entry BN-en to any destination of the same domain. This LSP could 283 be enforce by means of RSVP-TE signaling or Segment Routing labels 284 stack. 286 Local LSP tunnel(i): A local LSP tunnel of domain(i) 288 IGP-TE: Interior Gateway Protocol with Traffic Engineering support. 289 Both OSPF-TE and IS-IS-TE are identified in this category. 291 Stitching Label (SL): A dedicated label that is used to stitch two 292 RSVP-TE tunnels or two Segment Routing paths. 294 SL(i): A Stitching Label that link domain(i-1) to domain(i). 296 LK(i): A Link that connect BN-ex(i-1) to BN-en(i). Note that BN- 297 ex(i-1) could be connected to BN-en(i) by more than one link. LK(i) 298 serves to identify which of the multiple links will be used for the 299 inter-domain LSP setup. 301 PLSP-ID(i): A PLSP-ID that identify the local tunnel part of an 302 inter-domain tunnel in the domain(i). 304 PCE: Path Computation Element. An entity (component, application, or 305 network node) that is capable of computing a network path or route 306 based on a network graph and applying computational constraints. 308 PCE(i) is a PCE with the scope of domain(i). 310 2. Stitching Label 312 This section introduce the concept of Stitching Label that allows 313 stitching and nesting of local LSP tunnels in order to form inter- 314 domain path that cross several different domains. 316 2.1. Definition 318 The operation of stitch or nest a local LSP tunnel(i) to a local LSP 319 tunnel(i+1) in order to form and inter-domain path simply consist in 320 defining the label that the output BN-ex(i) will use to send its 321 traffic to the entry BN-en(i+1). Indeed, the entry BN-en(i+1) needs 322 to identify the incoming traffic i.e. IP packets, in order to know if 323 this traffic must follow the local LSP tunnel(i+1) or not. 324 Forwarding Equivalent Class (FEC) could be used for that purpose. 325 But, when stitching or nesting tunnels, the FEC is reduce to the 326 incoming label that the entry BN-en(i+1) as chosen for the local LSP 327 tunnel(i+1). 329 In this memo, we introduce the named of 'Stitching Label (SL)' to 330 designate this label. Such label is usually exchange between output 331 BN-ex(i) and entry BN-en(i+1) with the RSVP-TE signaling. But, as we 332 want to avoid to use RSVP-TE signaling due to operational 333 constraints, this Stitching Label will be convey by PCEP protocol. 334 In fact, the Explicit Route Object (ERO) and the Record Route Object 335 (RRO) are defined in order to transport this Stitching Label in the 336 RSVP-TE signaling. As PCEP protocol used RSVP-TE Objects, and in 337 particular the ERO and RRO, it is able to convey the Stitching Label 338 without any modification of the PCEP protocol nor the PCE or RSVP-TE 339 Objects. 341 As per RFC4003 [RFC4003], the Stitching Label will be convey as a 342 companion of an IP address. In our case, this is one of the IP 343 address of the link LK(i) which connects BN-ex(i) to BN-en(i+1) and 344 carries the traffic from the domain(i) to domain(i+1). It is left to 345 implementation to select which of the two IP address of the link 346 LK(i) is used. 348 2.2. Inter-domain LSP-TYPE 350 However, even if PCEP could convey the Stitching Label, a PCC is not 351 aware that a PCE requests or provides such label. For that purpose, 352 this memo propose to use the LSP-TYPE as defined in 353 [I-D.ietf-pce-lsp-setup-type] with new values (See IANA section of 354 this memo) defined as follow: 356 o TBD1: Inter-Domain Traffic engineering end-to-end path is setup 357 using Backward Recursive or Hierarchical method. This new LSP- 358 TYPE value MUST be set in a PCInitiate messages sends by a PCE(i) 359 to its neighbor PCE(i+1) in the Backward Recursive method or by 360 the Parent PCE to the Child PCE(i) to initiate a new inter-domain 361 path. In turn, neighbor PCE(i+1) or Child PCE(i) MUST return a 362 Stitching Label SL with the IP address of the associated link in 363 the RRO of the PCRpt message to PCE(i) or Parent PCE. 365 o TBD2: Inter-Domain Traffic engineering local path is setup using 366 RSVP-TE. This new LSP-TYPE value MUST be set in the PCInitiate 367 message sends by a PCE(i) requesting to a PCC of domain(i) to 368 initiate a new local LSP tunnel(i) which is part of an inter- 369 domain path. This LSP-TYPE value MUST be used by the PCE(i) only 370 after receiving a PCInitiate message with an LSP-TYPE equal to 371 TBD1 from a neighbor PCE(i+1) in the Backward Recursive method or 372 Parent PCE in the Hierarchical method. In turn, the PCC of 373 domain(i) MUST return a Stitching Label SL with the IP address of 374 associated link in the RRO of the PCRpt message. 376 o TBD3: Inter-Domain Traffic engineering local path is setup using 377 Segment Routing. This new LSP-TYPE value MUST be set in the 378 PCInitiate message sends by a PCE(i) requesting to a PCC of 379 domain(i) to initiate a new Segment Routing path which is part of 380 and inter-domain Segment Routing path. This LSP-TYPE value MUST 381 be used by the PCE(i) only after receiving a PCInitiate message 382 with an LSP-TYPE equal to TBD1 from a neighbor PCE(i+1). In turn, 383 the PCC MUST return a Stitching Label SL with the IP address of 384 the associated link in the RRO of the PCRpt message. 386 3. Backward Recursive PCInitiate procedure 388 This section describes how to setup inter-domain paths than cross 389 several different domains by using a Backward Recursive method which 390 is compatible to inter-domain path computation by means of the BRPC 391 procedure as describe in RFC5441 [RFC5441]. 393 3.1. Mode of operation 395 This section describes how PCInitiate and PCRpt messages are combined 396 between PCE in order to setup inter-domain paths between a source 397 domain(1) to a destination domain(n). S and D are respectively the 398 source and destination of the inter-domain path. Domain(1) and 399 domain(n) are different and connected through 0 or more intermediate 400 domains denoted domain(i) with i = (2, n-1). Domains are directly 401 connected when n = 2. 403 First, the PCE(S) run standard BRPC algorithm as per RFC5441 404 [RFC5441] with its neighbor PCEs in order to compute the inter-domain 405 path from S to D, where S and D are respectively a node in the 406 domain(1) and domain(n). Path Key confidentiality as per RFC5520 407 [RFC5520] MAY be used to obfuscate the detailed ERO of the different 408 domains(i). The resulting ERO is of the form {S, PKS(1), BN-ex(1), 409 ..., BN-en(i), PKS(i), BN-ex(i), ..., BN-en(n), PKS(n), D}. As 410 subsequent domains are not aware about the final computed ERO in case 411 of multiple VSPT, the final computed ERO MUST be send in the 412 PCInitiate message to indicate to the subsequent PCEs which solution 413 has been finally chosen. 415 The complete procedure follow the different steps described below: 417 Steps 1: Initialization 419 Once ERO(S, D) computed, PCE(1) sends a PCInitiate message to PCE(2) 420 containing and ERO equal to {S, PKS(1), BN-ex(1), ..., BN-en(i), 421 PKS(i), BN-ex(i), ..., BN-en(n), PKS(n), D}, LSP-TYPE = TBD1 and End- 422 Points Object = (S, D). The ERO corresponds to the one PCE(1) as 423 received from PCE(2) during the BRPC process. In case of multiple 424 EROs, i.e. VSPT > 1, PCE(1) has chosen one of them and used the 425 selected one for the PCInitiate message. PKS(i) could be replaced by 426 the full ERO description if Path Key is not used by PCE(i). 428 When PCE(i) receives a PCInitiate message from domain(i-1) with LSP- 429 TYPE = TBD1 and ERO = {BN-en(i), PKS(i), BN-ex(i), ..., BN-en(n), 430 PKS(n), D)}, it forwards the PCInitiate message to PCE(i+1) once 431 remove its {BN-en(i), PKS(i), BN-ex(i)} part from the ERO. All 432 PCE(i) propagate the PCInitiate message to PCE(i+1) up to PCE(n) i.e. 433 to the domain(n). 435 Steps 2: Actions taken at the destination domain(n) by PCE(n) 437 When PCInitiate message propagation reach the destination domain(n), 438 PCE(n) retrieves the ERO from the PKS(n) if necessary and sends to 439 BN-en(n) a PCInitiate message with the ERO(n) = {BN-en(n), ..., D}, 440 LSP-TYPE= TBD2 and End-Points Object = {BN(n), D} in order to inform 441 the PCC BN-en(n) that this local LSP tunnel(n) is part of an inter- 442 domain path. When the PCC BN-en(n) received the PCInitiate message 443 from its PCE(n), it setup the local LSP tunnels from entry BN-en(n) 444 to D by means of RSVP-TE signaling with the given ERO(n). Once the 445 tunnel setup, it chooses a free label for the Stitching Label SL(n) 446 and add a new entry in its MPLS LFIB with this SL(n) label. Then, it 447 sends a PCRpt message to its PCE(n) with an RRO equal to {[LK(n), 448 SL(n)], RRO(n)} and PLSP-ID(n). Once PCE(n) receives the PCRpt from 449 the PCC BN-en(n) with the RRO, PLSP-ID and LSP-TYPE = TBD2, it sends 450 to the PCE(n-1) a PCRpt containing the RRO equal to {[LK(n), SL(n)]} 451 and PLSP-ID(n). PCE(n) MAY adds {BN(n), D} in the RRO as loose path. 453 Steps i: Actions performed by all intermediate domains(i), for i = 2 454 to n-1 456 1. When the PCE(i) receives a PCRpt message from domain(i+1) with 457 LSP-TYPE = TBD1, RRO = {[LK(i+1), SL(i+1)]} and PLSP-ID(i+1), it 458 retrieves the ERO from the PKS(i) if necessary and sends to the 459 PCC BN-en(i) a PCInitiate message with ERO = {ERO(i), [LK(i+1), 460 SL(i+1)]}, LSP-TYPE = TBD2 and End-Points Object = {BN-en(i), BN- 461 ex(i)} in order to inform the PCC BN-en(i) that this local LSP 462 tunnel(i) is part of an inter-domain path. 464 2. When the PCC BN-en(i) received the PCInitiate message from its 465 PCE(i), it setup the local LSP tunnels from BN-en(i) to BN-ex(i) 466 by means of RSVP-TE signaling with the given ERO(i). 468 3. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 469 is used to instruct the egress node of domain(i), i.e. BN-ex(i) 470 to forward packets belonging to this tunnel with the Stitching 471 Label. Both Label Stitching and IP address of outgoing interface 472 are carried in the ERO = {..., [LK(i+1), SL(i+1)]} as the last 473 SubObject in conformance to [RFC4003]. So that, BN-ex(i) 474 installs in its MPLS LFIB the SWAP instruction to label SL(i+1) 475 with forward to LK(i+1) instead of the usual POP instruction. 477 4. Once the tunnel setup, PCC BN-en(i) chooses a free label for the 478 Stitching Label SL(i) and add a new entry in its MPLS LFIB with 479 this SL(i) label. Then, it sends a PCRpt message to its PCE(i) 480 with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP-ID(i). 482 5. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 483 and LSP-TYPE = TBD2, it sends to the PCE(i-1) a PCRpt message 484 containing the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). 485 PCE(i) MAY adds {BN-en(i), BN-ex(i)} in the RRO as loose path. 487 Steps n: Actions performed at the source domain(1) 489 Once PCE(1) received the PCRpt message from PCE(2) with the RRO 490 containing the label SL(2), it sends a PCInitiate message to PCC node 491 S with ERO equal to {ERO(1), [LK(2), SL(2)]}, LSP_TYPE = 0 and End- 492 Points Object = {S, BN-ex(1)}. This time, the LSP_TYPE is equal to 0 493 as the PCC S does not need to return a Stitching Label SL i.e. it is 494 the head-end of the inter-domain path. Standard PCRpt message is 495 sent back to PCE(1) by the PCC node S. 497 3.2. Example 499 In the figure below, two different domains S and D are interconnected 500 through BN respectively BN-S and BN-D. PE-S and PE-D are edge 501 routers. All routers in the figure are connected to their respective 502 PCE through PCEP protocol. In this example, PCE(S) would setup an 503 inter-domain path between PE-S and PE-D acting as source and 504 destination of the tunnel. Intermediate routers between (PE-S, BN- 505 S), (BN-D and PE-D) as well as RSVP-TE messages are not represented 506 to simplify the figure. But they are all presents. The following 507 notation is used in the figure: 509 o PKS(D) = Path Key corresponding to the path from BN(D) to PE-D 510 o ERO(D) = Explicit Route Object corresponding to the path from 511 BN(D) to PE-D retrieves from PKS(D) 513 o RRO(D) = Record Route Object of local LSP tunnel(D) from BN(D) to 514 PE-D 516 o SL(D) = Stitching Label for local LSP tunnel from BN(D) to PE-D 518 o ERO(S) = Explicit Route Object corresponding to the path from PE-S 519 to BN(S) 521 o RRO(S) = Record Route Object of local LSP tunnel(S) from PE-S to 522 BN(S) 524 PE-S PCE-S BN-D PCE-D 525 | | | | 526 | [ -------- Standard BRPC exchange ------------] 527 | | | | 528 | | PCInitiate(ERO={BN(D), PKS(D)}, LSP-TYPE = TBD1) 529 | | --------------------------------------> | 530 | | | | 531 | | PCInitiate(ERO = ERO(D), LSP-TYPE = TBD2) 532 | | | <------- | 533 | | | | 534 | | PCRpt(RRO = {SL(D), RRO(D)}, LSP-TYPE = TBD2) 535 | | | ------> | 536 | | | | 537 | PCRpt(RRO = {SL(D), PKS(D)}, LSP-TYPE = TBD1, PLSP-ID(D)) 538 | | <-------------------------------------- | 539 | | | | 540 | PCInitiate(ERO={ERO(S), SL(D), BN(D)}, LSP-TYPE = 0) 541 | <------- | | | 542 | | | | 543 | PCRpt(RRO={RRO(S)}, LSP-TYPE = 0) | | 544 | -------> | | | 545 | | | | 547 +----------------------+ +----------------------+ 548 | | | | 549 | +------+ | PCEP | +------+ | 550 | +---->|PCE(S)|<-------------------------------->|PCE(D)| | 551 | | +------+ | | +------+ | 552 | | ^ | | ^ ^ | 553 | | | | | | | | 554 | |PCEP | | | | | | 555 | | |PCEP | | PCEP | | PCEP | 556 | v | | | | | | 557 (PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D) 558 | | Inter-Domain | | 559 | Domain (S) | Link | Domain (D) | 560 +----------------------+ +----------------------+ 562 [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---] 564 Example of inter-domain path setup between two domains 566 3.3. Inter-domain LSP setup procedure completion failure 568 In case of error during LSP setup, PCRpt and or PCErr messages MUST 569 be used to signal the problem to the neighbor PCE domain backward. 570 In particular, if new LSP-TYPE values defined in this memo are not 571 supported by the neighbor PCE or the PCC, the PCE, receptively the 572 PCC, MUST return a PCErr message with Error-Type = 21 (Traffic 573 engineering path setup error) and Error-Value = 1 (Unsupported path 574 setup type) to its neighbor PCE. If a PCE(i) receives a PCInitiate 575 message from its peer PCE(i-1) without LSP-TYPE set to TBD1 or LSP- 576 TYPE set to a value different from TBD1, it MUST return a PCErr 577 message with Error-Type = 21 (Traffic engineering path setup error) 578 and Error-Value = 1 (Unsupported path setup type) to its peer 579 PCE(i-1). 581 If a PCC or a PCE don't return an RRO or an RRO without the Stitching 582 Label SL with the IP address of the associated link following a 583 PCInitiate message with LSP-TYPE set to TBD1, the PCE MUST return a 584 PCErr message with Error-Type = 21 (Traffic engineering path setup 585 error) and Error-Value = TBD4 (No Mandatory Stitching Label is 586 present in the RRO). 588 In case of completion failure, the PCE(i) MUST propagate the PCErr 589 message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate 590 message (R flag set in the SRP Object as per draft pce initiated lsp 591 [RFC8281]) to delete this inter-domain path to its neighbor PCEs. 592 PCE(i) MUST propagate the PCInitiate message and remove their local 593 LSP tunnel by means of PCInitiate message to their PCC BN-en(i) and 594 send back PCRpt message to PCE(i-1). 596 In case of error in domain(i+1), PCE(i) MAY add the AS number of 597 domain(i+1) in the RRO to identify the faulty domain. 599 4. Hierarchical PCInitiate procedure 601 This section describes how to setup inter-domain paths than cross 602 several different domains by using a Hierarchical method which is 603 compatible to inter-domain path computation as describe in [RFC6805]. 605 4.1. Mode of operation 607 This section describes how PCInitiate and PCRpt messages are combined 608 between PCE in order to setup inter-domain paths between a source 609 domain(1) to a destination domain(n). S and D are respectively the 610 source and destination of the inter-domain path. Domain(1) and 611 domain(n) are different and connected through 0 or more intermediate 612 domains denoted domain(i) with i = (2, n-1). Domains are directly 613 connected when n = 2. 615 First, the Parent PCE contacts its Child PCE as per [RFC6805] in 616 order to compute the inter-domain path from S to D, where S and D are 617 respectively a node in the domain(1) and domain(n). Path Key 618 confidentiality as per RFC5520 [RFC5520] MAY be used to obfuscate the 619 detailed ERO of the different domains(i). The resulting ERO is of 620 the form (S, PKS(1), BN-ex(1), ..., BN-en(i), PKS(i), BN-ex(i), ..., 621 BN-en(n), PKS(n), D). 623 The complete procedure follow the different steps described below: 625 Step 1: Initialization 627 Parent PCE sends a PCInitiate message to child PCE(n) with an ERO = 628 {PKS(n)} and End-Points = {BN-en(n), D}. Then, PCE(n) retrieves the 629 ERO from the PKS(n) if necessary and sends to BN-en(n) a PCInitiate 630 message with the ERO(n) = {BN-en(n), ..., D}, LSP-TYPE= TBD2 and End- 631 Points Object = {BN-en(n), D} in order to inform the PCC BN-en(n) 632 that this local LSP tunnel(n) is part of an inter-domain path. When 633 the PCC BN-en(n) received the PCInitiate message from its PCE(n), it 634 setup the local LSP tunnel from entry BN-en(n) to D by means of RSVP- 635 TE signaling with the given ERO(n). Once the tunnel setup, it 636 chooses a free label for the Stitching Label SL(n) and add a new 637 entry in its MPLS LFIB with this SL(n) label. Then, it sends a PCRpt 638 message to its PCE(n) with an RRO equal to {[LK(n), SL(n)], RRO(n)} 639 and PLSP-ID(n). Once PCE(n) receives the PCRpt from the PCC BN-en(n) 640 with the RRO, PLSP-ID and LSP-TYPE = TBD2, it sends to its Parent PCE 641 a PCRpt containing the RRO equal to {[LK(n), SL(n)]} and PLSP-ID(n). 642 PCE(n) MAY adds {BN-en(n), D} in the RRO as loose path. 644 Steps i: Actions performed for all intermediate domains(i), for i = 645 n-1 to 2 647 1. Parent PCE sends a PCInitiate message to Child PCE(i) with LSP- 648 TYPE = TBD1, ERO = {PKS(i), [LK(i+1), SL(i+1)]} and End-Points = 649 {BN-en(i), BN-ex(i)} 651 2. Then, PCE(i) retrieves the ERO from the PKS(i) if necessary and 652 sends to the PCC BN-en(i) a PCInitiate message with ERO = 653 {ERO(i), [LK(i+1), SL(i+1)]}, LSP-TYPE = TBD2 and End-Points 654 Object = {BN-en(i), BN-ex(i)} in order to inform the PCC BN-en(i) 655 that this local LSP tunnel(i) is part of an inter-domain path. 657 3. When the PCC BN-en(i) received the PCInitiate message from its 658 PCE(i), it setup the local LSP tunnel from BN-en(i) to BN-ex(i) 659 by means of RSVP-TE signaling with the given ERO(i). 661 4. Egress Control mechanism, as per RFC4003 section 2.1 [RFC4003], 662 is used to instruct the egress node of domain(i), i.e. BN-ex(i) 663 to forward packets belonging to this tunnel with the Stitching 664 Label. Both Label Stitching and IP address of outgoing interface 665 are carried in the ERO = {..., [LK(i+1), SL(i+1)]} as the last 666 SubObject in conformance to [RFC4003]. So that, BN-ex(i) 667 installs in its MPLS LFIB the SWAP instruction to label SL(i+1) 668 with forward to LK(i+1) instead of the usual POP instruction. 670 5. Once the tunnel setup, PCC BN-en(i) chooses a free label for the 671 Stitching Label SL(i) and add a new entry in its MPLS L(F)IB with 672 this SL(i) label. Then, it sends a PCRpt message to its PCE(i) 673 with an RRO equal to {[LK(i), SL(i)], RRO(i)} and PLSP-ID(i). 675 6. Once PCE(i) receives the PCRpt from the PCC BN-en(i) with the RRO 676 and LSP-TYPE = TBD2, it sends to its Parent PCE a PCRpt message 677 containing the RRO equal to {[LK(i), SL(i)]} and the PLSP-ID(i). 678 PCE(i) MAY adds {BN-en(i), BN-ex(i)} in the RRO as loose path. 680 7. Once Parent PCE receives the PCRpt from the Child PCE(i), it 681 stores the corresponding PLSP-ID for this inter-domain tunnel 682 part 684 Steps n: Actions performed to the source domain(1) 686 Finally, Parent PCE sends a last PCInitiate message to Child PCE(1) 687 with LSP-TYPE = TBD1, ERO = {PKS(1), [LK(2), SL(2)]} and End-Points = 688 {S, BN-ex(1)}. In turn, Child PCE(1) sends a PCInitiate message to 689 PCC node S with ERO equal to {ERO(1), [LK(2), SL(2)]}, LSP_TYPE = 0 690 and End-Points Object = {S, BN-ex(1)}. This time, the LSP_TYPE is 691 equal to 0 as the PCC S does not need to return a Stitching Label SL, 692 i.e. it is the head-end of the inter-domain path. Standard PCRpt 693 message is sent back to PCE(1) by the PCC node S. In turn, Child 694 PCE(1) send a final PCRpt message to the Parent PCE with the PSLP- 695 ID(1). PCE(1) MAY adds {S, BN-ex(1)} in the RRO as loose path. 697 4.2. Inter-domain LSP setup procedure completion failure 699 In case of error during LSP setup, PCRpt and or PCError messages MUST 700 be used to signal the problem to the Parent PCE. In particular, if 701 new LSP-TYPE values defined in this memo are not supported by the 702 Child PCE or the PCC, the Child PCE, receptively the PCC, MUST return 703 a PCErr message with Error-Type = 21 (Traffic engineering path setup 704 error) and Error-Value = 1 (Unsupported path setup type) to its 705 Parent PCE. If Child PCE(i) receives a PCInitiate message from its 706 Parent PCE without LSP-TYPE set to TBD1 or LSP-TYPE set to a value 707 different from TBD1, it MUST return a PCErr message with Error-Type = 708 21 (Traffic engineering path setup error) and Error-Value = 1 709 (Unsupported path setup type) to its Parent PCE. 711 If a Child PCE or a PCC don't return an RRO or an RRO without the 712 Stitching Label SL with the IP address of the associated link 713 following a PCInitiate message with LSP-TYPE set to TBD1, the Parent 714 PCE, respectively the Child PCE, MUST return a PCErr message with 715 Error-Type = 21 (Traffic engineering path setup error) and Error- 716 Value = TBD4 (No Mandatory Stitching Label is present in the RRO). 718 In case of completion failure, the Parent PCE MUST MUST send a 719 PCInitate message (R flag set in the SRP Object as per draft pce 720 initiated lsp [RFC8281]) to delete this inter-domain path to the 721 Child PCEs that already setup their respective part of the inter- 722 domain tunnel. Child PCE(i) MUST remove their local LSP tunnel by 723 means of PCInitiate message with R flag set to 1 to their PCC BN- 724 en(i) and send back PCRpt message to the Parent PCE. 726 4.3. Example for Stateful H-PCE Stiching procedure 728 Taking the sample hierarchical domain topology example from [RFC6805] 729 as the reference topology for the entirety of this section. 731 ----------------------------------------------------------------- 732 | Domain 5 | 733 | ----- | 734 | |PCE 5| | 735 | ----- | 736 | | 737 | ---------------- ---------------- ---------------- | 738 | | Domain 1 | | Domain 2 | | Domain 3 | | 739 | | | | | | | | 740 | | ----- | | ----- | | ----- | | 741 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 742 | | ----- | | ----- | | ----- | | 743 | | | | | | | | 744 | | ----| |---- ----| |---- | | 745 | | |BN11+---+BN21| |BN23+---+BN31| | | 746 | | - ----| |---- ----| |---- - | | 747 | | |S| | | | | |D| | | 748 | | - ----| |---- ----| |---- - | | 749 | | |BN12+---+BN22| |BN24+---+BN32| | | 750 | | ----| |---- ----| |---- | | 751 | | | | | | | | 752 | | ---- | | | | ---- | | 753 | | |BN13| | | | | |BN33| | | 754 | -----------+---- ---------------- ----+----------- | 755 | \ / | 756 | \ ---------------- / | 757 | \ | | / | 758 | \ |---- ----| / | 759 | ----+BN41| |BN42+---- | 760 | |---- ----| | 761 | | | | 762 | | ----- | | 763 | | |PCE 4| | | 764 | | ----- | | 765 | | | | 766 | | Domain 4 | | 767 | ---------------- | 768 | | 769 ----------------------------------------------------------------- 771 Hierarchical domain topology from RFC6805 773 Section 3.3.1 of [I-D.ietf-pce-stateful-hpce]describes the per-domain 774 stitched LSP mode and list all the steps needed. To support SL based 775 stiching, using the reference architecture described in Figure above, 776 the steps are modified as follows (note that we do not use PKS in 777 this example for simplicity): 779 Step 1: initialization 781 The P-PCE (PCE5) is requested to initiate a LSP. Steps 4 to 10 of 782 section 4.6.2 of [RFC6805] are executed to determine the end to end 783 path, which are broken into per-domain LSPs e.g. {S-BN41, BN41-BN33, 784 BN33-D} 786 Step 2: LSP (BN33-D) at PCE3: 788 1. The P-PCE (PCE5) sends the initiate request to the child PCE 789 (PCE3) via PCInitiate message for LSP (BN33-D) with ERO=(BN33..D) 790 and LSP-TYPE=TBD1 792 2. The PCE3 further propagates the initiate message to BN33 with the 793 ERO and LSP-TYPE=TBD2/TBD3 based on setup type 795 3. BN33 initiates the setup of the LSP as per the path and reports 796 to the PCE3 the LSP status ("GOING-UP") 798 4. The PCE3 further reports the status of the LSP to the P-PCE 799 (PCE5) 801 5. The node BN33 notifies the LSP state to PCE3 when the state is 802 "UP" it also carry the stitching label (SL33) in RRO as 803 (SL33,BN33..D) 805 6. The PCE3 further reports the status of the LSP to the P-PCE 806 (PCE5) as well as carry the stitching label (SL33) in RRO as 807 (LK33,SL33,BN33..D) 809 Step 3: LSP (BN41-BN33) at PCE4 811 1. The P-PCE (PCE5) sends the initiate request to the child PCE 812 (PCE4) via PCInitiate message for LSP (BN41-BN33) with 813 ERO=(BN41..BN42,LK33,SL33,BN33) and LSP-TYPE=TBD1 815 2. The PCE4 further propagates the initiate message to BN41 with the 816 ERO and LSP-TYPE=TBD2/TBD3 based on setup type. In case of 817 RSVP_TE, the node BN41 encode the stitching label SL33 as part of 818 the ERO to make sure the node BN42 uses the label SL33 towards 819 node BN33. In case of SR, the label SL33 is part of the label 820 stack pushed at node BN41 822 3. BN41 initiates the setup of the LSP as per the path and reports 823 to the PCE4 the LSP status ("GOING-UP") 825 4. The PCE4 further reports the status of the LSP to the P-PCE 826 (PCE5) 828 5. The node BN41 notifies the LSP state to PCE4 when the state is 829 "UP" it also carry the stitching label (SL41) in RRO as 830 (LK41,SL41,BN41..BN33) 832 6. The PCE4 further reports the status of the LSP to the P-PCE 833 (PCE5) as well as carry the stitching label (SL41) in RRO as 834 (LK41,SL41,BN41..BN33) 836 Step 3: LSP (S-BN41) for PCE1 838 1. The P-PCE (PCE5) sends the initiate request to the child PCE 839 (PCE1) via PCInitiate message for LSP (S-BN41) with 840 ERO=(S..BN13,LK41,SL41,BN41) 842 2. The PCE1 further propagates the initiate message to node S with 843 the ERO. In case of RSVP_TE, the node S encode the stitching 844 label SL41 as part of the ERO to make sure the node BN13 uses the 845 label SL41 towards node BN41. In case of SR, the label SL41 is 846 part of the label stack pushed at node S 848 3. S initiates the setup of the LSP as per the path and reports to 849 the PCE1 the LSP status ("GOING-UP") 851 4. The PCE1 further reports the status of the LSP to the P-PCE 852 (PCE5) 854 5. The node S notifies the LSP state to PCE1 when the state is"UP" 856 6. The PCE1 further reports the status of the LSP to the P-PCE 857 (PCE5) 859 In this way, per-domain LSP are stitched together using the stitching 860 label (SL). The per-domain LSP MUST be setup from the destination 861 domain towards the source domain one after the other. 863 Once the per-domain LSP is setup, the entry BN chooses a free label 864 for the Stitching Label SL and add a new entry in its MPLS LFIB with 865 this SL label. The SL from the destination domain is propagated to 866 adjacent transit domain, towards the source domain at each step. 867 This happens through the entry BN to C-PCE to the P-PCE and vice- 868 versa. In case of RSVP-TE, the entry BN further propagates the SL 869 label to the exit BN via RSVP-TE. In case of SR, the SL label is 870 pushed as part of the SR label stack. 872 5. Inter-domain LSP Management 874 This section describe how inter-domain LSPs could be manage. 876 5.1. Identification of inter-domain tunnels 878 First, in order to manage inter-domain tunnels composed by the 879 stitching or nesting of local tunnels, it is important to identify 880 them. For this purpose, PLSP-ID managed by PCEs are combined to one 881 provided by PCCs to form global identifier as follow: 883 o PCE(i) in the Backward Recursive method or the Child PCE in 884 Hierarchical method MUST create a new unique PLSP-ID for this 885 inter-domain LSP part and MUST send it in the PCRpt message, to 886 the PCE(i-1), respectively the Parent PCE. In addition this new 887 PLSP-ID MUST be associated to the one received from the PCC that 888 instantiate the local tunnel part for further reference. 890 o In Hierarchical mode, Parent PCE MUST store and associate the 891 different PLSP-ID(i)s received from the different Child PCE(i)s in 892 order to identify the different part of the inter-domain paths. 894 o In Backward Recursive method, PCE(i) MUST store and associate its 895 PLSP-ID(i) and the PLSP-ID(i+1) it received from the PCE(i+1). 896 PCE(n) i.e. the last one in the chain, don't need to perform such 897 association. 899 Further reference to the inter-domain tunnel will use this PLSP- 900 ID(i). In Backward Recursive method, PCE(i) MUST replace the PLSP- 901 ID(i) by PLSP-ID(i+1) in the PCUpd message before propagating it to 902 PCE(i+1) and PCE(i) MUST replace the PLSP-ID(i+1) by PLSP-ID(i) in 903 the PCRpt message before propagating it to the PCE(i-1). In 904 Hierarchical method, Parent PCE MUST use the corresponding PLSP-ID(i) 905 of the Child PCE(i). 907 5.2. Inter-domain LSP management 909 For the Backward Recursive method, each domain manages their 910 respective local LSP tunnel part of an inter-domain path 911 independently of each other. In particular, Stitching Label(i) is 912 managed by domain(i) and is of interest of domain(i-1) only. Thus, 913 Stitching Label SL(i) is not supposed to be propagated to other 914 domains. The same behavior apply to PLSP-ID(i). In Hierarchical 915 method, the Parent PCE MUST ensure the correct distribution of 916 Stitching Label SL(i) to Child PCE(i-1. The PLSP-ID(i) is kept for 917 the usage of the Parent PCE and thus is not propagated. 919 If a PCE(i) needs to modify its local LSP tunnel(i) with PCUpd 920 message to the PCC BN-en(i), once PCRpt message received by the PCC 921 BN-en(i), it MUST sends a new PCRpt message to its neighbor PCE(i-1) 922 in Backward Recursive method, respectively to Parent PCE in 923 Hierarchical method, to advertise it of the modification. In 924 particular. In this case PLSP-ID(i) is used to identify the inter- 925 domain tunnel. PCE(i-1), respectively the Parent PCE, MUST propagate 926 the PCRpt message if the modification imply the previous domain e.g. 927 if the PCRpt indicates that the Stitching Label SL(i) has changed. 929 PCE(1), respectively Parent PCE, could modify the inter-domain path. 930 For that purpose, it MUST sends a PCUpd message to its neighbor PCEs, 931 respectively Child PCE, using the PLSP-ID it received. Each PCE(i) 932 MUST process PCUpd message the same way they process PCInitiate 933 message as define in section 3.1 for Backward Recursive method and in 934 section 4.1 for Hierarchical method. 936 In case a failure appear in domain(i), e.g. tunnel becoming down, 937 PCE(i) MUST sends a PCRpt message to its neighbor PCE(i-1), 938 respectively its Parent PCE to advertise it of the problem in its 939 local part of the inter-domain path. Once PCE(1), respectively 940 Parent PCE, receives this PCRpt message indicating that the tunnel is 941 down, it is up to the PCE(1), respectively Parent PCE to take 942 appropriate correction e.g. start a new path computation to update 943 the ERO. 945 5.3. Modification of inter-domain LSP 947 Modification of local LSP tunnel, BN-en(i) and BN-ex(i) is left for 948 further study. 950 5.4. Removal of inter-domain LSP 952 Deletion of inter-domain LSP is only possible by the inter-domain 953 tunnel initiator. For Backward Recursive method, PCInitiate message 954 with R flag set to 1 and PLSP-ID set accordingly to section 5.1, is 955 sent by PCE(1) to PCE(n) through PCE(i) and process the same way as 956 describe in section 3.1. For Hierarchical method, PCInitiate message 957 with R flag set to 1 is sent by the Parent PCE to each Child PCE(i) 958 with corresponding PLSP-ID(i) and process accordingly to section 4.1. 959 Each domain PCE(i) is responsible to delete its part of the tunnel 960 and PCC MUST remove the Stitching label SL in its LFIB in addition to 961 the tunnel when it received the PCInitiate message with the R flag 962 set to 1 and corresponding PLSP-ID. 964 6. Applicability 966 The newly introduce Stitching Label SL serves to stitch or nest part 967 of local LSP tunnels to form an inter-domain path. Each domain is 968 free to decide if the tunnel is stitched or nested. For example, a 969 domain(i) may decided to nest the incoming local LSP tunnel into a 970 higher hierarchy of tunnel for Traffic Engineering purpose. A PCE(i) 971 may also decided to group local LSP tunnels part of inter-domain 972 paths into a higher hierarchical tunnel to carry all these local LSP 973 tunnels from one BN-en(i) to one BN-ex(i). 975 To use Segment Routing instead of RSVP-TE to setup the local LSP 976 tunnels as defined in draft pce segment routing 977 [I-D.ietf-pce-segment-routing], PCE(i) MUST send PCInitiate message 978 with LSP-TYPE = TBD3 instead of TBD2 to advertise their respective 979 PCC that the local LSP tunnels is enforce by means of Segment 980 Routing. Stitching Label SL(i) will be inserted in the label stack 981 in order to become the top label in the stack when the packet reach 982 BN-en(i+1): BN-en(i) MUST install in its MPLS LFIB a SWAP instruction 983 to the replace the incoming Stitching Label SL(i) by the label stack 984 given by the ERO(i) plus the Stitching Label SL(i+1) as the last 985 label in the stack. The Stitching Label SL(i) serves as entry FEC 986 for BN-en(i) to identify the packets that follow the next Segment 987 Path. When packet reach BN-ex(i), the last label in the stack before 988 the label SL(i+1) corresponds to the SID that design BN-en(i+1). 989 This inter-domain SID could be obtain as per draft Egress Peer 990 Engineering [I-D.ietf-idr-bgpls-segment-routing-epe]. 992 The Stitching Label SL could serves to stitch Segment Path and RSVP- 993 TE tunnel. Indeed, each domain is free to enforce its part of the 994 inter-domain path with the underlying mechanism it chosen. Stitching 995 Label SL will be part of the label stack in order to become the top 996 label in the stack when reaching the BN-en(i+1). This Stitching 997 Label could be swap as usual if the next domain uses RSVP-TE tunnel. 998 When the previous domain uses a RSVP-TE tunnel, the Stitching Label 999 will serve as key for the BN-en(i+1) to determine which label stack 1000 it must push on top of the packet for a Segment Routing path. 1002 During the instantiation procedure, if PCE(i) decides to reuse a 1003 local tunnel which is not yet part of an inter-domain tunnel, it 1004 SHOULD send a PCUpd message with LSP-TYPE = TBD2 to the PCC BN-en(i) 1005 in order to request a Stitching Label SL(i) and new ERO(i) to include 1006 the Stitching Label SL(i+1) and the associated link to the previous 1007 ERO. 1009 [I-D.ietf-teas-actn-framework] describes framework for Abstraction 1010 and Control of TE Networks (ACTN), where each Physical Network 1011 Controller (PNC) is equivalent to C-PCE and P-PCE is the Multi-Domain 1012 Service Coordinator (MDSC). The Per domain stitched LSP as per the 1013 Hierarchical PCE architecture described in Section 3.3.1 and 1014 Section 4.1 of [I-D.ietf-pce-stateful-hpce] is well suited for ACTN. 1015 The stitching label (SL) mechanism as described in this document is 1016 well suited for ACTN when per domain LSP needs to be stitched to form 1017 an E2E tunnel or a VN Member. It is to be noted that certain VNs 1018 require isolation from other clients. The stitching label mechanism 1019 described in this document can be applicable to the VN isolation use- 1020 case by uniquely identifying the concatenated stitching labels across 1021 multi-domain only to a certain VN member or an E2E tunnel. 1023 Inter-layer scenario is left for further study. 1025 7. IANA Considerations 1027 7.1. LSP-TYPE values 1029 Draft pce lsp setup type [I-D.ietf-pce-lsp-setup-type] defines the 1030 PATH-SETUP-TYPE TLV and requests that IANA creates a registry to 1031 manage the value of the PATH_SETUP_TYPE TLV's PST field. IANA is 1032 requested to allocate a new code point in the PCEP PATH_SETUP_TYPE 1033 TLV PST field registry, as follows: 1035 +-------+-----------------------------------------------+-----------+ 1036 | Value | Description | Reference | 1037 +-------+-----------------------------------------------+-----------+ 1038 | TBD1 | Inter-Domain Traffic engineering end-to-end | This | 1039 | | path is setup using Backward Recursive method | Document | 1040 | TBD2 | Inter-Domain Traffic engineering local path | This | 1041 | | is setup using RSVP-TE | Document | 1042 | TBD3 | Inter-Domain Traffic engineering local path | This | 1043 | | is setup using Segment Routing | Document | 1044 +-------+-----------------------------------------------+-----------+ 1046 7.2. PCEP-Error Object 1048 IANA is requested to allocate code-points in the PCEP-ERROR Object 1049 Error Values registry for a new error-value or Error-Type 21 Invalid 1050 traffic engineering path setup: 1052 +-------------+------------------------------------------+ 1053 | Error-Value | Description | 1054 +-------------+------------------------------------------+ 1055 | TBD4 | Missing Mandatory Stitching Label in RRO | 1056 +-------------+------------------------------------------+ 1058 8. Security Considerations 1060 No modification of PCE protocol (PCEP) has been requested by this 1061 draft which not introduce any issue regarding security. Concerning 1062 the PCEP session between PCEs, authors recommend to use the secure 1063 version of PCEP as defined in draft secure transport for PCEP 1064 [RFC8253] or use any other secure tunnel mechanism e.g. IPsec tunnel 1065 to transport PCEP session between PCE. 1067 9. Acknowledgements 1069 The authors want to thanks PCE's WG members. 1071 10. Disclaimer 1073 This work has been performed in the framework of the H2020-ICT-2014 1074 project 5GEx (Grant Agreement no. 671636), which is partially funded 1075 by the European Commission. This information reflects the 1076 consortium's view, but neither the consortium nor the European 1077 Commission are liable for any use that may be done of the information 1078 contained therein. 1080 11. References 1082 11.1. Normative References 1084 [I-D.ietf-pce-lsp-setup-type] 1085 Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1086 Hardwick, "Conveying path setup type in PCEP messages", 1087 draft-ietf-pce-lsp-setup-type-10 (work in progress), May 1088 2018. 1090 [I-D.ietf-pce-stateful-hpce] 1091 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 1092 and O. Dios, "Hierarchical Stateful Path Computation 1093 Element (PCE).", draft-ietf-pce-stateful-hpce-05 (work in 1094 progress), June 2018. 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, 1098 DOI 10.17487/RFC2119, March 1997, 1099 . 1101 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1102 Element (PCE)-Based Architecture", RFC 4655, 1103 DOI 10.17487/RFC4655, August 2006, 1104 . 1106 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1107 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1108 DOI 10.17487/RFC5440, March 2009, 1109 . 1111 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1112 "A Backward-Recursive PCE-Based Computation (BRPC) 1113 Procedure to Compute Shortest Constrained Inter-Domain 1114 Traffic Engineering Label Switched Paths", RFC 5441, 1115 DOI 10.17487/RFC5441, April 2009, 1116 . 1118 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1119 Path Computation Element Architecture to the Determination 1120 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1121 DOI 10.17487/RFC6805, November 2012, 1122 . 1124 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1125 Computation Element Communication Protocol (PCEP) 1126 Extensions for Stateful PCE", RFC 8231, 1127 DOI 10.17487/RFC8231, September 2017, 1128 . 1130 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1131 Computation Element Communication Protocol (PCEP) 1132 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1133 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1134 . 1136 11.2. Informative References 1138 [I-D.dong-pce-discovery-proto-bgp] 1139 Dong, J., Chen, M., Dhody, D., Tantsura, J., Kumaki, K., 1140 and T. Murai, "BGP Extensions for Path Computation Element 1141 (PCE) Discovery", draft-dong-pce-discovery-proto-bgp-07 1142 (work in progress), July 2017. 1144 [I-D.ietf-idr-bgpls-segment-routing-epe] 1145 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 1146 Dong, "BGP-LS extensions for Segment Routing BGP Egress 1147 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 1148 epe-15 (work in progress), March 2018. 1150 [I-D.ietf-pce-segment-routing] 1151 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1152 and J. Hardwick, "PCEP Extensions for Segment Routing", 1153 draft-ietf-pce-segment-routing-11 (work in progress), 1154 November 2017. 1156 [I-D.ietf-teas-actn-framework] 1157 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 1158 Control of Traffic Engineered Networks", draft-ietf-teas- 1159 actn-framework-15 (work in progress), May 2018. 1161 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1162 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1163 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1164 . 1166 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1167 Switching (GMPLS) Signaling Resource ReserVation Protocol- 1168 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1169 DOI 10.17487/RFC3473, January 2003, 1170 . 1172 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 1173 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 1174 . 1176 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1177 Hierarchy with Generalized Multi-Protocol Label Switching 1178 (GMPLS) Traffic Engineering (TE)", RFC 4206, 1179 DOI 10.17487/RFC4206, October 2005, 1180 . 1182 [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, 1183 "Label Switched Path Stitching with Generalized 1184 Multiprotocol Label Switching Traffic Engineering (GMPLS 1185 TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, 1186 . 1188 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1189 "Preserving Topology Confidentiality in Inter-Domain Path 1190 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1191 DOI 10.17487/RFC5520, April 2009, 1192 . 1194 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1195 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1196 Path Computation Element Communication Protocol (PCEP)", 1197 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1198 . 1200 Authors' Addresses 1202 Olivier Dugeon 1203 Orange Labs 1204 2, Avenue Pierre Marzin 1205 Lannion 22307 1206 France 1208 Email: olivier.dugeon@orange.com 1210 Julien Meuric 1211 Orange Labs 1212 2, Avenue Pierre Marzin 1213 Lannion 22307 1214 France 1216 Email: julien.meuric@orange.com 1218 Young Lee 1219 Huawei Technologies 1220 5340 Legacy Drive, Building 3 1221 Plano TX 75023 1222 USA 1224 Email: leeyoung@huwaei.com 1226 Drhuv Dhody 1227 Huawei Technologies 1228 Divyashree Techno Park, Whitefield 1229 Bangalore Karnataka 560066 1230 India 1232 Email: dhruv.ietf@gmail.com 1233 Daniele Ceccarelli 1234 Ericsson 1235 Torshamnsgatan, 48 1236 Stockholm 1237 Sweden 1239 Email: daniele.ceccarelli@ericsson.com