Resending as it seems some people have not received it in full...
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
From: Alexander Vainshtein
Sent: Thursday, November 18, 2021 1:04 PM
To: [email protected]
Cc: [email protected]
Subject: A few questions pertaining to the Virtual Ethernet Segment draft
Hi,
I have several questions with regard to the Virtual Ethernet Segment draft.
1. I have tried to understand how the customer Ethernet frames received by
some EVI from an ENNI port (as defined in Section 1.1 of the Virtual Ethernet
Segment
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-eth-segment#section-1.1>)
via a specific EVC are supposed to be encapsulated when sent to remote PEs
belonging to the same EVI
* RFC 7432 (that deals with customer Ethernet frames received with a
single VLAN tag) states (in many places) that "The MPLS-encapsulated frames
MUST remain tagged with the originating VID".
* The above definition does not seem to be applicable to the scenarios
in which the customer frames are received with more than one VLAN tag. At the
same time I have not found any relevant definition in the draft - did I miss
something?
* My guess (FWIW) that the outer VLAN (S-VLAN):
i. MUST be
stripped from the frame that has been received from an virtual ES associated
with an ENNI port
ii. MUST be
pushed on the frame that has been received by an EVI in MPLS encapsulation
Can you please confirm/comment on these guesses?
1. I also have similar concerns regarding egress VLAN translation:
* It is explicitly mentioned in RFC 7432 as the way to handle the
scenarios when different customer sites are attached to the EVI using different
VLANs in the case of VLAN-aware and VLAN-aware Bundle service interface
* It is also explicitly prohibited in RFC 7432 if the EVI implements
VLAN Bundle service interface
* Can you please clarify what are the rules for the frames that have
been received with EVPN encapsulation and are supposed to be transmitted via an
virtual ES associated with an ENNI port?
2. I also have a problem with Figure 1 in the draft that says that the same
ENNI port may support both All-Active Multi-Homing of one CE and single-homing
of another CE:
* According to RFC 7432 All-Active multi-homing assumes that the CE
treats all the links comprising a given MH ES and connecting it to multiple PEs
as a single LAG
* This means that such a CE could run LACP on these links, with each of
the PEs acting as the LACP peer for the links that attach it to this CE
* How should this be modified in the case of a virtual ES associated
with an ENNI port? Specifically:
i. Should
the PE run "S-tagged LACP" instance per EVC for peering with each specific
multi-homed CE?
ii. Or should
a single LACP instance run between the PE and the edge device of the Carrier
Ethernet network?
Your timely feedback would be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
Notice: 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]
https://www.ietf.org/mailman/listinfo/bess
