Ali,
Lots of thanks again for a prompt and very encouraging response.
I defer to you and the rest of the authors of 7432bis whether Informative
reference to MEF documents describing processing of L2 Control Protocols should
be added. (IMHO it could be useful while not causing any procedural issu
Hi Sasha, Jorge:
I agree with you both that the clarification should be done wrt “data” traffic
and the detailed handling of L2CP is outside of the scope of 7432bis as
already covered in MEF documents.
Wrt data traffic on a port, we have two uses cases:
1. Access ports where the data traf
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
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
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-kno
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
