idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-teas-native-ip-scenarios], [I-D.ietf-teas-pce-native-ip]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2020) is 1529 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: 'RFC2119' is mentioned on line 105, but not defined == Unused Reference: 'RFC8281' is defined on line 419, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-03 == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-05 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-pce-native-ip (ref. 'I-D.ietf-teas-pce-native-ip') ** Downref: Normative reference to an Informational RFC: RFC 8283 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track B. Khasanov 5 Expires: August 21, 2020 S. Fang 6 Huawei 7 C. Zhu 8 ZTE Corporation 9 February 18, 2020 11 PCEP Extension for Native IP Network 12 draft-ietf-pce-pcep-extension-native-ip-05 14 Abstract 16 This document defines the Path Computation Element Communication 17 Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) 18 based application in Native IP network. The scenario and framework 19 of CCDR in native IP is described in 20 [I-D.ietf-teas-native-ip-scenarios] and 21 [I-D.ietf-teas-pce-native-ip]. This draft describes the key 22 information that is transferred between Path Computation Element 23 (PCE) and Path Computation Clients (PCC) to accomplish the End to End 24 (E2E) traffic assurance in Native IP network under central control 25 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 August 21, 2020. 44 Copyright Notice 46 Copyright (c) 2020 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. CCI Objects . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5. CCI Object associated TLV . . . . . . . . . . . . . . . . . . 4 66 5.1. Peer Address List TLV . . . . . . . . . . . . . . . . . . 4 67 5.2. Peer Prefix Association TLV . . . . . . . . . . . . . . . 6 68 5.2.1. Prefix sub TLV . . . . . . . . . . . . . . . . . . . 7 69 5.3. Explicit Peer Route TLV . . . . . . . . . . . . . . . . . 7 70 6. Management Consideration . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. CCI Object Type . . . . . . . . . . . . . . . . . . . . . 9 74 8.2. CCI Object Associated TLV . . . . . . . . . . . . . . . . 9 75 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 10.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Traditionally, Multiprotocol Label Switching Traffic Engineering 84 (MPLS-TE) traffic assurance requires the corresponding network 85 devices support Multiprotocol Label Switching (MPLS) or the complex 86 Resource ReSerVation Protocol (RSVP)/Label Distribution Protocol 87 (LDP) /Segment Routing etc. technologies to assure the End-to-End 88 (E2E) traffic performance. But in native IP network, there will be 89 no such signaling protocol to synchronize the action among different 90 network devices. It is necessary to use the central control mode 91 that described in [RFC8283] to correlate the forwarding behavior 92 among different network devices. Draft [I-D.ietf-teas-pce-native-ip] 93 describes the architecture and solution philosophy for the E2E 94 traffic assurance in Native IP network via Dual/Multi Border Gateway 95 Protocol (BGP) solution. This draft describes the corresponding Path 96 Computation Element Communication Protocol (PCEP) extensions to 97 transfer the key information about peer address list, peer prefix 98 association and the explicit peer route on on-path router. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 3. Terminology 108 .This document uses the following terms defined in [RFC5440]: PCE, 109 PCEP 111 The following terms are defined in this document: 113 o CCDR: Central Control Dynamic Routing 115 o CCI: Central Controller's Instructions 117 o E2E: End to End 119 o EPR: Explicit Peer Route 121 o PAL: Peer Address List 123 o PPA: Peer Prefix Association 125 o QoS: Quality of Service 127 4. CCI Objects 129 Draft [I-D.ietf-pce-pcep-extension-for-pce-controller] introduces the 130 Central Controller's Instructions (CCI) object which is included in 131 the PCInitiate and PCRpt message to transfer the centrally control 132 instruction and status between Path Computation Element (PCE) and 133 Path Computation Clients (PCC). This object is extended to include 134 the construction for native IP solution. Additional Type-Length- 135 Values (TLVs) are defined and included in this extended CCI object. 137 CCI Object-Class is TBD, should be same as that defined in draft 138 [I-D.ietf-pce-pcep-extension-for-pce-controller] 140 CCI Object-Type is TBD for Native IP network 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | CC-ID | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Reserved | Flags | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 // Optional TLV // 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: CCI Object Format 154 The fields in the CCI object are as follows: 156 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 157 creates an CC-ID for each instruction, the value is unique within the 158 scope of the PCE and is constant for the lifetime of a PCEP session. 159 The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. 161 Flags: Is used to carry any additional information pertaining to the 162 CCI. 164 Optional TLV: Additional TLVs that are associated with the Native IP 165 construction. 167 5. CCI Object associated TLV 169 Three new TLVs are defined in this draft: 171 o PAL TLV: Peer Address List TLV, used to tell the network device 172 which peer it should be peered with dynamically 174 o PPA TLV: Peer Prefix Association TLV,used to tell which prefixes 175 should be advertised via the corresponding peer 177 o EPR TLV: Explicit Peer Route TLV,used to point out which route 178 should be taken to arrive to the peer. 180 5.1. Peer Address List TLV 182 The Peer Address List TLV is defined to specify the IP address of 183 peer that the received network device should establish the BGP 184 relationship with. This TLV should only be included and sent to the 185 head and end router of the E2E path in case there is no Route 186 Reflection (RR) involved. If the RR is used between the head and end 187 routers, then such information should be sent to head router, RR and 188 end router respectively. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type=TBD | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Peer Num | Resv. | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Peer ID | AT | Resv. | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Local AS Number | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Peer AS Number | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | ETTL | Peer Cookie | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Local IP Address(4/16 Bytes) | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Peer IP Address(4/16 Bytes) | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Additional Peer Info. | 210 // (From Peer ID to Peer IP Address) // 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: Peer Address List TLV Format 214 Type: 2 Bytes, value is TBD. 216 Length: 2 Bytes, the length of the following fields. 218 Peer Num : 2 Bytes, Peer Address Number on the advertised router. 220 Peer-ID: 2 Bytes, to distinguish the different peer pair, will be 221 referenced in Peer Prefix Association, if the PCE use multi-BGP 222 solution for different QoS assurance requirement. 224 AT: 1 Bytes, Address Type. To indicate the address type of Peer. 225 Equal to 4, if the following IP address of peer is belong to IPv4; 226 Equal to 6 if the following IP address of peer is belong to IPv6. 228 Resv: 1 Bytes, Reserved for future use. 230 Local AS Number: 4 Bytes, to indicate the AS number of the Local 231 Peer. 233 Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. 235 ETTL: 1 Bytes, to indicate the multi hop count for EBGP session. It 236 should be 0 and ignored when Local AS and Peer AS is same. 238 Peer Cookie: Used for establishing the secure BGP session between two 239 peers. The PCEP client should use the MD5 algorithm to generate the 240 encrypted message. 242 Local IP Address(4/16 Bytes): IPv4 address of the local router, used 243 to peer with other end router. When AT equal to 4, length is 32bit; 244 when AT equal to 16, length is 128bit. 246 Peer IP Address(4/16 Bytes): IPv4 address of the peer router, used to 247 peer with the local router. When AT equal to 4, length is 32bit; 248 IPv6 address of the peer when AT equal to 16, length is 128bit; 250 5.2. Peer Prefix Association TLV 252 The Peer Prefix Association TLV is defined to specify the IP prefixes 253 that should be advertised by the corresponding Peer. This TLV should 254 only be included and sent to the head/end router of the end2end path 255 in case there is no RR involved. If the RR is used between the head 256 and end routers, then such information should be sent to head 257 router,RR and end router respectively. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type=TBD | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Peer ID | Prefixes Num | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Peer Associated IP Prefix sub TLV(Variable) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 3: Peer Prefix Association TLV Format 270 Type: 2 Bytes, value is TBD 272 Length: 2 Bytes, the length of the following fields. 274 Peer-ID: 2 Bytes, to indicate which peer should be used to advertise 275 the following IP Prefix TLV. This value is assigned in the Peer 276 Address List object and is referred in this object. 278 Prefixes Num: 2 Bytes, number of prefixes that advertised by the 279 corresponding Peer. It should be equal to number of the following IP 280 prefix sub TLV. 282 Peer Associated IP Prefix sub TLV: Variable Length, indicate the 283 advertised IP Prefix. 285 5.2.1. Prefix sub TLV 287 Prefix sub TLV is used to carry the prefix information, which has the 288 following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type=TBD | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | AT | Prefix Length | Prefix Value | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Prefix Value | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 4: Prefix sub TLV Format 301 Type: 2 Bytes, value is TBD 303 Length: 2 Bytes, the length of the following fields. 305 AT: 1 Byte, Address Type. To indicate the address type of Peer. 306 Equal to 4, if the following "Prefix address" belong to IPv4; Equal 307 to 6 if the following "Prefix address" belong to IPv6. 309 Prefix Length: 1 Byte, the prefix length. For example, for 310 10.0.0.0/8, this field will be equal to 8; for 2001:DB8::/32, this 311 field will be equal to 32. 313 Prefix Value: Variable length, the value of the prefix. For example, 314 for 10.0.0.0/8, this field will be 10.0.0.0; for 2001:DB8::/32, this 315 field will be equal to 2001:DB8::. 317 5.3. Explicit Peer Route TLV 319 The Explicit Peer Route TLV is defined to specify the explicit peer 320 route to the corresponding peer address on each device that is on the 321 E2E assurance path. This TLV should be sent to all the devices that 322 locates on the E2E assurance path that calculated by PCE. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type=TBD | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Route Priority| AT | Peer Address(IPv4/IPv6) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Next Hop Address to the Peer(IPv4/IPv6) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 5: Explicit Peer Route TLV 335 Type: 2 Bytes, value is TBD 337 Length: 2 Bytes, the length of following fields. 339 Route Priority: 1 Byte, The priority of this explicit route. The 340 higher priority should be preferred by the device. 342 AT: 1 Byte, Address Type. To indicate the address type of explicit 343 peer route. Equal to 4, if the following peer and next hop address 344 belongs to IPv4; Equal to 6 if the following peer and next hop 345 address belongs to IPv6. 347 Peer Address: Variable Length, to indicate the peer address. 349 Next Hop Address to the Peer: Variable Length, to indicate the next 350 hop address to the corresponding peer that indicated by the Peer-ID. 352 6. Management Consideration 354 The information transferred in this draft is mainly used for the 355 light weight BGP session setup, the prefix distribution and the 356 explicit route deployment. The planning, allocation and distribution 357 of the peer addresses within IGP should be accomplished in advanced 358 and they are out of the scope of this draft. 360 7. Security Considerations 362 Service provider should consider the protection of PCE and their 363 communication with the underlay devices, which is described in 364 document [RFC5440] and [RFC8253] 366 8. IANA Considerations 367 8.1. CCI Object Type 369 IANA is requested to allocate new registry for the CCI Object Type: 371 Object-Type Value CCI Object Name Reference 372 3 Native IP This document 374 8.2. CCI Object Associated TLV 376 IANA is requested to confirm the early allocation of the following 377 TLV Type Indicator values within the "PCEP TLV Type Indicator" sub- 378 registry of the PCEP Numbers registry, and to update the reference in 379 the registry to point to this document, when it is an RFC: 381 Value Meaning Reference 382 --------------------------------------------------------- 383 TBD Peer Address List TLV This document 384 TBD Peer Prefix Association TLV This document 385 TBD Explicit Peer Route TLV This document 386 TBD Prefix sub TLV This document 388 9. Acknowledgement 390 Thanks Dhruv Dhody for his valuable suggestions and comments. 392 10. References 394 10.1. Normative References 396 [I-D.ietf-pce-pcep-extension-for-pce-controller] 397 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 398 and Protocol Extensions for Using PCE as a Central 399 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 400 extension-for-pce-controller-03 (work in progress), 401 November 2019. 403 [I-D.ietf-teas-pce-native-ip] 404 Wang, A., Zhao, Q., Khasanov, B., and H. Chen, "PCE in 405 Native IP Network", draft-ietf-teas-pce-native-ip-05 (work 406 in progress), January 2020. 408 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 409 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 410 DOI 10.17487/RFC5440, March 2009, 411 . 413 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 414 "PCEPS: Usage of TLS to Provide a Secure Transport for the 415 Path Computation Element Communication Protocol (PCEP)", 416 RFC 8253, DOI 10.17487/RFC8253, October 2017, 417 . 419 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 420 Computation Element Communication Protocol (PCEP) 421 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 422 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 423 . 425 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 426 Architecture for Use of PCE and the PCE Communication 427 Protocol (PCEP) in a Network with Central Control", 428 RFC 8283, DOI 10.17487/RFC8283, December 2017, 429 . 431 10.2. Informative References 433 [I-D.ietf-teas-native-ip-scenarios] 434 Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, 435 "Scenarios and Simulation Results of PCE in Native IP 436 Network", draft-ietf-teas-native-ip-scenarios-12 (work in 437 progress), October 2019. 439 Authors' Addresses 441 Aijun Wang 442 China Telecom 443 Beiqijia Town, Changping District 444 Beijing, Beijing 102209 445 China 447 Email: wangaj3@chinatelecom.cn 449 Boris Khasanov 450 Huawei Technologies,Co.,Ltd 451 Moskovskiy Prospekt 97A 452 St.Petersburg 196084 453 Russia 455 Email: khasanov.boris@huawei.com 456 Sheng Fang 457 Huawei Technologies, Co., 458 Ltd 459 Huawei Bld., No.156 Beiqing Rd. 460 Beijing 461 China 463 Email: fsheng@huawei.com 465 Chun Zhu 466 ZTE Corporation 467 50 Software Avenue, Yuhua District 468 Nanjing, Jiangsu 210012 469 China 471 Email: zhu.chun1@zte.com.cn