[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