Updates to network-instance EVPN models for EVPN/Vxlan support

[abamberger-arista]

Change Scope

This change seeks to accomplish 3 goals:

• Add support for configuring VLAN-aware-bundle MACVRFs, in addition to the currently supported VLAN-based MACVRFs
• Add support for configuring local VLAN-to-VNI and VRF-to-VNI mappings for VXLAN
• Add support for configuring the type(s) of MACs/IP prefixes to redistribute over EVPN for both MACVRFs and IPVRFs

Support for VLAN-aware-bundle MACVRFs

The EVPN EVI configuration in the existing network-instance model contains a “service-type” leaf used for configuring the type of MACVRF that the EVI represents. EVPN supports 3 different service types, VLAN-based, VLAN-bundle, and VLAN-aware-bundle, but per https://www.openconfig.net/docs/models/evpn_use_cases/, the existing Openconfig model only supports the VLAN-based service type (“In the current version of EVPN Model in Openconfig, VLAN_BASED is supported”).

The existing EVI model only supports configuring a single VNI per-EVI (network-instances/network-instance/evpn/evpn-instances/evpn-instance/vxlan/vni/), while configuring a VLAN-aware-bundle MACVRF requires the ability to configure all of the VNIs contained in the bundle.

To that effect, this change proposes the addition of an additional “vni-list” leaf list, which will allow the configuration of an arbitrary number of VNIs per-MACVRF. This new “vni-list” member will be made conditional on the service-type of the MACVRF being VLAN_AWARE. The existing “vni” member will be made conditional on the service type of the MACVRF being VLAN_BASED or VLAN_AWARE.

Because only VLAN-based MACVRFs are currently supported, and the existing tree will not change for those types of MACVRFs, this change is fully backwards compatible.

New tree state after proposed change (additions in bold):

module: openconfig-network-instance
+--rw network-instances
   +--rw network-instance* [name]
      +--rw evpn
         +--rw evpn-instances
            +--rw evpn-instance* [evi]
               +--rw vxlan
               |  +--rw config
               |  |  +--rw vni?                               oc-evpn-types:vni-id
               |  |  +--rw vni-list*                          oc-evpn-types:vni-id
               |  |  +--rw overlay-endpoint-network-instance? -> ...
               |  |  +--rw overlay-endpoint?                  -> ...
               |  |  +--rw host-reachability-bgp?             boolean 
               |  |  +--rw multicast-group?                   oc-inet:ip-address
               |  |  +--rw multicast-mask?                    oc-inet:ip-address
               |  +--ro state
               |  |  +--ro vni?                               oc-evpn-types:vni-id
               |  |  +--ro vni-list*                          oc-evpn-types:vni-id
               |  |  +--ro overlay-endpoint-network-instance? -> ...
               |  |  +--ro overlay-endpoint?                  -> ...
               |  +--ro host-reachability-bgp?                boolean
               |  +--ro multicast-group?                      oc-inet:ip-address
               |  +--ro multicast-mask?                       oc-inet:ip-address
               +--rw anycast-source-interface
                  +--rw config
                  |     ...
                  +--ro state
                        ...

New Yang Paths:

• network-instances/network-instance/evpn/evpn-instances/evpn-instance/vxlan/config/vni-list/
• network-instances/network-instance/evpn/evpn-instances/evpn-instance/vxlan/status/vni-list/

Support for configuring local VLAN-to-VNI and VRF-to-VNI mappings

The existing endpoint-vnis subtree for VXLAN endpoints is read-only, and seems intended for reporting state “learned on the local VXLAN Tunnel End Point from remote VTEPs in the default network instance” (see https://openconfig.net/projects/models/schemadocs/yangdoc/openconfig-network-instance.html).

To support the configuration of local VLAN-to-VNI and VRF-to-VNI mappings on a VTEP, this change proposes the addition of a “local-endpoint-vnis” subtree, which will be congruent with the existing “endpoint-vnis” subtree, but be read/write, and allow the configuration of local VLAN-to-VNI and VRF-to-VNI mappings.

It will specifically contain support for configuring the VNI, VNI type (L2 or L3), and either the bridge-domain (for L2 VNIs) or l3-vrf-name (for L3 VNIs).

Because this is a new subtree being added, this change is fully backwards compatible.

New tree state after proposed change (additions in bold):

module: openconfig-network-instance
+--rw network-instances
   +--rw network-instance* [name]
      +--rw connection-points
         +--rw connection-point* [connection-point-id]
            +--rw endpoints
               +--rw endpoint* [endpoint-id]
                  +--rw vxlan
                     +--rw local-endpoint-vnis
                        +--rw local-endpoint-vni* [vni]
                           +--rw vni       -> ../config/vni
                              +--rw config
                              |  +--rw vni?             oc-evpn-types:evi-id
                              |  +--rw vni-type?        enumeration
                              |  +--rw bridge-domain?   uint32
                              |  +--rw l3-vrf-name?     string
                              +--ro state
                                 +--ro vni?             oc-evpn-types:evi-id
                                 +--ro vni-type?        enumeration
                                 +--ro bridge-domain?   uint32
                                 +--ro l3-vrf-name?     string

New Yang Paths:

• network-instances/network-instance/connection-points/connection-point/endpoints/endpoint/vxlan/local-endpoint-vnis/…

Support for configuring the type(s) of EVPN route redistribution for MACVRFs and IPVRFs

MACVRFs and IPVRFs can be configured to redistribute different types of MACs and IP Prefixes to their peers. For instance, a MACVRF might be configured to redistribute routes for dynamic MACs learned in the associated local VLANs, but not static MACs configured in those same VLANs.

To support the ability to configure these distribution settings, this change proposes the addition of a “redistribute” leaf list to the EVI subtree, along with a new identity type for types of redistributions to support. This initial proposal has 3 types of redistributions defined, REDISTRIBUTE_LEARNED and REDISTRIBUTE_STATIC, for redistributing dynamically learned and statically configured MACs, respectively, into a MACVRF, and REDISTRIBUTE_CONNECTED, for redistributing connected IP routes into an IPVRF. Additional types of redistribution could be added in later changes.

Because this is a new leaf being added, this change is fully backwards compatible.

New tree state after proposed change (additions in bold):

module: openconfig-network-instance
+--rw network-instances
   +--rw network-instance* [name]
      +--rw evpn
         +--rw evpn-instances
            +--rw evpn-instance* [evi]
               +--rw evi                     -> ../config/evi
                  +--rw config
                  |  +--rw evi?                    string
                  |  +--rw encapsulation-type?     identityref
                  |  +--rw service-type?           identityref
                  |  +--rw multicast-group?        oc-inet:ipaddress
                  |  +--rw multicast-mask?         oc-inet:ipaddress
                  |  +--rw replication-mode?       enumeration
                  |  +--rw route-distinguisher?    union
                  |  +--rw control-word-enabled?   boolean
                  |  +--rw redistribute*           oc-evpn-types:redistribute-type
                  +--ro state
                  |  +--ro evi?                    string
                  |  +--ro encapsulation-type?     identityref
                  |  +--ro service-type?           identityref
                  |  +--ro multicast-group?        oc-inet:ip-address
                  |  +--ro multicast-mask?         oc-inet:ip-address
                  |  +--ro replication-mode?       enumeration
                  |  +--ro route-distinguisher?    union
                  |  +--ro control-word-enabled?   boolean
                  |  +--ro redistribute*           oc-evpn-types:redistribute-type

New Yang Paths:

• network-instances/network-instance/evpn/evpn-instances/evpn-instance/config/redistribute
• network-instances/network-instance/evpn/evpn-instances/evpn-instance/status/redistribute

Platform Implementations

Arista EOS:

VLAN-aware-bundle configuration:
https://www.arista.com/en/um-eos/eos-evpn-overview#xx1247264

router bgp 65002
...
   vlan-aware-bundle foo
      rd 1.1.1.11:1213
      route-target both 12:13
      redistribute learned
      vlan 12-13

VLAN-to-VNI and VRF-to-VNI mapping:
https://www.arista.com/en/um-eos/eos-vxlan-configuration#xx1152323

interface Vxlan1
   vxlan udp-port 4789
   vxlan vlan 200 vni 658120
   vxlan vlan 100 vni 100
   vxlan vrf test vni 12345

Redistribution config:
https://www.arista.com/en/um-eos/eos-sample-configurations#xx1247650

router bgp 65002
   vlan 10
      rd 1.1.1.11:1010
      route-target both 1010:1010
      redistribute learned
   !
   vlan 11
      rd 1.1.1.11:1011
      route-target both 1011:1011
      redistribute learned
      redistribute static
   !
   vrf red
   ...
      redistribute connected

[jorabada]

A comment about redistribute* - why would you need this for EVPN? I don't think there is anything similar for other BGP address families. That is, in an IP-VRF with VPN-IP, there are no leaf-lists to indicate whether you redistribute local, static or other types of routes into VPN-IP routes. Why would you do the same for EVPN routes? you can always apply policies to control what the node advertises or not. This one seems very vendor-specific, so I would not agree with adding this... my two cents.

[dplore]

In OC, redistribution between protocols and network-instances is handled via the table-connections concept. I am not completely sure if it applies here as I am not very familiar with EVPN. But from my quick look, it does sound like this redistribute goal is in fact to copy routes from one "RIB" to another.

For a deeper explanation of how OC handles redistribution, see https://github.com/openconfig/public/blob/4d4aa4b7dd94acfae84e3f567b534116e6bd5ca4/doc/network_instance_redistribution.md

[abamberger-arista]

I've taken a look at the linked documentation regarding table-connections, and while I do agree that at a high level this accomplishes much of what I was trying to model with the redistribute leaf list, I think there are some details that would need to be worked out.

The biggest mismatch to me seems to be that the existing table-connections concept is very L3-focused (for instance with address family being part of the key). I can see modeling L2-EVPN distribution as a sort of "L2 route leaking" from the local FDB into the "EVPN FDB". For instance, redistributing learned macs or static macs into EVPN could be thought of as leaking locally learned macs, or locally configured static macs, into a virtual "EVPN FDB" (where they'd subsequently be advertised as type-2 routes). There would likely need to be additional protocol types added to the INSTALL_PROTOCOL_TYPE identity (such as one for EVPN, or L2-EVPN, to function as the dst-protocol). It might be possible to re-use some of the existing protocol types for the source protocol in these instances.

What do folks think about introducing an l2-table-connections (or something along those lines), which is analogous to the existing table-connections but is more customized for the L2 case (for instance, doesn't require an address family)?

[dplore]

I've taken a look at the linked documentation regarding table-connections, and while I do agree that at a high level this accomplishes much of what I was trying to model with the redistribute leaf list, I think there are some details that would need to be worked out.

The biggest mismatch to me seems to be that the existing table-connections concept is very L3-focused (for instance with address family being part of the key). I can see modeling L2-EVPN distribution as a sort of "L2 route leaking" from the local FDB into the "EVPN FDB". For instance, redistributing learned macs or static macs into EVPN could be thought of as leaking locally learned macs, or locally configured static macs, into a virtual "EVPN FDB" (where they'd subsequently be advertised as type-2 routes). There would likely need to be additional protocol types added to the INSTALL_PROTOCOL_TYPE identity (such as one for EVPN, or L2-EVPN, to function as the dst-protocol). It might be possible to re-use some of the existing protocol types for the source protocol in these instances.

What do folks think about introducing an l2-table-connections (or something along those lines), which is analogous to the existing table-connections but is more customized for the L2 case (for instance, doesn't require an address family)?

In concept this seems fine to me. So the use case I see in the example is to redistribute learned MAC addresses into BGP? Is that right? So the source would be a specific network-instance address-family: L2_ETHERNET, install-protocol: L2_ETHERNET (this would be a new INSTALL_PROTOCOL_TYPE as you mentioned, since there's not an appropriate one defined yet)

[LimeHat]

For instance, redistributing learned macs or static macs into EVPN could be thought of as leaking locally learned macs, or locally configured static macs, into a virtual "EVPN FDB"

I think EVPN technology/specification, by itself, assumes that local MACs are advertised to peers (using route type 2). And a specific implementation requires additional configuration knobs for that. Using table connections to achieve this configuration with type 2 routes seems wrong to me: this is not a redistribution from another protocol, this is an essential, core feature of the EVPN.

I would suggest splitting this PR into two parts (vlan-aware EVPNs and advertisement of route type-2 in evpns), since a broader conversation is required to address the latter.

[dplore]

For instance, redistributing learned macs or static macs into EVPN could be thought of as leaking locally learned macs, or locally configured static macs, into a virtual "EVPN FDB"

I think EVPN technology/specification, by itself, assumes that local MACs are advertised to peers (using route type 2). And a specific implementation requires additional configuration knobs for that. Using table connections to achieve this configuration with type 2 routes seems wrong to me: this is not a redistribution from another protocol, this is an essential, core feature of the EVPN.

I would suggest splitting this PR into two parts (vlan-aware EVPNs and advertisement of route type-2 in evpns), since a broader conversation is required to address the latter.

Thanks for the information @LimeHat (myself and most of the active OC operator reviewers for OC) are not very familiar with evpn. So the PR should have at least 2 references to implementations that use such configuration to help justify that the configuration is relevant and needed.

@abamberger-arista to reduce blocking on this PR, please break this up into 3 separate PR's:

1. EVPN VLAN-aware-bundle MACVRFs
2. Configuration of VLAN-to-VNI and VRF-to-VNI mapping
3. EVPN redistribution for MACVRFs and IPVRFs

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 60ae9c1

[abamberger-arista]

Per request, I've split this into 3 separate PRs, see #1124, #1125, and #1126, and am closing this PR.