idnits 2.17.1 draft-wang-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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 14, 2018) is 2262 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 95, but not defined == Missing Reference: 'RFC5440' is mentioned on line 111, but not defined == Unused Reference: 'RFC4655' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-pce-pce-initiated-lsp-07' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-teas-pce-control-function' is defined on line 332, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-07 == Outdated reference: A later version (-05) exists of draft-ietf-teas-pce-central-control-01 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group A.Wang 2 Internet Draft China Telecom 3 Boris Khasanov 4 Huawei Technologies 5 Sudhir Cheruathur 6 Juniper Networks 7 Chun Zhu 8 ZTE Company 10 Intended status: Standard Track February 14, 2018 11 Expires: August 13, 2018 13 PCEP Extension for Native IP Network 14 draft-wang-pce-pcep-extension-native-ip-01.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 13, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 49 This document defines the PCEP extension for CCDR application in 50 Native IP network. The scenario and architecture of CCDR in native 51 IP is described in [draft-ietf-teas-native-ip-scenarios] and [draft- 52 ietf-teas-pce-native-ip]. This draft describes the key information 53 that is transferred between PCE and PCC to accomplish the end2end 54 traffic assurance in Native IP network under central control mode. 56 Table of Contents 58 1. Introduction ................................................ 2 59 2. Conventions used in this document............................ 2 60 3. New Objects Extension........................................ 3 61 4. Object Formats. ............................................. 3 62 4.1. Peer Address List object................................ 3 63 4.2. Peer Prefix Association................................. 4 64 4.3. EXPLICIT PEER ROUTE Object.............................. 6 65 5. Management Consideration..................................... 6 66 6. Security Considerations...................................... 7 67 7. IANA Considerations ......................................... 7 68 8. Conclusions ................................................. 7 69 9. References .................................................. 7 70 9.1. Normative References.................................... 7 71 9.2. Informative References.................................. 7 72 10. Acknowledgments ............................................ 8 74 1. Introduction 76 Traditionally, MPLS-TE traffic assurance requires the corresponding 77 network devices support MPLS or the complex RSVP/LDP/Segment Routing 78 etc. technologies to assure the end-to-end traffic performance. But 79 in native IP network, there will be no such signaling protocol to 80 synchronize the action among different network devices. It is 81 necessary to use the central control mode that described in [draft- 82 ietf-teas-pce-control-function] to correlate the forwarding behavior 83 among different network devices. Draft [draft-ietf-teas-pce-native- 84 ip] describes the architecture and solution philosophy for the 85 end2end traffic assurance in Native IP network via Dual/Multi BGP 86 solution. This draft describes the corresponding PCEP extension to 87 transfer the key information about peer address list, peer prefix 88 association and the explicit peer route on on-path router. 90 2. Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 3. New Objects Extension 98 Three new objects are defined in this draft; they are Peer Address 99 List Object (PAL Object), Peer Prefix Association Object (PPA Object) 100 and Explicit Peer Route object (EPR Object). 102 Peer Address List object is used to tell the network device which 103 peer it should be peered with dynamically, Peer Prefix Association 104 is used to tell which prefixes should be advertised via the 105 corresponding peer and Explicit Peer Route object is used to point 106 out which route should be to taken to arrive to the peer. 108 4. Object Formats. 110 Each extension object takes the similar format, that is to say, it 111 began with the common object header defined in [RFC5440] as the 112 following: 114 0 1 2 3 116 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Object-Class | OT |Res|P|I| Object Length (bytes) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | | 126 // (Object body) // 128 | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Different object-class, object type and the corresponding object 133 body is defined separated in the following section. 135 4.1. Peer Address List object. 137 The Peer Address List object is used in a PCE Initiate message 138 [draft-ietf-pce-pce-initiated-lsp] to specify the ip address of peer 139 that the received network device should establish the BGP 140 relationship with. 142 This Object should only be sent to the head and end router of the 143 end2end path in case there is no RR involved. If the RR is used 144 between the head end routers, then such information should be sent 145 to head router/RR and end router/RR respectively. 147 Peer Address List object Object-Class is ** 149 Peer Address List object Object-Type is ** 151 0 1 2 3 153 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Peer Num | Peer-Id | AT | Resv. 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Local IP Address(4/16 Bytes) | 163 // Peer IP Address(4/16 Bytes) // 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Peer Num (8 bits): Peer Address Number on the advertised router. 169 Peer-Id(8 bits): To distinguish the different peer pair, will be 170 referenced in Peer Prefix Association, if the PCE use multi-BGP 171 solution for different QoS assurance requirement. 173 AT(8 bits): Address Type. To indicate the address type of Peer. 174 Equal to 4, if the following IP address of peer is belong to IPv4; 175 Equal to 6 if the following IP address of peer is belong to IPv6. 177 Resv(8 bits): Reserved for future use. 179 Local IP Address(4/16 Bytes): IPv4 address of the local router, used 180 to peer with other end router. When AT equal to 4, length is 181 32bit; when AT equal to 16, length is 128bit; 183 Peer IP Address(4/16 Bytes): IPv4 address of the peer router, used 184 to peer with the local router. When AT equal to 4, length is 32bit; 185 IPv6 address of the peer when AT equal to 16, length is 128bit; 187 4.2. Peer Prefix Association 189 THE Peer Prefix Association object is carried within in a PCE 190 Initiate message [draft-ietf-pce-pce-initiated-lsp] to specify the 191 IP prefixes that should be advertised by the corresponding Peer. 193 This Object should only be sent to the head and end router of the 194 end2end path in case there is no RR involved. If the RR is used 195 between the head end routers, then such information should be sent 196 to head router/RR and end router/RR respectively. 198 Peer Prefix Association object Object-Class is ** 200 Peer Prefix Association object Object-Type is ** 202 0 1 2 3 204 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Peer-Id | AT | Resv. | Prefixes Num. 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Peer Associated IP Prefix TLV | 214 // Peer Associated IP Prefix TLV // 216 | Peer Associated IP Prefix TLV | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Peer-Id(8 bits): To indicate which peer should be used to advertise 221 the following IP Prefix TLV. This value is assigned in the Peer 222 Address List object and is referred in this object. 224 AT(8 bits): 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(8 bits): Reserved for future use. 230 Prefixes Num(8 bits): Number of prefixes that advertised by the 231 corresponding Peer. It should be equal to num of the following IP 232 prefix TLV. 234 Peer Associated IP Prefix TLV: Variable Length, use the TLV format 235 to indicate the advertised IP Prefix. 237 4.3. EXPLICIT PEER ROUTE Object 239 THE EXPLICIT PEER ROUTE Object is carried in a PCE Initiate message 240 [draft-ietf-pce-pce-initiated-lsp] to specify the explicit peer 241 route to the corresponding peer address on each device that is on 242 the end2end assurance path. 244 This Object should be sent to all the devices that locates on the 245 end2end assurance path that calculated by PCE. 247 EXPLICIT PEER ROUTE Object Object-Class is ** 249 EXPLICIT PEER ROUTE Object Object-Type is ** 251 0 1 2 3 253 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Peer-Id | AT | Resv. | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Next Hop Address to the Peer (IPv4/IPv6) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Peer-Id(8 bits): To indicate the peer that the following next hop 266 address point to. This value is assigned in the Peer Address List 267 object and is referred in this object. 269 AT(8 bits): Address Type. To indicate the address type of explicit 270 peer route. Equal to 4, if the following next hop address to the 271 peer is belong to IPv4; Equal to 6 if the following next hop 272 address to the peer is belong to IPv6. 274 Resv(16 bits): Reserved for future use. 276 Next Hop Address to the Peer TLV: Variable Length, use the TLV 277 format to indicate the next hop address to the corresponding peer 278 that indicated by the Peer-Id. 280 5. Management Consideration. 282 6. Security Considerations 284 TBD 286 7. IANA Considerations 288 TBD 290 8. Conclusions 292 TBD 294 9. References 296 9.1. Normative References 298 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 300 Computation Element (PCE)-Based Architecture", RFC 302 4655, August 2006,. 304 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 306 Computation Element (PCE) Communication Protocol 308 (PCEP)", RFC 5440, March 2009, 310 . 312 9.2. Informative References 314 [I-D.draft-ietf-pce-pce-initiated-lsp-07] 315 E.Crabbe, I.Minei, S.Sivabalan, R.Varga, "PCEP Extensions for PCE- 316 initiated LSP Setup in a Stateful PCE Model", 317 https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 318 (work in progress), July, 2016 320 [I-D. draft-ietf-teas-native-ip-scenarios] 321 Wang, X.Huang et al. "CCDR Scenario, Simulation and Suggestion" 322 https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip- 323 scenarios/ (work in progress), February, 2018 325 [I-D. draft-ietf-teas-pce-native-ip] 326 Aijun Wang, Quintin Zhao, Boris Khasanov, Huaimo Chen,Raghavendra 327 Mallya, Shaofu Peng "PCE in Native IP Network", 328 https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/ 330 (work in progress), February, 2018 332 [I-D.draft-ietf-teas-pce-control-function] 333 Farrel, Q.Zhao "An Architecture for use of PCE and PCEP in a Network 334 with Central Control" 335 https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-01 337 (work in progress),December, 2016 339 10. Acknowledgments 341 TBD 343 Authors' Addresses 345 Aijun Wang 346 China Telecom 347 Beiqijia Town, Changping District 348 Beijing,China 350 Email: wangaj.bri@chinatelecom.cn 352 Boris Khasanov 353 Huawei Technologies 354 Moskovskiy Prospekt 97A 355 St.Petersburg 196084 356 Russia 358 EMail: khasanov.boris@huawei.com 360 Sudhir Cheruathur 361 Juniper Networks 362 1133 Innovation Way 363 Sunnyvale, California 94089 USA 365 Email: scheruathur@juniper.net 367 Chun Zhu 368 ZTE Corporation 369 50 Software Avenue, Yuhua District 370 Nanjing, Jiangsu 210012 371 China 372 Email:zhu.chun1@zte.com.cn