idnits 2.17.1 draft-wang-pce-extension-native-ip-00.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 : ---------------------------------------------------------------------------- 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. -- 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 110, but not defined == Missing Reference: 'RFC5440' is mentioned on line 125, but not defined == Unused Reference: 'RFC4655' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-ietf-pce-pce-initiated-lsp-07' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-wang-teas-pce-native-ip-01' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-zhao-teas-pce-control-function' is defined on line 334, 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-01 Summary: 1 error (**), 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 8 Intended status: Standard Track October 24,2016 9 Expires: April 23, 2017 11 PCEP Extension for Native IP Network 12 draft-wang-pce-extension-native-ip-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may not be modified, 21 and derivative works of it may not be created, and it may not be 22 published except as an Internet-Draft. 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, except to publish it 27 as an RFC and to translate it into languages other than English. 29 It is for publication as an RFC or to translate it into languages 30 other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on April 24, 2017. 49 Copyright Notice 51 Copyright (c) 2016 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. 61 Abstract 63 This document defines the PCEP extension for PCE application in 64 Native IP network. The scenario and architecture of PCE in native IP 65 is described in [I-D.draft-wang-teas-pce-native-ip-01.txt]. This 66 draft describes the key information that is transferred between PCE 67 and PCC to accomplish the end2end traffic assurance in Native IP 68 network under central control mode. 70 Table of Contents 72 1. Introduction ................................................... 2 73 2. Conventions used in this document ...............................3 74 3. New Objects Extension .......................................... 3 75 4. Object Formats. ................................................ 3 76 4.1. BGP PEER Object.............................................4 77 4.2. BGP PREFIX Object...........................................5 78 4.3. STATICROUTE Object .........................................6 79 5. Management Consideration.........................................7 80 6. Security Considerations..........................................7 81 7. IANA Considerations .............................................7 82 8. Conclusions .....................................................7 83 9. References ......................................................7 84 9.1. Normative References........................................7 85 9.2. Informative References......................................7 86 10. Acknowledgments ................................................8 88 1. Introduction 90 Traditionally, MPLS-TE traffic assurance requires the corresponding 91 network devices support MPLS or the complex RSVP/LDP/Segment Routing 92 etc. technologies to assure the end-to-end traffic performance. But 93 in native IP network, there will be no such signaling protocol to 94 synchronize the action among different network devices. It is 95 necessary to use the central control mode that described in [I- 96 D.draft-zhao-teas-pce-control-function] to correlate the forwarding 97 behavior among different network devices. Draft [I-D.draft-wang- 98 teas-pce-native-ip-00.txt] describes the architecture and solution 99 philosophy for the end2end traffic assurance in Native IP network 100 via Dual/Multi BGP solution. This draft describes the corresponding 101 PCEP extension to transfer the key information about BGP peer 102 relationship, BGP Prefix advertised and the static route on on-path 103 router. 105 2. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. New Objects Extension 113 Three new objects are defined in this draft, they are BGP PEER 114 object, BGP PREFIX object and STATICROUTE object. 116 BGP PEER object is used to tell the network device which peer it 117 should be peered with dynamically, BGP PREFIX object is used to tell 118 which prefixes should be advertised via the corresponding BGP peer 119 and STATICROUTE object is used to point out which route should be to 120 taken to arrive to the bgp peer. 122 4. Object Formats. 124 Each extension object takes the similar format, that is to say, it 125 began with the common object header defined in [RFC5440] as the 126 following: 128 0 1 2 3 130 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Object-Class | OT |Res|P|I| Object Length (bytes) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 140 // (Object body) // 142 | | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Different object-class, object type and the corresponding object 146 body is defined separated in the following section. 148 4.1. BGP PEER Object. 150 The BGP PEER object is used in a PCE Initiate message [draft-ietf- 151 pce-pce-initiated-lsp] to specify the ip address of BGP peer that 152 the received network device should establish the BGP relationship 153 with. 155 This Object should only be sent to the head and end router of the 156 end2end path in case there is no RR involved. If the RR is used 157 between the head end routers, then such information should be sent 158 to head router/RR and end router/RR respectively. 160 BGP PEER Object Object-Class is ** 162 BGP PEER Object Object-Type is ** 164 0 1 2 3 166 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Peer-Id | AT |Resv. 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | IP Address of BGP Peer(4/16 Bytes) | 176 // IP Address of BGP Peer(4/16 Bytes) // 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Peer-Id(8 bits): To distinguish the different BGP Peer, will be 181 referenced in BGP PREFIX object, if the PCE use multiBGP solution 182 for different QoS assurance requirement. 184 AT(8 bits): Address Type. To indicate the address type of BGP Peer. 185 Equal to 4, if the following IP address of BGP peer is belong to 186 IPv4; Equal to 6 if the following IP address of BGP peer is belong 187 to IPv6. 189 Resv(16 bits): Reserved for future use. 191 IP Address of BGP Peer(4/16 Bytes): IPv4 address of the BGP peer 192 when AT equal to 4, length is 32bit; IPv6 address of the BGP peer 193 when AT equal to 16, length is 128bit; 195 4.2. BGP PREFIX Object 197 THE BGP PREFIX object is carried within in a PCE Initiate message 198 [draft-ietf-pce-pce-initiated-lsp] to specify the IP prefixes that 199 should be advertised by the corresponding BGP Peer. 201 This Object should only be sent to the head and end router of the 202 end2end path in case there is no RR involved. If the RR is used 203 between the head end routers, then such information should be sent 204 to head router/RR and end router/RR respectively. 206 BGP PREFIX Object Object-Class is ** 208 BGP PREFIX Object Object-Type is ** 210 0 1 2 3 212 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Peer-Id | AT | Resv. | Prefixes Num. 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | BGP Advertised IP Prefix TLV | 222 // BGP Advertised IP Prefix TLV // 224 | BGP Advertised IP Prefix TLV | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Peer-Id(8 bits): To indicate which BGP peer should be used to 229 advertise the following IP Prefix TLV. This value is assigned in 230 the BGP PEER object and is referred in this object. 232 AT(8 bits): Address Type. To indicate the address type of BGP Peer. 233 Equal to 4, if the following IP address of BGP peer is belong to 234 IPv4; Equal to 6 if the following IP address of BGP peer is belong 235 to IPv6. 237 Resv(8 bits): Reserved for future use. 239 Prefixes Num(8 bits): Number of prefixes that advertised by the 240 corresponding BGP Peer. It should be equal to num of the following 241 IP prefix TLV. 243 BGP Advertised IP Prefix TLV: Variable Length, use the TLV format to 244 indicate the advertised IP Prefix. 246 4.3. STATICROUTE Object 248 THE STATICROUTE Object is carried in a PCE Initiate message [draft- 249 ietf-pce-pce-initiated-lsp] to specify the static route to the 250 corresponding BGP peer address on each device that is on the end2end 251 assurance path. 253 This Object should be sent to all the devices that locates on the 254 end2end assurance path that calculated by PCE. 256 STATICROUTE Object Object-Class is ** 258 STATICROUTE Object Object-Type is ** 260 0 1 2 3 262 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Peer-Id | AT | Resv. | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Next Hop Address to the BGP Peer (IPv4/IPv6) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Peer-Id(8 bits): To indicate the BGP peer that the following next 275 hop address point to. This value is assigned in the BGP PEER 276 object and is referred in this object. 278 AT(8 bits): Address Type. To indicate the address type of 279 staticroute. Equal to 4, if the following next hop address to the 280 BGP peer is belong to IPv4; Equal to 6 if the following next hop 281 address to the BGP peer is belong to IPv6. 283 Resv(16 bits): Reserved for future use. 285 Next Hop Address to the BGP Peer TLV: Variable Length, use the TLV 286 format to indicate the next hop address to the corresponding BGP 287 peer that indicated by the Peer-Id. 289 5. Management Consideration. 291 6. Security Considerations 293 TBD 295 7. IANA Considerations 297 TBD 299 8. Conclusions 301 TBD 303 9. References 305 9.1. Normative References 307 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 309 Computation Element (PCE)-Based Architecture", RFC 311 4655, August 2006,. 313 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 315 Computation Element (PCE) Communication Protocol 317 (PCEP)", RFC 5440, March 2009, 319 . 321 9.2. Informative References 323 [I-D.draft-ietf-pce-pce-initiated-lsp-07] 324 E.Crabbe, I.Minei, S.Sivabalan, R.Varga, "PCEP Extensions for PCE- 325 initiated LSP Setup in a Stateful PCE Model", 326 https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 327 (work in progress), July, 2016 329 [I-D.draft-wang-teas-pce-native-ip-01] 330 Aijun Wang, Quintin Zhao, Boris Khasanov, Raghavendra Mallya, "PCE 331 in Native IP Network", https://tools.ietf.org/html/draft-wang-teas- 332 pce-native-ip-01(work in progress),October, 2016 334 [I-D.draft-zhao-teas-pce-control-function] 335 Farrel, Q.Zhao "An Architecture for use of PCE and PCEP in a Network 336 with Central Control" 337 https://datatracker.ietf.org/doc/draft-zhao-teas-pce-control- 338 function/ (work in progress),June, 2016 340 10. Acknowledgments 342 TBD 344 Authors' Addresses 346 Aijun Wang 347 China Telecom 348 Beiqijia Town, Changping District 349 Beijing,China 351 Email: wangaj@ctbri.com.cn 353 Boris Khasanov 354 Huawei Technologies 355 Moskovskiy Prospekt 97A 356 St.Petersburg 196084 357 Russia 359 EMail: khasanov.boris@huawei.com 361 Sudhir Cheruathur 362 Juniper Networks 363 1133 Innovation Way 364 Sunnyvale, California 94089 USA 366 Email: scheruathur@juniper.net