idnits 2.17.1 draft-wang-pce-extension-native-ip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([I-D.draft-wang-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. -- Couldn't find a document date in the document -- date freshness check skipped. 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 112, but not defined == Missing Reference: 'RFC5440' is mentioned on line 128, but not defined == Unused Reference: 'RFC4655' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-pce-pce-initiated-lsp-07' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-teas-pce-control-function' is defined on line 338, 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 (-07) exists of draft-wang-teas-pce-native-ip-02 == Outdated reference: A later version (-05) exists of draft-ietf-teas-pce-central-control-01 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). 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 March 9,2017 11 Expires: September 8, 2017 13 PCEP Extension for Native IP Network 14 draft-wang-pce-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 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, and it may not be 24 published except as an Internet-Draft. 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. This document may not be modified, 28 and derivative works of it may not be created, except to publish it 29 as an RFC and to translate it into languages other than English. 31 It is for publication as an RFC or to translate it into languages 32 other than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on September8, 201717. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. 63 Abstract 65 This document defines the PCEP extension for PCE application in 66 Native IP network. The scenario and architecture of PCE in native IP 67 is described in [I-D.draft-wang-teas-pce-native-ip]. This draft 68 describes the key information that is transferred between PCE and 69 PCC to accomplish the end2end traffic assurance in Native IP network 70 under central control mode. 72 Table of Contents 74 1. Introduction ................................................ 2 75 2. Conventions used in this document ............................ 3 76 3. New Objects Extension......................................... 3 77 4. Object Formats. ............................................. 3 78 4.1. Peer Address List object................................ 4 79 4.2. Peer Prefix Association................................. 5 80 4.3. EXPLICIT PEER ROUTE Object.............................. 6 81 5. Management Consideration..................................... 7 82 6. Security Considerations...................................... 7 83 7. IANA Considerations ......................................... 7 84 8. Conclusions ................................................. 7 85 9. References .................................................. 7 86 9.1. Normative References .................................... 7 87 9.2. Informative References.................................. 8 88 10. Acknowledgments ............................................ 8 90 1. Introduction 92 Traditionally, MPLS-TE traffic assurance requires the corresponding 93 network devices support MPLS or the complex RSVP/LDP/Segment Routing 94 etc. technologies to assure the end-to-end traffic performance. But 95 in native IP network, there will be no such signaling protocol to 96 synchronize the action among different network devices. It is 97 necessary to use the central control mode that described in [I- 98 D.draft-ietf-teas-pce-control-function] to correlate the forwarding 99 behavior among different network devices. Draft [I-D.draft-wang- 100 teas-pce-native-ip] describes the architecture and solution 101 philosophy for the end2end traffic assurance in Native IP network 102 via Dual/Multi BGP solution. This draft describes the corresponding 103 PCEP extension to transfer the key information about peer address 104 list, peer prefix association and the explicit peer route on on-path 105 router. 107 2. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. New Objects Extension 115 Three new objects are defined in this draft; they are Peer Address 116 List Object (PAL Object), Peer Prefix Association Object (PPA Object) 117 and Explicit Peer Route object (EPR Object). 119 Peer Address List object is used to tell the network device which 120 peer it should be peered with dynamically, Peer Prefix Association 121 is used to tell which prefixes should be advertised via the 122 corresponding peer and Explicit Peer Route object is used to point 123 out which route should be to taken to arrive to the peer. 125 4. Object Formats. 127 Each extension object takes the similar format, that is to say, it 128 began with the common object header defined in [RFC5440] as the 129 following: 131 0 1 2 3 133 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Object-Class | OT |Res|P|I| Object Length (bytes) | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 // (Object body) // 144 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Different object-class, object type and the corresponding object 149 body is defined separated in the following section. 151 4.1. Peer Address List object. 153 The Peer Address List object is used in a PCE Initiate message 154 [draft-ietf-pce-pce-initiated-lsp] to specify the ip address of peer 155 that the received network device should establish the BGP 156 relationship with. 158 This Object should only be sent to the head and end router of the 159 end2end path in case there is no RR involved. If the RR is used 160 between the head end routers, then such information should be sent 161 to head router/RR and end router/RR respectively. 163 Peer Address List object Object-Class is ** 165 Peer Address List object Object-Type is ** 167 0 1 2 3 169 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Peer Num | Peer-Id | AT | Resv. 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Local IP Address(4/16 Bytes) | 179 // Peer IP Address(4/16 Bytes) // 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Peer Num (8 bits): Peer Address Number on the advertised router. 185 Peer-Id(8 bits): To distinguish the different peer pair, will be 186 referenced in Peer Prefix Association, if the PCE use multi-BGP 187 solution for different QoS assurance requirement. 189 AT(8 bits): Address Type. To indicate the address type of Peer. 190 Equal to 4, if the following IP address of peer is belong to IPv4; 191 Equal to 6 if the following IP address of peer is belong to IPv6. 193 Resv(8 bits): Reserved for future use. 195 Local IP Address(4/16 Bytes): IPv4 address of the local router, used 196 to peer with other end router. When AT equal to 4, length is 32bit; 197 when AT equal to 16, length is 128bit; 199 Peer IP Address(4/16 Bytes): IPv4 address of the peer router, used 200 to peer with the local router. When AT equal to 4, length is 32bit; 201 IPv6 address of the peer when AT equal to 16, length is 128bit; 203 4.2. Peer Prefix Association 205 THE Peer Prefix Association object is carried within in a PCE 206 Initiate message [draft-ietf-pce-pce-initiated-lsp] to specify the 207 IP prefixes that should be advertised by the corresponding Peer. 209 This Object should only be sent to the head and end router of the 210 end2end path in case there is no RR involved. If the RR is used 211 between the head end routers, then such information should be sent 212 to head router/RR and end router/RR respectively. 214 Peer Prefix Association object Object-Class is ** 216 Peer Prefix Association object Object-Type is ** 218 0 1 2 3 220 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Peer-Id | AT | Resv. | Prefixes Num. 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Peer Associated IP Prefix TLV | 230 // Peer Associated IP Prefix TLV // 232 | Peer Associated IP Prefix TLV | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Peer-Id(8 bits): To indicate which peer should be used to advertise 236 the following IP Prefix TLV. This value is assigned in the Peer 237 Address List object and is referred in this object. 239 AT(8 bits): Address Type. To indicate the address type of Peer. 240 Equal to 4, if the following IP address of peer is belong to IPv4; 241 Equal to 6 if the following IP address of peer is belong to IPv6. 243 Resv(8 bits): Reserved for future use. 245 Prefixes Num(8 bits): Number of prefixes that advertised by the 246 corresponding Peer. It should be equal to num of the following IP 247 prefix TLV. 249 Peer Associated IP Prefix TLV: Variable Length, use the TLV format 250 to indicate the advertised IP Prefix. 252 4.3. EXPLICIT PEER ROUTE Object 254 THE EXPLICIT PEER ROUTE Object is carried in a PCE Initiate message 255 [draft-ietf-pce-pce-initiated-lsp] to specify the explicit peer 256 route to the corresponding peer address on each device that is on 257 the end2end assurance path. 259 This Object should be sent to all the devices that locates on the 260 end2end assurance path that calculated by PCE. 262 EXPLICIT PEER ROUTE Object Object-Class is ** 264 EXPLICIT PEER ROUTE Object Object-Type is ** 266 0 1 2 3 268 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Peer-Id | AT | Resv. | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Next Hop Address to the Peer (IPv4/IPv6) | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Peer-Id(8 bits): To indicate the peer that the following next hop 280 address point to. This value is assigned in the Peer Address List 281 object and is referred in this object. 283 AT(8 bits): Address Type. To indicate the address type of explicit 284 peer route. Equal to 4, if the following next hop address to the 285 peer is belong to IPv4; Equal to 6 if the following next hop 286 address to the peer is belong to IPv6. 288 Resv(16 bits): Reserved for future use. 290 Next Hop Address to the Peer TLV: Variable Length, use the TLV 291 format to indicate the next hop address to the corresponding peer 292 that indicated by the Peer-Id. 294 5. Management Consideration. 296 6. Security Considerations 298 TBD 300 7. IANA Considerations 302 TBD 304 8. Conclusions 306 TBD 308 9. References 310 9.1. Normative References 312 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 314 Computation Element (PCE)-Based Architecture", RFC 316 4655, August 2006,. 318 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 320 Computation Element (PCE) Communication Protocol 322 (PCEP)", RFC 5440, March 2009, 323 . 325 9.2. Informative References 327 [I-D.draft-ietf-pce-pce-initiated-lsp-07] 328 E.Crabbe, I.Minei, S.Sivabalan, R.Varga, "PCEP Extensions for PCE- 329 initiated LSP Setup in a Stateful PCE Model", 330 https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 331 (work in progress), July, 2016 333 [I-D.draft-wang-teas-pce-native-ip] 334 Aijun Wang, Quintin Zhao, Boris Khasanov, Raghavendra Mallya, Shaofu 335 Peng "PCE in Native IP Network", https://tools.ietf.org/html/draft- 336 wang-teas-pce-native-ip-02(work in progress), March, 2017 338 [I-D.draft-ietf-teas-pce-control-function] 339 Farrel, Q.Zhao "An Architecture for use of PCE and PCEP in a Network 340 with Central Control" 341 https://tools.ietf.org/html/draft-ietf-teas-pce-central-control-01 343 (work in progress),December, 2016 345 10. Acknowledgments 347 TBD 349 Authors' Addresses 351 Aijun Wang 352 China Telecom 353 Beiqijia Town, Changping District 354 Beijing,China 356 Email: wangaj.bri@chinatelecom.cn 358 Boris Khasanov 359 Huawei Technologies 360 Moskovskiy Prospekt 97A 361 St.Petersburg 196084 362 Russia 364 EMail: khasanov.boris@huawei.com 365 Sudhir Cheruathur 366 Juniper Networks 367 1133 Innovation Way 368 Sunnyvale, California 94089 USA 370 Email: scheruathur@juniper.net 372 Chun Zhu 373 ZTE Corporation 374 50 Software Avenue, Yuhua District 375 Nanjing, Jiangsu 210012 376 China 377 Email:zhu.chun1@zte.com.cn