idnits 2.17.1 draft-dugeon-brpc-stateful-00.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 (March 13, 2017) is 2600 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 195, but not defined == Missing Reference: 'PCE-C' is mentioned on line 195, but not defined == Missing Reference: 'PCE-A' is mentioned on line 207, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-07) exists of draft-dong-pce-discovery-proto-bgp-06 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-03 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-18) exists of draft-ietf-pce-pceps-11 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-08 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 Summary: 2 errors (**), 0 flaws (~~), 10 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 5 Expires: September 14, 2017 March 13, 2017 7 A Backward Recursive PCE-initiated inter-domain LSP Setup 8 draft-dugeon-brpc-stateful-00 10 Abstract 12 The Path Computation Element (PCE) working group (WG) has produced a 13 set of RFCs to standardize the behavior of the Path Computation 14 Element as a tool to help MPLS-TE, GMPLS LSP tunnels and Segment 15 Routing paths placement. This also include the ability to compute 16 inter-domain LSPs or Segment Routing path following a distributed or 17 hierarchical approach. In complement to the original stateless mode, 18 a stateful mode has been added. In particular, the new PCInitiate 19 message allows a PCE to directly ask a PCC to setup an MPLS-TE, GMPLS 20 LSP tunnels or a Segment Routing path. However, once computed, the 21 inter-domain LSPs or Segment Routing path are hard to setup in the 22 underlying network. Especially, in operational network, RSVP-TE 23 signaling is not enable between BGP border routers. But, such RSVP- 24 TE signaling is mandatory to setup contiguous LSP tunnels or to 25 stitch or nest independent LSP tunnels to form the end-to-end inter- 26 domain LSP tunnels. This draft propose to combine a Backward 27 Recursive method with PCInitiate message to setup independent LSP 28 tunnels per domain and stitch or nest the different LSP tunnels to 29 setup end-to-end inter-domain LSP tunnels without the need of inter- 30 domain signaling between BGP border routers. A new Stitching Label 31 definition and new LSP-TYPE code points are proposed for that 32 purpose. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on September 14, 2017. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. General assumptions . . . . . . . . . . . . . . . . . . . 4 76 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Stitching Label . . . . . . . . . . . . . . . . . . . . . . . 6 78 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 6 79 2.2. Inter-domain LSP-TYPE . . . . . . . . . . . . . . . . . . 7 80 3. Inter-domain LSP tunnels setup procedure . . . . . . . . . . 8 81 3.1. Mode of operation . . . . . . . . . . . . . . . . . . . . 8 82 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.3. Inter-domain LSP setup procedure completion failure . . . 11 84 3.4. Inter-domain LSP management . . . . . . . . . . . . . . . 12 85 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 5.1. LSP-TYPE values . . . . . . . . . . . . . . . . . . . . . 13 88 5.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 14 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 8.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Problem Statement 98 Looking to the different RFCs that describe the PCE architecture and 99 in particular PCE based architecture [RFC4655], PCE protocol 100 [RFC5440], BRPC [RFC5441] and H-PCE [RFC6805], the Path Computation 101 Element (PCE) is able to compute inter-domain path in complement to 102 intra-domain computation. Such inter-domain paths could then serve 103 as the Explicit Route Object input for the RSVP-TE signaling to setup 104 the LSPs tunnel within the underlying network. Three sort of end-to- 105 end LSP tunnels could be established: 107 o Contiguous tunnels: The RSVP-TE signaling crosses the boundary 108 between two domains e.g. between two AS Border Routers (ASBR) like 109 if it is two routers of the same domain. This kind of tunnel is 110 not recommended mostly for security and scalability purpose. In 111 addition, the initiating domain imposes huge constraints on 112 subsequent domains, because they undergo the tunnel request 113 without being able to control it. 115 o Stitching tunnels: Each domain establishes in its own network the 116 corresponding part of the end-to-end LSP tunnel independently. 117 Then, a second end-to-end RSVP-TE Path message is sent by the 118 initiating domain to stitch the different tunnel parts to form the 119 end-to-end LSP tunnel. In fact, this second RSVP-TE Path message 120 is used by border nodes to exchange the label that must be used by 121 the previous domain to send the traffic in order that the IP 122 packets follow the next LSP tunnel in the following domain. These 123 labels are convey in the RSVP-TE Resv message. 125 o Nesting tunnels: This is similar to the stitching mode but, this 126 time, with the possibility to setup tunnel hierarchy. For 127 example, an LSP tunnel between two edge domains crossing a transit 128 domain could be inserted into a tunnel of higher hierarchy in the 129 transit domain. Again, a second end-to-end RSVP-TE Path message 130 is sent from the source to the destination. Labels that must be 131 used to nest local tunnels are carried by the RSVP-TE Resv 132 message. 134 In all case, RSVP-TE signaling must be exchange between the different 135 domains. However, from an operational point of view, looking to 136 different networks under the responsibility of different 137 administrative entities, only BGP protocol are setup and configured 138 between AS Border Routers (ASBR). Indeed, to the author's knowledge, 139 there is no example of operational networks that enable RSVP-TE 140 between ASBR. Technology speaking, this is possible and many RFCs 141 describe how to use RSVP-TE at the inter-domain. But, due to 142 security, scalability, management and contract constraints, RSVP-TE 143 is no longer exposed at the network boundary. To circumvent the 144 security issue, RSVP-TE could be carry inside an IPsec tunnel between 145 ASBR, but, this not eliminate the scalability aspect nor the 146 constraints impose by seting up and end-to-end LSP tunnels. 148 The purpose of this memo is to take the benefit of PCE stateful mode 149 as per draft pce stateful [I-D.ietf-pce-stateful-pce] and draft pce 150 initiated [I-D.ietf-pce-pce-initiated-lsp] to stitch or nest inter- 151 domain LSP tunnels directly using PCEP protocol between domain's PCE 152 instead of using RSVP-TE signaling at the inter-domain while keeping 153 each operator independently setup their respective part of the end- 154 to-end LSP tunnels. PCInitiated message is used in a Backward 155 Recursive way like the PCReq message in BRPC [RFC5441], to 156 recursively setup the end-to-end tunnel. PCRep message is used to 157 automatically stitch or nest the different local LSP tunnels. And, 158 PCRep in conjunction of PCUpd messages are used to maintain, modify 159 and remove end-to-end LSP tunnels. 161 1.1. General assumptions 163 In the rest of this document, we used the same references as per BRPC 164 [RFC5441] and make the following set of assumptions (see figure 165 below): 167 o Domain refers to an IGP area or an Autonomous System (AS). 169 o Inter-domain LSP tunnel is used to refer to an LSP tunnel that 170 cross two or more different domains as defined previously, 172 o At least, one PCE is deployed in each domain. These PCE are all 173 stateful active capable and could request to enforce LSP tunnels 174 in their respective domain by means of PCInitiate messages. 176 o LSRs, including border nodes, are PCC enable and support stateful 177 active mode. PCEP sessions is established between these routers 178 and their domain's PCE. 180 o Each PCE establishes a PCEP session with its respective neighbor 181 domain's PCE. The way a PCE discover its neighboring PCE is out 182 of scope of this draft. These information could be fulfill 183 administratively or automatically discovered through, for example 184 per draft 'BGP Extensions for Path Computation Element (PCE) 185 Discovery' [I-D.dong-pce-discovery-proto-bgp], 187 o PCEs are able to compute and end-o-end path as per BRPC procedure 188 [RFC5441]. 190 +----------------+ +----------------+ 191 | Domain (B) | | Domain (C) | 192 | | | | 193 | /-------|---PCEP---|--------\ | 194 | / | | \ | 195 | [PCE-B] | | [PCE-C] | 196 | / (BN)<------>(BN) | 197 | / | Inter | | 198 +---|--(BN)------+ Domain +----------------+ 199 | ^ Link 200 PCEP | 201 | | Inter-domain Link 202 | v 203 +---|--(BN)------+ 204 | | | 205 | | Domain (A) | 206 | \ | 207 | [PCE-A] | 208 | | 209 | | 210 +----------------+ 212 Example of the representation of 3 domains with 3 PCEs 214 1.2. Terminology 216 ABR: Area Border Routers. Routers used to connect two IGP areas 217 (areas in OSPF or levels in IS-IS). 219 ASBR: Autonomous System Border Router. Router used to connect 220 together ASes of the same or different service providers via one or 221 more inter-AS links. 223 AS: Autonomous System 225 Border Node (BN): a boundary node is either an ABR in the context of 226 inter-area Traffic Engineering or an ASBR in the context of inter-AS 227 Traffic Engineering. 229 Domains: Autonomous System (AS) or IGP Area. An Autonoumous System 230 is composed by one or more IGP area. 232 Entry BN of domain(i): a BN connecting domain(i-1) to domain(i) along 233 a determined sequence of domains. Multiple entry BN(i) could be used 234 to connect domain(i-1) to domain(i). 236 Exit BN of domain(i): a BN connecting domain(i) to domain(i+1) along 237 a determined sequence of domains. Multiple exit BN(i) could be used 238 to connect domain(i) to domain(i+1). 240 Inter-domain LSP tunnel: A LSP tunnel that crosses two or more 241 domains through a per of Border Node. 243 Local LSP tunnel: A LSP tunnel that do not cross a domain. It is 244 setup between entry BN to exit BN, any source to exit BN or entry BN 245 to any destination of the same domain. 247 Local LSP tunnel(i): A local LSP tunnel of domain(i) 249 IGP-TE: Interior Gateway Protocol with Traffic Engineering support. 250 Both OSPF-TE and IS-IS-TE are identified in this category. 252 Stitching Label (SL): A dedicated label that is used to stitch two 253 RSVP-TE tunnels or two Segment Routing paths. 255 PCE: Path Computation Element. An entity (component, application, or 256 network node) that is capable of computing a network path or route 257 based on a network graph and applying computational constraints. 259 PCE(i) is a PCE with the scope of domain(i). 261 2. Stitching Label 263 This section introduce the concept of Stitching Label that allows 264 stitching and nesting of Local LSP tunnels in order to form inter- 265 domain LSP tunnel that cross several different domains. 267 2.1. Definition 269 The operation of stitch or nest a local LSP tunnel(i) to a local LSP 270 tunnel(i+1) in order to form and inter-domain LSP tunnel simply 271 consist in defining the label that the exit BN(i) will use to send 272 its traffic to the entry BN(i+1). Indeed, the entry BN(i+1) needs to 273 identify the incoming traffic i.e. IP packets, in order to know if 274 this traffic must follow the local LSP tunnel(i+1) or not. 275 Forwarding Equivalent Class (FEC) could be used for that purpose. 276 But, when stitching or nesting tunnels, the FEC is reduce to the 277 incoming label that the entry BN(i+1) as chosen for the local LSP 278 tunnel(i+1). 280 In this memo, we introduce the named of 'Stitching Label (SL)' to 281 designate this label. Such label is usually exchange between exit 282 BN(i) and entry BN(i+1) with the RSVP-TE signaling. But, as we want 283 to avoid to use RSVP-TE signaling due to operational constraints, 284 this Stitching Label will be convey by PCEP protocol. In fact, the 285 Explicit Route Object (ERO) and the Record Route Object (RRO) are 286 defined in order to transport this Stitching Label in the RSVP-TE 287 signaling. As PCEP protocol used RSVP-TE Objects, and in particular 288 the ERO and ERO, it is able to convey the Stitching Label without any 289 modification of the PCEP protocol nor the PCE or RSVP-TE Objects. 291 As per RFC4003 [RFC4003], the Stitching Label will be convey as a 292 companion of an IP address. In our case, this is the IP address of 293 the input interface ITF_INPUT(i+1) of BN(i+1) which is connected to 294 the exit BN(i) and which receives the traffic from the domain(i). 296 2.2. Inter-domain LSP-TYPE 298 However, even if PCEP could convey the Stitching Label, a PCC is not 299 aware that a PCE requests or provides such label. For that purpose, 300 this memo propose to use the LSP-TYPE as defined in draft lsp setup 301 type [I-D.ietf-pce-lsp-setup-type] with new values (See IANA section 302 of this memo) defined as follow: 304 o TBD1: Inter-Domain Traffic engineering end-to-end path is setup 305 using Backward Recursive method. This new LSP-TYPE value MUST be 306 set in a PCInitiate messages sends by a PCE(i) to its neighbor 307 PCE(i+1) to initiate a new inter-domain LSP tunnel. In turn, 308 neighbor PCE(i+1) MUST return a Stitching Label SL with the IP 309 address of the associated interface in the RRO of the PCRpt 310 message to PCE (i). 312 o TBD2: Inter-Domain Traffic engineering local path is setup using 313 RSVP-TE. This new LSP-TYPE value MUST be set in the PCInitiate 314 message sends by a PCE(i) requesting to a PCC of domain(i) to 315 initiate a new local LSP tunnel(i) which is part of an inter- 316 domain LSP tunnel. This LSP-TYPE value MUST be used by the PCE(i) 317 only after receiving a PCInitiate message with an LSP-TYPE equal 318 to TBD1 from a neighbor PCE(i-1). In turn, the PCC of domain(i) 319 MUST return a Stitching Label SL with the IP address of associated 320 interface in the RRO of the PCRpt message. 322 o TBD3: Inter-Domain Traffic engineering local path is setup using 323 Segment Routing. This new LSP-TYPE value MUST be set in the 324 PCInitiate message sends by a PCE(i) requesting to a PCC of 325 domain(i) to initiate a new Segment Routing path which is part of 326 and inter-domain Segment Routing path. This LSP-TYPE value MUST 327 be used by the PCE(i) only after receiving a PCInitiate message 328 with an LSP-TYPE equal to TBD1 from a neighbor PCE(i-1). In turn, 329 the PCC MUST return a Stitching Label SL with the IP address of 330 the associated interface in the RRO of the PCRpt message. 332 3. Inter-domain LSP tunnels setup procedure 334 This section describes how to setup inter-domain LSP tunnels than 335 cross several different domains. 337 3.1. Mode of operation 339 This section describes how PCInitiate and PCRpt messages are combined 340 between PCE in order to setup inter-domain LSP tunnels between a 341 source domain(1) to a destination domain(n). S and D are 342 respectively the source and destination of the inter-domain LSP 343 tunnel. Domain(1) and domain(n) are different and connected through 344 0 or more intermediate domains denoted domain(i) with i = (2, n-1). 345 Domains are directly connected when n = 2. 347 First, the PCE(S) run standard BRPC algorithm as per RFC5441 348 [RFC5441] with its neighbor PCEs in order to compute the inter-domain 349 LSP tunnel from S to D, where S and D are respectively a node in the 350 domain(1) and domain(n). Path Key confidentiality as per RFC5520 351 [RFC5520] MAY be used to obfuscate the detailed ERO of the different 352 domains(i). The resulting ERO is of the form (S, PKS(1), exit BN(1), 353 ..., entry BN(i), PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D). 354 As subsequent domains are not aware about the final computed ERO in 355 case of multiple VSPT, the final computed ERO MUST be send in the 356 PCInitiate message to indicate to the subsequent PCEs which solution 357 has been finally chosen. 359 The complete procedure follow the different steps described below: 361 Steps 1: Initialization 363 Once ERO(S, D) computed, PCE(1) sends a PCInitiate message to PCE(2) 364 containing and ERO equal to {S, PKS(1), exit BN(1), ..., entry BN(i), 365 PKS(i), exit BN(i), ..., entry BN(n), PKS(n), D}, LSP-TYPE = TBD1 and 366 End-Points Object = (S, D). The ERO corresponds to the one PCE(1) as 367 received from PCE(2) during the BRPC process. In case of multiple 368 EROs, i.e. VSPT > 1, PCE(1) has chosen one of them and used the 369 selected one for the PCInitiate message. PKS(i) could be replaced by 370 the full ERO description if Path Key is not used by PCE(i). 372 When PCE(i) receives a PCInitiate message from domain(i-1) with LSP- 373 TYPE = TBD1 and ERO = {entry BN(i), PKS(i), exit BN(i), ..., entry 374 BN(n), PKS(n), D)}, it forwards the PCInitiate message to PCE(i+1) 375 once remove its {entry BN(i), PKS(i), exit BN(i)} part from the ERO. 376 All intermediate PCE(i) propagate the PCInitiate message to PCE(i+1) 377 up to the domain(n). 379 Steps 2: Actions taken at the destination domain(n) 380 When PCInitiate message propagation reach the destination domain(n), 381 PCE(n) retrieves the ERO from the PKS(n) if necessary and sends to 382 entry BN(n) a PCInitiate message with the ERO(n) = {BN(n), ..., D}, 383 LSP-TYPE= TBD2 and End-Points Object = (BN(n), D) in order to inform 384 the PCC BN(n) that this local LSP tunnel(n) is part of an inter- 385 domain LSP tunnel. When the PCC entry BN(n) received the PCInitiate 386 message from its PCE(n), it setup the LSP tunnels from entry BN(n) to 387 D by means of RSVP-TE signaling with the given ERO(n). Once the 388 tunnel setup, it chooses a free label for the Stitching Label SL(n) 389 and add a new entry in its MPLS LFIB with this SL(n) label. Then, it 390 sends a PCRpt message to its PCE(n) with an RRO equal to 391 {[ITF_INPUT(n), SL(n)], RRO(n)}. Once PCE(n) receives the PCRpt from 392 the PCC BN(n) with the RRO and LSP-TYPE = TBD2, it sends to the 393 PCE(n-1) a PCRpt containing the RRO equal to {[ITF_INPUT(n), SL(n)]}. 394 PCE(n) MAY adds BN(n), D in the RRO as loose path. 396 Steps i: Actions performed by all intermediate domains(i), for i = 2 397 to n-1 399 1. When the PCE(i) receives a PCRpt message from domain(i+1) with 400 LSP-TYPE = TBD1 and RRO = {[ITF_INPUT(i+1), SL(i+1)]}, it 401 retrieves the ERO from the PKS(i) if necessary and sends to the 402 PCC entry BN(i) a PCInitiate message with ERO = {ERO(i), 403 [ITF_INPUT(i+1), SL(i+1)]}, LSP-TYPE = TBD2 and End-Points Object 404 = {entry BN(i), exit BN(i)} in order to inform the PCC entry 405 BN(i) that this local LSP tunnel(i) is part of an inter-domain 406 LSP tunnel. 408 2. When the PCC entry BN(i) received the PCInitiate message from its 409 PCE(i), it setup the LSP tunnels from entry BN(i) to exit BN(i) 410 by means of RSVP-TE signaling with the given ERO(i). 412 3. When the exit Bn(i) receives an RSVP-TE Path message with an ERO 413 = {x-1, [ITF_INPUT(i+1), SL(i+1)]} and End-Points Object = {entry 414 BN(i), exit BN(i)}, it MUST install in its MPLS LFIB the SWAP 415 instruction to label SL(i+1) with forward to ITF_INPUT(i+1) 416 instead of the standard POP instruction. 418 4. Once the tunnel setup, it chooses a free label for the Stitching 419 Label SL(i) and add a new entry in its MPLS LFIB with this SL(i) 420 label. Then, it sends a PCRpt message to its PCE(i) with an RRO 421 equal to {[ITF_INPUT(i), SL(i)], RRO(i)}. 423 5. Once PCE(i) receives the PCRpt from the PCC entry BN(i) with the 424 RRO and LSP-TYPE = TBD2, it sends to the PCE(i-1) a PCRpt 425 containing the RRO equal to {[ITF_INPUT(i), SL(i)]}. PCE(i) MAY 426 adds entry BN(i), exit BN(i) in the RRO as loose path. 428 Steps n: Actions performed at the source domain(1) 430 Once PCE(1) received the PCRpt message from PCE(2) with the RRO 431 containing the label SL(2), it sends a PCInitiate message to PCC node 432 S with ERO equal to {ERO(1), [ITF_INPUT(2), SL(2)]}, LSP_TYPE = 0 and 433 End-Points Object = {S, BN(1)}. This time, the LSP_TYPE is equal to 0 434 as the PCC S does not need to return a Stitching Label SL i.e. it is 435 the head-end of the inter-domain LSP tunnel. Standard PCRpt message 436 is sent back to PCE(1) by the PCC node S. 438 To use Segment Routing instead of RSVP-TE to setup the LSP tunnels as 439 defined in draft pce segment routing [I-D.ietf-pce-segment-routing], 440 PCEs MUST send PCInitiate message with LSP-TYPE = TBD3 instead of 441 TBD2 to advertise their respective PCC that the LSP tunnels is 442 enforce by means of Segment Routing. SL label will be inserted in 443 the label stack in order to become the top label in the stack when 444 the packet reach entry BN(i+). Then, entry BN(i+1) will push a new 445 label stack to reach the exit BN(i+1) and follow. 447 3.2. Example 449 In the figure below, two different domains S and D are interconnected 450 through BN respectively BN-S and BN-D. PE-S and PE-D are edge 451 routers. All routers in the figure are connected to their respective 452 PCE through PCEP protocol. In this example, PCE(S) would setup an 453 intre-domain LSP tunnel between PE-S and PE-D acting as source and 454 destination of the tunnel. Intermediate routers between (PE-S, BN- 455 S), (BN-D and PE-D) as well as RSVP-TE messages are not represented 456 to simplify the figure. But they are all presents. The following 457 notation is used in the figure: 459 o PKS(D) = Path Key correponding to the path from BN(D) to PE-D 461 o ERO(D) = Explicit Route Object corresponding to the path from 462 BN(D) to PE-D retrieves from PKS(D) 464 o RRO(D) = Record Route Object of Local LSP tunnel(D) from BN(D) to 465 PE-D 467 o SL(D) = Stitching Label for Local LSP tunnel from BN(D) to PE-D 469 o ERO(S) = Explicit Route Object corresponding to the path from PE-S 470 to BN(S) 472 o RRO(S) = Record Route Object of Local LSP tunnel(S) from PE-S to 473 BN(S) 475 1. 477 PE-S PCE-S BN-D PCE-D 478 | | | | 479 | [ -------- Standard BRPC exchange ------------] 480 | | | | 481 | | PCInitiate(ERO={BN(D), PKS(D)}, LSP-TYPE = TBD1) 482 | | --------------------------------------> | 483 | | | | 484 | | PCInitiate(ERO = ERO(D), LSP-TYPE = TBD2) 485 | | | <------- | 486 | | | | 487 | | PCRpt(RRO = {SL(D), RRO(D)}, LSP-TYPE = TBD2) 488 | | | ------> | 489 | | | | 490 | | PCRpt(RRO = {SL(D), PKS(D)}, LSP-TYPE = TBD1) 491 | | <-------------------------------------- | 492 | | | | 493 | PCInitiate(ERO={ERO(S), SL(D), BN(D)}, LSP-TYPE = 0) 494 | <------- | | | 495 | | | | 496 | PCRpt(RRO={RRO(S)}, LSP-TYPE = 0) | | 497 | -------> | | | 498 | | | | 500 +----------------------+ +----------------------+ 501 | | | | 502 | +------+ | PCEP | +------+ | 503 | +---->|PCE(S)|<-------------------------------->|PCE(D)| | 504 | | +------+ | | +------+ | 505 | | ^ | | ^ ^ | 506 | | | | | | | | 507 | |PCEP | | | | | | 508 | | |PCEP | | PCEP | | PCEP | 509 | v | | | | | | 510 (PE-S) +------> (BN-S) <---------> (BN-D)<----+ +----> (PE-D) 511 | | Inter-Domain | | 512 | Domain (S) | Link | Domain (D) | 513 +----------------------+ +----------------------+ 515 [--- LSP Tunnel (S) ---][---- SL label ----][--- LSP Tunnel (D) ---] 517 Example of end-to-end LSP tunnel setup between two domains 519 3.3. Inter-domain LSP setup procedure completion failure 521 In case of error during LSP setup, PCRpt and or PCError messages MUST 522 be used to signal the problem to the neighbor PCE domain backward. 523 In particular, if new LSP-TYPE values defined in this memo are not 524 supported by the neighbor PCE or the PCC, the PCE, receptively the 525 PCC, MUST return a PCErr message with Error-Type = 21 (Traffic 526 engineering path setup error) and Error-Value = 1 (Unsupported path 527 setup type) to its neighbor PCE. 529 If a PCC or a PCE don't return an RRO or an RRO without the Stitching 530 Label SL with the IP address of the associated interface following a 531 PCInitiate message with LSP-TYPE set to the new values defined in 532 this memo, the PCE MUST return a PCErr message with Error-Type = 21 533 (Traffic engineering path setup error) and Error-Value = TBD4 (No 534 Mandatory Stitching Label is present in the RRO). 536 In case of completion failure, the PCE(i) MUST propagate the PCErr 537 message up to the PCE(1). In turn, PCE(1) MUST send a PCInitate 538 message (R flag set in the SRP Object as per draft pce initiated lsp 539 [I-D.ietf-pce-pce-initiated-lsp] to delete this inter-domain LSP 540 tunnel to its neighbor PCEs. PCE(i) MUST propagate the PCInitiate 541 message and remove their Local LSP tunnel by means of PCInitiate 542 message to their PCC entry BN(i) and send back PCRpt message to 543 PCE(i-1). 545 3.4. Inter-domain LSP management 547 Each domain manages their respective local LSP tunnel part of an 548 inter-domain LSP tunnel independently of each other. In particular, 549 Stitching Label(i) is managed by domain(i) and is of interest of 550 domain(i-1) only. Thus, Stitching Label SL(i) is not supposed to be 551 propagated to other domains. 553 If a PCE(i) needs to modify its local LSP tunnel(i) with PCUpd 554 message, it MUST sends a new PCRpt message to its neighbor PCE(i-1) 555 to advertise it of the modification, in particular if this concern a 556 modification of Stitching Label SL(i). 558 PCE(1) could modify the inter-domain LSP tunnel. For that purpose, 559 it MUST sends a PCUpd message to its neighbor PCEs. Each PCE(i) MUST 560 process PCUpd message the same way they process PCInitiate message: 561 first, propagate the PCUpd message up to the destination domain(n), 562 then process the modification once PCRpt received from PCE(i+1) and 563 send PCRpt to PCE(i-1) once modification done. 565 Modification of Local LSP tunnel, entry BN(i) and exit BN(i) is left 566 for further study. 568 In case of a failure appear in domain(i), PCE(i) MUST sends a PCRpt 569 message to its neighbor PCE(i-1) to advertise it that its local part 570 of the inter-domain LSP tunnel is down. Once PCE(1) receives this 571 PCRpt message indicating that the tunnel is down, it is up to the 572 PCE(1) to take appropriate correction e.g. start a new BRPC to 573 compute a new ERO. 575 4. Applicability 577 The newly introduce Stitching Label SL serves to stitch or nest part 578 of LSP tunnels to form an inter-domain LSP tunnel. Each domain is 579 free to decide if the tunnel is stitched or nested. For example, a 580 domain(i) may decided to nest the incoming Local LSP tunnel into a 581 higher hierarchy of tunnel for Traffic Engineering purpose. A PCE(i) 582 may also decided to group Local LSP tunnels part of inter-domain LSP 583 tunnels into a higher hierarchical tunnel to carry all these Local 584 LSP tunnels from one entry BN(i) to one exit BN(i). 586 The Stitching Label SL could serves to stitch Segment Path and RSVP- 587 TE tunnel. Indeed, each domain is free to enforce its part of the 588 inter-domain LSP tunnel with the underlying mechanism it chosen. 589 Stitching Label SL will be part of the label stack in order to become 590 the top label in the stack when reaching the entry BN(i+1). This 591 Stitching Label could be swap as usual if the next domain that uses 592 RSVP-TE tunnel. When the previous domain uses a RSVP-TE tunnel, the 593 Stitching Label will serve as key for the entry BN(i+1) to determine 594 which label stack it must push on top of the packet for a Segment 595 Routing path. 597 In inter-layer scenario is left for further study. 599 5. IANA Considerations 601 5.1. LSP-TYPE values 603 Draft pce lsp setup type [I-D.ietf-pce-lsp-setup-type] defines the 604 PATH-SETUP-TYPE TLV and requests that IANA creates a registry to 605 manage the value of the PATH_SETUP_TYPE TLV's PST field. IANA is 606 requested to allocate a new code point in the PCEP PATH_SETUP_TYPE 607 TLV PST field registry, as follows: 609 +-------+-----------------------------------------------+-----------+ 610 | Value | Description | Reference | 611 +-------+-----------------------------------------------+-----------+ 612 | TBD1 | Inter-Domain Traffic engineering end-to-end | This | 613 | | path is setup using Backward Recursive method | Document | 614 | TBD2 | Inter-Domain Traffic engineering local path | This | 615 | | is setup using RSVP-TE | Document | 616 | TBD3 | Inter-Domain Traffic engineering local path | This | 617 | | is setup using Segment Routing | Document | 618 +-------+-----------------------------------------------+-----------+ 620 5.2. PCEP-Error Object 622 IANA is requested to allocate code-points in the PCEP-ERROR Object 623 Error Values registry for a new error-value or Error-Type 21 Invalid 624 traffic engineering path setup: 626 +-------------+------------------------------------------+ 627 | Error-Value | Description | 628 +-------------+------------------------------------------+ 629 | TBD4 | Missing Mandatory Stitching Label in RRO | 630 +-------------+------------------------------------------+ 632 6. Security Considerations 634 No modification of PCE protocol (PCEP) has been requested by this 635 draft which not introduce any issue regarding security. Concerning 636 the PCEP session between PCEs, authors recommend to use the secure 637 version of PCEP as defined in draft secure transport for PCEP 638 [I-D.ietf-pce-pceps] or use any other secure tunnel mechanism e.g. 639 IPsec tunnel to transport PCEP session between PCE. 641 7. Acknowledgements 643 The authors want to thanks PCE's WG members. 645 8. References 647 8.1. Normative References 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 655 Element (PCE)-Based Architecture", RFC 4655, 656 DOI 10.17487/RFC4655, August 2006, 657 . 659 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 660 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 661 DOI 10.17487/RFC5440, March 2009, 662 . 664 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 665 "A Backward-Recursive PCE-Based Computation (BRPC) 666 Procedure to Compute Shortest Constrained Inter-Domain 667 Traffic Engineering Label Switched Paths", RFC 5441, 668 DOI 10.17487/RFC5441, April 2009, 669 . 671 8.2. Informative References 673 [I-D.dong-pce-discovery-proto-bgp] 674 Dong, J., Chen, M., Dhody, D., Tantsura, J., Kumaki, K., 675 and T. Murai, "BGP Extensions for Path Computation Element 676 (PCE) Discovery", draft-dong-pce-discovery-proto-bgp-06 677 (work in progress), October 2016. 679 [I-D.ietf-pce-lsp-setup-type] 680 Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga, 681 R., Tantsura, J., and J. Hardwick, "Conveying path setup 682 type in PCEP messages", draft-ietf-pce-lsp-setup-type-03 683 (work in progress), June 2015. 685 [I-D.ietf-pce-pce-initiated-lsp] 686 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 687 Extensions for PCE-initiated LSP Setup in a Stateful PCE 688 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 689 progress), March 2017. 691 [I-D.ietf-pce-pceps] 692 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 693 Transport for PCEP", draft-ietf-pce-pceps-11 (work in 694 progress), January 2017. 696 [I-D.ietf-pce-segment-routing] 697 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 698 Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and 699 J. Hardwick, "PCEP Extensions for Segment Routing", draft- 700 ietf-pce-segment-routing-08 (work in progress), October 701 2016. 703 [I-D.ietf-pce-stateful-pce] 704 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 705 Extensions for Stateful PCE", draft-ietf-pce-stateful- 706 pce-18 (work in progress), December 2016. 708 [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress 709 Control", RFC 4003, DOI 10.17487/RFC4003, February 2005, 710 . 712 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 713 "Preserving Topology Confidentiality in Inter-Domain Path 714 Computation Using a Path-Key-Based Mechanism", RFC 5520, 715 DOI 10.17487/RFC5520, April 2009, 716 . 718 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 719 Path Computation Element Architecture to the Determination 720 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 721 DOI 10.17487/RFC6805, November 2012, 722 . 724 Authors' Addresses 726 Olivier Dugeon 727 Orange 728 2, Avenue Pierre Marzin 729 Lannion 22307 730 France 732 Email: olivier.dugeon@orange.com 734 Julien Meuric 735 Orange 736 2, Avenue Pierre Marzin 737 Lannion 22307 738 France 740 Email: julien.meuric@orange.com