Subject: BGP Base Draft - Issue List v1.4

From: [email-masked]
Date: Tue, 22 Oct 2002 19:02:19 -0700

Hello all,

This is the 1.4 edition of the issues document.  Since the 1.3 edition
we have:  

 Added 1 issue.
 Added a list of to-do documents (Appendix A)
 Updated 10 issues.
 Moved the same 10 issues to consensus.

We have only 8 issues outstanding, and we're close on some of them.  Time
to take a deep breath and plow on through, we're almost there!
 
Andrew

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 10:34:43 -0400

On Tue, Oct 22, 2002 at 07:02:19PM -0700, [email-masked] wrote:
> Status: No Consensus
> Change: Potentially
> Summary: IFF we have two implementations, we'd consider including this in
>   the base spec.
>  
> Discussion:
> 
> Jonathan brought up that:
> 
> This paper (thanks Jeff)

Since my name is brought up, I thought I'd offer an opinion. :-)

> http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
> indicates that it
> is better to do the loop detection outbound as well inbound.  The current
> draft indicates that
> it only needs to be done inbound.  IOS does it inbound as well as outbound.
> GateD/Juniper
> does it (did it ???) only inbound.
> 
> So I propose we add:
> "An implementation MAY choose to not advertise routes to EBGP peers if these
> routes contain
> the AS of that peer in the AS path."
> after:
> "If the autonomous system number appears in the AS path the route may be
> stored in the
> Adj-RIB In, but unless the router is configured to accept routes with its
> own AS in the
> AS path, the route shall not be passed to the BGP Decision Process."
> 
> *If there is at least one other implementation that does outbound
> pruning/loop-detection.*

My suggestion is that this can stay out of the base draft.  While it
is true that this speeds up convergence (per the paper), it doesn't
affect interoperability.

Also, adding this specifically removes the ability from several 
implementations to be able to bridge a partitioned AS by permitting
loops.  (I'm not going to argue whether this is a Good way to do this,
just that its done.)

Its also worth noting that one could produce the same resultant speed-up
by detecting the loop on an outbound basis and *not* applying the
min*timers to the UPDATE.  Thus, this would be a case of an advertisement
of NLRI being treated the same, timer-wise, as the advertisement of
WD_NLRI.

I would suggest moving this suggestion for outbound loop detection
in one form or another to the 1772 replacement.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 10:42:41 -0400

> ----------------------------------------------------------------------------
> 32) Clarify EGP Reference
> ----------------------------------------------------------------------------

I'd like to propose that all of the issues here have been addressed
by 32.1 and we close this one.

If others disagree, could you note what your perception of remaining
issues are?

-- Jeff

---

From: David Barak <[email-masked]>
Date: Wed, 23 Oct 2002 10:47:43 -0400 (EDT)

agreed.

David Barak
WorldCom
Voice: +1-703-886-5500
Fax: +1-703-886-0541

"Quis custodes ipsos custodiet?" - Juvenal
=====   Fully RFC 1925 compliant   =====

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 10:47:26 -0400

> I would rephrase the paragraph as follows =>
> 
>   "The local speaker SHALL then install that route in the Loc-RIB,
>    replacing any route to the same destination that is currently being
>    held in the Loc-RIB. When the new BGP route is installed in the Routing
>    Table, care must be taken to ensure that existing routes to the same
>    destination that are now considered invalid are removed from the
>    Routing Table. Whether or not the new BGP route replaces an existing
>    non-BGP route in the routing table depends on the policy configured
>    on the BGP speaker."

With the exception that Routing Table should be capitalized throughout,
I'd suggest we take this as consensus.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 10:53:37 -0400

> Curtis later proposed this text:

Most of which I'm in violent agreement with. :-)

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

Its important to note that BGP Identifier is only important if the
rest of the Open is valid.  For example, we must first get past
AS number, hold time values, capabilities, etc.

> The FSM stays around as long as "BGP Identifier" is not known.

Or may be immediately aborted if the rest of the OPEN is rejected.

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 23 Oct 2002 07:54:29 -0700

Jeff,

> I'd suggest we take this as consensus.

Agreed.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 23 Oct 2002 07:55:10 -0700

Jeff,

> > ---------------------------------------------------------------------------

Agreed.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 23 Oct 2002 07:56:04 -0700

Jeff,

> > http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-0
> > indicates that it

Agreed.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 10:56:04 -0400

> 39) Redundant Sentance Fragments
> Summary: Redundant definitions, clarity requested.  Possible solution below.
> 
> Discussion:
> 
> 5. P. 50, section 9.1.4, The two fragments of this sentence are redundant
> and don't say anything new or simplify the content. Just keep one fragment.
> 
> "A route describing a smaller set of destinations (a longer prefix) is said
> to be more specific than a route describing a larger set of destinations (a
> shorted prefix); similarly, a route describing a larger set of destinations
> (a shorter prefix) is said to be less specific than a route describing a
> smaller set of destinations (a longer prefix)."
> 
> There was a comment that disagreed, thinking that both "more specific"
> and "less specific" need to be defined.	 And suggested that only the
> third and forth parentheses need to be dropped.
> 
> The original commentor agreed with the parentheses changes.
> 
> Yakov agreed to drop the third and fourth parentheses in the -18 version.
> 
> Jonathan replied to this:
> 
> Disagree, the text if fine the way it is, except you need to change
> "shorted" to "shorter".

This sounds like consensus to me - especially if we're quibbling about
a typo. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 11:06:29 -0400

> 45) Consistant References to BGP Peers/Connections/Sessions

In general, the cleanup is appropriate.  The only change would
be agreeing with Alex:

> "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") 

Thus, consistantly use "BGP session".

Aside from converging on this point, I think we have reached consensus.

Are there arguments to keep this "BGP connection"?

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 11:15:11 -0400

> 46) FSM Connection Collision Detection
> Summary: We need to decide which text (the original base draft, or the FSM
>   draft) needs to be updated to clear up this issue.  There does appear to
>   be agreement that some clarification would be beneficial.
> 
> Discussion:
> 
> The original reviewer (Tom) commented that the base draft, FSM section, could
> use some clarification around the area of connection collision detection.
> Specifically, he argued that it seems like there are actually 2 FSM's
> depending on which one backs off in the case of a collision.  He 
> proposed this text to clear things up:
> 
> "8 BGP FInite State Machine  
> 
> This section specifies BGP operation - between a BGP speaker and its
> peer over a single TCP connection - in terms of a Finite State Machine
> (FSM).  Following is a brief summary ... "(as before)
>  
> Instead of just
> 
> "This section specifies BGP operation in terms of a Finite State
> Machine (FSM).  Following is a brief summary ... "(as before).  
> 
> Curtis responded:
> 
>    There is one FSM per connection.  Prior to determining what peer a
>    connection is associated with there may be two connections for a
>    given peer.  There should be no more than one connection per peer.
>    The collision detection identifies the case where there is more
>    than one connection per peer and provides guidance for which
>    connection to get rid of.  When this occurs, the corresponding FSM
>    for the connection that is closed should be disposed of.
> 
> I'm not sure which document containing an FSM we should be reading at
> this point, but we could add the above paragraph if we need to
> explicitly state that the extra connection and its FSM is disposed of
> when a collision is detected.
> 
> When a TCP accept occurs, a connection is created and an FSM is
> created.  Prior to the point where the peer associated with the
> connection is known the FSM cannot be associated with a peer.  The
> collision is a transient condition in which the rule of "one BGP
> session per peer" is temporarily violated and then corrected.

With the additional FSM text contained in issue 48, I think we're
mostly good here.  However, given the complexity of the issue
(where is the current text - which is the canonical version, etc.)
I would like to see the text in a complete form before suggesting
we declare consensus on this.

Yakov - what is the hope of getting a -18 candidate posted including
all consensus changes for review?

-- Jeff

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 23 Oct 2002 08:17:56 -0700

Jeff,

> Are there arguments to keep this "BGP connection"?

If we are to use "BGP session" instead of "BGP connection", we
would talk about "Session collision" not "connection collision".

I would prefer to use "BGP connection".

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 23 Oct 2002 08:20:57 -0700

Jeff,

> > Summary: Redundant definitions, clarity requested.  Possible solution below
> > 
> > Discussion:
> > 

Yes, indeed we have a consesus - fix the typo and drop the third and 
fourth parentheses.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 23 Oct 2002 11:26:18 -0400

Yakov,

> I would prefer to use "BGP connection".

I can see that.

A stronger argument is perhaps the fact that our notification messages
have always said "connection not synchronized".  Given that implementors
have often used the words from this text in their CLI/GUI/SNMP
implementation, its probably best to stay with "connection".

I yield to your argument. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 29 Oct 2002 11:15:02 -0500

> Or may be immediately aborted if the rest of the OPEN is rejected.

To be strictly correct the sentence could be changed to read "The FSM
stays around as long as the BGP session and TCP connection are not
rejected for other reasons and the 'BGP Identifier' is not known."

I don't think this needs to be added since it would seem, at least to
me, clear that a FSM would not be retained for a closed TCP connection
regardless of the reason it was closed, on FIN/ACK completion,
reception of CEASE, OPEN message rejection, or any other reason.

Curtis