idnits 2.17.1 draft-ietf-pce-pcep-extension-native-ip-01.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 26, 2018) is 2130 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 93, but not defined == Missing Reference: 'RFC5440' is mentioned on line 110, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-teas-native-ip-scenarios-00 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-native-ip-scenarios (ref. 'I-D.ietf-teas-native-ip-scenarios') == Outdated reference: A later version (-17) exists of draft-ietf-teas-pce-native-ip-00 ** 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: 4 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: December 28, 2018 Huawei 6 S. Cheruathur 7 Juniper Networks 8 C. Zhu 9 ZTE Corporation 10 June 26, 2018 12 PCEP Extension for Native IP Network 13 draft-ietf-pce-pcep-extension-native-ip-01 15 Abstract 17 This document defines the PCEP extension for CCDR application in 18 Native IP network. The scenario and architecture of CCDR in native 19 IP is described in [I-D.ietf-teas-native-ip-scenarios] and 20 [I-D.ietf-teas-pce-native-ip]. This draft describes the key 21 information that is transferred between PCE and PCC to accomplish the 22 end2end traffic assurance in Native IP network under central control 23 mode. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 28, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 2 61 3. New Objects Extension . . . . . . . . . . . . . . . . . . . . 3 62 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.1. Peer Address List object . . . . . . . . . . . . . . . . 3 64 4.2. Peer Prefix Association . . . . . . . . . . . . . . . . . 4 65 4.3. 4.3. Explicit Peer Route Object . . . . . . . . . . . . . 5 66 5. Management Consideration . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Traditionally, MPLS-TE traffic assurance requires the corresponding 75 network devices support MPLS or the complex RSVP/LDP/Segment Routing 76 etc. technologies to assure the end-to-end traffic performance. But 77 in native IP network, there will be no such signaling protocol to 78 synchronize the action among different network devices. It is 79 necessary to use the central control mode that described in [RFC8283] 80 to correlate the forwarding behavior among different network devices. 81 Draft [I-D.ietf-teas-pce-native-ip] describes the architecture and 82 solution philosophy for the end2end traffic assurance in Native IP 83 network via Dual/Multi BGP solution. This draft describes the 84 corresponding PCEP extension to transfer the key information about 85 peer address list, peer prefix association and the explicit peer 86 route on on-path router. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 3. New Objects Extension 96 Three new objects are defined in this draft: 98 o PAL Object: Peer Address List Object, used to tell the network 99 device which peer it should be peered with dynamically 101 o PPA Object: Peer Prefix Association Object,used to tell which 102 prefixes should be advertised via the corresponding peer 104 o EPR Objec: Explicit Peer Route object,used to point out which 105 route should be taken to arrive to the peer. 107 4. Object Formats 109 Each extension object takes the similar format, that is to say, it 110 began with the common object header defined in [RFC5440] as the 111 following: 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Object-Class | OT |Res|P|I| Object Length(bytes) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | (Object body) | 119 // // 120 | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 Different object-class, object type and the corresponding object body 124 is defined separated in the following section. 126 4.1. Peer Address List object 128 The Peer Address List object is used in a PCE Initiate 129 message[RFC8281] [draft-ietf-pce-pce-initiated-lsp] to specify the ip 130 address of peer that the received network device should establish the 131 BGP relationship with. This Object should only be sent to the head 132 and end router of the end2end path in case there is no RR involved. 133 If the RR is used between the head and end routers, then such 134 information should be sent to head router/RR and end router/RR 135 respectively. 137 Peer Address List object Object-Class is ** 139 Peer Address List object Object-Type is ** 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Peer Num | Peer-Id | AT | Resv. | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Local IP Address(4/16 Bytes) | 146 // Peer IP Address(4/16 Bytes) // 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Peer Num (8 bits): Peer Address Number on the advertised router. 151 Peer-Id(8 bits): To distinguish the different peer pair, will be 152 referenced in Peer Prefix Association, if the PCE use multi-BGP 153 solution for different QoS assurance requirement. 155 AT(8 bits): Address Type. To indicate the address type of Peer. 156 Equal to 4, if the following IP address of peer is belong to IPv4; 157 Equal to 6 if the following IP address of peer is belong to IPv6. 159 Resv(8 bits): Reserved for future use. 161 Local IP Address(4/16 Bytes): IPv4 address of the local router, used 162 to peer with other end router. When AT equal to 4, length is 32bit; 163 when AT equal to 16, length is 128bit. 165 Peer IP Address(4/16 Bytes): IPv4 address of the peer router, used to 166 peer with the local router. When AT equal to 4, length is 32bit; 167 IPv6 address of the peer when AT equal to 16, length is 128bit; 169 4.2. Peer Prefix Association 171 The Peer Prefix Association object is carried within in a PCE 172 Initiate message [RFC8281] to specify the IP prefixes that should be 173 advertised by the corresponding Peer. This Object should only be 174 sent to the head and end router of the end2end path in case there is 175 no RR involved. If the RR is used between the head and end routers, 176 then such information should be sent to head router/RR and end 177 router/RR respectively. 179 Peer Prefix Association object Object-Class is ** 181 Peer Prefix Association object Object-Type is ** 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Peer Id | AT | Resv. | Prefixes Num. | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Peer Associated IP Prefix TLV | 188 // Peer Associated IP Prefix TLV // 189 | Peer Associated IP Prefix TLV | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Peer-Id(8 bits): To indicate which peer should be used to advertise 193 the following IP Prefix TLV. This value is assigned in the Peer 194 Address List object and is referred in this object. 196 AT(8 bits): Address Type. To indicate the address type of Peer. 197 Equal to 4, if the following IP address of peer is belong to IPv4; 198 Equal to 6 if the following IP address of peer is belong to IPv6. 200 Resv(8 bits): Reserved for future use. 202 Prefixes Num(8 bits): Number of prefixes that advertised by the 203 corresponding Peer. It should be equal to number of the following IP 204 prefix TLV. 206 Peer Associated IP Prefix TLV: Variable Length, use the TLV format to 207 indicate the advertised IP Prefix. 209 4.3. 4.3. Explicit Peer Route Object 211 The Explicit Peer Route Object is carried in a PCE Initiate message 212 [RFC8281] to specify the explicit peer route to the corresponding 213 peer address on each device that is on the end2end assurance path. 214 This Object should be sent to all the devices that locates on the 215 end2end assurance path that calculated by PCE. 217 Explict Peer Route Object Object-Class is ** 219 Explict Peer Route Object Object-Type is ** 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Peer Id | AT | Resv. | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Next Hop Address to the Peer(IPv4/IPv6) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Peer-Id(8 bits): To indicate the peer that the following next hop 229 address point to. This value is assigned in the Peer Address List 230 object and is referred in this object. 232 AT(8 bits): Address Type. To indicate the address type of explicit 233 peer route. Equal to 4, if the following next hop address to the 234 peer is belong to IPv4; Equal to 6 if the following next hop address 235 to the peer is belong to IPv6. Resv(16 bits): Reserved for future 236 use. 238 Next Hop Address to the Peer TLV: Variable Length, use the TLV format 239 to indicate the next hop address to the corresponding peer that 240 indicated by the Peer-Id. 242 5. Management Consideration 244 TBD 246 6. Security Considerations 248 TBD 250 7. IANA Considerations 252 TBD 254 8. Normative References 256 [I-D.ietf-teas-native-ip-scenarios] 257 Wang, A., Huang, X., Qou, C., Huang, L., and K. Mi, "CCDR 258 Scenario, Simulation and Suggestion", draft-ietf-teas- 259 native-ip-scenarios-00 (work in progress), February 2018. 261 [I-D.ietf-teas-pce-native-ip] 262 Wang, A., Zhao, Q., Khasanov, B., and K. Mi, "PCE in 263 Native IP Network", draft-ietf-teas-pce-native-ip-00 (work 264 in progress), February 2018. 266 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 267 Computation Element Communication Protocol (PCEP) 268 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 269 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 270 . 272 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 273 Architecture for Use of PCE and the PCE Communication 274 Protocol (PCEP) in a Network with Central Control", 275 RFC 8283, DOI 10.17487/RFC8283, December 2017, 276 . 278 Authors' Addresses 280 Aijun Wang 281 China Telecom 282 Beiqijia Town, Changping District 283 Beijing, Beijing 102209 284 China 286 Email: wangaj.bri@chinatelecom.cn 288 Boris Khasanov 289 Huawei Technologies,Co.,Ltd 290 Moskovskiy Prospekt 97A 291 St.Petersburg 196084 292 Russia 294 Email: khasanov.boris@huawei.com 296 Sudhir Cheruathur 297 Juniper Networks 298 1133 Innovation Way 299 Sunnyvale, California 94089 300 USA 302 Email: scheruathur@juniper.net 304 Chun Zhu 305 ZTE Corporation 306 50 Software Avenue, Yuhua District 307 Nanjing, Jiangsu 210012 308 China 310 Email: zhu.chun1@zte.com.cn