Resend -- looks like previous message didn't make it to the list. -------- Forwarded Message -------- Subject: Re: [dev] EVPN (and L3VPN) configuration Date: Tue, 13 Jun 2017 20:49:05 -0400 From: Lou Berger <lberger@labn.net> To: dev@lists.frrouting.org Hi Vivek, Thanks for this message - discussing on list is useful. My view is that we had lots of discussions the last time around and cam up with a compromise solution. (From my view, I'm okay with changing this past agreement as long as there is community agreement on the new syntax.) Here's what I see in the notes document from the last time around: ** *config term* * router bgp .... !core instance vrf-policy <vrf-name> rd <value> route-map <mapname> label <value> #nexthop ip <> | ipv6 <> Rt import <> | export <> | both <> [no] tunnel advertisement-method <encap-attribute|evpn> tunnel type <none| l2tpv3overip | gre | ipinip | vxlan | mpls | mplsovergre > route-map rmap permit 10 Set label <value> set extcommunity rt 10:100 set extcommunity soo 10:102 set ip nexthop <> | ipv6 nexthop <>* router bgp XXX vrf <vrf-name>* ! (address-family ipv4) network 1.2.3.0/24 <http://1.2.3.0/24>route-map foo neighbor ... ! CE session (or alternately, VRF-lite session) !make vrf redistribution (import/export)the default redistribute static|ospf|vrf [route map] ...! CE setup for OSPF no redistribute vrf no export vrf export vrf [route map] ... add [vrf <vrf-name>] prefix <prefix> [rd <value>] [label <value>] [pref (0-255)] clear [vrf <vrf-name>] <all|prefix <prefix> [rd <value>]|rd <value>> <extracted from google docs notes> Lou On 6/13/2017 3:08 PM, Vivek Venkatraman wrote:

About 3 weeks ago, I submitted PR 619 (https://github.com/FRRouting/frr/pull/619) 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.

The essential configuration involves only two steps as documented in the file doc/evpn.md <http://evpn.md>:

1. Enable (activate) the EVPN (AFI/SAFI 25/70) address-family between BGP speakers 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.

Step #2 is of course not needed on a Route Reflector.

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).

router bgp 65001 address-family l2vpn evpn neighbor SPINE activate vni 10100 rd 1:10100 route-target import 1:10100 exit-vni advertise-all-vni exit-address-family

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"?

I don't think "vni-policy", or for that matter, "vrf-policy" is the best choice due to the following two main reasons:

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).

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?

I see it as being very useful to have all the configuration relevant to a VRF (or VNI) in one place.

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.

Based on the consensus that emerges, I shall update my PR and/or introduce modifications in a subsequent PR - if needed.

Vivek

_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev