[dev] EVPN (and L3VPN) configuration

Philippe Guibert philippe.guibert at 6wind.com
Tue Jun 20 11:42:43 EDT 2017


Hi Lou, Vivek,

inline my comments,


On Mon, Jun 19, 2017 at 4:51 PM, Lou Berger <lberger at labn.net> wrote:
>
>
> 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.

I am not sure about that.
Right now, I don't have the exact use case that shows that. I will
give more information later.
What I mean is that there may be some instances that can get both L3
and L2 information.
As far as I know, this is the case for RT2 entries with two labels inside.

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

Does VSI covers MPLs labels ?

>
>> 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!
++1

Philippe



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