Re: [Idr] draft-walton-bgp-route-oscillation-stop as an IDR WG document

Pierre Francois <pierre.francois@uclouvain.be> Wed, 26 May 2010 08:32 UTC

Return-Path: <pierre.francois@uclouvain.be>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DCE3A67AF for <idr@core3.amsl.com>; Wed, 26 May 2010 01:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTCRmjh0aQgS for <idr@core3.amsl.com>; Wed, 26 May 2010 01:32:39 -0700 (PDT)
Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 53DAE3A67BD for <idr@ietf.org>; Wed, 26 May 2010 01:32:39 -0700 (PDT)
Received: from nukuhiva.dhcp.info.ucl.ac.be (nukuhiva.dhcp.info.ucl.ac.be [130.104.228.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pifrancois@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A125CF29B9; Wed, 26 May 2010 10:31:04 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 smtp4.sgsi.ucl.ac.be A125CF29B9
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1274862664; bh=91zJd1aq2YZfCVHIz66jIcS7eDNuL85TZjdtCzuhnKQ=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=vDFeInULwMNw2r83cJbWBF4L44cQxdNbcZYwNxBZ4SMZI5RFONAh5XAhkuoAKlCA5 k8Mqr796burN4LcuRL3b862gFC01tndoXeDT22T5lvgAaBA8VvbrARJmGUxzIzA7LP k6u8fTgpodnZrkuVSvql2Uvt/96eXAF0Ts8/TDro=
Message-ID: <4BFCDC47.4070206@uclouvain.be>
Date: Wed, 26 May 2010 10:31:03 +0200
From: Pierre Francois <pierre.francois@uclouvain.be>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: John Scudder <jgs@juniper.net>
References: <922D86C4-1ABD-4DE7-A7BE-4B1B85AAF6F2@juniper.net>
In-Reply-To: <922D86C4-1ABD-4DE7-A7BE-4B1B85AAF6F2@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96-exp at smtp-4.sipr-dc.ucl.ac.be
X-Virus-Status: Clean
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: A125CF29B9.00000
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: pierre.francois@uclouvain.be
X-SGSI-Spam-Status: No
Cc: Inter-Domain Routing List <idr@ietf.org>
Subject: Re: [Idr] draft-walton-bgp-route-oscillation-stop as an IDR WG document
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: pierre.francois@uclouvain.be
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 08:32:41 -0000

Hi,

There comes a few comments/questions on the draft.


A. Configuration workarounds

In the deployment considerations section, it is stated that simple
configuration workarounds will do the job, once the route oscillations
are detected. It might be interested to list them.
Could you confirm that what you had in mind is the following :

Let's say that we have a set of prefixes for which we have routing oscillations.

The procedure is

0. Detect (assumed solved) the oscillating prefixes.

1. Write a prefix list containing them

2. Reconfigure all the RRs in the AS to now apply AS Group Best for
the prefixes in the list.

then, optionally,

3. Fix the root cause of the oscillation.

4. Reconfigure all the RRs to no longer apply AS Group Best for the
prefix list.

During step 2 (and optional step 4), transiently, some RRs will have been
reconfigured to do AS Group Best, and some not. It might be
interesting to state in the draft that this transient use of different
add-path modes does not put the network into more trouble than what it
is facing.

It might also be interesting to state that fixing the root cause of
the oscillation (if in the plan of operations) typically takes much more time 
than completing steps 1 and 2.

If this is not the case, maybe operators will consider that

- only doing steps 0 and 3 is the way to go...

or

- always apply AS Group Best path propagation, be there an oscillation
   or not, is the way to go. If the additional control-plane state and
   state update is not an issue, this is much easier than the re-active
   approach.


B. Discussing the number of additional paths propagated.

I read "The number of the neighbor-AS's for a particular address
prefix is typically small because of the limited number of upstream
providers for a customer [...]"

Isn't this statement assuming that we are in the context of an ISP
dealing with MED oscillations with MED-tweaked paths received from a provider ?

I would have bet that MED is typically used the other way round, hence
the ISP gets oscillations due to MED tweaking by its customer.

In which case the statement would become "The number of neighbor AS's
for a particular address prefix is typically small because of the
limited number of customer ASes providing a path to a given prefix ?"

In which case this statement might need to be backed up with data
showing that large Tiers do not have a lot of neighboring customer
ASes providing a path to a given prefix to which the same loc-pref is
applied and which have the same shortest AS path length.  This is less
intuitive than the other way round.

[...] "and the nature of advertising only customer routes at the
inter-exchange points."

What do you exactly mean with this ?

Is it that the number of paths received from peers is small so if
there is MED oscillation on peer paths, it won't be on a lot of paths so that
Group best will not let many additional paths be propagated in that scenario ?
?

The fact that we're only talking about control-plane state increase
should be stressed. More paths, yes, but not more entries in the
FIB.

Regards,

Pierre.


John Scudder wrote:
> Folks,
> 
> We have received a request to adopt draft-walton-bgp-route-oscillation-stop as an IDR working group document.  Please send comments to the list.  The deadline for comments is May 25, 2010.
> 
> --John
> 
> -------- 
> Subject:	I-D Action:draft-walton-bgp-route-oscillation-stop-03.txt
> Date:	Mon, 10 May 2010 11:30:02 -0700 (PDT)
> From:	Internet-Drafts@ietf.org
> Reply-To:	internet-drafts@ietf.org
> To:	i-d-announce@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : BGP Persistent Route Oscillation Solutions
> 	Author(s)       : D. Walton, et al.
> 	Filename        : draft-walton-bgp-route-oscillation-stop-03.txt
> 	Pages           : 9
> 	Date            : 2010-05-10
> 
> In this document we present two sets of paths for an address prefix
> that can be advertised by a BGP route reflector or confederation ASBR
> to eliminate the MED-induced route oscillations in a network.  The
> first set involves all the available paths, and would achieve the
> same routing consistency as the full IBGP mesh.  The second set,
> which is a subset of the first one, involves the neighbor-AS based
> Group Best Paths, and would be sufficient to eliminate the MED-
> induced route oscillations (subject to certain commonly adopted
> topological constrains).
> 
> A URL for this Internet-Draft is:
> 
> http://www.ietf.org/internet-drafts/draft-walton-bgp-route-oscillation-stop-03.txt
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> 
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>