Re: [Idr] [MIB-DOCTORS] BGP MIBv2 discontinuity objects

Jeffrey Haas <> Wed, 16 July 2008 21:13 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 53BF43A6969; Wed, 16 Jul 2008 14:13:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C9443A69B5; Wed, 16 Jul 2008 14:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fcj6Nm38Xs97; Wed, 16 Jul 2008 14:13:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6B7B83A697C; Wed, 16 Jul 2008 14:13:07 -0700 (PDT)
Received: by (Postfix, from userid 1001) id A5234244181; Wed, 16 Jul 2008 21:13:37 +0000 (UTC)
Date: Wed, 16 Jul 2008 17:13:37 -0400
From: Jeffrey Haas <>
To: David B Harrington <>
Message-ID: <20080716211337.GA17720@slice>
References: <001e01c8e779$fd90e650$6601a8c0@JoanPC> <00af01c8e781$66710720$>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <00af01c8e781$66710720$>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: "'MIB Doctors (E-mail)'" <>, 'David Ward' <>,
Subject: Re: [Idr] [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


1. If you interpret this response as "snippy", please don't take
personal offense. 
2.  This is  exactly the sort of feedback that this MIB has
been requiring.

On Wed, Jul 16, 2008 at 04:20:31PM -0400, David B Harrington wrote:
> I have some concerns if different implementations do not represent
> things in a consistent manner, and reflect the changing conditions in
> a consistent manner. I am concerned that the design of these tables
> and a lack of standardized behavior at discontinuity might lead to
> misinformation being presented to an operator. "Implementations vary
> widely" raises a red flag for me about any supposed **standard**.

Just like most IETF protocols, BGP-4's specifications are largely about
on-the-wire behavior and abstract data modeling.  The MIB is there to
give people a canonical way to get at operational state and the abstract

The IETF isn't here to tell you how to write your code.

If your implementation doesn't have persistent storage, you're not going
to have a place to store the last-used INDEX for a table in the case of
a discontinuity.  That's an implementation issue.

If your implementation chooses to load your path attribute set from a
local cache before you even bring up a single BGP peering session and
maintain consistent indices across reboots, that's an implementation

We're not here to tell people that the MIB is meant to constrain how
they write their code.  We're here to say that the MIB models the data
in a clear and operationally useful fashion.  I'd be lax in my duties if
I didn't point out where the model and reality might have problems

> I also get concerned when a MIB designer talks about the limitations
> of SMI at using complex modeling stsructures. MIB modules are
> effectively relational database models, and in my experience
> relational database models typically do not use deeply nested
> structures.

But BGP does.  Honestly, most TLV based protocols do.  Perhaps the only
novel thing about BGP (and probably not even novel) is that path
attributes are shared amongst prefixes.  And thus have a one-to-many

>  And attempts to force SMI to represent deeply nested
> structures usually result in poor MIB designs. "If only SMI supported
> ASN.1 deeply nested structures" raises a red flag for me.

Excellent.  You obviously have an opinion.  If you don't have time to
study the whole MIB, at least study the bgpAfPathAttrTable and its
relationsip to the bgpNlriTable.

Over the past 5 years of working on this MIB, I've received
contradictory advice from several "mib experts".

1. Flatten the tables.  This removes the "deeply nested" concern.  This
makes a MIB walk full of redundant information.
2. Factor the tables.  This removes redundant information at the risk of
introducing relational integrity and discontinuity issues.

Given that BGP implementations have data structures that are factored
and that size of MIB walks was a concern I was repeatedly presented with, I
chose 2.  This was after a lot of hallway discussion over several IETFs.

If this is a problem, *speak now*.  Given the amount of churn over both
views over the last several years, if we can't even get consensus among
the MIB doctors we'd be best off driving a stake into this spec and
handing the resultant dust to Sue and Yakov for careful burial as a
warning to the future to not even bother trying.

-- Jeff
Idr mailing list