Dear Authors I reviewed the EVPN FRR draft and it is well written.
There is a tremendous amount of detail in this draft and wonder if it should be easier to split into different drafts that focus on different underlays or technologies. My understanding from reading the draft is that this draft uses a “secondary” redirect label “ERL” using downstream label allocation for the FRR next hop path to provide a pre programmed backup FRR path BDF peer next hop, that can provide data plane based convergence improvement over the existing RFC 7432bis EVPN mechanisms for control plane based convergence. This concept of utilizing a secondary label for faster convergence has similarities to IDR draft for IP VPN BGP PIC Edge pre programmed FRR PE-CE path protection draft below: https://datatracker.ietf.org/doc/html/draft-mohanty-idr-secondary-label-00 Maybe worth reading to compare notes and the ML archive. https://mailarchive.ietf.org/arch/msg/idr/ZucrYt9amGP8DD_BAXb6rwwpRGA/ In the discussion it was mentioned solving the issue at the service level and it’s complexity versus solving at the transport layer with BGP-LU. Not sure that would apply here but just wanted to mention. 3. Requirements section Would this draft apply to IP VPN / EVPN interworking https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking Would this also apply to RFC 9014 DCI Overlay? https://datatracker.ietf.org/doc/rfc9014/ And EVPN Multisite below https://datatracker.ietf.org/doc/draft-sharma-bess-multi-site-evpn/ Item #11 Solution should not relay on adding labels to the label stack or underlay specific SPL. Since this draft is providing PE-CE AC EVPN all active multi home fast reroute protection service level label allocation similar to IP VPN per CE label allocation mode on egress PE-CE AC. Normally you would have a BOS service label for the EVPN ESL, however for the additional ERL label why would there not be an additional label added to the label stack and this would be an MNA action for PSD for the ERL SPL? I think you mentioned that the solution would be transport underlay agnostic and maybe that could be added to section 3. That is great that this solution is underlay agnostic! This solution requires that the DF algorithm used must support BDF election RFC 8584 so if PE1 AC fails it used ERL2 signaled by PE2 NH pre programmed BDF FRR path and if PE2 AC fails or uses ERL1 signaled by PE1 NH pre programmed BDF FRR path. Correct? 5.2 Terminal disposition behavior Basically the ERL redirect BDF NH can only be signaled once and then is terminated so it’s a one time FRR until the link is restored. This is to prevent looping in case of simultaneous PE-CE failure. However in a simultaneous failure PE1 would signal ERL1 to PE2 and PE2 would signal ERL2 to PE1 in this case both PE-CS links bounced and both would PEs would redirect to each other. Due to timing of redirect from link flapping it seems you could have a continual bouncing back and forth of redirects between the PEs. 5.2 The ERL acts like a local cross-connect by providing a direct channel from disposition to the AC. ERLs are terminal-disposition and prevents once‑redirected packets from being redirected again. With this forwarding attribute on ERLs, known only locally to the downstream-allocating PE, redirection is achieved without growing the label stack with another special purpose label.¶ <https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.2-5> Section 5.2 is talking about the terminal disposition using the section 5.1 discussion that the redirect label must carry a special attribute in the local forwarding and decapsulation chain where an override to DF election is applied where traffic from the ERL will bypass the local blocking state. So once control plane is converged the ERL will stop and that will basically terminate the redirect loop from happening after the 1st occurrence? 7.1 NVO Tunnels This section briefly describes NVO and applicability of this ERL solution to NVO and for Non MPLS based NVO VXLAN & GENEVE, I am guessing those details would be split off into a different draft. 7.1 and 7.1.1 should take into account RFC 9014 DCI overlay where the VNI is regenerated and not globally significant. Also for Non MPLS NVO VXLAN should account for ESI MLAG hosts and BGP Only DC using RFC 9014 DCI overlay regeneration of VNI. 7.2 SRv6 The draft should mention that RFC 9252 does not account for ARG field and point to BIS update. https://datatracker.ietf.org/doc/html/draft-trr-bess-bgp-srv6-args-02 Should mention that SRv6 PGM below description of the two endpoint functions used. End.DT2U is decapsulation and Unicast MAC L2 table lookup End.DT2U+Arg.FR2 So we have a double SID for the endpoint behavior , the regular End.DT2U endpoint function L2 table traffic lookup. I think this section for End.DT2U is for L2 table lookup and not for the redirect reroute which is handled by END.DX2. End.DX2 is decapsulation and L2 cross connect - L2 VPN EVPN VPWS - L2 service SID END.DX2+Arg.FR2 (ERL redirect) So for END.DX2 we have a double sid for the endpoint behavior the regular End.DX2 endpoint function L2 table traffic + rerouted traffic (ERL redirect) ARG+FR2 processing and both service SID would be advertised together. Can default packing method be used for encoding in BGP prefix sid and optional update packing optimization split between common part mapped to BGP prefix sid and FUNC+ARG mapped to NLRI? 7.2.3 Conflicting endpoint behaviors AFAIK here you have 2 endpoint behaviors that we are using to provide the ERL additional label redirect for the FRR BDF next hop pre programmed backup path. My understanding is you would advertise per section 7.2.1 and 7.2.2 you would advertise both End.DT2U for table lookup and End.DX2 for EVPN VPWS service sid but now with the additional new SID +ARG.FR2. So I believe the double service SID with the additional ARG field for FRR are the two new variants being introduced with this draft. 7.3 Inter AS Options No issues 8. BGP extensions No issues Kind Regards Gyan
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
