Updates to network-instance EVPN models for EVPN redist support
Change Scope
This is part 3 of splitting the original PR #1108 into 3 separate PRs. This one targets changes required to configure redistribution of routes into EVPN
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
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
/gcbrun
No major YANG version changes in commit ffe479ea1e9b762d1ef6fb940f9db50649a10cf9
/gcbrun
Hi @abamberger-arista, the state tree doesn't match this PR? Where is vni-list?
Hi @abamberger-arista, the state tree doesn't match this PR? Where is
vni-list?
That was part of the previous PR (#1125)
I have the same comment as in the original PR: I don't believe the redistribution is a fundamentally correct approach to control mac/type-2 route distribution. It is an implementation of a specific vendor's CLI, but it doesn't mean it should be adopted in OC as it is.
IMO, the baseline EVPN implies that locally learned mac addresses are advertised to neighbors (that's the core rfc7432/rfc8365 behavior). And to my knowledge, this is what most implementations do. A typical L2 EVPN instance will not be properly functioning without the type-2 routes.
While it is true that there are certain use cases where an operator may wish to limit type-2 advertisements, that should not be the default behavior, and the use of redistribution to control that is highly questionable.
Some implementations (I'm aware of 2 vendors) offer a single bool knob to disable mac-advertisements/type-2 routes for the limited number of use cases where it may be needed.
Is there a second reference that has static/dynamic granularity?
Last but not least, can you elaborate on this part?
REDISTRIBUTE_CONNECTED, for redistributing connected IP routes into an IPVRF. Additional types of redistribution could be added in later changes.
If we are talking about the regular redistribution, then it is already defined by OpenConfig standards. If this is something specific to EVPN, please provide more details as to what, exactly, this feature is supposed to do.