P2MP mLDP tunnels for BUM traffic in EVPN-MPLS services

P2MP mLDP tunnels for BUM traffic in EVPN-MPLS services are supported and enabled through the use of the provider-tunnel context. If EVPN-MPLS takes ownership over the provider-tunnel, bgp-ad is still supported in the service but it does not generate BGP updates, including the PMSI Tunnel Attribute. The following CLI example shows an EVPN-MPLS service that uses P2MP mLDP LSPs for BUM traffic.

*A:PE-1>config>service>vpls(vpls or b-vpls)# info 
----------------------------------------------
  description "evpn-mpls-service with p2mp mLDP"
  bgp-evpn
    evi 10
    no ingress-repl-inc-mcast-advertisement 
    mpls bgp 1
      no shutdown
      auto-bind-tunnel resolution any
  exit
  provider-tunnel
    inclusive
      owner bgp-evpn-mpls
      root-and-leaf
      mldp
      no shutdown
      exit
    exit
  sap 1/1/1:1 create 
  exit
  spoke-sdp 1:1 create
 exit

When provider-tunnel inclusive is used in EVPN-MPLS services, the following commands can be used in the same way as for BGP-AD or BGP-VPLS services:

data-delay-interval
root-and-leaf
mldp
shutdown

The following commands are used by provider-tunnel in BGP-EVPN MPLS services:

[no] ingress-repl-inc-mcast-advertisement

This command allows you to control the advertisement of IMET-IR and IMET-P2MP-IR routes for the service. See BGP-EVPN control plane for MPLS tunnels for a description of the IMET routes. The following considerations apply:
- If configured as no ingress-repl-inc-mcast-advertisement, the system does not send the IMET-IR or IMET-P2MP-IR routes, regardless of the service being enabled for BGP-EVPN MLPLS or BGP-EVPN VXLAN.
- If configured as ingress-repl-inc-mcast-advertisement and the PE is root-and-leaf, the system sends an IMET-P2MP-IR route.
- If configured as ingress-repl-inc-mcast-advertisement and the PE is no root-and-leaf, the system sends an IMET-IR route.
- Default value is ingress-repl-inc-mcast-advertisement.
[no] owner {bgp-ad | bgp-vpls | bgp-evpn-mpls}

The owner of the provider tunnel must be configured. The default value is no owner. The following considerations apply:
- Only one of the protocols supports a provider tunnel in the service and it must be explicitly configured.
- bgp-vpls and bgp-evpn are mutually exclusive.
- While bgp-ad and bgp-evpn can coexist in the same service, only bgp-evpn can be the provider-tunnel owner in such cases.

Figure: EVPN services with p2mp mLDP—control plane shows the use of P2MP mLDP tunnels in an EVI with a root node and a few leaf-only nodes.

Figure: EVPN services with p2mp mLDP—control plane

Consider the use case of a root-and-leaf PE4 where the other nodes are configured as leaf-only nodes (no root-and-leaf). This scenario is handled as follows:

If ingress-repl-inc-mcast-advertisement is configured, then as soon as the bgp-evpn mpls option is enabled, the PE4 sends an IMET-P2MP route (tunnel type mLDP), or optionally, an IMET-P2MP-IR route (tunnel type composite). IMET-P2MP-IR routes allow leaf-only nodes to create EVPN-MPLS multicast destinations and send BUM traffic to the root.
If ingress-repl-inc-mcast-advertisement is configured, PE1/2/3 do not send IMET-P2MP routes; only IMET-IR routes are sent.
- The root-and-leaf node imports the IMET-IR routes from the leaf nodes but it only sends BUM traffic to the P2MP tunnel as long as it is active.
- If the P2MP tunnel goes operationally down, the root-and-leaf node starts sending BUM traffic to the evpn-mpls multicast destinations
When PE1/2/3 receive and import the IMET-P2MP or IMET-P2MP-IR from PE4, they join the mLDP P2MP tree signaled by PE4. They issue an LDP label-mapping message including the corresponding P2MP FEC.

As described in IETF Draft draft-ietf-bess-evpn-etree, mLDP and Ingress Replication (IR) can work in the same network for the same service; that is, EVI1 can have some nodes using mLDP (for example, PE1) and others using IR (for example, PE2). For scaling, this is significantly important in services that consist of a pair of root nodes sending BUM in P2MP tunnels and hundreds of leaf-nodes that only need to send BUM traffic to the roots. By using IMET-P2MP-IR routes from the roots, the operator makes sure the leaf-only nodes can send BUM traffic to the root nodes without the need to set up P2MP tunnels from the leaf nodes.

When both static and dynamic P2MP mLDP tunnels are used on the same router, Nokia recommends that the static tunnels use a tunnel ID lower than 8193. If a tunnel ID is statically configured with a value equal to or greater than 8193, BGP-EVPN may attempt to use the same tunnel ID for services with enabled provider-tunnel, and fail to set up an mLDP tunnel.

Inter-AS option C or seamless-MPLS models for non-segmented mLDP trees are supported with EVPN for BUM traffic. The leaf PE that joins an mLDP EVPN root PE supports Recursive and Basic Opaque FEC elements (types 7 and 1, respectively). Therefore, packet forwarding is handled as follows:

The ABR or ASBR may leak the root IP address into the leaf PE IGP, which allows the leaf PE to issue a Basic opaque FEC to join the root.
The ABR or ASBR may distribute the root IP using BGP label-ipv4, which results in the leaf PE issuing a Recursive opaque FEC to join the root.

For more information about mLDP opaque FECs, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN and the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide.

All-active multihoming and single-active with an ESI label multihoming are supported in EVPN-MPLS services together with P2MP mLDP tunnels. Both use an upstream-allocated ESI label, as described in RFC 7432 section 8.3.1.2, which is popped at the leaf PEs, resulting in the requirement that, in addition to the root PE, all EVPN-MPLS P2MP leaf PEs must support this capability (including the PEs not connected to the multihoming ES).