idnits 2.17.1 draft-xiong-pce-stateful-pce-sr-inter-domain-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2019) is 1641 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-hu-pce-stitching-lsp-association-01 == Outdated reference: A later version (-09) exists of draft-ietf-pce-sr-path-segment-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pce-stateful-hpce (ref. 'I-D.ietf-pce-stateful-hpce') == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-01 == Outdated reference: A later version (-07) exists of draft-li-pce-sr-bidir-path-06 == Outdated reference: A later version (-02) exists of draft-xiong-spring-path-segment-sr-inter-domain-00 ** Downref: Normative reference to an Informational draft: draft-xiong-spring-path-segment-sr-inter-domain (ref. 'I-D.xiong-spring-path-segment-sr-inter-domain') ** Downref: Normative reference to an Informational RFC: RFC 4105 ** Downref: Normative reference to an Informational RFC: RFC 4216 ** Downref: Normative reference to an Informational RFC: RFC 4655 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE WG Quan Xiong 3 Internet-Draft Greg Mirsky 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 24, 2020 Fangwei Hu 6 Individual 7 Weiqiang Cheng 8 China Mobile 9 October 22, 2019 11 Stateful PCE for SR-MPLS Inter-domain 12 draft-xiong-pce-stateful-pce-sr-inter-domain-02 14 Abstract 16 This document proposes a solution to perform the Segment Routing with 17 MPLS data plane (SR-MPLS) inter-domain path computation and 18 initiation with stateful PCEs and the use of Path Segments. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. The SR-MPLS Inter-domain with Path Segments . . . . . . . . . 3 58 3. Inter-domain Path Segment Allocation . . . . . . . . . . . . 6 59 3.1. PCC Allocated . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. PCE Allocated . . . . . . . . . . . . . . . . . . . . . . 7 61 4. PCEP Procedure . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. HPCE-initiated LSP . . . . . . . . . . . . . . . . . . . 7 63 4.2. PCC-initiated LSP . . . . . . . . . . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Informative References . . . . . . . . . . . . . . . . . 9 69 8.2. Normative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The Path Computation Element (PCE) architecture is defined in 75 [RFC4655] for MPLS Traffic Engineering (MPLS-TE) and Generalized MPLS 76 (GMPLS) networks. The Path Computation Element Communication 77 Protocol (PCEP) defined in [RFC5440] provides mechanisms for PCEs to 78 perform path computations in response to Path Computation Clients 79 (PCCs) requests. 81 [I-D.ietf-pce-segment-routing] proposes extensions to PCEP that allow 82 a stateful PCE to compute TE paths in segment routing (SR) networks. 83 As defined in [I-D.ietf-spring-mpls-path-segment], a path segment is 84 used to identify a SR path and support bidirectional SR paths 85 correlation. [I-D.ietf-pce-sr-path-segment] proposed the extension 86 for PCEP to operate with Path Segment. [I-D.li-pce-sr-bidir-path] 87 proposed the extension for PCEP to group two unidirectional SR Paths 88 into an Associated Bidirectional SR Path. 89 [I-D.xiong-spring-path-segment-sr-inter-domain] proposes the use of 90 Path Segment in inter-domain scenarios for SR-MPLS network. It is 91 required to perform the SR inter-domain path computation and 92 initiation with PCE deployment. 94 The path computation requirments for Label Switched Paths (LSPs) 95 across multiple domains are discussed in [RFC4105] and [RFC4216]. 96 Inter-domain path computation can be performed by a single stateful 97 PCE and multiple stateful PCEs. The PCE may has no ability to 98 collect the topologies all over the domains. So the single PCE model 99 is not applied in deployment. Three multiple PCEs models can be uesd 100 to perform PCE-based inter-domain path computation including Per- 101 Domain Path Computation [RFC5152], Backward-Recursive PCE-Based 102 Computation (BRPC) [RFC5441] and Hierarchical PCE (H-PCE) [RFC6805]. 103 Computing the optimum inter-domain path requires co-operation between 104 multiple PCEs. But the sequence of domains need to be known before 105 the path computation in BRPC mechanism. Stateful H-PCE architecture 106 is appropriate to compute an optimal end-to-end path across multiple 107 domains. 109 As defined in [I-D.xiong-spring-path-segment-sr-inter-domain], the 110 SR-MPLS inter-domain models includes stitching and nesting inter- 111 domain models between inter-Area or inter-AS domains. This document 112 proposes a solution to perform the SR-MPLS inter-domain path 113 computation and initiation with stateful PCEs and the use of Path 114 Segments. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 1.2. Terminology 124 The terminology is defined as [RFC5440], 125 [I-D.ietf-pce-segment-routing] , [I-D.ietf-spring-mpls-path-segment]. 127 2. The SR-MPLS Inter-domain with Path Segments 129 The SR-MPLS inter-domain scenario is described in 130 [I-D.xiong-spring-path-segment-sr-inter-domain]. The domains of the 131 networks may be IGP Areas or ASes and the inter- domain scenario may 132 be inter-Area or inter-AS. The multiple SR-MPLS domains may be 133 interconnect with a ABR within areas or inter-link between ASes. The 134 hierarchical PCE architecture is described in [RFC6805], a parent PCE 135 maintains a domain topology map that contains the child domains (seen 136 as vertices in the topology) and their interconnections (links in the 137 topology) but no information about the content of the child domains. 138 Each child domain has one PCE taking in charge of computing paths 139 across its own domain. These PCEs are known as child PCEs and have a 140 relationship with the parent PCE. 142 As the Figure 1 shown, H-PCE is parent PCE and PCE-1, PCE-2 and PCE-3 143 are child PCEs which is responsible for each own domain. SR-AS1, SR- 144 AS2 and SR-AS3 interconnect with logical links and SR-Area1, SR-Area2 145 and SR-Area3 interconnect within border nodes. The SR end-to-end 146 bidirectional LSP needs to be provided along the multi-domain paths. 147 The Path 1~5 are forward path segments and Path 1'~5' are the related 148 reverse path segments and these are all inter-domain path segments. 150 When an optimal inter-domain path is required, the ingress PCE sends 151 a request to the parent PCE or the stateful parent PCE itself to 152 initiate the path computation. The parent PCE selects a set of 153 candidate domain paths based on the domain topology and the state of 154 the inter-domain links. It then sends computation requests to the 155 child PCEs responsible for each of the domains on the candidate 156 domain paths. The stateful child PCE in each domain performs active 157 stateful procedure as defined [RFC8231]. 159 +-------+ 160 +------------------+ H-PCE +-------------------+ 161 | +---+---+ | 162 | | | 163 v v v 164 +--+--+ +--+--+ +--+--+ 165 |PCE-1| |PCE-2| |PCE-3| 166 +--+--+ +--+--+ +--+--+ 167 | | | 168 v v v 169 SR Inter-Area: 170 .................. ................. .................... 171 . . . . . . 172 +-----+ +-----+ +-----+ +-----+ 173 | A | | X | | Y | | Z | 174 +-----+ +-----+ +-----+ +-----+ 175 . SR-Area1 . . SR-Area2 . . SR-Area3 . 176 .................. ................. .................... 178 Forward Path Segments: 179 |------Path1------->|-----Path2------->|--------Path3------>| 180 Reverse Path Segments: 181 |<-----Path1'-------|<----Path2'-------|<--------Path3'-----| 183 SR Inter-AS: 184 .................... .................... ..................... 185 . . . . . . 186 . +---+ +---+ . . +---+ +---+ . . +---+ +----+ . 187 . | A |------| B |-------| C |-----| X |---------| Y |-----| Z | . 188 . +---+ +---+ . . +---+ +---+ . . +---+ +----+ . 189 . SR-AS1 . . SR-AS2 . . SR-AS3 . 190 .................... .................... ..................... 192 Forward Path Segments: 193 |----Path1---->|-Path2-->|----Path3--->|-Path4-->|-----Path5------>| 194 Reverse Path Segments: 195 |<---Path1'----|<-Path2'-|<---Path3'---|<-Path4'-|<----Path5'------| 197 Figure 1 The SR Inter-Domain with H-PCE 199 The LSPs of multiple domains can be stitched together by adding them 200 to a stitching LSP association group as defined in 201 [I-D.hu-pce-stitching-lsp-association]. As the Figure 2 shown, the 202 stateful H-PCE sends the PCInit message defined in [RFC8281] to 203 initiate the inter-domain path computation adding the forward LSP 1~3 204 to Assoc#1 and reverse LSP 1'~3' to Assoc#2. The child PCEs may 205 initiate the intra-domain LSPs when receiving the message from parent 206 PCE. The LSP 1~3 could be stitched to a forward end-to-end LSP and 207 the LSP 1'~3' could be stitched to a reverse end-to-end LSP. 208 Furthermore, the two unidirectional end-to-end LSPs MAY be bound to a 209 bidirectional end-to-end LSP as decribed in 210 [I-D.li-pce-sr-bidir-path]. 212 +-------+ 213 +------------------+ H-PCE +-----------------+ 214 PCInit | +---+---+ | 215 (LSP1,Assoc#1) | PCInit(LSP2,Assoc#1)| PCInit(LSP3,Assoc#1)| 216 PCInit | PCInit(LSP2',Assoc#2 |PCInit(LSP3',Assoc#2 | 217 (LSP1',Assoc#2)| | | 218 v v v 219 +-----+ +-----+ +-----+ 220 |PCE-1| |PCE-2| |PCE-3| 221 +-----+ +-----+ +-----+ 222 PCInit/ \PCInit PCInit/ \PCInit PCInit/ \PCInit 223 LSP1/ \LSP1' LSP2/ \LSP2' LSP3/ \LSP3' 224 Assoc#1/ \Assoc#2 Assoc#1/ \Assoc#2 Assoc#1/ \Assoc#2 225 v v v v v v 226 +-----+ LSP1 +-----------+ LSP2 +-----------+ LSP3 +-----+ 227 | A |-------->| X |--------->| Y |-------->| Z | 228 | |<--------| |<---------| |<--------| | 229 +-----+ LSP1' +-----------| LSP2' +-----------+ LSP3' +-----+ 230 |----------------------Forward End-to-end LSP--------------------->| 231 |<---------------------Reverse End-to-end LSP----------------------| 233 Figure 2 The SR inter-domain Stitching LSP Association 235 3. Inter-domain Path Segment Allocation 237 The inter-domain path segment may be allocated by PCC or PCE. The 238 PCE may be the single domain PCE which taking in charge of the 239 respective domain. The inter-domain path segments is a unique value 240 in the domain which PCC or PCE belongs to. The operation of path 241 segment request and reply may be the same with that in single domain 242 as defined in [I-D.ietf-pce-sr-path-segment]. 244 3.1. PCC Allocated 246 As defined in [I-D.xiong-spring-path-segment-sr-inter-domain], an 247 inter-domain path segment can be allocated by egress PCC and may be 248 maintained on the PCC itself. The inter-domain path segment connects 249 two domains and the ingress and egress PCC are belong to different 250 domains. The ingress and egress PCC need to exchange messages which 251 carrying path segment information between the two PCEs. 253 The Ingress PCC may request to allocate a path segment from egress 254 PCC. Once egress PCC allocated the inter-domain path segment, it 255 need to inform the PCE in respective domain with the PCRpt message. 256 The PCE need to communicate with the PCE which the ingress PCC 257 belongs to inform the value allocated. 259 3.2. PCE Allocated 261 The ingress PCC may request the inter-domain path segment to be 262 allocated by the PCE in PCC-Initiated LSP. The PCE may allocate the 263 inter-domain path segment on its own domain in PCEs-Initiated LSP. 264 The allocated path segment needs to be informed to the ingress and 265 egress PCC. 267 The inter-domain path segments may be allocated separately by the 268 PCEs which control the ingress and egress PCC along with the LSP 269 initiation. 271 4. PCEP Procedure 273 [RFC8281] describes setup, maintenance and teardown of PCE-initiated 274 LSPs under the stateful PCE model, without the need for local 275 configuration on the PCC. Similar to LSP updation, the inter-domain 276 LSP can be initiated by the ingress PCE using the PCInitiate message 277 to the ingress LSR. Per-domain LSP may also be initiated by 278 respective domain's PCE and stitched together. 280 4.1. HPCE-initiated LSP 282 In H-PCE [RFC6805] architecture, the parent PCE is used to compute a 283 multi-domain path based on the domain connectivity information. The 284 stateful H-PCE in active model can be used to initiate the inter- 285 domain bidirectional path for SR networks. PCE sends PCInitiate 286 message to its domain SR nodes with ERO={SID LIST} and carrying 287 stitching association group TLV and path segments. If the SR nodes 288 is the border nodes of the SR domain, it correlates the two path 289 segments and the related SID list if the related association ID is 290 the same value. 292 The PECP procedure for the HPCE-initiated LSP is following: 294 The stateful H-PCE initiates the end-to-end path computation across 295 multiple domains and selects a set of candidate domain paths based on 296 the topology. 298 The stateful H-PCE sends PCInitiate message to every PCEs which the 299 end-to-end path traversed, carrying inter-domain path segments 300 allocated by H-PCE, stitching LSP association group and the SID list 301 in the ERO object. 303 The stateful child PCE in each domain perform active stateful 304 procedure as defined in [I-D.ietf-pce-sr-path-segment]. 306 4.2. PCC-initiated LSP 308 In case of passive path computation request to the ingress PCE from 309 the ingress LSR, the H-PCE path computation procedure is applied to 310 compute sequence of domains or end-to-end path by using PCReq and 311 PCRep messages among stateful PCEs in passive mode. 313 In case of delegation to the ingress PCE (active stateful PCE), the 314 ingress child PCE may further delegate to parent PCE as per 315 [I-D.ietf-pce-stateful-hpce]. The parent PCE could update the path 316 of the inter-domain LSP. 318 The ingress nodes of the source AS sends the PCReq message to its 319 PCE, then the PCE sends PCReq message to the H-PCE or stateful PCEs 320 in other domains. The PECP procedure for the PCC-initiated LSP in 321 H-PCE model is as follow. 323 The ingress PCC from the ingress domain sends a PCReq request to the 324 PCE which is responsible for the domain containing the destination 325 information. 327 The ingress PCE sends the path computation request direct to the 328 parent PCE. 330 The parent PCE computes the optimal end-to-end path and initiates the 331 inter-domain paths to the child PCEs which the path traversed. 333 Each PCE sends PCInitiate message to ingress or egress nodes of its 334 domain to initiate the LSPs. 336 5. Security Considerations 338 TBD. 340 6. IANA Considerations 342 TBD. 344 7. Acknowledgements 346 TBD. 348 8. References 350 8.1. Informative References 352 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 353 Path Computation Element Architecture to the Determination 354 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 355 DOI 10.17487/RFC6805, November 2012, 356 . 358 8.2. Normative References 360 [I-D.hu-pce-stitching-lsp-association] 361 Xiong, Q., Mirsky, G., hu, f., and W. Cheng, "Stitching 362 LSP Association", draft-hu-pce-stitching-lsp- 363 association-01 (work in progress), July 2019. 365 [I-D.ietf-pce-segment-routing] 366 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 367 and J. Hardwick, "PCEP Extensions for Segment Routing", 368 draft-ietf-pce-segment-routing-16 (work in progress), 369 March 2019. 371 [I-D.ietf-pce-sr-path-segment] 372 Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, 373 "Path Computation Element Communication Protocol (PCEP) 374 Extension for Path Segment in Segment Routing (SR)", 375 draft-ietf-pce-sr-path-segment-00 (work in progress), 376 October 2019. 378 [I-D.ietf-pce-stateful-hpce] 379 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, 380 "Hierarchical Stateful Path Computation Element (PCE)", 381 draft-ietf-pce-stateful-hpce-15 (work in progress), 382 October 2019. 384 [I-D.ietf-spring-mpls-path-segment] 385 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 386 "Path Segment in MPLS Based Segment Routing Network", 387 draft-ietf-spring-mpls-path-segment-01 (work in progress), 388 September 2019. 390 [I-D.li-pce-sr-bidir-path] 391 Li, C., Chen, M., Cheng, W., Li, Z., Dong, J., Gandhi, R., 392 and Q. Xiong, "PCEP Extensions for Associated 393 Bidirectional Segment Routing (SR) Paths", draft-li-pce- 394 sr-bidir-path-06 (work in progress), August 2019. 396 [I-D.xiong-spring-path-segment-sr-inter-domain] 397 Xiong, Q., Mirsky, G., and W. Cheng, "The Use of Path 398 Segment in SR Inter-domain Scenarios", draft-xiong-spring- 399 path-segment-sr-inter-domain-00 (work in progress), July 400 2019. 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 408 "Requirements for Inter-Area MPLS Traffic Engineering", 409 RFC 4105, DOI 10.17487/RFC4105, June 2005, 410 . 412 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 413 System (AS) Traffic Engineering (TE) Requirements", 414 RFC 4216, DOI 10.17487/RFC4216, November 2005, 415 . 417 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 418 Element (PCE)-Based Architecture", RFC 4655, 419 DOI 10.17487/RFC4655, August 2006, 420 . 422 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 423 Per-Domain Path Computation Method for Establishing Inter- 424 Domain Traffic Engineering (TE) Label Switched Paths 425 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 426 . 428 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 429 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 430 DOI 10.17487/RFC5440, March 2009, 431 . 433 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 434 "A Backward-Recursive PCE-Based Computation (BRPC) 435 Procedure to Compute Shortest Constrained Inter-Domain 436 Traffic Engineering Label Switched Paths", RFC 5441, 437 DOI 10.17487/RFC5441, April 2009, 438 . 440 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 441 Computation Element Communication Protocol (PCEP) 442 Extensions for Stateful PCE", RFC 8231, 443 DOI 10.17487/RFC8231, September 2017, 444 . 446 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 447 Computation Element Communication Protocol (PCEP) 448 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 449 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 450 . 452 Authors' Addresses 454 Quan Xiong 455 ZTE Corporation 456 No.6 Huashi Park Rd 457 Wuhan, Hubei 430223 458 China 460 Phone: +86 27 83531060 461 Email: xiong.quan@zte.com.cn 463 Greg Mirsky 464 ZTE Corporation 465 USA 467 Email: gregimirsky@gmail.com 469 Fangwei Hu 470 Individual 471 China 473 Email: hufwei@gmail.com 474 Weiqiang Cheng 475 China Mobile 476 Beijing 477 China 479 Email: chengweiqiang@chinamobile.com