EVPN VLAN Tag Extended Community

Introduction defines MAC/IP Advertisement Route, which can optionally carry IPv4 or IPv6 addresses associated with a MAC address. The MPLS Label1 field is encoded as 3 octets, where the high-order 20 bits contain the label value. The MPLS Label1 must be downstream assigned, and it is associated with the MAC address being advertised by the advertising PE. The advertising PE uses this label for applying policies on the received route and performs forwarding based on the destination MAC address toward the CE. In case any routing policies need to be made on an additional label such as a VLAN identifier, then the information conveyed in the EVPN MAC/IP Advertisement Route may not be enough for the remote PE to apply the right policies and eventually make the correct forwarding decision towards the CE. A new Extended Community that is advertised along with an EVPN MAC/IP Advertisement Route and carries information relevant to the VLAN identifiers so that an EVPN PE can apply the right policies based on this information is defined in this document.

Terminology

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terms and Abbreviations

EVPN: Ethernet Virtual Private Network. A BGP-based protocol for building VPNs and network overlays. Defined in for use with MPLS encapsulation, and extended in for use with alternative encapsulations, including VXLAN
PE: Provider Edge device
VLAN: Virtual LAN. A single bridging domain local to a device.
CE: Customer Edge device
BD: Broadcast Domain
ARP: Address Resolution Protocol
ND: Neighbor Discovery protocol, specified in

The EVPN VLAN-Tag Extended Community This document defines a transitive EVPN Extended Community (Type field value of 0x06) with a Sub-Type of TBD, as allocated by IANA. It is advertised along with EVPN MAC/IP Advertisement routes that carry an IPv4 or IPv6 address. 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=TBD | Flags | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLANID3 | VLANID2 | VLANID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags field 0 1 2 3 4 5 +-+-+-+-+-+-+ |Stacke.|VL.| +-+-+-+-+-+-+ The Flags field is a composite value of Stacked VLAN Type and VLAN count. Stacked VLAN Type can be one of the following values: 0x01 - Host was learnt via Single-tagged IEEE 802.1Q frames. The following represents a Single-tagged 802.1Q packet format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DestMAC | SrcMAC | 802.1Q | EtherType | Payload | CRC/FCS | | TPID=0x8100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x02 - Host was learnt via IEEE 802.1Q double-tagged frames. The following represents a 802.1Q double-tagged packet format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DestMAC | SrcMAC | 802.1Q | 802.1Q | EtherType | Payload | CRC/FCS| | TPID=0x8100 TPID=0x8100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x03 - Host was learnt via IEEE 802.1ad frames. The following represents a IEEE 802.1ad double-tagged packet format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DestMAC | SrcMAC | 802.1Q | 802.1Q | EtherType | Payload | CRC/FCS| | TPID=0x88A8 TPID=0x8100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VLAN Count indicates the number of VLAN IDs present in the extended community The valid range of this field must be 1-3. All other values are invalid. The receiver PE MUST treat an invalid value as an invalid Extended Community and MUST ignore it. VLANID1, VLANID2, VLANID3 must be in the range of 1 through 4094. Any other value MUST be considered as invalid. Reserved field MUST be set to zero on transmission and MUST be ignored on receipt. If more than one instance of this Extended Community is present in the EVPN MAC/IP route Advertisement, then the first EVPN VLAN Extended community is considered and the rest of the EVPN VLAN Extended communities MUST be ignored.

Use of the EVPN VLAN Tag Extended Community This section describes the relevant procedures when advertising and processing the EVPN VLAN Tag Extended Community. In this section, the term "PE" refers to a PE that supports the procedures defined in this document.

Transmission of the EVPN VLAN Tag Extended Community A PE MAY learn IP-to-MAC bindings through mechanisms other than EVPN, including:

Static configuration via the management plane
ARP or Neighbor Discovery (ND) learning (including proxy ARP/ND)
Snooping of ARP or Neighbor Advertisement (NA) messages received from a CE

When advertising the EVPN VLAN Tag community using EVPN MAC/IP Advertisement routes:

If the binding is learned from a single-tagged IEEE 802.1Q frames, the PE MAY include the EVPN VLAN Tag Extended Community with Stacked VLANs = 0x01.
If the binding is learned from double-tagged IEEE 802.1Q frames, the PE MAY include the EVPN VLAN Tag Extended Community with: Stacked VLANs = 0x02.
If the binding is learned from IEEE 802.1ad frames, the PE MAY include the EVPN VLAN Tag Extended Community with: Stacked VLANs = 0x03.
Based on the number of VLAN IDs that are present as part of the VLANIDs field, the count field is set appropriately whose value will have a range of 1-3.
The Reserved bits of the VLANIDs are always set to 0.

This Extended Community does not modify procedures defined in RFC 7432, including the use of the MAC Mobility Extended Community.

Reception of the EVPN VLAN Tag Extended Community Upon receiving an EVPN MAC/IP Advertisement route, a PE MUST process the EVPN VLAN Tag Extended Community as follows:

A route MUST NOT have more than one such Extended Community. If multiple instances are received then the first community is processed and all other instances MUST be ignored.
Based on the VLAN Count received, VLANIDs starting from VLANID1 are appropriately read.

IANA Considerations A new transitive extended community Type of 0x06 and Sub-Type of TBD for EVPN VLAN Tag Extended Community needs to be allocated by IANA.

Security Considerations This document relies on the EVPN control plane defined in . Therefore, all security considerations described therein apply. An attacker MAY exploit ARP or ND mechanisms to create excessive state in PEs within the same Broadcast Domain, potentially leading to resource exhaustion. Implementations SHOULD consider mitigation techniques, including:

Limiting the number of proxy ARP/ND entries per BD or per interface.
Monitoring and rate-limiting the creation of dynamic entries.

This document does not introduce new security considerations beyond those already present in EVPN.