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

[Igor Malyushkin <[e-mail]>]

пн, 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.
>
>