BGP EVPN control plane for EVPN E-Tree

BGP EVPN control plane is extended and aligned with IETF RFC 8317 to support EVPN E-Tree services. Figure: EVPN E-Tree BGP routes shows the main EVPN extensions for the EVPN E-Tree information model.

Figure: EVPN E-Tree BGP routes

The following BGP extensions are implemented for EVPN E-Tree services:

• An EVPN E-Tree extended community (EC) sub-type 0x5 is defined. The following information is included:

  • The lower bit of the Flags field contains the L bit (where L=1 indicates leaf AC).

  • The leaf label contains a 20-bit MPLS label in the high-order 20 bits of the label field. This leaf label is automatically allocated by the system or statically assigned by the evpn-etree-leaf-label <value> command.

• The new E-Tree EC is sent with the following routes:

  • AD per-ES per PE route for BUM egress filtering:

    Each EVPN E-Tree capable PE advertises an AD per-ES route with the E-Tree EC, and the following information:

    • Service RD and route-target; if ad-per-es-route-target evi-rt-set is configured, then non-zero ESI AD per-ES routes (used for multihoming) are sent per the evi-rt-set configuration, but E-Tree zero-ESI routes (used for E-Tree) are sent based on the default evi-rt configuration

    • ESI = 0

    • Eth Tag = MAX-ET

    • MPLS label = zero

  • AD per-EVI route for root or leaf configuration consistency check as follows:

    • The E-Tree EC is sent with the AD per-EVI routes for a specific ES. In this case, no validation is performed by the implementation, and the leaf indication is only used for troubleshooting on the remote PEs.

    • The MPLS label value is zero.

    • All attachment circuits (ACs) in each EVI for a specific ES must be configured as either a root or leaf AC, but not a combination. In case of a configuration error, for example, where the AC in PE1 is configured as root and in PE2 as leaf AC, the remote PE3 receives the AD per-EVI routes with inconsistent leaf indication. However, the unicast filtering remains unaffected and is still handled by the FDB lookup information.

  • MAC/IP routes for known unicast ingress filtering as follows:

    • An egress PE sends all MAC/IP routes learned over a leaf AC SAP or spoke SDP with this E-Tree EC indicating that the MAC/IP belongs to a leaf AC.

    • The MPLS label value in the EC is 0.

    • Upon receiving a route with E-Tree EC, the ingress PE imports the route and installs the MAC in the FDB with a leaf flag (if there is a leaf indication in the route). Any frame coming from a leaf AC for which the MAC destination address (DA) matches a leaf AC MAC is discarded at the ingress.

    • If two PEs send the same MAC with the same ESI but inconsistent root or leaf AC indication, the MAC is installed in the FDB as root.