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

[Pekka Savola <[e-mail]>]

On Mon, 13 Sep 2004, David Meyer wrote:
> 	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.

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

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