idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-11.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 38 instances of too long lines in the document, the longest one being 56 characters in excess of 72. ** The abstract seems to contain references ([RFC8735], [I-D.ietf-teas-pce-native-ip]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2021) is 1167 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 (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-10 == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-16 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-pce-native-ip (ref. 'I-D.ietf-teas-pce-native-ip') ** Downref: Normative reference to an Informational RFC: RFC 8283 ** Downref: Normative reference to an Informational RFC: RFC 8735 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track B. Khasanov 5 Expires: August 11, 2021 Yandex LLC 6 S. Fang 7 R. Tan 8 Huawei Technologies,Co.,Ltd 9 C. Zhu 10 ZTE Corporation 11 February 7, 2021 13 PCEP Extension for Native IP Network 14 draft-ietf-pce-pcep-extension-native-ip-11 16 Abstract 18 This document defines the Path Computation Element Communication 19 Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) 20 based application in Native IP network. The scenario and framework 21 of CCDR in native IP is described in [RFC8735] and 22 [I-D.ietf-teas-pce-native-ip]. This draft describes the key 23 information that is transferred between Path Computation Element 24 (PCE) and Path Computation Clients (PCC) to accomplish the End to End 25 (E2E) traffic assurance in Native IP network under central control 26 mode. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 11, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Capability Advertisemnt . . . . . . . . . . . . . . . . . . . 4 66 4.1. Open message . . . . . . . . . . . . . . . . . . . . . . 4 67 5. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5.1. The PCInitiate message . . . . . . . . . . . . . . . . . 5 69 5.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 6 70 6. PCECC Native IP TE Procedures . . . . . . . . . . . . . . . . 7 71 6.1. BGP Session Establishment Procedures . . . . . . . . . . 7 72 6.2. Explicit Route Establish Procedures . . . . . . . . . . . 9 73 6.3. BGP Prefix Advertisement Procedures . . . . . . . . . . . 12 74 7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 13 75 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 14 77 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 78 7.4. Peer Prefix Association Object . . . . . . . . . . . . . 18 79 8. End to End Path Protection . . . . . . . . . . . . . . . . . 20 80 9. New Error-Types and Error-Values Defined . . . . . . . . . . 20 81 10. Deployment Considerations . . . . . . . . . . . . . . . . . . 21 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 12.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 22 85 12.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 22 86 12.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 23 87 12.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 23 88 13. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 90 15. Normative References . . . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 93 1. Introduction 95 Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- 96 TE) requires the corresponding network devices support Multiprotocol 97 Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label 98 Distribution Protocol (LDP) technologies to assure the End-to-End 99 (E2E) traffic performance. But in native IP network, there will be 100 no such signaling protocol to synchronize the action among different 101 network devices. It is necessary to use the central control mode 102 that described in [RFC8283] to correlate the forwarding behavior 103 among different network devices. Draft [I-D.ietf-teas-pce-native-ip] 104 describes the architecture and solution philosophy for the E2E 105 traffic assurance in Native IP network via Multi Border Gateway 106 Protocol (BGP) solution. This draft describes the corresponding Path 107 Computation Element Communication Protocol (PCEP) extensions to 108 transfer the key information about BGP peer info, peer prefix 109 association and the explicit peer route on on-path routers. 111 2. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. Terminology 121 This document uses the following terms defined in [RFC5440]: PCE, 122 PCEP 124 The following terms are defined in this document: 126 o CCDR: Central Control Dynamic Routing 128 o E2E: End to End 130 o BPI: BGP Peer Info 132 o EPR: Explicit Peer Route 134 o PPA: Peer Prefix Association 136 o QoS: Quality of Service 138 4. Capability Advertisemnt 140 4.1. Open message 142 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 143 advertise their support of Native IP extensions. 145 This document defines a new Path Setup Type (PST) [RFC8408] for 146 Native-IP, as follows: 148 o PST = TBD1: Path is a Native IP path as per 149 [I-D.ietf-teas-pce-native-ip]. 151 A PCEP speaker MUST indicate its support of the function described in 152 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 153 object with this new PST included in the PST list. 155 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 156 CAPABILITY sub-TLV to exchange information about their PCECC 157 capability. A new flag is defined in PCECC-CAPABILITY sub-TLV for 158 Native IP. 160 N (NATIVE-IP-TE-CAPABILITY - 1 bit - TBD2): If set to 1 by a PCEP 161 speaker, it indicates that the PCEP speaker is capable for TE in 162 Native IP network as specified in this document. The flag MUST be 163 set by both the PCC and PCE in order to support this extension. 165 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 166 the newly defined path setup type, but without the N bit set in 167 PCECC-CAPABILITY sub-TLV, it MUST: 169 o Send a PCErr message with Error-Type=10(Reception of an invalid 170 object) and Error-Value TBD3(PCECC NATIVE-IP-TE-CAPABILITY bit is 171 not set). 173 o Terminate the PCEP session 175 5. PCEP messages 177 PCECC Native IP TE solution utilizing the existing PCE LSP Initate 178 Request message(PCInitiate)[RFC8281], and PCE Report message(PCRpt) 179 [RFC8281] to accomplish the multi BGP sessions establishment, E2E TE 180 path deployment, and route prefixes advertisement among different BGP 181 sessions. A new PST for Native-IP is used to indicate the path setup 182 based on TE in Native IP networks. 184 The extended PCInitiate message described in 185 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 186 or cleanup central controller's instructions (CCIs). 187 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 188 called CCI for the encoding of central controller's instructions. 189 This document specify a new CCI object-type for Native IP. The PCEP 190 messages are extended in this document to handle the PCECC operations 191 for Native IP. Three new PCEP Objects (BGP Peer Info (BPI) Object, 192 Explicit Peer Route (EPR) Object and Peer Prefix Association (PPA) 193 Object) are defined in this document. Refer toSection 7 for detail 194 object definitions. 196 5.1. The PCInitiate message 198 The PCInitiate Message defined in [RFC8281] and extended in 199 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 200 to support Native-IP CCI. 202 The format of the extended PCInitiate message is as follows: 204 ::= 205 206 Where: 207 is defined in [RFC5440] 209 ::= 210 [] 212 ::= 213 (| 214 | 215 ) 217 ::= 218 ( 219 )| 220 ((||) 221 ) 223 ::= 224 [] 226 Where: 227 is as per 228 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 229 and 230 are as per 231 [RFC8281]. 233 The LSP and SRP object is defined in [RFC8231]. 235 When PCInitiate message is used create Native IP instructions, the 236 SRP and CCI objects MUST be present. The error handling for missing 237 SRP or CCI object is as per 238 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one 239 of BPI, EPR, or PPA object MUST be present. The PLSP-ID within the 240 LSP object should be set by PCC uniquely according to the Symbolic 241 Path Name TLV that included in the CCI object. The Symbolic Path 242 Name is used by the PCE/PCC to identify uniquely the E2E native IP TE 243 path. 245 If none of them are present, the receiving PCC MUST send a PCErr 246 message with Error-type=6 (Mandatory Object missing) and Error- 247 value=TBD4 (Native IP object missing). If there are more than one of 248 BPI, EPR or PPA object are presented, the receiving PCC MUST send a 249 PCErr message with Error-type=19(Invalid Operation) and Error- 250 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 251 this message). 253 To cleanup the SRP object must set the R (remove) bit. 255 5.2. The PCRpt message 257 The PCRpt message is used to acknowledge the Native-IP instructions 258 received from the central controller (PCE). 260 The format of the PCRpt message is as follows: 262 ::= 263 264 Where: 266 ::= [] 268 ::= (| 269 ) 271 ::= [] 272 273 275 ::= [] 276 ( 277 )| 278 ((||) 279 ) 281 Where: 282 is as per [RFC8231] and the LSP and SRP object are 283 also defined in [RFC8231]. 285 The error handling for missing CCI object is as per 286 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one 287 of BPI, EPR, or PPA object MUST be present. 289 If none of them are present, the receiving PCE MUST send a PCErr 290 message with Error-type=6 (Mandatory Object missing) and Error- 291 value=TBD4 ( Native IP object missing). If there are more than one 292 of BPI, EPR or PPA object are presented, the receiving PCE MUST send 293 a PCErr message with Error-type=19(Invalid Operation) and Error- 294 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 295 this message). 297 6. PCECC Native IP TE Procedures 299 The detail procedures for the TE in native IP environment are 300 described in the following sections. 302 6.1. BGP Session Establishment Procedures 304 The procedures for establishing the BGP session between two peers is 305 shown below, using the PCInitiate and PCRpt message pair. 307 The PCInitiate message should be sent to PCC which acts as BGP 308 routers and route reflector. In the example in Figure 1, it should 309 be sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR. 311 When PCC receives the BPI and CCI object (with the R bit set to 0 in 312 SRP object) in PCInitiate message, the PCC should try to establish 313 the BGP session with the indicated Peer AS and Local/Peer IP address. 315 When PCC creates successfully the BGP session that is indicated by 316 the associated information, it should report the result via the PCRpt 317 messages, with BPI object included, and the corresponding SRP and CCI 318 object. 320 When PCC receives this message with the R bit set to 1 in SRP object 321 in PCInitiate message, the PCC should clear the BGP session that 322 indicated by the BPI object. 324 When PCC clears successfully the specified BGP session, it should 325 report the result via the PCRpt message, with the BPI object 326 included, and the corresponding SRP and CCI object. 328 +------------------+ 329 +-----------+ PCE +----------+ 330 | +--------^---------+ | 331 | | | 332 M2/M2-R & M3/M3-R 333 | | | 334 | +---v---+ | 335 +---------------+ R3(RR)+-----------------+ 336 | +-------+ | 337 M1/M1-R M4/M4-R 338 | | 339 +v-+ +--+ +--+ +-v+ 340 |R1+----------+R5+----------+R6+---------+R7| 341 ++-+ +--+ +--+ +-++ 342 | | 343 | +--+ +--+ | 344 +------------+R2+----------+R4+-----------+ 345 +--+ +--+ 346 Figure 1: BGP Session Establishment Procedures(R3 act as RR) 348 The message number, message peers, message type and message key 349 parameters in the above figures are shown in below table: 351 Table 1: Message Information 352 +-------------------------------------------------------------+ 353 | No.| Peers| Type | Message Key Parameters | 354 +-------------------------------------------------------------+ 355 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 356 |M1-R| |PCRpt |BPI Object(Local_IP=R1_A,Peer_IP=R3_A)| 357 +-------------------------------------------------------------+ 358 |M2 |PCE/R3|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 359 |M2-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R1_A)| 360 +-------------------------------------------------------------+ 361 |M3 |PCE/R3|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 362 |M3-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R7_A)| 363 +-------------------------------------------------------------+ 364 |M4 |PCE/R7|PCInitiate|CC-ID=X4(Symbolic Path Name=Class A) | 365 |M4-R| |PCRpt |BPI Object(Local_IP=R7_A,Peer_IP=R3_A)| 366 +-------------------------------------------------------------+ 368 If the PCC cannot establish the BGP session that required by this 369 object, it should report the error values via PCErr message with the 370 newly defined error type(Error-type=TBD6) and error value(Error- 371 value=TBD7, Peer AS not match; or Error-Value=TBD8, Peer IP can't be 372 reached), which is indicated in Section 9 374 If the Local_IP or Peer_IP within BPI object is used in other 375 existing BGP sessions, the PCC should report such error situation via 376 PCErr message with Err-type=TBD6 and error value(Error-value=TBD9, 377 Local IP is in use; Error-value=TBD10, Remote IP is in use). 379 6.2. Explicit Route Establish Procedures 381 The detail procedures for the explicit route establishment procedures 382 is shown below, using PCInitiate and PCRpt message pair. 384 The PCInitiate message should be sent to the on-path routers 385 respectively. In the example, for explicit route from R1 to R7, the 386 PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as 387 shown in Figure 2. For explicit route from R7 to R1, the PCInitiate 388 message should be sent to R7(M1), R4(M2) and R2(M3), as shown in 389 Figure 3.. 391 When PCC receives the EPR and the CCI object (with the R bit set to 0 392 in SRP object) in PCInitiate message, the PCC should install the 393 explicit route to the the peer. 395 When PCC install successfully the explicit route to the peer, it 396 should report the result via the PCRpt messages, with EPR object 397 included, and the corresponding SRP and CCI object. 399 When PCC receives the EPR and the CCI object with the R bit set to 1 400 in SRP object in PCInitiate message, the PCC should clear the 401 explicit route to the peer that indicated by the EPR object. 403 When PCC clear successfully the explicit route that indicated by this 404 object, it should report the result via the PCRpt message, with the 405 EPR object included, and the corresponding SRP and CCI object. 407 +------------------+ 408 +----------+ PCE + 409 | +----^-----------^-+ 410 | | | 411 | | | 412 | | +------+ | 413 +-----------------+R3(RR)+--|-------------+ 414 M1/M1-R | +------+ | | 415 | | | | 416 +v-+ +--+ | | +--+ +--+ 417 |R1+------+R5+---+-----------|---+R6+----+R7| 418 ++-+ +--+ | | +--+ +-++ 419 | M2/M2-R M3/M3-R | 420 | | | | 421 | +--v--+ +--v-+ | 422 +------------+- R2 +-----+ R4 +-----------+ 423 +--+--+ +--+-+ 424 Figure 2: Explicit Route Establish Procedures(From R1 to R7) 426 The message number, message peers, message type and message key 427 parameters in the above figures are shown in below table: 429 Table 2: Message Information 430 +------------------------------------------------------------------+ 431 | No.|Peers | Type | Message Key Parameters | 432 +------------------------------------------------------------------+ 433 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 434 |M1-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R2_A)| 435 +------------------------------------------------------------------+ 436 |M2 |PCE/R2|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 437 |M2-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R4_A)| 438 +------------------------------------------------------------------+ 439 |M3 |PCE/R4|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 440 |M3-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R7_A)| 441 +------------------------------------------------------------------+ 442 +------------------+ 443 + PCE +-----------+ 444 +----^-----------^-+ | 445 | | | 446 | | | 447 | +------+ | | 448 +-----------------+R3(RR)+--|-------------+ 449 | | +------+ | M1/M1-R 450 | | | | 451 +--+ +--+ | | +--+ +-v+ 452 |R1+------+R5+---+-----------|---+R6+----+R7| 453 ++-+ +--+ | | +--+ +-++ 454 | M3/M3-R M2/M2-R | 455 | | | | 456 | +--v--+ +--v-+ | 457 +------------+- R2 +-----+ R4 +-----------+ 458 +--+--+ +--+-+ 459 Figure 3: Explicit Route Establish Procedures(From R7 to R1) 461 The message number, message peers, message type and message key 462 parameters in the above figures are shown in below table: 464 Table 3: Message Information 465 +------------------------------------------------------------------+ 466 |No. |Peers | Type | Message Key Parameters | 467 +------------------------------------------------------------------+ 468 |M1 |PCE/R7|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 469 |M1-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R4_A)| 470 +------------------------------------------------------------------+ 471 |M2 |PCE/R4|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 472 |M2-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R2_A)| 473 +------------------------------------------------------------------+ 474 |M3 |PCE/R2|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 475 |M3-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R1_A)| 476 +------------------------------------------------------------------+ 478 In order to avoid the transient loop during the deploy of explicit 479 peer route, the EPR object should be sent to the PCCs in the reverse 480 order of the E2E path. To remove the explicit peer route, the EPR 481 object should be sent to the PCCs in the same order of E2E path. 483 Upon the error occurs, the PCC SHOULD send the corresponding error 484 via PCErr message, with an error information (Error-type=TBD6, Error- 485 value=TBD12, Explicit Peer Route Error) that defined in Section 9. 487 When the peer info that associated with the Symbolic Path Name is not 488 the same as the peer info that indicated in BPI object in PCC, an 489 error (Error-type=TBD6, Error-value=17, EPR/BPI Peer Info mismatch) 490 should be reported via the PCErr message. 492 6.3. BGP Prefix Advertisement Procedures 494 The detail procedures for BGP prefix advertisement is shown below, 495 using PCInitiate and PCRpt message pair. 497 The PCInitiate message should be sent to PCC that acts as BGP peer 498 router only. In the example, it should be sent to R1(M1) or R7(M2) 499 respectively. 501 When PCC receives the PPA and the CCI object (with the R bit set to 0 502 in SRP object) in PCInitiate message, the PCC should send the 503 prefixes indicated in this object to the appointed BGP peer. 505 When PCC sends successfully the prefixes to the appointed BGP peer, 506 it should report the result via the PCRpt messages, with PPA object 507 included, and the corresponding SRP and CCI object. 509 When PCC receives the PPA and the CCI object with the R bit set to 1 510 in SRP object in PCInitiate message, the PCC should withdraw the 511 prefixes advertisement to the peer that indicated by this object. 513 When PCC withdraws successfully the prefixes that indicated by this 514 object, it should report the result via the PCRpt message, with the 515 PPA object included, and the corresponding SRP and CCI object. 517 The IPv4 prefix MUST only be advertised via the IPv4 BGP session and 518 the IPv6 prefix MUST only be advertised via the IPv6 BGP session. If 519 mismatch occur, an error(Error-type=TBD6, Error-value=TBD18, BPI/PPR 520 address family mismatch) should be reported via PCErr message. 522 When the peer info that associated with the Symbolic Path Name is not 523 the same as the peer info that indicated in BPI object in PCC, an 524 error (Error-type=TBD6, Error-value=TBD19, PPA/BPI peer info 525 mismatch) should be reported via the PCErr message. 527 +------------------+ 528 +----------+ PCE +-----------+ 529 | +------------------+ | 530 | +--+ | 531 +------------------+R3+-------------------+ 532 M1&M1-R +--+ M2&M2-R 533 | | 534 +v-+ +--+ +--+ +-v+ 535 |R1+----------+R5+----------+R6+---------+R7| 536 ++-+ +--+ +--+ +-++ 537 | | 538 | | 539 | +--+ +--+ | 540 +------------+R2+----------+R4+-----------+ 541 Figure 4: BGP Prefix Advertisement Procedures 543 Table 4: Message Information 544 +-----------------------------------------------------------+ 545 |No. | Peers| Type | Message Key Parameters | 546 +-----------------------------------------------------------+ 547 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A)| 548 |M1-R| |PCRpt |PPA Object(Peer IP=R7_A,Prefix=1_A) | 549 +-----------------------------------------------------------+ 550 |M2 |PCE/R7|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A)| 551 |M2-R| |PCRpt |PPA Object(Peer IP=R1_A,Prefix=7_A) | 552 +-----------------------------------------------------------+ 554 7. New PCEP Objects 556 One new CCI Object and three new PCEP objects are defined in this 557 draft. All new PCEP objects are as per [RFC5440] 559 7.1. CCI Object 561 The Central Control Instructions (CCI) Object is used by the PCE to 562 specify the forwarding instructions is defined in 563 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 564 defines another object-type for Native-IP. 566 CCI Object-Type is TBD13 for Native-IP as below 567 0 1 2 3 568 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | CC-ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Reserved | Flags | 573 +---------------------------------------------------------------+ 574 | | 575 // Optional TLV // 576 | | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 5: CCI Object for Native IP 581 Figure 1 583 The field CC-ID is as described in 584 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields 585 are defined for CCI Object-Type TBD13 587 Reserved: is set to zero while sending, ignored on receipt. 589 Flags: is used to carry any additional information pertaining to the 590 CCI. Currently no flag bits are defined. 592 The Symbolic Path Name TLV [RFC8231] MUST be included in the CCI 593 Object-Type TBD13 to identify the E2E TE path in Native IP 594 environment and MUST be unique. 596 7.2. BGP Peer Info Object 598 The BGP Peer Info object is used to specify the information about the 599 peer that the PCC should establish the BGP relationship with. This 600 object should only be included and sent to the head and end router of 601 the E2E path in case there is no Route Reflection (RR) involved. If 602 the RR is used between the head and end routers, then such 603 information should be sent to head router, RR and end router 604 respectively. 606 By default, there MUST be no prefix be distributed via such BGP 607 session that established by this object. 609 By default, the Local/Peer IP address SHOULD be dedicated to the 610 usage of native IP TE solution, and SHOULD NOT be used by other BGP 611 sessions that established by manual or non PCE initiated 612 configuration. 614 BGP Peer Info Object-Class is TBD14 615 BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 617 The format of the BGP Peer Info object body for IPv4(Object-Type=1) 618 is as follows: 620 0 1 2 3 621 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Peer AS Number | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | ETTL | Reserved | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Local IP Address | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Peer IP Address | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Additional TLVs | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Figure 6: BGP Peer Info Object Body Format for IPv4 635 The format of the BGP Peer Info object body for IPv6(Object-Type=2) 636 is as follows: 638 0 1 2 3 639 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Peer AS Number | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | ETTL | Tunnel Type | Reserved | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | | 646 + + 647 | Local IP Address (16 bytes) | 648 + + 649 | | 650 + + 651 | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 + + 655 | Peer IP Address (16 bytes) | 656 + + 657 | | 658 + + 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Additional TLVs | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Figure 7: BGP Peer Info Object Body Format for IPv6 665 Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. 667 ETTL: 1 Byte, to indicate the multi hop count for EBGP session. It 668 should be 0 and ignored when Local AS and Peer AS is same. 670 Tunnel Type: 1 Byte, indicate the tunnel type that used to transfer 671 the traffic that identified by the prefixes that advertised by the 672 corresponding BGP peer. Value 0 indicate no tunnel is used. Other 673 value can refer to the IANA allocation value in "BGP Tunnel 674 Encapsulation Attribute Tunnel Types". 676 Reserved: is set to zero while sending, ignored on receipt.. 678 Local IP Address(4/16 Bytes): IP address of the local router, used to 679 peer with other end router. When Object-Type is 1, length is 4 680 bytes; when Object-Type is 2, length is 16 bytes. 682 Peer IP Address(4/16 Bytes): IP address of the peer router, used to 683 peer with the local router. When Object-Type is 1, length is 4 684 bytes; when Object-Type is 2, length is 16 bytes; 685 Additional TLVs: TLVs that associated with this object, can be used 686 to convey other necessary information for dynamic BGP session 687 establishment. Its definition is out of the current document. 689 When PCC receives BPI object, with Object-Type=1, it should try to 690 establish BGP session with the peer in AFI/SAFI=1/1; when PCC 691 receives BPI object with Object-Type=2, it should try to establish 692 the BGP session with the peer in AFI/SAFI=2/1. Other BGP 693 capabilities,for example, Graceful Restart(GR) that enhance the BGP 694 performance should also be negotiated and used by default. 696 7.3. Explicit Peer Route Object 698 The Explicit Peer Route object is defined to specify the explicit 699 peer route to the corresponding peer address on each device that is 700 on the E2E assurance path. This Object should be sent to all the 701 devices that locates on the E2E assurance path that calculated by 702 PCE. 704 The path established by this object should have higher priority than 705 other path calculated by dynamic IGP protocol, but should be lower 706 priority that the static route configured by manual or NETCONF 707 channel. 709 Explicit Peer Route Object-Class is TBD15. 711 Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6 713 The format of Explicit Peer Route object body for IPv4(Object-Type=1) 714 is as follows: 716 0 1 2 3 717 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Route Priority | Reserved | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | IPv4 Peer Address | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Next Hop Address to the IPv4 Peer Address | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Additional TLVs | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 8: Explicit Peer Route Object Body Format for IPv4 729 The format of Explicit Peer Route object body for IPv6(Object-Type=2) 730 is as follows: 732 0 1 2 3 733 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Route Priority | Reserved | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | | 738 + + 739 | IPv6 Peer Address | 740 + + 741 | | 742 + + 743 | | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | | 746 + + 747 | Next Hop Address to the IPv6 Peer Address | 748 + + 749 | | 750 + + 751 | | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Additional TLVs | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 9: Explicit Peer Route Object Body Format for IPv6 757 Route Priority: 2 Bytes, The priority of this explicit route. The 758 higher priority should be preferred by the device. This field is 759 used to indicate the backup path at each hop. 761 Reserved.: is set to zero while sending, ignored on receipt. 763 Peer Address: To indicate the peer address. 765 Next Hop Address to the Peer: To indicate the next hop address to the 766 corresponding peer. 768 Additional TLVs: TLVs that associated with this object, can be used 769 to convey other necessary information for explicit peer path 770 establishment. Its definition is out of the current document. 772 7.4. Peer Prefix Association Object 774 The Peer Prefix Association object is defined to specify the IP 775 prefixes that should be advertised to the corresponding peer. This 776 object should only be included and sent to the head/end router of the 777 end2end path. 779 The prefixes information included in this object MUST only be 780 advertised to the indicated peer, MUST NOT be advertised to other BGP 781 peers. 783 Peer Prefix Association Object-Class is TBD16 785 Peer Prefix Association Object-Type is 1 for IPv4 and 2 for IPv6 787 The format of the Peer Prefix Association object body is as follows: 789 0 1 2 3 790 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Peer IPv4 Address | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 // IPv4 Prefix subobjects // 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Additional TLVs | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Figure 10: Peer Prefix Association Object Body Format for IPv4 802 0 1 2 3 803 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Peer IPv6 Address | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | | 808 // IPv6 Prefix subobjects // 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Additional TLVs | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 11: Peer Prefix Association Object Body Format for IPv6 815 Peer IPv4 Address: 4 Bytes. Identifies the peer IPv4 address that 816 the associated prefixes will be sent to. 818 IPv4 Prefix subojects: List of IPv4 Prefix subobjects that defined in 819 [RFC3209], identify the prefixes that will be sent to the peer that 820 identified by Peer IPv4 Address List. 822 Peer IPv6 Address: 16 Bytes. Identifies the peer IPv6 address that 823 the associated prefixes will be sent to. 825 IPv6 Prefix subojects: List of IPv6 Prefix subobjects that defined in 826 [RFC3209], identify the prefixes that will be sent to the peer that 827 identified by Peer IPv6 Address List. 829 Additional TLVs: TLVs that associated with this object, can be used 830 to convey other necessary information for prefixes advertisement. 831 Its definition is out of the current document. 833 8. End to End Path Protection 835 [RFC8697] defines the path associations procedures between sets of 836 Label Switched Path (LSP). Such procedures can also be used for the 837 E2E path protection. To accomplish this, the PCE should attach the 838 ASSOCIATION object with the EPR object in the PCInitiate message, 839 with the association type set to 1 (Path Protection Association). 840 The Extended Association ID that included within the Extended 841 Association ID TLV, which is included in the ASSOCIATION object, 842 should be set to the Symbolic Path Name of different E2E path. This 843 PCinitiate should be sent to the head-end of the E2E path. 845 The head-end of the path can use the existing path detection 846 mechanism, to monitor the status of the active path. Once it detects 847 the failure, it can switch the backup protection path immediately. 849 9. New Error-Types and Error-Values Defined 851 A PCEP-ERROR object is used to report a PCEP error and is 852 characterized by an Error-Type that specifies that type of error and 853 an Error-value that provides additional information about the error. 854 An additional Error-Type and several Error-values are defined to 855 represent some the errors related to the newly defined objects, which 856 are related to Native IP TE procedures. 858 +============+===============+==============================+ 859 | Error-Type | Meaning | Error-value | 860 +============+===============+=====================================+ 861 | TBD6 | Native IP | | 862 | | TE failure | | 863 +------------+---------------+-------------------------------------+ 864 | | | 0: Unassigned | 865 +------------+---------------+-------------------------------------+ 866 | | |TBD7: Peer AS not match | 867 +------------+---------------+-------------------------------------+ 868 | | |TBD8:Peer IP can't be reached | 869 +------------+---------------+-------------------------------------+ 870 | | |TBD9:Local IP is in use | 871 +------------+---------------+-------------------------------------+ 872 | | |TBD10:Remote IP is in use | 873 +------------+---------------+-------------------------------------+ 874 | | |TBD11:Exist BGP session broken | 875 +------------+---------------+-------------------------------------+ 876 | | |TBD12:Explicit Peer Route Error | 877 +------------+---------------+-------------------------------------+ 878 | | |TBD17:EPR/BPI Peer Info mismatch | 879 +------------+---------------+-------------------------------------+ 880 | | |TBD18:BPI/PPA Address Family mismatch| 881 +------------+---------------+-------------------------------------+ 882 | | |TBD19:PPA/BPI Peer Info mismatch | 883 +------------+---------------+-------------------------------------+ 884 | | | | 885 +------------+---------------+-------------------------------------+ 886 | | | | 887 +------------+---------------+-------------------------------------+ 888 | | | | 889 +------------+---------------+-------------------------------------+ 890 | | | | 891 +------------+---------------+-------------------------------------+ 892 Figure 12: Newly defined Error-Type and Error-Value 894 10. Deployment Considerations 896 The information transferred in this draft is mainly used for the 897 light weight BGP session setup, explicit route deployment and the 898 prefix distribution. The planning, allocation and distribution of 899 the peer addresses within IGP should be accomplished in advanced and 900 they are out of the scope of this draft. 902 [RFC8232] describes the state synchronization procedure between 903 stateful PCE and PCC. The communication of PCE and PCC described in 904 this draft should also follow this procedures, treat the three newly 905 defined objects that associated with the same symbolic path name as 906 the attribute of the same path in the LSP-DB. 908 When PCE detects one or some of the PCCs are out of control, it 909 should recompute and redeploy the traffic engineering path for native 910 IP on the active PCCs. When PCC detects that it is out of control of 911 the PCE, it should clear the information that initiated by the PCE. 912 The PCE should assures the avoidance of possible transient loop in 913 such node failure when it deploy the explicit peer route on the PCCs. 915 If the established BGP session is broken after some time, the PCC 916 should also report such error via PCErr message with Err-type=TBD6 917 and error value(Error-value=TBD11, Existing BGP session is broken). 918 Upon receiving such PCErr message, the PCE should clear the prefixes 919 advertisement on the previous BGP session, clear the explicit peer 920 route to the previous peer address; select other Local_IP/Peer_IP 921 pair to establish the new BGP session, deploy the explicit peer route 922 to the new peer address, and advertises the prefixes on the new BGP 923 session. 925 11. Security Considerations 927 Service provider should consider the protection of PCE and their 928 communication with the underlay devices, which is described in 929 document [RFC5440] and [RFC8253] 931 12. IANA Considerations 933 12.1. Path Setup Type Registry 935 [RFC8408] created a sub-registry within the "Path Computation Element 936 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 937 IANA is requested to allocate a new code point within this registry, 938 as follows: 940 Value Description Reference 941 TBD1 Native IP TE Path This document 943 12.2. PCECC-CAPABILITY sub-TLV's Flag field 945 [I-D.ietf-pce-pcep-extension-for-pce-controller] created a sub- 946 registry within the "Path Computation Element Protocol (PCEP) 947 Numbers" registry to manage the value of the PCECC-CAPABILITY sub- 948 TLV's 32-bits Flag field. IANA is requested to allocate a new bit 949 position within this registry, as follows: 951 Value Description Reference 952 TBD2(N) NATIVE-IP-TE-CAPABILITY This document 954 12.3. PCEP Object Types 956 IANA is requested to allocate new registry for the PCEP Object Type: 958 Object-Class Value Name Reference 959 TBD13 CCI Object This document 960 Object-Type 961 TBD: Native IP 963 TBD14 BGP Peer Info This document 964 Object-Type 965 1: IPv4 address 966 2: IPv6 address 968 TBD15 Explicit Peer Route This document 969 Object-Type 970 1: IPv4 address 971 2: IPv6 address 973 TBD16 Peer Prefix Association This document 974 Object-Type 975 1: IPv4 address 976 2: IPv6 address 978 12.4. PCEP-Error Object 980 IANA is requested to allocate new error types and error values within 981 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 982 PCEP Numbers registry for the following errors:: 984 Error-Type Meaning Error-value Reference 985 6 Mandatory Object missing 986 TBD4:Native IP object missing This document 988 10 Reception of an invalid object 989 TBD3:PCECC NATIVE-IP-TE-CAPABILITY bit is not set This document 991 19 Invalid Operation 992 TBD5:Only one of the BPI,EPR or PPA object can be included in this message This document 994 TBD6 Native IP TE failure This document 995 TBD7:Peer AS not match 996 TBD8:Peer IP can't be reached 997 TBD9:Local IP is in use 998 TBD10:Remote IP is in use 999 TBD11:Exist BGP session broken 1000 TBD12:Explicit Peer Route Error 1001 TBD17:EPR/BPI Peer Info mismatch 1002 TBD18:BPI/PPA Address Family mismatch 1003 TBD19:PPA/BPI Peer Info mismatch 1005 13. Contributor 1007 Dhruv Dhody has contributed the contents of this draft. 1009 14. Acknowledgement 1011 Thanks Mike Koldychev, Siva Sivabalan, Adam Simpson for his valuable 1012 suggestions and comments. 1014 15. Normative References 1016 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1017 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1018 Procedures and Protocol Extensions for Using PCE as a 1019 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1020 extension-for-pce-controller-10 (work in progress), 1021 January 2021. 1023 [I-D.ietf-teas-pce-native-ip] 1024 Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path 1025 Computation Element (PCE) based Traffic Engineering (TE) 1026 in Native IP Networks", draft-ietf-teas-pce-native-ip-16 1027 (work in progress), January 2021. 1029 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1030 Requirement Levels", BCP 14, RFC 2119, 1031 DOI 10.17487/RFC2119, March 1997, 1032 . 1034 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1035 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1036 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1037 . 1039 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1040 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1041 DOI 10.17487/RFC5440, March 2009, 1042 . 1044 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1045 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1046 May 2017, . 1048 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1049 Computation Element Communication Protocol (PCEP) 1050 Extensions for Stateful PCE", RFC 8231, 1051 DOI 10.17487/RFC8231, September 2017, 1052 . 1054 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1055 and D. Dhody, "Optimizations of Label Switched Path State 1056 Synchronization Procedures for a Stateful PCE", RFC 8232, 1057 DOI 10.17487/RFC8232, September 2017, 1058 . 1060 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1061 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1062 Path Computation Element Communication Protocol (PCEP)", 1063 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1064 . 1066 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1067 Computation Element Communication Protocol (PCEP) 1068 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1069 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1070 . 1072 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1073 Architecture for Use of PCE and the PCE Communication 1074 Protocol (PCEP) in a Network with Central Control", 1075 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1076 . 1078 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1079 Hardwick, "Conveying Path Setup Type in PCE Communication 1080 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1081 July 2018, . 1083 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1084 Dhody, D., and Y. Tanaka, "Path Computation Element 1085 Communication Protocol (PCEP) Extensions for Establishing 1086 Relationships between Sets of Label Switched Paths 1087 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1088 . 1090 [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, 1091 "Scenarios and Simulation Results of PCE in a Native IP 1092 Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, 1093 . 1095 Authors' Addresses 1097 Aijun Wang 1098 China Telecom 1099 Beiqijia Town, Changping District 1100 Beijing, Beijing 102209 1101 China 1103 Email: wangaj3@chinatelecom.cn 1105 Boris Khasanov 1106 Yandex LLC 1107 Ulitsa Lva Tolstogo 16 1108 Moscow 1109 Russia 1111 Email: bhassanov@yahoo.com 1113 Sheng Fang 1114 Huawei Technologies,Co.,Ltd 1115 Huawei Bld., No.156 Beiqing Rd. 1116 Beijing 1117 China 1119 Email: fsheng@huawei.com 1120 Ren Tan 1121 Huawei Technologies,Co.,Ltd 1122 Huawei Bld., No.156 Beiqing Rd. 1123 Beijing 1124 China 1126 Email: tanren@huawei.com 1128 Chun Zhu 1129 ZTE Corporation 1130 50 Software Avenue, Yuhua District 1131 Nanjing, Jiangsu 210012 1132 China 1134 Email: zhu.chun1@zte.com.cn