[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at ietf.org
https://www.ietf.org/mailman/listinfo/idr