Hi Chris, There is a design philosophy against sending notifications to agents about information that comes from agents. This is in contrast to notifications to agents about events that occur in the data-plane, like DHCP lease, new ARP/ND, learned L2 addresses, etc.
/neale From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> Date: Thursday 27 February 2020 at 16:32 To: "Neale Ranns (nranns)" <nra...@cisco.com> Cc: Christian Hopps <cho...@chopps.org>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] Can I submit some API changes for 19.08, et al. release branches? > On Feb 27, 2020, at 9:41 AM, Neale Ranns via Lists.Fd.Io > <nranns=cisco....@lists.fd.io> wrote: > > > > From: <vpp-dev@lists.fd.io> on behalf of Christian Hopps <cho...@chopps.org> > Date: Thursday 27 February 2020 at 15:16 > To: "Neale Ranns (nranns)" <nra...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>, Andrew 👽 Yourtchenko > <ayour...@gmail.com>, "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? > > [snip] > > > > 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. :) > > > > True 😊 but the general usage model for VPP is that there is one > > agent/client giving it all the state it needs to function. So why would > > that agent need lookup functions, it has all the data already. The dump > > APIs serve to repopulate the agent with all state should it crash. > > I suppose that's why I needed to add this API then. :) > > We're using VPP more like a replacement for the kernel networking stack, with > multiple networking clients interfacing to it, rather than just one > monolithic application. > > Ok. Just don’t fall into the pit that is ‘I want VPP to tell client X when > client Y does something’ – VPP is not a message bus 😊 I'd like to be careful here. If VPP is serving as a replacement for the networking stack with multiple clients interfacing to it, then it does serve as the single-source-of-truth on things like interface state, routes, etc. So, I do want to hear inside my IKE daemon from VPP that a route, intefrace, etc, may have changed, I don't want to have to interface the IKE daemon to N possible pieces of software that might modify routes, interfaces, etc. I'm only being careful here b/c if one looks at e.g., netlink functionality and then at the VPP api there are some gaps (e.g., interface address add/del and route add delete events are missing I believe). I'm assuming that these gaps exist b/c, as you say, people have generally not needed them, but not b/c there a design philosophy against them. Thanks, Chris. > > /neale > > > Thanks, > Chris. > > > > > /neale >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15594): https://lists.fd.io/g/vpp-dev/message/15594 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] -=-=-=-=-=-=-=-=-=-=-=-
