Network Working Group S. Zhuang Internet-Draft Z. Li Intended status: Standards Track L. Yong Expires: April 21, 2016 Huawei Technologies October 19, 2015 BGP Extensions for Enhanced VPN Auto Discovery draft-zhuang-bess-enhanced-vpn-auto-discovery-00 Abstract All kinds of VPN technologies have been widely deployed to bear different services. As new applications develop, there proposes the requirement of auto-discovery of Layer 3 Virtual Private Network (L3VPN) and enhanced auto-discovery requirements for other VPN technologies which already have the auto-discovery mechanisms. This document identifies the possible applications and these auto- discovery requirements. Accordingly this document defines a new BGP NLRI, called the BGP-VPN-INSTANCE NLRI to satisfy the requirement of auto-discovery of BGP VPN instance and a new type of the extended community, called the Import Route Target which can be applied for auto-discovery mechanisms of multiple VPN technologies. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2016. Zhuang, et al. Expires April 21, 2016 [Page 1] Internet-Draft BGP Extensions For VPN AD October 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements of VPN Auto-Discovery . . . . . . . . . . . . . 3 3.1. Centralized Traffic Optimization . . . . . . . . . . . . 3 3.2. Label/Segment Allocation for VPN Instance . . . . . . . . 3 4. IRT Extended Community . . . . . . . . . . . . . . . . . . . 4 5. BGP Extensions for L3VPN Auto-Discovery . . . . . . . . . . . 4 5.1. BGP-VPN-INSTANCE SAFI . . . . . . . . . . . . . . . . . . 4 5.2. BGP-VPN-INSTANCE NLRI . . . . . . . . . . . . . . . . . . 5 5.2.1. VPN Membership A-D Route . . . . . . . . . . . . . . 6 5.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction All kinds of VPN technologies have been widely deployed to bear different services. As new applications develop, there proposes the requirement of auto-discovery of Layer 3 Virtual Private Network (L3VPN) [RFC4364] and enhanced auto-discovery requirements for other VPN technologies which already have the auto-discovery mechanisms. This document identifies the possible applications and these auto- discovery requirements. Accordingly this document defines a new BGP NLRI, called the BGP-VPN-INSTANCE NLRI to satisfy the requirement of auto-discovery of BGP VPN instance and a new type of the extended Zhuang, et al. Expires April 21, 2016 [Page 2] Internet-Draft BGP Extensions For VPN AD October 2015 community, called the Import Route Target which can be applied for auto-discovery mechanisms of multiple VPN technologies. 2. Terminologies This document uses the terminologies defined in [RFC4026]: ERT: Export Route Target IRT: Import Route Target PE: Provider Edge RD: Route Distinguisher VRF: Virtual Routing and Forwarding VPN A-D: VPN Auto-Discovery 3. Requirements of VPN Auto-Discovery 3.1. Centralized Traffic Optimization As the development of central controlled application such as PCE- initiated LSP[I-D.ietf-pce-pce-initiated-lsp]and PCE-initiated P2MP LSP[I-D.palle-pce-stateful-pce-initiated-p2mp-lsp], PCE can be used to initiate setup of RSVP-TE LSP or P2MP LSP for the purpose of traffic optimization. In order to support such applications, the controller should learn the relationship of unicast VPN instances or multicast VPN instances distributed on different PEs. According to the existing auto-discovery mechanism of VPN technologies such as EVPN[RFC7432] or MVPN[RFC6514], the A-D routes are always advertised with the Export Route Target (ERT). The ingress PE can use the Import Route Target (IRT) of local MVPN/EVPN instance to match the route target advertised with the NLRI to determine the relationship of these VPN instances. But the controller which can be used as the RR of VPN routes cannot learn the relationship of VPN instances since the Import Route Target information is not advertised with these A-D routes. In order to support such applications the IRT should be carried with A-D routes. 3.2. Label/Segment Allocation for VPN Instance [I-D.li-mpls-global-label-usecases] propose the usecases of label allocation for unicast VPN or multicast VPN instance. [I-D.li-spring-segment-path-programming] propose the usecases of segment allocation for steering traffic. In order to support such applications the PEs needs to learn the relationship of VPN instances Zhuang, et al. Expires April 21, 2016 [Page 3] Internet-Draft BGP Extensions For VPN AD October 2015 distributed on other PEs. For L3VPN [RFC4364] there is no auto- discovery mechanism of BGP VPN instance. In order to support such applications, auto-discovery mechanism should be introduced for L3VPN. 4. IRT Extended Community This document defines a new type of the extended community, called as Import Route Target. This extended community is a new transitive extended community with the Sub-Type field is TBD. The IANA registry of BGP Extended Communities clearly identifies communities of specific formats: "Two-octet AS Specific Extended Community" [RFC4360], "Four-octet AS Specific Extended Community" [RFC5668], and "IPv4 Address Specific Extended Community" [RFC4360]. Route Targets [RFC4360] extended community identify this format in the high-order (Type) octet of the Extended Community. Import Route Target extended community will reuses the same mechanism. This document defines the following IRT Extended Communities: +------+--------+--------------------+-------------------------------------+ | Type |Sub-Type| Extended Community | Encoding | +------+--------+--------------------+-------------------------------------+ | 0x00 | TBD | AS-2byte IRT | 2-octet AS, 4-octet Value | | 0x01 | TBD | IPv4 IRT | 4-octet IPv4 Address, 2-octet Value | | 0x02 | TBD | AS-4byte IRT | 4-octet AS, 2-octet Value | +------+--------+--------------------+-------------------------------------+ Figure 1 IRT Extended Communities The IRT Extended Community can be used for MVPN[RFC6514], L3VPN[RFC4364], EVPN[RFC7432], BGP-based VPLS[RFC4761], and BGP-AD- based VPLS[RFC6074] etc. The existing auto-discovery mechanisms of these VPN technologies always carry the ERT extended community. According to the requirements of applications, the IRT extended community SHOULD be able to be carried with different A-D routes. The local policy can be used to control the distribution of IRT information which is out of scope of this document. 5. BGP Extensions for L3VPN Auto-Discovery 5.1. BGP-VPN-INSTANCE SAFI The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes from multiple "address families". In this document a new Subsequent Zhuang, et al. Expires April 21, 2016 [Page 4] Internet-Draft BGP Extensions For VPN AD October 2015 Address Family is introduced, called "BGP-VPN-INSTANCE Sub Address Family" uses a specific BGP-VPN-INSTANCE-SAFI (TBD). This document also defines a new BGP NLRI, called the BGP-VPN- INSTANCE NLRI to support the BGP VPN instance auto-discovery. BGP- VPN-INSTANCE MP_REACH_NLRI and MP_UNREACH_NLRI (shown in the figure 1 and figure 2) are formatted as described in [RFC4760]. +-------------------------------------------------------+ | Address Family Identifier (2 octets): 1/2/25 | +-------------------------------------------------------+ | Subsequent AFI (1 octet): BGP-VPN-INSTANCE-SAFI (TBD) | +-------------------------------------------------------+ | Length of Next Hop (1 octet) | +-------------------------------------------------------+ | Next Hop (variable) | +-------------------------------------------------------+ | Reserved (1 octet) | +-------------------------------------------------------+ | BGP-VPN-INSTANCE NLRI (variable) | +-------------------------------------------------------+ Figure 2 BGP-VPN-INSTANCE MP_REACH_NLRI +-------------------------------------------------------+ | Address Family Identifier (2 octets): 1/2/25 | +-------------------------------------------------------+ | Subsequent AFI (1 octet): BGP-VPN-INSTANCE-SAFI (TBD) | +-------------------------------------------------------+ | BGP-VPN-INSTANCE NLRI (variable) | +-------------------------------------------------------+ Figure 3 BGP-VPN-INSTANCE MP_UNREACH_NLRI 5.2. BGP-VPN-INSTANCE NLRI The following is the format of the BGP-VPN-INSTANCE NLRI. +---------------------------------------------------+ | Route Type (1 octet) | +---------------------------------------------------+ | Length (1 octet) | +---------------------------------------------------+ | Route Type Specific (variable) | +---------------------------------------------------+ Figure 4 BGP-VPN-INSTANCE NLRI Zhuang, et al. Expires April 21, 2016 [Page 5] Internet-Draft BGP Extensions For VPN AD October 2015 The Route Type field defines the encoding of the rest of BGP-VPN- INSTANCE NLRI (Route Type specific BGP-VPN-INSTANCE NLRI). The Length field indicates the length in octets of the Route Type specific field of the BGP-VPN-INSTANCE NLRI. This document defines the following Route Types for BGP-VPN-INSTANCE routes: -- Type 1: VPN Membership A-D Route 5.2.1. VPN Membership A-D Route VPN Membership A-D Route is utilized for VPN Membership Auto- Discovery between PEs. Its format is defined as following diagram: +--------------------------------------------------+ | Local Router's IP Address (variable) | +--------------------------------------------------+ | RD (8 octets) | +--------------------------------------------------+ Figure 5 VPN Membership A-D Route a) Local Router's IP Address: Advertising PE's IPv4/IPv6 address. b) RD: RD of one VRF on advertising PE, encoded as described in [RFC4364]. 5.3. Procedures For every PE, it needs to process all its VRF configuration and generate one VPN Membership A-D Route for each VRF respectively. Local Router's IP Address field MUST filled with the Advertising Router's IP address. RD field MUST be filled with the VRF's RD value. All ERTs of the VRF MUST be carried in BGP Update's RT Extended Community Path Attribute with the Membership A-D Route for the VRF. According to the requirement of different applications, all IRTs of the VRF SHOULD be able to be carried in BGP Update's IRT Extended Community Path Attribute with the VPN Membership A-D Route for the VRF. Zhuang, et al. Expires April 21, 2016 [Page 6] Internet-Draft BGP Extensions For VPN AD October 2015 If a VRF is created, then its corresponding VPN Membership A-D Route MUST be generated and advertised. If the VRF whose VPN Membership A-D Route has been advertised is deleted, then the VPN Membership A-D Route Withdraw message MUST be generated and advertised. If IRTs or ERTs of the VRF whose VPN Membership A-D Route has been advertised are changed, then a VPN Membership A-D Route Update with same Prefix and latest IRTs or ERTs MUST be advertised. When the receiving PE receives VPN Membership A-D Route, VPN relationship matching MUST be checked with IRTs carried in VPN Membership A-D Route and ERTs of each Local VRF. When the central controller receives VPN Membership A-D Route, VPN relationship matching MUST be checked with IRTs and ERTs carried in VPN Membership A-D Routes of different VPN instances. 6. Contributors The following people have substantially contributed to the solution and to the editing of this document:. Hui Ni Huawei Email: nihui@huawei.com 7. IANA Considerations TBD. 8. Security Considerations TBD 9. Acknowledgements The authors would like to thank Shuanglong Chen, Eric Wu for their contributions to this work. 10. References 10.1. Normative References Zhuang, et al. Expires April 21, 2016 [Page 7] Internet-Draft BGP Extensions For VPN AD October 2015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, DOI 10.17487/RFC4365, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, . [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS Specific BGP Extended Community", RFC 5668, DOI 10.17487/RFC5668, October 2009, . [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . Zhuang, et al. Expires April 21, 2016 [Page 8] Internet-Draft BGP Extensions For VPN AD October 2015 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 10.2. Informative References [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-04 (work in progress), April 2015. [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., Yang, T., Raszuk, R., and L. Fang, "Usecases of MPLS Global Label", draft-li-mpls-global- label-usecases-03 (work in progress), October 2015. [I-D.li-spring-segment-path-programming] Li, Z. and I. Milojevic, "Segment Path Programming (SPP)", draft-li-spring-segment-path-programming-00 (work in progress), October 2015. [I-D.palle-pce-stateful-pce-initiated-p2mp-lsp] Palle, U., Dhody, D., Tanaka, Y., Ali, Z., and V. Beeram, "PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE Model", draft-palle-pce-stateful- pce-initiated-p2mp-lsp-06 (work in progress), June 2015. [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . Authors' Addresses Shunwan Zhuang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Zhuang, et al. Expires April 21, 2016 [Page 9] Internet-Draft BGP Extensions For VPN AD October 2015 Zhenbin Li Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Lucy Yong Huawei Technologies Email: lucy.yong@huawei.com Zhuang, et al. Expires April 21, 2016 [Page 10]