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

[Igor Malyushkin <[e-mail]>]

Hi Robert,

I was discussing a more general view on the protection topic. Imagine, you
have a ladder topology (i.e., a square in a region, RFC5439, Figure 5 as
the example) and ABRs have their path to only a directly connected ASBR.
Such topologies are not rare, especially in SP cores. Probably, there are
other examples, but I have none by hand at the moment.

Another point is we aren't talking about some potential solution, many
network equipment already have this shipped. Whether to use it or not is a
decision for a network designer. This is everything that I wanted to state
at the very beginning.

Speaking of the topology from the draft, if ABR23 has a path via P29, it
should have more priority as a protection path because of the metrics. I
agree with you, if we do not account for a double failure (which is rare
for planning teams in my experience), we do not need a protection path
between ABRs.


пн, 18 мар. 2024 г. в 23:35, 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.
>>>
>>>