BESS Working Group W. Wang Internet-Draft A. Wang Intended status: Standards Track China Telecom Expires: 9 September 2023 H. Wang Huawei Technologies 8 March 2023 Layer-3 Accessible EVPN Services draft-wang-bess-l3-accessible-evpn-05 Abstract This draft describes layer-3 accessible EVPN service interfaces according to [RFC7432], and proposes a new solution which can simplify the deployment of layer-3 accessible EVPN service. This solution allows each PE in EVPN network to maintain only one IP-VRF. 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 https://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 9 September 2023. Copyright Notice Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Wang, et al. Expires 9 September 2023 [Page 1] Internet-Draft L3 Accessible EVPN March 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Service Interfaces in layer-3 accessible EVPN . . . . . . . . 4 5. Solutions of LSI-aware bundle service interface . . . . . . . 6 6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7 6.1. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 7 6.1.1. Extensions to VxLAN . . . . . . . . . . . . . . . . . 7 6.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7 7. Modification of MAC/IP address storage mode on PE . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction [RFC7432]defines three service interfaces for layer-2 accessible EVPN: VLAN-Based Service Interface, VLAN-Bundle Service Interface and VLAN-Aware Bundle Service Interface. These three types of service interfaces can realize the isolation of layer-2 traffic of customers in different ways, as shown in Figure 1. 1:1 1:1 +------+ +---------+ +------+ |VID 11+---+ EVI 1 +---+VID 12| +------+ +---------+ +------+ |VID 21+---+ EVI 2 +---+VID 22| +------+ +---------+ +------+ |VID 31+---+ EVI 3 +---+VID 32| +------+ +---------+ +------+ |VID 41+---+ EVI 4 +---+VID 42| +------+ +---------+ +------+ VLAN-based Service Interface N:1 1:N +------+ +---------+ +------+ |VID 11---------+ +--------+VID 12| +------+ + + +------+ |VID 21+--------+ +--------+VID 22| +------+ + EVI 1 + +------+ |VID 31+--------+ +--------+VID 32| +------+ + + +------+ Wang, et al. Expires 9 September 2023 [Page 2] Internet-Draft L3 Accessible EVPN March 2023 |VID 41+--------+ +--------+VID 42| +------+ +---------+ +------+ VLAN-bundle Service Interface N:1 1:N +----------------------+ +------+ |+--------------------+| +------+ |VID 11+--++ Broadcast Domain 1 ++--+VID 12| +------+ |+--------------------+| +------+ |VID 21+--++ Broadcast Domain 2 ++--+VID 22| +------+ |+--------------------+| +------+ |VID 31+--++ Broadcast Domain 3 ++--+VID 32| +------+ |+--------------------+| +------+ |VID 41+--++ Broadcast Domain 4 ++--+VID 42| +------+ |+--------------------+| +------+ | | | EVI 1 | +----------------------+ VLAN-Aware Bundle Service Interface Figure 1: EVPN Service Interfaces Overview For VLAN-based service interface, there is a one to one mapping between VID and EVI. Each EVI has a single broadcast domain so that traffic from different customers can be isolated. For VLAN-bundle service interface, there is a N to one mapping between VID and EVI. Each EVI has a single broadcast domain, but the MAC address MUST be unique that can be used for customer traffic isolation. For VLAN-aware bundle service interface, there is a N to one mapping between VID and EVI. Each EVI has multiple broadcast domains while the MAC address can overlap. One broadcast domain corresponds to one VID, which can be used to customer traffic isolation. In the scenarios corresponding to these service interfaces, CE-PE should be placed in the same Layer-2 network. In most of provider network, CE-PE need to cross a Layer-3 network, then the above service interfaces should be extended to adapt to the layer-3 network. Wang, et al. Expires 9 September 2023 [Page 3] Internet-Draft L3 Accessible EVPN March 2023 In this draft, we describe three layer-3 accessible interfaces for EVPN, summarize the existing layer-3 accessible EVPN solutions, and propose a new solution which can simplify the depolyment of layer-3 accessible EVPN service. 2. Conventions used in this document 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 [RFC2119] . 3. Terminology The following terms are defined in this draft: * CE: Client Edge * PE: Provider Edge * EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] * VxLAN: Virtual eXtensible Local Area Network, defined in [RFC7348] * IPSec: Internet Protocol Security, defined in [RFC4301] 4. Service Interfaces in layer-3 accessible EVPN In most of provider network, CE-PE need to cross a Layer-3 network. With this scenario, service interfaces defined in [RFC7432] should be extended to adapt to the layer-3 network. To achieve the traffic isolation, tunnel encapsulation technologies can be used. We define Logical Session Identifier(LSI) to distinguish the packets from different tunnels, which is related to VNI/SPI. The length of LSI is 16 bits. The layer-3 accessible interfaces for EVPN are shown in Figure 2, refer to [RFC7432] 1:1 1:1 +------+ +---------+ +------+ |LSI 11+---+ IP-VRF1 +---+LSI 12| +------+ +---------+ +------+ |LSI 21+---+ IP-VRF2 +---+LSI 22| +------+ +---------+ +------+ |LSI 31+---+ IP-VRF3 +---+LSI 32| Wang, et al. Expires 9 September 2023 [Page 4] Internet-Draft L3 Accessible EVPN March 2023 +------+ +---------+ +------+ |LSI 41+---+ IP-VRF4 +---+LSI 42| +------+ +---------+ +------+ LSI-based Service Interface N:1 1:N +------+ +---------+ +------+ |LSI 11---------+ +--------+LSI 12| +------+ + + +------+ |LSI 21+--------+ +--------+LSI 22| +------+ + IP-VRF1 + +------+ |LSI 31+--------+ +--------+LSI 32| +------+ + + +------+ |LSI 41+--------+ +--------+LSI 42| +------+ +---------+ +------+ LSI-bundle Service Interface N:1 1:N +----------------------+ +------+ |+--------------------+| +------+ |LSI 11+--++ Logical Plane 1 ++--+LSI 12| +------+ |+--------------------+| +------+ |LSI 21+--++ Logical Plane 2 ++--+LSI 22| +------+ |+--------------------+| +------+ |LSI 31+--++ Logical Plane 3 ++--+LSI 32| +------+ |+--------------------+| +------+ |LSI 41+--++ Logical Plane 4 ++--+LSI 42| +------+ |+--------------------+| +------+ | | | IP-VRF 1 | +----------------------+ LSI-Aware Bundle Service Interface Figure 2: Layer-3 accessible EVPN Service Interfaces Overview For LSI-based service interface, there is a one to one mapping between LSI and IP-VRF. Each IP-VRF has a single logical plane so that traffic from different customers can be isolated. Wang, et al. Expires 9 September 2023 [Page 5] Internet-Draft L3 Accessible EVPN March 2023 For LSI-bundle service interface, there is a N to one mapping between LSI and IP-VRF. Each IP-VRF has a single logical plane, but the IP address MUST be unique that can be used for customer traffic isolation. For LSI-aware bundle service interface, there is a N to one mapping between LSI and IP-VRF. Each IP-VRF has multiple logical planes while the IP address can overlap. One logical plane corresponds to one LSI, which can be used to customer traffic isolation. 5. Solutions of LSI-aware bundle service interface Let's assume a scenario as shown in Figure 3, where Backbone is EVPN domain, and the MANs are Layer-3 network. VNIs in MANs are independently allocated, which may lead to the overlap of VNI in different customer sites. +---+ +---+ |C-A+--------+ +-------+C-A| +---+ | +-----------+ +-----------------+ +-----------+ | +---+ +-+--+ | | +-+-+ +-+-+ | | +--+-+ | CE +---+ MAN +-+PE | Backbone |PE +---+ MAN +---+ CE | +-+--+ | | +-+-+ +-+-+ | | +--+-+ +---+ | +-----------+ +-----------------+ +-----------+ | +---+ |C-B+--------+ +-------+C-B| +---+ +---+ Figure 3: LSI-aware bundle service interface scenario If each VNI has its own IP-VRF, each PE and CE maintain an IP-VRF for each deployment. In this situation, customer traffic can be isolated by different VNIs, and there is no need for extending control plane/ forwarding plane protocols. For deployment, we expect a simpler way, such as assign an IP-VRF to each customer, not to each department. That is to say, all VNIs share one IP-VRF on PEs. In this situation, each CE still maintain an IP-VRF for each deployment, but each PE maintains only one VRF for all deployments. In this situation, customer traffic cannot be isolated by VNIs. We propose a solution for this scenario: * Using LSI information to identify different customer routes / traffic. As described above, LSI can be generated by VNI/SPI, and there is a one to one mapping between LSI and VNI/SPI. PEs should maintain the mapping table of LSI and VNI/SPI, so that they can distinguish different customer routes / traffic. LSI information can be transmitted by using Ethernet Tag ID or a newly defined ESI type. Wang, et al. Expires 9 September 2023 [Page 6] Internet-Draft L3 Accessible EVPN March 2023 * TBD (more solutions are welcome). For example, the scenario shown in Figure 3 supports end-to-end L2/L3 data transmission. There is a N:1 mapping between LSI and EVI, 1:1 mapping between LSI and VLAN ID, and 1:1 mapping between LSI and VNI, LSIs are used for traffic isolation. If customers need end-to-end L2 data transmission, the use of LSI is similar to VLAN ID. If customers need end-to-end L3 data transmission, LSI can carry the identification information of customers through the layer-3 network. 6. Protocol Extensions 6.1. Forwarding Plane 6.1.1. Extensions to VxLAN When the forwarding plane uses VxLAN tunnel technologies, we should extend the VxLAN GPE header to carry the LSI information, the extentions to the VxLAN GPE header is shown in Figure 4: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|Ver|I|P|B|O| LSI |Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VXLAN Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The extentions to VxLAN GPE header We define a S bit. If S is set to 1, it means the field after O bit contains LSI information. 6.2. Control Plane We propose two methods to advertise LSI information in control plane: * Reusing the Ethernet Tag ID field. This method requires the update of [I-D.ietf-bess-evpn-prefix-advertisement] (Etherenet Tag ID is set to 0 for route type 5), and may arise some confuse with the original definition of Ethernet Tag ID. * Using the newly defined ESI type as shown in Figure 5. This method can preserve the original purpose of ESI definition (multi- homing). Wang, et al. Expires 9 September 2023 [Page 7] Internet-Draft L3 Accessible EVPN March 2023 +---+---+---+---+---+---+---+---+---+---+ | T | Reserved | CE Identifier | LSI | +---+---+---+---+---+---+---+---+---+---+ Figure 5: The format of new ESI type Where: * T (1 octet): specify the ESI Type. The recommended value is 0x06. * CE Identifier (3 octets): the route ID/IPv4 address of CE. * LSI (2 octets): the LSI information. Since the length of LSI is 16 bits, while the length of Ethernet Tag ID and ESI are 80 bits and 32 bits, respectively. We can only use the lower 16 bits of Ethernet Tag ID / ESI field to carry LSI information, the other bits MUST set to 0. 7. Modification of MAC/IP address storage mode on PE LSI-aware bundle service interface also changes the storage mode of MAC / IP address on PE, as shown in Figure 6. +--------------------------+ +--------------------------------+ |MAC-VRF | |IP-VRF | | | | | | BD-A (LSI <-> VNI) | | Logical plane 1 (LSI <-> VNI) | | MAC 1 | | IP Prefix 1 | | ...... | | ...... | | | | | | BD-B (LSI <-> VNI) | | Logical plane 2 (LSI <-> VNI) | | MAC 100 | | IP Prefix 100 | | ...... | | ...... | +--------------------------+ +--------------------------------+ LSI-Aware Bundle Service LSI-Aware Bundle Service Interface(L2) Interface(L3) Figure 6: Modification of MAC/IP address storage mode on PE For end-to-end layer-2 data transmission, the storage mode of MAC address in MAC-VRF is similar to VLAN-aware bundle service, the only change is that different bridge domains are distinguished by LSI. Wang, et al. Expires 9 September 2023 [Page 8] Internet-Draft L3 Accessible EVPN March 2023 For end-to-end layer-3 data transmission, sub-VRFs are needed in IP- VRF to storage IP address. Different SDs are distinguished by LSIs. 8. Security Considerations TBD 9. IANA Considerations This draft extends the VxLAN GPE header, S bit of Flag and LSI field are added: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|Ver|I|P|B|O| LSI |Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VXLAN Network Identifier (VNI) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This draft also define a new ESI type: +---+---+---+---+---+---+---+---+---+---+ | T | Reserved | CE Identifier | LSI | +---+---+---+---+---+---+---+---+---+---+ 10. Normative References [I-D.ietf-bess-evpn-prefix-advertisement] Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", Work in Progress, Internet-Draft, draft-ietf-bess-evpn- prefix-advertisement-11, 18 May 2018, . [I-D.ietf-bess-mvpn-evpn-aggregation-label] Zhang, Z. J., Rosen, E. C., Lin, W., Li, Z., and I. Wijnands, "MVPN/EVPN Tunnel Aggregation with Common Labels", Work in Progress, Internet-Draft, draft-ietf- bess-mvpn-evpn-aggregation-label-09, 12 December 2022, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wang, et al. Expires 9 September 2023 [Page 9] Internet-Draft L3 Accessible EVPN March 2023 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [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, . Authors' Addresses Wei Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: weiwang94@foxmail.com Aijun Wang China Telecom Beiqijia Town, Changping District Beijing Beijing, 102209 China Email: wangaj3@chinatelecom.cn Haibo Wang Huawei Technologies Huawei Building, No.156 Beiqing Rd. Beijing Beijing, 100095 China Email: rainsword.wang@huawei.com Wang, et al. Expires 9 September 2023 [Page 10]