Re: Challenges for the BGP MIBv2

[Jeffrey Haas <jhaas@nexthop.com>]

Apologies for the long delay between messages.  I lost the reply and
then work got busy.  :-)

Juergen Schoenwaelder was heard to say:
> Subject: Re: Challenges for the BGP MIBv2
> 
> So there is a tradeoff here and in most cases, we lean more towards
> multiple objects rather than encoded OCTET STRINGs. This avoids any
> issues with SNMP's inherent limitation on message sizes and it gives
> applications the freedom to request precisely the data they need.
> And applications do not need yet another endocing/decoding function
> to get access to the values.

Would you recommend having both forms - the human readable form
and also the machine readable form?

> I think the only hard constraint is the message size. Variables longer 
> than say 400 octets can create severe problems. So keep things in a
> reasonable size.

In practice, how much in the way of problems have there been
when using larger PDUs?

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?

> > Issue 2.3:
> > New extensions appear very often.  Given that the approach to adding
> > extensions appears to be "re-issue the entire MIB", this seems to
> > imply that IDR will be issuing MIB updates *extremely* frequently.
> 
> Can extensions not go into extension MIB modules? You may want to
> design your tables such that this is possible. And the IETF processs
> will help you to turn "extremely frequent updates" into "regular
> updates" at best. ;-)

An extension MIB is certainly a possibility and was originally
planned in the original BGP MIBv2.  However, the fact that the
information involved frequenly extends the existing tables.

Consider the BGP Path attribute table.  It will look somewhat like the
following:

PathAttrTable.PathAttrIndex = {                                                 
    (Standard RFC1771 path attribute scalars)                                   
    AsPathString -- representation of complex data structure in human readable  
                 -- format (implementation dependant)                           
    AsPathIndex                                                                 
    }      

We now want to add in, via extension MIB, BGP communities.

As best I understand the process, we must issue a complete new mib
document with the MODULE-IDENTITY anchored somewhere, potentially
at a mount point for extensions in the base MIB.

We would then declare something like:

CommunityEntry AUGMENTS PathAttrEntry = {
    CommunityString
    CommunityIndex
    }

Presume the MIB structure looked something like this:

mib-2.bgp-mib2.(...).PathAttrTable

Presume the designated mountpoint for extensions is something like:

mib-2.bgp-mib2.(...).PathTableExtensions (at the same level as PathAtttrTable)

Presume our community extension mib looked something like this:
bgpcommunitytable MODULE-IDENTITY PathTableExtensions.1
CommunityTable = bgpcommunitytable.1

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

Is there an accepted practice that allows one to extend an existing
table without have to issue a new document that revises the entire
table?  

I really expect the answer to the above question is "no, that's not
the way SMI works".  This would be a pity since allowing something like
this allows for cleanly extending table contents for extensions.

A secondary issue is that if one wishes to add multiple objects, for
example in the route reflection extension MIB:

ReflectPeerTable AUGMENTS BgpPeerEntry = {
    RouteReflectType INTEGER
}

ReflectPathAttr AUGMENTS PathAttrEntry = {
    ClusterListString
    ClusterListIndex
    OriginatorId
}

We now have multiple extension tables that make rooting the MODULE-IDENTITY
of extensions make more sense at the top level of the base MIB.

...

My views on this may be a bit skewed since all of my management experience
has been using snmpget and snmpwalk.  The fact that information extending
the base tables might not show up in the walk is probably just an unfortunate
fact of life.

Please let me know if I'm completely off base.  I think once I have
these things answered, I can proceed with my work.


-- 
Jeff Haas 
NextHop Technologies