<div dir="ltr">About 3 weeks ago, I submitted PR 619 (<a href="https://github.com/FRRouting/frr/pull/619">https://github.com/FRRouting/frr/pull/619</a>) which provides the standardized EVPN control plane for VxLAN. This is the EVPN implementation that is available/shipping with Cumulus Linux, just merged with the FRR 'master' branch. The PR provides a summary of the functionality.<div><br></div><div>The essential configuration involves only two steps as documented in the file doc/<a href="http://evpn.md">evpn.md</a>:</div><div><br></div><div>1. Enable (activate) the EVPN (AFI/SAFI 25/70) address-family between BGP speakers</div><div>2. Enable EVPN itself on the local system - to advertise local VNIs and MACs and Neighbors (ARP/ND) associated with those VNIs using BGP/EVPN procedures. The RD and RT parameters will be automatically derived as specified in these procedures and/or prevalent best practice.</div><div><br></div><div>Step #2 is of course not needed on a Route Reflector.</div><div><br></div><div>In addition, there are commands to configure the RD and RTs if auto-derivation is not desired - for e.g., peering with third-party BGP system. The syntax for this is shown through an example configuration below (which also shows steps #1 and #2).</div><div><br></div><div><div><font face="monospace, monospace">router bgp 65001</font></div><div><font face="monospace, monospace"> address-family l2vpn evpn</font></div><div><font face="monospace, monospace">  neighbor SPINE activate</font></div><div><font face="monospace, monospace">  vni 10100</font></div><div><font face="monospace, monospace">   rd 1:10100</font></div><div><font face="monospace, monospace">   route-target import 1:10100</font></div><div><font face="monospace, monospace">  exit-vni</font></div><div><font face="monospace, monospace">  advertise-all-vni</font></div><div><font face="monospace, monospace"> exit-address-family</font></div></div><div><br></div><div>One topic of discussion is regarding this optional VNI configuration. Instead of the keyword being "vni", should it be "vni-policy" to match with "vrf-policy"?</div><div><br></div><div>I don't think "vni-policy", or for that matter, "vrf-policy" is the best choice due to the following two main reasons:</div><div><br></div><div>1. A "policy" is a fairly familiar construct in routing parlance. It commonly refers to a set of rules or definitions that are generically specified and can then be applied to different "attach points". In FRR, a "route-map" would be a good example of such a policy. It may be misleading to call the specific configuration for a VNI or VRF as "policy", particularly when the VNI/VRF may later support import/export policies (route-maps).</div><div><br></div><div>2. The configuration syntax that emerged for VRFs after the last round of discussions separates out the "CE side" configuration (e.g., CE neighbors, redistribution etc.) from the "PE side" configuration (e.g., RD and RT configuration). From the user/operator's perspective, I do not see any value add in this separation, only a potential source of confusion since the same entity (VRF) needs to be configured in multiple places. It can also be debatable where a configuration lies. For e.g., should "vrf-import-policy" reside on the "PE side" as it deals with received L3VPN routes or on the "CE side" as it decides which routes to import into which VRF table?</div><div><br></div><div>I see it as being very useful to have all the configuration relevant to a VRF (or VNI) in one place.</div><div><br></div><div>The purpose of this email is to solicit wider feedback since only a few people participated in the earlier discussion and their positions are very likely unchanged. My suggestion would be to have the initial deliberations on the list and if that does not converge or indicates the need for a meeting, the maintainers will call one.</div><div><br></div><div>Based on the consensus that emerges, I shall update my PR and/or introduce modifications in a subsequent PR - if needed.</div><div><br></div><div>Vivek</div><div><br></div></div>