Re: [bess] A question about Duplicated MAC Issue in Single Flow-Active multi-homing

[Alexander Vainshtein <[e-mail]>]

Luc,
Lots of thanks for a prompt and very useful response.

An explicit mention of the possibility of false duplicated MAC detection and a recommendation for tuning the parameters of the duplicated MAC detection mechanism in accordance with the hold timers of the Layer 2 Control Protocol would be fine IMHO.

Regards,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Luc André Burdet <[e-mail]>
Sent: Thursday, February 9, 2023, 22:31
To: Alexander Vainshtein <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; Nitsan Dolev <[e-mail]>; Alexander Ferdman <[e-mail]>; Yair Nissim <[e-mail]>; Evyatar Wiesel <[e-mail]>; [e-mail] <[e-mail]>
Subject: [EXTERNAL] Re: A question about Duplicated MAC Issue in Single Flow-Active multi-homing

Hi Sasha,

The Access Protocol should protect from frequent topology changes—most access protocols have dampening or hold-times incorporated.
We can add a note commenting on this possibility though... and a MAY or SHOULD increasing limits on mobility procedures for scenarios where unwanted behaviour occurs (in case access protocols hold-time is insufficient)

Regards,
Luc André

Luc André Burdet |  Cisco  |  [e-mail]  |  Tel: [phone]


From: Alexander Vainshtein <[e-mail]>
Date: Thursday, February 9, 2023 at 12:02
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, Nitsan Dolev <[e-mail]>, Alexander Ferdman <[e-mail]>, Yair Nissim <[e-mail]>, Evyatar Wiesel <[e-mail]>, [e-mail] <[e-mail]>
Subject: A question about Duplicated MAC Issue in Single Flow-Active multi-homing
Hi,
I have a questions about detection and handling of the duplicated MAC addresses (as described in Section 15.1 of the 7432bis draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-06#section-15.1<https://clicktime.symantec.com/15siKyzgnJGPGVhmKQ1jW?h=IS2FntitpqllknQYEDDxwFr8I_uYY3tkFoAz_JLE0_w=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-06%23section-15.1>>) in the case of Single Flow-active multihoming as described in the EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto-02<https://clicktime.symantec.com/15siF9oQKganrYsqmqcat?h=D-1-JOvi3DuqNIG9XB61Zujdb0s1S0QLscs5O9Or4aM=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto-02>> draft. Section 5 of this draft states:

When a host moves to PE2 from the PE1 L2GW peer, the MAC mobility sequence number is incremented to signal to remote peers that a 'move' has occurred and the routing tables must be updated to PE2. This is required when an Access Protocol is running where the loop is broken between two CEs in the access and the L2GWs, and the host is no longer reachable from the PE1-side but now from the PE.

This means that frequent topology changes in the Layer 2 customer site  attached to the EVPN domain via a MH ES in Single Flow-Active multi-homing mode could result in false detection of MAC duplidation.
This, in its turn, would result in the L2 GW PEs stopping "sending, updating or processing any BGP MAC/IP Advertisement routes" for the MAC addresses affected by these topology changes and this, in its turn, would result in (full or partial) blackholing of traffic to such MAC addresses.

It is not clear to me how this situation should be handled. One possibility that comes to my mind is disabling of the MAC duplication procedures for MAC addresses that arre learned fro m MH ES in Single Flow-Active MH mode


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.