Hi Jon,
Some answers inline.
Thanks,
neale
-----Original Message-----
From: Jon Loeliger <j...@netgate.com>
Date: Thursday, 21 September 2017 at 16:42
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures
On Tue, Aug 29, 2017 at 9:37 AM, Neale Ranns (nranns) <nra...@cisco.com>
wrote:
>
> Hi Jon,
>
> The new API does not function correctly in master at this time. If you
want to ride on the bleeding edge with the new API, the code I intend to commit
is (complete AFAICT) here:
> https://gerrit.fd.io/r/#/c/7819/
>
> it’s not committed yet because I need to do an n-step dance with CSIT
changes to make the verify jobs pass. This will take a few weeks (because
vacations).
>
> Regards,
> neale
Hi Neale,
Hope your vacation went well!
Glad to see you are back at The Salt Mines, though! Any chance for
a brief update on the progress of this whole Route Table re-work effort?
It’s committed and ready to go.
I’m still working through some updates to CSIT to behave w.r.t. adding tables
first before adding routes or binding interfaces. After that I will add the
checks in VPP to enforce it.
Specifically, I have code poised to use the "add_del_table" API call, and
I *think* that I can do that now. But can I remove the soon-to-be-obsolete
create_table_if_needed flag yet?
You can remove that flag. I mistakenly left the flag in the API, but it has no
effect in VPP. Too late to remove it now we are in the API Freeze, I’ll do it
in the next iteration.
Also, I read a comment about the need to ensure that an interface does
not have addresses on it when the IF is bound to a route table. I get
the "why" behind that, but I'd like a small clarification: Is that per-AF?
Or is that "across the board"?
Per-AF. One could bind an interface to a new IPv4 tale whilst it had IPv6
address.
The reason I ask is the potentially somewhat disconnected special case
API call intf_add_del_address which contains a flag "del_all". And it
does as advertised -- it removes all IPv4 and IPv6 addresses in one shot.
But if the route table addition is per-AF, it might make sense to have
the two calls coordinated a bit better. That is:
- Modify intf_add_del_address to del_all per AF, or all AFs
- Modify intf_sw_interface_set_table to accept and bind one or both AFs
It is all in an effort to avoid repeatedly removing and re-adding the
addresses that might be present in either or both AFs on an interface.
See where I am headed there? Am I way off base?
I agree that is inconsistent. I would propose the del_all case becomes AF
specific. But I would also suggest this in an API change, albeit semantic not
syntactic, and so we should wait for the next release.
Regards,
neale
Thanks,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
