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

< forking off a thread with BESS WG involved >

Wen, you made some good points in the MPLS WG session today on why you
believe the NFFRR-based data plane solution [1] is better than the
individual draft [2] in BESS that proposes a control plane solution.

Since the points are related to the EVPN/L3VPN service, I feel they are
better debated in the BESS WG.

Thanks,
Ketan
[1] https://datatracker.ietf.org/doc/draft-burdet-bess-evpn-fast-reroute/
[2] https://datatracker.ietf.org/doc/draft-kompella-mpls-nffrr/

On Tue, Jul 26, 2022 at 9:11 PM Igor Malyushkin <gmalyushkin@gmail.com>
wrote:

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