Subject: grow: draft-griffin-bgp-wedgies-00.txt as a WG document?

From: David Meyer <[email-masked]>
Date: Mon, 13 Sep 2004 08:01:12 -0700

Folks,

	Please take a look at draft-griffin-bgp-wedgies-00.txt. I
	would like to get a sense of how people feel about this
	document at a (GROW) WG document.

	Thanks,

	Dave

_________________________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/grow.html
web archive:        http://darkwing.uoregon.edu/~llynch/grow/

---

From: David Meyer <[email-masked]>
Date: Mon, 13 Sep 2004 09:37:20 -0700

>> I read it and found it very interesting and appropriate for the GROW WG.

	Thanks Thomas.

	Dave

>> 
>> 
>> Thomas
>> 
>> At 17:01 2004-09-13, David Meyer wrote:
>> >        Folks,
>> >

---

From: Thomas Eriksson <[email-masked]>
Date: Mon, 13 Sep 2004 18:29:51 +0200

Thomas

---

From: David Meyer <[email-masked]>
Date: Mon, 13 Sep 2004 12:46:12 -0700

On Mon, Sep 13, 2004 at 01:25:45PM -0600, Danny McPherson wrote:
>> 
>> On Sep 13, 2004, at 9:01 AM, David Meyer wrote:
>> 
>> >	Folks,
>> >
>> I think it fits and is generally useful information as
>> well.

Thanks Danny.

Dave

---

From: David Meyer <[email-masked]>
Date: Tue, 14 Sep 2004 07:47:03 -0700

On Wed, Sep 15, 2004 at 12:42:16AM +1000, Geoff Huston wrote:
>> At 01:01 AM 14/09/2004, David Meyer wrote:
>> >        Folks,
>> >
>> As an additional note here, I suggested this to Dave as it appears to fit 
>> within goal (ii) of the GROW charter:
>> 
>> (ii). Document and suggest operational solutions to problematic
>>            aspects of the currently deployed routing
>>            system. Examples include instability caused by
>>            oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345)
>>            values.

Precisely. 

Thahnks,

Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Sep 2004 09:54:48 -0400

Dave,

> 	document at a (GROW) WG document.

This is a useful first pass at documenting some BGP system convergence
issues.  This seems to fit within the charter of the WG.

A random comment on the draft (presuming both of the authors are
on the WG mailing list):

A given BGP implementation should be deterministic at the routing level.
However, as this document notes, it isn't deterministic at the system
level.  The draft notes one form of temporal determinism and specifically
notes the "choose oldest route" step in the BGP tie breaking process.
However, it is possible to cause system level temporal determinism
stopping at the router-id stage.

-- 
Jeff Haas 
NextHop Technologies

---

From: David Meyer <[email-masked]>
Date: Wed, 15 Sep 2004 06:57:31 -0700

>> stopping at the router-id stage.

	Jeff,

	Thanks for the comments.

	Dave

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Sep 2004 10:16:33 -0400

Minor correction:

> A given BGP implementation should be deterministic at the routing level.

This should read "router level".

Need more coffee...

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 09:01:03 +0300 (EEST)

> 	document at a (GROW) WG document.

Seems like a good idea.

Some quick comments on the draft:

substantial
-----------

- is this intended as a "problem statement", or should this also 
include some discussion as to the ways to avoid these problems?  I 
think it would be important to discuss some mitigation techniques at 
least somewhere...

- isn't there already a race-condition, leading to a potential wedgie, 
when first advertising the prefixes?  That is, in:

   In this case AS1 has marked its advertisement of prefixes to AS2 as
   "backup only", and its advertisement of prefixes to AS4 as "primary".
   AS3 will hear AS4's advertisement across the peering link, and pick
   of AS1's prefixes with the path "AS4, AS1".  AS3 will advertise this
   to AS2.  AS2 will hear two paths to AS1, the first is by the direct
   connection to AS1, and the second is via the path "AS3, AS4, AS1".
   AS2 will prefer the longer path as the directly connected routes are
   marked "backup only", and AS2's local preference decision will prefer
   the AS3 advertisement over the AS1 advertisement.

.. here, we are assuming that the "primary" link/router has been
brought up first, yes?  For example, after a site-wide blackout [or
just software maintenance of the primary router, though that is
already included in 'path is broken'), it could be that the BGP
advertisement through the backup path is fastest to propagate to AS3,
leading to a similar wedgie, right?

Or, when you set up the multihomed site, you'll first have to 
configure the primary path, and only then the backup path, otherwise 
the backup path will be wedged, right?

(note here: the next paragraph says "if AS1 AS4 path is broken" --
this is a bit vague, perhaps on purpose: as seen above, this is not
just about link failure, but also an issue with the boxes in each
end.. perhaps this should be spelled out a bit more)

editorial
---------

- the sections should be split to appropriately-sized subsections 
(e.g., introduction and the two different issues in section 2) -- 
this would make it easier to follow the train of throught.

- BGP spec (at least) needs to be normatively referenced.

- one might want to put in a reference to RFC3345 on MED oscillations 
as well, but that might be a bit of a farther fetch.

- security considerations section is missing.

- there are two instances of non-ascii chars at the end of sect 6, 
final paragraph.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings