[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