Re: A proposed change to BGP-4 MIB bgpPeerTable INDEX clause

[Dennis Ferguson <[e-mail]>]

Dimitry,

>  This change has been requested by me and is based on our experience of
>  implementing BGP-4 MIB. I'm realy sorry :(( bringing it up this late but I
>  still view it important enough to be considered before BGP-4 MIB can be
>  advanced to a Draft Standard -- without this change BGP-4 MIB will not be
>  able to support multiple bgp connection to the same remote address which
>  IS supported by BGP-4 RFC.  Without this change implementations which
>  allow such setup with full compliance with BGP-4 RFC (e.g. Bay Network's
>  implementation) will not be able to use the "standard" BGP-4 MIB for bgp
>  management.

I think I agree with Paul's conclusion, though maybe not with all his
arguments.

I also have an implementation which will allow multiple BGP sessions to
the same guy using different local addresses, in full compliance with
the BGP-4 RFC ("compliance" in that, while it doesn't explicitly say
you can do this, it doesn't explicitly say anything to prevent this
either).  I knew of no particular reason why this would be useful when
the code was written, and still don't, but saw no reason to disallow
this either since it wasn't inconvenient for the implementation and
someone else might find something useful to do with it.

But in addition to this, the same implementation allows you the option of
leaving the local address unspecified, in full compliance with the
BGP-4 RFC, in which case the local address may very well change from
connection to connection and be unknown in Idle or Active state.
This seems a bit problematic given your proposed change, since this
is probably the more normally used case but such connections will end
up with an index which is a moving target.

The same implementation also allows, in full compliance with the BGP-4
RFC, the option of leaving the remote (as well as local) addresses
unspecified, using an address-and-mask policy filter to mediate who
is allowed to connect.  This is occasionally useful in that it can allow
a new IBGP peer to be added to the mesh without prior configuration
of every router in the mesh.  This is unaffected by your change, but
I did want to point this out as another feature which the BGP-4 RFC
allows but which can't be managed using the "standard" BGP-4 MIB (if
only because the standard mib has no way to let you set address-and-mask
filters).

The same implementation also allows, in full compliance with the BGP-4
RFC, multiple connections using the same pair of source and destination
addresses, with the connections being distinguished by local and remote
AS numbers.  This is possibly useful if the local and/or remote router
implementation supports simultaneous operations in multiple AS's, something
which the BGP-4 RFC doesn't explicitly recognize as possible but doesn't
explicitly disallow either.  This can't be managed using the standard
BGP-4 MIB either, even after your change.

And the same implementation also allows, in full compliance with the BGP-4
RFC, multiple connections using the same pair of source and destination
addresses, with the same AS numbers in use, with the sessions being
distinguished for policy purposes using OPEN message authentication.  This
is possibly useful if, for example, you want to have multiple-local-RIB route
servers running IBGP between themselves, perhaps to ensure that a particular
route is advertised to a particular AS at only one interconnect at a time.
This can't be managed using the standard BGP-4 MIB either.

In fact there are a lot of things one can do in full compliance (where
"compliance" is defined as it works, and isn't explicitly disallowed
by the standard) with just about any routing protocol standard you care
to pick which are impossible to "manage" with that routing protocol's
standard MIB.  In fact this is probably an unavoidable outcome of the
conflict between good protocol specification, whose aim should be to
avoid unnecessary constaints on reasonable, unforeseen applications of
the protocol, and good MIB specification, which really needs to strive
for simplicity and stability to ensure that implementation requirements
are kept reasonable.  Or, at least, this is the conclusion I drew when
I brought up this exact issue about the BGP-3 MIB when it was being defined,
and had my request for changes to the equivalent index vetoed by the group.

In any case, while I empathize with your having an implementation feature
which is inaccessable from the proposed BGP-4 MIB, this is certainly not
the only such implementation feature which exists, or will come to exist.
And for this particular feature I agree with Paul that the lateness of
this change makes the cost/benefit ratio for the change extremely
unattractive.  The feature is unlikely to be commonly used and the MIB
is old enough to cause backward compatability concerns.

So I think that if you let the SNMP tail wag your implementation dog you are
bound to end up with an implementation which is least common denominator
in terms of features.  In this case the least common denominator doesn't
seem too bad.

Dennis Ferguson