Re: [Idr] BGP MIB representation of RIBs (Re: [MIB-DOCTORS] BGP MIBv2 discontinuity objects)

Wed, Jul 16, 2008 at 09:17:01PM -0400, Jeffrey Haas:
> On Wed, Jul 16, 2008 at 05:55:35PM -0700, john heasley wrote:
> > I've not followed the BGP MIBv2 thread closely, but I believe the heat is
> > related to BGP RIB representation and this is something that I've been
> > wanting to ask about.
> > 
> > Specifically, we see no value that this kind of data, along with route
> > attributes, be in a MIB.  Rather it seems to slow standardization and
> > implementation.  For example, we've been wanting peer in-RIB sums for
> > some time.
> > 
> > Can't the RIB be eliminated?  If not, can it be split into a separate and
> > optional MIB?
> 
> More people have commented about the counters being useful than they've
> commented about the NLRI tables being useful.
> 
> I will readily admit that the RIB representation is where all of the
> churn of the last few years has been.  When I've previously been asked
> about removing the RIB data, some people have stated they'd prefer to
> see it present.  These people seemed to be interested in monitoring the
> stability of a small set of prefixes and the RIB was helpful for that.
> 
> Additionally, the earlier version of the MIB (published as RFC 4273) has
> the AdjRibsIn and Loc-Rib indirectly present as bgp4PathAttrTable.
> Providing this in the address family independent fashion was partially
> about keeping existing functionality.
> 
> Could the RIB be eliminated?  Possibly.  I think that would upset some
> people
> and make others happy.
> 
> Can it be made optional?  Certainly.  This is just a matter of updating
> the conformance statements.  This would require working group consensus.
> 
> Could it be split into a separate MIB?  Also possible.
> 
> My recommendation would be to keep the RIB.  I have no strong opinion
> about keeping it in the same document or making it optional.

I'd imagine that Cisco, for example, would get pressure to include the RIB.
So, merely making it optional is likely not sufficient.  Implementation of
the "base" MIB would still be constrained by the RIB representation.  It'd
have to be eliminated or separated (hopefully in such a way that it is not
bound to the base MIB).
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr