Hello Igor, Thanks very much for the good explanation.
Best Regards, Menachem From: Igor Malyushkin <gmalyush...@gmail.com> Date: Tuesday, 10 January 2023 at 13:28 To: Menachem Dodge <mdo...@drivenets.com> Cc: Alexander Vainshtein <alexander.vainsht...@rbbn.com>, bess@ietf.org <bess@ietf.org> Subject: Re: [bess] Question regarding section 17.3 draft-ietf-bess-rfc7432bis Hi Menachem, The remote PE isn't treating all MAC/IP advertisements learned from the same ESI as being withdrawn, the important nuance from section 17.3 here is: ... from the advertising PE. So we don't consider all MACs behind the ES as being withdrawn, some of them can belong to other PEs. My understanding of the highlighted sentence is that we should consider these MACs as being withdrawn for the case when there are no other PE routers behind the same ES. Checking of that is based on the existence of Ethernet A-D routes for this ES. If we receive an Ethernet A-D withdraw from a PE (and do not receive MAC/IP withdraws from the same PE) we can resolve a next-hop for the MAC/IP routes from this PE via other Ethernet A-D routes (if there are at least one). If we don't have any Ethernet A-D routes for the ES, all MAC/IP routes behind this ES (based on an ESI) are treated as being withdrawn at once. Section 9.2.2 gives a good explanation. вт, 10 янв. 2023 г. в 11:47, Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>>: Hello Igor, Sasha, Thanks for your responses. I would accept what you have explained, however I can’t then understand the meaning of the last paragraph of section 17.3: When a PE receives a withdrawal of a particular Ethernet A-D route from an advertising PE, it SHOULD consider all the MAC/IP Advertisement routes that are learned from the same ESI as in the Ethernet A-D route from the advertising PE as having been withdrawn. This optimizes the network convergence times in the event of PE-to-CE failures. Please could you explain why the remote PE is treating all the MAC/IP Advertisement routes learned from the same ESI as being withdrawn. That would mean that it would start flooding for these MAC addresses. Thank you kindly. Best Regards, Menachem From: Igor Malyushkin <gmalyush...@gmail.com<mailto:gmalyush...@gmail.com>> Date: Monday, 9 January 2023 at 16:51 To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Cc: Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] Question regarding section 17.3 draft-ietf-bess-rfc7432bis Hi folks, I concur with Sasha. The idea behind retaining locally learned MACs until their timers hit zero is to reduce unknown unicast flooding in a service. All ingress PEs will have time to learn new MAC advertisements from the rest PE behind the ES (if they don't have them apriori). This is actually useful for both multihoming modes. пн, 9 янв. 2023 г. в 18:18, Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>: Menachem, Please note that the procedures defined in Section 17.3 of RFC 7432 (and of the 7432bis draft) are not limited to failure of PE-CE links that belong to multi-homed Ethernet Segments (MH ES). If the failed link belongs to a All-Active MH ES, retention of EVPN MAC/IP Advertisement routes advertised by the PE in question for MAC addresses locally learned by the PE in question: 1. Allows remote PEs to continue forwarding traffic with Destination MAC addresses in question to other PEs attached to the same MH ES as described in Section 8.2 of RFC 7432 2. Prevents these MAC addresses being from being stuck forever in the FDBs of remote PEs if they are not locally re-learned by one of the remaining PEs attached to the same MH ES. Hope this helps. Regards, Sasha From: Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>> Sent: Monday, January 9, 2023 2:37 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; bess@ietf.org<mailto:bess@ietf.org> Subject: [EXTERNAL] Re: Question regarding section 17.3 draft-ietf-bess-rfc7432bis Hello Sasha, Thanks for your response. If the only reason to keep the MAC addresses at the PE with the failed link is for implementing the EVPN Fast Reroute, then would it be possible to state this clearly in section 17.3; such that if the EVPN Fast Reroute is not supported or the EVPN Redirect Label was not received from the other PEs of that ESI, then BGP could send withdraw of MAC/IP Advertisement routes immediately. Thank you kindly. Best Regards, Menachem From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Monday, 9 January 2023 at 14:22 To: Menachem Dodge <mdo...@drivenets.com<mailto:mdo...@drivenets.com>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: Question regarding section 17.3 draft-ietf-bess-rfc7432bis Menachem and all, As I see it, Section 17.3 of 7432bis<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_15t5pN1f8G28GkmXKHYMT-3Fh-3DSjpaaxCyxLAZzwwflrJej0b7trn9LrojCZMcgSkK2h8-3D-26u-3Dhttps-3A__urldefense.proofpoint.com_v2_url-3Fu-253Dhttps-2D3A-5F-5Fdatatracker.ietf.org-5Fdoc-5Fhtml-5Fdraft-2D2Dietf-2D2Dbess-2D2Drfc7432bis-2D2D06-2D23section-2D2D17.3-2526d-253DDwMFAg-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253DcezglEhs6Oa-5FCKN9mhFbT8T8kmWwaNdtBDjE9bvBG-5FE-2526m-253DdfM6dD-2DfslW05FpT7-2D3WWuNUAouGp6rNX5ABb5ciRm0-2526s-253DfHphfhvH0o5QSVnCcrA-5FdI1yivjVdxbrkq5Bn8ChUsk-2526e-253D&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=Grphi4loNd6qZ1SactwcOMkzFwEf-RVNcCMaZSiLzJs&s=daT-2SqHxk4Kk5kmXBE9eOjMGTEL_WrlASSN9oWXkGg&e=> does not differ from Section 17.3 in RFC 7432<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_15t5uCCwashighbSrqwW5-3Fh-3DWHsjQh3h8Twd1jPlYfM9vpTX9F0ObZymPu7ZykHmVU0-3D-26u-3Dhttps-3A__urldefense.proofpoint.com_v2_url-3Fu-253Dhttps-2D3A-5F-5Fwww.rfc-2D2Deditor.org-5Frfc-5Frfc7432-2D23section-2D2D17.3-2526d-253DDwMFAg-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253DcezglEhs6Oa-5FCKN9mhFbT8T8kmWwaNdtBDjE9bvBG-5FE-2526m-253DdfM6dD-2DfslW05FpT7-2D3WWuNUAouGp6rNX5ABb5ciRm0-2526s-253Dut1QXQIflQEqnm0ubOZ7I-5FJC1pBwc-2DHxzf5QiHhDWX4-2526e-253D&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=Grphi4loNd6qZ1SactwcOMkzFwEf-RVNcCMaZSiLzJs&s=JmbjrkLzhU9KgrS-cdHZJOyFeKND6qwJCQrZ_pMSLLM&e=>. Both documents only define reaction of the EVPN Control Plane to failure of a PE-CE link, and these definitions guarantee that remote PEs would stop sending "known unicast" traffic for customer MAC addresses that have been learned from the failed link to the affected PE. If the failed link belonged to a multi-homed Ethernet Segment, fast recovery of affected traffic can be provided using the method defined in the EVPN Fast Reroute<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_15t5jXpNfeLXrowbmj9Cq-3Fh-3D9bR1ndElY-5FypBg4i3gF9fz4-2DimFmDppGk-5FXBQmU7nrc-3D-26u-3Dhttps-3A__urldefense.proofpoint.com_v2_url-3Fu-253Dhttps-2D3A-5F-5Fdatatracker.ietf.org-5Fdoc-5Fhtml-5Fdraft-2D2Dburdet-2D2Dbess-2D2Devpn-2D2Dfast-2D2Dreroute-2D2D03-2526d-253DDwMFAg-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253DcezglEhs6Oa-5FCKN9mhFbT8T8kmWwaNdtBDjE9bvBG-5FE-2526m-253DdfM6dD-2DfslW05FpT7-2D3WWuNUAouGp6rNX5ABb5ciRm0-2526s-253DQnbRrmQWvX1osKypfiORzfk0pcI1btu8O0d5-2DA15t4g-2526e-253D&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=Grphi4loNd6qZ1SactwcOMkzFwEf-RVNcCMaZSiLzJs&s=OP_Q3lMYi0lglIan76aaneN8TUBQWhRnHfi4Jq7msXk&e=> draft. Regards, Sasha From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Menachem Dodge Sent: Monday, January 9, 2023 10:22 AM To: bess@ietf.org<mailto:bess@ietf.org> Subject: [EXTERNAL] [bess] Question regarding section 17.3 draft-ietf-bess-rfc7432bis Hello All, In section 17.3 of the draft-ietf-bess-rfc7432bis PE-to-CE Network Failures the first paragraph states that: “If the connectivity between the multihomed CE and one of the PEs to which it is attached fails, the PE MUST withdraw the set of Ethernet A-D per ES routes that had been previously advertised for that ES.” … “When the MAC entry on the PE ages out, the PE MUST withdraw the MAC address from BGP.” The last paragraph of that section 17.3 states that: When a PE receives a withdrawal of a particular Ethernet A-D route from an advertising PE, it SHOULD consider all the MAC/IP Advertisement routes that are learned from the same ESI as in the Ethernet A-D route from the advertising PE as having been withdrawn. This optimizes the network convergence times in the event of PE-to-CE failures. Clarification Please could you explain why the PE that has detected the network failure to its CE is retaining the MAC addresses until age-out time, and only then withdrawing the MAC/IP Advertisement routes; while all the remote PEs that receive the withdrawal of the Ethernet A-D route should be considering all the MAC/IP Advertisement routes received from that PE and learned from that ESI as having been withdrawn, without waiting for the withdrawal of the MAC/IP Advertisement routes. This seems to be inconsistent behavior. Thank you kindly. Best Regards, Menachem Dodge System Architect [signature_227873180] +972-52-617-5734 mdo...@drivenets.com<mailto:mdo...@drivenets.com> follow us on LinkedIn<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_15t5ehd6D2ewSs7gEAk4D-3Fh-3DP-2DePmL-5FytXLySNaDoyBLZ-2DyIEAs4uPowWoy0ZShyrZE-3D-26u-3Dhttps-3A__urldefense.proofpoint.com_v2_url-3Fu-253Dhttps-2D3A-5F-5Fclicktime.symantec.com-5F15siKypPPVR6CW288BcBc-2D3Fh-2D3DQZH9KlwmZbXPTDgoU19R1IAeBWh-2D5FJpPi0nB7SNM4AKM-2D3D-2D26u-2D3Dhttps-2D3A-5F-5Fwww.linkedin.com-5Fcompany-5Fdrivenets-2526d-253DDwMFAg-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253DcezglEhs6Oa-5FCKN9mhFbT8T8kmWwaNdtBDjE9bvBG-5FE-2526m-253DdfM6dD-2DfslW05FpT7-2D3WWuNUAouGp6rNX5ABb5ciRm0-2526s-253D9OlX8rX6IfH-5F0GKDtZmbU0YP2RPPFHNkYNPgqvQD0CA-2526e-253D&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=Grphi4loNd6qZ1SactwcOMkzFwEf-RVNcCMaZSiLzJs&s=wzXKLuCav6U2SfJftL14Kfj5Xev_rJoj01PhbmV9d38&e=> www.drivenets.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.drivenets.com&d=DwQFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=F4Et8u9KD5Es_a22YCwJuRayaszLitlROxQoRRpEvF4&s=lYXgAbJaxmPAjEEOVnMdrcF1Oe400TKaSPxCviMFJ-4&e=> 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<mailto:BESS@ietf.org> https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwQFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=F4Et8u9KD5Es_a22YCwJuRayaszLitlROxQoRRpEvF4&s=SKNRYN7XoasgyRvda84-HrxMqF9VfOHgFBm1eZxFtAc&e=>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
