Hi Russ ... For me the base set is completely not sufficient for any of the application I would use I2RS for.
As example: it is missing match on VLAN, set MPLS VPN label, set MPLS transport label. r. > On Thu, Mar 14, 2013 at 4:14 PM, Russ White <[email protected]> wrote: > > 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
