idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-12.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 30 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 (March 26, 2021) is 1120 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 4272 ** Downref: Normative reference to an Informational RFC: RFC 8283 ** Downref: Normative reference to an Informational RFC: RFC 8735 Summary: 6 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: September 27, 2021 Yandex LLC 6 S. Fang 7 R. Tan 8 Huawei Technologies,Co.,Ltd 9 C. Zhu 10 ZTE Corporation 11 March 26, 2021 13 PCEP Extension for Native IP Network 14 draft-ietf-pce-pcep-extension-native-ip-12 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 September 27, 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 Advertisement Object . . . . . . . . . . . . 18 79 8. End to End Path Protection . . . . . . . . . . . . . . . . . 20 80 9. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 10. New Error-Types and Error-Values Defined . . . . . . . . . . 20 82 11. Deployment Considerations . . . . . . . . . . . . . . . . . . 21 83 12. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 13.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 22 86 13.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 22 87 13.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 23 88 13.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 23 89 14. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 91 16. Normative References . . . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 94 1. Introduction 96 Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- 97 TE) requires the corresponding network devices support Multiprotocol 98 Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label 99 Distribution Protocol (LDP) technologies to assure the End-to-End 100 (E2E) traffic performance. In Segment Routing either IGP extensions 101 or BGP are used to steer a packet through an SR Policy instantiated 102 as an ordered list of instructions called "segments". But in native 103 IP network, there will be no such signaling protocol to synchronize 104 the action among different network devices. It is necessary to use 105 the central control mode that described in [RFC8283] to correlate the 106 forwarding behavior among different network devices. Draft 107 [I-D.ietf-teas-pce-native-ip] describes the architecture and solution 108 philosophy for the E2E traffic assurance in Native IP network via 109 Multi Border Gateway Protocol (BGP) solution. This draft describes 110 the corresponding Path Computation Element Communication Protocol 111 (PCEP) extensions to transfer the key information about BGP peer 112 info, peer prefix advertisement and the explicit peer route on on- 113 path routers. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Terminology 125 This document uses the following terms defined in [RFC5440]: PCE, 126 PCEP 128 The following terms are defined in this document: 130 o CCDR: Central Control Dynamic Routing 132 o E2E: End to End 134 o BPI: BGP Peer Info 136 o EPR: Explicit Peer Route 138 o PPA: Peer Prefix Advertisement 140 o QoS: Quality of Service 142 4. Capability Advertisemnt 144 4.1. Open message 146 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 147 advertise their support of Native IP extensions. 149 This document defines a new Path Setup Type (PST) [RFC8408] for 150 Native-IP, as follows: 152 o PST = TBD1: Path is a Native IP path as per 153 [I-D.ietf-teas-pce-native-ip]. 155 A PCEP speaker MUST indicate its support of the function described in 156 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 157 object with this new PST included in the PST list. 159 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 160 CAPABILITY sub-TLV to exchange information about their PCECC 161 capability. A new flag is defined in PCECC-CAPABILITY sub-TLV for 162 Native IP: 164 N (NATIVE-IP-TE-CAPABILITY - 1 bit - TBD2): If set to 1 by a PCEP 165 speaker, it indicates that the PCEP speaker is capable for TE in 166 Native IP network as specified in this document. The flag MUST be 167 set by both the PCC and PCE in order to support this extension. 169 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 170 the newly defined path setup type, but without the N bit set in 171 PCECC-CAPABILITY sub-TLV, it MUST: 173 o Send a PCErr message with Error-Type=10(Reception of an invalid 174 object) and Error-Value TBD3(PCECC NATIVE-IP-TE-CAPABILITY bit is 175 not set). 177 o Terminate the PCEP session 179 5. PCEP messages 181 PCECC Native IP TE solution utilizing the existing PCE LSP Initate 182 Request message(PCInitiate)[RFC8281], and PCE Report message(PCRpt) 183 [RFC8281] to accomplish the multi BGP sessions establishment, E2E TE 184 path deployment, and route prefixes advertisement among different BGP 185 sessions. A new PST for Native-IP is used to indicate the path setup 186 based on TE in Native IP networks. 188 The extended PCInitiate message described in 189 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 190 or cleanup central controller's instructions (CCIs). 191 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 192 called CCI for the encoding of central controller's instructions. 193 This document specify a new CCI object-type for Native IP. The PCEP 194 messages are extended in this document to handle the PCECC operations 195 for Native IP. Three new PCEP Objects (BGP Peer Info (BPI) Object, 196 Explicit Peer Route (EPR) Object and Peer Prefix Advertisement (PPA) 197 Object) are defined in this document. Refer to (Section 7) for 198 detail object definitions. 200 5.1. The PCInitiate message 202 The PCInitiate Message defined in [RFC8281] and extended in 203 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 204 to support Native-IP CCI. 206 The format of the extended PCInitiate message is as follows: 208 ::= 209 210 Where: 211 is defined in [RFC5440] 213 ::= 214 [] 216 ::= 217 (| 218 | 219 ) 221 ::= 222 ( 223 )| 224 ((||) 225 ) 227 ::= 228 [] 230 Where: 231 is as per 232 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 233 and 234 are as per 235 [RFC8281]. 237 The LSP and SRP objects are defined in [RFC8231]. 239 When PCInitiate message is used create Native IP instructions, the 240 SRP and CCI objects MUST be present. The error handling for missing 241 SRP or CCI object is as per 242 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one 243 of BPI, EPR, or PPA object MUST be present. The PLSP-ID within the 244 LSP object should be set by PCC uniquely according to the Symbolic 245 Path Name TLV that included in the CCI object. The Symbolic Path 246 Name is used by the PCE/PCC to identify uniquely the E2E native IP TE 247 path. 249 If none of them are present, the receiving PCC MUST send a PCErr 250 message with Error-type=6 (Mandatory Object missing) and Error- 251 value=TBD4 (Native IP object missing). If there are more than one of 252 BPI, EPR or PPA object are presented, the receiving PCC MUST send a 253 PCErr message with Error-type=19(Invalid Operation) and Error- 254 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 255 this message). 257 To cleanup the SRP object must set the R (remove) bit. 259 5.2. The PCRpt message 261 The PCRpt message is used to acknowledge the Native-IP instructions 262 received from the central controller (PCE). 264 The format of the PCRpt message is as follows: 266 ::= 267 268 Where: 270 ::= [] 272 ::= (| 273 ) 275 ::= [] 276 277 279 ::= [] 280 ( 281 )| 282 ((||) 283 ) 285 Where: 286 is as per [RFC8231] and the LSP and SRP object are 287 also defined in [RFC8231]. 289 The error handling for missing CCI object is as per 290 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one 291 of BPI, EPR, or PPA object MUST be present. 293 If none of them are present, the receiving PCE MUST send a PCErr 294 message with Error-type=6 (Mandatory Object missing) and Error- 295 value=TBD4 ( Native IP object missing). If there are more than one 296 of BPI, EPR or PPA object are presented, the receiving PCE MUST send 297 a PCErr message with Error-type=19(Invalid Operation) and Error- 298 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 299 this message). 301 6. PCECC Native IP TE Procedures 303 The detail procedures for the TE in native IP environment are 304 described in the following sections. 306 6.1. BGP Session Establishment Procedures 308 The procedures for establishing the BGP session between two peers is 309 shown below, using the PCInitiate and PCRpt message pair. 311 The PCInitiate message should be sent to PCC which acts as BGP router 312 and route reflector(RR). In the example in Figure 1, it should be 313 sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR. 315 When PCC receives the BPI and CCI object (with the R bit set to 0 in 316 SRP object) in PCInitiate message, the PCC should try to establish 317 the BGP session with the indicated Peer AS and Local/Peer IP address. 319 When PCC creates successfully the BGP session that is indicated by 320 the associated information, it should report the result via the PCRpt 321 messages, with BPI object and the corresponding SRP and CCI object 322 included. 324 When PCC receives this message with the R bit set to 1 in SRP object 325 in PCInitiate message, the PCC should clear the BGP session that 326 indicated by the BPI object. 328 When PCC clears successfully the specified BGP session, it should 329 report the result via the PCRpt message, with the BPI object 330 included, and the corresponding SRP and CCI object. 332 +------------------+ 333 +-----------+ PCE +----------+ 334 | +--------^---------+ | 335 | | | 336 M2/M2-R & M3/M3-R 337 | | | 338 | +---v---+ | 339 +---------------+ R3(RR)+-----------------+ 340 | +-------+ | 341 M1/M1-R M4/M4-R 342 | | 343 +v-+ +--+ +--+ +-v+ 344 |R1+----------+R5+----------+R6+---------+R7| 345 ++-+ +--+ +--+ +-++ 346 | | 347 | +--+ +--+ | 348 +------------+R2+----------+R4+-----------+ 349 +--+ +--+ 350 Figure 1: BGP Session Establishment Procedures(R3 act as RR) 352 The message number, message peers, message type and message key 353 parameters in the above figures are shown in below table: 355 Table 1: Message Information 356 +-------------------------------------------------------------+ 357 | No.| Peers| Type | Message Key Parameters | 358 +-------------------------------------------------------------+ 359 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 360 |M1-R| |PCRpt |BPI Object(Local_IP=R1_A,Peer_IP=R3_A)| 361 +-------------------------------------------------------------+ 362 |M2 |PCE/R3|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 363 |M2-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R1_A)| 364 +-------------------------------------------------------------+ 365 |M3 |PCE/R3|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 366 |M3-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R7_A)| 367 +-------------------------------------------------------------+ 368 |M4 |PCE/R7|PCInitiate|CC-ID=X4(Symbolic Path Name=Class A) | 369 |M4-R| |PCRpt |BPI Object(Local_IP=R7_A,Peer_IP=R3_A)| 370 +-------------------------------------------------------------+ 372 If the PCC cannot establish the BGP session that required by this 373 object, it should report the error values via PCErr message with the 374 newly defined error type(Error-type=TBD6) and error value(Error- 375 value=TBD7, Peer AS not match; or Error-Value=TBD8, Peer IP can't be 376 reached), which is indicated in Section 10 378 If the Local_IP or Peer_IP within BPI object is used in other 379 existing BGP sessions, the PCC should report such error situation via 380 PCErr message with Err-type=TBD6 and error value(Error-value=TBD9, 381 Local IP is in use; Error-value=TBD10, Remote IP is in use). 383 6.2. Explicit Route Establish Procedures 385 The detail procedures for the explicit route establishment procedures 386 is shown below, using PCInitiate and PCRpt message pair. 388 The PCInitiate message should be sent to the on-path routers 389 respectively. In the example, for explicit route from R1 to R7, the 390 PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as 391 shown in Figure 2. For explicit route from R7 to R1, the PCInitiate 392 message should be sent to R7(M1), R4(M2) and R2(M3), as shown in 393 Figure 3. 395 When PCC receives the EPR and the CCI object (with the R bit set to 0 396 in SRP object) in PCInitiate message, the PCC should install the 397 explicit route to the the peer. 399 When PCC install successfully the explicit route to the peer, it 400 should report the result via the PCRpt messages, with EPR object and 401 the corresponding SRP and CCI object included. 403 When PCC receives the EPR and the CCI object with the R bit set to 1 404 in SRP object in PCInitiate message, the PCC should clear the 405 explicit route to the peer that indicated by the EPR object. 407 When PCC clear successfully the explicit route that indicated by this 408 object, it should report the result via the PCRpt message, with the 409 EPR object included, and the corresponding SRP and CCI object. 411 +------------------+ 412 +----------+ PCE + 413 | +----^-----------^-+ 414 | | | 415 | | | 416 | | +------+ | 417 +-----------------+R3(RR)+--|-------------+ 418 M1/M1-R | +------+ | | 419 | | | | 420 +v-+ +--+ | | +--+ +--+ 421 |R1+------+R5+---+-----------|---+R6+----+R7| 422 ++-+ +--+ | | +--+ +-++ 423 | M2/M2-R M3/M3-R | 424 | | | | 425 | +--v--+ +--v-+ | 426 +------------+- R2 +-----+ R4 +-----------+ 427 +--+--+ +--+-+ 428 Figure 2: Explicit Route Establish Procedures(From R1 to R7) 430 The message number, message peers, message type and message key 431 parameters in the above figures are shown in below table: 433 Table 2: Message Information 434 +------------------------------------------------------------------+ 435 | No.|Peers | Type | Message Key Parameters | 436 +------------------------------------------------------------------+ 437 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 438 |M1-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R2_A)| 439 +------------------------------------------------------------------+ 440 |M2 |PCE/R2|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 441 |M2-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R4_A)| 442 +------------------------------------------------------------------+ 443 |M3 |PCE/R4|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 444 |M3-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R7_A)| 445 +------------------------------------------------------------------+ 446 +------------------+ 447 + PCE +-----------+ 448 +----^-----------^-+ | 449 | | | 450 | | | 451 | +------+ | | 452 +-----------------+R3(RR)+--|-------------+ 453 | | +------+ | M1/M1-R 454 | | | | 455 +--+ +--+ | | +--+ +-v+ 456 |R1+------+R5+---+-----------|---+R6+----+R7| 457 ++-+ +--+ | | +--+ +-++ 458 | M3/M3-R M2/M2-R | 459 | | | | 460 | +--v--+ +--v-+ | 461 +------------+- R2 +-----+ R4 +-----------+ 462 +--+--+ +--+-+ 463 Figure 3: Explicit Route Establish Procedures(From R7 to R1) 465 The message number, message peers, message type and message key 466 parameters in the above figures are shown in below table: 468 Table 3: Message Information 469 +------------------------------------------------------------------+ 470 |No. |Peers | Type | Message Key Parameters | 471 +------------------------------------------------------------------+ 472 |M1 |PCE/R7|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 473 |M1-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R4_A)| 474 +------------------------------------------------------------------+ 475 |M2 |PCE/R4|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 476 |M2-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R2_A)| 477 +------------------------------------------------------------------+ 478 |M3 |PCE/R2|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 479 |M3-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R1_A)| 480 +------------------------------------------------------------------+ 482 In order to avoid the transient loop during the deploy of explicit 483 peer route, the EPR object should be sent to the PCCs in the reverse 484 order of the E2E path. To remove the explicit peer route, the EPR 485 object should be sent to the PCCs in the same order of E2E path. 487 Upon the error occurs, the PCC SHOULD send the corresponding error 488 via PCErr message, with an error information (Error-type=TBD6, Error- 489 value=TBD12, Explicit Peer Route Error) that defined in Section 10. 491 When the peer info is not the same as the peer info that indicated in 492 BPI object in PCC for the same path that is identified by Symbolic 493 Path Name TLV, an error (Error-type=TBD6, Error-value=17, EPR/BPI 494 Peer Info mismatch) should be reported via the PCErr message. 496 6.3. BGP Prefix Advertisement Procedures 498 The detail procedures for BGP prefix advertisement are shown below, 499 using PCInitiate and PCRpt message pair. 501 The PCInitiate message should be sent to PCC that acts as BGP peer 502 router only. In the example, it should be sent to R1(M1) or R7(M2) 503 respectively. 505 When PCC receives the PPA and the CCI object (with the R bit set to 0 506 in SRP object) in PCInitiate message, the PCC should send the 507 prefixes indicated in this object to the appointed BGP peer. 509 When PCC sends successfully the prefixes to the appointed BGP peer, 510 it should report the result via the PCRpt messages, with PPA object 511 and the corresponding SRP and CCI object included. 513 When PCC receives the PPA and the CCI object with the R bit set to 1 514 in SRP object in PCInitiate message, the PCC should withdraw the 515 prefixes advertisement to the peer that indicated by this object. 517 When PCC withdraws successfully the prefixes that indicated by this 518 object, it should report the result via the PCRpt message, with the 519 PPA object included, and the corresponding SRP and CCI object. 521 The IPv4 prefix MUST only be advertised via the IPv4 BGP session and 522 the IPv6 prefix MUST only be advertised via the IPv6 BGP session. If 523 mismatch occur, an error(Error-type=TBD6, Error-value=TBD18, BPI/PPR 524 address family mismatch) should be reported via PCErr message. 526 When the peer info is not the same as the peer info that indicated in 527 BPI object in PCC for the same path that is identified by Symbolic 528 Path Name TLV, an error (Error-type=TBD6, Error-value=TBD19, PPA/BPI 529 peer info mismatch) should be reported via the PCErr message. 531 +------------------+ 532 +----------+ PCE +-----------+ 533 | +------------------+ | 534 | +--+ | 535 +------------------+R3+-------------------+ 536 M1&M1-R +--+ M2&M2-R 537 | | 538 +v-+ +--+ +--+ +-v+ 539 |R1+----------+R5+----------+R6+---------+R7| 540 ++-+ +--+ +--+ +-++ 541 | | 542 | | 543 | +--+ +--+ | 544 +------------+R2+----------+R4+-----------+ 545 Figure 4: BGP Prefix Advertisement Procedures 547 Table 4: Message Information 548 +-----------------------------------------------------------+ 549 |No. | Peers| Type | Message Key Parameters | 550 +-----------------------------------------------------------+ 551 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A)| 552 |M1-R| |PCRpt |PPA Object(Peer IP=R7_A,Prefix=1_A) | 553 +-----------------------------------------------------------+ 554 |M2 |PCE/R7|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A)| 555 |M2-R| |PCRpt |PPA Object(Peer IP=R1_A,Prefix=7_A) | 556 +-----------------------------------------------------------+ 558 7. New PCEP Objects 560 One new CCI Object and three new PCEP objects are defined in this 561 draft. All new PCEP objects are as per [RFC5440] 563 7.1. CCI Object 565 The Central Control Instructions (CCI) Object is used by the PCE to 566 specify the forwarding instructions is defined in 567 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 568 defines another object-type for Native-IP. 570 CCI Object-Type is TBD13 for Native-IP as below 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | CC-ID | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Reserved | Flags | 577 +---------------------------------------------------------------+ 578 | | 579 // Optional TLV // 580 | | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 5: CCI Object for Native IP 585 Figure 1 587 The field CC-ID is as described in 588 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields 589 are defined for CCI Object-Type TBD13 591 Reserved: is set to zero while sending, ignored on receipt. 593 Flags: is used to carry any additional information pertaining to the 594 CCI. Currently no flag bits are defined. 596 The Symbolic Path Name TLV [RFC8231] MUST be included in the CCI 597 Object-Type TBD13 to identify the E2E TE path in Native IP 598 environment and MUST be unique. 600 7.2. BGP Peer Info Object 602 The BGP Peer Info object is used to specify the information about the 603 peer that the PCC should establish the BGP relationship with. This 604 object should only be included and sent to the head and end router of 605 the E2E path in case there is no Route Reflection (RR) involved. If 606 the RR is used between the head and end routers, then such 607 information should be sent to head router, RR and end router 608 respectively. 610 By default, there MUST be no prefix be distributed via such BGP 611 session that established by this object. 613 By default, the Local/Peer IP address SHOULD be dedicated to the 614 usage of native IP TE solution, and SHOULD NOT be used by other BGP 615 sessions that established by manual or non PCE initiated 616 configuration. 618 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 | 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 Reserved: is set to zero while sending, ignored on receipt.. 676 Local IP Address(4/16 Bytes): IP address of the local router, used to 677 peer with other end router. When Object-Type is 1, length is 4 678 bytes; when Object-Type is 2, length is 16 bytes. 680 Peer IP Address(4/16 Bytes): IP address of the peer router, used to 681 peer with the local router. When Object-Type is 1, length is 4 682 bytes; when Object-Type is 2, length is 16 bytes; 684 Additional TLVs: TLVs that associated with this object, can be used 685 to convey other necessary information for dynamic BGP session 686 establishment. Their definition are out of the current document. 688 When PCC receives BPI object, with Object-Type=1, it should try to 689 establish BGP session with the peer in AFI/SAFI=1/1; when PCC 690 receives BPI object with Object-Type=2, it should try to establish 691 the BGP session with the peer in AFI/SAFI=2/1. Other BGP 692 capabilities,for example, Graceful Restart(GR) that enhance the BGP 693 performance should also be negotiated and used by default. 695 7.3. Explicit Peer Route Object 697 The Explicit Peer Route object is defined to specify the explicit 698 peer route to the corresponding peer address on each device that is 699 on the E2E assurance path. This Object should be sent to all the 700 devices that locates on the E2E assurance path that calculated by 701 PCE. 703 The path established by this object should have higher priority than 704 other path calculated by dynamic IGP protocol, but should be lower 705 priority than the static route configured by manual or NETCONF or by 706 other means. 708 Explicit Peer Route Object-Class is TBD15. 710 Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6 712 The format of Explicit Peer Route object body for IPv4(Object-Type=1) 713 is as follows: 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Route Priority | Reserved | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | IPv4 Peer Address | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Next Hop Address to the IPv4 Peer Address | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Additional TLVs | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Figure 8: Explicit Peer Route Object Body Format for IPv4 728 The format of Explicit Peer Route object body for IPv6(Object-Type=2) 729 is as follows: 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Route Priority | Reserved | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | | 737 + + 738 | IPv6 Peer Address | 739 + + 740 | | 741 + + 742 | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | 745 + + 746 | Next Hop Address to the IPv6 Peer Address | 747 + + 748 | | 749 + + 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Additional TLVs | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 9: Explicit Peer Route Object Body Format for IPv6 756 Route Priority: 2 Bytes, The priority of this explicit route. The 757 higher priority should be preferred by the device. This field is 758 used to indicate the backup path at each hop. 760 Reserved.: is set to zero while sending, ignored on receipt. 762 Peer Address: To indicate the peer address. 764 Next Hop Address to the Peer: To indicate the next hop address to the 765 corresponding peer. 767 Additional TLVs: TLVs that associated with this object, can be used 768 to convey other necessary information for explicit peer path 769 establishment. Its definition is out of the current document. 771 7.4. Peer Prefix Advertisement Object 773 The Peer Prefix Advertisement object is defined to specify the IP 774 prefixes that should be advertised to the corresponding peer. This 775 object should only be included and sent to the head/end router of the 776 end2end path. 778 The prefixes information included in this object MUST only be 779 advertised to the indicated peer, MUST NOT be advertised to other BGP 780 peers. 782 Peer Prefix Advertisement Object-Class is TBD16 784 Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for IPv6 786 The format of the Peer Prefix Advertisement object body is as 787 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 Advertisement 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 Advertisement 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. BGP Considerations 851 This draft defines the procedures and objects to create the BGP 852 sessions and advertises the associated prefixes dynamically. Only 853 the key information, for example peer IP addresses, peer AS number 854 are exchanged via the PCEP protocol. Other parameters that are 855 needed for the BGP session setup should be derived from their default 856 values, as described in Section 7.2. Upon receives such key 857 information, the BGP module on the PCC should try to accomplish the 858 task that appointed by the PCEP protocol and report the status to the 859 PCEP modules. 861 There is no influence to current implementation of BGP Finite State 862 Machine(FSM). The PCEP cares only the success and failure status of 863 BGP session, and act upon such information accordingly. 865 10. New Error-Types and Error-Values Defined 867 A PCEP-ERROR object is used to report a PCEP error and is 868 characterized by an Error-Type that specifies that type of error and 869 an Error-value that provides additional information about the error. 870 An additional Error-Type and several Error-values are defined to 871 represent some the errors related to the newly defined objects, which 872 are related to Native IP TE procedures. 874 +============+===============+==============================+ 875 | Error-Type | Meaning | Error-value | 876 +============+===============+=====================================+ 877 | TBD6 | Native IP | | 878 | | TE failure | | 879 +------------+---------------+-------------------------------------+ 880 | | | 0: Unassigned | 881 +------------+---------------+-------------------------------------+ 882 | | |TBD7: Peer AS not match | 883 +------------+---------------+-------------------------------------+ 884 | | |TBD8:Peer IP can't be reached | 885 +------------+---------------+-------------------------------------+ 886 | | |TBD9:Local IP is in use | 887 +------------+---------------+-------------------------------------+ 888 | | |TBD10:Remote IP is in use | 889 +------------+---------------+-------------------------------------+ 890 | | |TBD11:Exist BGP session broken | 891 +------------+---------------+-------------------------------------+ 892 | | |TBD12:Explicit Peer Route Error | 893 +------------+---------------+-------------------------------------+ 894 | | |TBD17:EPR/BPI Peer Info mismatch | 895 +------------+---------------+-------------------------------------+ 896 | | |TBD18:BPI/PPA Address Family mismatch| 897 +------------+---------------+-------------------------------------+ 898 | | |TBD19:PPA/BPI Peer Info mismatch | 899 +------------+---------------+-------------------------------------+ 901 Figure 12: Newly defined Error-Type and Error-Value 903 11. Deployment Considerations 905 The information transferred in this draft is mainly used for the 906 light weight BGP session setup, explicit route deployment and the 907 prefix distribution. The planning, allocation and distribution of 908 the peer addresses within IGP should be accomplished in advanced and 909 they are out of the scope of this draft. 911 [RFC8232] describes the state synchronization procedure between 912 stateful PCE and PCC. The communication of PCE and PCC described in 913 this draft should also follow this procedures, treat the three newly 914 defined objects that associated with the same symbolic path name as 915 the attribute of the same path in the LSP-DB. 917 When PCE detects one or some of the PCCs are out of control, it 918 should recompute and redeploy the traffic engineering path for native 919 IP on the active PCCs. When PCC detects that it is out of control of 920 the PCE, it should clear the information that initiated by the PCE. 922 The PCE should assures the avoidance of possible transient loop in 923 such node failure when it deploy the explicit peer route on the PCCs. 925 If the established BGP session is broken after some time, the PCC 926 should also report such error via PCErr message with Err-type=TBD6 927 and error value(Error-value=TBD11, Existing BGP session is broken). 928 Upon receiving such PCErr message, the PCE should clear the prefixes 929 advertisement on the previous BGP session, clear the explicit peer 930 route to the previous peer address; select other Local_IP/Peer_IP 931 pair to establish the new BGP session, deploy the explicit peer route 932 to the new peer address, and advertises the prefixes on the new BGP 933 session. 935 12. Security Considerations 937 The setup of BGP sessions, prefix advertisement, and explicit peer 938 route establishment are all controlled by the PCE. See [RFC4271] and 939 [RFC4272] for BGP security considerations. Security consideration 940 part in [RFC5440] and [RFC8231] should be considered. To prevent a 941 bogus PCE sending harmful messages to the network nodes, the network 942 devices should authenticate the validity of the PCE and ensure a 943 secure communication channel between them. Mechanisms described in 944 [RFC8253] should be used. 946 13. IANA Considerations 948 13.1. Path Setup Type Registry 950 [RFC8408] created a sub-registry within the "Path Computation Element 951 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 952 IANA is requested to allocate a new code point within this registry, 953 as follows: 955 Value Description Reference 956 TBD1 Native IP TE Path This document 958 13.2. PCECC-CAPABILITY sub-TLV's Flag field 960 [I-D.ietf-pce-pcep-extension-for-pce-controller] created a sub- 961 registry within the "Path Computation Element Protocol (PCEP) 962 Numbers" registry to manage the value of the PCECC-CAPABILITY sub- 963 TLV's 32-bits Flag field. IANA is requested to allocate a new bit 964 position within this registry, as follows: 966 Value Description Reference 967 TBD2(N) NATIVE-IP-TE-CAPABILITY This document 969 13.3. PCEP Object Types 971 IANA is requested to allocate new registry for the PCEP Object Type: 973 Object-Class Value Name Reference 974 TBD13 CCI Object This document 975 Object-Type 976 TBD: Native IP 978 TBD14 BGP Peer Info This document 979 Object-Type 980 1: IPv4 address 981 2: IPv6 address 983 TBD15 Explicit Peer Route This document 984 Object-Type 985 1: IPv4 address 986 2: IPv6 address 988 TBD16 Peer Prefix Advertisement This document 989 Object-Type 990 1: IPv4 address 991 2: IPv6 address 993 13.4. PCEP-Error Object 995 IANA is requested to allocate new error types and error values within 996 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 997 PCEP Numbers registry for the following errors:: 999 Error-Type Meaning Error-value Reference 1000 6 Mandatory Object missing 1001 TBD4:Native IP object missing This document 1003 10 Reception of an invalid object 1004 TBD3:PCECC NATIVE-IP-TE-CAPABILITY bit is not set This document 1006 19 Invalid Operation 1007 TBD5:Only one of the BPI,EPR or PPA object can be included in this message This document 1009 TBD6 Native IP TE failure This document 1010 TBD7:Peer AS not match 1011 TBD8:Peer IP can't be reached 1012 TBD9:Local IP is in use 1013 TBD10:Remote IP is in use 1014 TBD11:Exist BGP session broken 1015 TBD12:Explicit Peer Route Error 1016 TBD17:EPR/BPI Peer Info mismatch 1017 TBD18:BPI/PPA Address Family mismatch 1018 TBD19:PPA/BPI Peer Info mismatch 1020 14. Contributor 1022 Dhruv Dhody has contributed the contents of this draft. 1024 15. Acknowledgement 1026 Thanks Mike Koldychev, Siva Sivabalan, Adam Simpson for his valuable 1027 suggestions and comments. 1029 16. Normative References 1031 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1032 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1033 Procedures and Protocol Extensions for Using PCE as a 1034 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1035 extension-for-pce-controller-10 (work in progress), 1036 January 2021. 1038 [I-D.ietf-teas-pce-native-ip] 1039 Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "Path 1040 Computation Element (PCE) based Traffic Engineering (TE) 1041 in Native IP Networks", draft-ietf-teas-pce-native-ip-16 1042 (work in progress), January 2021. 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Levels", BCP 14, RFC 2119, 1046 DOI 10.17487/RFC2119, March 1997, 1047 . 1049 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1050 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1051 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1052 . 1054 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1055 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1056 DOI 10.17487/RFC4271, January 2006, 1057 . 1059 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1060 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1061 . 1063 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1064 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1065 DOI 10.17487/RFC5440, March 2009, 1066 . 1068 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1069 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1070 May 2017, . 1072 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1073 Computation Element Communication Protocol (PCEP) 1074 Extensions for Stateful PCE", RFC 8231, 1075 DOI 10.17487/RFC8231, September 2017, 1076 . 1078 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1079 and D. Dhody, "Optimizations of Label Switched Path State 1080 Synchronization Procedures for a Stateful PCE", RFC 8232, 1081 DOI 10.17487/RFC8232, September 2017, 1082 . 1084 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1085 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1086 Path Computation Element Communication Protocol (PCEP)", 1087 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1088 . 1090 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1091 Computation Element Communication Protocol (PCEP) 1092 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1093 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1094 . 1096 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1097 Architecture for Use of PCE and the PCE Communication 1098 Protocol (PCEP) in a Network with Central Control", 1099 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1100 . 1102 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1103 Hardwick, "Conveying Path Setup Type in PCE Communication 1104 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1105 July 2018, . 1107 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1108 Dhody, D., and Y. Tanaka, "Path Computation Element 1109 Communication Protocol (PCEP) Extensions for Establishing 1110 Relationships between Sets of Label Switched Paths 1111 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1112 . 1114 [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, 1115 "Scenarios and Simulation Results of PCE in a Native IP 1116 Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, 1117 . 1119 Authors' Addresses 1121 Aijun Wang 1122 China Telecom 1123 Beiqijia Town, Changping District 1124 Beijing, Beijing 102209 1125 China 1127 Email: wangaj3@chinatelecom.cn 1129 Boris Khasanov 1130 Yandex LLC 1131 Ulitsa Lva Tolstogo 16 1132 Moscow 1133 Russia 1135 Email: bhassanov@yahoo.com 1136 Sheng Fang 1137 Huawei Technologies,Co.,Ltd 1138 Huawei Bld., No.156 Beiqing Rd. 1139 Beijing 1140 China 1142 Email: fsheng@huawei.com 1144 Ren Tan 1145 Huawei Technologies,Co.,Ltd 1146 Huawei Bld., No.156 Beiqing Rd. 1147 Beijing 1148 China 1150 Email: tanren@huawei.com 1152 Chun Zhu 1153 ZTE Corporation 1154 50 Software Avenue, Yuhua District 1155 Nanjing, Jiangsu 210012 1156 China 1158 Email: zhu.chun1@zte.com.cn