Subject: Re: Generial Editorial Comment

From: "Tom Petch" <[email-masked]>
Date: Thu, 26 Sep 2002 19:50:11 +0100

I take issue with the 'will attempt to connect' which goes too far.

The FSM defines events 4 and 5, 'with passive Transport
establishment', so the system may wait and not attempt to connect.
The exit from this state is either the receipt of an incoming TCP
connection (SYN) or timer expiry.

So we may have a FSM attempting to transport connect for a given
source/destination IP pair or we may have an FSM not attempting to
connect.  (In the latter case, I do not think we can get a collision).
In the latter case, an incoming connection should not generate an
additional FSM.

I do not believe the concept of active and passive is helpful since a
given system can flip from one to the other and it does not help us to
clarify the number of FSM involved..

Tom Petch
[email-masked]
-----Original Message-----
From: Curtis Villamizar <[email-masked]>
To: Natale, Jonathan <[email-masked]>
Cc: [email-masked]' <[email-masked]>; Yakov Rekhter
<[email-masked]>; Alex Zinin <[email-masked]>; Abarbanel, Benjamin
<[email-masked]>; [email-masked] <[email-masked]>
Date: 26 September 2002 18:27
Subject: Re: Generial Editorial Comment

>In message
<[email-masked]
>ks.com>, "Natale, Jonathan" writes:
>> Wrong.
>>
>> " If the source IP address used
>>    by one of these connections is the same as the destination IP
address
>>    used by the other, and the destination IP address used by the
first
>>    connection is the same as the source IP address used by the
other, we
>>    refer to this situation as connection collision."
>> - draft-ietf-idr-bgp4-17
>
>You're correct in that you must have a collision of IP addresses on
>the TCP connections and that the BGP Identifier is used only to
>resolve which gets dropped.
>
>The FSM stays around as long as "BGP Identifier" is not known.
>Replace "not known with certainty" with "known but the BGP identifier
>is not known" and replace "for the same peer" with "for the same
>configured peering".
>
>The first paragraph is unchanged:
>
>   BGP must maintain separate FSM for each configured peer.  Each BGP
>   peer paired in a potential connection will atempt to connect to
the
>   other.  For the purpose of this discussions, the active or connect
>   side of a TCP connection (the side sending the first TCP SYN
packet)
>   is called outgoing.  The passive or listenning side (the sender of
>   the first SYN ACK) is called the an incoming connection.
>
>The second paragraph becomes:
>
>   A BGP implementation must connect to and listen on TCP port 179
for
>   incoming connections in addition to trying to connect to peers.
>   For each incoming connection, a state machine must be
instantiated.
>   There exists a period in which the identity of the peer on the
>   other end of an incoming connection is known but the BGP
identifier
>   is not known.  During this time, both an incoming and outgoing
>   connection for the same configured peering may exist.  This is
>   referred to as a connection collision (see Section x.x, was 6.8).
>
>The next paragraph then needs to get fixed.  Changed "for each peer"
>to "for each configured peering".
>
>   A BGP implementation will have at most one FSM for each configured
>   peering plus one FSM for each incoming TCP connection for which
the
>   peer has not yet been identified.  Each FSM corresponds to exactly
>   one TCP connection.
>
>Add a paragraph to further clarify the point you made.
>
>   There may be more than one connection between a pair of peers if
>   the connections are configured to use a different pair of IP
>   addresses.  This is referred to as multiple "configured peerings"
>   to the same peer.
>
>> So multiple simultaneous BGP connection are allowed between the
same two
>> peers, and this behavior is implemented, for example to do load
balancing.
>
>Good point.
>
>I hope the corrections above cover your (entirely valid) objections.
>If you see any more errors please let me know.
>
>Curtis
>
>
>> -----Original Message-----
>> From: Curtis Villamizar [mailto:[email-masked]]
>> Sent: Thursday, September 26, 2002 11:34 AM
>> To: Yakov Rekhter
>> Cc: Alex Zinin; Abarbanel, Benjamin; [email-masked]
>> Subject: Re: Generial Editorial Comment
>>
>>
>> In message <[email-masked]>, Yakov
Rekhter
>> writes
>> :
>> > Alex,
>> >
>> > > Defining terms like this in a separate section would be really
nice.
>> > > (BTW, I personally think using "BGP session" which works over a
"TCP
>> > > connection" would be closer to the terminology we're actually
using
>> > > now and would avoid possible confusions when people read terms
like
>> > > "Connection collision") It would also be great if we had
descriptions
>> > > for all data structures that are not explicitly defined (e.g.,
the
>> > > current spec has no notion of a peer data structure), timers,
etc.
>> > >
>> > > Two other things that I think would make sense to explicitly
>> > > define are
>> > >
>> > >    - processing of incoming TCP connections (peer lookup,
acceptance,
>> > >      FSM creation, collision control,)
>> > >
>> > >    - generation of events while processing BGP messages, i.e.,
>> > >      the text describing message processing should say where
>> > >      needed that a specific event for the BGP session should
>> > >      be generated.
>> >
>> > Please suggest the appropriate text.
>> >
>> > yakov.
>>
>>
>>
>> Yakov,
>>
>> Here is some suggestion.  I don't know where in the document you'd
>> like to put this or whether you would prefer to omit it.  That's up
to
>> you.
>>
>>   BGP must maintain separate FSM for each configured peer.  Each
BGP
>>   peer paired in a potential connection will atempt to connect to
the
>>   other.  For the purpose of this discussions, the active or
connect
>>   side of a TCP connection (the side sending the first TCP SYN
packet)
>>   is called outgoing.  The passive or listenning side (the sender
of
>>   the first SYN ACK) is called the an incoming connection.
>>
>>   A BGP implementation must connect to and listen on TCP port 179
for
>>   incoming connections in addition to trying to connect to peers.
For
>>   each incoming connection, a state machine must be instantiated.
>>   There exists a period in which the identity of the peer on the
other
>>   end of an incoming connection is not known with certainty.
During
>>   this time, both an incoming and outgoing connection for the same
>>   peer may exist.  This is referred to as a connection collision
(see
>>   Section x.x, was 6.8).
>>
>>   A BGP implementation will have at most one FSM for each peer plus
>>   one FSM for each incoming TCP connection for which the peer has
not
>>   yet been identified.  Each FSM corresponds to exactly one TCP
>>   connection.
>>
>> The above covers Alex's first request only.
>>
>> Curtis
>>

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 30 Sep 2002 10:31:45 -0400

> [email-masked]

Could this be corrected by replacing "will attempt to connect" with
"unless configured to remain in the idle state, or configured to
remain passive, will attempt to connect".  We could also shorten that
to "will attempt to connect unless configured otherwise".

Clarification (perhaps an item for a glossary entry):

  The terms active and passive have been in our vocabulary for almost
  a decade and have proven useful.  The words active and passive have
  slightly different meanings applied to a TCP connection or applied
  to a peer.  There is only one active side and one passive side to
  any one TCP connection as per the definition below.  When a BGP
  speaker is configured passive it will never attempt to connect.  If
  a BGP speaker is configured active it may end up on either the
  active or passive side of the connection that eventually gets
  established.  Once the TCP connection is completed, it doesn't
  matter which end was active and which end was passive and the only
  difference is which side of the TCP connection has port number 179.

We're going to make this a very long document if we add "unless
configured otherwise" to hundreds of places in the document just to
make it absolutely correct.  Maybe we should issue a moritorium on
"unless configured otherwise" changes.  :-)

Curtis