idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-04.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 (August 26, 2019) is 1705 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 108, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-02 == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-03 ** 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 == Outdated reference: A later version (-12) exists of draft-ietf-teas-native-ip-scenarios-06 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: February 27, 2020 Huawei 6 S. Cheruathur 7 Juniper Networks 8 C. Zhu 9 ZTE Corporation 10 S. Fang 11 Huawei 12 August 26, 2019 14 PCEP Extension for Native IP Network 15 draft-ietf-pce-pcep-extension-native-ip-04 17 Abstract 19 This document defines the Path Computation Element Communication 20 Protocol (PCEP) extension for Central Control Dynamic Routing (CCDR) 21 based application in Native IP network. The scenario and framework 22 of CCDR in native IP is described in 23 [I-D.ietf-teas-native-ip-scenarios] and 24 [I-D.ietf-teas-pce-native-ip]. This draft describes the key 25 information that is transferred between Path Computation Element 26 (PCE) and Path Computation Clients (PCC) to accomplish the End to End 27 (E2E) traffic assurance in Native IP network under central control 28 mode. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 27, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. CCI Objects . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 5. CCI Object associated TLV . . . . . . . . . . . . . . . . . . 4 69 5.1. Peer Address List TLV . . . . . . . . . . . . . . . . . . 4 70 5.2. Peer Prefix Association TLV . . . . . . . . . . . . . . . 6 71 5.2.1. Prefix sub TLV . . . . . . . . . . . . . . . . . . . 7 72 5.3. Explicit Peer Route TLV . . . . . . . . . . . . . . . . . 7 73 6. Management Consideration . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. CCI Object Type . . . . . . . . . . . . . . . . . . . . . 8 77 8.2. CCI Object Associated TLV . . . . . . . . . . . . . . . . 8 78 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Traditionally, Multiprotocol Label Switching Traffic Engineering 87 (MPLS-TE) traffic assurance requires the corresponding network 88 devices support Multiprotocol Label Switching (MPLS) or the complex 89 Resource ReSerVation Protocol (RSVP)/Label Distribution Protocol 90 (LDP) /Segment Routing etc. technologies to assure the End-to-End 91 (E2E) traffic performance. But in native IP network, there will be 92 no such signaling protocol to synchronize the action among different 93 network devices. It is necessary to use the central control mode 94 that described in [RFC8283] to correlate the forwarding behavior 95 among different network devices. Draft [I-D.ietf-teas-pce-native-ip] 96 describes the architecture and solution philosophy for the E2E 97 traffic assurance in Native IP network via Dual/Multi Border Gateway 98 Protocol (BGP) solution. This draft describes the corresponding Path 99 Computation Element Communication Protocol (PCEP) extensions to 100 transfer the key information about peer address list, peer prefix 101 association and the explicit peer route on on-path router. 103 2. Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Terminology 111 .This document uses the following terms defined in [RFC5440]: PCE, 112 PCEP 114 The following terms are defined in this document: 116 o CCDR: Central Control Dynamic Routing 118 o CCI: Central Controller's Instructions 120 o E2E: End to End 122 o EPR: Explicit Peer Route 124 o PAL: Peer Address List 126 o PPA: Peer Prefix Association 128 o QoS: Quality of Service 130 4. CCI Objects 132 Draft [I-D.ietf-pce-pcep-extension-for-pce-controller] introduces the 133 Central Controller's Instructions (CCI) object which is included in 134 the PCInitiate and PCRpt message to transfer the centrally control 135 instruction and status between Path Computation Element (PCE) and 136 Path Computation Clients (PCC). This object is extended to include 137 the construction for native IP solution. Additional Type-Length- 138 Values (TLVs) are defined and included in this extended CCI object. 140 CCI Object-Class is TBD, should be same as that defined in draft 141 [I-D.ietf-pce-pcep-extension-for-pce-controller] 142 CCI Object-Type is TBD for Native IP network 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | CC-ID | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Reserved | Flags | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 // Optional TLV // 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1: CCI Object Format 157 The fields in the CCI object are as follows: 159 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 160 creates an CC-ID for each instruction, the value is unique within the 161 scope of the PCE and is constant for the lifetime of a PCEP session. 162 The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. 164 Flags: Is used to carry any additional information pertaining to the 165 CCI. 167 Optional TLV: Additional TLVs that are associated with the Native IP 168 construction. 170 5. CCI Object associated TLV 172 Three new TLVs are defined in this draft: 174 o PAL TLV: Peer Address List TLV, used to tell the network device 175 which peer it should be peered with dynamically 177 o PPA TLV: Peer Prefix Association TLV,used to tell which prefixes 178 should be advertised via the corresponding peer 180 o EPR TLV: Explicit Peer Route TLV,used to point out which route 181 should be taken to arrive to the peer. 183 5.1. Peer Address List TLV 185 The Peer Address List TLV is defined to specify the IP address of 186 peer that the received network device should establish the BGP 187 relationship with. This TLV should only be included and sent to the 188 head and end router of the E2E path in case there is no Route 189 Reflection (RR) involved. If the RR is used between the head and end 190 routers, then such information should be sent to head router, RR and 191 end router respectively. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type=TBD | Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Peer Num | Resv. | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Peer ID | AT | Resv. | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Local AS Number | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Peer AS Number | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Local IP Address(4/16 Bytes) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Peer IP Address(4/16 Bytes) | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Additional Peer Info. | 211 // (From Peer ID to Peer IP Address) // 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2: Peer Address List TLV Format 215 Type: 2 Bytes, value is TBD. 217 Length: 2 Bytes, the length of the following fields. 219 Peer Num : 2 Bytes, Peer Address Number on the advertised router. 221 Peer-ID: 2 Bytes, to distinguish the different peer pair, will be 222 referenced in Peer Prefix Association, if the PCE use multi-BGP 223 solution for different QoS assurance requirement. 225 AT: 1 Bytes, Address Type. To indicate the address type of Peer. 226 Equal to 4, if the following IP address of peer is belong to IPv4; 227 Equal to 6 if the following IP address of peer is belong to IPv6. 229 Resv: 1 Bytes, Reserved for future use. 231 Local AS Number: 4 Bytes, to indicate the AS number of the Local 232 Peer. 234 Peer AS Number: 4 Bytes, to indicate the AS number of Remote Peer. 236 Local IP Address(4/16 Bytes): IPv4 address of the local router, used 237 to peer with other end router. When AT equal to 4, length is 32bit; 238 when AT equal to 16, length is 128bit. 240 Peer IP Address(4/16 Bytes): IPv4 address of the peer router, used to 241 peer with the local router. When AT equal to 4, length is 32bit; 242 IPv6 address of the peer when AT equal to 16, length is 128bit; 244 5.2. Peer Prefix Association TLV 246 The Peer Prefix Association TLV is defined to specify the IP prefixes 247 that should be advertised by the corresponding Peer. This TLV should 248 only be included and sent to the head/end router of the end2end path 249 in case there is no RR involved. If the RR is used between the head 250 and end routers, then such information should be sent to head 251 router,RR and end router respectively. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type=TBD | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Peer ID | AT | Prefixes Num | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Peer Associated IP Prefix sub TLV(Variable) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 3: Peer Prefix Association TLV Format 264 Type: 2 Bytes, value is TBD 266 Length: 2 Bytes, the length of the following fields. 268 Peer-ID: 2 Bytes, to indicate which peer should be used to advertise 269 the following IP Prefix TLV. This value is assigned in the Peer 270 Address List object and is referred in this object. 272 AT: 2 Bytes, Address Type. To indicate the address type of Peer. 273 Equal to 4, if the following IP address of peer is belong to IPv4; 274 Equal to 6 if the following IP address of peer is belong to IPv6. 276 Prefixes Num: 2 Bytes, number of prefixes that advertised by the 277 corresponding Peer. It should be equal to number of the following IP 278 prefix sub TLV. 280 Peer Associated IP Prefix sub TLV: Variable Length, indicate the 281 advertised IP Prefix. 283 5.2.1. Prefix sub TLV 285 Prefix sub TLV is used to carry the prefix information, which has the 286 following format: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type=TBD | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | AT | Prefix Length | Resv. | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Prefix Value | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 4: Prefix sub TLV Format 299 Type: 2 Bytes, value is TBD 301 Length: 2 Bytes, the length of the following fields. 303 AT: 1 Byte, Address Type. To indicate the address type of Peer. 304 Equal to 4, if the following "Prefix address" belong to IPv4; Equal 305 to 6 if the following "Prefix address" belong to IPv6. 307 Prefix Length: 1 Byte, the length of the following prefix. For 308 example, for 10.0.0.0/8, this field will be equal to 8. 310 Prefix Value: Variable length, the value of the prefix. For example, 311 for 10.0.0./8, this field will be 10.0.0.0 313 5.3. Explicit Peer Route TLV 315 The Explicit Peer Route TLV is defined to specify the explicit peer 316 route to the corresponding peer address on each device that is on the 317 E2E assurance path. This TLV should be sent to all the devices that 318 locates on the E2E assurance path that calculated by PCE. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type=TBD | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Peer ID | AT | Route Priority| 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Next Hop Address to the Peer(IPv4/IPv6) | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 5: Explicit Peer Route TLV 331 Type: 2 Bytes, value is TBD 333 Length: 2 Bytes, the length of following fields. 335 Peer-ID: 2 Bytes, to indicate the peer that the following next hop 336 address point to. This value is assigned in the Peer Address List 337 object and is referred in this object. 339 AT: 1 Byte, Address Type. To indicate the address type of explicit 340 peer route. Equal to 4, if the following next hop address to the 341 peer belongs to IPv4; Equal to 6 if the following next hop address to 342 the peer belongs to IPv6. 344 Route Priority: 1 Byte, The priority of this explicit route. The 345 higher priority should be preferred by the device. 347 Next Hop Address to the Peer: Variable Length, to indicate the next 348 hop address to the corresponding peer that indicated by the Peer-ID. 349 If AT=4, the length will be 4 bytes, if AT=6, the length will be 16 350 bytes. 352 6. Management Consideration 354 TBD 356 7. Security Considerations 358 TBD 360 8. IANA Considerations 362 8.1. CCI Object Type 364 IANA is requested to allocate new registry for the CCI Object Type: 366 Object-Type Value CCI Object Name Reference 367 3 Native IP This document 369 8.2. CCI Object Associated TLV 371 IANA is requested to confirm the early allocation of the following 372 TLV Type Indicator values within the "PCEP TLV Type Indicator" sub- 373 registry of the PCEP Numbers registry, and to update the reference in 374 the registry to point to this document, when it is an RFC: 376 Value Meaning Reference 377 --------------------------------------------------------- 378 TBD Peer Address List TLV This document 379 TBD Peer Prefix Association TLV This document 380 TBD Explicit Peer Route TLV This document 381 TBD Prefix sub TLV This document 383 9. Acknowledgement 385 Thanks Dhruv Dhody for his valuable suggestions and comments. 387 10. References 389 10.1. Normative References 391 [I-D.ietf-pce-pcep-extension-for-pce-controller] 392 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 393 and Protocol Extensions for Using PCE as a Central 394 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 395 extension-for-pce-controller-02 (work in progress), July 396 2019. 398 [I-D.ietf-teas-pce-native-ip] 399 Wang, A., Zhao, Q., Khasanov, B., Chen, H., and R. Mallya, 400 "PCE in Native IP Network", draft-ietf-teas-pce-native- 401 ip-03 (work in progress), April 2019. 403 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 404 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 405 DOI 10.17487/RFC5440, March 2009, 406 . 408 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 409 Architecture for Use of PCE and the PCE Communication 410 Protocol (PCEP) in a Network with Central Control", 411 RFC 8283, DOI 10.17487/RFC8283, December 2017, 412 . 414 10.2. Informative References 416 [I-D.ietf-teas-native-ip-scenarios] 417 Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, 418 "Scenarios and Simulation Results of PCE in Native IP 419 Network", draft-ietf-teas-native-ip-scenarios-06 (work in 420 progress), June 2019. 422 Authors' Addresses 424 Aijun Wang 425 China Telecom 426 Beiqijia Town, Changping District 427 Beijing, Beijing 102209 428 China 430 Email: wangaj3@chinatelecom.cn 432 Boris Khasanov 433 Huawei Technologies,Co.,Ltd 434 Moskovskiy Prospekt 97A 435 St.Petersburg 196084 436 Russia 438 Email: khasanov.boris@huawei.com 440 Sudhir Cheruathur 441 Juniper Networks 442 1133 Innovation Way 443 Sunnyvale, California 94089 444 USA 446 Email: scheruathur@juniper.net 448 Chun Zhu 449 ZTE Corporation 450 50 Software Avenue, Yuhua District 451 Nanjing, Jiangsu 210012 452 China 454 Email: zhu.chun1@zte.com.cn 456 Sheng Fang 457 Huawei Technologies, Co., Ltd 458 Huawei Bld., No.156 Beiqing Rd. 459 Beijing 460 China 462 Email: fsheng@huawei.com