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