Re: [Idr] BGP MIB v2 input

[Jeffrey Haas <[e-mail]>]

On Mon, Mar 26, 2007 at 06:50:37AM +0100, Bill Fenner wrote:
> It may be worth breaking this down into areas of limitation of the
> current MIB:
> 
> 1. v6 peer support
> 2. v6 and other NLRI support
> 3. 4-byte AS support
> 4. extra counters desired
> (Others?)
> 
> #1 can be taken care of with a rev of the peer table using
> the InetAddressType/InetAddress TCs.
> 
> For #2, I have a somewhat radical proposal, which is to eliminate
> the reporting of the BGP table contents via SNMP.  The radical
> replacement would be a "lookup request" which you do by writing
> an AFI, SAFI, NLRI to a lookup table, specifying whether you want
> longest match or all matches, and you read the results from a
> lookup results table.
> 
> (a few reasons for this change:
> a) It's not very efficient to have an SNMP table with 200k+ rows;
> b) It's hard to represent, e.g., VPN routes; and
> c) You probably want to know "what routes do you know for
> this destination", which is not easy to answer even with the
> existing indexing, since "destination" is probably a /32 and
> the prefix in the table is probably not)

#2 is an intriguing idea. Existing UI implementations already cover
having multiple "processes" access the routing table simultaneously.
However, I think this may have some interesting implementation
headaches.  Could you please comment on them?

- This would require set/write access to the MIB, correct?  If so,
  that's one of the things that people expressed serious reservations
  about for any purpose previously.  If not, are people on board with
  dynamic queries using get operations where getnext wouldn't work?
- The results would likely be some sort of dynamically created OID tree
  for each query.  UIs such as a CLI tend to have reasonably well
  understood lifetimes for their route table walking routines, but MIBs
  have a much less well defined interface.  Additionally, if you're
  running the same query over and over, you may end up with multiple
  views instatiated which may have excessive overhead.  Further, you
  don't have any sort of static OID you can use to monitor the state of
  a particular route.
- The results of this query would seem to be the same MIB structure as
  one would have for the entire routing table.  MIB structure-wise, I
  don't think we save any complexity.

If these premises are true to one extent or another, that still leads to
an interesting possibility.  We could still have the necessary query
objects.  The result would then be a rowpointer to the root of the
existing routing table's subtree that matched the query.  There would be
no need to dynamically generate views of the routing table, however
there would need to be a little intelligence in the querying routine to
stop walking after you've hit a less specific route.

> #3 is straightforward, especially since between #1 and #2
> we're probably changing most of the places you see an
> AS number anyway.

The choice I made in the updates was to simply have the base routing
table be 4-byte aware.  The annoying case is a 2-byte to 4-byte
transition speaker where three versions of the objects may be present:
The active derived set, the received 2-byte path attributes and the
received 4-byte path attributes.  In the interest of simplicity in the
base MIB, I'm suggesting the additional transitional views be left to an
extention MIB.

-- Jeff

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