Re: [Idr] BGP MIB v2 input

On Mon, Mar 26, 2007 at 10:50:18PM +0300, Pekka Savola wrote:
> Just wondering: the current BGP4 MIB already supports the routing 
> databse (BGP4-MIB::bgp4PathAttrBest at least).  Are you proposing 
> dropping the equivalent functionality from the new MIB or just some 
> more exciting new variants?

A deficiency that I had originally been asked to address in the second
version of the MIB was access to structured data.  I'll give two
examples:

- The AS_PATH in the RFC 4273 MIB is contained in:

        bgp4PathAttrASPathSegment OBJECT-TYPE
            SYNTAX     OCTET STRING (SIZE (2..255))
            MAX-ACCESS read-only
            STATUS     current

Pretty much memcpy() the AS_PATH into the MIB and truncate.
This had two issues:
1) It's truncated in some circumstances
2) It required the management appliance to have a function that could
parse AS_PATHs (and potentially truncated ones at that).

That's not useful.  For the AS_PATH, we probably want two pieces of
data:
1) Something humanly readable
2) Something that's a canonicalized version of the data structure that
doesn't lose information.

These can be solved using roughly this structure:
NlriTable contains pathattrindex
PathAttrTable[pathattrindex] contains path attributes:
 - MED, etc.
 - Human readable AS_PATH
 - aspathindex

AsPathTable[aspathindex][subindex] is a table that canonicalizes the
entirety of the AS_PATH.

Problems with this representation:
- The human readable bit will likely be vendor specific.  That's okay as
  long as we have something canonical.  However, it's going to be
  limited to 255 characters courtesy of SnmpAdminString
- The AsPathTable is convoluted enough that you probably still don't
  want to look at it.It could be interpreted by a human without decoding
  TLVs in your head, but it's still not pretty.  *However*, it is
  cachacble.

The second example is communities.  It has all of the same problems.
Additionally, communities aren't required to be supported in order to do
BGP.  This means putting them in the base BGP mib is probably a bad
idea.  You still want the data, so you put them in an extensions mib.

Note: IDR feedback has had me try things both ways over the last several
years with regards to extentions/not extentions.

> Similar information for the whole FIB exists under IP-FORWARD-MIB.

With all respect to that MIB author: The data was easier to represent.

> An example: I currently use both IP-FORWARD-MIB and 
> BGP4-MIB::bgp4PathAttrBest in SNMP scripts by parsing the config files 
> (interface-related routing protocol config to be exact) and checking 
> them against operational policy (e.g., certain kinds of interface 
> addresses must be in OSPF; others must not be in OSPF; some others 
> must be in BGP; static routes must be in BGP; etc.).

I think this answers some of Curtis' questions. :-)

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr