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
- A proposed change to BGP-4 MIB bgpPeerTable INDEX… John Y. Chu
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… Paul Traina
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… Robert Snyder
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… John Y. Chu
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… Robert Snyder
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… Dimitry Haskin
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… Paul Traina
- Re: A proposed change to BGP-4 MIB bgpPeerTable I… Dennis Ferguson