.. aand then one of the calls in the batch fails. Why not use a shim layer that on the one hand fits what Neale was saying and on the other it accepts batches and handles failures. Say .. netconf? :-)
Florin > On Feb 7, 2018, at 2:10 PM, Ed Warnicke <hagb...@gmail.com> wrote: > > 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 > <mailto: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 <mailto:l...@cisco.com>> > Date: Wednesday, 7 February 2018 at 15:34 > To: "Neale Ranns (nranns)" <nra...@cisco.com <mailto:nra...@cisco.com>>, Jon > Loeliger <j...@netgate.com <mailto:j...@netgate.com>> > Cc: vpp-dev <vpp-dev@lists.fd.io <mailto: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 <mailto:j...@netgate.com>>; John Lo (loj) > <l...@cisco.com <mailto:l...@cisco.com>> > Cc: vpp-dev <vpp-dev@lists.fd.io <mailto: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 <mailto:vpp-dev-boun...@lists.fd.io>> on > behalf of Jon Loeliger <j...@netgate.com <mailto:j...@netgate.com>> > Date: Friday, 2 February 2018 at 22:08 > To: "John Lo (loj)" <l...@cisco.com <mailto:l...@cisco.com>> > Cc: vpp-dev <vpp-dev@lists.fd.io <mailto: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 > <mailto: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 <mailto:vpp-dev@lists.fd.io> > https://lists.fd.io/mailman/listinfo/vpp-dev > <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
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
