I oppose adoption of this I-D.  The use of terminology seems
incompatible with the use of the same terminology elsewhere and,
arguably, contradicts the charter.

For example, this I-D says

" A RIB
   contains one or more routing instances.
   A routing instance, in the context of the RIB
   information model, is a collection of routing tables, interfaces, and
   routing parameters.
  The routing tables specify how incoming
   traffic is to be forwarded."

whereas the charter clearly differentiates the RIB, which is the subject
of this WG, from the FIB, which is not.  The reference here to routing
tables sounds rather like a FIB.  (Of course, the charter fails to
define RIB and FIB which is likely to be a recurrent problem for all the
work of this WG unless and until rough consensus is achieved thereon.)

And the I-D places heavy emphasis on interfaces which again seems to
have
nothing to do with the charter.

This topic has surfaced several times on several WG lists, none of which
has produced an agreed document, but the best one would appear to me to
agree that there are processes, not just data, and that these processes
are tied to routing protocols, and that the data thereof needs to be
split into three
 - a RIB (in the sense that I most often see it used) containing the
data used by a protocol process instance
- a central database of consolidated routes, sometime referred to as
RIB2
- what gets used in forwarding, usually by the silicon.

Routing table and FIB I see used arbitrarily and so confusingly used for
the second and third data structures.  (I have no idea what the charter
means in this regard).

Tom Petch

----- Original Message -----
From: "Joel M. Halpern" <[email protected]>
To: "Nitin Bahadur" <[email protected]>
Cc: <[email protected]>; "Alia Atlas" <[email protected]>
Sent: Thursday, July 25, 2013 3:43 AM
Subject: Re: [i2rs] Call for WG Adoption:
draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12)


> 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

Reply via email to