Mankamana, Lots of thanks for your email and detailed responses. Please see some comments to your responses inline below.
Regards, Sasha From: Mankamana Mishra (mankamis) <[email protected]> Sent: Thursday, July 24, 2025 9:54 AM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: [email protected] Subject: [EXTERNAL] Re: A couple of question about draft-ietf-bess-evpn-ac-aware-bundling Thanks Alex for feedback , please find inline comment. From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Tuesday, February 6, 2024 at 5:52 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: A couple of question about draft-ietf-bess-evpn-ac-aware-bundling Hi, I have a couple of question about the AC-aware bundling draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ac-aware-bundling-04> . The background for these questions is given below. 1. Section 6.2 of RFC 7432<https://datatracker.ietf.org/doc/html/rfc7432#section-6.2> that defines VLAN Bundle Service Interface says that “MAC addresses MUST be unique across all VLANs for that EVI in order for this service to work” . a. This requirement is not limited to multihomed PEs b. No mechanisms for enforcement of this requirement (e.g., by detecting and handling of possible violations) are defined c. Any manipulation of VLAN tags is strictly prohibited with this service interface 2. The draft in question defines a similar requirement and effectively provides a way to enforce it. However: a. Detection of misconfiguration is explicitly limited to just multihomed PEs (as can be seen from the title of Section 5) b. The draft does not impose any limitations on VLAN manipulation (this is expected in the case of inter-subnet traffic (with each subnet differentiated by a VLAN) within a single broadcast domain) c. The draft seems to deal just with the situation in which multiple subnets in the same broadcast domain are differentiated by VLANs. And now my questions: Q1: What is the rationale for restricting detection and handling of violation of the above-mentioned rule to just multi-homed PEs? Mankamana : If you look at figure-1 and its description in problem statement section, this problem is valid only for multihoming case where same EVI has different VLAN differentiating AC . [[Sasha]] I think that the mechanism introduced in the draft could be useful for addressing problems that have not been mentioned in the problem statement – e.g., detecting the situations in which a PE in which an EVI that implements VLAN Bundle service interface is instantiated, locally learns the same MAC address from different VLANs on the same port. Q2: Does the draft support the situations in which multiple IP subnets in the same broadcast domain are NOT differentiated by different VLANs? Mankamana: Would be happy to know more about what use case this trying to cover ? [[Sasha]] Answered in my response to your other mail Q3: Is VLAN translation with AC-aware bundling service interface allowed for intra-subnet traffic that undergoes “pure Layer 2 switching” in the single broadcast domain? Mankamana : There is no restriction imposed by this draft for any traffic , rather it gives enough context to multihomed peer to be able to forward the traffic to appropriate VLAN. [[Sasha]] Got it, lots of thanks. Your feedback would be highly appreciated. 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.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
