Subject: Re: Generial Editorial Comment

From: "Tom Petch" <[email-masked]>
Date: Mon, 7 Oct 2002 16:33:11 +0100

Yes, I like the change from
"will attempt to connect" with

 "will attempt to connect unless configured otherwise".

I don't like the active/passive; we have active already defined as
part of the FSM (Aug02 version)
" In this state BGP is trying to acquire a peer by listening
 for and accepting a transport protocol connection"
and I think this goes far enough.

Tom Petch
-----Original Message-----
From: Curtis Villamizar <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked] <[email-masked]>; Yakov Rekhter
<[email-masked]>;  idr <[email-masked]>
Date: 30 September 2002 15:31
Subject: Re: Generial Editorial Comment

>
>I 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]
>
>
>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
>
>
>> -----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
>> >>
>>
>>
>>