Jorge, Lots of thanks for a prompt and most helpful response. IMHO the text is Section 6.2.1 should explicitly state your interpretation, i e.:
* Untagged customer traffic is encapsulated and forwarded "as is" * Untagged Layer 2 control protocols traffic (identified by carrying well-known multicast destination MAC addresses is handled in accordance with appropriate local configuration for each specific protocol. They may be forwarded, discarded, or peered. Does this make sense to you? Regards, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Tuesday, June 18, 2024 7:36:22 PM 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> Subject: [EXTERNAL] Re: Port-Based Service Interface in draft-ietf-bess-rfc7432bis Hi Sasha, The implementations I know, all the traffic – tagged and untagged – is mapped to the EVPN broadcast domain, for that type of service. Since no pop/push is done of the vlan tags, untagged traffic would be encapsulated into the EVPN packet and forwarded as is. My interpretation in this case of “The MPLS-encapsulated frames MUST remain tagged with the originating VID” is no-tagging for those packets, since the originating VID was non-existent. I don’t see any issues with LACP and multihoming, since LACP PDUs are punted to the control plane on the PEs, and not forwarded. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com> Date: Tuesday, June 18, 2024 at 5:54 AM To: draft-ietf-bess-rfc7432...@ietf.org <draft-ietf-bess-rfc7432...@ietf.org> Cc: bess@ietf.org <bess@ietf.org> Subject: Port-Based Service Interface in 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, I have a question regarding Section 6.2.1 of 7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-09#section-6.2.1>. This section defines Port-based Service Interface in EVPN as “a special case of the VLAN bundle service interface, where all of the VLANs on the port are part of the same service and map to the same bundle” . It further states that “The procedures are identical to those described in Section 6.2” which, in its turn, says that “no VID translation is allowed for this (VLAN bundle - Sasha) service interface type”. My question is: what happens with untagged traffic received from an Ethernet port to which an EVI (or EVPN-VPWS) implementing port-based service interface is attached? It seems that mapping untagged traffic to tagged using port-based VLAN ID at ingress and stripping this VLAN tag at egress is not compliant with the definitions above. An interesting special case could be the case of an All-Active MH ES that runs LACP on its constituent links vs. the attached CE. 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 -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
