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

john heasley <heas@shrubbery.net> Thu, 17 July 2008 01:43 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FAE3A68DA; Wed, 16 Jul 2008 18:43:05 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F9C3A696D; Wed, 16 Jul 2008 18:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSfFw3CLI4Te; Wed, 16 Jul 2008 18:43:03 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2A53A68DA; Wed, 16 Jul 2008 18:43:03 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id CF5CD108696; Thu, 17 Jul 2008 01:43:19 +0000 (UTC)
Date: Wed, 16 Jul 2008 18:43:19 -0700
From: john heasley <heas@shrubbery.net>
To: Jeffrey Haas <jhaas@pfrc.org>
Message-ID: <20080717014319.GF14628@shrubbery.net>
References: <20080717005535.GA4195@shrubbery.net> <20080717011701.GC20179@slice>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20080717011701.GC20179@slice>
User-Agent: Mutt/1.4.2.3i
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
Cc: john heasley <heas@shrubbery.net>, "MIB Doctors \(E-mail\)" <mib-doctors@ietf.org>, idr@ietf.org
Subject: Re: [Idr] BGP MIB representation of RIBs (Re: [MIB-DOCTORS] BGP MIBv2 discontinuity objects)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

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