idnits 2.17.1 draft-zhuang-bess-enhanced-vpn-auto-discovery-02.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 date (November 6, 2018) is 1992 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) -- No information found for draft-li-mpls-global- - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Shunwan Zhuang 2 Intended status: Proposed Standard Zhenbin Li 3 Donald Eastlake 4 Huawei 5 Lucy Yong 6 Independent 7 Expires: May 5, 2018 November 6, 2018 9 BGP Extensions for Enhanced VPN Auto Discovery 10 draft-zhuang-bess-enhanced-vpn-auto-discovery-02.txt 12 Abstract 14 A variety of VPN technologies have been widely deployed to bear 15 different services. As new applications develop, a requirement has 16 been proposed for auto-discovery of Layer 3 Virtual Private Networks 17 (L3VPN) and enhanced auto-discovery requirements for other VPN 18 technologies that already have basic auto-discovery mechanisms. 20 This document identifies some possible applications of these auto- 21 discovery requirements and defines a new BGP NLRI, called the BGP- 22 VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of 23 BGP VPN instances. It also defines a new type of extended community, 24 called the Import Route Target, which can be applied to auto- 25 discovery mechanisms of multiple VPN technologies. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Distribution of this document is unlimited. Comments should be sent 33 to the authors or the BESS working group mailing list: bess@ietf.org. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 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 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 47 Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 Table of Contents 52 1. Introduction............................................3 53 2. Terminologies...........................................4 55 3. Requirements of VPN Auto-Discovery......................5 56 3.1 Centralized Traffic Optimization.......................5 57 3.2 Label/Segment Allocation for VPN Instance..............5 59 4. IRT Extended Community..................................6 61 5. BGP Extensions for L3VPN Auto-Discovery.................7 62 5.1 BGP-VPN-INSTANCE SAFI..................................7 63 5.2 BGP-VPN-INSTANCE NLRI..................................8 64 5.2.1 VPN Membership A-D Route.............................8 65 5.3 Procedures............................................9 67 6. IANA Considerations....................................10 68 6.1 BGP Extended Communities..............................10 69 6.2 Subsequent Address Family Identifier..................10 71 7. Security Considerations................................11 73 Contributors..............................................11 74 Acknowledgements..........................................11 76 Normative References......................................12 77 Informative References....................................13 79 Authors' Addresses........................................14 81 1. Introduction 83 A variety of VPN technologies have been widely deployed to bear 84 different services. As new applications develop, a requirement has 85 been proposed for auto-discovery of Layer 3 Virtual Private Networks 86 (L3VPN) [RFC4364] and enhanced auto-discovery requirements for other 87 VPN technologies which already have basic auto-discovery mechanisms. 89 This document identifies some possible applications of these auto- 90 discovery requirements and defines a new BGP NLRI [RFC4271], called 91 the BGP-VPN-INSTANCE NLRI, to satisfy the requirement of auto- 92 discovery of BGP VPN instance. It also defines a new type of extended 93 community, called the Import Route Target (IRT), which can be applied 94 to auto-discovery mechanisms of multiple VPN technologies. 96 2. Terminologies 98 This document uses the terminologies defined in [RFC4026]: 100 AFI: Address Family Identifier 102 ERT: Export Route Target 104 IRT: Import Route Target 106 LSP: Label Switched Path 108 NLRI: Network Layer Reachability Information 110 PE: Provider Edge 112 RD: Route Distinguisher 114 VRF: Virtual Routing and Forwarding 116 VPN A-D: VPN Auto-Discovery 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 3. Requirements of VPN Auto-Discovery 126 The following subsections are examples of VPN Auto-Discovery 127 requirements. 129 3.1 Centralized Traffic Optimization 131 As the development of centrally controlled application such as PCE- 132 initiated LSP [RFC8281] and PCE-initiated P2MP LSP [I-D.palle-pce- 133 stateful-pce-initiated-p2mp-lsp], PCE can be used to initiate setup 134 of RSVP-TE LSP or P2MP LSP for the purpose of traffic optimization. 135 In order to support such applications, the controller should learn 136 the relationship of unicast VPN instances or multicast VPN instances 137 distributed on different PEs. According to the existing VPN auto- 138 discovery mechanism for technologies such as EVPN [RFC7432] or MVPN 139 [RFC6514], the A-D routes are always advertised with the Export Route 140 Target (ERT). The ingress PE can use an Import Route Target (IRT) of 141 the local MVPN/EVPN instance to match the route target advertised 142 with the NLRI to determine the relationship of these VPN instances. 143 But the controller, which can be used as the route reflector of VPN 144 routes, cannot learn the relationship of VPN instances since the 145 Import Route Target information is not advertised with these A-D 146 routes. In order to support such applications the IRT should be 147 carried with A-D routes. 149 3.2 Label/Segment Allocation for VPN Instance 151 [I-D.li-mpls-global-label-usecases] proposes use cases of label 152 allocation for unicast VPN or multicast VPN instances. [I-D.li- 153 spring-segment-path-programming] proposes use cases of segment 154 allocation for steering traffic. In order to support such 155 applications the PEs needs to learn the relationship of VPN instances 156 distributed on other PEs. For L3VPN [RFC4364] there is no auto- 157 discovery mechanism for BGP VPN instances. In order to support such 158 applications, an auto-discovery mechanism should be introduced for 159 L3VPN. 161 4. IRT Extended Community 163 This document defines a new type of transitive extended community, 164 called as Import Route Target. 166 The IANA registry of BGP Extended Communities clearly identifies 167 communities of specific formats: "Two-octet AS Specific Extended 168 Community" [RFC4360], "Four-octet AS Specific Extended Community" 169 [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360]. 170 Route Targets [RFC4360] extended community identify this format in 171 the high-order (Type) octet of the Extended Community. The Import 172 Route Target extended community will reuses the same mechanism. 174 This document defines the following IRT Extended Communities: 176 +------+------+--------------+-------------------------------------+ 177 | | Sub- | Extended | | 178 | Type | Type | Community | Encoding | 179 +------+------+--------------+-------------------------------------+ 180 | 0x00 | TBD1 | AS-2byte IRT | 2-octet AS, 4-octet Value | 181 | 0x01 | TBD2 | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value | 182 | 0x02 | TBD3 | AS-4byte IRT | 4-octet AS, 2-octet Value | 183 +------+------+--------------+-------------------------------------+ 185 Figure 1. IRT Extended Communities 187 The IRT Extended Community can be used for MVPN [RFC6514], L3VPN 188 [RFC4364], EVPN [RFC7432], BGP-based VPLS [RFC4761], and BGP-AD-based 189 VPLS [RFC6074] and the like. The existing auto-discovery mechanisms 190 of these VPN technologies always carry the ERT extended community. 191 To meet the requirements of applications, they need to carry the IRT 192 extended community with different A-D routes. The local policy, 193 which is out of scope of this document, can be used to control the 194 distribution of IRT information. 196 5. BGP Extensions for L3VPN Auto-Discovery 198 5.1 BGP-VPN-INSTANCE SAFI 200 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 201 from multiple "address families". In this document a new Subsequent 202 Address Family is specified, called "BGP-VPN-INSTANCE Sub Address 203 Family", which uses a specific BGP-VPN-INSTANCE-SAFI (TBD4). 205 This document also defines a new BGP NLRI, called the BGP-VPN- 206 INSTANCE NLRI to support the BGP VPN instance auto-discovery. BGP- 207 VPN-INSTANCE MP_REACH_NLRI and MP_UNREACH_NLRI (shown in Figures 2 208 and 3) are formatted as described in [RFC4760]. The BGP-VPN-INSTANCE 209 NLRI is described in more detail in Section 5.2. 211 +-------------------------------------------------------+ 212 | Address Family Identifier: 1/2/25 (2 octets) | 213 +---------------------------+---------------------------+ 214 | Subsequent AFI: | (1 octet) 215 | BGP-VPN-INSTANCE-SAFI=TBD4| 216 +---------------------------+ 217 | Length of Next Hop | (1 octet) 218 +---------------------------+---... 219 | Next Hop (variable) 220 +---------------------------+---... 221 | Reserved | (1 octet) 222 +---------------------------+---... 223 | BGP-VPN-INSTANCE NLRI (variable) 224 +-------------------------------... 226 Figure 2. BGP-VPN-INSTANCE MP_REACH_NLRI 228 +-------------------------------------------------------+ 229 | Address Family Identifier: 1/2/25 (2 octets) | 230 +---------------------------+---------------------------+ 231 | Subsequent AFI: | (1 octet) 232 | BGP-VPN-INSTANCE-SAFI=TBD4| 233 +---------------------------+---... 234 | BGP-VPN-INSTANCE NLRI (variable) 235 +-------------------------------... 237 Figure 3. BGP-VPN-INSTANCE MP_UNREACH_NLRI 239 5.2 BGP-VPN-INSTANCE NLRI 241 The following is the format of the BGP-VPN-INSTANCE NLRI. 243 +---------------------------+ 244 | Route Type | (1 octet) 245 +---------------------------+ 246 | Length | (1 octet) 247 +---------------------------+---... 248 | Route Type Specific (variable) | 249 +---------------------------------------------------+ 251 Figure 4. BGP-VPN-INSTANCE NLRI 253 The Route Type field specifies the encoding of the rest of BGP-VPN- 254 INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI). 256 The Length field indicates the length in octets of the Route Type 257 specific field of the BGP-VPN-INSTANCE NLRI. 259 This document defines the following Route Types for BGP-VPN-INSTANCE 260 routes: 262 Type 1: VPN Membership A-D Route 264 5.2.1 VPN Membership A-D Route 266 The VPN Membership A-D Route is utilized for VPN Membership Auto- 267 Discovery between PEs. Its format is shown in Figure 5. 269 +-------------------------------------... 270 | Local Router's IP Address (variable) 271 +----------------------------------------+ 272 | RD | (8 octets) 273 +----------------------------------------+ 275 Figure 5. VPN Membership A-D Route 277 a) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. 279 b) RD: RD of one VRF on advertising PE, encoded as described in 280 [RFC4364]. 282 5.3 Procedures 284 Every PE needs to process all its VRF configuration and generate one 285 VPN Membership A-D Route for each VRF respectively. The Local 286 Router's IP Address field MUST be filled with the Advertising 287 Router's IP address. The RD field MUST be filled with the VRF's RD 288 value. 290 All ERTs of the VRF MUST be carried in a BGP Update's RT Extended 291 Community Path Attribute with the Membership A-D Route for the VRF. 292 To meet the requirements of different applications, all IRTs of the 293 VRF SHOULD be able to be carried in BGP Update's IRT Extended 294 Community Path Attribute with the VPN Membership A-D Route for the 295 VRF. 297 If a VRF is created, then its corresponding VPN Membership A-D Route 298 MUST be generated and advertised. 300 If the VRF whose VPN Membership A-D Route has been advertised is 301 deleted, then the VPN Membership A-D Route Withdraw message MUST be 302 generated and advertised. 304 If IRTs or ERTs of the VRF whose VPN Membership A-D Route has been 305 advertised are changed, then a VPN Membership A-D Route Update with 306 same Prefix and latest IRTs or ERTs MUST be advertised. 308 When the receiving PE receives a VPN Membership A-D Route, VPN 309 relationship matching MUST be checked with the IRTs carried in the 310 VPN Membership A-D Route and ERTs of each Local VRF. 312 When the central controller receives a VPN Membership A-D Route, VPN 313 relationship matching MUST be checked with IRTs and ERTs carried in 314 VPN Membership A-D Routes of different VPN instances. 316 6. IANA Considerations 318 6.1 BGP Extended Communities 320 IANA is requested to assign three BGP Extended Community Sub-Types as 321 shown below. 323 Transitive Two-Octet AS-Specific Extended Community Sub-Type 324 Sub-Type Description Reference 325 -------- --------------------- --------------- 326 TBD1 Import Route Target [this document] 328 Transitive IPv4-Address-Specific Extended Community Sub-Type 329 Sub-Type Description Reference 330 -------- --------------------- --------------- 331 TBD2 Import Route Target [this document] 333 Transitive Four-Octet AS-Specific Extended Community Sub-Type 334 Sub-Type Description Reference 335 -------- --------------------- --------------- 336 TBD3 Import Route Target [this document] 338 6.2 Subsequent Address Family Identifier 340 IANA is requested to assign a Subsequent Address Family Identifier 341 (SAFI) from the First Come First Served range as follows: 343 Value Description Reference 344 ----- --------------------- --------------- 345 TBD4 BGP-VPN-INSTANCE-SAFI [this document] 347 7. Security Considerations 349 TBD 351 Contributors 353 The following people have substantially contributed to the solution 354 and to the editing of this document:. 356 Hui Ni 357 Huawei Technologies 358 Email: nihui@huawei.com 360 Acknowledgements 362 The authors would like to thank Shuanglong Chen, Eric Wu for their 363 contributions to this work. 365 Normative References 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, DOI 369 10.17487/RFC2119, March 1997, . 372 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 373 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 374 10.17487/RFC4271, January 2006, . 377 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 378 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 379 February 2006, . 381 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 382 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 383 2006, . 385 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 386 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 387 10.17487/RFC4760, January 2007, . 390 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 391 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 392 RFC 4761, DOI 10.17487/RFC4761, January 2007, 393 . 395 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 396 Specific BGP Extended Community", RFC 5668, DOI 397 10.17487/RFC5668, October 2009, . 400 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 401 "Provisioning, Auto-Discovery, and Signaling in Layer 2 402 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 403 10.17487/RFC6074, January 2011, . 406 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 407 Encodings and Procedures for Multicast in MPLS/BGP IP 408 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 409 . 411 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 412 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 413 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 414 2015, . 416 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 417 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 418 2017, . 420 Informative References 422 [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T., 423 Raszuk, R., and L. Fang, "Usecases of MPLS Global Label", 424 draft-li-mpls-global- label-usecases-03 (work in progress), 425 October 2015. 427 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 428 Private Network (VPN) Terminology", RFC 4026, DOI 429 10.17487/RFC4026, March 2005, . 432 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 433 Computation Element Communication Protocol (PCEP) 434 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 435 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 436 . 438 Authors' Addresses 440 Shunwan Zhuang 441 Huawei Technologies 442 Huawei Building, No.156 Beiqing Rd. 443 Beijing. 100095 China 445 Email: zhuangshunwan@huawei.com 447 Zhenbin Li 448 Huawei Technologies 449 Huawei Building, No.156 Beiqing Rd. 450 Beijing, 100095 China 452 Email: lizhenbin@huawei.com 454 Donald Eastlake 455 Huawei Technologies 456 1424 Pro Shop Court 457 Davenport, FL 33896 USA 459 Phone: +1-508-333-2270 460 Email: d3e3e3@gmail.com 462 Lucy Yong 463 Independent 464 USA 466 Phone: +1-469-227-5837 467 Email: lucyyong@gmail.com 469 Copyright, Disclaimer, and Additional IPR Provisions 471 Copyright (c) 2018 IETF Trust and the persons identified as the 472 document authors. All rights reserved. 474 This document is subject to BCP 78 and the IETF Trust's Legal 475 Provisions Relating to IETF Documents 476 (http://trustee.ietf.org/license-info) in effect on the date of 477 publication of this document. Please review these documents 478 carefully, as they describe your rights and restrictions with respect 479 to this document. Code Components extracted from this document must 480 include Simplified BSD License text as described in Section 4.e of 481 the Trust Legal Provisions and are provided without warranty as 482 described in the Simplified BSD License.