Jorge, Again, lots of thanks for a prompt response. I fully agree that my second bullet is effectively covered by the relevant MEF technical specifications (MEF45.1). IMHO an Informational reference to these documents would be useful.
As for my first bullet: from my POV the text of Section 6.2.1 of the original RFC 7432 has left the behavior of the port-based service interface regarding untagged customer traffic open to interpretations. Closing this gap in 7432bis would be most useful IMHO. Regards, Sasha From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> Sent: Wednesday, June 19, 2024 12:00 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-ietf-bess-rfc7432...@ietf.org Cc: bess@ietf.org Subject: [EXTERNAL] Re: Port-Based Service Interface in draft-ietf-bess-rfc7432bis Hi Sasha, I don’t have a strong opinion on your first bullet, if there are no objections. Although it could be interpreted as if RFC7432 didn’t support untagged traffic on port-based service interfaces, which is not the case. About the second bullet, we are not defining L2CP behavior in any of the BESS specs, my understanding is that this is more an MEF matter. So I wouldn’t understand why we need to add the second bullet. I don’t think we should. Thanks. Jorge From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Tuesday, June 18, 2024 at 10:50 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> <draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: 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. 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<mailto:jorge.raba...@nokia.com>> Sent: Tuesday, June 18, 2024 7:36:22 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> <draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto: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<mailto:alexander.vainsht...@rbbn.com>> Date: Tuesday, June 18, 2024 at 5:54 AM To: draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> <draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto: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
