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

Brian Dickson <> Fri, 13 June 2008 17:13 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 62EA53A6816; Fri, 13 Jun 2008 10:13:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7BA83A63D3 for <>; Fri, 13 Jun 2008 10:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.361
X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f0-6s3kxwAIk for <>; Fri, 13 Jun 2008 10:13:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0BEA63A6816 for <>; Fri, 13 Jun 2008 10:13:56 -0700 (PDT)
Received: from ([]) by with esmtp (Exim 4.22) id 1K7Cr6-00024R-EQ; Fri, 13 Jun 2008 13:14:28 -0400
Message-ID: <>
Date: Fri, 13 Jun 2008 13:14:13 -0400
From: Brian Dickson <>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Subject: Re: [Idr] New Draft Notification draft-dickson-idr-last-resort
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Olivier Bonaventure wrote:
> 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

Ah, yes, thanks. Good example, it makes it very clear.

My original gut instinct was for the LOCAL_PREFERENCE mechanism. I went 
with the change in path selection because I didn't want to be overly 
restrictive towards implementers.

I see my original instinct was right. :-)

I'll update the draft and post it shortly.

Thanks again for your input, I think the resulting draft is much cleaner 


> 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

Idr mailing list