idnits 2.17.1 draft-zhuang-bess-enhanced-vpn-auto-discovery-07.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 (January 10, 2021) is 1174 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) == Missing Reference: 'I-D.palle-pce-stateful-pce-initiated-p2mp-lsp' is mentioned on line 138, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: July 9, 2021 January 10, 2021 10 BGP Extensions for Enhanced VPN Auto Discovery 11 draft-zhuang-bess-enhanced-vpn-auto-discovery-07.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 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 48 Shadow Directories can be accessed at 49 http://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 74 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 A-D: Auto-Discovery 103 AFI: Address Family Identifier 105 ERT: Export Route Target 107 IRT: Import Route Target 109 LSP: Label Switched Path 111 NLRI: Network Layer Reachability Information 113 P2MP: Point to Multi-Point 115 PE: Provider Edge 117 RD: Route Distinguisher 119 VRF: Virtual Routing and Forwarding 121 VPN A-D: VPN Auto-Discovery 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 3. Requirements of VPN Auto-Discovery 131 The following subsections are examples of VPN Auto-Discovery 132 requirements. 134 3.1 Centralized Traffic Optimization 136 As the development of centrally controlled application such as PCE- 137 initiated LSP [RFC8281] and PCE-initiated P2MP LSP 138 [I-D.palle-pce-stateful-pce-initiated-p2mp-lsp], PCE can be used to 139 initiate setup of RSVP-TE LSP or P2MP LSP for the purpose of traffic 140 optimization. In order to support such applications, the controller 141 should learn the relationship of unicast VPN instances or multicast 142 VPN instances distributed on different PEs. According to the 143 existing VPN auto-discovery mechanism for technologies such as EVPN 144 [RFC7432] or MVPN [RFC6514], the A-D routes are always advertised 145 with the Export Route Target (ERT). The ingress PE can use an Import 146 Route Target (IRT) of the local MVPN/EVPN instance to match the route 147 target advertised with the NLRI to determine the relationship of 148 these VPN instances. But the controller, which can be used as the 149 route reflector of VPN routes, cannot learn the relationship of VPN 150 instances since the Import Route Target information is not advertised 151 with these A-D routes. In order to support such applications the IRT 152 can be carried with A-D routes as specified below. 154 3.2 Label/Segment Allocation for VPN Instance 156 [I-D.li-mpls-global-label-usecases] proposes use cases of label 157 allocation for unicast VPN or multicast VPN instances. 158 [I-D.li-spring-segment-path-programming] proposes use cases of 159 segment allocation for steering traffic. In order to support such 160 applications the PEs needs to learn the relationship of VPN instances 161 distributed on other PEs. For L3VPN [RFC4364] there is no auto- 162 discovery mechanism for BGP VPN instances. In order to support such 163 applications, an auto-discovery mechanism for L3VPN is specified 164 below. 166 4. IRT Extended Community 168 This document defines a new type of transitive extended community, 169 called Import Route Target. 171 The IANA registry of BGP Extended Communities clearly identifies 172 communities of specific formats: "Two-octet AS Specific Extended 173 Community" [RFC4360], "Four-octet AS Specific Extended Community" 174 [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360]. 175 Route Target [RFC4360] extended communities identify this format in 176 the high-order (Type) octet of the Extended Community. The Import 177 Route Target extended community reuses the same mechanism. 179 This document defines the following IRT Extended Communities: 181 +------+------+--------------+-------------------------------------+ 182 | | Sub- | Extended | | 183 | Type | Type | Community | Encoding | 184 +------+------+--------------+-------------------------------------+ 185 | 0x00 | TBD1 | AS-2byte IRT | 2-octet AS, 4-octet Value | 186 | 0x01 | TBD2 | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value | 187 | 0x02 | TBD3 | AS-4byte IRT | 4-octet AS, 2-octet Value | 188 +------+------+--------------+-------------------------------------+ 190 Figure 1. IRT Extended Communities 192 The IRT Extended Community can be used for MVPN [RFC6514], L3VPN 193 [RFC4364], EVPN [RFC7432], BGP-based VPLS [RFC4761], and BGP-AD-based 194 VPLS [RFC6074] and the like. The existing auto-discovery mechanisms 195 of these VPN technologies always carry the ERT extended community. 196 To meet the requirements of applications, they need to carry the IRT 197 extended community with different A-D routes. The local policy, 198 which is out of scope of this document, can be used to control the 199 distribution of IRT information. 201 5. BGP Extensions for L3VPN Auto-Discovery 203 5.1 BGP-VPN-INSTANCE SAFI 205 The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes 206 from multiple "address families". In this document a new Subsequent 207 Address Family is specified, called "BGP-VPN-INSTANCE Sub Address 208 Family", which uses a specific BGP-VPN-INSTANCE-SAFI (TBD4). 210 This document also defines a new BGP NLRI, called the BGP-VPN- 211 INSTANCE NLRI to support the BGP VPN instance auto-discovery. BGP- 212 VPN-INSTANCE MP_REACH_NLRI and MP_UNREACH_NLRI (shown in Figures 2 213 and 3) are formatted as described in [RFC4760]. The BGP-VPN-INSTANCE 214 NLRI is described in more detail in Section 5.2. 216 +-------------------------------------------------------+ 217 | Address Family Identifier: 1/2/25 (2 octets) | 218 +---------------------------+---------------------------+ 219 | Subsequent AFI: | (1 octet) 220 | BGP-VPN-INSTANCE-SAFI=TBD4| 221 +---------------------------+ 222 | Length of Next Hop | (1 octet) 223 +---------------------------+---... 224 | Next Hop (variable) 225 +---------------------------+---... 226 | Reserved | (1 octet) 227 +---------------------------+---... 228 | BGP-VPN-INSTANCE NLRI (variable) 229 +-------------------------------... 231 Figure 2. BGP-VPN-INSTANCE MP_REACH_NLRI 233 +-------------------------------------------------------+ 234 | Address Family Identifier: 1/2/25 (2 octets) | 235 +---------------------------+---------------------------+ 236 | Subsequent AFI: | (1 octet) 237 | BGP-VPN-INSTANCE-SAFI=TBD4| 238 +---------------------------+---... 239 | BGP-VPN-INSTANCE NLRI (variable) 240 +-------------------------------... 242 Figure 3. BGP-VPN-INSTANCE MP_UNREACH_NLRI 244 5.2 BGP-VPN-INSTANCE NLRI 246 The following is the format of the BGP-VPN-INSTANCE NLRI. 248 +---------------------------+ 249 | Route Type | (1 octet) 250 +---------------------------+ 251 | Length | (1 octet) 252 +---------------------------+---... 253 | Route Type Specific (variable) | 254 +---------------------------------------------------+ 256 Figure 4. BGP-VPN-INSTANCE NLRI 258 The Route Type field specifies the encoding of the rest of 259 BGP-VPN-INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI). 261 The Length field indicates the length in octets of the Route Type 262 specific field of the BGP-VPN-INSTANCE NLRI. 264 This document defines the following Route Type for BGP-VPN-INSTANCE 265 routes: 267 Type 1: VPN Membership A-D Route 269 5.2.1 VPN Membership A-D Route 271 The VPN Membership A-D Route is utilized for VPN Membership A-D 272 between PEs. Its format is shown in Figure 5. 274 +-------------------------------------... 275 | Local Router's IP Address (variable) 276 +----------------------------------------+ 277 | RD | (8 octets) 278 +----------------------------------------+ 280 Figure 5. VPN Membership A-D Route 282 a) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. 284 b) RD: RD of one VRF on the advertising PE, encoded as described 285 in [RFC4364]. 287 5.3 Procedures 289 Every PE needs to process all its VRF configuration and generate one 290 VPN Membership A-D Route for each VRF respectively. The Local 291 Router's IP Address field MUST be filled with the Advertising 292 Router's IP address. The RD field MUST be filled with the VRF's RD 293 value. 295 All ERTs of the VRF MUST be carried in a BGP Update's RT Extended 296 Community Path Attribute with the Membership A-D Route for the VRF. 297 To meet the requirements of different applications, all IRTs of the 298 VRF SHOULD be able to be carried in BGP Update's IRT Extended 299 Community Path Attribute with the VPN Membership A-D Route for the 300 VRF. 302 If a VRF is created, then its corresponding VPN Membership A-D Route 303 MUST be generated and advertised. 305 If the VRF whose VPN Membership A-D Route has been advertised is 306 deleted, then the VPN Membership A-D Route Withdraw message MUST be 307 generated and advertised. 309 If IRTs or ERTs of the VRF whose VPN Membership A-D Route has been 310 advertised are changed, then a VPN Membership A-D Route Update with 311 same Prefix and latest IRTs or ERTs MUST be advertised. 313 When the receiving PE receives a VPN Membership A-D Route, VPN 314 relationship matching MUST be checked with the IRTs carried in the 315 VPN Membership A-D Route and ERTs of each Local VRF. 317 When the central controller receives a VPN Membership A-D Route, VPN 318 relationship matching MUST be checked with IRTs and ERTs carried in 319 VPN Membership A-D Routes of different VPN instances. 321 6. IANA Considerations 323 6.1 BGP Extended Communities 325 IANA is requested to assign three BGP Extended Community Sub-Types as 326 shown below. 328 Transitive Two-Octet AS-Specific Extended Community Sub-Type 329 Sub-Type Description Reference 330 -------- --------------------- --------------- 331 TBD1 Import Route Target [this document] 333 Transitive IPv4-Address-Specific Extended Community Sub-Type 334 Sub-Type Description Reference 335 -------- --------------------- --------------- 336 TBD2 Import Route Target [this document] 338 Transitive Four-Octet AS-Specific Extended Community Sub-Type 339 Sub-Type Description Reference 340 -------- --------------------- --------------- 341 TBD3 Import Route Target [this document] 343 6.2 Subsequent Address Family Identifier 345 IANA is requested to assign a Subsequent Address Family Identifier 346 (SAFI) from the First Come First Served range as follows: 348 Value Description Reference 349 ----- --------------------- --------------- 350 TBD4 BGP-VPN-INSTANCE-SAFI [this document] 352 7. Security Considerations 354 TBD 356 Contributors 358 The following people have substantially contributed to the solution 359 and to the editing of this document:. 361 Hui Ni 362 Huawei Technologies 363 Email: nihui@huawei.com 365 Acknowledgements 367 The authors would like to thank Shuanglong Chen and Eric Wu for their 368 contributions to this work. 370 Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, DOI 374 10.17487/RFC2119, March 1997, . 377 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 378 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 379 10.17487/RFC4271, January 2006, . 382 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 383 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 384 February 2006, . 386 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 387 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 388 2006, . 390 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 391 "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 392 10.17487/RFC4760, January 2007, . 395 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 396 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 397 RFC 4761, DOI 10.17487/RFC4761, January 2007, 398 . 400 [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS 401 Specific BGP Extended Community", RFC 5668, DOI 402 10.17487/RFC5668, October 2009, . 405 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 406 "Provisioning, Auto-Discovery, and Signaling in Layer 2 407 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 408 10.17487/RFC6074, January 2011, . 411 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 412 Encodings and Procedures for Multicast in MPLS/BGP IP 413 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 414 . 416 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 417 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 418 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 419 2015, . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 422 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 423 2017, . 425 Informative References 427 [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T., 428 Raszuk, R., and L. Fang, "Usecases of MPLS Global Label", 429 draft-li-mpls-global-label-usecases-03 (work in progress), 430 October 2015. 432 [I-D.li-spring-segment-path-programming] Li, Z., Milojevic, I., Z. 433 Zhuang, "Segment Path Programming (SPP)", 434 draft-li-spring-segment-path-programming-00 (work in 435 progress), October 2015. 437 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 438 Private Network (VPN) Terminology", RFC 4026, DOI 439 10.17487/RFC4026, March 2005, . 442 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 443 Computation Element Communication Protocol (PCEP) 444 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 445 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 446 . 448 Authors' Addresses 450 Shunwan Zhuang 451 Huawei Technologies 452 Huawei Building, No.156 Beiqing Rd. 453 Beijing. 100095 China 455 Email: zhuangshunwan@huawei.com 457 Zhenbin Li 458 Huawei Technologies 459 Huawei Building, No.156 Beiqing Rd. 460 Beijing, 100095 China 462 Email: lizhenbin@huawei.com 464 Donald Eastlake 465 Futurewei Technologies 466 2386 Panoramic Circle 467 Apopka, FL 32703 USA 469 Phone: +1-508-333-2270 470 Email: d3e3e3@gmail.com 472 Lucy Yong 473 Independent 474 USA 476 Phone: +1-469-227-5837 477 Email: lucyyong@gmail.com 479 Copyright, Disclaimer, and Additional IPR Provisions 481 Copyright (c) 2021 IETF Trust and the persons identified as the 482 document authors. All rights reserved. 484 This document is subject to BCP 78 and the IETF Trust's Legal 485 Provisions Relating to IETF Documents 486 (http://trustee.ietf.org/license-info) in effect on the date of 487 publication of this document. Please review these documents 488 carefully, as they describe your rights and restrictions with respect 489 to this document. Code Components extracted from this document must 490 include Simplified BSD License text as described in Section 4.e of 491 the Trust Legal Provisions and are provided without warranty as 492 described in the Simplified BSD License.