[dev] Fwd: Re: EVPN (and L3VPN) configuration

[Lou Berger]

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 at labn.net>
To: dev at 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 at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev