idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-10.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 86 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 5, 2021) is 1176 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 9, 2021 Yandex LLC 6 S. Fang 7 R. Tan 8 Huawei Technologies,Co.,Ltd 9 C. Zhu 10 ZTE Corporation 11 February 5, 2021 13 PCEP Extension for Native IP Network 14 draft-ietf-pce-pcep-extension-native-ip-10 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 9, 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 . . . . . . . . . . . . . . . . . . . 22 87 12.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 23 88 13. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 90 15. Normative References . . . . . . . . . . . . . . . . . . . . 24 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 | Message No.| Message Peers | Message Type | Message Key Parameters | 354 +------------------------------------------------------------------------------------------+ 355 | M1/M1-R | PCE/R1 | PCInitiate/PCRpt | CC-ID=X1(Symbolic Path Name=Class A) | 356 | | | | BPI Object(Local_IP=R1_A,Peer_IP=R3_A) | 357 +------------------------------------------------------------------------------------------+ 358 | M2/M2-R | PCE/R3 | PCInitiate/PCRpt | CC-ID=X2(Symbolic Path Name=Class A) | 359 | | | | BPI Object(Local_IP=R3_A,Peer_IP=R1_A )| 360 +------------------------------------------------------------------------------------------+ 361 | M3/M3-R | PCE/R3 | PCInitiate/PCRpt | CC-ID=X3(Symbolic Path Name=Class A) | 362 | | | | BPI Object(Local_IP=R3_A,Peer_IP=R7_A) | 363 +------------------------------------------------------------------------------------------+ 364 | M4/M4-R | PCE/R7 | PCInitiate/PCRpt | CC-ID=X4(Symbolic Path Name=Class A) | 365 | | | | 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 If the established BGP session is broken after some time, the PCC 380 should also report such error via PCErr message with Err-type=TBD6 381 and error value(Error-value=TBD11, Existing BGP session is broken). 382 Upon receiving such PCErr message, the PCE should select other 383 Local_IP/Peer_IP pair to establish the new BGP session. 385 6.2. Explicit Route Establish Procedures 387 The detail procedures for the explicit route establishment procedures 388 is shown below, using PCInitiate and PCRpt message pair. 390 The PCInitiate message should be sent to the on-path routers 391 respectively. In the example, for explicit route from R1 to R7, the 392 PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as 393 shown in Figure 2. For explicit route from R7 to R1, the PCInitiate 394 message should be sent to R7(M1), R4(M2) and R2(M3), as shown in 395 Figure 3.. 397 When PCC receives the EPR and the CCI object (with the R bit set to 0 398 in SRP object) in PCInitiate message, the PCC should install the 399 explicit route to the the peer. 401 When PCC install successfully the explicit route to the peer, it 402 should report the result via the PCRpt messages, with EPR object 403 included, and the corresponding SRP and CCI object. 405 When PCC receives the EPR and the CCI object with the R bit set to 1 406 in SRP object in PCInitiate message, the PCC should clear the 407 explicit route to the peer that indicated by the EPR object. 409 When PCC clear successfully the explicit route that indicated by this 410 object, it should report the result via the PCRpt message, with the 411 EPR object included, and the corresponding SRP and CCI object. 413 +------------------+ 414 +----------+ PCE + 415 | +----^-----------^-+ 416 | | | 417 | | | 418 | | +------+ | 419 +-----------------+R3(RR)+--|-------------+ 420 M1/M1-R | +------+ | | 421 | | | | 422 +v-+ +--+ | | +--+ +--+ 423 |R1+------+R5+---+-----------|---+R6+----+R7| 424 ++-+ +--+ | | +--+ +-++ 425 | M2/M2-R M3/M3-R | 426 | | | | 427 | +--v--+ +--v-+ | 428 +------------+- R2 +-----+ R4 +-----------+ 429 +--+--+ +--+-+ 430 Figure 2: Explicit Route Establish Procedures(From R1 to R7) 432 The message number, message peers, message type and message key 433 parameters in the above figures are shown in below table: 435 Table 2: Message Information 436 +----------------------------------------------------------------------------------------------+ 437 | Message No.| Message Peers | Message Type | Message Key Parameters | 438 +----------------------------------------------------------------------------------------------+ 439 | M1/M1-R | PCE/R1 | PCInitiate/PCRpt | CC-ID=X1(Symbolic Path Name=Class A) | 440 | | | | EPR Object(Peer Address=R7_A,Next Hop=R2_A)| 441 +----------------------------------------------------------------------------------------------+ 442 | M2/M2-R | PCE/R2 | PCInitiate/PCRpt | CC-ID=X2(Symbolic Path Name=Class A) | 443 | | | | EPR Object(Peer Address=R7_A,Next Hop=R4_A)| 444 +----------------------------------------------------------------------------------------------+ 445 | M3/M3-R | PCE/R4 | PCInitiate/PCRpt | CC-ID=X3(Symbolic Path Name=Class A) | 446 | | | | EPR Object(Peer Address=R7_A,Next Hop=R7_A)| 447 +----------------------------------------------------------------------------------------------+ 449 +------------------+ 450 + PCE +-----------+ 451 +----^-----------^-+ | 452 | | | 453 | | | 454 | +------+ | | 455 +-----------------+R3(RR)+--|-------------+ 456 | | +------+ | M1/M1-R 457 | | | | 458 +--+ +--+ | | +--+ +-v+ 459 |R1+------+R5+---+-----------|---+R6+----+R7| 460 ++-+ +--+ | | +--+ +-++ 461 | M3/M3-R M2/M2-R | 462 | | | | 463 | +--v--+ +--v-+ | 464 +------------+- R2 +-----+ R4 +-----------+ 465 +--+--+ +--+-+ 466 Figure 3: Explicit Route Establish Procedures(From R7 to R1) 468 The message number, message peers, message type and message key 469 parameters in the above figures are shown in below table: 471 Table 3: Message Information 472 +----------------------------------------------------------------------------------------------+ 473 | Message No.| Message Peers | Message Type | Message Key Parameters | 474 +----------------------------------------------------------------------------------------------+ 475 | M1/M1-R | PCE/R7 | PCInitiate/PCRpt | CC-ID=X1(Symbolic Path Name=Class A) | 476 | | | | EPR Object(Peer Address=R1_A,Next Hop=R4_A)| 477 +----------------------------------------------------------------------------------------------+ 478 | M2/M2-R | PCE/R4 | PCInitiate/PCRpt | CC-ID=X2(Symbolic Path Name=Class A) | 479 | | | | EPR Object(Peer Address=R1_A,Next Hop=R2_A)| 480 +----------------------------------------------------------------------------------------------+ 481 | M3/M3-R | PCE/R2 | PCInitiate/PCRpt | CC-ID=X3(Symbolic Path Name=Class A) | 482 | | | | EPR Object(Peer Address=R1_A,Next Hop=R1_A)| 483 +----------------------------------------------------------------------------------------------+ 485 Upon the error occurs, the PCC SHOULD send the corresponding error 486 via PCErr message, with an error information (Error-type=TBD6, Error- 487 value=TBD12, Explicit Peer Route Error) that defined in Section 9. 489 When the peer info that associated with the Symbolic Path Name is not 490 the same as the peer info that indicated in BPI object in PCC, an 491 error (Error-type=TBD6, Error-value=17, EPR/BPI Peer Info mismatch) 492 should be reported via the PCErr message. 494 6.3. BGP Prefix Advertisement Procedures 496 The detail procedures for BGP prefix advertisement is shown below, 497 using PCInitiate and PCRpt message pair. 499 The PCInitiate message should be sent to PCC that acts as BGP peer 500 router only. In the example, it should be sent to R1(M1) or R7(M2) 501 respectively. 503 When PCC receives the PPA and the CCI object (with the R bit set to 0 504 in SRP object) in PCInitiate message, the PCC should send the 505 prefixes indicated in this object to the appointed BGP peer. 507 When PCC sends successfully the prefixes to the appointed BGP peer, 508 it should report the result via the PCRpt messages, with PPA object 509 included, and the corresponding SRP and CCI object. 511 When PCC receives the PPA and the CCI object with the R bit set to 1 512 in SRP object in PCInitiate message, the PCC should withdraw the 513 prefixes advertisement to the peer that indicated by this object. 515 When PCC withdraws successfully the prefixes that indicated by this 516 object, it should report the result via the PCRpt message, with the 517 PPA object included, and the corresponding SRP and CCI object. 519 The IPv4 prefix MUST only be advertised via the IPv4 BGP session and 520 the IPv6 prefix MUST only be advertised via the IPv6 BGP session. If 521 mismatch occur, an error(Error-type=TBD6, Error-value=TBD18, BPI/PPR 522 address family mismatch) should be reported via PCErr message. 524 When the peer info that associated with the Symbolic Path Name is not 525 the same as the peer info that indicated in BPI object in PCC, an 526 error (Error-type=TBD6, Error-value=TBD19, PPA/BPI peer info 527 mismatch) should be reported via the PCErr message. 529 +------------------+ 530 +----------+ PCE +-----------+ 531 | +------------------+ | 532 | +--+ | 533 +------------------+R3+-------------------+ 534 M1&M1-R +--+ M2&M2-R 535 | | 536 +v-+ +--+ +--+ +-v+ 537 |R1+----------+R5+----------+R6+---------+R7| 538 ++-+ +--+ +--+ +-++ 539 | | 540 | | 541 | +--+ +--+ | 542 +------------+R2+----------+R4+-----------+ 543 Figure 4: BGP Prefix Advertisement Procedures 545 Table 4: Message Information 546 +----------------------------------------------------------------------------------------------+ 547 | Message No.| Message Peers | Message Type | Message Key Parameters | 548 +----------------------------------------------------------------------------------------------+ 549 | M1/M1-R | PCE/R1 | PCInitiate/PCRpt | CC-ID=X1(Symbolic Path Name=Class A) | 550 | | | | PPA Object(Peer IP=R7_A,Prefix=1_A) | 551 +----------------------------------------------------------------------------------------------+ 552 | M2/M2-R | PCE/R7 | PCInitiate/PCRpt | CC-ID=X2(Symbolic Path Name=Class A) | 553 | | | | PPA Object(Peer IP=R1_A,Prefix=7_A) | 554 +----------------------------------------------------------------------------------------------+ 556 7. New PCEP Objects 558 One new CCI Object and three new PCEP objects are defined in this 559 draft. All new PCEP objects are as per [RFC5440] 561 7.1. CCI Object 563 The Central Control Instructions (CCI) Object is used by the PCE to 564 specify the forwarding instructions is defined in 565 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 566 defines another object-type for Native-IP. 568 CCI Object-Type is TBD13 for Native-IP as below 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | CC-ID | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Reserved | Flags | 576 +---------------------------------------------------------------+ 577 | | 578 // Optional TLV // 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 5: CCI Object for Native IP 584 Figure 1 586 The field CC-ID is as described in 587 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields 588 are defined for CCI Object-Type TBD13 590 Reserved: is set to zero while sending, ignored on receipt. 592 Flags: is used to carry any additional information pertaining to the 593 CCI. Currently no flag bits are defined. 595 The Symbolic Path Name TLV [RFC8231] MUST be included in the CCI 596 Object-Type TBD13 to identify the E2E TE path in Native IP 597 environment and MUST be unique. 599 7.2. BGP Peer Info Object 601 The BGP Peer Info object is used to specify the information about the 602 peer that the PCC should establish the BGP relationship with. This 603 object should only be included and sent to the head and end router of 604 the E2E path in case there is no Route Reflection (RR) involved. If 605 the RR is used between the head and end routers, then such 606 information should be sent to head router, RR and end router 607 respectively. 609 By default, there MUST be no prefix be distributed via such BGP 610 session that established by this object. 612 By default, the Local/Peer IP address SHOULD be dedicated to the 613 usage of native IP TE solution, and SHOULD NOT be used by other BGP 614 sessions that established by manual or non PCE initiated 615 configuration. 617 BGP Peer Info Object-Class is TBD14 619 BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 621 The format of the BGP Peer Info object body for IPv4(Object-Type=1) 622 is as follows: 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Peer AS Number | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | ETTL | Reserved | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Local IP Address | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Peer IP Address | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Additional TLVs | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 6: BGP Peer Info Object Body Format for IPv4 639 The format of the BGP Peer Info object body for IPv6(Object-Type=2) 640 is as follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Peer AS Number | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | ETTL | Tunnel Type | Reserved | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 + + 651 | Local IP Address (16 bytes) | 652 + + 653 | | 654 + + 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 + + 659 | Peer IP Address (16 bytes) | 660 + + 661 | | 662 + + 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Additional TLVs | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 7: BGP Peer Info Object Body Format for IPv6 669 Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. 671 ETTL: 1 Byte, to indicate the multi hop count for EBGP session. It 672 should be 0 and ignored when Local AS and Peer AS is same. 674 Tunnel Type: 1 Byte, indicate the tunnel type that used to transfer 675 the traffic that identified by the prefixes that advertised by the 676 corresponding BGP peer. Value 0 indicate no tunnel is used. Other 677 value can refer to the IANA allocation value in "BGP Tunnel 678 Encapsulation Attribute Tunnel Types". 680 Reserved: is set to zero while sending, ignored on receipt.. 682 Local IP Address(4/16 Bytes): IP address of the local router, used to 683 peer with other end router. When Object-Type is 1, length is 4 684 bytes; when Object-Type is 2, length is 16 bytes. 686 Peer IP Address(4/16 Bytes): IP address of the peer router, used to 687 peer with the local router. When Object-Type is 1, length is 4 688 bytes; when Object-Type is 2, length is 16 bytes; 689 Additional TLVs: TLVs that associated with this object, can be used 690 to convey other necessary information for dynamic BGP session 691 establishment. Its definition is out of the current document. 693 When PCC receives BPI object, with Object-Type=1, it should try to 694 establish BGP session with the peer in AFI/SAFI=1/1; when PCC 695 receives BPI object with Object-Type=2, it should try to establish 696 the BGP session with the peer in AFI/SAFI=2/1. Other BGP 697 capabilities,for example, Graceful Restart(GR) that enhance the BGP 698 performance should also be negotiated and used by default. 700 7.3. Explicit Peer Route Object 702 The Explicit Peer Route object is defined to specify the explicit 703 peer route to the corresponding peer address on each device that is 704 on the E2E assurance path. This Object should be sent to all the 705 devices that locates on the E2E assurance path that calculated by 706 PCE. 708 The path established by this object should have higher priority than 709 other path calculated by dynamic IGP protocol, but should be lower 710 priority that the static route configured by manual or NETCONF 711 channel. 713 Explicit Peer Route Object-Class is TBD15. 715 Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6 717 The format of Explicit Peer Route object body for IPv4(Object-Type=1) 718 is as follows: 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Route Priority | Reserved | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | IPv4 Peer Address | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Next Hop Address to the IPv4 Peer Address | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Additional TLVs | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 Figure 8: Explicit Peer Route Object Body Format for IPv4 733 The format of Explicit Peer Route object body for IPv6(Object-Type=2) 734 is as follows: 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Route Priority | Reserved | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | | 742 + + 743 | IPv6 Peer Address | 744 + + 745 | | 746 + + 747 | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | | 750 + + 751 | Next Hop Address to the IPv6 Peer Address | 752 + + 753 | | 754 + + 755 | | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Additional TLVs | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Figure 9: Explicit Peer Route Object Body Format for IPv6 761 Route Priority: 2 Bytes, The priority of this explicit route. The 762 higher priority should be preferred by the device. This field is 763 used to indicate the backup path at each hop. 765 Reserved.: is set to zero while sending, ignored on receipt. 767 Peer Address: To indicate the peer address. 769 Next Hop Address to the Peer: To indicate the next hop address to the 770 corresponding peer. 772 Additional TLVs: TLVs that associated with this object, can be used 773 to convey other necessary information for explicit peer path 774 establishment. Its definition is out of the current document. 776 7.4. Peer Prefix Association Object 778 The Peer Prefix Association object is defined to specify the IP 779 prefixes that should be advertised to the corresponding peer. This 780 object should only be included and sent to the head/end router of the 781 end2end path. 783 The prefixes information included in this object MUST only be 784 advertised to the indicated peer, MUST NOT be advertised to other BGP 785 peers. 787 Peer Prefix Association Object-Class is TBD16 789 Peer Prefix Association Object-Type is 1 for IPv4 and 2 for IPv6 791 The format of the Peer Prefix Association object body is as follows: 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Peer IPv4 Address | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | | 799 // IPv4 Prefix subobjects // 800 | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Additional TLVs | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 10: Peer Prefix Association Object Body Format for IPv4 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Peer IPv6 Address | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | | 812 // IPv6 Prefix subobjects // 813 | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Additional TLVs | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Figure 11: Peer Prefix Association Object Body Format for IPv6 819 Peer IPv4 Address: 4 Bytes. Identifies the peer IPv4 address that 820 the associated prefixes will be sent to. 822 IPv4 Prefix subojects: List of IPv4 Prefix subobjects that defined in 823 [RFC3209], identify the prefixes that will be sent to the peer that 824 identified by Peer IPv4 Address List. 826 Peer IPv6 Address: 16 Bytes. Identifies the peer IPv6 address that 827 the associated prefixes will be sent to. 829 IPv6 Prefix subojects: List of IPv6 Prefix subobjects that defined in 830 [RFC3209], identify the prefixes that will be sent to the peer that 831 identified by Peer IPv6 Address List. 833 Additional TLVs: TLVs that associated with this object, can be used 834 to convey other necessary information for prefixes advertisement. 835 Its definition is out of the current document. 837 8. End to End Path Protection 839 [RFC8697] defines the path associations procedures between sets of 840 Label Switched Path (LSP). Such procedures can also be used for the 841 E2E path protection. To accomplish this, the PCE should attach the 842 ASSOCIATION object with the EPR object in the PCInitiate message, 843 with the association type set to 1 (Path Protection Association). 844 The Extended Association ID that included within the Extended 845 Association ID TLV, which is included in the ASSOCIATION object, 846 should be set to the Symbolic Path Name of different E2E path. This 847 PCinitiate should be sent to the head-end of the E2E path. 849 The head-end of the path can use the existing path detection 850 mechanism, to monitor the status of the active path. Once it detects 851 the failure, it can switch the backup protection path immediately. 853 9. New Error-Types and Error-Values Defined 855 A PCEP-ERROR object is used to report a PCEP error and is 856 characterized by an Error-Type that specifies that type of error and 857 an Error-value that provides additional information about the error. 858 An additional Error-Type and several Error-values are defined to 859 represent some the errors related to the newly defined objects, which 860 are related to Native IP TE procedures. 862 +============+===============+==============================+ 863 | Error-Type | Meaning | Error-value | 864 +============+===============+=====================================+ 865 | TBD6 | Native IP | | 866 | | TE failure | | 867 +------------+---------------+-------------------------------------+ 868 | | | 0: Unassigned | 869 +------------+---------------+-------------------------------------+ 870 | | |TBD7: Peer AS not match | 871 +------------+---------------+-------------------------------------+ 872 | | |TBD8:Peer IP can't be reached | 873 +------------+---------------+-------------------------------------+ 874 | | |TBD9:Local IP is in use | 875 +------------+---------------+-------------------------------------+ 876 | | |TBD10:Remote IP is in use | 877 +------------+---------------+-------------------------------------+ 878 | | |TBD11:Exist BGP session broken | 879 +------------+---------------+-------------------------------------+ 880 | | |TBD12:Explicit Peer Route Error | 881 +------------+---------------+-------------------------------------+ 882 | | |TBD17:EPR/BPI Peer Info mismatch | 883 +------------+---------------+-------------------------------------+ 884 | | |TBD18:BPI/PPA Address Family mismatch| 885 +------------+---------------+-------------------------------------+ 886 | | |TBD19:PPA/BPI Peer Info mismatch | 887 +------------+---------------+-------------------------------------+ 888 | | | | 889 +------------+---------------+-------------------------------------+ 890 | | | | 891 +------------+---------------+-------------------------------------+ 892 | | | | 893 +------------+---------------+-------------------------------------+ 894 | | | | 895 +------------+---------------+-------------------------------------+ 896 Figure 12: Newly defined Error-Type and Error-Value 898 10. Deployment Considerations 900 The information transferred in this draft is mainly used for the 901 light weight BGP session setup, explicit route deployment and the 902 prefix distribution. The planning, allocation and distribution of 903 the peer addresses within IGP should be accomplished in advanced and 904 they are out of the scope of this draft. 906 [RFC8232] describes the state synchronization procedure between 907 stateful PCE and PCC. The communication of PCE and PCC described in 908 this draft should also follow this procedures, treat the three newly 909 defined objects that associated with the same symbolic path name as 910 the attribute of the same path in the LSP-DB. 912 When PCE detects one or some of the PCCs are out of control, it 913 should recompute and redeploy the traffic engineering path for native 914 IP on the active PCCs. When PCC detects that it is out of control of 915 the PCE, it should clear the information that initiated by the PCE. 916 The PCE should assures the avoidance of possible transient loop in 917 such node failure when it deploy the explicit peer route on the PCCs. 919 11. Security Considerations 921 Service provider should consider the protection of PCE and their 922 communication with the underlay devices, which is described in 923 document [RFC5440] and [RFC8253] 925 12. IANA Considerations 927 12.1. Path Setup Type Registry 929 [RFC8408] created a sub-registry within the "Path Computation Element 930 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 931 IANA is requested to allocate a new code point within this registry, 932 as follows: 934 Value Description Reference 935 TBD1 Native IP TE Path This document 937 12.2. PCECC-CAPABILITY sub-TLV's Flag field 939 [I-D.ietf-pce-pcep-extension-for-pce-controller] created a sub- 940 registry within the "Path Computation Element Protocol (PCEP) 941 Numbers" registry to manage the value of the PCECC-CAPABILITY sub- 942 TLV's 32-bits Flag field. IANA is requested to allocate a new bit 943 position within this registry, as follows: 945 Value Description Reference 946 TBD2(N) NATIVE-IP-TE-CAPABILITY This document 948 12.3. PCEP Object Types 950 IANA is requested to allocate new registry for the PCEP Object Type: 952 Object-Class Value Name Reference 953 TBD13 CCI Object This document 954 Object-Type 955 TBD: Native IP 957 TBD14 BGP Peer Info This document 958 Object-Type 959 1: IPv4 address 960 2: IPv6 address 962 TBD15 Explicit Peer Route This document 963 Object-Type 964 1: IPv4 address 965 2: IPv6 address 967 TBD16 Peer Prefix Association This document 968 Object-Type 969 1: IPv4 address 970 2: IPv6 address 972 12.4. PCEP-Error Object 974 IANA is requested to allocate new error types and error values within 975 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 976 PCEP Numbers registry for the following errors:: 978 Error-Type Meaning Error-value Reference 979 6 Mandatory Object missing 980 TBD4:Native IP object missing This document 982 10 Reception of an invalid object 983 TBD3:PCECC NATIVE-IP-TE-CAPABILITY bit is not set This document 985 19 Invalid Operation 986 TBD5:Only one of the BPI,EPR or PPA object can be included in this message This document 988 TBD6 Native IP TE failure This document 989 TBD7:Peer AS not match 990 TBD8:Peer IP can't be reached 991 TBD9:Local IP is in use 992 TBD10:Remote IP is in use 993 TBD11:Exist BGP session broken 994 TBD12:Explicit Peer Route Error 995 TBD17:EPR/BPI Peer Info mismatch 996 TBD18:BPI/PPA Address Family mismatch 997 TBD19:PPA/BPI Peer Info mismatch 999 13. Contributor 1001 Dhruv Dhody has contributed the contents of this draft. 1003 14. Acknowledgement 1005 Thanks Mike Koldychev, Siva Sivabalan, Adam Simpson for his valuable 1006 suggestions and comments. 1008 15. Normative References 1010 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1011 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1012 Procedures and Protocol Extensions for Using PCE as a 1013 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1014 extension-for-pce-controller-10 (work in progress), 1015 January 2021. 1017 [I-D.ietf-teas-pce-native-ip] 1018 Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path 1019 Computation Element (PCE) based Traffic Engineering (TE) 1020 in Native IP Networks", draft-ietf-teas-pce-native-ip-16 1021 (work in progress), January 2021. 1023 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1024 Requirement Levels", BCP 14, RFC 2119, 1025 DOI 10.17487/RFC2119, March 1997, 1026 . 1028 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1029 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1030 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1031 . 1033 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1034 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1035 DOI 10.17487/RFC5440, March 2009, 1036 . 1038 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1039 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1040 May 2017, . 1042 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1043 Computation Element Communication Protocol (PCEP) 1044 Extensions for Stateful PCE", RFC 8231, 1045 DOI 10.17487/RFC8231, September 2017, 1046 . 1048 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1049 and D. Dhody, "Optimizations of Label Switched Path State 1050 Synchronization Procedures for a Stateful PCE", RFC 8232, 1051 DOI 10.17487/RFC8232, September 2017, 1052 . 1054 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1055 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1056 Path Computation Element Communication Protocol (PCEP)", 1057 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1058 . 1060 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1061 Computation Element Communication Protocol (PCEP) 1062 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1063 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1064 . 1066 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1067 Architecture for Use of PCE and the PCE Communication 1068 Protocol (PCEP) in a Network with Central Control", 1069 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1070 . 1072 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1073 Hardwick, "Conveying Path Setup Type in PCE Communication 1074 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1075 July 2018, . 1077 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1078 Dhody, D., and Y. Tanaka, "Path Computation Element 1079 Communication Protocol (PCEP) Extensions for Establishing 1080 Relationships between Sets of Label Switched Paths 1081 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1082 . 1084 [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, 1085 "Scenarios and Simulation Results of PCE in a Native IP 1086 Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, 1087 . 1089 Authors' Addresses 1090 Aijun Wang 1091 China Telecom 1092 Beiqijia Town, Changping District 1093 Beijing, Beijing 102209 1094 China 1096 Email: wangaj3@chinatelecom.cn 1098 Boris Khasanov 1099 Yandex LLC 1100 Ulitsa Lva Tolstogo 16 1101 Moscow 1102 Russia 1104 Email: bhassanov@yahoo.com 1106 Sheng Fang 1107 Huawei Technologies,Co.,Ltd 1108 Huawei Bld., No.156 Beiqing Rd. 1109 Beijing 1110 China 1112 Email: fsheng@huawei.com 1114 Ren Tan 1115 Huawei Technologies,Co.,Ltd 1116 Huawei Bld., No.156 Beiqing Rd. 1117 Beijing 1118 China 1120 Email: tanren@huawei.com 1122 Chun Zhu 1123 ZTE Corporation 1124 50 Software Avenue, Yuhua District 1125 Nanjing, Jiangsu 210012 1126 China 1128 Email: zhu.chun1@zte.com.cn