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

[Menachem Dodge <[e-mail]>]

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__datatracker.ietf.org_doc_html_draft-2Dietf-2Dbess-2Drfc7432bis-2D06-23section-2D17.3&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=dfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0&s=fHphfhvH0o5QSVnCcrA_dI1yivjVdxbrkq5Bn8ChUsk&e=> does not differ from Section 17.3 in RFC 7432<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7432-23section-2D17.3&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=dfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0&s=ut1QXQIflQEqnm0ubOZ7I_JC1pBwc-Hxzf5QiHhDWX4&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__datatracker.ietf.org_doc_html_draft-2Dburdet-2Dbess-2Devpn-2Dfast-2Dreroute-2D03&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=dfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0&s=QnbRrmQWvX1osKypfiORzfk0pcI1btu8O0d5-A15t4g&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
[signature_227873180]
[phone]
[e-mail]<mailto:[e-mail]>
follow us on LinkedIn<https://urldefense.proofpoint.com/v2/url?u=https-3A__clicktime.symantec.com_15siKypPPVR6CW288BcBc-3Fh-3DQZH9KlwmZbXPTDgoU19R1IAeBWh-5FJpPi0nB7SNM4AKM-3D-26u-3Dhttps-3A__www.linkedin.com_company_drivenets&d=DwMFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=dfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0&s=9OlX8rX6IfH_0GKDtZmbU0YP2RPPFHNkYNPgqvQD0CA&e=>
www.drivenets.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.drivenets.com&d=DwQFAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=cezglEhs6Oa_CKN9mhFbT8T8kmWwaNdtBDjE9bvBG_E&m=dfM6dD-fslW05FpT7-3WWuNUAouGp6rNX5ABb5ciRm0&s=w0rbywVWm1U0Tp5-SHvZhy-SoynRxWRsKr5RlY6VbKU&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.