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

Dimitry Haskin <dimitry_haskin@wellfleet.com> Thu, 19 January 1995 20:55 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09186; 19 Jan 95 15:55 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09182; 19 Jan 95 15:55 EST
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa14475; 19 Jan 95 15:55 EST
Received: by interlock.ans.net id AA38946 (InterLock SMTP Gateway 1.1 for iwg-out@ans.net); Thu, 19 Jan 1995 15:24:25 -0500
Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 19 Jan 1995 15:24:25 -0500
Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 19 Jan 1995 15:24:25 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 19 Jan 1995 15:24:25 -0500
Date: Thu, 19 Jan 95 15:22:31 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dimitry Haskin <dimitry_haskin@wellfleet.com>
Message-Id: <9501192022.AA11710@wellfleet>
To: pst@cisco.com
Subject: Re: A proposed change to BGP-4 MIB bgpPeerTable INDEX clause
Cc: bgp@ans.net, snyder@cisco.com

 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.

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.

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.

There also is a redundancy argument which is a weak one.

Regards,
 Dimitry