On 03/14/2013 07:46 AM, Robert Raszuk wrote:
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.
I guess I'm confused now on what you consider propietary implementation
detail of a RIB, but I'll assume you are still talking strictly about a
RIB abstraction and increasing its scope to multiple RIBs communicating
with a single I2RS agent.
Not sure about dozens of details, but your four good questions above all
seem to revolve around a single issue, handling of multiple RIBs, which
I think is important to have as a use case.
-Scott
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.
--
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
