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

"Griffin, Tim" <tim.griffin@intel.com> Thu, 23 September 2004 07:40 UTC

Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19268 for <grow-archive@lists.ietf.org>; Thu, 23 Sep 2004 03:40:22 -0400 (EDT)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i8N7ZSQK009269; Thu, 23 Sep 2004 00:35:28 -0700 (PDT)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i8N7ZSID009268; Thu, 23 Sep 2004 00:35:28 -0700 (PDT)
Received: from petasus.isw.intel.com (petasus.isw.intel.com [192.55.37.196]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i8N7ZQas009234 for <grow@lists.uoregon.edu>; Thu, 23 Sep 2004 00:35:27 -0700 (PDT)
Received: from swsmsxvs01.isw.intel.com (swsmsxvs01.isw.intel.com [172.28.130.22]) by petasus.isw.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.9 2004/01/09 01:01:53 root Exp $) with SMTP id i8N7ZM0Z011093; Thu, 23 Sep 2004 07:35:25 GMT
Received: from swsmsx331.ger.corp.intel.com ([172.28.130.50]) by swsmsxvs01.isw.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004092308345802885 ; Thu, 23 Sep 2004 08:34:58 +0100
Received: from swsmsx403.ger.corp.intel.com ([172.28.130.36]) by swsmsx331.ger.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Sep 2004 08:34:59 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: grow: draft-griffin-bgp-wedgies-00.txt as a WG document?
Date: Thu, 23 Sep 2004 08:34:18 +0100
Message-ID: <D36E65D7939490448D2BB44EECF479D80DC965@swsmsx403.ger.corp.intel.com>
Thread-Topic: grow: draft-griffin-bgp-wedgies-00.txt as a WG document?
Thread-Index: AcShMsZx3eWpRS7ZR8yeYoicoAT61AAC65Jg
From: "Griffin, Tim" <tim.griffin@intel.com>
To: Pekka Savola <pekkas@netcore.fi>, David Meyer <dmm@1-4-5.net>
Cc: grow@lists.uoregon.edu, gih@apnic.net
X-OriginalArrivalTime: 23 Sep 2004 07:34:59.0117 (UTC) FILETIME=[D45E2DD0:01C4A13F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by darkwing.uoregon.edu id i8N7ZRas009260
Sender: owner-grow@lists.uoregon.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Pekka, 

Thanks for your helpful comments. 

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

I see it primarily as an informational "awareness raising" document --- 
Hopefully it will stimulate discussion, perhaps driven by more examples,

of what mitigations techniques might help. 


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

Yes, we could make that more clear --- the routing policies allow two
distinct
stable routings, and how we fall into one or the other has to do with
history
(exactly the kind of thing we want to avoid if we ever hope to debug
problems!). 

---tim


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