I vote for #1. Acee On 7/28/13 11:15 AM, "Nitin Bahadur" <[email protected]> wrote:
> >My original intent here was to provide "a name" to something that >aggregated all the routing-instances. >Obviously as many have pointed out, giving it the name of "rib" was a bad >choice. > >So we have 2 choices: >- Remove the top-level object in the grammar (rib) completelyŠand instead >start off with routing-instance. >- Rename "rib" (in the grammar) to something better :) > > >Thanks >Nitin Bahadur > > > > > >On 7/25/13 4:25 AM, "Acee Lindem" <[email protected]> wrote: > >>I agree with Joel. >> >>On 7/24/13 7:43 PM, "Joel M. Halpern" <[email protected]> wrote: >> >>>This seems a different use of the term RIB than most of the work I am >>>familiar with. Even without dealing with things like protocol specific >>>RIBs, and BGP's RIB-in and RIB-out, when we deal with VRFs we normally >>>discuss them as using separate RIBs. This is why the terminology seems >>>upside-down to me. >>> >>>Yours, >>>Joel >>> >>>On 7/24/13 10:21 PM, Nitin Bahadur wrote: >>>> Hi Joel, >>>> >>>> Maybe this can help clarify what we meant by the RIB. >>>> >>>> The RIB is the totality of all routing-information in a router. The >>>> routing information itself can be sub-divided into multiple objects >>>>called >>>> routing-instances. >>>> >>>> Routing-instances allow us to partition the physical router into >>>>domains >>>> that can operate independently from one another in terms of routing >>>>and >>>> forwarding. >>>> >>>> >>>> The rest of that section describes what objects are contained in a >>>>RIB, >>>> like routing tables, routes and nexthops. >>>> >>>> >>>> HTH as a starting point. >>>> Nitin Bahadur >>>> >>>> >>>> >>>> >>>> >>>> On 7/24/13 3:19 PM, "Joel M. Halpern" <[email protected]> wrote: >>>> >>>>> Asking for a text proposal is quite reasonable. >>>>> Unfortunately, since my oncern is taht I can not understand what is >>>>> meant by RIB in this definition, it is really ahrd to propose an >>>>> alternative set of definitions that do what the authors wanted. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 7/24/13 6:16 PM, Alia Atlas wrote: >>>>>> Joel, >>>>>> >>>>>> I understand your concern. Do you have text to suggest to Nitin and >>>>>> co-authors? >>>>>> I think part of this is figuring out how to pull out the RIB bits >>>>>> (routing tables) and what traffic they apply to - as well as the >>>>>>policy >>>>>> of how to create associated containers. Nitin's called that a >>>>>>routing >>>>>> instance... >>>>>> >>>>>> What set of objects would you create? >>>>>> >>>>>> I personally would like to see the info-model described in something >>>>>> other than rBNF - but I view that as a piece that can happen in a >>>>>>future >>>>>> version. >>>>>> >>>>>> Alia >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 24, 2013 at 6:08 PM, Joel M. Halpern >>>>>><[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Looking again at this document, I have to reluctantly say taht >>>>>>I >>>>>>do >>>>>> not support adoption of this document at this time. >>>>>> >>>>>> The base definition of RIB is still very unclear. A RIB is >>>>>>some >>>>>> collection of routing instances? First, this seems upside-down >>>>>>to >>>>>> me. A routing instance would seem to contain a RIB, not the >>>>>>other >>>>>> way around. Secondly, what defines, describes, or otherwise >>>>>>helps >>>>>> decide what set of routing instances go in the same RIB. >>>>>> >>>>>> If this issue were clarified, I believe the rest of the >>>>>>material >>>>>>is >>>>>> in sufficiently good shape for working group adoption. >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> >>>>>> >>>>>> On 7/24/13 5:55 PM, Alia Atlas wrote: >>>>>> >>>>>> Please review draft-nitinb-i2rs-rib-info-__model-01 and >>>>>>comment >>>>>> on whether >>>>>> it should be adopted by I2RS. Detailed technical >>>>>>conversation >>>>>> is also >>>>>> most welcome. >>>>>> >>>>>> Authors: Are you aware of any IPR that applies >>>>>> to draft-nitinb-i2rs-rib-info-__model-01 Is so, has this >>>>>>IPR >>>>>> been >>>>>> disclosed in compliance with IETF IPR rules (see RFCs 3979, >>>>>> 4879, 3669 >>>>>> and 5378 for more details). >>>>>> >>>>>> This WG call for adoption will complete on August 12. >>>>>> >>>>>> Thanks, >>>>>> Alia >>>>>> >>>>>> >>>>>> _________________________________________________ >>>>>> i2rs mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>>>> <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
