I wouldn't frame the question in terms of the packet header but the routing table... I don't know that the answer comes out different, but... :-)
That said, I think a good base set would be: - Dest IP Address - Next hop IP address - Outbound interface - Admin distance - Some form of tags - Table ID We've talked about the ad,in distance being more like a community string than an integer (having multiple parts so you can have several types of metrics here), but I don't know how useful that would be. I'm all for thinking past the immediate need and leaving doors open for unthought of things, though. There's also the back channel out of the rib to consider -- specifically, things like, "your route was just overwritten by another process," "a route was just redistributed to you," "the next hop for this route just went away," "this connected route just failed," and other related stuff. But I think we might need to get the use cases to give us what information they need, and work build a good list from that. Then we can ask the question, "is there a model that fits already?" :-) Russ <>< [email protected] On Mar 14, 2013, at 11:02 AM, Robert Raszuk <[email protected]> wrote: > My main question is what L2-L4 fields for the packet lookup I can > program to the 'RIB" by I2RS. Very precise and simple. > > The use case for multiple RIBs is just being shown in the room. L3VPN > PE auto-provisioning ;) > > Best, > R,. > > On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte <[email protected]> wrote: >> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
