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

[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.

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.

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.

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.


> 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.