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
