AC-Aware Bundling Service Interface in EVPN

Abstract

An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual.¶

EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain.¶

EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only.¶

1. Introduction

EVPN based All-Active multihoming is becoming the basic building block for providing redundancy in next generation data center deployments as well as service provider access/aggregation network. For EVPN IRB mode, there are deployments which expect to be able to support multiple subnets within a single broadcast domain. Each subnet would be differentiated by VLAN. Thus, a single IRB interface can still serve multiple subnets.¶

Motivation behind such deployments are¶

1. Manageability: The support to have multiple subnets using a single broadcast domain requires only one broadcast domain and one IRB for "N" subnets compare to the "N" broadcast domain and "N" IRB interface to manage.¶

2. Simplicity: It avoids extra configuration by configuring VLAN Range with single BD and IRB as compared to individual VLAN, BD, and IRB interface per subnet.¶

[RFC7432] defines three types of service interface. None of them provide flexibility to achieve multiple subnets within a single broadcast domain. The different types of service interface from [RFC7432] are:¶

1. VLAN-Based Service Interface: With this service interface, an EVPN instance consists of only a single broadcast domain (e.g., a single VLAN). Therefore, there is a one-to-one mapping between a VID on this interface and a MAC-VRF.¶

2. VLAN Bundle Service Interface: With this service interface, an EVPN instance corresponds to multiple broadcast domains (e.g., multiple VLANs); however, only a single bridge table is maintained per MAC-VRF, which means multiple VLANs share the same bridge table. The MPLS-encapsulated frames MUST remain tagged with the originating VID. Tag translation is NOT permitted. The Ethernet Tag ID in all EVPN routes MUST be set to 0.¶

3. VLAN-Aware Bundle Service Interface: With this service interface, an EVPN instance consists of multiple broadcast domains (e.g., multiple VLANs) with each VLAN having its own bridge table -- i.e., multiple bridge tables (one per VLAN) are maintained by a single MAC-VRF corresponding to the EVPN instance.¶

From the definition, it seems like VLAN Bundle Service Interface does provide flexibility to support multiple subnets within a single broadcast domain. However, the requirement is to have multiple subnets from same ES on multihoming All-Active mode; that would not work. For example, lets take the case from Figure 1 where PE1 learns MAC of H1 on VLAN 1 (subnet S1). PE1 originates EVPN MAC route, as per [RFC7432], where the Ethernet Tag would be set to 0. Incoming packets from the IRB interface, at PE2, are untagged packets. PE2 does not have any associated AC information from EVPN MAC routes advertised by PE1. PE2 can not forward traffic that is destined to H1.¶

This document specifies an extension to existing service interface types defined in [RFC7432] and defines AC-aware Bundling service interface. AC-aware Bundling service interface would provide a mechanism to have multiple subnets in the single broadcast domain. This extension is applicable only for multihomed EVPN PEs.¶

                                H3
                                |
                            +---+---+
                            |  PE3  | EVI-1
                            +---+---+
                                |
        +-----------------------+--------------------+
        |                                            |
        |                  IP MPLS core              |
        |                                            |
        +------+------------------------------+------+
               |                              |
+--------------+----+                    +----+--------------+
|        PE1        |                    |        PE2        |
|                   |                    |                   |
|      +-----+      |                    |      +-----+      |
|      | IRB |      |                    |      | IRB |      |
|   +--+-----+--+   |                    |   +--+-----+--+   |
|   |  BD & EVI |   |                    |   |  BD & EVI |   |
|   +--+--+--+--+   |                    |   +-----------+   |
|   |S1|S2|S3|S4|   |                    |   |S1|S2|S3|S4|   |
+---+--+-X+--+--+---+                    +---+--+--+X-+--+---+
            X                                    X
               X                              X
                  X                        X  ESI-100
                     X                  X     EVI-1
                        X            X        BD-1
                           X      X
                              XX
                           +------+
                           |  CE  |
                           +-+--+-+
                             |  |
                            H1  H2
                         MAC-1  MAC-2
                        VLAN-1  VLAN-2
                        (S,G)   (S,G)

EVPN topology with multihoming and non multihoming PE.¶

Figure 1 shows sample EVPN topology where PE1 and PE2 are multihomed PEs. PE3 is remote PE participating in the same EVPN instance (EVI-1). It illustrates four subnets S1, S2, S3, and S4 where numerical value provides associated VLAN information.¶

2. Terminology

• AC: Attachment circuit.¶

• ARP: Address Resolution Protocol.¶

• BD: broadcast domain. As per [RFC7432], an EVI consists of a single or multiple BDs. In case of VLAN-bundle and VLAN-based service models (see [RFC7432]), a BD is equivalent to an EVI. In the case of the VLAN-aware bundle service model, an EVI contains multiple BDs. Also, in this document, BD and subnet are equivalent terms.¶

• BD Route Target: refers to the broadcast domain assigned to Route Target [RFC4364]. In the case of the VLAN-aware bundle service model, all the BD instances in the MAC-VRF share the same Route Target.¶

• BT: Bridge Table. The instantiation of a BD in a MAC-VRF, as per [RFC7432].¶

• Ethernet A-D route: Ethernet Auto-Discovery (A-D) route, as per [RFC7432].¶

• EVI: EVPN Instance spanning the NVE/PE devices that are participating on that EVPN, as per [RFC7432].¶

• EVPN: Ethernet Virtual Private Networks, as per [RFC7432].¶

• IRB: Integrated Routing and Bridging interface. It connects an IP-VRF to a BD (or subnet).¶

• MAC-VRF: A Virtual Routing and Forwarding Table for Media Access Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is also an instantiation of an EVI in an NVE/PE.¶

• ND: Neighbor Discovery Protocol.¶

• PE: Provider edge device hosting EVPN instance¶

• RD: BGP Route Distinguisher.¶

• RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined in [RFC7432].¶

• RT-5: EVPN route type 5, i.e., IP Prefix route. As defined in Section 3 of [RFC9136].¶

• SN: Subnet.¶

• TS: Tenant System.¶

• VLAN: The usage of VLAN refers to the 802.1Q or 802.1AD tag.¶

• (S, G): Multicast membership request¶

• This document also assumes familiarity with the terminology of [RFC7432],[RFC8365], [RFC7365].¶

3. Requirements

1. A new service interface represents an attachment-circuit where multiple VLANs are configured. Each of these VLANs is represented by a different AC ID (Identifier) under a single broadcast domain.¶

2. Service interface MUST be applicable to multihomed PEs only.¶

3. Service interface MUST have an Ethernet-Segment identifier assignment.¶

4. New service interface handling procedures MUST be backward compatible with implementation procedures defined in [RFC7432].¶

5. New service interface MUST support EVPN multicast routes defined in [RFC9251] too.¶

4. Solution Description

5. Mis-configuration Across Multihoming PEs

If there is misconfiguration of VLAN or VLAN range across multihoming PEs, the same MAC address would be learned with different VLANs per broadcast domain. In this case, an Error message MUST be thrown for the operator to make configuration changes. Furthermore, the errored MAC route MUST be ignored.¶

6. BGP Encoding

This document defines one new BGP Extended Community for EVPN.¶

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Type=0x06     | Sub-Type=0x0E |      Reserved (16 bits)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               attachment circuit ID (32 bits)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. Security Considerations

The same Security Considerations described in [RFC7432] are valid for this document.¶

8. IANA Considerations

IANA has allocated the following codepoints in the "EVPN Extended Community Sub-Types" subregistry under the "Border Gateway Protocol (BGP) Extended Communities" registry.¶

9. Acknowledgement

We would like to thank Luc Andre Burdet, Tapraj Singh , Mei Zhang for providing valuable comments.¶

10. References

Appendix A. Contributors for This Document

In addition to the authors listed on the front page, the following co-authors have also contributed to this document:¶

Patrice Brissette
Cisco Systems¶