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

[Jeffrey Haas <[e-mail]>]

David,

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

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

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

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

>  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
[e-mail]
https://www.ietf.org/mailman/listinfo/idr