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

[Jeffrey Haas <jhaas at pfrc.org>]

On Wed, Jul 16, 2008 at 07:10:36PM -0400, David B Harrington wrote:
> I never take personal offense when a response seems "snippy" after I
> have told an author "maybe your design just sucks" ;-)

Constructive criticism is good, even when it hurts.  It's better than a
few unnecessary trips on the I-D-go-round.

> We're here to say that the MIB models the data in a clear and
> operationally useful ***and standardized*** fashion.

In the case of the Path Attributes tables and the indexing, I don't have
great concerns about standardization.  The language clearly needs to be
expanded so that it's clear what it's for and the issues you can run
into for both usage and implementation.

> My concern is that you may be lax in your duties if you do not define
> an interoperable, standardized representation for this situation.

I'd like to think I have enough IDR cred at this point for people to
know that I'm a big fan of clear, interoperable standards. :-)

> I spent an hour looking over these two tables. Without a knowledge of
> BGP, that study was useless.
> I do not have time at this point to do the research necessary to
> understand the BGP relationships and the modeling relationships.

Fair enough.  The general issue is that the data represents a
many-to-one relationship of prefixes to path attributes; more than one
prefix can point to the same path attribute row.  From an SNMP modeling
perspective, it's irrelevant whether a set of path attributes are
present once or multiple times within the path attribute table.  This
means it is possible to model the prefix row to path attribute row
relationship as one to one if that is the implementor's inclination.

It is even possible for a path attribute row to exist without being
referred to by a prefix.

Documenting this is clearly the challenge.

> I did spot one thing I would recommend changing. You have objects that
> "will be absent" under certain conditions, such as the preference
> objects. I think it better to implement the object with special values
> for "no preference indicated"; then an NMS knows whether there was no
> preference indicated, or the implementer simply chose not to implement
> the object. In addition, having "holes" in tables makes MIB Walk
> presentation more complex and easier for operators to misconstrue.

The problem is the protocol permits the full range of values for an
Integer32 to be used.  I will revert to a previous strategy of using a
related TruthValue object to document whether the object contains a
useful value.

> If you have considered these concerns and reached a suitable
> engineering tradeoff, great.

It's my belief that I've achieved rough consensus and Joan (and
previously Sharon) has been great about ironing out issues that would be
of concern within the OPS WG.  Once we're over the remaining bumps,
we'll hopefully be to running code.

> The MIB Doctors have talked about, but never produced, a "MIB Design
> Guidelines" document.

I believe you'd find a lot of support for this effort.

Thanks for your input.

-- Jeff
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr