idnits 2.17.1 draft-zhuang-bess-enhanced-vpn-auto-discovery-08.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 (July 9, 2021) is 1021 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 issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Zhuang 2 Intended status: Proposed Standard Z. Li 3 Huawei Technologies 4 D. Eastlake 5 Futurewei Technologies 6 L. Yong 7 Independent 8 Expires: January 8, 2022 July 9, 2021 10 BGP Extensions for Enhanced VPN Auto Discovery 11 draft-zhuang-bess-enhanced-vpn-auto-discovery-08.txt 13 Abstract 15 A variety of VPN technologies have been widely deployed to bear 16 different services. As new applications develop, a requirement has 17 been proposed for auto-discovery of Layer 3 Virtual Private Networks 18 (L3VPN) and enhanced auto-discovery requirements for other VPN 19 technologies that already have basic auto-discovery mechanisms. 21 This document identifies some possible applications of these auto- 22 discovery requirements and defines a new BGP NLRI, called the BGP- 23 VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of 24 BGP VPN instances. It also defines a new type of extended community, 25 called the Import Route Target, which can be applied to auto- 26 discovery mechanisms of multiple VPN technologies. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Distribution of this document is unlimited. Comments should be sent 34 to the authors or the BESS working group mailing list: bess@ietf.org. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 https://www.ietf.org/shadow.html. 51 Table of Contents 53 1. Introduction............................................3 54 2. Terminologies...........................................4 56 3. Requirements of VPN Auto-Discovery......................5 57 3.1 Centralized Traffic Optimization.......................5 58 3.2 Label/Segment Allocation for VPN Instance..............5 60 4. IRT Extended Community..................................6 62 5. BGP Extensions for L3VPN Auto-Discovery.................7 63 5.1 BGP-VPN-INSTANCE SAFI..................................7 64 5.2 BGP-VPN-INSTANCE NLRI..................................8 65 5.2.1 VPN Membership A-D Route.............................8 66 5.3 Procedures............................................9 68 6. IANA Considerations....................................10 69 6.1 BGP Extended Communities..............................10 70 6.2 Subsequent Address Family Identifier..................10 72 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 A-D: Auto-Discovery 102 AFI: Address Family Identifier 104 ERT: Export Route Target 106 IRT: Import Route Target 108 LSP: Label Switched Path 110 NLRI: Network Layer Reachability Information 112 P2MP: Point to Multi-Point 114 PE: Provider Edge 116 RD: Route Distinguisher 118 VRF: Virtual Routing and Forwarding 120 VPN A-D: VPN Auto-Discovery 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 3. Requirements of VPN Auto-Discovery 130 The following subsections are examples of VPN Auto-Discovery 131 requirements. 133 3.1 Centralized Traffic Optimization 135 As the development of centrally controlled application such as PCE- 136 initiated LSP [RFC8281] and PCE-initiated P2MP LSP [RFC8623], PCE can 137 be used to initiate setup of RSVP-TE LSP or P2MP LSP for the purpose 138 of traffic optimization. In order to support such applications, the 139 controller should learn the relationship of unicast VPN instances or 140 multicast VPN instances distributed on different PEs. According to 141 the existing VPN auto-discovery mechanism for technologies such as 142 EVPN [RFC7432] or MVPN [RFC6514], the A-D routes are always 143 advertised with the Export Route Target (ERT). The ingress PE can 144 use an Import Route Target (IRT) of the local MVPN/EVPN instance to 145 match the route target advertised with the NLRI to determine the 146 relationship of these VPN instances. But the controller, which can 147 be used as the route reflector of VPN routes, cannot learn the 148 relationship of VPN instances since the Import Route Target 149 information is not advertised with these A-D routes. In order to 150 support such applications the IRT can be carried with A-D routes as 151 specified below. 153 3.2 Label/Segment Allocation for VPN Instance 155 [I-D.li-mpls-global-label-usecases] proposes use cases of label 156 allocation for unicast VPN or multicast VPN instances. 157 [I-D.li-spring-segment-path-programming] proposes use cases of 158 segment allocation for steering traffic. In order to support such 159 applications the PEs needs to learn the relationship of VPN instances 160 distributed on other PEs. For L3VPN [RFC4364] there is no auto- 161 discovery mechanism for BGP VPN instances. In order to support such 162 applications, an auto-discovery mechanism for L3VPN is specified 163 below. 165 4. IRT Extended Community 167 This document defines a new type of transitive extended community, 168 called Import Route Target. 170 The IANA registry of BGP Extended Communities clearly identifies 171 communities of specific formats: "Two-octet AS Specific Extended 172 Community" [RFC4360], "Four-octet AS Specific Extended Community" 173 [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360]. 174 Route Target [RFC4360] extended communities identify this format in 175 the high-order (Type) octet of the Extended Community. The Import 176 Route Target extended community reuses the same mechanism. 178 This document defines the following IRT Extended Communities: 180 +------+------+--------------+-------------------------------------+ 181 | | Sub- | Extended | | 182 | Type | Type | Community | Encoding | 183 +------+------+--------------+-------------------------------------+ 184 | 0x00 | TBD1 | AS-2byte IRT | 2-octet AS, 4-octet Value | 185 | 0x01 | TBD2 | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value | 186 | 0x02 | TBD3 | AS-4byte IRT | 4-octet AS, 2-octet Value | 187 +------+------+--------------+-------------------------------------+ 189 Figure 1. IRT Extended Communities 191 The IRT Extended Community can be used for MVPN [RFC6514], L3VPN 192 [RFC4364], EVPN [RFC7432], BGP-based VPLS [RFC4761], and BGP-AD-based 193 VPLS [RFC6074] and the like. The existing auto-discovery mechanisms 194 of these VPN technologies always carry the ERT extended community. 195 To meet the requirements of applications, they need to carry the IRT 196 extended community with different A-D routes. The local policy, 197 which is out of scope of this document, can be used to control the 198 distribution of IRT information. 200 5. BGP Extensions for L3VPN Auto-Discovery 202 5.1 BGP-VPN-INSTANCE SAFI 204 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 205 from multiple "address families". In this document a new Subsequent 206 Address Family is specified, called "BGP-VPN-INSTANCE Sub Address 207 Family", which uses a specific BGP-VPN-INSTANCE-SAFI (TBD4). 209 This document also defines a new BGP NLRI, called the BGP-VPN- 210 INSTANCE NLRI to support the BGP VPN instance auto-discovery. BGP- 211 VPN-INSTANCE MP_REACH_NLRI and MP_UNREACH_NLRI (shown in Figures 2 212 and 3) are formatted as described in [RFC4760]. The BGP-VPN-INSTANCE 213 NLRI is described in more detail in Section 5.2. 215 +-------------------------------------------------------+ 216 | Address Family Identifier: 1/2/25 (2 octets) | 217 +---------------------------+---------------------------+ 218 | Subsequent AFI: | (1 octet) 219 | BGP-VPN-INSTANCE-SAFI=TBD4| 220 +---------------------------+ 221 | Length of Next Hop | (1 octet) 222 +---------------------------+---... 223 | Next Hop (variable) 224 +---------------------------+---... 225 | Reserved | (1 octet) 226 +---------------------------+---... 227 | BGP-VPN-INSTANCE NLRI (variable) 228 +-------------------------------... 230 Figure 2. BGP-VPN-INSTANCE MP_REACH_NLRI 232 +-------------------------------------------------------+ 233 | Address Family Identifier: 1/2/25 (2 octets) | 234 +---------------------------+---------------------------+ 235 | Subsequent AFI: | (1 octet) 236 | BGP-VPN-INSTANCE-SAFI=TBD4| 237 +---------------------------+---... 238 | BGP-VPN-INSTANCE NLRI (variable) 239 +-------------------------------... 241 Figure 3. BGP-VPN-INSTANCE MP_UNREACH_NLRI 243 5.2 BGP-VPN-INSTANCE NLRI 245 The following is the format of the BGP-VPN-INSTANCE NLRI. 247 +---------------------------+ 248 | Route Type | (1 octet) 249 +---------------------------+ 250 | Length | (1 octet) 251 +---------------------------+---... 252 | Route Type Specific (variable) | 253 +---------------------------------------------------+ 255 Figure 4. BGP-VPN-INSTANCE NLRI 257 The Route Type field specifies the encoding of the rest of 258 BGP-VPN-INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI). 260 The Length field indicates the length in octets of the Route Type 261 specific field of the BGP-VPN-INSTANCE NLRI. 263 This document defines the following Route Type for BGP-VPN-INSTANCE 264 routes: 266 Type 1: VPN Membership A-D Route 268 5.2.1 VPN Membership A-D Route 270 The VPN Membership A-D Route is utilized for VPN Membership A-D 271 between PEs. Its format is shown in Figure 5. 273 +-------------------------------------... 274 | Local Router's IP Address (variable) 275 +----------------------------------------+ 276 | RD | (8 octets) 277 +----------------------------------------+ 279 Figure 5. VPN Membership A-D Route 281 a) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. 283 b) RD: RD of one VRF on the advertising PE, encoded as described 284 in [RFC4364]. 286 5.3 Procedures 288 Every PE needs to process all its VRF configuration and generate one 289 VPN Membership A-D Route for each VRF respectively. The Local 290 Router's IP Address field MUST be filled with the Advertising 291 Router's IP address. The RD field MUST be filled with the VRF's RD 292 value. 294 All ERTs of the VRF MUST be carried in a BGP Update's RT Extended 295 Community Path Attribute with the Membership A-D Route for the VRF. 296 To meet the requirements of different applications, all IRTs of the 297 VRF SHOULD be able to be carried in BGP Update's IRT Extended 298 Community Path Attribute with the VPN Membership A-D Route for the 299 VRF. 301 If a VRF is created, then its corresponding VPN Membership A-D Route 302 MUST be generated and advertised. 304 If the VRF whose VPN Membership A-D Route has been advertised is 305 deleted, then the VPN Membership A-D Route Withdraw message MUST be 306 generated and advertised. 308 If IRTs or ERTs of the VRF whose VPN Membership A-D Route has been 309 advertised are changed, then a VPN Membership A-D Route Update with 310 same Prefix and latest IRTs or ERTs MUST be advertised. 312 When the receiving PE receives a VPN Membership A-D Route, VPN 313 relationship matching MUST be checked with the IRTs carried in the 314 VPN Membership A-D Route and ERTs of each Local VRF. 316 When the central controller receives a VPN Membership A-D Route, VPN 317 relationship matching MUST be checked with IRTs and ERTs carried in 318 VPN Membership A-D Routes of different VPN instances. 320 6. IANA Considerations 322 6.1 BGP Extended Communities 324 IANA is requested to assign three BGP Extended Community Sub-Types as 325 shown below. 327 Transitive Two-Octet AS-Specific Extended Community Sub-Type 328 Sub-Type Description Reference 329 -------- --------------------- --------------- 330 TBD1 Import Route Target [this document] 332 Transitive IPv4-Address-Specific Extended Community Sub-Type 333 Sub-Type Description Reference 334 -------- --------------------- --------------- 335 TBD2 Import Route Target [this document] 337 Transitive Four-Octet AS-Specific Extended Community Sub-Type 338 Sub-Type Description Reference 339 -------- --------------------- --------------- 340 TBD3 Import Route Target [this document] 342 6.2 Subsequent Address Family Identifier 344 IANA is requested to assign a Subsequent Address Family Identifier 345 (SAFI) from the First Come First Served range as follows: 347 Value Description Reference 348 ----- --------------------- --------------- 349 TBD4 BGP-VPN-INSTANCE-SAFI [this document] 351 7. Security Considerations 353 TBD 355 Contributors 357 The following people have substantially contributed to the solution 358 and to the editing of this document:. 360 Hui Ni 361 Huawei Technologies 362 Email: nihui@huawei.com 364 Acknowledgements 366 The authors would like to thank Shuanglong Chen and Eric Wu for their 367 contributions to this work. 369 Normative References 371 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 372 Requirement Levels", BCP 14, RFC 2119, DOI 373 10.17487/RFC2119, March 1997, . 376 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 377 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 378 10.17487/RFC4271, January 2006, . 381 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 382 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 383 February 2006, . 385 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 386 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 387 2006, . 389 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 390 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 391 10.17487/RFC4760, January 2007, . 394 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 395 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 396 RFC 4761, DOI 10.17487/RFC4761, January 2007, 397 . 399 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 400 Specific BGP Extended Community", RFC 5668, DOI 401 10.17487/RFC5668, October 2009, . 404 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 405 "Provisioning, Auto-Discovery, and Signaling in Layer 2 406 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 407 10.17487/RFC6074, January 2011, . 410 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 411 Encodings and Procedures for Multicast in MPLS/BGP IP 412 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 413 . 415 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 416 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 417 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 418 2015, . 420 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 421 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 422 2017, . 424 Informative References 426 [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T., 427 Raszuk, R., and L. Fang, "Usecases of MPLS Global Label", 428 draft-li-mpls-global-label-usecases-03 (work in progress), 429 October 2015. 431 [I-D.li-spring-segment-path-programming] Li, Z., Milojevic, I., Z. 432 Zhuang, "Segment Path Programming (SPP)", 433 draft-li-spring-segment-path-programming-00 (work in 434 progress), October 2015. 436 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 437 Private Network (VPN) Terminology", RFC 4026, DOI 438 10.17487/RFC4026, March 2005, . 441 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 442 Computation Element Communication Protocol (PCEP) 443 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 444 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 445 . 447 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 448 Path Computation Element (PCE) Protocol Extensions for 449 Usage with Point-to-Multipoint TE Label Switched Paths 450 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 451 . 453 Authors' Addresses 455 Shunwan Zhuang 456 Huawei Technologies 457 Huawei Building, No.156 Beiqing Rd. 458 Beijing. 100095 China 460 Email: zhuangshunwan@huawei.com 462 Zhenbin Li 463 Huawei Technologies 464 Huawei Building, No.156 Beiqing Rd. 465 Beijing, 100095 China 467 Email: lizhenbin@huawei.com 469 Donald Eastlake 470 Futurewei Technologies 471 2386 Panoramic Circle 472 Apopka, FL 32703 USA 474 Phone: +1-508-333-2270 475 Email: d3e3e3@gmail.com 477 Lucy Yong 478 Independent 479 USA 481 Phone: +1-469-227-5837 482 Email: lucyyong@gmail.com 484 Copyright, Disclaimer, and Additional IPR Provisions 486 Copyright (c) 2021 IETF Trust and the persons identified as the 487 document authors. All rights reserved. 489 This document is subject to BCP 78 and the IETF Trust's Legal 490 Provisions Relating to IETF Documents 491 (http://trustee.ietf.org/license-info) in effect on the date of 492 publication of this document. Please review these documents 493 carefully, as they describe your rights and restrictions with respect 494 to this document. Code Components extracted from this document must 495 include Simplified BSD License text as described in Section 4.e of 496 the Trust Legal Provisions and are provided without warranty as 497 described in the Simplified BSD License.