Re: [Idr] BGP MIB v2 input

[Jeffrey Haas <[e-mail]>]

Curtis,

On Mon, Mar 26, 2007 at 12:18:13PM -0400, Curtis Villamizar wrote:
> If we are going to play games that allow stateful SNMP access to solve
> the routing table dump problem I suggest we create a MIB pseudo write
> to take a snapshot of the routing table with a given identifier.

I may have mis-interpreted Bill, but I think he simply wanted a better
way to get at a specific set of routes rather than an atomic routing
table dump.  When I was pondering the "sub-view" problem, I had many of
the same thoughts you put in your reply.  My next thought was, 
"Ew, gross!"

I think the snapshot mechanism may be nice for some implementations, but
I'd hesitate to recommend it go into the IETF standard mib for BGP.

> As is (current MIB) from a practical standpoint the BGP routing table
> cannot be dumped via SNMP.

[All very much IMO:]

I'd agree.  I also don't know if it's the right problem to be solved.
SNMP is very good at getting you to specific instances of some data.  It
is okay for getting you the "next" data instance, but its idea of "next"
is a bit weak for routing table dumps.  

As a data abstraction format, it has some ugly limits.  You're
recommended to not use OCTET STRINGs longer than 255 bytes, but BGP has
several object that in binary format would be longer than that.  This
has meant that canonicalizing objects such as AS_PATHs require a pointer
to another table which breaks out the elements into effectively an array
of an array.

As an abstract data transport, it's weak in that it wants a pull rather
than a push.  This means that you end up making several potentially
expensive API calls to your routing table to pull data with the
possibility of caches going stale due to the time involved.  This may be
less so with GETBULK, but that depends on the user.

> I'm not sure if this addresses one implied requirement (or imagined on
> my part?) of #2 above, which is to dump a specific prefix only.  I
> thought that would already be possible with GET-NEXT and the existing
> ordering used in the MIB.

Fetching a specific prefix is easy.  Bill's suggestion was "fetch the
most specific prefix" or "fetch more specific prefixes".  The current
RFC 4273 MIB would return data:

        bgp4PathAttrEntry OBJECT-TYPE
            SYNTAX     Bgp4PathAttrEntry
            MAX-ACCESS not-accessible
            STATUS     current
            DESCRIPTION
                    "Information about a path to a network."
            INDEX { bgp4PathAttrIpAddrPrefix,
                    bgp4PathAttrIpAddrPrefixLen,
                    bgp4PathAttrPeer            }
            ::= { bgp4PathAttrTable 1 }

Prefix (an ip addres), followed by the prefix length, followed by the
peers who have that prefix.  (The update actually has the indexes the
other way - all routes for a peer.  That's broken and I'll fix it.)

This means that 10.0.0.0/8 and more specific will give you something
like:
10.0.0.0/8
10.0.0.0/9
10.1.0.0/24

You and I would expect 10.1/24 to fall after 10/8 as a more specific,
but SNMP wouldn't.  This lexicographic threading of a radix trie already
gives developers heartburn and introduces all sorts of fun
inefficiencies.

Perhaps the better question to ask is, "Is having access to the routing
table via SNMP even worth it?"  After several years of thinking about
this (and a little bit of time before that as an operator), I think the
answer is "maybe", but certainly not for dumping.  I've provided a
representation that lets you do it.  I can't even argue it's the best
one, but I seemed to have played "stump the mib doctor" a few times over
the past few years. :-)

-- Jeff

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr