search

openconfig / gribi

A gRPC Interface to a Network Element RIB.
Apache License 2.0
57 stars 14 forks source link

Add an initial proposal for the Flush RPC. #16

Closed robshakir closed 3 years ago

robshakir commented 3 years ago 
 * (M) v1/proto/service/gribi.proto
  - Add a Flush RPC proposal.

Proposal for the Flush RPC. The operation supports modes whereby the client expects that it is the master, and where it does not know the current election ID. Flushes are provided per network instance, or for all network instances.

robshakir commented 3 years ago

Thanks for the review @nandanarista.

Perhaps we should align on philosophy of what this RPC is intended to do first here -- @nflath or @fetterly -- please chime in if you have comments here.

I was viewing Flush as a mechanism whereby we have the simplest possible "remove all the currently installed routes that might be stale" through gRIBI. It seems to me that we might want to keep it as simple as possible to achieve that -- after all, more "surgical" removal can be done through just using Modify. If we adopt this approach, then the answer to (1) and (2) would be essentially - "let's not add these, if you need a particular AFT flushed then go and do this through Modify, if you need FIB ACK, then go and do that through Modify too" (do a Get then do a subsequent DELETE for anything that your read back.

The reason to introduce more complexity would be if we think the cost of that diff-and-delete is too high and it is going to be run frequently. IMHO, the only case where you really want to delete everything (even from a particular AFT) is going to be in the case whereby the device is now running in some headless mode due to controller failure. In that scenario, you probably want to have some tooling (that might not be the existing master) to go and just throw away those routes. Since that tooling is quite emergency-centric then you likely want it to be as simple as possible (and we'd think of Flush as something like quitquitquit but not quitting the daemon at the other end). The diff-and-delete approach seems like it would likely be reasonable performance if you're a "full controller", and would exercise code paths that you already have (for reconciliation) - rather than this "special case this delete because it's everything" codepath that we're introducing here.

From a protocol design perspective -- I also prefer not having (2) be handled due to the fact that we don't actually have much context in this RPC - i.e., we don't allow master election negotiation, or FIB ACK to be specified right now. If we were to go to that complexity - should this RPC really be part of Modify?

nandanarista commented 3 years ago

Perhaps we should align on philosophy of what this RPC is intended to do first here -- @nflath or @fetterly -- please chime in if you have comments here.

I was viewing Flush as a mechanism whereby we have the simplest possible "remove all the currently installed routes that might be stale" through gRIBI.

ah I see. If Flush is an emergency brake, then keeping it simple makes sense to me and thus the proposal LGTM.