I think we agree that RIB elements for read and write must be clearly defined. And should be extensible.
But is RIB abstraction sufficient for I2RS ? For example as we know each VRF contains it's own RIB (different table id). So protocol must be able to also encode which RIB we are talking to. Further who will instantiate the VRF in this case ? Will I2RS be able to create a RIB instance on the fly ? How will we attach such RIB instance to interfaces ? There is dozens of details here without which I am afraid we can't go productively forward. Best, R. On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte <[email protected]> wrote: > On 03/14/2013 07:34 AM, Robert Raszuk wrote: >> >> Hi Scott, >> >>> Why do we need to go beyond defining an interface to the RIB to make your >>> use case work? >> >> >> I am talking precise about that definition of RIB interface. Not how >> the RIB works in given vendor of network element. That is >> implementation detail. >> >> Basically a list of values one can write or read to/from RIB. Have you >> seen any document with such list yet ? > > > So we agree that what a RIB looks like is out of scope, and we need to > insure extensibility beyond proposed use cases for the actual RIB interface? > If so I think the group is well on track to get there, as we grind through > use cases and existing data models. > > -Scott > >> >> Cheers, >> R. >> > > > -- > People who are essentially without the power to implement their ideas in the > real world must leverage the power of their reputations. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
