Jon, Nitin, and Joel: I too agree this draft is not ready for WG adoption.
To move this forward, I would suggest that the draft get broken into two pieces: 1) What is a RIB and how i2rs will deal with it, and 2) RIB information model based on the first part. The difficulty with the merging of the two is that the work is that the WG needs to confirm #1 in order to get clarity with #2. Does this help? Sue -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jon Mitchell Sent: Friday, July 26, 2013 2:11 PM To: Sri Cc: [email protected]; Nitin Bahadur; Joel M. Halpern; Alia Atlas Subject: Re: [i2rs] Call for WG Adoption: draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) I also oppose WG adoption for some of the same reasons that Joel stated earlier. That said, there is some useful content in this document but I had some additional questions or concerns that could just be mis-reading of intent: Thanks, -Jon Section 2.1: paragraph 2 - "if the intersection MUST be the null set, then an interface MUST NOT be present in", current text using "should" seems inconsistent. fields - 1. If INSTANCE_NAME is required and the distinguisher by which you keep these tables seperate, why is INSTANCE_DISTINGUISHER also a required field? I could understand if you said INSTANCE_DISTINGUISHER actually was exactly the BGP RD instead of could be mapped "well" to it. However even then it's not clear this is required outside of a L3VPN context. On the other hand if INSTANCE_NAME is NOT required and is really meant to be an optional user friendly name, then perhaps you mean INSTANCE_DISTINGUISHER MUST be unique rather than SHOULD be. 2. A paragraph break seperating mandatory and optional fields would be really helpful, I thought this was one bullet list on first pass. 3. ROUTER_ID seems protocol specific (although many implementations allow you to set one globally to apply to multiple protocols). Does it make sense to expose this to the data model if protocol manipulation and configuration are out of scope? Also the mention of virtual routers here seems odd in that one could also imagine virtual routers would have seperate i2rs interfaces. ISO_SYSTEM_ID seems even more circumspect, if that, why not BGP ASN and all kinds of other protocol details? 4. as_data doesn't make any sense to me here, can you elaborate? If the goal is to apply some sort of generic tag to routes in this routing instance maybe a local implementation tag/color/blah is what you meant here? Unless i2rs is focused on BGP protocol manipulation it doesn't seem that RIB manager is likely to use AS length as a determining factor for route selection (later in the doc it appears route preference and metric are the deciding factor which seems more consistent with my understanding of a RIB). Section 2.3: 1. LOCAL_ONLY - I wonder if the word RIB in this description is used in the common meaning rather than the document's definition? 2. as-path - This makes me wonder if this draft is optimized around specific vendor implementations that export BGP attributes to the RIB (common definition) rather than keeping them in the bRIB. Even if this is the case, does this imply we should include other BGP attributes as well, why limit it to as-path? Section 2.4.1: A large portion of this section seems to suggest things that are FIB, not RIB manipulation, for instance recursive next hops and the mention of multiple headers. Multiple headers may have to be installed in the FIB as a router consults a RIB and finds a nexthop that also leads to the RIB (and not a local interface of some kind) but this wording seems to suggest it can be programmed directly in one entry rather than by consulting the RIB again when it's non-local. This seems to be out of scope for i2rs? Section 2.4.2: I'm a bit unclear if this is in scope for RIB or FIB either, but assuming it is in scope, should LOAD_BALANCE_WEIGHT mention that PROTECTION_PREFERENCE must be equal? In other words, these two items don't appear to be mutually exclusive to me, however it doesn't explicitely state if they are in this model or if they aren't, how to deal a set of nexthops with both attributes. Section 2.4.3: Is writing destination MAC in scope for this WG? Or is this mean to be a specified nexthop IP like you may have for a static route in traditioanl CLI config? If it's an IPv4 entry and only a MAC is specified what is written in the destination IP address? Section 2.4.4.1: These seem MPLS specific and typically is a signalling function? On 25/07/13 16:57 -0700, Sri wrote: > > 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 R > D"_blank">https://www.ietf.org/mailman/<u></u>lis= > tinfo/i2rs</a>><br> > <br> > <br> > </blockquote> > _________________________ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
