[dev] EVPN (and L3VPN) configuration

Lou Berger lberger at labn.net
Mon Jun 19 10:51:44 EDT 2017



On 6/17/2017 1:25 AM, Vivek Venkatraman wrote:
> Hi Lou and Philippe,
>
> Besides the provisioning angle, how these entities map to current data
> structures and code flow also is a consideration, IMO. Everything
> about the current VRF ('struct bgp' or 'struct zebra_vrf' or soon to
> be introduced support for OSPF) pertains to a Layer-3 routing
> instance. I'm not sure it is a good idea to either morph that
> construct into a Layer-2 (bridging) instance too or try to envelope a
> Layer-2 instance and a Layer-3 instance under something else (like
> "network-instance").

What are your thoughts on when we get to bridge+router capability? 
Allowing for this is part of what drove my comments.

I have a fair bit of this in a prototype using rfapi and openflow, but
not quete working or in sharable form.  (Just need to find a few days to
code!)

>
> My line of thinking after discussion with a few of my colleagues is as
> follows:
>
> 1. We should keep Layer-3 instance and Layer-2 instance configuration
> distinct, though there may be some common parameters that both have.
Again, we can't forget about the real case of bridge routers and cause
us problems down the road.

> 2. While internal semantics indicate some parameters are "CE related"
> and other parameters are "PE related", there are instances where it
> can be argued either way. In any case, it would be easier for the
> user/operator to have the configuration for one entity in one place,
> as much as possible.
I think your distinction is customer-facing (within VRF/VSI) and
provider-facing (within core/provider transport), right?

> 3. The reference to "VNI" directly and some aspects of the
> configuration syntax in my PR make it too specific to EVPN for VxLAN.
> This should be made more generic.
Does VSI work for you?

> 4. There are certain aspects though about EVPN for VxLAN that allow
> for auto-creation and auto-derivation for which allowance has to be
> made. For e.g., I'm sure an operator wouldn't want to configure a
> named-instance for each VNI on the system when the VNI itself can be
> the key and can be learnt by the routing control plane from the kernel.
>
> With these in mind, I'll discuss a proposal with my colleagues before
> bringing it here for further discussion next week.
>
Excellent!

Lou

> Thanks,
> Vivek
>
>
>
> On Thu, Jun 15, 2017 at 6:53 AM, Lou Berger <lberger at labn.net
> <mailto:lberger at labn.net>> wrote:
>
>     Philippe,
>
>     I agree with your analysis.  One additional point bellow.
>
>
>     On 6/15/2017 9:18 AM, Philippe Guibert wrote:
>     > Hi Vivek,
>     >
>     > I just saw Lou's reply message.
>     > Initial agreement was using vrf-policy under bgp node.
>     > If I understand correctly, there is kind of redundancy with EVPN
>     > address-family vni configuration command used on CE side.
>     >
>     > Your remark is very interesting. I think it is worth looking at
>     how to
>     > fuse both configuration ways.
>     > Please find below some remarks on what could be done.
>     >
>     >> 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
>     >>
>     >> I see it as being very useful to have all the configuration
>     relevant to a
>     >> VRF (or VNI) in one place.
>     > Thanks for point out that. I agree with you
>     >
>     >> 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"?
>     > If we want to have a common vty node to enter the information, I
>     would
>     > like to draw your attention to the following:
>     > - This vty node should be used for not only EVPN,but also VPNVx
>     > address families.
>     > The vni value used should be an attribute of that VPN object ( since
>     > vxlan does not apply to VPNVx afi/safi).
>     > This vty node should be moved from evpn address-family to bgp node.
>     >
>     > - This vty node stands for a VRF that should be used.
>     > It is true that in comparison to route-map concept, the "vrf-policy"
>     > wording could be improved.
>     > But we have to distinguish the vtynode from VRF node that is used
>     > outside of BGP node.
>     >
>     > Based on vrf-policy wording, the subnode vty commands should be
>     added
>     > vni keyword.
>     This would also work nicely for the future case where the VNI is a
>     bridge/router. it would just fall out by specifying a valid vrf
>     name in
>     the vrf-policy.  Although this does lead to the slightly ugly case of
>     needing to rename the 'policy' when associating a running VNI/VSI
>     (bridge) with a VRF.  perhaps it makes sense to uncouple of the
>     binding
>     of the "policy" with the VRF name and VSI/VNI ID.  e.g.,
>
>
>      network-instance <node-name>
>        !when associated with a named BGP VRF
>         vrf <vrf-name>
>        !when associated with a vni
>         vni <vni-id>
>         rd <value>
>         rt (import|export|both) <value> [<value-list>]
>         label <value>
>         route-map <mapname>
>         tunnel advertisement-method <encap-attribute|evpn>
>         tunnel type (none|l2tpv3overip|gre|ipinip|vxlan|mpls|mplsovergre)
>
>
>     The name network-instance comes from
>         https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model
>     <https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model>
>
>     An alternative is to not add vrf/vni above and do something like
>      router bgp XXX vrf <vrf-name>*
>        network-instance <node-name>
>
>     and under a new bgp vsi (I like the more generic name VSI over
>     VNI) node
>       vsi <vni-id>
>        network-instance <node-name>
>
>     but then it's up to the config reader to notice when something is
>     a bridge and/or router instance.  (so I prefer the first
>
>
>     > Vivek, those changes have also wider impact, I mean, at least
>     > internally in the BGP daemon.
>     > I list some of the changes that may be done, if we merge [both vty
>     > nodes in a single one.
>     >
>     > - The VRF configuration calls VNC code, while VNI configuration
>     calls
>     > bgp_evpn_vty.c code.
>     > This should be put in a separate file. A registration mechanism with
>     > EVPN and VNC could apply.
>     Yes this would need to change.
>
>     > - Some other attributes of EVPN ( RD and RT auto derivation)
>     could be
>     > configurable within that new VRF instance.
>     >
>     > - Also, regarding the advertise-all-vni command, does that mean that
>     > such VNI ( VRFs objects ) should be instantiated too ?
>     > I mean, I am sorry, I did not attend the specific EVPN meeting you
>     > lead a few weeks ago. I know Lou was there.
>
>     > Perhaps you talked about the way to exchange VNI information between
>     > EVPN and VNC ?
>     We did, but all future (non blocking) stuff.  The sole blocking issue
>     from my perspective is resolving this discussion.
>
>     Lou
>
>     > Regards,
>     >
>     > Philippe
>     >
>     >
>     > [0]
>     https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#
>     <https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#>
>     >
>     >
>     >
>     >
>     >> 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 <mailto:dev at lists.frrouting.org>
>     >> https://lists.frrouting.org/listinfo/dev
>     <https://lists.frrouting.org/listinfo/dev>
>     >>
>
>




More information about the dev mailing list