Re: [Idr] I-D Action: draft-ietf-idr-bgp-fwd-rr-02.txt

[Robert Raszuk <[e-mail]>]

Igor,

To hopefully put a final note here please observe that in well designed
network each ABRs will be receiving at least two paths with different next
hops. In the discussed case those will be coming via RR27 from ASBR21 and
ASBR22.

So when you lose such next hop from region-2 you:

a) have already another path via different ASBR

b) it is highly likely that any of the region-2 ASBRs going down will go
down from both ABRs in the same time.

IMO creating repair between ABRs is unnecessary. Keep in mind that NH
metric to any remote ASBRs (via any path in region-2) MUST be lower then
metric to peer ABR's next hop. This means that any local protection will
use paths from region-2 not such ABR to ABR link.

Thx a lot,
R.



On Mon, Mar 18, 2024 at 5:34 PM Igor Malyushkin <[e-mail]>
wrote:

>
>
> пн, 18 мар. 2024 г. в 20:11, Robert Raszuk <[e-mail]>:
>
>> Hi Igor,
>>
>>
>>> This is crucial to my point. The local "repair" action is really not a
>>>> repair. When you loose your sessions on primary ABR1 to region-2, or you
>>>> get withdraws etc ...) you need to re-run local (on said ABR1) best path as
>>>> there is no other trigger to simply activate bulk switchover in data plane
>>>> to suddenly go to ABR2. This is the key.
>>>>
>>> [IM] I see at least three such triggers.
>>>
>>
>> Ahhh see the crux of the matter is that none of those listed below is
>> applicable to support bulk data plane switchover to back ABR :(
>>
> [IM] Generally, all infrastructure routes have several possible next-hop
> addresses. We monitor the availability of the next hops (and LSPs to them),
> not prefixes. So, the "bulkiness" here is about our reaction to a next-hop
> failure. This next-hop is a part of many NHFLEs. But modern gear has lots
> of optimizations with pointers and so on to make it almost instant.
>
>>
>> An outgoing Region2-faced interface failure.
>>>
>>
>> When you loose interface and ABR is (and should be) connected via at
>> least two interfaces to each region your IBGP sessions are intact.
>>
> [IM] Yes, and it is always a good option to have the second interface as a
> backup. But it is the same next-hop protection technique and another layer
> in the hierarchy (upper). Modern devices have several layers of next-hops
> and can react to different failures.
>
>>
>> And even if this is single interface and you invent new harmful knob to
>> invalidate IBGP sessions when interface X goes down (this is common
>> practice on directly connected EBGP sessions only) you still have zoo of
>> prefixes received over those IBGP sessions and each may have been
>> advertised with different label.
>>
>
>> So you still need to run full best path and pick new (now backup path) on
>> a per prefix basis and install one by one in RIB/FIB/LFIB.
>>
>
>>
>>> An IGP event in Region 2 with a remote ASBR failure.
>>>
>>
>> Ok you can invalidate a remote next hop. Sure. But that means as you have
>> observed already that each route may be incoming with different label so
>> you need prefix by prefix pick alternative label and install it in
>> RIB/FIB/LFIB locally.
>>
>  [IM] Actually, this is a parallel process, we can protect our labeled
> traffic during the calculation of new bests.
>
>>
>>
>>
>>> An RSVP event of underlying Region 2's LSP failure.
>>>
>>
>> Whow ... now we see a soft state protocol through into this mix.  And
>> when an RSVP-TE LSP to remote next hop in region-2 goes down you want to
>> consider this a trigger to invalidate given next hop ? Ok but we are back
>> to #2 above. Still one by one ...
>>
> [IM] Sure! Most of the modern SP-ready devices react on an LSP failure.
> Once I tested an IOS device and it didn't react on an LSP failure at all
> because it had a route toward an NH. Horrible...
>
>>
>>
>>> All of them describe some group of prefixes and can influence the
>>> switchover to their backups.
>>>
>>
>> That would be true for vanilla IPv4/\Pv6 SAFI 1. Not for SAFI 4 or SAFI
>> 76.
>>
> [IM] I didn't get it, sorry.
>
>>
>> Cheers,
>> R.
>>
>>