Hi Joel, You seem to be pointing to two issues that need a better definition - 1) The RIB whose IM is being described in this doc (as opposed to all other XXX-RIBs in a router) 2) The routing-instance that is defined in this doc as part of the RIB as opposed to a more general understanding of a routing-instance.
First let me try to clarify some statements to see if there is agreement and then we can cobble together some wording around it for the draft - 0. A router can be thought of as an I2RS agent endpoint. This definition is outside the scope of this document, but it may help to understand the RIB IM in relation to I2RS. 1. There is a single RIB in a router. When referred to in the context of a router, this RIB is unqualified. The IM in this draft is describing this RIB. 2. A router has zero or more routing instances. Each routing instance will have its own RIB. This RIB is unqualified in the context of that routing instance, but is qualified by the routing-instance name when in the context of the router (e.g. core.RIB or VPN_X.RIB). We can further qualify by the type i.e. the routing-instance (e.g. routing_instance.core.RIB) if there are separate namespaces for routing-instance names and say protocols, but this is a minor point. 3. The collection of the RIBs of all the routing-instances in the router is the RIB (i.e., the RIB defined in 1.) 4. Other RIBs e.g. the BGP RIB-in of a routing instance has to be qualified further within the routing instance and hence is not part of the RIB (i.e. the RIB defined in 1.). So you will have routing_instance.core.bgp-in.RIB to describe BGPs RIB-in for that instance. All such XXX-RIB IMs are outside the scope of this draft. 5. To summarize, the RIB in 1. in words - This document describes the IM of the RIB of a router. A router has a single RIB. A router consists of multiple routing instances and each routing-instance has a RIB. The router's RIB consists of the collection of RIBs of all the routing-instances of the router. A routing-instance's RIB consists of routes added by zero or more routing/signaling/static protocols of that routing instance. Routes added by one instance can be resolved via routes in other instances and this relationship is reflected in the RIB. The RIB-manager manages all the routes in the RIB and executes the policies to recursively resolve the routes according to the capabilities of the forwarding hardware. It also downloads the routes to the FIB. The RIB-manager also executes policies to re-distribute routes across protocols. Let me know if this helps. On Wed, Jul 24, 2013 at 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> >>>> >>>> <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<https://www.ietf.org/mailman/listinfo/i2rs> >>> >>> >>> >> >> >> >> ______________________________**_________________ > i2rs mailing list > [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
