[dev] EVPN (and L3VPN) configuration

[Lou Berger]

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

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