Ali and all,
I have read the new version of Section 6.3 of 7432-bis, and it addresses my
concerns.
Regards, and lots of thanks for taking care of this issue.
Sasha
From: Ali Sajassi (sajassi) <saja...@cisco.com>
Sent: Friday, January 6, 2023 12:09 AM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>;
draft-ietf-bess-rfc7432bis.auth...@ietf.org
Cc: bess@ietf.org; Ron Sdayoor <ron.sday...@rbbn.com>; Moti Morgenstern
<moti.morgenst...@rbbn.com>; Nitsan Dolev <nitsan.do...@rbbn.com>; Michael
Gorokhovsky <michael.gorokhov...@rbbn.com>
Subject: [EXTERNAL] Re: A doubt in the requirements pertaining to VLAN-aware
service interface in draft-ietf-bess-rfc7432bis
Hi Sasha,
Thanks for your insightful comments. A few comments:
1) The text that you provided, gives further clarification to the existing
text and thus I will incorporate it with some modifications as below:
"In the case where a single VLAN is represented by a single VID and
thus no VID translation is required for the operational duration of
that VLAN , an MPLS-encapsulated packet MUST
carry that VID and the Ethernet Tag ID in all EVPN routes advertised for
this BD
MUST be set to that VID. The advertising PE SHOULD advertise the MPLS Label
in the
Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1
in the MAC/IP Advertisement routes representing both the Ethernet Tag ID
and the EVI but MAY advertise the labels representing ONLY the EVI.
This decision is only a local matter by the advertising PE which
is also the disposition PE) and doesn't affect any other PEs."
2) For the use case that you provided where a single VLAN can be
represented by multiple VIDs (although at the later time where the VLAN starts
with a single VID and then additional VID is configured for the same VLAN), is
more appropriate to the 2nd paragraph that you quoted below. Basically, if the
operator knows that at some point, there will be multiple VIDs for a VLAN, then
they should follow the 2nd para text.
3) I will clarify what normalized VID mean (i.e., a unique VID network
wide in context of an EVI). Although this VID is not used explicitly in data
plane, it is used implicitly because it identifies the BD and thus the bridge
table for incoming packets at the ingress PE. Even though the tag translation
is done at the egress PE.
Cheers,
Ali
From: Alexander Vainshtein
<alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>
Date: Tuesday, November 29, 2022 at 2:18 AM
To:
draft-ietf-bess-rfc7432bis.auth...@ietf.org<mailto:draft-ietf-bess-rfc7432bis.auth...@ietf.org>
<draft-ietf-bess-rfc7432bis.auth...@ietf.org<mailto:draft-ietf-bess-rfc7432bis.auth...@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>,
Ron Sdayoor <ron.sday...@rbbn.com<mailto:ron.sday...@rbbn.com>>, Moti
Morgenstern <moti.morgenst...@rbbn.com<mailto:moti.morgenst...@rbbn.com>>,
Nitsan Dolev <nitsan.do...@rbbn.com<mailto:nitsan.do...@rbbn.com>>, Michael
Gorokhovsky <michael.gorokhov...@rbbn.com<mailto:michael.gorokhov...@rbbn.com>>
Subject: A doubt in the requirements pertaining to VLAN-aware service interface
in draft-ietf-bess-rfc7432bis
Hi all,
I have some doubts in the following requirement for Ethernet Tag ID in Section
6.3 of the 7432bis
draft<https://clicktime.symantec.com/15siF9byzEiFPAhs8AxLb?h=vgZyn6M9g5pMAup4Gz6UGHO0ysNqEHAPmpqoYioaG4A=&u=https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-05%23section-6.3>
(the problematic text is highlighted):
In the case where a single VLAN is represented by a single VID and
thus no VID translation is required, an MPLS-encapsulated packet MUST
carry that VID. The Ethernet Tag ID in all EVPN routes MUST be set
to that VID. The advertising PE MAY advertise the MPLS Label in the
Ethernet A-D per EVI and MPLS Label1 in the MAC/IP Advertisement
routes representing ONLY the EVI or representing both the Ethernet
Tag ID and the EVI. This decision is only a local matter by the
advertising PE (which is also the disposition PE) and doesn't affect
any other PEs.
In the case where a single VLAN is represented by different VIDs on
different CEs and thus VID translation is required, a normalized
Ethernet Tag ID (VID) MUST be carried in the EVPN BGP routes.
Furthermore, the advertising PE advertises the MPLS Label1 in the
MAC/IP Advertisement route representing both the Ethernet Tag ID and
the EVI, so that upon receiving an MPLS-encapsulated packet, the
advertising PE can identify the corresponding bridge table from the
MPLS EVPN label and perform Ethernet Tag ID translation ONLY at the
disposition PE -- i.e., the Ethernet frames transported over the
MPLS/IP network MUST remain tagged with the originating VID, and VID
translation is performed on the disposition PE. The Ethernet Tag ID
in all EVPN routes MUST be set to the normal
First of all, please note that the quoted text does not mention Inclusive
Multicast Ethernet Tag routes and the labels advertised in them at all.
My doubts are based on the following scenario:
1. Suppose that originally all the BDs in an EVI that implements
VLAN-aware Bundle service interface has been has been created with the same per
BD VID delimiting all the attachment circuits network-wide (in all the PEs). In
accordance with the highlighted requirement, Ethernet Tag ID in all EVPN routes
advertised for this BD has been set to the VID in question and at least some
(may be all) the PEs have allocated only per-EVI labels for these routes.
2. Suppose further that a new attachment circuit delimited by a different
single VID (and configured with egress VLAN translation) is now added to this
BD in one of the PEs:
a. The highlighted requirements are now applicable, and the EVPN Type 2
routes now must carry labels that represent both the Ethernet Tag ID and the
EVI.
b. This presumably means that all the previously advertised EVPN Type 2
routes for this BD MUST be withdrawn, and new ones - carrying labels that
represent both the EVI and the specific BD - advertised. The same applies to
EVPN Type 3 routes for the affected BD. My guess that this would result in a
substantial traffic disruption at least for the affected BD - but most probably
for all the BDs in this EVI.
Please note that if labels advertised in EVPN per EVI Type 1, Type 2 and Type 3
routes were always allocated to represent t6he {EVI, Ethernet Tag ID} pairs,
the problem would not occur.
May I suggest replacing the problematic (for me) para with the new text as
following (the changes vs. the current text are highlighted):
In the case where a single VLAN is represented by a single VID and
thus no VID translation is required, an MPLS-encapsulated packet MUST
carry that VID. The Ethernet Tag ID in all EVPN routes advertised for this
BD
MAY be set to that VID. The advertising PE SHOULD advertise the MPLS Label
in the
Ethernet A-D per EVI and Inclusive Multicast routes and MPLS Label1
in the MAC/IP Advertisement routes representing both the Ethernet Tag ID
and the EVI but MAY advertise the labels representing ONLY the EVI.
This decision is only a local matter by the advertising PE which
is also the disposition PE) and doesn't affect any other PEs.
May I also suggest not to use the term "normalized Ethernet Tag" in the next
para because:
- It is not actually defined anywhere
- It carries (from my POV) some data plane-related connotations while
in fact it only is seen in the EVPN control plane entities and does not affect
the data plane at all.
3.
Your feedback would be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
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.
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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
