idnits 2.17.1 draft-zhuang-bess-enhanced-vpn-auto-discovery-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 date (March 26, 2018) is 2222 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: September 25, 2018 March 26, 2018 9 BGP Extensions for Enhanced VPN Auto Discovery 10 draft-zhuang-bess-enhanced-vpn-auto-discovery-01.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 75 Acknowledgements..........................................11 77 Normative References......................................12 78 Informative References....................................13 80 Authors' Addresses........................................14 82 1. Introduction 84 A variety of VPN technologies have been widely deployed to bear 85 different services. As new applications develop, a requirement has 86 been proposed for auto-discovery of Layer 3 Virtual Private Networks 87 (L3VPN) [RFC4364] and enhanced auto-discovery requirements for other 88 VPN technologies which already have basic auto-discovery mechanisms. 90 This document identifies some possible applications of these auto- 91 discovery requirements and defines a new BGP NLRI [RFC4271], called 92 the BGP-VPN-INSTANCE NLRI, to satisfy the requirement of auto- 93 discovery of BGP VPN instance. It also defines a new type of extended 94 community, called the Import Route Target (IRT), which can be applied 95 to auto-discovery mechanisms of multiple VPN technologies. 97 2. Terminologies 99 This document uses the terminologies defined in [RFC4026]: 101 AFI: Address Family Identifier 103 ERT: Export Route Target 105 IRT: Import Route Target 107 LSP: Label Switched Path 109 NLRI: Network Layer Reachability Information 111 PE: Provider Edge 113 RD: Route Distinguisher 115 VRF: Virtual Routing and Forwarding 117 VPN A-D: VPN Auto-Discovery 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 3. Requirements of VPN Auto-Discovery 127 The following subsections are examples of VPN Auto-Discovery 128 requirements. 130 3.1 Centralized Traffic Optimization 132 As the development of centrally controlled application such as PCE- 133 initiated LSP [RFC8281] and PCE-initiated P2MP LSP [I-D.palle-pce- 134 stateful-pce-initiated-p2mp-lsp], PCE can be used to initiate setup 135 of RSVP-TE LSP or P2MP LSP for the purpose of traffic optimization. 136 In order to support such applications, the controller should learn 137 the relationship of unicast VPN instances or multicast VPN instances 138 distributed on different PEs. According to the existing VPN auto- 139 discovery mechanism for technologies such as EVPN [RFC7432] or MVPN 140 [RFC6514], the A-D routes are always advertised with the Export Route 141 Target (ERT). The ingress PE can use an Import Route Target (IRT) of 142 the local MVPN/EVPN instance to match the route target advertised 143 with the NLRI to determine the relationship of these VPN instances. 144 But the controller, which can be used as the route reflector of VPN 145 routes, cannot learn the relationship of VPN instances since the 146 Import Route Target information is not advertised with these A-D 147 routes. In order to support such applications the IRT should be 148 carried with A-D routes. 150 3.2 Label/Segment Allocation for VPN Instance 152 [I-D.li-mpls-global-label-usecases] proposes use cases of label 153 allocation for unicast VPN or multicast VPN instances. [I-D.li- 154 spring-segment-path-programming] proposes use cases of segment 155 allocation for steering traffic. In order to support such 156 applications the PEs needs to learn the relationship of VPN instances 157 distributed on other PEs. For L3VPN [RFC4364] there is no auto- 158 discovery mechanism for BGP VPN instances. In order to support such 159 applications, an auto-discovery mechanism should be introduced for 160 L3VPN. 162 4. IRT Extended Community 164 This document defines a new type of transitive extended community, 165 called as Import Route Target. 167 The IANA registry of BGP Extended Communities clearly identifies 168 communities of specific formats: "Two-octet AS Specific Extended 169 Community" [RFC4360], "Four-octet AS Specific Extended Community" 170 [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360]. 171 Route Targets [RFC4360] extended community identify this format in 172 the high-order (Type) octet of the Extended Community. The Import 173 Route Target extended community will reuses the same mechanism. 175 This document defines the following IRT Extended Communities: 177 +------+------+--------------+-------------------------------------+ 178 | | Sub- | Extended | | 179 | Type | Type | Community | Encoding | 180 +------+------+--------------+-------------------------------------+ 181 | 0x00 | TBD1 | AS-2byte IRT | 2-octet AS, 4-octet Value | 182 | 0x01 | TBD2 | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value | 183 | 0x02 | TBD3 | AS-4byte IRT | 4-octet AS, 2-octet Value | 184 +------+------+--------------+-------------------------------------+ 186 Figure 1. IRT Extended Communities 188 The IRT Extended Community can be used for MVPN [RFC6514], L3VPN 189 [RFC4364], EVPN [RFC7432], BGP-based VPLS [RFC4761], and BGP-AD-based 190 VPLS [RFC6074] and the like. The existing auto-discovery mechanisms 191 of these VPN technologies always carry the ERT extended community. 192 To meet the requirements of applications, they need to carry the IRT 193 extended community with different A-D routes. The local policy, 194 which is out of scope of this document, can be used to control the 195 distribution of IRT information. 197 5. BGP Extensions for L3VPN Auto-Discovery 199 5.1 BGP-VPN-INSTANCE SAFI 201 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 202 from multiple "address families". In this document a new Subsequent 203 Address Family is specified, called "BGP-VPN-INSTANCE Sub Address 204 Family", which uses a specific BGP-VPN-INSTANCE-SAFI (TBD4). 206 This document also defines a new BGP NLRI, called the BGP-VPN- 207 INSTANCE NLRI to support the BGP VPN instance auto-discovery. BGP- 208 VPN-INSTANCE MP_REACH_NLRI and MP_UNREACH_NLRI (shown in Figures 2 209 and 3) are formatted as described in [RFC4760]. The BGP-VPN-INSTANCE 210 NLRI is described in more detail in Section 5.2. 212 +-------------------------------------------------------+ 213 | Address Family Identifier: 1/2/25 (2 octets) | 214 +---------------------------+---------------------------+ 215 | Subsequent AFI: | (1 octet) 216 | BGP-VPN-INSTANCE-SAFI=TBD4| 217 +---------------------------+ 218 | Length of Next Hop | (1 octet) 219 +---------------------------+---... 220 | Next Hop (variable) 221 +---------------------------+---... 222 | Reserved | (1 octet) 223 +---------------------------+---... 224 | BGP-VPN-INSTANCE NLRI (variable) 225 +-------------------------------... 227 Figure 2. BGP-VPN-INSTANCE MP_REACH_NLRI 229 +-------------------------------------------------------+ 230 | Address Family Identifier: 1/2/25 (2 octets) | 231 +---------------------------+---------------------------+ 232 | Subsequent AFI: | (1 octet) 233 | BGP-VPN-INSTANCE-SAFI=TBD4| 234 +---------------------------+---... 235 | BGP-VPN-INSTANCE NLRI (variable) 236 +-------------------------------... 238 Figure 3. BGP-VPN-INSTANCE MP_UNREACH_NLRI 240 5.2 BGP-VPN-INSTANCE NLRI 242 The following is the format of the BGP-VPN-INSTANCE NLRI. 244 +---------------------------+ 245 | Route Type | (1 octet) 246 +---------------------------+ 247 | Length | (1 octet) 248 +---------------------------+---... 249 | Route Type Specific (variable) | 250 +---------------------------------------------------+ 252 Figure 4. BGP-VPN-INSTANCE NLRI 254 The Route Type field specifies the encoding of the rest of BGP-VPN- 255 INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI). 257 The Length field indicates the length in octets of the Route Type 258 specific field of the BGP-VPN-INSTANCE NLRI. 260 This document defines the following Route Types for BGP-VPN-INSTANCE 261 routes: 263 Type 1: VPN Membership A-D Route 265 5.2.1 VPN Membership A-D Route 267 The VPN Membership A-D Route is utilized for VPN Membership Auto- 268 Discovery between PEs. Its format is shown in Figure 5. 270 +-------------------------------------... 271 | Local Router's IP Address (variable) 272 +----------------------------------------+ 273 | RD | (8 octets) 274 +----------------------------------------+ 276 Figure 5. VPN Membership A-D Route 278 a) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. 280 b) RD: RD of one VRF on advertising PE, encoded as described in 281 [RFC4364]. 283 5.3 Procedures 285 Every PE needs to process all its VRF configuration and generate one 286 VPN Membership A-D Route for each VRF respectively. The Local 287 Router's IP Address field MUST be filled with the Advertising 288 Router's IP address. The RD field MUST be filled with the VRF's RD 289 value. 291 All ERTs of the VRF MUST be carried in a BGP Update's RT Extended 292 Community Path Attribute with the Membership A-D Route for the VRF. 293 To meet the requirements of different applications, all IRTs of the 294 VRF SHOULD be able to be carried in BGP Update's IRT Extended 295 Community Path Attribute with the VPN Membership A-D Route for the 296 VRF. 298 If a VRF is created, then its corresponding VPN Membership A-D Route 299 MUST be generated and advertised. 301 If the VRF whose VPN Membership A-D Route has been advertised is 302 deleted, then the VPN Membership A-D Route Withdraw message MUST be 303 generated and advertised. 305 If IRTs or ERTs of the VRF whose VPN Membership A-D Route has been 306 advertised are changed, then a VPN Membership A-D Route Update with 307 same Prefix and latest IRTs or ERTs MUST be advertised. 309 When the receiving PE receives a VPN Membership A-D Route, VPN 310 relationship matching MUST be checked with the IRTs carried in the 311 VPN Membership A-D Route and ERTs of each Local VRF. 313 When the central controller receives a VPN Membership A-D Route, VPN 314 relationship matching MUST be checked with IRTs and ERTs carried in 315 VPN Membership A-D Routes of different VPN instances. 317 6. IANA Considerations 319 6.1 BGP Extended Communities 321 IANA is requested to assign three BGP Extended Community Sub-Types as 322 shown below. 324 Transitive Two-Octet AS-Specific Extended Community Sub-Type 325 Sub-Type Description Reference 326 -------- --------------------- --------------- 327 TBD1 Import Route Target [this document] 329 Transitive IPv4-Address-Specific Extended Community Sub-Type 330 Sub-Type Description Reference 331 -------- --------------------- --------------- 332 TBD2 Import Route Target [this document] 334 Transitive Four-Octet AS-Specific Extended Community Sub-Type 335 Sub-Type Description Reference 336 -------- --------------------- --------------- 337 TBD3 Import Route Target [this document] 339 6.2 Subsequent Address Family Identifier 341 IANA is requested to assign a Subsequent Address Family Identifier 342 (SAFI) from the First Come First Served range as follows: 344 Value Description Reference 345 ----- --------------------- --------------- 346 TBD4 BGP-VPN-INSTANCE-SAFI [this document] 348 7. Security Considerations 350 TBD 352 Contributors 354 The following people have substantially contributed to the solution 355 and to the editing of this document:. 357 Hui Ni 358 Huawei Technologies 359 Email: nihui@huawei.com 361 Acknowledgements 363 The authors would like to thank Shuanglong Chen, Eric Wu for their 364 contributions to this work. 366 Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, DOI 370 10.17487/RFC2119, March 1997, . 373 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 374 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 375 10.17487/RFC4271, January 2006, . 378 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 379 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 380 February 2006, . 382 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 383 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 384 2006, . 386 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 387 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 388 10.17487/RFC4760, January 2007, . 391 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 392 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 393 RFC 4761, DOI 10.17487/RFC4761, January 2007, 394 . 396 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 397 Specific BGP Extended Community", RFC 5668, DOI 398 10.17487/RFC5668, October 2009, . 401 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 402 "Provisioning, Auto-Discovery, and Signaling in Layer 2 403 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 404 10.17487/RFC6074, January 2011, . 407 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 408 Encodings and Procedures for Multicast in MPLS/BGP IP 409 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 410 . 412 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 413 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 414 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 415 2015, . 417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 418 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 419 2017, . 421 Informative References 423 [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T., 424 Raszuk, R., and L. Fang, "Usecases of MPLS Global Label", 425 draft-li-mpls-global- label-usecases-03 (work in progress), 426 October 2015. 428 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 429 Private Network (VPN) Terminology", RFC 4026, DOI 430 10.17487/RFC4026, March 2005, . 433 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 434 Computation Element Communication Protocol (PCEP) 435 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 436 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 437 . 439 Authors' Addresses 441 Shunwan Zhuang 442 Huawei Technologies 443 Huawei Building, No.156 Beiqing Rd. 444 Beijing. 100095 China 446 Email: zhuangshunwan@huawei.com 448 Zhenbin Li 449 Huawei Technologies 450 Huawei Building, No.156 Beiqing Rd. 451 Beijing, 100095 China 453 Email: lizhenbin@huawei.com 455 Donald Eastlake 456 Huawei Technologies 457 155 Beaver Street 458 Milford, MA 01757 USA 460 Phone: +1-508-333-2270 461 Email: d3e3e3@gmail.com 463 Lucy Yong 464 Independent 465 USA 467 Phone: +1-469-227-5837 468 Email: lucyyong@gmail.com 470 Copyright, Disclaimer, and Additional IPR Provisions 472 Copyright (c) 2018 IETF Trust and the persons identified as the 473 document authors. All rights reserved. 475 This document is subject to BCP 78 and the IETF Trust's Legal 476 Provisions Relating to IETF Documents 477 (http://trustee.ietf.org/license-info) in effect on the date of 478 publication of this document. Please review these documents 479 carefully, as they describe your rights and restrictions with respect 480 to this document. Code Components extracted from this document must 481 include Simplified BSD License text as described in Section 4.e of 482 the Trust Legal Provisions and are provided without warranty as 483 described in the Simplified BSD License.