[dev] EVPN (and L3VPN) configuration

[Philippe Guibert]

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.

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.

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

Regards,

Philippe


[0] 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
> https://lists.frrouting.org/listinfo/dev
>