< 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 <[email protected]> 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 <[email protected]>: > >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/mpls >> >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
