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

[Paul Traina <[e-mail]>]

  From: [e-mail] (John Y. Chu)
  Subject: A proposed change to BGP-4 MIB bgpPeerTable INDEX clause
  
  Folks,
  A change to the BGP-4 MIB definition has been proposed.  The change
  is to use an existing field (bgpPeerLocalAddr) as the secondary index
  of bgpPeerTable, as shown:
  
  
                  bgpPeerEntry OBJECT-TYPE
                      SYNTAX     BgpPeerEntry
                      MAX-ACCESS not-accessible
                      STATUS     current
                      DESCRIPTION
                              "Entry containing information about the
                              connection with a BGP peer."
                      INDEX { bgpPeerRemoteAddr,
  +                           bgpPeerLocalAddr  }
                      ::= { bgpPeerTable 1 }
  
  
  The BGP-4 protocol spec allows multiple BGP sessions to be established
  with a single peer, and each session is distinguished by its local IP
  address.  Thus the change.
  
  Comment?

Ugh!  Bletch.  Barf! ...is that sufficient?  :-)

This is a very serious change this late in the game for something that I have
never seen anyone do or request.

The only need I have ever encountered for multiple sessions are the
connection of two peers together through a primary network (A) and a
back-door network (B), in which case, the peerings are uniquely identified
by the remote IP addresses.

	B	|---R---|	A
		|	|
	B	|---R---|	A

Now don't get me wrong,  it's certainly possible to establish two peerings
with a remote internal peer over different source addresses,  but that would
be far less efficient than using a single connection from source to destination
and letting the IGP route the connection (that's the whole point of a loopback
interface).

I be interested in hearing the result of your recent survey of "who has
implemented the BGP-4 MIB" since obviously I wouldn't be griping
about this so much if I weren't unhappy about the backwards compatibility
problem you've just fed me since I was so foolhardy as to implement the
MIB to the draft as it stood a year ago. :-)

I would urge you to reconsider this change.... if it was changing a
component, I might let it slide,  but when you add an additional index,
I think you should have a really good justification, and I don't see one
here.