Subject: RE: Generial Editorial Comment

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 26 Sep 2002 12:11:55 -0400

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

So multiple simultaneous BGP connection are allowed between the same two
peers, and this behavior is implemented, for example to do load balancing.

-----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: Thu, 26 Sep 2002 13:27:21 -0400

In message <[email-masked]
>    refer to this situation as connection collision."

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:

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.

> 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