Re: [bess] Question regarding section 17.3 draft-ietf-bess-rfc7432bis

[Igor Malyushkin <[e-mail]>]

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 <[e-mail]>:

> 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 <[e-mail]>
> *Date: *Monday, 9 January 2023 at 16:51
> *To: *Alexander Vainshtein <[e-mail]>
> *Cc: *Menachem Dodge <[e-mail]>, [e-mail] <[e-mail]>
> *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 <
> [e-mail]>:
>
> 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 <[e-mail]>
> *Sent:* Monday, January 9, 2023 2:37 PM
> *To:* Alexander Vainshtein <[e-mail]>; [e-mail]
> *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 <[e-mail]>
> *Date: *Monday, 9 January 2023 at 14:22
> *To: *Menachem Dodge <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *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 <[e-mail]> *On Behalf Of *Menachem Dodge
> *Sent:* Monday, January 9, 2023 10:22 AM
> *To:* [e-mail]
> *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
>
> [image: signature_227873180]
>
> [phone]
>
> [e-mail]
>
> 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=Grphi4loNd6qZ1SactwcOMkzFwEf-RVNcCMaZSiLzJs&s=n6wev3g3GS7wjDga5IByZwBnSvTJWnK_Yd-NwWnKY0k&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
> [e-mail]
> 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=Grphi4loNd6qZ1SactwcOMkzFwEf-RVNcCMaZSiLzJs&s=Xq7mI9sR48BjLvyo7nPieGvAXgvAcj349_XisCDDF_Y&e=>
>
>