Neale, I think this really really fundamentally comes down to the ability to configure in batch. If I know I want to send something to vpp that creates an interface and configures it in a *batch*, I can't know when I send that batch configuration what sw_index will be. So I either have to break up the batch or have a way of getting a deterministic handle (name) to configure the interface being created. When you are writing a local control plane, you often just say "fuck it, I'm not going to be able to batch. But if you are writing a remote control plane (high latency per message) or have a user copy pasting over configs via a CLI (not our CLI, but another CLI you write) etc... batching is crucially important.
Ed On Wed, Feb 7, 2018 at 7:18 AM Neale Ranns (nranns) <nra...@cisco.com> wrote: > > > But all control planes need to know the sw_if_index provided by VPP as it > is this value (and not the interface name) that one needs to subsequently > configure the interface. So why the reliance of VPP’s given name? AFIAK > VPP’s given name is only important when interpreting CLI output. > > All control planes are free to choose whatever naming schemes they like, > but they must maintain a control-plane-name to sw_if_index mapping. And to > make VPP CLI output more useful, also maintain a control-plane-name to > VPP-name mapping. In other words, X, is always the control-plane-name. > > > > /neale > > > > > > *From: *"John Lo (loj)" <l...@cisco.com> > *Date: *Wednesday, 7 February 2018 at 15:34 > *To: *"Neale Ranns (nranns)" <nra...@cisco.com>, Jon Loeliger < > j...@netgate.com> > *Cc: *vpp-dev <vpp-dev@lists.fd.io> > *Subject: *RE: [vpp-dev] VXLAN Tunnel IF Names > > > > I guess Jon’s point was the control plane need to know exactly what X > would be and not rely on VPP to provide the sw_if_index or query VPP for > the name after the VXLAN create request. This makes the control plane CLI > script/template support more straight forward. In the case of mixed usage > where a requested instance is not available, I wonder how control plane > should handle the error condition if it does not check the result of the > VXLAN create request… -John > > > > *From:* Neale Ranns (nranns) > *Sent:* Wednesday, February 07, 2018 5:55 AM > *To:* Jon Loeliger <j...@netgate.com>; John Lo (loj) <l...@cisco.com> > *Cc:* vpp-dev <vpp-dev@lists.fd.io> > *Subject:* Re: [vpp-dev] VXLAN Tunnel IF Names > > > > Hi Jon, > > > > I feel I must ask J > > “That <X> has to match a VPP interface by name. But what name?” > > why does it need to match a VPP interface name? shouldn’t <X> = MyVxlan23. > Your control plane maintains mappings between MyVxlan23 and VPP’s > sw_if_index. > > > > /neale > > > > > > *From: *<vpp-dev-boun...@lists.fd.io> on behalf of Jon Loeliger < > j...@netgate.com> > *Date: *Friday, 2 February 2018 at 22:08 > *To: *"John Lo (loj)" <l...@cisco.com> > *Cc: *vpp-dev <vpp-dev@lists.fd.io> > *Subject: *Re: [vpp-dev] VXLAN Tunnel IF Names > > > > On Wed, Jan 31, 2018 at 6:41 PM, John Lo (loj) <l...@cisco.com> wrote: > > Hi Jon, > > > > Hi John, > > > > Thanks for taking the time to get back to me on this! > > > > All VPP tunnel creation uses the mechanism of returning a sw_if_index of > the created tunnel. > > > > I know. I get that. It works. > > > > The name of the tunnel is then followed by a number being the instance or > index to the tunnel struct vector. Thus, the first VXLAN tunnel created is > called vxlan_tunnel0 followed by vxlan_tunnel1, etc. The number is > incrementing unless tunnels are deleted and created again where a newly > created tunnel will reuse the last deleted tunnel, hence its name. If all > previously deleted tunnels are used up, then the tunnel name number will > start incrementing again. > > > > Right. > > > > I am not sure if it is feasible to follow this behavior to “predict” > tunnel name. > > > > It is not. > > > > The problem is not just "predict it", but the user has to be > > able to know the associated SW IF name at the time that > > the (vxlan tunnel) create API call happens. > > > > The reason for that is because the very next thing the > > API call user is going to want to do is configure that interface. > > Short of interrogating the system, there is no way to know > > the IF name. (I understand that the name can be obtained > > from the sw_if_index. That's not what I mean.) > > > > Consider this series of PEUDO API calls that are being > > issued by some client front-end. Think of this as a batch > > of CLI commands: > > > > vxlan MyVxlan23 > > source 1.2.3.4 > > destination 10.11.12.13 > > vni 19 > > exit > > > > interface <X> > > do stuff to interface like apply an ACL or whatever > > exit > > > > There is no way to batch-run those as there is a step > > needed to determine what <X> is. It could be "vxlan_tunnel..." > > anything. > > > > That <X> has to match a VPP interface by name. But what name? > > The entire transactional history of VXLANs must be known in > > order to guess the next name. > > > > BTW, GRE tunnels are created and named the same way. You added TEB > (transparent ethernet bridging) support to GRE. Have you not been using it > and bothered by how to predict name of created GRE tunnels? > > > > I've not touched GRE yet. However, it is next on my list to fix! > > My current plan is to submit essentially the same patch there too. > > > > It is not a good idea to tie tunnel name to VNI as it is not a unique ID > to identify VXLAN tunnels. It is quite common for existence of multiple > VXLAN tunnels with the same VNI with different remote end point IP > addresses. A bridge domain (BD) may have multiple VXLAN tunnels with the > same VNI to several remote servers where the same overlay network exist. It > is quite common to use the ID for BD or VLAN as the VNI for all its VXLAN > tunnels to make it easier to track their usage. > > > > Excellent! Thank you for this insight! That makes total sense now! > > > > I suppose it is feasible to provide another set of VXLAN tunnel > create/delete API to allow caller to specify instance or number of the > tunnel, similar to what you did for loopback interface. > > > > This is the route I was headed: Just like loopback interface naming! > > > > In this case, the above example would be, perhaps, something like this: > > > > vxlan MyVxlan23 > > instance 101 > > source 1.2.3.4 > > destination 10.11.12.13 > > vni 19 > > exit > > > > interface vxlan_tunnel101 > > do stuff to interface like apply an ACL or whatever > > exit > > > > One complication for the new API is that, upon VXLAN tunnel deletion, > the interface created for the tunnel is not really deleted by the current > code but put into a reuse pool. > > > > I solved that by making a trivial vxlan_name_renumber() function, > > and then calling vnet_interface_name_remumber(sw_if_index, instance) > > to update the previously captured "vxlan_tunnel<X>" name and rename > > it using the new instance number. > > > > When more tunnels are created, any interface from reuse pool with its > existing interface name will be used for the new tunnel, before new > interfaces are created. If a interface is reused upon tunnel creation, its > interface name may not match the specified tunnel instance/number of the > new tunnel creation API. One way to overcome this may be to not keep > interface in reused pool on tunnel deletion. Thus, tunnel creation would > always create new interface. For backward compatibility, I suppose we can > keep the tunnel create/delete API as is so interfaces of deleted tunnels > are kept for reuse. The new API will then always create/delete interface on > tunnel create/delete. This would put a restriction that user should not > mix the usage of new or old APIs. > > > > To me, that sounds like a whole bunch of really unnecessary code > replication > > and fragile separation of API results that will invariably get mixed up and > > cause mysterious failures. > > > > Instead, I maintain the original instance allocation scheme when there is > > no requested Instance Id made by the CLI or API user. > > > > I have submitted a patch to Gerrit. When this passes "verify", I'll add > you to be > > a Reviewer! > > > > HTH, > > jdl > > > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
