<div dir="ltr">Hi Lou and Philippe,<div><br></div><div>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").</div><div><br></div><div>My line of thinking after discussion with a few of my colleagues is as follows:</div><div><br></div><div>1. We should keep Layer-3 instance and Layer-2 instance configuration distinct, though there may be some common parameters that both have.</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>With these in mind, I'll discuss a proposal with my colleagues before bringing it here for further discussion next week.</div><div><br></div><div>Thanks,</div><div>Vivek</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 6:53 AM, Lou Berger <span dir="ltr"><<a href="mailto:lberger@labn.net" target="_blank">lberger@labn.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Philippe,<br>
<br>
I agree with your analysis. One additional point bellow.<br>
<br>
<br>
On 6/15/2017 9:18 AM, Philippe Guibert wrote:<br>
> Hi Vivek,<br>
><br>
> I just saw Lou's reply message.<br>
> Initial agreement was using vrf-policy under bgp node.<br>
> If I understand correctly, there is kind of redundancy with EVPN<br>
> address-family vni configuration command used on CE side.<br>
><br>
> Your remark is very interesting. I think it is worth looking at how to<br>
> fuse both configuration ways.<br>
> Please find below some remarks on what could be done.<br>
><br>
>> In addition, there are commands to configure the RD and RTs if<br>
>> auto-derivation is not desired - for e.g., peering with third-party BGP<br>
>> system. The syntax for this is shown through an example configuration below<br>
>> (which also shows steps #1 and #2).<br>
>><br>
>> router bgp 65001<br>
>> address-family l2vpn evpn<br>
>> neighbor SPINE activate<br>
>> vni 10100<br>
>> rd 1:10100<br>
>> route-target import 1:10100<br>
>> exit-vni<br>
>> advertise-all-vni<br>
>> exit-address-family<br>
>><br>
>> I see it as being very useful to have all the configuration relevant to a<br>
>> VRF (or VNI) in one place.<br>
> Thanks for point out that. I agree with you<br>
><br>
>> One topic of discussion is regarding this optional VNI configuration.<br>
>> Instead of the keyword being "vni", should it be "vni-policy" to match with<br>
>> "vrf-policy"?<br>
> If we want to have a common vty node to enter the information, I would<br>
> like to draw your attention to the following:<br>
> - This vty node should be used for not only EVPN,but also VPNVx<br>
> address families.<br>
> The vni value used should be an attribute of that VPN object ( since<br>
> vxlan does not apply to VPNVx afi/safi).<br>
> This vty node should be moved from evpn address-family to bgp node.<br>
><br>
> - This vty node stands for a VRF that should be used.<br>
> It is true that in comparison to route-map concept, the "vrf-policy"<br>
> wording could be improved.<br>
> But we have to distinguish the vtynode from VRF node that is used<br>
> outside of BGP node.<br>
><br>
> Based on vrf-policy wording, the subnode vty commands should be added<br>
> vni keyword.<br>
This would also work nicely for the future case where the VNI is a<br>
bridge/router. it would just fall out by specifying a valid vrf name in<br>
the vrf-policy. Although this does lead to the slightly ugly case of<br>
needing to rename the 'policy' when associating a running VNI/VSI<br>
(bridge) with a VRF. perhaps it makes sense to uncouple of the binding<br>
of the "policy" with the VRF name and VSI/VNI ID. e.g.,<br>
<br>
<br>
network-instance <node-name><br>
!when associated with a named BGP VRF<br>
vrf <vrf-name><br>
!when associated with a vni<br>
vni <vni-id><br>
rd <value><br>
rt (import|export|both) <value> [<value-list>]<br>
label <value><br>
route-map <mapname><br>
tunnel advertisement-method <encap-attribute|evpn><br>
tunnel type (none|l2tpv3overip|gre|ipinip|<wbr>vxlan|mpls|mplsovergre)<br>
<br>
<br>
The name network-instance comes from<br>
<a href="https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>draft-ietf-rtgwg-ni-model</a><br>
<br>
An alternative is to not add vrf/vni above and do something like<br>
router bgp XXX vrf <vrf-name>*<br>
network-instance <node-name><br>
<br>
and under a new bgp vsi (I like the more generic name VSI over VNI) node<br>
vsi <vni-id><br>
network-instance <node-name><br>
<br>
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<br>
<br>
<br>
> Vivek, those changes have also wider impact, I mean, at least<br>
> internally in the BGP daemon.<br>
> I list some of the changes that may be done, if we merge [both vty<br>
> nodes in a single one.<br>
><br>
> - The VRF configuration calls VNC code, while VNI configuration calls<br>
> bgp_evpn_vty.c code.<br>
> This should be put in a separate file. A registration mechanism with<br>
> EVPN and VNC could apply.<br>
Yes this would need to change.<br>
<br>
> - Some other attributes of EVPN ( RD and RT auto derivation) could be<br>
> configurable within that new VRF instance.<br>
><br>
> - Also, regarding the advertise-all-vni command, does that mean that<br>
> such VNI ( VRFs objects ) should be instantiated too ?<br>
> I mean, I am sorry, I did not attend the specific EVPN meeting you<br>
> lead a few weeks ago. I know Lou was there.<br>
<br>
> Perhaps you talked about the way to exchange VNI information between<br>
> EVPN and VNC ?<br>
We did, but all future (non blocking) stuff. The sole blocking issue<br>
from my perspective is resolving this discussion.<br>
<br>
Lou<br>
<br>
> Regards,<br>
><br>
> Philippe<br>
><br>
><br>
> [0] <a href="https://docs.google.com/document/d/1w_ie2tNXCgn0N3ZNFGYTK6lJkwMmk_XN5yz33MMNNqM/edit#" rel="noreferrer" target="_blank">https://docs.google.com/<wbr>document/d/1w_<wbr>ie2tNXCgn0N3ZNFGYTK6lJkwMmk_<wbr>XN5yz33MMNNqM/edit#</a><br>
><br>
><br>
><br>
><br>
>> I don't think "vni-policy", or for that matter, "vrf-policy" is the best<br>
>> choice due to the following two main reasons:<br>
>><br>
>> 1. A "policy" is a fairly familiar construct in routing parlance. It<br>
>> commonly refers to a set of rules or definitions that are generically<br>
>> specified and can then be applied to different "attach points". In FRR, a<br>
>> "route-map" would be a good example of such a policy. It may be misleading<br>
>> to call the specific configuration for a VNI or VRF as "policy",<br>
>> particularly when the VNI/VRF may later support import/export policies<br>
>> (route-maps).<br>
>><br>
>> 2. The configuration syntax that emerged for VRFs after the last round of<br>
>> discussions separates out the "CE side" configuration (e.g., CE neighbors,<br>
>> redistribution etc.) from the "PE side" configuration (e.g., RD and RT<br>
>> configuration). From the user/operator's perspective, I do not see any value<br>
>> add in this separation, only a potential source of confusion since the same<br>
>> entity (VRF) needs to be configured in multiple places. It can also be<br>
>> debatable where a configuration lies. For e.g., should "vrf-import-policy"<br>
>> reside on the "PE side" as it deals with received L3VPN routes or on the "CE<br>
>> side" as it decides which routes to import into which VRF table?<br>
>><br>
>> I see it as being very useful to have all the configuration relevant to a<br>
>> VRF (or VNI) in one place.<br>
>><br>
>> The purpose of this email is to solicit wider feedback since only a few<br>
>> people participated in the earlier discussion and their positions are very<br>
>> likely unchanged. My suggestion would be to have the initial deliberations<br>
>> on the list and if that does not converge or indicates the need for a<br>
>> meeting, the maintainers will call one.<br>
>><br>
>> Based on the consensus that emerges, I shall update my PR and/or introduce<br>
>> modifications in a subsequent PR - if needed.<br>
>><br>
>> Vivek<br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> dev mailing list<br>
>> <a href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a><br>
>> <a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/<wbr>listinfo/dev</a><br>
>><br>
<br>
</blockquote></div><br></div>