[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Challenges for the BGP MIBv2
On Tue, Sep 28, 2004 at 12:56:12PM -0400, Jeffrey Haas wrote:
> Would you recommend having both forms - the human readable form
> and also the machine readable form?
I would be worried about two formats. And if in doubt, I would prefer
machine readable format in a MIB (since SNMP data by its very nature
is more geared towards programs).
> > 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?
You might be pretty OK in practice if you keep things well within the
evolving Internet MTU of 1500 bytes (whole IP packet). Doing more is
definitely asking for trouble. And some implementations may even no
interoperate with 1500 byte packets (and still be compliant SNMP
engines).
> 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?
You should for sure have a good explanation. We do have objects which
are much larger in existing MIBs. But then usually there is a good
story why in practice they won't be so large and so on. Looking at
BGP paths, such an argument may be difficult to make.
> 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".
The IF-MIB is a prominent example where the ifTable and the ifXTable are
rooted in very different branches of the OID space. For real management
applications, this does not matter at all. BTW, the new module will be
rooted below mib-2 anyway according to the MIB review guidelines.
> 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.
Exactly.
> Please let me know if I'm completely off base. I think once I have
> these things answered, I can proceed with my work.
I looked through the existing BGP4-MIB today (for some other reason).
It is IPv4 specific - do you plan to make it IP version independent?
In that case, you have to rewrite it anyway and the whole discussion
about extensions of the existing MIB becomes a mood point.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany