Re: [Idr] [IETFMIBS] SNMP bgpPeerTable IPV6

[Jeffrey Haas <[e-mail]>]

On Fri, Jul 30, 2010 at 02:29:19PM +0200, Simon Leinen wrote:
> The I-D has been active (growing and shrinking) over at least nine
> years: draft-ietf-idr-bgp4-mibv2-00 is from July 2001.  Since I cannot
> currently follow the IDR WG, I don't know what's holding it up right now.

There were several issues early on in its development:
- Requirements churn.  The original request was to bring "configurability"
  to the MIB.  You should find that several of the initial drafts thrashed
  around configuration objects.  Those were dropped ultimately due to both
  lack of support for it as a feature and resistance from implementors who
  simply didn't want writeable objects in the MIB.
- Structural representations with regard to BGP features that were lists of
  objects.  The usual example that tends to come up for this are
  communities.  The only way to represent communities in a human-readable
  format is to break them out into a separate table that has a loose
  relationship to the underlying path attributes table.  This is
  operationally unusable.  

  This particular issue drove me to eventually request the routing and OPS
  area to request MIB implementors to stop trying to put complex structural
  encodings in MIBs.  There was, IMO, very broad support for this action.
  The OPS groups at the time recognized that they needed to find a better
  representational mechanism.  I believe netconf/netmod was the general
  direction such things were pushed.

The MIB has been structurally stable for a while and is simply waiting for
implementations.  I have had one 95% done in Quagga for most of a few years
that I simply need to clean up and publish.  (And yes, I do recognize the
push I've gotten from several individuals in the last year to publish that
code.  I've simply had other life priorities.)

> > Force10 supports it under FORCE10-BGP4-V2-MIB
> 
> Thanks, that's great to know.  Force 10 just moved up two notches on
> my personal vendor sympathy scale.  Of course your feedback (and that
> of users on the operator side, if any) would be very useful for
> advancing this in IDR.

And I would appreciate feedback from the implementors with any issues they
had with either implementing the MIB from either a structural or an
operational standpoint.

-- Jeff