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

Jeffrey Haas <> Thu, 17 July 2008 01:16 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 89F933A69EC; Wed, 16 Jul 2008 18:16:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 821EE3A69DF; Wed, 16 Jul 2008 18:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l-38vwz-kIQI; Wed, 16 Jul 2008 18:16:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF4953A69EF; Wed, 16 Jul 2008 18:16:30 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 8F15F244181; Thu, 17 Jul 2008 01:17:01 +0000 (UTC)
Date: Wed, 16 Jul 2008 21:17:01 -0400
From: Jeffrey Haas <>
To: john heasley <>
Message-ID: <20080717011701.GC20179@slice>
References: <>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: "MIB Doctors \(E-mail\)" <>,
Subject: Re: [Idr] BGP MIB representation of RIBs (Re: [MIB-DOCTORS] BGP MIBv2 discontinuity objects)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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
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.

-- Jeff
Idr mailing list