Subject: BGP-4 mib announcement
From: Susan Hares <[email-masked]>
To: [email-masked]
Date: Sat, 27 Feb 1999 07:45:23 -0500 (EST)

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-04.txt
Date: Thu, 25 Feb 1999 16:24:50 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

Note: This revision reflects comments received during the last call period.

	Title		: Definitions of Managed Objects for the 
                          Fourth Version of Border Gateway Protocol (BGP-4)
	Author(s)	: S. Hares, J. Johnson, S. Willis, J. Burruss, J. Chu
	Filename	: draft-ietf-idr-bgp4-mib-04.txt
	Pages		: 30
	Date		: 23-Feb-99
	
   This memo is an extension to the SNMP MIB.  It specifies an IAB
   standards track protocol for the Internet community, and requests
   discussion and suggestions for improvements.  The origin of this memo
   is from RFC 1269 'Definitions of Managed Objects for the Border
   Gateway Protocol (Version 3)', which was updated to support BGP-4 in
   RFC 1657.  This memo fixes errors introduced when the MIB was
   converted to use the SNMPv2 SMI, as well as updates references to the
   current SNMP framework documents.
 
   Distribution of this memo is unlimited.  Please forward comments to
   [email-masked].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-mib-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-mib-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: [email-masked]
Date: Thu, 25 Feb 1999 06:04:36 -0500 (EST)
To: [email-masked]
Subject: BGP-4 MIB last call
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The BGP-4 mib text has been modified to meet IETF 
standards.  It has been reposted as:

	 <draft-ietf-idr-bgp4-mib-04.txt>

This document will go out for 1 week review. 
I will post last call on this document on 3/5/99.  

A number of implementations of this BGP-4+ MIB have
been written.  Could the implementors of these MIBs
please send the answers to the following questions
to me:

        1) Do you have an implementation of the BGP-4 MIB?

          An improved draft of the BGP-4 MIB has been posted
          to the Internet Drafts.   The explanations of the BGP-4
          MIB has been changed, but not the MIB format.

       2) Can you send me a snmpwalk of this BGP-4+ MIB?
	  If yes is the answer to the question, please
	  enclose the output of an snmpwalk.

       3) How many products is the BGP-4+ in?  How many
          units has each product sold?

        4) How many ISPs use routers with BGP-4+ in their Network?
           How many people make use of the BGP-4+ MIB in running
           their network?

Thank-you,

Susan Hares

Date: Thu, 25 Feb 1999 08:44:08 +0100 (MET)
From: "Peder Chr. Norgaard" <[email-masked]>
To: [email-masked]
Cc: Susan Hares <[email-masked]>, [email-masked]
Subject: Re: fyi - forwarded submission
Sender: [email-masked]

On Wed, 24 Feb 1999 [email-masked] wrote:

> this error, plus one more (the REVISION clauses in the MODULE-IDENTITY
> are in the wrong order) have been fixed in a -04 draft which has been
> submitted to the Internet Drafts editor.
> 
> /jeff
> 

Hereby acknowledge:  the revised draft compiles fine for me.

thank you very much.
					--peder chr.

Peder Chr. Nørgaard                   System Developer, M. Sc.
Telebit Communications A/S            tel: +45 86 28 81 77 - 49
Fabrikvej 11                          fax: +45 86 28 81 86
DK-8260 Viby J   Denmark              e-mail: [email-masked]

Date: Wed, 24 Feb 1999 13:13:35 -0500 (EST)
From: Susan Hares <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: fyi - forwarded submission
Sender: [email-masked]

Did you like the question set I sent?

Sue

On Wed, 24 Feb 1999 [email-masked] wrote:

> this error, plus one more (the REVISION clauses in the MODULE-IDENTITY
> are in the wrong order) have been fixed in a -04 draft which has been
> submitted to the Internet Drafts editor.
> 
> /jeff
> 
> > 
> > There is a syntax error in the BGP4 MIB draft.  Line 775 says:
> > 
> >            ::= { bgpPathAttrTable 1 }
> > 
> > RFC 1657 has it correctly:
> > 
> >            ::= { bgpRcvdPathAttrTable 1 }
> > 
> > OK, it is in the obsoleted part of the MIB.  But it prevents load of the
> > MIB by the system I use to compile MIBs (the scotty system).
> > 
> > best regards
> > 				--peder chr.
> 

From: [email-masked]
Subject: Re: fyi - forwarded submission
To: [email-masked] (Susan Hares)
Date: Wed, 24 Feb 1999 07:32:07 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

this error, plus one more (the REVISION clauses in the MODULE-IDENTITY
are in the wrong order) have been fixed in a -04 draft which has been
submitted to the Internet Drafts editor.

/jeff

> 
> There is a syntax error in the BGP4 MIB draft.  Line 775 says:
> 
>            ::= { bgpPathAttrTable 1 }
> 
> RFC 1657 has it correctly:
> 
>            ::= { bgpRcvdPathAttrTable 1 }
> 
> OK, it is in the obsoleted part of the MIB.  But it prevents load of the
> MIB by the system I use to compile MIBs (the scotty system).
> 
> best regards
> 				--peder chr.

Date: Wed, 24 Feb 1999 06:42:52 -0500 (EST)
From: Susan Hares <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: fyi - forwarded submission
Sender: [email-masked]

Date: Wed, 24 Feb 1999 04:08:10 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from
["Peder Chr. Norgaard" <[email-masked]>]   

Date: Wed, 24 Feb 1999 10:07:58 +0100 (MET)
From: "Peder Chr. Norgaard" <[email-masked]>
Subject: Syntax error in draft-ietf-idr-bgp4-mib-03.txt - does not compile

There is a syntax error in the BGP4 MIB draft.  Line 775 says:

           ::= { bgpPathAttrTable 1 }

RFC 1657 has it correctly:

           ::= { bgpRcvdPathAttrTable 1 }

OK, it is in the obsoleted part of the MIB.  But it prevents load of the
MIB by the system I use to compile MIBs (the scotty system).

best regards
				--peder chr.

Peder Chr. Nørgaard                   System Developer, M. Sc.
Telebit Communications A/S            tel: +45 86 28 81 77 - 49
Fabrikvej 11                          fax: +45 86 28 81 86
DK-8260 Viby J   Denmark              e-mail: [email-masked]

Date: Fri, 19 Feb 1999 18:51:31 -0500 (EST)
From: Susan Hares <[email-masked]>
To: Fred Baker <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IP6 support in draft-ietf-idr-bgp4-mib-03.txt
Sender: [email-masked]

Fred:

So.. with that input, we are going to:

	1) Call for implementation status on the current BGP-4+ MIB
	2) Create the standardization report for the BGP-4+ MIB
	3) Use the MIB standardization report to forward the MIB
	    along the standards track

I'll start the new MIB work with jeff - if you want to Jeff.

Sue

On Fri, 19 Feb 1999, Fred Baker wrote:

> At 10:07 AM 2/19/99 -0800, [email-masked] wrote:
> >Since the purpose of this draft is to advance the current mib along the
> >standards track, I feel it is best left alone.  I agree with Sue that a new
> >mib will be required to address IPv6 as well as other issues.
> 
> OK, I'll buy that
> 

Date: Fri, 19 Feb 1999 10:47:54 -0800
To: [email-masked]
From: Fred Baker <[email-masked]>
Subject: Re: IP6 support in draft-ietf-idr-bgp4-mib-03.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 10:07 AM 2/19/99 -0800, [email-masked] wrote:
>Since the purpose of this draft is to advance the current mib along the
>standards track, I feel it is best left alone.  I agree with Sue that a new
>mib will be required to address IPv6 as well as other issues.

OK, I'll buy that

From: [email-masked]
Subject: Re: IP6 support in draft-ietf-idr-bgp4-mib-03.txt
To: [email-masked] (Fred Baker)
Date: Fri, 19 Feb 1999 10:07:01 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 
> At 05:19 AM 2/19/99 -0500, Susan Hares wrote:
> >I cannot speak for the other co-authors, but I had intended to
> >suggest to the working group that the mib like the BGP
> >should have a normal MIB RFC and a follow-on RFC that supports
> >Multi-protocol BGP (multicast and IPv6).  
> 
> works for me; it seems like that second document might be an "augment" MIB
> if the base MIB is structured properly - simply add optional objects that
> implement the relevant address types. The biggest issues there are likely
> to be the use of addresses as index objects (which mean that you swap out a
> table instead of an object) and semantic differences like the need for an
> (S,G) route. Do you believe that the BGP-4 MIB is structured in such a way
> as to make this relatively painless?

All of the tables in the MIB contain one or more indices of type IpAddress,
which is an IPv4 address type.  IPv6 addresses/routes will require new tables.

Since the purpose of this draft is to advance the current mib along the
standards track, I feel it is best left alone.  I agree with Sue that a new
mib will be required to address IPv6 as well as other issues.

/jeff

Date: Fri, 19 Feb 1999 08:36:40 -0800
To: Susan Hares <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: IP6 support in draft-ietf-idr-bgp4-mib-03.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], Rob Coltun <[email-masked]>
Sender: [email-masked]

At 05:19 AM 2/19/99 -0500, Susan Hares wrote:
>I cannot speak for the other co-authors, but I had intended to
>suggest to the working group that the mib like the BGP
>should have a normal MIB RFC and a follow-on RFC that supports
>Multi-protocol BGP (multicast and IPv6).  

works for me; it seems like that second document might be an "augment" MIB
if the base MIB is structured properly - simply add optional objects that
implement the relevant address types. The biggest issues there are likely
to be the use of addresses as index objects (which mean that you swap out a
table instead of an object) and semantic differences like the need for an
(S,G) route. Do you believe that the BGP-4 MIB is structured in such a way
as to make this relatively painless?

Date: Fri, 19 Feb 1999 05:19:40 -0500 (EST)
From: Susan Hares <[email-masked]>
To: Fred Baker <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: IP6 support in draft-ietf-idr-bgp4-mib-03.txt
Sender: [email-masked]

Fred:

I cannot speak for the other co-authors, but I had intended to
suggest to the working group that the mib like the BGP
should have a normal MIB RFC and a follow-on RFC that supports
Multi-protocol BGP (multicast and IPv6).  

Sue Hares

On Thu, 18 Feb 1999, Fred Baker wrote:

> A question has come up that you may know the answer to. How does
> draft-ietf-idr-bgp4-mib-03.txt address IP6 environments? Specifically
> what recommendations do you have for supporting IP6?
> 

Date: Thu, 18 Feb 1999 14:42:41 -0800 (PST)
From: Fred Baker <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: IP6 support in draft-ietf-idr-bgp4-mib-03.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

A question has come up that you may know the answer to. How does
draft-ietf-idr-bgp4-mib-03.txt address IP6 environments? Specifically
what recommendations do you have for supporting IP6?

To: Paul Traina <[email-masked]>
cc: "jaihari loganathan" <[email-masked]>, [email-masked]
Subject: Re: RFC 1965 AS_PATH modification rules 
Date: Tue, 16 Feb 1999 20:56:37 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

Hi,

Having gone over this with pst (Paul T.), it seems that it would make 
sense to update the RFC to reflect various peoples experiences with
BGP confederations and at the same time push the RFC from its current 
Experimental status to Proposed Standard.

Would the WG co-chairs and other members of the list be interested in 
pursuing this?  IMHO since there are multiple implementations and 
deployments of confederations in the field, this looks reasonable.

Thanks,
--rohit.

On Thu, 11 Feb 1999 11:34:00 -0800 [email-masked] writes:
=>No.
=>
=>
=>In message <[email-masked]>, Rohit Dube write
>s:
=>> On Thu, 11 Feb 1999 09:49:24 PST [email-masked] writes:
=>> =>Hi,
=>> =>   AS_PATH modification rules about propagating a route to a 
=>> =>CONFEDERATION-EBGP peer goes :
=>> =>
=>> =>   "2) if the first path segment of the AS_PATH is not of type 
=>> =>AS_CONFED_SEQUENCE the local system shall prepend a new path segment of 
=>> =>type AS_CONFED_SEQUENCE to the AS_PATH, including its own
=>> =>confederation identifier in that segment."
=>> =>^^^^^^^^^^^^^^^^^^^^^^^^
=>> =>   
=>> =>   Question : Should this not be "its own AS number" instead.
=>> 
=>> Yup you are right.
=>> 
=>> The RFC may need an update on this as also on the segment type defines.
=>> AS_CONFED_SEQUENCE is defined as 4 whereas most deployed implementations 
=>> that I am aware of actually use a type of 3. 
=>> 
=>> pst, care to update??
=>> 
=>> --rohit.
=>
___

From: Avi Freedman <[email-masked]>
Subject: Re: BGP RFC & draft: 6.8 Connection collision detection.
To: [email-masked] (Gunnar Lindberg)
Date: Tue, 16 Feb 1999 09:03:07 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> Fair enough, or rather "fuzzy enough" :-). On the nitpicking side one
> could argue whether cisco has this "allowed via configuration" since
> it's probably hardwired into their code, but never mind... I.e. fine,
> 
> 	Gunnar

Sure, it's configurable - if you don't add any other peers between the
same pair of routers, any SYN from any other IP (or the one configured)
will be ignored if there's a session in place...

Avi

From: Gunnar Lindberg <[email-masked]>
Date: Tue, 16 Feb 1999 11:14:01 +0100 (MET)
To: [email-masked]
Subject: Re: BGP RFC & draft: 6.8 Connection collision detection.
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Fair enough, or rather "fuzzy enough" :-). On the nitpicking side one
could argue whether cisco has this "allowed via configuration" since
it's probably hardwired into their code, but never mind... I.e. fine,

	Gunnar

>From [email-masked]  Wed Feb 10 23:48:06 1999
>Message-Id: <[email-masked]>
>Date: Wed, 10 Feb 1999 14:28:30 -0800
>From: Yakov Rekhter <[email-masked]>

>[replying to myself...]

>> > <[email-masked]>, the mail below was sent both to the official IDR
>> > mailing list <[email-masked]> and to the RFC and draft authors. Fairly
>> > long time ago. To date we have not received any response.
>> > 
>> > As is, it seems like RFC1771 and draft-ietf-idr-bgp4-08.txt describes
>> > something different from what that most implementations do. If so,
>> > this is bad for IETF documents' credibility.
>> > 
>> > It may well be that we are wrong, but if so one could expect some
>> > response from the authors to tell us that and explain why and how.
>> > Hope to get either response soon.
>> 
>> Unless there will be strong objections on the IDR mailing list,
>> I'll remove secton 6.8 from the Internet Draft.

>rather than removing section 6.8, I'd like to propose to replace

>       A connection collision with an existing BGP connection that is in
>       Established states causes unconditional closing of the newly
>       created connection.
>   
>   with
>   
>       Unless allowed via configuration, a connection collision with an
>       existing BGP connection that is in Established state causes closing
>       of the newly created connection.

>That would be enough to address the prolem raised by Gunnar.
>   
>Yakov.

To: "jaihari loganathan" <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 1965 AS_PATH modification rules 
Date: Thu, 11 Feb 1999 13:41:43 -0500
From: Rohit Dube <[email-masked]>
Sender: [email-masked]

On Thu, 11 Feb 1999 09:49:24 PST [email-masked] writes:
=>Hi,
=>   AS_PATH modification rules about propagating a route to a 
=>CONFEDERATION-EBGP peer goes :
=>
=>   "2) if the first path segment of the AS_PATH is not of type 
=>AS_CONFED_SEQUENCE the local system shall prepend a new path segment of 
=>type AS_CONFED_SEQUENCE to the AS_PATH, including its own
=>confederation identifier in that segment."
=>^^^^^^^^^^^^^^^^^^^^^^^^
=>   
=>   Question : Should this not be "its own AS number" instead.

Yup you are right.

The RFC may need an update on this as also on the segment type defines.
AS_CONFED_SEQUENCE is defined as 4 whereas most deployed implementations 
that I am aware of actually use a type of 3. 

pst, care to update??

--rohit.

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC 1965 AS_PATH modification rules
Date: Thu, 11 Feb 1999 09:49:24 PST
Sender: [email-masked]

Hi,
   AS_PATH modification rules about propagating a route to a 
CONFEDERATION-EBGP peer goes :

   "2) if the first path segment of the AS_PATH is not of type 
AS_CONFED_SEQUENCE the local system shall prepend a new path segment of 
type AS_CONFED_SEQUENCE to the AS_PATH, including its own
confederation identifier in that segment."
^^^^^^^^^^^^^^^^^^^^^^^^
   
   Question : Should this not be "its own AS number" instead.

Pl. let me know,
Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

To: Yakov Rekhter <[email-masked]>
cc: Gunnar Lindberg <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP RFC & draft: 6.8 Connection collision detection. 
Date: Wed, 10 Feb 1999 14:28:30 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

[replying to myself...]

> > <[email-masked]>, the mail below was sent both to the official IDR
> > mailing list <[email-masked]> and to the RFC and draft authors. Fairly
> > long time ago. To date we have not received any response.
> > 
> > As is, it seems like RFC1771 and draft-ietf-idr-bgp4-08.txt describes
> > something different from what that most implementations do. If so,
> > this is bad for IETF documents' credibility.
> > 
> > It may well be that we are wrong, but if so one could expect some
> > response from the authors to tell us that and explain why and how.
> > Hope to get either response soon.
> 
> Unless there will be strong objections on the IDR mailing list,
> I'll remove secton 6.8 from the Internet Draft.

rather than removing section 6.8, I'd like to propose to replace

       A connection collision with an existing BGP connection that is in
       Established states causes unconditional closing of the newly
       created connection.
   
   with
   
       Unless allowed via configuration, a connection collision with an
       existing BGP connection that is in Established state causes closing
       of the newly created connection.

That would be enough to address the prolem raised by Gunnar.
   
Yakov.

To: Gunnar Lindberg <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP RFC & draft: 6.8 Connection collision detection. 
Date: Wed, 10 Feb 1999 12:25:56 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Gunnar,

> <[email-masked]>, the mail below was sent both to the official IDR
> mailing list <[email-masked]> and to the RFC and draft authors. Fairly
> long time ago. To date we have not received any response.
> 
> As is, it seems like RFC1771 and draft-ietf-idr-bgp4-08.txt describes
> something different from what that most implementations do. If so,
> this is bad for IETF documents' credibility.
> 
> It may well be that we are wrong, but if so one could expect some
> response from the authors to tell us that and explain why and how.
> Hope to get either response soon.

Unless there will be strong objections on the IDR mailing list,
I'll remove secton 6.8 from the Internet Draft.

Yakov.

> 
> 	Gunnar Lindberg
> 
> -----------------------------------------------------------------------
> >From [email-masked]  Fri Oct 30 10:22:52 1998
> >From: Gunnar Lindberg <[email-masked]>
> >Date: Fri, 30 Oct 1998 10:02:53 +0100 (MET)
> >Message-Id: <[email-masked]>
> >To: [email-masked], [email-masked], [email-masked]
> >Subject: BGP RFC & draft: 6.8 Connection collision detection.
> >Cc: [email-masked]
> 
> >This is an old question that a colleuage of mine brought up with
> >Yakov Rekhter quite some time ago. It exists both in RFC1771 and
> >draft-ietf-idr-bgp4-08.txt, and maybe we should get rid of it, i.e.
> >make the STD docs reflect reality and implementations.
> 
> >It seems to us that "6.8 Connection collision detection" makes it
> >impossible to form parallel EBGP sessions between a pair of routers,
> >even if the sessions are over different interfaces/networks. E.g.
> 
> >    =========================================
> >    =                                       =
> >    =              <- EBGP ->               =
> >    ========+=====================+==========
> >         ___|___       :       ___|___ 
> >        !       ! AS1  :  AS2 !       !
> >        !_______!      :      !_______!
> >            |          :          |
> >    --------+---------------------+----------
> >                   <- EBGP ->
> 
> >What we do is set up EBGP sessions between the two routers over both
> >the FDDI and the Ethernet. This is for backup only, we use LocalPref
> >to control it and we want both connections to be up for a reasonably
> >fast switchover if the FDDI fails - it does not seem like a god idea
> >to start with TCP connect and route updates at that time; well, you
> >all get the picture.
> 
> >In practice this works quite well (cisco equipment - we would assume
> >the same goes for other vendors, since this seems like a reasonable
> >thing to do).
> 
> >But, according to "6.8 Connection collision detection", the routers
> >should compare the "BGP Identifier" and only keep the connection that
> >is initiated by the one with the highest value. See below.
> 
> >This is true for multi-hop IBGP & EBGP, but not for *BGP interface-
> >to-interface, and the spec should clarify that. E.g:
> 
> >    If the connection is over directly connected interfaces,
> >    connection collision is detected by comparing the IP address
> >    of the remote peer/connection, instead of the BGP Identifier.
> 
> >Yes, I deliberatly want to allow parallel IBGP sessions interface-to-
> >interface as well - it is kind of weird, but I think we have a case
> >were it could be useful (but weird enough not to go public :-).
> 
> >All of this seems to work well with existing cisco code and does not
> >seem to harm. I suggest an update to the spec.
> 
> >	Gunnar Lindberg
> 
> >------------------------------------------------------------------------
> >6.8 Connection collision detection.
> 
> > If a pair of BGP speakers try simultaneously to establish a TCP
> > connection to each other, then two parallel connections between this
> > pair of speakers might well be formed.  We refer to this situation as
> > connection collision.  Clearly, one of these connections must be
> > closed.
> 
> > Based on the value of the BGP Identifier a convention is established
> > for detecting which BGP connection is to be preserved when a
> > collision does occur. The convention is to compare the BGP
> > Identifiers of the peers involved in the collision and to retain only
> > the connection initiated by the BGP speaker with the higher-valued
> > BGP Identifier.
> 
> > Upon receipt of an OPEN message, the local system must examine all of
> > its connections that are in the OpenConfirm state.  A BGP speaker may
> > also examine connections in an OpenSent state if it knows the BGP
> > Identifier of the peer by means outside of the protocol.  If among
> > these connections there is a connection to a remote BGP speaker whose
> > BGP Identifier equals the one in the OPEN message, then the local
> > system performs the following collision resolution procedure:
> 
> 
> >    1. The BGP Identifier of the local system is compared to the BGP
> >    Identifier of the remote system (as specified in the OPEN
> >    message).
> 
> >    2. If the value of the local BGP Identifier is less than the
> >    remote one, the local system closes BGP connection that already
> >    exists (the one that is already in the OpenConfirm state), and
> >    accepts BGP connection initiated by the remote system.
> 
> >    3. Otherwise, the local system closes newly created BGP connection
> >    (the one associated with the newly received OPEN message), and
> >    continues to use the existing one (the one that is already in the
> >    OpenConfirm state).
> 
> >    Comparing BGP Identifiers is done by treating them as (4-octet
> >    long) unsigned integers.
> > ...
> >------------------------------------------------------------------------
> 

From: Gunnar Lindberg <[email-masked]>
Date: Wed, 10 Feb 1999 12:22:02 +0100 (MET)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: BGP RFC & draft: 6.8 Connection collision detection.
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

<[email-masked]>, the mail below was sent both to the official IDR
mailing list <[email-masked]> and to the RFC and draft authors. Fairly
long time ago. To date we have not received any response.

As is, it seems like RFC1771 and draft-ietf-idr-bgp4-08.txt describes
something different from what that most implementations do. If so,
this is bad for IETF documents' credibility.

It may well be that we are wrong, but if so one could expect some
response from the authors to tell us that and explain why and how.
Hope to get either response soon.

	Gunnar Lindberg

-----------------------------------------------------------------------
>From [email-masked]  Fri Oct 30 10:22:52 1998
>From: Gunnar Lindberg <[email-masked]>
>Date: Fri, 30 Oct 1998 10:02:53 +0100 (MET)
>Message-Id: <[email-masked]>
>To: [email-masked], [email-masked], [email-masked]
>Subject: BGP RFC & draft: 6.8 Connection collision detection.
>Cc: [email-masked]

>This is an old question that a colleuage of mine brought up with
>Yakov Rekhter quite some time ago. It exists both in RFC1771 and
>draft-ietf-idr-bgp4-08.txt, and maybe we should get rid of it, i.e.
>make the STD docs reflect reality and implementations.

>It seems to us that "6.8 Connection collision detection" makes it
>impossible to form parallel EBGP sessions between a pair of routers,
>even if the sessions are over different interfaces/networks. E.g.

>    =========================================
>    =                                       =
>    =              <- EBGP ->               =
>    ========+=====================+==========
>         ___|___       :       ___|___ 
>        !       ! AS1  :  AS2 !       !
>        !_______!      :      !_______!
>            |          :          |
>    --------+---------------------+----------
>                   <- EBGP ->

>What we do is set up EBGP sessions between the two routers over both
>the FDDI and the Ethernet. This is for backup only, we use LocalPref
>to control it and we want both connections to be up for a reasonably
>fast switchover if the FDDI fails - it does not seem like a god idea
>to start with TCP connect and route updates at that time; well, you
>all get the picture.

>In practice this works quite well (cisco equipment - we would assume
>the same goes for other vendors, since this seems like a reasonable
>thing to do).

>But, according to "6.8 Connection collision detection", the routers
>should compare the "BGP Identifier" and only keep the connection that
>is initiated by the one with the highest value. See below.

>This is true for multi-hop IBGP & EBGP, but not for *BGP interface-
>to-interface, and the spec should clarify that. E.g:

>    If the connection is over directly connected interfaces,
>    connection collision is detected by comparing the IP address
>    of the remote peer/connection, instead of the BGP Identifier.

>Yes, I deliberatly want to allow parallel IBGP sessions interface-to-
>interface as well - it is kind of weird, but I think we have a case
>were it could be useful (but weird enough not to go public :-).

>All of this seems to work well with existing cisco code and does not
>seem to harm. I suggest an update to the spec.

>	Gunnar Lindberg

>------------------------------------------------------------------------
>6.8 Connection collision detection.

> If a pair of BGP speakers try simultaneously to establish a TCP
> connection to each other, then two parallel connections between this
> pair of speakers might well be formed.  We refer to this situation as
> connection collision.  Clearly, one of these connections must be
> closed.

> Based on the value of the BGP Identifier a convention is established
> for detecting which BGP connection is to be preserved when a
> collision does occur. The convention is to compare the BGP
> Identifiers of the peers involved in the collision and to retain only
> the connection initiated by the BGP speaker with the higher-valued
> BGP Identifier.

> Upon receipt of an OPEN message, the local system must examine all of
> its connections that are in the OpenConfirm state.  A BGP speaker may
> also examine connections in an OpenSent state if it knows the BGP
> Identifier of the peer by means outside of the protocol.  If among
> these connections there is a connection to a remote BGP speaker whose
> BGP Identifier equals the one in the OPEN message, then the local
> system performs the following collision resolution procedure:

>    1. The BGP Identifier of the local system is compared to the BGP
>    Identifier of the remote system (as specified in the OPEN
>    message).

>    2. If the value of the local BGP Identifier is less than the
>    remote one, the local system closes BGP connection that already
>    exists (the one that is already in the OpenConfirm state), and
>    accepts BGP connection initiated by the remote system.

>    3. Otherwise, the local system closes newly created BGP connection
>    (the one associated with the newly received OPEN message), and
>    continues to use the existing one (the one that is already in the
>    OpenConfirm state).

>    Comparing BGP Identifiers is done by treating them as (4-octet
>    long) unsigned integers.
> ...
>------------------------------------------------------------------------