Re: [Idr] New Draft Notification draft-dickson-idr-last-resort

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Fri, 13 June 2008 06:41 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A09F63A68C0; Thu, 12 Jun 2008 23:41:47 -0700 (PDT)
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 83A6B3A69E0 for <idr@core3.amsl.com>; Thu, 12 Jun 2008 23:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 m1UZWMFvBT-c for <idr@core3.amsl.com>; Thu, 12 Jun 2008 23:41:45 -0700 (PDT)
Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 93B093A68C0 for <idr@ietf.org>; Thu, 12 Jun 2008 23:41:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=wNDUjEp4bv/nBKCg/hNOlDI6z5c=; b=httCiSgCNS sDKel4zJLkVbajxtvY5TyYrziOlS4WcRyDRinSLCbUm/KhzmDNcVKyToWHAkaT8G 57ACK1zMPvKMkrUM8g510jUcQw3HMW6oMZ5IiQirOCMqtfjSrKB6L0SeAsZ2elDd TqIlNaapPTxK0UtIn1lfvDAdL0iPEMqBE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=zgxun 5/jWCWUEekg3pdocn3H0GtPw+rZeT5Iy+/nlBI5OOUuZGYiPlkixRA/mz2RIyqGR fO79FE8z1UQlPgMX2IJ96atqx0HKCSZmNl7PpHMeJMDxxOuG5lQShHRoIr+qVIVs voSfC8ABUombCay/URJQW5ak0xiCe8NIZyMcx4=
Received: from mbpobo.local (ip-83-134-192-103.dsl.scarlet.be [83.134.192.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Fri, 13 Jun 2008 08:42:00 +0200 (CEST)
Message-ID: <485216B3.9040501@uclouvain.be>
Date: Fri, 13 Jun 2008 08:41:55 +0200
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Brian Dickson <briand@ca.afilias.info>
References: <alpine.LRH.1.10.0806091642180.32755@tor.hrz.tu-chemnitz.de> <4850A71E.9040201@ca.afilias.info> <4850A95E.10008@ca.afilias.info> <48516A79.6030709@ca.afilias.info> <48516E77.5030906@uclouvain.be> <48517445.9090809@ca.afilias.info>
In-Reply-To: <48517445.9090809@ca.afilias.info>
X-Enigmail-Version: 0.95.6
X-AV-Checked: ClamAV using ClamSMTP
X-Sgsi-Spamcheck: SASL authenticated,
X-MailScanner-ID: 5975A1C6E05.BB0DB
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Cc: idr@ietf.org
Subject: Re: [Idr] New Draft Notification draft-dickson-idr-last-resort
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Olivier.Bonaventure@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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Brian,
> 
> In all cases, a router will only announce a prefix if it is locally 
> selected as "best". LAST_RESORT affects local selection, but does not 
> change what happens once local selection is complete.
> 
> If after this explanation, you still believe a condition can exist where 
> a permanent routing loop would occur, please walk me through a specific 
> example, as I think that would be the best way to identify what leads 
> the the loop.

The problem occurs inside iBGP. For example, consider the following AS

NU1 ----1-----U1----1----NU2------100-----U2

NU1 and U2 are border routers that receive an eBGP path with same AS 
Path length, same MED, ... but NU1 receives the path with LAST_RESORT 
while U2's path does not contain LAST_RESORT. The number on the links 
indicate the IGP cost

NU1 and NU2 do not understand LAST_RESORT while U1 and U2 understand it.
There is an iBGP full mesh.

NU1 accepts the path and places it inside its FIB. Same for U2.

U1 understands LAST_RESORT and thus selects U2 as its BGP nexthop.
NU2 does not understand LAST_RESORT and thus selects NU1 as its BGP 
nexthop. There is a forwarding loop between U1 and NU2. This loop did 
not exist before the introduction of LAST_RESORT


Olivier


-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr