Hi Benson, I think this is excellent point.
And as said I also think this is extremely important to move forward. In other words I am just afraid that when junisco is talking about RIB they are talking about current global RIB model which obviously is completely not sufficient to realize/provision network wide services by I2RS protocol alone. So I just hope that we define base interface to network element which will allow to address all use cases (even those already documented by the drafts on the table). Best, R. > On Thu, Mar 14, 2013 at 6:53 PM, Benson Schliesser <[email protected]> > wrote: > I think it depends if and/or how we decouple traffic-bearing interfaces from > the RIB... Do we want the information model to represent ingress/egress > labels, VLANs, etc as fields in the RIB, attributes of the RIB (or of > various tables), or attributes of interfaces? Is the information model the > same for ingress vs egress traffic? > > I have opinions, of course. But I'm open-minded. > > Cheers, > -Benson > > > > On 3/14/13 1:46 PM, Alia Atlas wrote: >> >> I do see setting an MPLS label as a characteristic of a next-hop. The >> concern will be describing capabilities reasonably without a rat-hole. >> >> This is doing L3 routing - so VLAN matching seems out; while there may >> be PWE3 or L2VPN type use-cases eventually, I've not seen them yet. >> >> Alia >> >> On Thu, Mar 14, 2013 at 11:17 AM, Robert Raszuk <[email protected]> wrote: >>> >>> 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 >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
