[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: Challenges for the BGP MIBv2

MIB Doctors, not sure if you are all on ietfmibs@ops.ietf.org

That is why I am forwarding.

Discussion and responses to ietfmibs@ops.ietf.org please

Bert

-----Original Message-----
From: Jeffrey Haas [mailto:jhaas@nexthop.com]
Sent: Wednesday, September 08, 2004 16:38
To: ietfmibs@ops.ietf.org
Cc: Jeffrey Haas
Subject: Challenges for the BGP MIBv2


MIB Experts,

I have been charged by the IDR working group to author/edit the
next version of the BGP MIB.  Almost two years ago with the help of
Wayne Tackabury we made a valiant start on getting this MIB put
together.  The current version of that MIB has expired.  Work on
that MIB had stalled while trying to finish work on the replacement
for RFC 1657.  That work appears to be nearing completion.

The replacement for RFC 1657 (currently published as
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-15.txt)
deals reasonably well with the updates to RFC 1771, but only deals
with the base BGP-4 protocol.  As many or most of you are probably 
aware, BGP has grown considerably over the years with a number
of extensions almost all of which are considered "optional", although
a number are well supported in almost all known implementations.

The challenges for the next version of the MIB is to properly represent
the base protocol functionality better than the draft-ietf-idr-bgp-mib-15
but also provide access to information that is contained in the
optional extensions.

Most of my challenges are "how do I properly represent a particular
object in the MIB".

Most of the extensions to BGP tend to create additional BGP Path Attributes.
For example, BGP Communities, BGP Extended Communities, Cluster Lists
for Route Reflection, etc.  Most of these additional Path Attributes can
be modeled as an ordered or unordered lists.

Conceptually, the information is roughly modeled like this:

NlriTable.Peer.Prefix = {
    (Calculated attributes)
    PathAttrIndex
    }

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

AsPathTable.AsPathIndex.AsPathSegmentIndex.AsPathElementIndex = {
    AsPathIndex -- arbitary table index to a distinct AS_PATH
    AsPathSegmentIndex -- index into ordered list of AS_PATH Segments
    AsPathElementIndex -- index into ordered list of AS_PATH Elements
		       -- within a given segment
    AsPathType -- Type of AS_Path that this element is.  All elements
	       -- within a given segmentindex must be the same.
    AsPathElement -- The AS Number itself
    }

In draft-ietf-idr-bgp4-mib-15, this table doesn't exist.  Instead it is
represented as an OCTET STRING where it is up to the end user to
break out the elements themselves.  (See bgp4PathAttrASPathSegment)

So, this brings us to:

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

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?

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.

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?

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.

Are there known approaches for dealing with this?

----------

Any help with the above general questions would be most useful.  I will
likely have additional questions after those issues are resolved.

-- 
Jeff Haas 
NextHop Technologies