Re: Challenges for the BGP MIBv2

[Jeffrey Haas <jhaas@nexthop.com>]

Randy,

Thanks for the quick response.

On Tue, Sep 28, 2004 at 11:25:36AM -0700, Randy Presuhn wrote:
> I'd be wary of doing so, unless there was very clear language about
> which took precedence if the two forms didn't agree, both for reads and
> for writes.

The objects in question would be read-only for the most part.

The "nicety" that I'm trying to create is that when the MIB walk
is done, one can fetch a human-readable object and not have to
construct it from the data.

As an example, here is a complex BGP AS_PATH:
13361 5650 1239 8764 [8986 31006]

The BGP MIBv2 representation of these elements was as follows in
my last version of the draft:

 bgpM2AsPathTable OBJECT-TYPE
	SYNTAX	   SEQUENCE OF BgpM2AsPathEntry
	MAX-ACCESS not-accessible
	STATUS	   current
	DESCRIPTION
	    "The BGP-4 Path Attribute AS Path Table
	     contains the per network path (NLRI)
	     AS PATH data received from the
	     advertising BGP peer."
	::= { bgpM2Rib 6 }


    bgpM2AsPathTableEntry OBJECT-TYPE
	SYNTAX	   BgpM2AsPathEntry
	MAX-ACCESS not-accessible
	STATUS	   current
	DESCRIPTION
	    "Information about an AS path provided with a path to
	     a network."
	INDEX {
	    bgpM2PathAttrIndex,
	    bgpM2AsPathSegmentIndex,
	    bgpM2AsPathElementIndex
	}
	::= { bgpM2AsPathTable 1 }


    BgpM2AsPathEntry ::= SEQUENCE {
	bgpM2AsPathSegmentIndex
	    Unsigned32,
	bgpM2AsPathElementIndex
	    Unsigned32,
	bgpM2AsPathType
	    INTEGER,
	bgpM2AsPathElementValue
	    InetAutonomousSystemNumber
    }

Thus, the above path would be represented as

bgpM2Rib.6.1.1.3.X.1.1 = 2 (asSequence)
bgpM2Rib.6.1.1.4.X.1.1 = 13361
bgpM2Rib.6.1.1.3.X.1.2 = 2 (asSequence)
bgpM2Rib.6.1.1.4.X.1.2 = 5650
bgpM2Rib.6.1.1.3.X.1.3 = 2 (asSequence)
bgpM2Rib.6.1.1.4.X.1.3 = 1239
bgpM2Rib.6.1.1.3.X.1.4 = 2 (asSequence)
bgpM2Rib.6.1.1.4.X.1.4 = 8764
bgpM2Rib.6.1.1.3.X.2.1 = 1 (asSet)
bgpM2Rib.6.1.1.4.X.2.1 = 8986
bgpM2Rib.6.1.1.3.X.2.2 = 1 (asSet)
bgpM2Rib.6.1.1.4.X.2.2 = 31006

where X is an arbitrary path index

This is clearly a larger number of objects to fetch than the human readable
text.  In the case of truncated strings, this can be used to reconstruct it.

I could easily see where an operator would prefer the easy way of fetching
things.  

I definitely acknowledge your consistancy issue.  Part of the problem will
be that implementors will want the human readable text to be similar
to their implementation and thus the same data could be represented
differently.

> > To ask a related question, when working on a standards track MIB,
> > is the inclusion of an object that is longer than 400 octests
> > an immediate red flag?
> 
> As a reviewer, I'd want to know more about the motivation and
> expected usage, and would be strongly inclined to request a more
> robust alternative.

The intent would be to have the human readable text as an alternative
rather than the only method of retrieving the data.

> > I believe that the primary effect of this is that a walk of
> > the PathAttrTable subtree will *not* show the community table since
> > that is "elsewhere".
> 
> This is not a problem.
> This is the way, for example, all the media-specific stuff works
> with respect to the interfaces table.

It is my perception with how I'd like this to work that seems to be
the issue then. :-)

> According to RFC 2578 (page 38), one of the things that may be done is:
> (7)  A conceptual row may be augmented by adding new columnar objects at
>      the end of the row, and making the corresponding update to the
>      SEQUENCE definition.

This must be done by re-issuing the existing MIB module, correct?
If not, a pointer to an example of doing this would be greatly appreciated.

> For applications (or scripts) doing MIB walks, there's really no difference in
> code size or complexitity between doing
>      get-next(T1.a.i, T1.b.i, T1.c.i, T1.x.i)
> and
>      get-next(T1.a.i, T1.b.i, T1.c.i, T2.x.i)

I'd agree.  However, this presumes that you know that T2 is there.
The same goes for T3->Tn for any number of possible extentions.
Having it all in the same table seems optimal - however it also
seems contrary to practice.

I think this may answer the MIB extension part of my question.

Thanks.

-- 
Jeff Haas 
NextHop Technologies