idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-15.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], [RFC8821]), 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 (27 July 2021) is 1003 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) ** 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 ** Downref: Normative reference to an Informational RFC: RFC 8821 Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 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: 28 January 2022 Yandex LLC 6 S. Fang 7 R. Tan 8 Huawei Technologies,Co.,Ltd 9 C. Zhu 10 ZTE Corporation 11 27 July 2021 13 PCEP Extension for Native IP Network 14 draft-ietf-pce-pcep-extension-native-ip-15 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 [RFC8821]. This 22 draft describes the key information that is transferred between Path 23 Computation Element (PCE) and Path Computation Clients (PCC) to 24 accomplish the End to End (E2E) traffic assurance in Native IP 25 network under central control mode. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 28 January 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Capability Advertisemnt . . . . . . . . . . . . . . . . . . . 4 64 4.1. Open message . . . . . . . . . . . . . . . . . . . . . . 4 65 5. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5.1. The PCInitiate message . . . . . . . . . . . . . . . . . 5 67 5.2. The PCRpt message . . . . . . . . . . . . . . . . . . . . 6 68 6. PCECC Native IP TE Procedures . . . . . . . . . . . . . . . . 7 69 6.1. BGP Session Establishment Procedures . . . . . . . . . . 7 70 6.2. Explicit Route Establish Procedures . . . . . . . . . . . 9 71 6.3. BGP Prefix Advertisement Procedures . . . . . . . . . . . 12 72 7. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 14 75 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 76 7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 19 77 8. End to End Path Protection . . . . . . . . . . . . . . . . . 21 78 9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21 79 10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 11. New Error-Types and Error-Values Defined . . . . . . . . . . 22 81 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 84 14.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 24 85 14.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 24 86 14.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 24 87 14.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 25 88 15. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 25 89 16. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 90 17. Normative References . . . . . . . . . . . . . . . . . . . . 25 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 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. In Segment Routing either IGP extensions 100 or BGP are used to steer a packet through an SR Policy instantiated 101 as an ordered list of instructions called "segments". But in native 102 IP network, there will be no such signaling protocol to synchronize 103 the action among different network devices. It is necessary to use 104 the central control mode that described in [RFC8283] to correlate the 105 forwarding behavior among different network devices. [RFC8821] 106 describes the architecture and solution philosophy for the E2E 107 traffic assurance in Native IP network via Multi Border Gateway 108 Protocol (BGP) solution. This draft describes the corresponding Path 109 Computation Element Communication Protocol (PCEP) extensions to 110 transfer the key information about BGP peer info, peer prefix 111 advertisement and the explicit peer route on on-path routers. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 3. Terminology 123 This document uses the following terms defined in [RFC5440]: PCE, 124 PCEP 126 The following terms are defined in this document: 128 * CCDR: Central Control Dynamic Routing 130 * E2E: End to End 132 * BPI: BGP Peer Info 134 * EPR: Explicit Peer Route 136 * PPA: Peer Prefix Advertisement 138 * QoS: Quality of Service 140 4. Capability Advertisemnt 142 4.1. Open message 144 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 145 advertise their support of Native IP extensions. 147 This document defines a new Path Setup Type (PST) [RFC8408] for 148 Native-IP, as follows: 150 * PST = TBD1: Path is a Native IP path as per [RFC8821]. 152 A PCEP speaker MUST indicate its support of the function described in 153 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 154 object with this new PST included in the PST list. 156 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 157 CAPABILITY sub-TLV to exchange information about their PCECC 158 capability. A new flag is defined in PCECC-CAPABILITY sub-TLV for 159 Native IP: 161 N (NATIVE-IP-TE-CAPABILITY - 1 bit - TBD2): If set to 1 by a PCEP 162 speaker, it indicates that the PCEP speaker is capable for TE in 163 Native IP network as specified in this document. The flag MUST be 164 set by both the PCC and PCE in order to support this extension. 166 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 167 the newly defined path setup type, but without the N bit set in 168 PCECC-CAPABILITY sub-TLV, it MUST: 170 * Send a PCErr message with Error-Type=10(Reception of an invalid 171 object) and Error-Value TBD3(PCECC NATIVE-IP-TE-CAPABILITY bit is 172 not set). 174 * Terminate the PCEP session 176 5. PCEP messages 178 PCECC Native IP TE solution utilizing the existing PCE LSP Initate 179 Request message(PCInitiate)[RFC8281], and PCE Report message(PCRpt) 180 [RFC8281] to accomplish the multi BGP sessions establishment, E2E TE 181 path deployment, and route prefixes advertisement among different BGP 182 sessions. A new PST for Native-IP is used to indicate the path setup 183 based on TE in Native IP networks. 185 The extended PCInitiate message described in 186 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 187 or cleanup central controller's instructions (CCIs). 189 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 190 called CCI for the encoding of central controller's instructions. 191 This document specify a new CCI object-type for Native IP. The PCEP 192 messages are extended in this document to handle the PCECC operations 193 for Native IP. Three new PCEP Objects (BGP Peer Info (BPI) Object, 194 Explicit Peer Route (EPR) Object and Peer Prefix Advertisement (PPA) 195 Object) are defined in this document. Refer toSection 7 for detail 196 object definitions. 198 5.1. The PCInitiate message 200 The PCInitiate Message defined in [RFC8281] and extended in 201 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 202 to support Native-IP CCI. 204 The format of the extended PCInitiate message is as follows: 206 ::= 207 208 Where: 209 is defined in [RFC5440] 211 ::= 212 [] 214 ::= 215 (| 216 | 217 ) 219 ::= 220 221 (| 222 ((||) 223 )) 225 ::= 226 [] 228 Where: 229 is as per 230 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 231 and 232 are as per 233 [RFC8281]. 235 The LSP and SRP objects are defined in [RFC8231]. 237 When PCInitiate message is used create Native IP instructions, the 238 SRP, LSP and CCI objects MUST be present. The error handling for 239 missing SRP, LSP or CCI object is as per 240 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one 241 of BPI, EPR, or PPA object MUST be present. The PLSP-ID within the 242 LSP object should be set by PCC uniquely according to the Symbolic 243 Path Name TLV that included in the CCI object. The Symbolic Path 244 Name is used by the PCE/PCC to identify uniquely the E2E native IP TE 245 path. 247 If none of them are present, the receiving PCC MUST send a PCErr 248 message with Error-type=6 (Mandatory Object missing) and Error- 249 value=TBD4 (Native IP object missing). If there are more than one of 250 BPI, EPR or PPA object are presented, the receiving PCC MUST send a 251 PCErr message with Error-type=19(Invalid Operation) and Error- 252 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 253 this message). 255 To cleanup the SRP object must set the R (remove) bit. 257 5.2. The PCRpt message 259 The PCRpt message is used to acknowledge the Native-IP instructions 260 received from the central controller (PCE). 262 The format of the PCRpt message is as follows: 264 ::= 265 266 Where: 268 ::= [] 270 ::= (| 271 ) 273 ::= [] 274 275 277 ::= [] 278 279 (| 280 ((||) 281 )) 283 Where: 284 is as per [RFC8231] and the LSP and SRP object are 285 also defined in [RFC8231]. 287 The error handling for missing CCI object is as per 288 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further only one 289 of BPI, EPR, or PPA object MUST be present. 291 If none of them are present, the receiving PCE MUST send a PCErr 292 message with Error-type=6 (Mandatory Object missing) and Error- 293 value=TBD4 ( Native IP object missing). If there are more than one 294 of BPI, EPR or PPA object are presented, the receiving PCE MUST send 295 a PCErr message with Error-type=19(Invalid Operation) and Error- 296 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 297 this message). 299 6. PCECC Native IP TE Procedures 301 The detail procedures for the TE in native IP environment are 302 described in the following sections. 304 6.1. BGP Session Establishment Procedures 306 The procedures for establishing the BGP session between two peers by 307 using the PCInitiate and PCRpt message pair is shown below. 309 The PCInitiate message should be sent to PCC which acts as BGP router 310 and/or route reflector(RR). 312 In the example in Figure 1, if the router R1 and R7 are within one AS 313 and R3 acts as the route reflector, PCInitiate message should be sent 314 to route reflector clients R1(M1) and R7(M4), and the route reflector 315 R3(M2 & M3) respectively. For inter-AS scenario, such message can be 316 sent directly to the ASBR router to build EBGP session. 318 PCInitiate message creates an auto-configuration function for these 319 BGP peers providing the indicated Peer AS and the Local/Peer IP 320 Address. 322 When PCC receives the BPI and CCI object (with the R bit set to 0 in 323 SRP object) in PCInitiate message, the PCC should try to establish 324 the BGP session with the indicated Peer AS and Local/Peer IP address. 326 When PCC creates successfully the BGP session that is indicated by 327 the associated information, it should report the result via the PCRpt 328 messages, with BPI object and the corresponding SRP and CCI object 329 included. 331 When PCC receives this message with the R bit set to 1 in SRP object 332 in PCInitiate message, the PCC should clear the BGP session that 333 indicated by the BPI object. 335 When PCC clears successfully the specified BGP session, it should 336 report the result via the PCRpt message, with the BPI object 337 included, and the corresponding SRP and CCI object. 339 +------------------+ 340 +-----------+ PCE +----------+ 341 | +--------^---------+ | 342 | | | 343 M2/M2-R & M3/M3-R 344 | | | 345 | +---v---+ | 346 +---------------+ R3(RR)+-----------------+ 347 | +-------+ | 348 M1/M1-R M4/M4-R 349 | | 350 +v-+ +--+ +--+ +-v+ 351 |R1+----------+R5+----------+R6+---------+R7| 352 ++-+ +--+ +--+ +-++ 353 | | 354 | +--+ +--+ | 355 +------------+R2+----------+R4+-----------+ 356 +--+ +--+ 357 Figure 1: BGP Session Establishment Procedures(R3 act as RR) 359 The message number, message peers, message type and message key 360 parameters in the above figures are shown in below table: 362 Table 1: Message Information 363 +-------------------------------------------------------------+ 364 | No.| Peers| Type | Message Key Parameters | 365 +-------------------------------------------------------------+ 366 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 367 |M1-R| |PCRpt |BPI Object(Local_IP=R1_A,Peer_IP=R3_A)| 368 +-------------------------------------------------------------+ 369 |M2 |PCE/R3|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 370 |M2-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R1_A)| 371 +-------------------------------------------------------------+ 372 |M3 |PCE/R3|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 373 |M3-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R7_A)| 374 +-------------------------------------------------------------+ 375 |M4 |PCE/R7|PCInitiate|CC-ID=X4(Symbolic Path Name=Class A) | 376 |M4-R| |PCRpt |BPI Object(Local_IP=R7_A,Peer_IP=R3_A)| 377 +-------------------------------------------------------------+ 379 If the PCC cannot establish the BGP session that required by this 380 object, it should report the error values via PCErr message with the 381 newly defined error type(Error-type=TBD6) and error value(Error- 382 value=TBD7, Peer AS not match; or Error-Value=TBD8, Peer IP can't be 383 reached), which is indicated in Section 11 385 If the Local IP Address or Peer IP Address within BPI object is used 386 in other existing BGP sessions, the PCC should report such error 387 situation via PCErr message with Err-type=TBD6 and error value(Error- 388 value=TBD9, Local IP is in use; Error-value=TBD10, Remote IP is in 389 use). 391 6.2. Explicit Route Establish Procedures 393 The detail procedures for the explicit route establishment procedures 394 is shown below, using PCInitiate and PCRpt message pair. 396 The PCInitiate message should be sent to the on-path routers 397 respectively. In the example, for explicit route from R1 to R7, the 398 PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as 399 shown in Figure 2. For explicit route from R7 to R1, the PCInitiate 400 message should be sent to R7(M1), R4(M2) and R2(M3), as shown in 401 Figure 3. 403 When PCC receives the EPR and the CCI object (with the R bit set to 0 404 in SRP object) in PCInitiate message, the PCC should install the 405 explicit route to the the peer. 407 When PCC install successfully the explicit route to the peer, it 408 should report the result via the PCRpt messages, with EPR object and 409 the corresponding SRP and CCI object included. 411 When PCC receives the EPR and the CCI object with the R bit set to 1 412 in SRP object in PCInitiate message, the PCC should clear the 413 explicit route to the peer that indicated by the EPR object. 415 When PCC clear successfully the explicit route that indicated by this 416 object, it should report the result via the PCRpt message, with the 417 EPR object included, and the corresponding SRP and CCI object. 419 +------------------+ 420 +----------+ PCE + 421 | +----^-----------^-+ 422 | | | 423 | | | 424 | | +------+ | 425 +-----------------+R3(RR)+--|-------------+ 426 M1/M1-R | +------+ | | 427 | | | | 428 +v-+ +--+ | | +--+ +--+ 429 |R1+------+R5+---+-----------|---+R6+----+R7| 430 ++-+ +--+ | | +--+ +-++ 431 | M2/M2-R M3/M3-R | 432 | | | | 433 | +--v--+ +--v-+ | 434 +------------+- R2 +-----+ R4 +-----------+ 435 +--+--+ +--+-+ 436 Figure 2: Explicit Route Establish Procedures(From R1 to R7) 438 The message number, message peers, message type and message key 439 parameters in the above figures are shown in below table: 441 Table 2: Message Information 442 +------------------------------------------------------------------+ 443 | No.|Peers | Type | Message Key Parameters | 444 +------------------------------------------------------------------+ 445 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 446 |M1-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R2_A)| 447 +------------------------------------------------------------------+ 448 |M2 |PCE/R2|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 449 |M2-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R4_A)| 450 +------------------------------------------------------------------+ 451 |M3 |PCE/R4|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 452 |M3-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R7_A)| 453 +------------------------------------------------------------------+ 454 +------------------+ 455 + PCE +-----------+ 456 +----^-----------^-+ | 457 | | | 458 | | | 459 | +------+ | | 460 +-----------------+R3(RR)+--|-------------+ 461 | | +------+ | M1/M1-R 462 | | | | 463 +--+ +--+ | | +--+ +-v+ 464 |R1+------+R5+---+-----------|---+R6+----+R7| 465 ++-+ +--+ | | +--+ +-++ 466 | M3/M3-R M2/M2-R | 467 | | | | 468 | +--v--+ +--v-+ | 469 +------------+- R2 +-----+ R4 +-----------+ 470 +--+--+ +--+-+ 471 Figure 3: Explicit Route Establish Procedures(From R7 to R1) 473 The message number, message peers, message type and message key 474 parameters in the above figures are shown in below table: 476 Table 3: Message Information 477 +------------------------------------------------------------------+ 478 |No. |Peers | Type | Message Key Parameters | 479 +------------------------------------------------------------------+ 480 |M1 |PCE/R7|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 481 |M1-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R4_A)| 482 +------------------------------------------------------------------+ 483 |M2 |PCE/R4|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 484 |M2-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R2_A)| 485 +------------------------------------------------------------------+ 486 |M3 |PCE/R2|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 487 |M3-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R1_A)| 488 +------------------------------------------------------------------+ 490 In order to avoid the transient loop during the deploy of explicit 491 peer route, the EPR object should be sent to the PCCs in the reverse 492 order of the E2E path. To remove the explicit peer route, the EPR 493 object should be sent to the PCCs in the same order of E2E path. 495 To accomplish ECMP effects, the PCE can send multiple EPR objects to 496 the same node, with the same route priority and peer address value 497 but different next hop addresses. 499 The PCC should verify that the next hop address is reachable. Upon 500 the error occurs, the PCC SHOULD send the corresponding error via 501 PCErr message, with an error information (Error-type=TBD6, Error- 502 value=TBD12, Explicit Peer Route Error) that defined in Section 11. 504 When the peer info is not the same as the peer info that indicated in 505 BPI object in PCC for the same path that is identified by Symbolic 506 Path Name TLV, an error (Error-type=TBD6, Error-value=17, EPR/BPI 507 Peer Info mismatch) should be reported via the PCErr message. 509 6.3. BGP Prefix Advertisement Procedures 511 The detail procedures for BGP prefix advertisement are shown below, 512 using PCInitiate and PCRpt message pair. 514 The PCInitiate message should be sent to PCC that acts as BGP peer 515 router only. In the example, it should be sent to R1(M1) or R7(M2) 516 respectively. 518 When PCC receives the PPA and the CCI object (with the R bit set to 0 519 in SRP object) in PCInitiate message, the PCC should send the 520 prefixes indicated in this object to the appointed BGP peer. 522 When PCC sends successfully the prefixes to the appointed BGP peer, 523 it should report the result via the PCRpt messages, with PPA object 524 and the corresponding SRP and CCI object included. 526 When PCC receives the PPA and the CCI object with the R bit set to 1 527 in SRP object in PCInitiate message, the PCC should withdraw the 528 prefixes advertisement to the peer that indicated by this object. 530 When PCC withdraws successfully the prefixes that indicated by this 531 object, it should report the result via the PCRpt message, with the 532 PPA object included, and the corresponding SRP and CCI object. 534 The allowed AFI/SAFI for the IPv4 BGP session should be 1/1(IPv4 535 prefix) and the allowed AFI/SAFI for the IPv6 BGP session should be 536 2/1(IPv6 prefix). If mismatch occur, an error(Error-type=TBD6, 537 Error-value=TBD18, BPI/PPR address family mismatch) should be 538 reported via PCErr message. 540 When the peer info is not the same as the peer info that indicated in 541 BPI object in PCC for the same path that is identified by Symbolic 542 Path Name TLV, an error (Error-type=TBD6, Error-value=TBD19, PPA/BPI 543 peer info mismatch) should be reported via the PCErr message. 545 +------------------+ 546 +----------+ PCE +-----------+ 547 | +------------------+ | 548 | +--+ | 549 +------------------+R3+-------------------+ 550 M1&M1-R +--+ M2&M2-R 551 | | 552 +v-+ +--+ +--+ +-v+ 553 |R1+----------+R5+----------+R6+---------+R7| 554 ++-+ +--+ +--+ +-++ 555 | | 556 | | 557 | +--+ +--+ | 558 +------------+R2+----------+R4+-----------+ 559 Figure 4: BGP Prefix Advertisement Procedures 561 Table 4: Message Information 562 +-----------------------------------------------------------+ 563 |No. | Peers| Type | Message Key Parameters | 564 +-----------------------------------------------------------+ 565 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A)| 566 |M1-R| |PCRpt |PPA Object(Peer IP=R7_A,Prefix=1_A) | 567 +-----------------------------------------------------------+ 568 |M2 |PCE/R7|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A)| 569 |M2-R| |PCRpt |PPA Object(Peer IP=R1_A,Prefix=7_A) | 570 +-----------------------------------------------------------+ 572 7. New PCEP Objects 574 One new CCI Object and three new PCEP objects are defined in this 575 draft. All new PCEP objects are as per [RFC5440] 577 7.1. CCI Object 579 The Central Control Instructions (CCI) Object is used by the PCE to 580 specify the forwarding instructions is defined in 581 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 582 defines another object-type for Native-IP. 584 CCI Object-Type is TBD13 for Native-IP as below 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | CC-ID | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Reserved | Flags | 591 +---------------------------------------------------------------+ 592 | | 593 // Optional TLV // 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Figure 5: CCI Object for Native IP 599 Figure 1 601 The field CC-ID is as described in 602 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following fields 603 are defined for CCI Object-Type TBD13 605 Reserved: is set to zero while sending, ignored on receipt. 607 Flags: is used to carry any additional information pertaining to the 608 CCI. Currently no flag bits are defined. 610 The Symbolic Path Name TLV [RFC8231] MUST be included in the CCI 611 Object-Type TBD13 to identify the E2E TE path in Native IP 612 environment and MUST be unique. 614 7.2. BGP Peer Info Object 616 The BGP Peer Info object is used to specify the information about the 617 peer that the PCC should establish the BGP relationship with. This 618 object should only be included and sent to the head and end router of 619 the E2E path in case there is no Route Reflection (RR) involved. If 620 the RR is used between the head and end routers, then such 621 information should be sent to head router, RR and end router 622 respectively. 624 By default, there MUST be no prefix be distributed via such BGP 625 session that established by this object. 627 By default, the Local/Peer IP address SHOULD be dedicated to the 628 usage of native IP TE solution, and SHOULD NOT be used by other BGP 629 sessions that established by manual or non PCE initiated 630 configuration. 632 BGP Peer Info Object-Class is TBD14 633 BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 635 The format of the BGP Peer Info object body for IPv4(Object-Type=1) 636 is as follows: 638 0 1 2 3 639 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Peer AS Number | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | ETTL | Reserved |T| 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Local IP Address | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Peer IP Address | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Tunnel Source IP Address | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Tunnel Destination IP Address | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Additional TLVs | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 Figure 6: BGP Peer Info Object Body Format for IPv4 657 The format of the BGP Peer Info object body for IPv6(Object-Type=2) 658 is as follows: 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Peer AS Number | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | ETTL | Reserved |T| 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | | 668 + + 669 | Local IP Address (16 bytes) | 670 + + 671 | | 672 + + 673 | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | | 676 + + 677 | Peer IP Address (16 bytes) | 678 + + 679 | | 680 + + 681 | | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | | 684 + + 685 | Tunnel Source IP Address (16 bytes) | 686 + + 687 | | 688 + + 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | | 692 + + 693 | Tunnel Destination IP Address (16 bytes) | 694 + + 695 | | 696 + + 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Additional TLVs | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Figure 7: BGP Peer Info Object Body Format for IPv6 703 Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. 705 ETTL: 1 Byte, to indicate the multihop count for EBGP session. It 706 should be 0 and ignored when Local AS and Peer AS is same. 708 Reserved: is set to zero while sending, ignored on receipt. 710 T bit: Indicates whether the traffic that associated with the 711 prefixes advertised via this BGP session is transported via IPinIP 712 tunnel (when T bit is set) or not (when T bit is clear). 714 Local IP Address(4/16 Bytes): IP address of the local router, used to 715 peer with other end router. When Object-Type is 1, length is 4 716 bytes; when Object-Type is 2, length is 16 bytes. 718 Peer IP Address(4/16 Bytes): IP address of the peer router, used to 719 peer with the local router. When Object-Type is 1, length is 4 720 bytes; when Object-Type is 2, length is 16 bytes; 722 Tunnel Source IP Address(4/16 Bytes): IP address of the tunnel 723 source, should be owned by the local router. When Object-Type is 1, 724 length is 4 bytes; when Object-Type is 2, length is 16 bytes. 726 Tunnel Destination IP Address(4/16 Bytes): IP address of the tunnel 727 destination, should be owned by the peer router. When Object-Type is 728 1, length is 4 bytes; when Object-Type is 2, length is 16 bytes. 729 Should be different from the Peer IP Address. 731 Additional TLVs: TLVs that associated with this object, can be used 732 to convey other necessary information for dynamic BGP session 733 establishment. Their definition are out of the current document. 735 When PCC receives BPI object, with Object-Type=1, it should try to 736 establish BGP session with the peer in AFI/SAFI=1/1; when PCC 737 receives BPI object with Object-Type=2, it should try to establish 738 the BGP session with the peer in AFI/SAFI=2/1. Other BGP 739 capabilities,for example, Graceful Restart(GR) that enhance the BGP 740 performance should also be negotiated and used by default. 742 7.3. Explicit Peer Route Object 744 The Explicit Peer Route object is defined to specify the explicit 745 peer route to the corresponding peer address on each device that is 746 on the E2E assurance path. This Object should be sent to all the 747 devices that locates on the E2E assurance path that calculated by 748 PCE. 750 The path established by this object should have higher priority than 751 other path calculated by dynamic IGP protocol, but should be lower 752 priority than the static route configured by manual or NETCONF or by 753 other means. 755 Explicit Peer Route Object-Class is TBD15. 757 Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6 759 The format of Explicit Peer Route object body for IPv4(Object-Type=1) 760 is as follows: 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Route Priority | Reserved | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Peer/Tunnel Destination Address | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Next Hop Address to the Peer/Tunnel Destination Address | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Additional TLVs | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 Figure 8: Explicit Peer Route Object Body Format for IPv4 775 The format of Explicit Peer Route object body for IPv6(Object-Type=2) 776 is as follows: 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Route Priority | Reserved | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | | 784 + + 785 | Peer Address/Tunnel Destination Address | 786 + + 787 | | 788 + + 789 | | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | | 792 + + 793 | Next Hop Address to the Peer/Tunnel Destination Address | 794 + + 795 | | 796 + + 797 | | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Additional TLVs | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 Figure 9: Explicit Peer Route Object Body Format for IPv6 803 Route Priority: 2 Bytes, The priority of this explicit route. The 804 higher priority should be preferred by the device. This field is 805 used to indicate the backup path at each hop. 807 Reserved: is set to zero while sending, ignored on receipt. 809 Peer/Tunnel Destination Address: To indicate the peer address(4/16 810 Bytes). When T bit is set in the associated BPI object, use the 811 tunnel destination address in BPI object; when T bit is clear, use 812 the peer address in BPI object. 814 Next Hop Address to the Peer/Tunnel Destination Address: To indicate 815 the next hop address(4/16 Bytes) to the corresponding peer/tunnel 816 destination address. 818 Additional TLVs: TLVs that associated with this object, can be used 819 to convey other necessary information for explicit peer path 820 establishment. Their definitions are out of the current document. 822 7.4. Peer Prefix Advertisement Object 824 The Peer Prefix Advertisement object is defined to specify the IP 825 prefixes that should be advertised to the corresponding peer. This 826 object should only be included and sent to the head/end router of the 827 end2end path. 829 The prefixes information included in this object MUST only be 830 advertised to the indicated peer, MUST NOT be advertised to other BGP 831 peers. 833 Peer Prefix Advertisement Object-Class is TBD16 835 Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for IPv6 837 The format of the Peer Prefix Advertisement object body is as 838 follows: 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Peer IPv4 Address | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 // IPv4 Prefix subobjects // 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Additional TLVs | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 Figure 10: Peer Prefix Advertisement Object Body Format for IPv4 853 0 1 2 3 854 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 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Peer IPv6 Address | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | | 859 // IPv6 Prefix subobjects // 860 | | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Additional TLVs | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Figure 11: Peer Prefix Advertisement Object Body Format for IPv6 866 Peer IPv4 Address: 4 Bytes. Identifies the peer IPv4 address that 867 the associated prefixes will be sent to. 869 IPv4 Prefix subojects: List of IPv4 Prefix subobjects that defined in 870 [RFC3209], identify the prefixes that will be sent to the peer that 871 identified by Peer IPv4 Address List. 873 Peer IPv6 Address: 16 Bytes. Identifies the peer IPv6 address that 874 the associated prefixes will be sent to. 876 IPv6 Prefix subojects: List of IPv6 Prefix subobjects that defined in 877 [RFC3209], identify the prefixes that will be sent to the peer that 878 identified by Peer IPv6 Address List. 880 Additional TLVs: TLVs that associated with this object, can be used 881 to convey other necessary information for prefixes advertisement. 882 Their definitions are out of the current document. 884 8. End to End Path Protection 886 [RFC8697] defines the path associations procedures between sets of 887 Label Switched Path (LSP). Such procedures can also be used for the 888 E2E path protection. To accomplish this, the PCE should attach the 889 ASSOCIATION object with the EPR object in the PCInitiate message, 890 with the association type set to 1 (Path Protection Association). 891 The Extended Association ID that included within the Extended 892 Association ID TLV, which is included in the ASSOCIATION object, 893 should be set to the Symbolic Path Name of different E2E path. This 894 PCinitiate should be sent to the head-end of the E2E path. 896 The head-end of the path can use the existing path detection 897 mechanism(for example, Bidirectional Forwarding Detection [RFC5880]), 898 to monitor the status of the active path. Once it detects the 899 failure, it can switch the backup protection path immediately. 901 9. Re-Delegation and Clean up 903 In case of a PCE failure, a new PCE can gain control over the central 904 controller instructions. As per the PCEP procedures in [RFC8281], 905 the State Timeout Interval timer is used to ensure that a PCE failure 906 does not result in automatic and immediate disruption for the 907 services. Similarly, as per 908 [I-D.ietf-pce-pcep-extension-for-pce-controller], the central 909 controller instructions are not removed immediately upon PCE failure. 910 Instead, they could be re-delegated to the new PCE before the 911 expiration of this timer, or be cleaned up on the expiration of this 912 timer. The allows for network clean up without manual intervention. 913 The PCC MUST support the removal of CCI as one of the behaviors 914 applied on expiration of the State Timeout Interval timer. 916 10. BGP Considerations 918 This draft defines the procedures and objects to create the BGP 919 sessions and advertises the associated prefixes dynamically. Only 920 the key information, for example peer IP addresses, peer AS number 921 are exchanged via the PCEP protocol. Other parameters that are 922 needed for the BGP session setup should be derived from their default 923 values, as described in Section 7.2. Upon receives such key 924 information, the BGP module on the PCC should try to accomplish the 925 task that appointed by the PCEP protocol and report the status to the 926 PCEP modules. 928 There is no influence to current implementation of BGP Finite State 929 Machine(FSM). The PCEP cares only the success and failure status of 930 BGP session, and act upon such information accordingly. 932 The error handling procedures related to incorrect BGP parameters are 933 specified in Section 6.1, Section 6.2, and Section 6.3. The handling 934 of the dynamic BGP sessions and associated prefixes on PCE failure is 935 described in Section 9. 937 11. New Error-Types and Error-Values Defined 939 A PCEP-ERROR object is used to report a PCEP error and is 940 characterized by an Error-Type that specifies that type of error and 941 an Error-value that provides additional information about the error. 942 An additional Error-Type and several Error-values are defined to 943 represent some the errors related to the newly defined objects, which 944 are related to Native IP TE procedures. 946 +============+===============+==============================+ 947 | Error-Type | Meaning | Error-value | 948 +============+===============+=====================================+ 949 | TBD6 | Native IP | | 950 | | TE failure | | 951 +------------+---------------+-------------------------------------+ 952 | | | 0: Unassigned | 953 +------------+---------------+-------------------------------------+ 954 | | |TBD7: Peer AS not match | 955 +------------+---------------+-------------------------------------+ 956 | | |TBD8:Peer IP can't be reached | 957 +------------+---------------+-------------------------------------+ 958 | | |TBD9:Local IP is in use | 959 +------------+---------------+-------------------------------------+ 960 | | |TBD10:Remote IP is in use | 961 +------------+---------------+-------------------------------------+ 962 | | |TBD11:Exist BGP session broken | 963 +------------+---------------+-------------------------------------+ 964 | | |TBD12:Explicit Peer Route Error | 965 +------------+---------------+-------------------------------------+ 966 | | |TBD17:EPR/BPI Peer Info mismatch | 967 +------------+---------------+-------------------------------------+ 968 | | |TBD18:BPI/PPA Address Family mismatch| 969 +------------+---------------+-------------------------------------+ 970 | | |TBD19:PPA/BPI Peer Info mismatch | 971 +------------+---------------+-------------------------------------+ 973 Figure 12: Newly defined Error-Type and Error-Value 975 12. Deployment Considerations 977 The information transferred in this draft is mainly used for the 978 light weight BGP session setup, explicit route deployment and the 979 prefix distribution. The planning, allocation and distribution of 980 the peer addresses within IGP should be accomplished in advanced and 981 they are out of the scope of this draft. 983 [RFC8232] describes the state synchronization procedure between 984 stateful PCE and PCC. The communication of PCE and PCC described in 985 this draft should also follow this procedures, treat the three newly 986 defined objects that associated with the same symbolic path name as 987 the attribute of the same path in the LSP-DB. 989 When PCE detects one or some of the PCCs are out of control, it 990 should recompute and redeploy the traffic engineering path for native 991 IP on the active PCCs. When PCC detects that it is out of control of 992 the PCE, it should clear the information that initiated by the PCE. 993 The PCE should assures the avoidance of possible transient loop in 994 such node failure when it deploy the explicit peer route on the PCCs. 996 If the established BGP session is broken after some time, the PCC 997 should also report such error via PCErr message with Err-type=TBD6 998 and error value(Error-value=TBD11, Existing BGP session is broken). 999 Upon receiving such PCErr message, the PCE should clear the prefixes 1000 advertisement on the previous BGP session, clear the explicit peer 1001 route to the previous peer address; select other Local_IP/Peer_IP 1002 pair to establish the new BGP session, deploy the explicit peer route 1003 to the new peer address, and advertises the prefixes on the new BGP 1004 session. 1006 13. Security Considerations 1008 The setup of BGP sessions, prefix advertisement, and explicit peer 1009 route establishment are all controlled by the PCE. See [RFC4271] and 1010 [RFC4272] for BGP security considerations. Security consideration 1011 part in [RFC5440] and [RFC8231] should be considered. To prevent a 1012 bogus PCE sending harmful messages to the network nodes, the network 1013 devices should authenticate the validity of the PCE and ensure a 1014 secure communication channel between them. Mechanisms described in 1015 [RFC8253] should be used. 1017 14. IANA Considerations 1018 14.1. Path Setup Type Registry 1020 [RFC8408] created a sub-registry within the "Path Computation Element 1021 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1022 IANA is requested to allocate a new code point within this registry, 1023 as follows: 1025 Value Description Reference 1026 TBD1 Native IP TE Path This document 1028 14.2. PCECC-CAPABILITY sub-TLV's Flag field 1030 [I-D.ietf-pce-pcep-extension-for-pce-controller] created a sub- 1031 registry within the "Path Computation Element Protocol (PCEP) 1032 Numbers" registry to manage the value of the PCECC-CAPABILITY sub- 1033 TLV's 32-bits Flag field. IANA is requested to allocate a new bit 1034 position within this registry, as follows: 1036 Value Description Reference 1037 TBD2(N) NATIVE-IP-TE-CAPABILITY This document 1039 14.3. PCEP Object Types 1041 IANA is requested to allocate new registry for the PCEP Object Type: 1043 Object-Class Value Name Reference 1044 44 CCI Object This document 1045 Object-Type 1046 TBD13: Native IP 1048 TBD14 BGP Peer Info This document 1049 Object-Type 1050 1: IPv4 address 1051 2: IPv6 address 1053 TBD15 Explicit Peer Route This document 1054 Object-Type 1055 1: IPv4 address 1056 2: IPv6 address 1058 TBD16 Peer Prefix Advertisement This document 1059 Object-Type 1060 1: IPv4 address 1061 2: IPv6 address 1063 14.4. PCEP-Error Object 1065 IANA is requested to allocate new error types and error values within 1066 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1067 PCEP Numbers registry for the following errors:: 1069 Error-Type Meaning Error-value Reference 1070 6 Mandatory Object missing 1071 TBD4:Native IP object missing This document 1073 10 Reception of an invalid object 1074 TBD3:PCECC NATIVE-IP-TE-CAPABILITY bit is not set This document 1076 19 Invalid Operation 1077 TBD5:Only one of the BPI,EPR or PPA object can be included in this message This document 1079 TBD6 Native IP TE failure This document 1080 TBD7:Peer AS not match 1081 TBD8:Peer IP can't be reached 1082 TBD9:Local IP is in use 1083 TBD10:Remote IP is in use 1084 TBD11:Exist BGP session broken 1085 TBD12:Explicit Peer Route Error 1086 TBD17:EPR/BPI Peer Info mismatch 1087 TBD18:BPI/PPA Address Family mismatch 1088 TBD19:PPA/BPI Peer Info mismatch 1090 15. Contributor 1092 Dhruv Dhody has contributed the contents of this draft. 1094 16. Acknowledgement 1096 Thanks Mike Koldychev, Susan Hares, Siva Sivabalan, Adam Simpson for 1097 his valuable suggestions and comments. 1099 17. Normative References 1101 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1102 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 1103 "Path Computation Element Communication Protocol (PCEP) 1104 Procedures and Extensions for Using the PCE as a Central 1105 Controller (PCECC) of LSPs", Work in Progress, Internet- 1106 Draft, draft-ietf-pce-pcep-extension-for-pce-controller- 1107 14, 5 March 2021, . 1110 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1111 Requirement Levels", BCP 14, RFC 2119, 1112 DOI 10.17487/RFC2119, March 1997, 1113 . 1115 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1116 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1117 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1118 . 1120 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1121 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1122 DOI 10.17487/RFC4271, January 2006, 1123 . 1125 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1126 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1127 . 1129 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1130 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1131 DOI 10.17487/RFC5440, March 2009, 1132 . 1134 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1135 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1136 . 1138 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1139 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1140 May 2017, . 1142 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1143 Computation Element Communication Protocol (PCEP) 1144 Extensions for Stateful PCE", RFC 8231, 1145 DOI 10.17487/RFC8231, September 2017, 1146 . 1148 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1149 and D. Dhody, "Optimizations of Label Switched Path State 1150 Synchronization Procedures for a Stateful PCE", RFC 8232, 1151 DOI 10.17487/RFC8232, September 2017, 1152 . 1154 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1155 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1156 Path Computation Element Communication Protocol (PCEP)", 1157 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1158 . 1160 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1161 Computation Element Communication Protocol (PCEP) 1162 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1163 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1164 . 1166 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1167 Architecture for Use of PCE and the PCE Communication 1168 Protocol (PCEP) in a Network with Central Control", 1169 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1170 . 1172 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1173 Hardwick, "Conveying Path Setup Type in PCE Communication 1174 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1175 July 2018, . 1177 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1178 Dhody, D., and Y. Tanaka, "Path Computation Element 1179 Communication Protocol (PCEP) Extensions for Establishing 1180 Relationships between Sets of Label Switched Paths 1181 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1182 . 1184 [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, 1185 "Scenarios and Simulation Results of PCE in a Native IP 1186 Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, 1187 . 1189 [RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based 1190 Traffic Engineering (TE) in Native IP Networks", RFC 8821, 1191 DOI 10.17487/RFC8821, April 2021, 1192 . 1194 Authors' Addresses 1195 Aijun Wang 1196 China Telecom 1197 Beiqijia Town, Changping District 1198 Beijing 1199 Beijing, 102209 1200 China 1202 Email: wangaj3@chinatelecom.cn 1204 Boris Khasanov 1205 Yandex LLC 1206 Ulitsa Lva Tolstogo 16 1207 Moscow 1209 Email: bhassanov@yahoo.com 1211 Sheng Fang 1212 Huawei Technologies,Co.,Ltd 1213 Huawei Bld., No.156 Beiqing Rd. 1214 Beijing 1215 China 1217 Email: fsheng@huawei.com 1219 Ren Tan 1220 Huawei Technologies,Co.,Ltd 1221 Huawei Bld., No.156 Beiqing Rd. 1222 Beijing 1223 China 1225 Email: tanren@huawei.com 1227 Chun Zhu 1228 ZTE Corporation 1229 50 Software Avenue, Yuhua District 1230 Nanjing 1231 Jiangsu, 210012 1232 China 1234 Email: zhu.chun1@zte.com.cn