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

[Paul Traina <[e-mail]>]

  From: [e-mail] (Dimitry Haskin)
  Subject: Re: A proposed change to BGP-4 MIB bgpPeerTable INDEX clause
  
   Paul,
  
  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.

Well, that's certainly an interesting way of phrasing it,  but I seem
to be having difficulty finding the exact text you're referring to in RFC1654,
in fact, the closest thing I find is section 6.8 which to my eye discourages
this sort of behavior.  In IDRP IPv6 Yakov and I went out of our way to
mention that while it was not precluded because of the broken nature of
IPv4 and IPv6 wrt addresses, it was not a good idea (we were polite).
  
  There are a few examples when multiple connections to the same remote
  address are useful:
  
  They can be used to gracefully move bgp connection from one local
  interface to another without loosing connectivity - you configure
  a secondary bgp connection and after it is fully up you disable
  the original one.

Why are you tying your BGP connections to a local interface in the first
place?  It seems to me that this is tied to an implementation, not part
of the protocol.
  
  They can be used to gracefully renumber an interface - you first assign
  a secondary address to the interface, configure a bgp connection from
  this new address without disrupting the original bgp connection, and
  after the new bgp connection is fully up the original connectin can
  be disconfigured.

If you're doing that, then you've already assumed that you have coordination
on both sides,  in which case,  using the same assumption, I would offer that
this is of little use to a customer since the reflexive operation may be
done on the other side.
  
  There also is a redundancy argument which is a weak one.

Agreed.

To be honest, and please, don't take offense, I'm not trying to take a
swipe at you folks...I don't understand why one would ever want to tie a BGP
session to a local IP address in the MIB.  Your TCP code selects the best
local address for a user automagicly,  and IBGP connections should either
follow that or home to a hardware independant IP address so that you're
not forcing the user to stand on his or her head in the cases where they
intend to renumber.

So, my basic feeling at this point is that there is little if any merit
to making such a capricious change to the MIB in order to support what
I would, at one of my most charitable moments, call a kludge.

Sorry,

Paul