Re: [mpls] Control plane solutions for the use cases of NFFRR

There is also an interesting point in Section 2.3 for FRR with RSVP-TE LSP.
I couldn't find any restrictions for protecting one bypass LSP with another
in 4090 but I strongly believe it's not the case. At least I know no
implementation makes such protection and personally consider it harmful.

I'm not an expert in SPRING. As I understand TI-LFA protects a label
instead of a path so turning off FRR at one PLR impacts a later FRR. I know
that it is by the design of the draft but what if the second FRR doesn't
create a loop and even is desirable? Imagine an additional link between N7
and N3 in Figure 3 with a higher cost. N2 acting as a PLR will impose
NFFRR SPL on a stack and redirect traffic to N6->N7->N3->N4. After a
failure of the primary N7-N3 link, N7 won't redirect traffic via the
secondary link to N3. Is it a desirable solution?

Talking about a service part of the draft I personally find it very
promising and useful. EVPN FRR solution looks costly from the number of
labels required for every ES. Moreover, it's difficult to imagine how to
scale this solution on other technologies, e.g. IP-VPN. The problem with
traffic looping between two multihoming PE due to PIC edge in the case of
multihomed CE's failure is not rare in IP-VPN. But there are no segment
routes to place a terminating label. A standalone control-plane solution is
required for it.

вт, 26 июл. 2022 г. в 10:09, Ketan Talaulikar <ketant.ietf@gmail.com>:

> Hello Kireeti/Wen,
>
> I wanted to check if you had considered a control plane-based solution for
> some of the use cases that motivated the NFFRR work.
>
> I would like to draw your attention to a draft that tries to address a
> similar problem space for EVPN:
> https://datatracker.ietf.org/doc/draft-burdet-bess-evpn-fast-reroute/
>
> For Segment Routing, we have the unprotected adjacency SIDs and there have
> been discussions in the SPRING WG for unprotected prefix SIDs. The use of
> these SIDs for the TI-LFA backup path can also address the issue.
>
> There may perhaps be similar control plane mechanisms that may work for
> other similar problem spaces?
>
> IMHO, tackling this problem space in the control plane alone seems more
> beneficial than in the data plane (I note that the NFFRR proposal also
> needs control plane extensions). Could you please share your views on this?
>
> Thanks,
> Ketan
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>