Subject: Generial Editorial Comment

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 20 Sep 2002 16:18:12 -0400

I have some general editorial comments.

1. Throughout the document we have various ways of naming the BGP
   peering communication. 1) BGP Session, 2) BGP Peering Session, 3) TCP   
   Connection, 4) BGP Connection, 5) BGP Peering Connection, 6) Connection, 
   7) BGP Speaker Connection. 

   BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

2. Change Internal peer to IBGP Peer.

3. Change External peer to EBGP Peer.

I know this is nits, but it maintains a clear consistency in the content.

Thanks,
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 3:39 PM
> To: Michael C. Cambria
> Cc: [email-masked]
> Subject: Re: -17 review Section 6 - BGP Error Handling. 
> 
> 
> Mike,
> 
> > Hi,
> > 
> > At the beginning of Section 6. BGP Error Handling:
> > 
> > 
> >     "When any of the conditions described here are detected, a
> >     NOTIFICATION message with the indicated Error Code, 
> Error Subcode,
> >     and Data fields is sent, and the BGP connection is closed."
> > 
> > There are several cases where the conditions described in 
> this section 
> > do not result in the BGP connection being closed.  These conditions 
> > should either state that the connection stays up.  Another 
> possibility 
> > is to remove "and the BGP connection is closed." above, and 
> for each 
> > listed connection, state what happens to the BGP connection.  This 
> > already takes place for certain conditions, but isn't done 
> consistantly.
> 
> How about replacing the above with the following:
> 
>    When any of the conditions described here are detected, a 
> NOTIFICATION
>    message with the indicated Error Code, Error Subcode, and Data
>    fields is sent, and the BGP connection is closed, unless it is
>    explicitly stated that no NOTIFICATION message is to be sent and
>    the BGP connection is not to be close. 
> > 
> > 
> > I tried to list what I found (which may be wrong or 
> incomplete) below:
> > 
> > 
> > 
> > "If the NEXT_HOP attribute is semantically incorrect, the 
> error should 
> > be logged, and the route should be ignored. In this case, no 
> > NOTIFICATION message should be sent."
> > 
> > * Append the connection is not closed.
> 
> Done.
> 
> > 
> > "(a) discard new address prefixes from the neighbor, or (b) 
> terminate 
> > the BGP peering with the neighbor."
> > 
> > * Append "the connection is not closed" to case (a)
> 
> added "(while maintaining BGP peering with the neighbor)" to case (a).
> 
> > 
> >     "If
> >     the autonomous system number appears in the AS path the 
> route may be
> >     stored in the Adj-RIB-In,"
> > 
> > * append and the BGP connection stays up.
> > 
> >                                 "but unless the router is 
> configured to
> >     accept routes with its own autonomous system in the AS path, the
> >     route shall not be passed to the BGP Decision Process."
> 
> I would suggest to move this text to Section 9 (UPDATE 
> message handling),
> as receiving a route with your own AS in the AS path isn't really
> an error. It is just that usually (but not always) you can't put
> this route in your Adj-RIB-In. 
> 
> > 
> > * Q1) does the BGP connection stay up?
> 
> yes.
> 
> > * Q2) what if the router isn't configured to accept routes 
> with its own 
> > AS in the AS path?  One _may_ store the route in 
> Adj-RIB-In, but if one 
> > doesn't want to?  
> 
> So, don't store them.
> 
> > Is the BGP connection closed?  If so, what subcode?
> 
> The connection is *not* closed.
> 
> >     "If an optional attribute is recognized, then the value of this
> >     attribute is checked. If an error is detected, the attribute is
> >     discarded, and the Error Subcode is set to Optional 
> Attribute Error.
> >     The Data field contains the attribute (type, length and value)."
> > 
> > * Append and the BGP conneciton stays up after "the 
> attribute is discarded".
> 
> Since you have to close the connection, you have to discard all the
> routes received via this connection, including the route with the
> incorrect attribute. So, there is no need to say that "the attribute
> is discarded".
> 
> Yakov.
>

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 20 Sep 2002 14:18:27 -0700

Ben,

>    peering communication. 1) BGP Session, 2) BGP Peering Session, 

I'll replace "session" with "connection". 

>    3) TCP Connection, 

The spec doesn't name BGP peering communication as "TCP connection";
TCP connection is used to establish BGP connection. So, TCP connection
and BGP connection are two different things.

>    4) BGP Connection, 

The spec is going to use this term (see above).

>                  5) BGP Peering Connection, 

I'll replace "BGP peering connection" with "BGP connection".

> 6) Connection, 

The text uses "connection" whenever it is clear from the context
that it refers to "BGP connection" (or "TCP connection").

>    7) BGP Speaker Connection. 

I'll replace "BGP Speaker Connection" with "BGP connection".

>    BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

The term "speaker" is used when it is clear from the context that
we are talking about "BGP speaker".

> 2. Change Internal peer to IBGP Peer.

IBGP stands for "BGP connection between internal peers". Therefore
the term "IBGP Peer" would mean "BGP connection between internal
peers peer".  That doesn't seem appropriate. 

> 3. Change External peer to EBGP Peer.

Ditto.

yakov.

---

From: Alex Zinin <[email-masked]>
Date: Fri, 20 Sep 2002 15:11:55 -0700

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.
 
Thanks.

-- 
Alex

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 22 Sep 2002 18:09:28 -0700

Alex,

>      needed that a specific event for the BGP session should

Please suggest the appropriate text.

yakov.

---

From: Alex Zinin <[email-masked]>
Date: Mon, 23 Sep 2002 11:31:19 -0700

Yakov,

[...]
> Please suggest the appropriate text.

Please see if document editors can use the contents of the message I
sent months ago to initiate the discussion:

> Date: Thu, 17 Jan 2002 17:44:11 -0800
> From: Alex Zinin <[email-masked]>
> Message-ID: <[email-masked]>
> To: [email-masked]
> Subject: More thoughts on FSM

BTW, it also has a draft of the FSM state diagram, which I also think
would be quite useful.

Alex

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 26 Sep 2002 11:33:41 -0400

In message <[email-masked]>, Yakov Rekhter writes

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