EVPN and VPLS integration

In accordance with draft-ietf-bess-evpn-vpls-seamless-integ, the 7210 SAS EVPN implementation supports the integration of EVPN-MPLS and VPLS to the same network within the same service. Because EVPN is not deployed in greenfield deployments, this feature is useful for facilitating the integration between both technologies and for migrating VPLS services to EVPN-MPLS.

The following behavior enables the integration of EVPN and SDP-bindings in the same VPLS network:

Systems with EVPN endpoints and SDP-bindings to the same far-end bring down the SDP-bindings.
- The router allows the establishment of an EVPN endpoint and an SDP-binding to the same far-end, but the SDP-binding is kept operationally down. Only the EVPN endpoint is operationally up. This applies to spoke-SDPs (manual).
- If an EVPN endpoint to a specified far-end exists and a spoke-SDP establishment is attempted, the spoke-SDP is set up but is kept down with an operational flag, indicating that there is an EVPN route to the same far-end.
- If an spoke-SDP exists and a valid or used EVPN route arrives, the EVPN endpoint is set up and the spoke-SDP is brought down with an operational flag indicating that there is an EVPN route to the same far-end.
- In the case of an SDP-binding and EVPN endpoint to different far-end IPs on the same remote PE, both links are up. This may occur if the SDP-binding is terminated in an IPv4 address that is different from the system address where the EVPN endpoint is terminated.
Users can add spoke-SDPs and all the EVPN-MPLS endpoints in the same split-horizon group (SHG).
- The following CLI command is added under the bgp-evpn>mpls context so that the EVPN-MPLS endpoints can be added to a split-horizon group: bgp-evpn mpls [no] split-horizon-group group-name.
- The bgp-evpn mpls split-horizon-group command must reference a user-configured split-horizon group. User-configured split-horizon groups can be configured within the service context. The same group-name can be associated with SAPs, spoke-SDPs, pw-template-bindings, and EVPN-MPLS endpoints.
- If the bgp-evpn mpls split-horizon-group command is not used, the default split-horizon group (that contains all the EVPN endpoints) is still used but cannot be referred to using SAPs/spoke-SDPs.
- The 7210 SAS-R6 and 7210 SAS-R12 equipped with an IMM-c card do not support a user-configured SHG. To configure the spoke-SDP and EVPN bindings in the same SHG group, the user can reference the default SHG using spoke-SDPs by configuring the use-evpn-default-shg option when the spoke-SDP is created. See VPLS services command reference for more information about the use-evpn-default-shg option.
The system disables the advertisement of MACs learned on spoke-SDPs or SAPs that are part of an EVPN split-horizon group.
- When the SAPs or spoke-SDPs (manual) are configured within the same split-horizon group as the EVPN endpoints, MAC addresses are still learned on them, but they are not advertised in EVPN.
- The preceding statement is also true if proxy-ARP/proxy-ND is enabled and an IP-to-MAC pair is learned on a SAP that belongs to the EVPN split-horizon group.
- The SAPs added to an EVPN split-horizon group should not be part of any EVPN multi-homed ES. If that occurs, the PE still advertises the AD per-EVI route for the SAP, attracting EVPN traffic that could not possibly be forwarded to that SAP.

The following figure shows an example of EVPN-VPLS integration.

Figure: EVPN-VPLS integration

The following example shows the configuration for PE1, PE5, and PE2 from the EVPN-VPLS integration example in the preceding figure.

Example: EVPN-VPLS integration configuration for PE1, PE5, and PE2

*A:PE1>config>service# info 
----------------------------------------------
vpls 1 customer 1 create
  split-horizon-group "SHG-1" create 
  bgp
    route-target target:65000:1
  bgp-evpn
    evi 1
    mpls
      no shutdown
  spoke-sdp 12:1 create
  exit
  spoke-sdp 13:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 14:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 15:1 split-horizon-group "SHG-1" create
  exit
  sap 1/1/1:1 create
  exit

*A:PE5>config>service# info 
----------------------------------------------
split-horizon-group "SHG-1" create
vpls 1 customer 1 create
  bgp
    route-target target:65000:1
  spoke-sdp 52:1 create
  exit
  spoke-sdp 51:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 53:1 split-horizon-group "SHG-1" create
  exit
  spoke-sdp 54:1 split-horizon-group "SHG-1" create
  exit

*A:PE2>config>service# info 
----------------------------------------------
vpls 1 customer 1 create
  end-point CORE create
    no suppress-standby-signaling
  spoke-sdp 21:1 end-point CORE
    precedence primary
  spoke-sdp 25:1 end-point CORE

The following applies to the configuration described in the preceding examples:

PE1, PE3, and PE4 have BGP-EVPN enabled in VPLS-1. PE2 has active/standby spoke SDPs to PE1 and PE5. In this configuration:
- PE1, PE3, and PE4 have manual spoke SDPs, but they are kept operationally down as long as there are EVPN endpoints active among them.
- Manual spoke SDPs on PE1, PE3, and PE4 and EVPN endpoints are instantiated within the same SHG, for example, the default SHG.
- Manual spoke SDPs from PE1 and PE5 to PE2 are not part of the default SHG.
For spoke SDPs and EVPN in the same SHG, MACs learned locally on a spoke SDP are not advertised in EVPN
BUM traffic operation on PE1:
- When CE1 sends BUM traffic, PE1 floods to all the active bindings.
- When CE2 sends BUM traffic, PE2 sends it to PE1 (active spoke SDP) and PE1 floods to all the bindings and SAPs.
- When CE5 sends BUM traffic, PE5 floods to the three EVPN PEs. PE1 floods to the active spoke SDP and SAPs, never to the EVPN PEs because they are part of the same SHG.