Hi Chris,
There are two overlapping sets of paths associated with each prefix in the FIB;
the desired set as programmed by the control plane and the set that can be used
(based on path availability, based on e.g. link or BFD state). I assume you
fetch the former by parsing through the path-list – is that what you were
looking for? The latter is subject to change without notice to the client.
/neale
From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org>
Date: Tuesday 25 February 2020 at 22:09
To: Andrew 👽 Yourtchenko <ayour...@gmail.com>
Cc: Christian Hopps <cho...@chopps.org>, "Dave Barach (dbarach)"
<dbar...@cisco.com>, vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release
branches?
> On Feb 25, 2020, at 3:44 PM, Andrew 👽 Yourtchenko <ayour...@gmail.com> wrote:
>
> That’s the APIs in the master prior to the API freeze, in my book.
>
> The today’s situation is:
>
> - want bleeding edge features ? Use master.
> - want sort-of-boring-stability ? Use release branch
>
> Now, I am really interested why the folks who do want to experiment with the
> APIs, do not pick the master ? (Say, specifically for your case).
FWIW, I'm absolutely fine following whatever guidelines, it's open source and
I'm sure people can make things work with whatever is best for both project[s].
In my case we're not really talking about an API that is "bleeding edge", but
rather "waited around for someone to need/implement it". Doing a route/fib
entry lookup isn't very bleeding edge given what VPP does. :)
My use case is interfacing an external IKE daemon (strongswan), I want to do a
route lookup (rather than download the entire FIB content and search for a
match myself hoping to use the same criteria that VPP would, which is the only
current API solution available).
I'd like to contribute my strongswan changes back to strongswan project, but
having them only be usable for some future yet-to-be-released version of VPP
might not be useful to people shipping products based mostly on
"sort-of-boring-but-stable" features.
Also worth noting, I implemented a basic route lookup (prefix based, from a
given table, either exact or longest prefix match), I didn't add any other
filtering or fanciness. I figured fanciness could be added later (if needed),
and went for simple, and if more complexity was needed, well there's always
what came before it. :)
define ip_route_lookup
{
u32 client_index;
u32 context;
u32 table_id;
u8 exact;
vl_api_prefix_t prefix;
};
define ip_route_lookup_reply
{
u32 context;
i32 retval;
vl_api_ip_route_t route;
};
Thanks,
Chris.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15611): https://lists.fd.io/g/vpp-dev/message/15611
Mute This Topic: https://lists.fd.io/mt/71535081/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
