Luc, Lots of thanks for a prompt response. I have missed the fact that, once DF calculation has been done, loss of the remote ES results in immediate re-calculation without any need for the DF election timer. My mistake.
Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com From: Luc Andre Burdet (lburdet) <lbur...@cisco.com> Sent: Thursday, December 9, 2021 4:55 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-ietf-bess-evpn-mh-pa....@ietf.org Cc: bess@ietf.org Subject: [EXTERNAL] Re: A query regarding applicability of EVPN fast failover mechanisms to Port-Active multi-homing draft Hi Sasha, The DF-Election timer is only run on an interface recovery, not on failure, e.g. on PE1 PE-CE link recovery. In step 4.b.ii, there is no timer involved. Port-active is no different than other DF-election mechanisms: RT4 ES withdrawal by PE1 will trigger DF takeover at PE2. I am aware of some implementations which have chosen to take PE1’s ES-EAD withdrawal into consideration for a pre-emptive DF-takeover by previous-BDF but I am not aware of any draft that specifies this. ES RT-4 and ES-EAD RT-1 are usually fairly close in terms of BGP propagation delays anyways. Hope this helps clarify 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, December 9, 2021 at 09:28 To: "draft-ietf-bess-evpn-mh-pa....@ietf.org<mailto:draft-ietf-bess-evpn-mh-pa....@ietf.org>" <draft-ietf-bess-evpn-mh-pa....@ietf.org<mailto:draft-ietf-bess-evpn-mh-pa....@ietf.org>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: A query regarding applicability of EVPN fast failover mechanisms to Port-Active multi-homing draft Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent-To: <j...@juniper.net<mailto:j...@juniper.net>>, <slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>>, <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, <lbur...@cisco.com<mailto:lbur...@cisco.com>>, <pbris...@cisco.com<mailto:pbris...@cisco.com>>, <edward.ley...@verizonwireless.com<mailto:edward.ley...@verizonwireless.com>>, <saja...@cisco.com<mailto:saja...@cisco.com>>, <aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>, <stho...@cisco.com<mailto:stho...@cisco.com>>, <manka...@cisco.com<mailto:manka...@cisco.com>>, <bin_...@comcast.com<mailto:bin_...@comcast.com>>, <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, <martin.vigour...@nokia.com<mailto:martin.vigour...@nokia.com>> Resent-Date: Thursday, December 9, 2021 at 09:28 Hi, A have a question regarding usage of EVPN fast failover mechanisms in combination with the port-active multi-homing mode as defined in the corresponding draft<https://clicktime.symantec.com/34ZsjXbXdtuQsg4hmwzmq5Q6H4?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-mh-pa-04>. Please configure the following scenario: 1. There are 3 PEs in the setup: PE-1, PE-2 and PE-3, and an EVI that is present in all of them. 2. The EVI in PE-1 and PE-2 is attached to a Port-Active MH ES (i.e. configuration is consistent) that uses Highest Preference-based Df election method * PE-1 is elected as the DF and activates the corresponding local port * PE-2 is elected as the Backup DF (BDF) in accordance with and blocks the corresponding port for customer traffic * Both PE-1 and PE-2 advertise per-EVI EVPN Type 1 route for the EVI in question (please note that this requires PE-2 to differentiate between failed ports and ports that it has decided to deactivate) 3. PE-1 learns multiple IP→MAC pairs from the MH ES in question and advertises it as an EVPN Type 2 route. As a consequence, PE-3 creates a pair of FDB entries for the MAC addresses in these pairs: * The active FDB entry in each pair entry points to PE-1 (because it has advertised an EVPN Type 2 route for the IP→MAC pair) and uses the label received in the Label1 field of the corresponding EVPN Type 2 route * The backup FDB entry in each points to PE-2 (because it has only advertised a per EVI EVPN Type 1 route for the EVI in question) and uses the label received in the Label field of the per-EVI EVPN Type 1 route 4. When the PE-CE link that is part of the MH ES in question fails in PE-1, it immediately withdraws the per ES EVPN Type 1 route for this MH ES * As a consequence, PE-3 activates the backup FDB entries for all MAC addresses it has learned from PE-1 and starts sending traffic to PE-2 * However, withdrawal of the per-ES EVPN-Type 1 route by and of itself will not trigger re-election of the DF. As a consequence, the port in PE-2 shall remain blocked until: i. The EVPN Type 4 route advertised by PE-1 for the MH ES in question is withdrawn ii. The DF Election timer (started when the EVPN Type 4 route is withdrawn, by default 3 seconds) expires. From my POV the above means that known unicast traffic sent by PE-3 toward the CEs on the MH ES shall be lost at least for the duration of the DF Election timer (could be more if withdrawal of the EVPN Type 4 route by PE-1 is not prioritized). Do I miss something substantial here? IMHO and FWIW the situation could be improved if the BDF on the Port-Active MH ES, upon detection of the per-ES EVPN Type 1 route for the MH ES in question by the PE that has been elected as the DF, would immediately assume the DF role and activates the corresponding port. But the Port-Active Multi-Homing draft does not define such behavior. Your timely feedback would be highly appreciated. Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com> Notice: 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. Notice: 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
