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

[Igor Malyushkin <[e-mail]>]

пн, 18 мар. 2024 г. в 19:30, Robert Raszuk <[e-mail]>:

>
>
>> When you are doing next hop self you are setting it to a local loopback
>>> address. That is your connected route. That next hop will be accessible to
>>> peering ABR via implicit or explicit null.
>>>
>> [IM] It's not necessary to advertise our loopback address as a labeled
>> route or even by BGP (we can disseminate it via IGP). When we receive a BGP
>> LU route there must be an unicast route to resolve its NH and an LSP toward
>> this NH to resolve a label.
>>
>
> I did not say it will be advertised by BGP for resolution. I said this
> Next Hop is going to sit in BGP UPDATEs and will be use in best path
> selection when comparing metrics with other next hops.
>
[IM] Ok. I agree and I still think that this document is a try to enumerate
some of the problems of that type and offer some remedies.

>
> a) we do not know which prefixes and labels going to region-2 got affected
>>> till we run best path on them
>>>
>> [IM] I do not understand this point. With the per-prefix label allocation
>> mode, we know it exactly in advance. This mode's name implies that.
>>
>
> 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. An outgoing Region2-faced
interface failure. An IGP event in Region 2 with a remote ASBR failure. An
RSVP event of underlying Region 2's LSP failure. All of them describe some
group of prefixes and can influence the switchover to their backups. I
mean, there is enough information for a node to act accordingly. The
problem here is that we are not always sure (without any special
intervention) that these backups produce a different path (not affected by
the event). But there is always a compromise.

It does not matter that you got those ABR2 backup routes/paths and labels
> ahead of time. At the time of failure of your IBGP peers to region-2 you
> still need local per prefix or at least per label.
>
[IM] As I said this is not the only type of failure.

>
> My point is that this entire sentence in the draft sort of warning users
> from configuring on subject ABRs same CLUSTER_ID is irrelevant considering
> that failure scenario of IBGP sessions to ABRs from region-2 going down may
> be detected in 180 seconds ... And some folks panic to run BFD on IBGP
> sessions.
>
[IM] I'm neither a big fan of BFD for iBGP or other peer-tracking
techniques. I agree with you that for some networks (maybe even for a lot
of them) the same CLUSTER_ID could fit well. Maybe there is a way to
restate this paragraph to include observation of current service providers'
practices, and also not to frighten possible readers at the same time.

>
>
>> b) for each prefix received from back ABR label may be different.
>>>
>> [IM] Sure, the per-prefix mode tends to be greedy in terms of resources.
>> It is a problem for Option B, but almost never a problem for Option C.
>>
>
> No one said anything about resources, but about time to do per prefix
> invalidation on ABR vs doing the fixup on ingress PEs and avoiding all the
> mess. My point is that we should do the latter.
>
>
>> So to reiterate I am saying that ABR doing local repair can not do any
>>> repair in prefix independent fashion as there is no single trigger from
>>> region-2 and there is no single switchover to backup ABR possible (each
>>> route may have a different per prefix label).
>>>
>> [IM] Well, I disagree.
>>
>
> Ok.
>
> Tx,
> R.
>