idnits 2.17.00 (12 Aug 2021) /tmp/idnits10453/draft-ietf-pce-pcep-extension-native-ip-18.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 document date (21 March 2022) is 54 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) == Missing Reference: 'I-D.ietf-pce-pcep-extension-for-pce-controller' is mentioned on line 227, but not defined == Missing Reference: 'RFC7942' is mentioned on line 1039, but not defined ** 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 (~~), 2 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: 22 September 2022 Yandex LLC 6 S. Fang 7 R. Tan 8 Huawei Technologies,Co.,Ltd 9 C. Zhu 10 ZTE Corporation 11 21 March 2022 13 PCEP Extension for Native IP Network 14 draft-ietf-pce-pcep-extension-native-ip-18 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 22 September 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 14 74 7.2. BGP Peer Info Object . . . . . . . . . . . . . . . . . . 15 75 7.3. Explicit Peer Route Object . . . . . . . . . . . . . . . 17 76 7.4. Peer Prefix Advertisement Object . . . . . . . . . . . . 20 77 8. End to End Path Protection . . . . . . . . . . . . . . . . . 21 78 9. Re-Delegation and Clean up . . . . . . . . . . . . . . . . . 21 79 10. BGP Considerations . . . . . . . . . . . . . . . . . . . . . 22 80 11. New Error-Types and Error-Values Defined . . . . . . . . . . 22 81 12. Deployment Considerations . . . . . . . . . . . . . . . . . . 23 82 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 24 83 13.1. Proof of Concept based on ODL . . . . . . . . . . . . . 24 84 14. Security Considerations . . . . . . . . . . . . . . . . . . . 25 85 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 86 15.1. Path Setup Type Registry . . . . . . . . . . . . . . . . 25 87 15.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 25 88 15.3. PCEP Object Types . . . . . . . . . . . . . . . . . . . 25 89 15.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 26 90 16. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 17. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 27 92 18. Normative References . . . . . . . . . . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 95 1. Introduction 97 Generally, Multiprotocol Label Switching Traffic Engineering (MPLS- 98 TE) requires the corresponding network devices support Multiprotocol 99 Label Switching (MPLS) or Resource ReSerVation Protocol (RSVP)/Label 100 Distribution Protocol (LDP) technologies to assure the End-to-End 101 (E2E) traffic performance. In Segment Routing either IGP extensions 102 or BGP are used to steer a packet through an SR Policy instantiated 103 as an ordered list of instructions called "segments". But in native 104 IP network, there will be no such signaling protocol to synchronize 105 the action among different network devices. It is necessary to use 106 the central control mode that described in [RFC8283] to correlate the 107 forwarding behavior among different network devices. [RFC8821] 108 describes the architecture and solution philosophy for the E2E 109 traffic assurance in Native IP network via Multi Border Gateway 110 Protocol (BGP) solution. This draft describes the corresponding Path 111 Computation Element Communication Protocol (PCEP) extensions to 112 transfer the key information about BGP peer info, peer prefix 113 advertisement and the explicit peer route on on-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 * CCDR: Central Control Dynamic Routing 132 * E2E: End to End 134 * BPI: BGP Peer Info 136 * EPR: Explicit Peer Route 138 * PPA: Peer Prefix Advertisement 140 * 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 * PST = TBD1: Path is a Native IP path as per [RFC8821]. 154 A PCEP speaker MUST indicate its support of the function described in 155 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 156 object with this new PST included in the PST list. 158 [RFC9050] defined the PCECC-CAPABILITY sub-TLV to exchange 159 information about their PCECC capability. A new flag is defined in 160 PCECC-CAPABILITY sub-TLV for Native IP: 162 N (NATIVE-IP-TE-CAPABILITY - 1 bit - TBD2): If set to 1 by a PCEP 163 speaker, it indicates that the PCEP speaker is capable for TE in 164 Native IP network as specified in this document. The flag MUST be 165 set by both the PCC and PCE in order to support this extension. 167 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 168 the newly defined path setup type, but without the N bit set in 169 PCECC-CAPABILITY sub-TLV, it MUST: 171 * Send a PCErr message with Error-Type=10(Reception of an invalid 172 object) and Error-Value TBD3(PCECC NATIVE-IP-TE-CAPABILITY bit is 173 not set). 175 * Terminate the PCEP session 177 5. PCEP messages 179 PCECC Native IP TE solution utilizing the existing PCE LSP Initate 180 Request message(PCInitiate)[RFC8281], and PCE Report message(PCRpt) 181 [RFC8281] to accomplish the multi BGP sessions establishment, E2E TE 182 path deployment, and route prefixes advertisement among different BGP 183 sessions. A new PST for Native-IP is used to indicate the path setup 184 based on TE in Native IP networks. 186 The extended PCInitiate message described in [RFC9050] is used to 187 download or cleanup central controller's instructions (CCIs). 188 [RFC9050] specifies an object called CCI for the encoding of central 189 controller's instructions. This document specify a new CCI object- 190 type for Native IP. The PCEP messages are extended in this document 191 to handle the PCECC operations for Native IP. Three new PCEP Objects 192 (BGP Peer Info (BPI) Object, Explicit Peer Route (EPR) Object and 193 Peer Prefix Advertisement (PPA) Object) are defined in this document. 194 Refer toSection 7 for detail object definitions. 196 5.1. The PCInitiate message 198 The PCInitiate Message defined in [RFC8281] and extended in [RFC9050] 199 is further extended to support Native-IP CCI. 201 The format of the extended PCInitiate message is as follows: 203 ::= 204 205 Where: 206 is defined in [RFC5440] 208 ::= 209 [] 211 ::= 212 (| 213 | 214 ) 216 ::= 217 218 (| 219 ((||) 220 )) 222 ::= 223 [] 225 Where: 226 is as per 227 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 228 and 229 are as per 230 [RFC8281]. 232 The LSP and SRP objects are defined in [RFC8231]. 234 When PCInitiate message is used create Native IP instructions, the 235 SRP, LSP and CCI objects MUST be present. The error handling for 236 missing SRP, LSP or CCI object is as per [RFC9050]. Further only one 237 of BPI, EPR, or PPA object MUST be present. The PLSP-ID within the 238 LSP object should be set by PCC uniquely according to the Symbolic 239 Path Name TLV that included in the CCI object. The Symbolic Path 240 Name is used by the PCE/PCC to identify uniquely the E2E native IP TE 241 path. 243 If none of them are present, the receiving PCC MUST send a PCErr 244 message with Error-type=6 (Mandatory Object missing) and Error- 245 value=TBD4 (Native IP object missing). If there are more than one of 246 BPI, EPR or PPA object are presented, the receiving PCC MUST send a 247 PCErr message with Error-type=19(Invalid Operation) and Error- 248 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 249 this message). 251 To cleanup the SRP object must set the R (remove) bit. 253 5.2. The PCRpt message 255 The PCRpt message is used to acknowledge the Native-IP instructions 256 received from the central controller (PCE). 258 The format of the PCRpt message is as follows: 260 ::= 261 262 Where: 264 ::= [] 266 ::= (| 267 ) 269 ::= [] 270 271 273 ::= [] 274 275 (| 276 ((||) 277 )) 279 Where: 280 is as per [RFC8231] and the LSP and SRP object are 281 also defined in [RFC8231]. 283 The error handling for missing CCI object is as per [RFC9050]. 284 Further only one of BPI, EPR, or PPA object MUST be present. 286 If none of them are present, the receiving PCE MUST send a PCErr 287 message with Error-type=6 (Mandatory Object missing) and Error- 288 value=TBD4 ( Native IP object missing). If there are more than one 289 of BPI, EPR or PPA object are presented, the receiving PCE MUST send 290 a PCErr message with Error-type=19(Invalid Operation) and Error- 291 value=TBD5(Only one of the BPI, EPR or PPA object can be included in 292 this message). 294 6. PCECC Native IP TE Procedures 296 The detail procedures for the TE in native IP environment are 297 described in the following sections. 299 6.1. BGP Session Establishment Procedures 301 The PCInitiate message can be used to configure the parameters for a 302 BGP peer session using the PCInitiate and PCRpt message pair. This 303 pair of PCE messages is exchanged with a PCE function attached to 304 each BGP peer which needs to be configured. After the BGP peer 305 session has been configured via this pair of PCE messages the BGP 306 session establishment process operates in a normal fashion. All BGP 307 peers are configured for peer to peer communication whether the peers 308 are E-BGP peers or I-BGP peers. One of the IBGP topologies requires 309 that multiple I-BGPs peers operate in a route-reflector I-BGP peer 310 topology. The example below shows two I-BGP route reflector clients 311 interacting with one Route Reflector (RR), but Route Reflector 312 topologies may have up to 100s of clients. Centralized configuration 313 via PCE provides mechanisms to scale auto-configuration of small and 314 large topologies. 316 The PCInitiate message should be sent to PCC which acts as BGP router 317 and/or route reflector(RR). 319 The route reflector topology for a single AS is shown in Figure 1. 320 The BGP routers R1, R3, and R7 are within a single AS. R1 and R7 are 321 BGP router-reflector clients, and R3 is a Route Reflector. The 322 PCInitiate message should be sent all of the BGP routers that need to 323 be configured R1 (M3), R3 (M2 & M3), and R7 (M4). 325 PCInitiate message creates an auto-configuration function for these 326 BGP peers providing the indicated Peer AS and the Local/Peer IP 327 Address. 329 When PCC receives the BPI and CCI object (with the R bit set to 0 in 330 SRP object) in PCInitiate message, the PCC should try to establish 331 the BGP session with the indicated Peer AS and Local/Peer IP address. 333 When PCC creates successfully the BGP session that is indicated by 334 the associated information, it should report the result via the PCRpt 335 messages, with BPI object and the corresponding SRP and CCI object 336 included. 338 When PCC receives this message with the R bit set to 1 in SRP object 339 in PCInitiate message, the PCC should clear the BGP session that 340 indicated by the BPI object. 342 When PCC clears successfully the specified BGP session, it should 343 report the result via the PCRpt message, with the BPI object 344 included, and the corresponding SRP and CCI object. 346 +------------------+ 347 +-----------+ PCE +----------+ 348 | +--------^---------+ | 349 | | | 350 M2/M2-R & M3/M3-R 351 | | | 352 | +---v---+ | 353 +---------------+ R3(RR)+-----------------+ 354 | +-------+ | 355 M1/M1-R M4/M4-R 356 | | 357 +v-+ +--+ +--+ +-v+ 358 |R1+----------+R5+----------+R6+---------+R7| 359 ++-+ +--+ +--+ +-++ 360 | | 361 | +--+ +--+ | 362 +------------+R2+----------+R4+-----------+ 363 +--+ +--+ 364 Figure 1: BGP Session Establishment Procedures(R3 act as RR) 366 The message number, message peers, message type and message key 367 parameters in the above figures are shown in below table: 369 Table 1: Message Information 370 +-------------------------------------------------------------+ 371 | No.| Peers| Type | Message Key Parameters | 372 +-------------------------------------------------------------+ 373 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 374 |M1-R| |PCRpt |BPI Object(Local_IP=R1_A,Peer_IP=R3_A)| 375 +-------------------------------------------------------------+ 376 |M2 |PCE/R3|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 377 |M2-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R1_A)| 378 +-------------------------------------------------------------+ 379 |M3 |PCE/R3|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 380 |M3-R| |PCRpt |BPI Object(Local_IP=R3_A,Peer_IP=R7_A)| 381 +-------------------------------------------------------------+ 382 |M4 |PCE/R7|PCInitiate|CC-ID=X4(Symbolic Path Name=Class A) | 383 |M4-R| |PCRpt |BPI Object(Local_IP=R7_A,Peer_IP=R3_A)| 384 +-------------------------------------------------------------+ 386 If the PCC cannot establish the BGP session that required by this 387 object, it should report the error values via PCErr message with the 388 newly defined error type(Error-type=TBD6) and error value(Error- 389 value=TBD7, Peer AS not match; or Error-Value=TBD8, Peer IP can't be 390 reached), which is indicated in Section 11 392 If the Local IP Address or Peer IP Address within BPI object is used 393 in other existing BGP sessions, the PCC should report such error 394 situation via PCErr message with Err-type=TBD6 and error value(Error- 395 value=TBD9, Local IP is in use; Error-value=TBD10, Remote IP is in 396 use). 398 6.2. Explicit Route Establish Procedures 400 The explicit route establishment procedures can be used to install a 401 route via PCE in the PCC/BGP Peer, using PCInitiate and PCRpt message 402 pair. Although the BGP policy might redistribute the routes 403 installed by explicit route, the PCE-BGP implementation needs to 404 prohibit the redistribution of the explicit route. PCE explicit 405 routes operate similar to static routes installed by network 406 management protocols (netconf/restconf) but the routes are associated 407 with the PCE routing module. Explicit route installations (like NM 408 static routes) must carefully install and uninstall static routes in 409 an specific order so that the pathways are established without loops. 411 The PCInitiate message should be sent to the on-path routers 412 respectively. In the example, for explicit route from R1 to R7, the 413 PCInitiate message should be sent to R1(M1), R2(M2) and R4(M3), as 414 shown in Figure 2. For explicit route from R7 to R1, the PCInitiate 415 message should be sent to R7(M1), R4(M2) and R2(M3), as shown in 416 Figure 3. 418 When PCC receives the EPR and the CCI object (with the R bit set to 0 419 in SRP object) in PCInitiate message, the PCC should install the 420 explicit route to the the peer. 422 When PCC install successfully the explicit route to the peer, it 423 should report the result via the PCRpt messages, with EPR object and 424 the corresponding SRP and CCI object included. 426 When PCC receives the EPR and the CCI object with the R bit set to 1 427 in SRP object in PCInitiate message, the PCC should clear the 428 explicit route to the peer that indicated by the EPR object. 430 When PCC clear successfully the explicit route that indicated by this 431 object, it should report the result via the PCRpt message, with the 432 EPR object included, and the corresponding SRP and CCI object. 434 +------------------+ 435 +----------+ PCE + 436 | +----^-----------^-+ 437 | | | 438 | | | 439 | | +------+ | 440 +-----------------+R3(RR)+--|-------------+ 441 M1/M1-R | +------+ | | 442 | | | | 443 +v-+ +--+ | | +--+ +--+ 444 |R1+------+R5+---+-----------|---+R6+----+R7| 445 ++-+ +--+ | | +--+ +-++ 446 | M2/M2-R M3/M3-R | 447 | | | | 448 | +--v--+ +--v-+ | 449 +------------+- R2 +-----+ R4 +-----------+ 450 +--+--+ +--+-+ 451 Figure 2: Explicit Route Establish Procedures(From R1 to R7) 453 The message number, message peers, message type and message key 454 parameters in the above figures are shown in below table: 456 Table 2: Message Information 457 +------------------------------------------------------------------+ 458 | No.|Peers | Type | Message Key Parameters | 459 +------------------------------------------------------------------+ 460 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 461 |M1-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R2_A)| 462 +------------------------------------------------------------------+ 463 |M2 |PCE/R2|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 464 |M2-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R4_A)| 465 +------------------------------------------------------------------+ 466 |M3 |PCE/R4|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 467 |M3-R| |PCRpt |EPR Object(Peer Address=R7_A,Next Hop=R7_A)| 468 +------------------------------------------------------------------+ 470 +------------------+ 471 + PCE +-----------+ 472 +----^-----------^-+ | 473 | | | 474 | | | 475 | +------+ | | 476 +-----------------+R3(RR)+--|-------------+ 477 | | +------+ | M1/M1-R 478 | | | | 479 +--+ +--+ | | +--+ +-v+ 480 |R1+------+R5+---+-----------|---+R6+----+R7| 481 ++-+ +--+ | | +--+ +-++ 482 | M3/M3-R M2/M2-R | 483 | | | | 484 | +--v--+ +--v-+ | 485 +------------+- R2 +-----+ R4 +-----------+ 486 +--+--+ +--+-+ 487 Figure 3: Explicit Route Establish Procedures(From R7 to R1) 489 The message number, message peers, message type and message key 490 parameters in the above figures are shown in below table: 492 Table 3: Message Information 493 +------------------------------------------------------------------+ 494 |No. |Peers | Type | Message Key Parameters | 495 +------------------------------------------------------------------+ 496 |M1 |PCE/R7|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A) | 497 |M1-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R4_A)| 498 +------------------------------------------------------------------+ 499 |M2 |PCE/R4|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A) | 500 |M2-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R2_A)| 501 +------------------------------------------------------------------+ 502 |M3 |PCE/R2|PCInitiate|CC-ID=X3(Symbolic Path Name=Class A) | 503 |M3-R| |PCRpt |EPR Object(Peer Address=R1_A,Next Hop=R1_A)| 504 +------------------------------------------------------------------+ 506 In order to avoid the transient loop during the deploy of explicit 507 peer route, the EPR object should be sent to the PCCs in the reverse 508 order of the E2E path. To remove the explicit peer route, the EPR 509 object should be sent to the PCCs in the same order of E2E path. 511 To accomplish ECMP effects, the PCE can send multiple EPR objects to 512 the same node, with the same route priority and peer address value 513 but different next hop addresses. 515 The PCC should verify that the next hop address is reachable. Upon 516 the error occurs, the PCC SHOULD send the corresponding error via 517 PCErr message, with an error information (Error-type=TBD6, Error- 518 value=TBD12, Explicit Peer Route Error) that defined in Section 11. 520 When the peer info is not the same as the peer info that indicated in 521 BPI object in PCC for the same path that is identified by Symbolic 522 Path Name TLV, an error (Error-type=TBD6, Error-value=17, EPR/BPI 523 Peer Info mismatch) should be reported via the PCErr message. 525 6.3. BGP Prefix Advertisement Procedures 527 The detail procedures for BGP prefix advertisement are shown below, 528 using PCInitiate and PCRpt message pair. 530 The PCInitiate message should be sent to PCC that acts as BGP peer 531 router only. In the example, it should be sent to R1(M1) or R7(M2) 532 respectively. 534 When PCC receives the PPA and the CCI object (with the R bit set to 0 535 in SRP object) in PCInitiate message, the PCC should send the 536 prefixes indicated in this object to the appointed BGP peer. 538 When PCC sends successfully the prefixes to the appointed BGP peer, 539 it should report the result via the PCRpt messages, with PPA object 540 and the corresponding SRP and CCI object included. 542 When PCC receives the PPA and the CCI object with the R bit set to 1 543 in SRP object in PCInitiate message, the PCC should withdraw the 544 prefixes advertisement to the peer that indicated by this object. 546 When PCC withdraws successfully the prefixes that indicated by this 547 object, it should report the result via the PCRpt message, with the 548 PPA object included, and the corresponding SRP and CCI object. 550 The allowed AFI/SAFI for the IPv4 BGP session should be 1/1(IPv4 551 prefix) and the allowed AFI/SAFI for the IPv6 BGP session should be 552 2/1(IPv6 prefix). If mismatch occur, an error(Error-type=TBD6, 553 Error-value=TBD18, BPI/PPR address family mismatch) should be 554 reported via PCErr message. 556 When the peer info is not the same as the peer info that indicated in 557 BPI object in PCC for the same path that is identified by Symbolic 558 Path Name TLV, an error (Error-type=TBD6, Error-value=TBD19, PPA/BPI 559 peer info mismatch) should be reported via the PCErr message. 561 +------------------+ 562 +----------+ PCE +-----------+ 563 | +------------------+ | 564 | +--+ | 565 +------------------+R3+-------------------+ 566 M1&M1-R +--+ M2&M2-R 567 | | 568 +v-+ +--+ +--+ +-v+ 569 |R1+----------+R5+----------+R6+---------+R7| 570 ++-+ +--+ +--+ +-++ 571 (BGP Router) (BGP Router) 572 | | 573 | | 574 | +--+ +--+ | 575 +------------+R2+----------+R4+-----------+ 576 Figure 4: BGP Prefix Advertisement Procedures 577 Table 4: Message Information 578 +-----------------------------------------------------------+ 579 |No. | Peers| Type | Message Key Parameters | 580 +-----------------------------------------------------------+ 581 |M1 |PCE/R1|PCInitiate|CC-ID=X1(Symbolic Path Name=Class A)| 582 |M1-R| |PCRpt |PPA Object(Peer IP=R7_A,Prefix=1_A) | 583 +-----------------------------------------------------------+ 584 |M2 |PCE/R7|PCInitiate|CC-ID=X2(Symbolic Path Name=Class A)| 585 |M2-R| |PCRpt |PPA Object(Peer IP=R1_A,Prefix=7_A) | 586 +-----------------------------------------------------------+ 588 7. New PCEP Objects 590 One new CCI Object and three new PCEP objects are defined in this 591 draft. All new PCEP objects are as per [RFC5440] 593 7.1. CCI Object 595 The Central Control Instructions (CCI) Object is used by the PCE to 596 specify the forwarding instructions is defined in [RFC9050]. This 597 document defines another object-type for Native-IP. 599 CCI Object-Type is TBD13 for Native-IP as below 601 0 1 2 3 602 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 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | CC-ID | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Reserved | Flags | 607 +---------------------------------------------------------------+ 608 | | 609 // Optional TLV // 610 | | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 5: CCI Object for Native IP 615 Figure 1 617 The field CC-ID is as described in [RFC9050]. Following fields are 618 defined for CCI Object-Type TBD13 620 Reserved: is set to zero while sending, ignored on receipt. 622 Flags: is used to carry any additional information pertaining to the 623 CCI. Currently no flag bits are defined. 625 The Symbolic Path Name TLV [RFC8231] MUST be included in the CCI 626 Object-Type TBD13 to identify the E2E TE path in Native IP 627 environment and MUST be unique. 629 7.2. BGP Peer Info Object 631 The BGP Peer Info object is used to specify the information about the 632 peer that the PCC should establish the BGP relationship with. This 633 object should only be included and sent to the head and end router of 634 the E2E path in case there is no Route Reflection (RR) involved. If 635 the RR is used between the head and end routers, then such 636 information should be sent to head router, RR and end router 637 respectively. 639 By default, there MUST be no prefix be distributed via such BGP 640 session that established by this object. 642 By default, the Local/Peer IP address SHOULD be dedicated to the 643 usage of native IP TE solution, and SHOULD NOT be used by other BGP 644 sessions that established by manual or non PCE initiated 645 configuration. 647 BGP Peer Info Object-Class is TBD14 649 BGP Peer Info Object-Type is 1 for IPv4 and 2 for IPv6 651 The format of the BGP Peer Info object body for IPv4(Object-Type=1) 652 is as follows: 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Peer AS Number | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | ETTL | Reserved |T| 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Local IP Address | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Peer IP Address | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Tunnel Source IP Address | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Tunnel Destination IP Address | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Additional TLVs | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Figure 6: BGP Peer Info Object Body Format for IPv4 673 The format of the BGP Peer Info object body for IPv6(Object-Type=2) 674 is as follows: 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Peer AS Number | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | ETTL | Reserved |T| 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | | 684 + + 685 | Local IP Address (16 bytes) | 686 + + 687 | | 688 + + 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | | 692 + + 693 | Peer IP Address (16 bytes) | 694 + + 695 | | 696 + + 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 + + 701 | Tunnel Source IP Address (16 bytes) | 702 + + 703 | | 704 + + 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 + + 709 | Tunnel Destination IP Address (16 bytes) | 710 + + 711 | | 712 + + 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Additional TLVs | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 Figure 7: BGP Peer Info Object Body Format for IPv6 719 Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. 721 ETTL: 1 Byte, to indicate the multihop count for EBGP session. It 722 should be 0 and ignored when Local AS and Peer AS is same. 724 Reserved: is set to zero while sending, ignored on receipt. 726 T bit: Indicates whether the traffic that associated with the 727 prefixes advertised via this BGP session is transported via IPinIP 728 tunnel (when T bit is set) or not (when T bit is clear). 730 Local IP Address(4/16 Bytes): IP address of the local router, used to 731 peer with other end router. When Object-Type is 1, length is 4 732 bytes; when Object-Type is 2, length is 16 bytes. 734 Peer IP Address(4/16 Bytes): IP address of the peer router, used to 735 peer with the local router. When Object-Type is 1, length is 4 736 bytes; when Object-Type is 2, length is 16 bytes; 738 Tunnel Source IP Address(4/16 Bytes): IP address of the tunnel 739 source, should be owned by the local router. When Object-Type is 1, 740 length is 4 bytes; when Object-Type is 2, length is 16 bytes. 742 Tunnel Destination IP Address(4/16 Bytes): IP address of the tunnel 743 destination, should be owned by the peer router. When Object-Type is 744 1, length is 4 bytes; when Object-Type is 2, length is 16 bytes. 745 Should be different from the Peer IP Address. 747 Additional TLVs: TLVs that associated with this object, can be used 748 to convey other necessary information for dynamic BGP session 749 establishment. Their definition are out of the current document. 751 When PCC receives BPI object, with Object-Type=1, it should try to 752 establish BGP session with the peer in AFI/SAFI=1/1; when PCC 753 receives BPI object with Object-Type=2, it should try to establish 754 the BGP session with the peer in AFI/SAFI=2/1. Other BGP 755 capabilities,for example, Graceful Restart(GR) that enhance the BGP 756 performance should also be negotiated and used by default. 758 7.3. Explicit Peer Route Object 760 The Explicit Peer Route object is defined to specify the explicit 761 peer route to the corresponding peer address on each device that is 762 on the E2E assurance path. This Object should be sent to all the 763 devices that locates on the E2E assurance path that calculated by 764 PCE. 766 The path established by this object should have higher priority than 767 other path calculated by dynamic IGP protocol, but should be lower 768 priority than the static route configured by manual or NETCONF or by 769 other means. 771 Explicit Peer Route Object-Class is TBD15. 773 Explicit Peer Route Object-Type is 1 for IPv4 and 2 for IPv6 775 The format of Explicit Peer Route object body for IPv4(Object-Type=1) 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 | Peer/Tunnel Destination Address | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Next Hop Address to the Peer/Tunnel Destination Address | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Additional TLVs | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Figure 8: Explicit Peer Route Object Body Format for IPv4 791 The format of Explicit Peer Route object body for IPv6(Object-Type=2) 792 is as follows: 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Route Priority | Reserved | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | 800 + + 801 | Peer Address/Tunnel Destination Address | 802 + + 803 | | 804 + + 805 | | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | | 808 + + 809 | Next Hop Address to the Peer/Tunnel Destination Address | 810 + + 811 | | 812 + + 813 | | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Additional TLVs | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Figure 9: Explicit Peer Route Object Body Format for IPv6 819 Route Priority: 2 Bytes, The priority of this explicit route. The 820 higher priority should be preferred by the device. This field is 821 used to indicate the backup path at each hop. 823 Reserved: is set to zero while sending, ignored on receipt. 825 Peer/Tunnel Destination Address: To indicate the peer address(4/16 826 Bytes). When T bit is set in the associated BPI object, use the 827 tunnel destination address in BPI object; when T bit is clear, use 828 the peer address in BPI object. 830 Next Hop Address to the Peer/Tunnel Destination Address: To indicate 831 the next hop address(4/16 Bytes) to the corresponding peer/tunnel 832 destination address. 834 Additional TLVs: TLVs that associated with this object, can be used 835 to convey other necessary information for explicit peer path 836 establishment. Their definitions are out of the current document. 838 7.4. Peer Prefix Advertisement Object 840 The Peer Prefix Advertisement object is defined to specify the IP 841 prefixes that should be advertised to the corresponding peer. This 842 object should only be included and sent to the head/end router of the 843 end2end path. 845 The prefixes information included in this object MUST only be 846 advertised to the indicated peer, MUST NOT be advertised to other BGP 847 peers. 849 Peer Prefix Advertisement Object-Class is TBD16 851 Peer Prefix Advertisement Object-Type is 1 for IPv4 and 2 for IPv6 853 The format of the Peer Prefix Advertisement object body is as 854 follows: 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Peer IPv4 Address | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | | 862 // IPv4 Prefix subobjects // 863 | | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Additional TLVs | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Figure 10: Peer Prefix Advertisement Object Body Format for IPv4 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Peer IPv6 Address | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | | 875 // IPv6 Prefix subobjects // 876 | | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Additional TLVs | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 Figure 11: Peer Prefix Advertisement Object Body Format for IPv6 882 Peer IPv4 Address: 4 Bytes. Identifies the peer IPv4 address that 883 the associated prefixes will be sent to. 885 IPv4 Prefix subojects: List of IPv4 Prefix subobjects that defined in 886 [RFC3209], identify the prefixes that will be sent to the peer that 887 identified by Peer IPv4 Address List. 889 Peer IPv6 Address: 16 Bytes. Identifies the peer IPv6 address that 890 the associated prefixes will be sent to. 892 IPv6 Prefix subojects: List of IPv6 Prefix subobjects that defined in 893 [RFC3209], identify the prefixes that will be sent to the peer that 894 identified by Peer IPv6 Address List. 896 Additional TLVs: TLVs that associated with this object, can be used 897 to convey other necessary information for prefixes advertisement. 898 Their definitions are out of the current document. 900 8. End to End Path Protection 902 [RFC8697] defines the path associations procedures between sets of 903 Label Switched Path (LSP). Such procedures can also be used for the 904 E2E path protection. To accomplish this, the PCE should attach the 905 ASSOCIATION object with the EPR object in the PCInitiate message, 906 with the association type set to 1 (Path Protection Association). 907 The Extended Association ID that included within the Extended 908 Association ID TLV, which is included in the ASSOCIATION object, 909 should be set to the Symbolic Path Name of different E2E path. This 910 PCinitiate should be sent to the head-end of the E2E path. 912 The head-end of the path can use the existing path detection 913 mechanism(for example, Bidirectional Forwarding Detection [RFC5880]), 914 to monitor the status of the active path. Once it detects the 915 failure, it can switch the backup protection path immediately. 917 9. Re-Delegation and Clean up 919 In case of a PCE failure, a new PCE can gain control over the central 920 controller instructions. As per the PCEP procedures in [RFC8281], 921 the State Timeout Interval timer is used to ensure that a PCE failure 922 does not result in automatic and immediate disruption for the 923 services. Similarly, as per [RFC9050], the central controller 924 instructions are not removed immediately upon PCE failure. Instead, 925 they could be re-delegated to the new PCE before the expiration of 926 this timer, or be cleaned up on the expiration of this timer. The 927 allows for network clean up without manual intervention. The PCC 928 MUST support the removal of CCI as one of the behaviors applied on 929 expiration of the State Timeout Interval timer. 931 10. BGP Considerations 933 This draft defines the procedures and objects to create the BGP 934 sessions and advertises the associated prefixes dynamically. Only 935 the key information, for example peer IP addresses, peer AS number 936 are exchanged via the PCEP protocol. Other parameters that are 937 needed for the BGP session setup should be derived from their default 938 values, as described in Section 7.2. Upon receives such key 939 information, the BGP module on the PCC should try to accomplish the 940 task that appointed by the PCEP protocol and report the status to the 941 PCEP modules. 943 There is no influence to current implementation of BGP Finite State 944 Machine(FSM). The PCEP cares only the success and failure status of 945 BGP session, and act upon such information accordingly. 947 The error handling procedures related to incorrect BGP parameters are 948 specified in Section 6.1, Section 6.2, and Section 6.3. The handling 949 of the dynamic BGP sessions and associated prefixes on PCE failure is 950 described in Section 9. 952 11. New Error-Types and Error-Values Defined 954 A PCEP-ERROR object is used to report a PCEP error and is 955 characterized by an Error-Type that specifies that type of error and 956 an Error-value that provides additional information about the error. 957 An additional Error-Type and several Error-values are defined to 958 represent some the errors related to the newly defined objects, which 959 are related to Native IP TE procedures. 961 +============+===============+==============================+ 962 | Error-Type | Meaning | Error-value | 963 +============+===============+=====================================+ 964 | TBD6 | Native IP | | 965 | | TE failure | | 966 +------------+---------------+-------------------------------------+ 967 | | | 0: Unassigned | 968 +------------+---------------+-------------------------------------+ 969 | | |TBD7: Peer AS not match | 970 +------------+---------------+-------------------------------------+ 971 | | |TBD8:Peer IP can't be reached | 972 +------------+---------------+-------------------------------------+ 973 | | |TBD9:Local IP is in use | 974 +------------+---------------+-------------------------------------+ 975 | | |TBD10:Remote IP is in use | 976 +------------+---------------+-------------------------------------+ 977 | | |TBD11:Exist BGP session broken | 978 +------------+---------------+-------------------------------------+ 979 | | |TBD12:Explicit Peer Route Error | 980 +------------+---------------+-------------------------------------+ 981 | | |TBD17:EPR/BPI Peer Info mismatch | 982 +------------+---------------+-------------------------------------+ 983 | | |TBD18:BPI/PPA Address Family mismatch| 984 +------------+---------------+-------------------------------------+ 985 | | |TBD19:PPA/BPI Peer Info mismatch | 986 +------------+---------------+-------------------------------------+ 988 Figure 12: Newly defined Error-Type and Error-Value 990 12. Deployment Considerations 992 The information transferred in this draft is mainly used for the 993 light weight BGP session setup, explicit route deployment and the 994 prefix distribution. The planning, allocation and distribution of 995 the peer addresses within IGP should be accomplished in advanced and 996 they are out of the scope of this draft. 998 [RFC8232] describes the state synchronization procedure between 999 stateful PCE and PCC. The communication of PCE and PCC described in 1000 this draft should also follow this procedures, treat the three newly 1001 defined objects that associated with the same symbolic path name as 1002 the attribute of the same path in the LSP-DB. 1004 When PCE detects one or some of the PCCs are out of control, it 1005 should recompute and redeploy the traffic engineering path for native 1006 IP on the active PCCs. When PCC detects that it is out of control of 1007 the PCE, it should clear the information that initiated by the PCE. 1008 The PCE should assures the avoidance of possible transient loop in 1009 such node failure when it deploy the explicit peer route on the PCCs. 1011 If the established BGP session is broken after some time, the PCC 1012 should also report such error via PCErr message with Err-type=TBD6 1013 and error value(Error-value=TBD11, Existing BGP session is broken). 1014 Upon receiving such PCErr message, the PCE should clear the prefixes 1015 advertisement on the previous BGP session, clear the explicit peer 1016 route to the previous peer address; select other Local_IP/Peer_IP 1017 pair to establish the new BGP session, deploy the explicit peer route 1018 to the new peer address, and advertises the prefixes on the new BGP 1019 session. 1021 13. Implementation Status 1023 [Note to the RFC Editor - remove this section before publication, as 1024 well as remove the reference to RFC 7942.] 1026 This section records the status of known implementations of the 1027 protocol defined by this specification at the time of posting of this 1028 Internet-Draft, and is based on a proposal described in [RFC7942]. 1029 The description of implementations in this section is intended to 1030 assist the IETF in its decision processes in progressing drafts to 1031 RFCs. Please note that the listing of any individual implementation 1032 here does not imply endorsement by the IETF. Furthermore, no effort 1033 has been spent to verify the information presented here that was 1034 supplied by IETF contributors. This is not intended as, and must not 1035 be construed to be, a catalog of available implementations or their 1036 features. Readers are advised to note that other implementations may 1037 exist. 1039 According to [RFC7942], "this will allow reviewers and working groups 1040 to assign due consideration to documents that have the benefit of 1041 running code, which may serve as evidence of valuable experimentation 1042 and feedback that have made the implemented protocols more mature. 1043 It is up to the individual working groups to use this information as 1044 they see fit". 1046 13.1. Proof of Concept based on ODL 1048 .At the time of posting the -18 version of this document, there are 1049 no known implementations of this mechanism. A proof of concept for 1050 the overall design has been verified using another SBI protocol on 1051 the Open DayLight (ODL) controller. 1053 14. Security Considerations 1055 The setup of BGP sessions, prefix advertisement, and explicit peer 1056 route establishment are all controlled by the PCE. See [RFC4271] and 1057 [RFC4272] for BGP security considerations. Security consideration 1058 part in [RFC5440] and [RFC8231] should be considered. To prevent a 1059 bogus PCE sending harmful messages to the network nodes, the network 1060 devices should authenticate the validity of the PCE and ensure a 1061 secure communication channel between them. Mechanisms described in 1062 [RFC8253] should be used. 1064 15. IANA Considerations 1066 15.1. Path Setup Type Registry 1068 [RFC8408] created a sub-registry within the "Path Computation Element 1069 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1070 IANA is requested to allocate a new code point within this registry, 1071 as follows: 1073 Value Description Reference 1074 TBD1 Native IP TE Path This document 1076 15.2. PCECC-CAPABILITY sub-TLV's Flag field 1078 [RFC9050] created a sub-registry within the "Path Computation Element 1079 Protocol (PCEP) Numbers" registry to manage the value of the PCECC- 1080 CAPABILITY sub-TLV's 32-bits Flag field. IANA is requested to 1081 allocate a new bit position within this registry, as follows: 1083 Value Description Reference 1084 TBD2(N) NATIVE-IP-TE-CAPABILITY This document 1086 15.3. PCEP Object Types 1088 IANA is requested to allocate new registry for the PCEP Object Type: 1090 Object-Class Value Name Reference 1091 44 CCI Object This document 1092 Object-Type 1093 TBD13: Native IP 1095 TBD14 BGP Peer Info This document 1096 Object-Type 1097 1: IPv4 address 1098 2: IPv6 address 1100 TBD15 Explicit Peer Route This document 1101 Object-Type 1102 1: IPv4 address 1103 2: IPv6 address 1105 TBD16 Peer Prefix Advertisement This document 1106 Object-Type 1107 1: IPv4 address 1108 2: IPv6 address 1110 15.4. PCEP-Error Object 1112 IANA is requested to allocate new error types and error values within 1113 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1114 PCEP Numbers registry for the following errors:: 1116 Error-Type Meaning Error-value Reference 1117 6 Mandatory Object missing 1118 TBD4:Native IP object missing This document 1120 10 Reception of an invalid object 1121 TBD3:PCECC NATIVE-IP-TE-CAPABILITY bit is not set This document 1123 19 Invalid Operation 1124 TBD5:Only one of the BPI,EPR or PPA object can be included in this message This document 1126 TBD6 Native IP TE failure This document 1127 TBD7:Peer AS not match 1128 TBD8:Peer IP can't be reached 1129 TBD9:Local IP is in use 1130 TBD10:Remote IP is in use 1131 TBD11:Exist BGP session broken 1132 TBD12:Explicit Peer Route Error 1133 TBD17:EPR/BPI Peer Info mismatch 1134 TBD18:BPI/PPA Address Family mismatch 1135 TBD19:PPA/BPI Peer Info mismatch 1137 16. Contributor 1139 Dhruv Dhody has contributed the contents of this draft. 1141 17. Acknowledgement 1143 Thanks Mike Koldychev, Susan Hares, Siva Sivabalan, Adam Simpson for 1144 his valuable suggestions and comments. 1146 18. Normative References 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, 1150 DOI 10.17487/RFC2119, March 1997, 1151 . 1153 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1154 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1155 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1156 . 1158 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1159 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1160 DOI 10.17487/RFC4271, January 2006, 1161 . 1163 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1164 RFC 4272, DOI 10.17487/RFC4272, January 2006, 1165 . 1167 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1168 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1169 DOI 10.17487/RFC5440, March 2009, 1170 . 1172 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 1173 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 1174 . 1176 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1177 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1178 May 2017, . 1180 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1181 Computation Element Communication Protocol (PCEP) 1182 Extensions for Stateful PCE", RFC 8231, 1183 DOI 10.17487/RFC8231, September 2017, 1184 . 1186 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1187 and D. Dhody, "Optimizations of Label Switched Path State 1188 Synchronization Procedures for a Stateful PCE", RFC 8232, 1189 DOI 10.17487/RFC8232, September 2017, 1190 . 1192 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1193 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1194 Path Computation Element Communication Protocol (PCEP)", 1195 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1196 . 1198 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1199 Computation Element Communication Protocol (PCEP) 1200 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1201 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1202 . 1204 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1205 Architecture for Use of PCE and the PCE Communication 1206 Protocol (PCEP) in a Network with Central Control", 1207 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1208 . 1210 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1211 Hardwick, "Conveying Path Setup Type in PCE Communication 1212 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1213 July 2018, . 1215 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1216 Dhody, D., and Y. Tanaka, "Path Computation Element 1217 Communication Protocol (PCEP) Extensions for Establishing 1218 Relationships between Sets of Label Switched Paths 1219 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1220 . 1222 [RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, 1223 "Scenarios and Simulation Results of PCE in a Native IP 1224 Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, 1225 . 1227 [RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based 1228 Traffic Engineering (TE) in Native IP Networks", RFC 8821, 1229 DOI 10.17487/RFC8821, April 2021, 1230 . 1232 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 1233 Computation Element Communication Protocol (PCEP) 1234 Procedures and Extensions for Using the PCE as a Central 1235 Controller (PCECC) of LSPs", RFC 9050, 1236 DOI 10.17487/RFC9050, July 2021, 1237 . 1239 Authors' Addresses 1241 Aijun Wang 1242 China Telecom 1243 Beiqijia Town, Changping District 1244 Beijing 1245 Beijing, 102209 1246 China 1247 Email: wangaj3@chinatelecom.cn 1249 Boris Khasanov 1250 Yandex LLC 1251 Ulitsa Lva Tolstogo 16 1252 Moscow 1253 Email: bhassanov@yahoo.com 1255 Sheng Fang 1256 Huawei Technologies,Co.,Ltd 1257 Huawei Bld., No.156 Beiqing Rd. 1258 Beijing 1259 China 1260 Email: fsheng@huawei.com 1262 Ren Tan 1263 Huawei Technologies,Co.,Ltd 1264 Huawei Bld., No.156 Beiqing Rd. 1265 Beijing 1266 China 1267 Email: tanren@huawei.com 1269 Chun Zhu 1270 ZTE Corporation 1271 50 Software Avenue, Yuhua District 1272 Nanjing 1273 Jiangsu, 210012 1274 China 1275 Email: zhu.chun1@zte.com.cn