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 <laburdet.i...@gmail.com>
Sent: Thursday, February 9, 2023, 22:31
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>;
draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>; Nitsan Dolev <nitsan.do...@rbbn.com>;
Alexander Ferdman <alexander.ferd...@rbbn.com>; Yair Nissim
<yair.nis...@rbbn.com>; Evyatar Wiesel <evyatar.wie...@rbbn.com>;
draft-ietf-bess-evpn-l2gw-pr...@ietf.org
<draft-ietf-bess-evpn-l2gw-pr...@ietf.org>
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 | laburdet.i...@gmail.com | Tel: +1 613 254 4814
From: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Date: Thursday, February 9, 2023 at 12:02
To: draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>, Nitsan Dolev <nitsan.do...@rbbn.com>,
Alexander Ferdman <alexander.ferd...@rbbn.com>, Yair Nissim
<yair.nis...@rbbn.com>, Evyatar Wiesel <evyatar.wie...@rbbn.com>,
draft-ietf-bess-evpn-l2gw-pr...@ietf.org
<draft-ietf-bess-evpn-l2gw-pr...@ietf.org>
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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
