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?
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?
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"?
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?
Thanks,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
