Re: [Idr] BGP MIBv2 implementation

[Jeffrey Haas <[e-mail]>]

Responding to a somewhat stale thread:

On Wed, Jul 25, 2012 at 04:21:50PM -0700, Bill Fenner wrote:
> > What is the problem with expanding the table to include all required BGP
> > information? If your concern is memory utilization, at the risk of stating
> > the obvious let me say that MIB structure doesn?t necessarily prescribe the
> > internal database structure, meaning you can always choose a more efficient
> > internal structure (e.g. using pointers instead of storing duplicate
> > information) and translate the SNMP queries from/to the MIB structure.
> >
> 
> Of course the SNMP structure is not necessarily at all related to the
> internal data structures.  My understanding is that the reason for the
> Rib-OUT table using RowPointer was the [not that well-founded, but still
> widespread] concern about the amount of data returned in a full MIB walk.

Speaking as a user of various MIBs while at a previous employer, I had way
too many bugs open with too many vendors on mis-behaving large MIB walks.
As a developer, while I realize that there shouldn't be this big of a
concern over the problem space, it crops up way too many places for me to
have stayed comfortable with the idea in the base BGP MIB v2.

>  (Also, it does concretely reduce the amount of data you need to process if
> you're a management system that wants to know all of the RIB-IN plus
> RIB-OUTs.)

This ended up being a bigger reason for the change.  The amount of redundant
information consumed by management systems got to be very large, very quick.
There was also the matter of consistency: When 200 peers all were recieving
the same route, if your MIB walk is too slow it may change state prior to
the completion of the walk.  

SNMP really is just the wrong tool for this sort of monitoring.

> What about representing locally-advertised routes as being received from a
> peer of type unknown, with zero length address?
> 
> 
> > ****
> >
> > -          Add support for BGP communities (as in your communities draft)
> > in the NLRI in/out tables.****
> >
> > There is no reason this can't be a future addition, right, in the interest
> > of getting the base functionality out?****
> >
> > ** **
> >
> > [DC] Why should this simple addition hold back progress?
> >
> 
> It was removed in 2007 because of a lack of consensus about including it.
>  Is your sense that that lack of consensus has changed?

An additional bit of conversation Bill and I had at IETF 84 while reviewing
BGP MIBv2 issues was that nothing stops someone like you, Daniel, from
adding an extension MIB that gives you the entire table, communities, etc.
My suggestion, however, is that the representational issues around
representing structured information in MIBs is that it's too much pain to
really want to do.

I would much more strongly support work to do this in YANG.
(And if I ever manage to help get this MIB to RFC, might have some energy to
help with that.)

-- Jeff