Subject: [bess] Re: A question about duplicate MAC detection in Section 15.1 of draft-ietf-bess-rfc7432bis
From: Alexander Vainshtein <[email-masked]>
To: "Jorge Rabadan (Nokia)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Matthew Bocci (Nokia)" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sun, 2 Feb 2025 07:25:22 +0000
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>

Jorge,
Lots of thanks for an unambiguous and very encouraging response.

IMHO and FWIW it would be nice if the text in the section in question would be more explicit on that point.

Regards,
Sasha

From: Jorge Rabadan (Nokia) <[email-masked]>
Sent: Thursday, January 30, 2025 7:19 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: [email-masked]; Matthew Bocci (Nokia) <[email-masked]>
Subject: [EXTERNAL] Re: A question about duplicate MAC detection in Section 15.1 of draft-ietf-bess-rfc7432bis

Hi Sasha,

That’s what the implementations I know do as well.
The section suggests that mobility events occur between local learning events and received MAC/IP Advertisement routes.

Thanks.
Jorge

From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Sunday, January 19, 2025 at 6:22 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Matthew Bocci (Nokia) <[email-masked]<mailto:[email-masked]>>
Subject: RE: A question about duplicate MAC detection in Section 15.1 of draft-ietf-bess-rfc7432bis

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

Hi all,
Some corrections.
The

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, January 19, 2025 11:59 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Subject: RE: A question about duplicate MAC detection in Section 15.1 of draft-ietf-bess-rfc7432bis
Importance: High

Hi,
More of the same:
My colleagues and I have identified at least one implementation in which EVPN PEs only count MAC Move events detected via local learning does not count MAC Move events between different remote PEs affecting duplicate MAC address detection.

If this is indeed the intention of Section 15.1, can you please update the text accordingly?

Regards, and lots of thanks in advance,
Sasha

From: Alexander Vainshtein
Sent: Wednesday, January 15, 2025 8:25 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Subject: A question about duplicate MAC detection in Section 15.1 of draft-ietf-bess-rfc7432bis
Importance: High

Hi,
I have a question about the rule for detection of duplicate MAC addresses in Section 15.1 of draft-ietf-bess-rfc7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-10#section-15.1>.

The problematic text is copied below (with the relevant fragments highlighted) admits two  interpretations:

a PE that detects a MAC mobility event via local learning starts an M-second timer (with a default value of M = 180), and if it detects N MAC moves before the timer expires (with a default value of N = 5), it concludes that a duplicate-MAC situation has occurred

I.e.:

The first MAC Move event that triggers the PE attempt to detect duplication MUST be detected via local learning (and therefore results in increment of the sequence number for the corresponding MAC address by the PE in question)

There is no explicit “via local learning” qualification for the consequent MAC Move events that are counted to decide whether the MAC address in question is duplicate or not.

IMHO this ambiguity may result in different decisions by the affected PEs. Please consider the following scenario:

An EVPN BD is instantiated in PE-1, PE-2 and PE-3. In each of these PEs it is attached to a single-homed Ethernet segment via a single AC

Initially MAC address X is locally learned by PE-1

Then X is locally learned by PE-2 that starts the M-seconds timer

After that X is locally learned by PE-3, PE-1, PE-3, PE- 1 and so on - but not by PE-2 – while the M-seconds timer in PE-2 is still running. All these events are identified by PE-2 as MAC Move events – but not via local learning:

If PE-2 counts these MAC Move events for the purpose of duplicate MAC detection, it declares X as duplicate and alerts the operator  - even if it did not participate in in

Otherwise, PE-2 does not declare X as duplicate.

I understand that the example above is a corner case, but. IMHO and FWIW, it should be resolved.
Can you please clarify, which of the above interpretations of the rule is correct and, in any case, clarify this point in the next revision of the draft?

Regards, and lots of thanks in advance,
Sasha

Disclaimer

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.