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

Jeffrey Haas <jhaas@pfrc.org> Thu, 17 July 2008 00:00 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 827D03A682E; Wed, 16 Jul 2008 17:00:31 -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 11B053A6828; Wed, 16 Jul 2008 17:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.132
X-Spam-Level:
X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 7yNarxh7cRWe; Wed, 16 Jul 2008 17:00:29 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 298DA3A6912; Wed, 16 Jul 2008 17:00:29 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 2AC32244181; Thu, 17 Jul 2008 00:00:59 +0000 (UTC)
Date: Wed, 16 Jul 2008 20:00:59 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: David B Harrington <dbharrington@comcast.net>
Message-ID: <20080717000059.GA19626@slice>
References: <001e01c8e779$fd90e650$6601a8c0@JoanPC> <00af01c8e781$66710720$0600a8c0@china.huawei.com> <20080716211337.GA17720@slice> <00cb01c8e799$2903da30$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <00cb01c8e799$2903da30$0600a8c0@china.huawei.com>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: "'MIB Doctors \(E-mail\)'" <mib-doctors@ietf.org>, 'David Ward' <dward@cisco.com>, idr@ietf.org
Subject: Re: [Idr] [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

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@ietf.org
https://www.ietf.org/mailman/listinfo/idr