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

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

Brian

> 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
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr