[dev] EVPN (and L3VPN) configuration
Lou Berger
lberger at labn.net
Tue Jun 20 12:44:37 EDT 2017
see below.
On 6/20/2017 11:42 AM, Philippe Guibert wrote:
> 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.
from the bgp distribution side, there is both a (L2VPN) mac and (L3VPN)
CE-advertised/PE-learned route to distribute in this case.
>
>>> 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 ?
I think of VSI = VRF for L2. So labels may or may be used based on config.
Lou
>
>>> 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