[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Challenges for the BGP MIBv2
On Wed, Sep 08, 2004 at 10:37:50AM -0400, Jeffrey Haas wrote:
> Issue 1:
> What is the value of using a table to represent a complex
> data structure when an SnmpAdminString representation of the
> same thing is available?
>
> Should we instead keep to coding it as an OCTET STRING and let
> management applications that care about things decode it themselves?
>
> Issue 1.1: Many list objects within BGP could potentially consume
> a majority of the BGP PDU. A BGP PDU is 4096 bytes. This means
> a given column can easily exceed the recommended column size.
> Breaking it down in a table simplifies implementation parsing at
> the cost of having a table of information that may be irrelevant when
> the SnmpAdminString representation may be enough. Representing it
> as an OCTET STRING reduces the overhead in fetching the information,
> but we may have to arbitrarily limit the size of the object and
> risk truncation.
>
> (Note that the human-readable format also suffers from possible
> truncation issues.)
I think there is no general answer to this question. Sometimes, encoding
things in an OCTET STRING makes sense, sometimes not. The DateAndTime TC
is an example where we encode structured data in an OCTET STRING and I
believe there is no discussion that this is the correct way to do
things. On the other end, probably everybody agrees that encoding
everything which describes an interface in an OCTET STRING would be
a bad things.
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.
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.
> Issue 2:
> How do we associate extension tables (e.g. communities) cleanly to
> the path attributes?
>
> If we were always including communities (e.g.), we could do this:
>
> PathAttrTable.PathAttrIndex = {
> (Standard RFC1771 path attribute scalars)
> AsPathString -- representation of complex data structure in human readable
> -- format (implementation dependant)
> AsPathIndex
> CommunityString -- representation of complex community data structure in
> -- human readable format (implementation dependant)
> CommunityIndex
> }
>
> CommunityTable.CommunityIndex.CommunitySubIndex = {
> CommunitySubIndex -- arbitrary subindex for unordered community list
> CommunityValue -- TC'd to OCTET STRING (4)
> }
>
> However, communities are not required to be implemented. How would we
> tie this in optionally?
It is common practice that index object have a range which excludes 0
so that you can use 0 as a special value in case there is no community
to point to. The much more interesting issue with such pointers is
referential integrity: what happens if an entry in the community table
is deleted?
> Issue 2.1:
> Since most optional extensions must be represented using a table,
> simple AUGMENTation can't be used. Is there an accepted alternative?
>
> The previously published version of the bgp-mibv2 did the following:
>
> CommunityTable.PathAttrIndex.CommunitySubIndex = {
> -- Same as above for Community Table
> }
>
> This is semantically correct since a given set of Path Attributes
> (identified by PathAttrIndex) includes (or doesn't) a given set of
> communities. However, the pointer approach (CommunityIndex)
> is cleaner since a given set of communities is likely to be attached
> to more than one distinct set of path attributes and this can
> minimize the number of times a management station must fetch a
> given set of communities.
>
> The approach of simply tying it to the PathAttrIndex allows clean
> extensions to the MIB without the need to "clutter" the PathAttrTable.
> It is unclear to me what the recognized practice is - clutter the table
> to make the implementation cleaner and simply make the presence of
> specific columns optional via conformance statements or tenuously
> connect things via the approach shown above for Issue 2.1.
Not sure I got this right. I guess you are worried that this indexing
approach duplicates community information. Whether this is an issue
depends on the usage of the MIB. There is no general answer I guess.
You have to look what managers likely do with the MIB. Implementation
wise, even if you have multiple tables, you might internally on the
agent store just one set of communities.
> Issue 2.2:
> Different extensions progress at different rates on the standards
> track. If the MIB were to embed information related to extensions
> at a lower level than the base specification, what issues does this
> cause on the standards track?
It won't work.
> 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. ;-)
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany