Luc, Lots of thanks for a prompt response. It seems that we are actually in sync regarding the traffic that would use ERL.
IMHO and FWIW an explicit statement that "BUM is not in-scope of the draft, it is not redirected" would help the readers. It would also help to clarify that bypassing DF Election behavior is not relevant for All-Active and Single Flow-Active redundancy modes. Regarding Port-Active redundancy mode: 1. Section 3.2 of Port-Active Multi-Homing draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-mh-pa-09#section-3.2> states that "Non-DF routers SHOULD implement a bidirectional blocking scheme for all traffic". To me bidirectional blocking means that traffic is neither received nor transmitted via the non-DF link - can you please clarify how bypassing DF Election procedures can help with his? 2. Section 5.1 of the EVPN FRR draft says that "to support EVPN Fast Reroute, the CE must be able to receive traffic from an OOS LAG link ". * This is a requirement for the CE which is not aware of EVPN r multi-homing * Can you please clarify if this is aligned with IEEE 802.1AX-2014? Regards, Sasha Regards, Sasha From: Luc Andre Burdet (lburdet) <lbur...@cisco.com> Sent: Thursday, November 9, 2023 6:00 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Cc: bess@ietf.org Subject: [EXTERNAL] Re: The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft Hi Sasha, BUM is not in-scope of the draft, it is not redirected; The Fast-Reroute draft describes 2 behaviours, terminal disposition and NDF-bypass. The mechanism is agnostic to the load-balancing mode: one, the other, or both behaviours may be applicable. You are right, in A/A the "NDF-bypass" is not applicable for ERL Regards, Luc André Luc André Burdet | lbur...@cisco.com<mailto:lbur...@cisco.com> | Tel: +1 613 254 4814 From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Thursday, November 9, 2023 at 10:41 To: Luc Andre Burdet (lburdet) <lbur...@cisco.com<mailto:lbur...@cisco.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: The significance of bypassing DF Election Behavior in the EVPN Fast Reroute draft Luc and all,https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1<https://datatracker.ietf.org/doc/html/draft-burdet-bess-evpn-fast-reroute-06#section-5.1> I have a question regarding significance of bypassing DF Election behavior in Section 5.1 of the EVPN Fast Reroute draft, at least in the case of All-Active multi-homing and EVPN-MPLS. To the best of my understanding, in this case DF Election based filtering is applied only to BUM traffic. Per Section 11.2 of RFC 7432<https://datatracker.ietf.org/doc/html/rfc7432#section-11.2> this traffic is carried using the label advertised in the PMSI attribute in the EVPN IMET route so that DF Election-based filtering can be applied only to the traffic received with this label: · In the case of ingress replication, this label is down-stream allocated by the egress PE and therefore would be different from the ERL label · In the case of P-multicast trees, this label would be upstream-allocated by the ingress PE and, in the case of non-aggregated tunnels, preceded by the label that identifies the P-multicast tree. (I am leaving aside the case of aggregated P-multicast trees). I.e., in both cases, the egress PE can identify the received BUM traffic based on the label stack in its EVPN encapsulation and apply DF-Election-based filtering just to this traffic - but not to traffic received with the ESL or ERL labels. What, if anything, do I miss? Regards, and lots of thanks in advance, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
