Ali,
Lots of thanks for a prompt response.
I have probably been not clear enough in my sequence of messages in this thread.
To clarify my position:
- I do not have any issues with the latest (-14) version of the Virtual Ethernet Segment draft.
- I fully agree that “mechanism for checking L2 Attribute (e.g., MTU) is independent of physical/virtual nature of ES and whatever procedure(s) that applies to physical ES, also applies
to virtual ESI. I also think that, in the case of “bridging” EVPN, the scope of MTU a specific Broadcast Domain and not any individual Ethernet Segment (physical or virtual) to which this Broadcast Domain is attached.
- I see that L2-Attributes Extended Community is not mentioned in the -014 version of the draft in any way. Therefore, there is no need to add a reference to the 7432bis draft that extends
its usage to “bridging” EVPN.
I apologize for possible churn my previous emails have introduced.
From: BESS <bess-bounces@xxxxxxxx>
On Behalf Of Ali Sajassi (sajassi)
Sent: Sunday, September 24, 2023 8:26 PM
To: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>; Ali Sajassi (sajassi) <sajassi=40cisco.com@xxxxxxxxxxxxxx>; Brian Haberman <brian@xxxxxxxxxxxxxxxxxx>; int-dir@xxxxxxxx
Cc: bess@xxxxxxxx; draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx; last-call@xxxxxxxx
Subject: [EXTERNAL] Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
Hi Sasha,
The point that I was trying to make in my response to Brian is that the mechanism for checking L2 Attribute (e.g., MTU) is independent of physical/virtual nature of ES and whatever procedure(s) that applies to
physical ES, also applies to virtual ES.
Now, if you have a question or issue with respect to why we are using IMET route for some L2 attributes and Ethernet-AD per EVI route for some other L2 attributes, then this question/issue needs to be raised (and
subsequently) addressed in context to 7432bis draft.
Cheers,
Ali
I support advancing the draft "as is".
My earlier comments are just about the responses to one if Brian's comments.
Get
Outlook for Android
IMHO and FWIW even the usage of EVPN L2 -Attributes Extended Community for "bridging" EVPN shall not address the issue raised by Brian because:
1.
Just one IMET route is advertised per BD and so the information it carties cznnot be associated with any specific ES
2.
With "bridging EVPN, per-EVI Ethernet A-D routes are advertised just for
multi-homed ES, therefore they cannot be used to distribute any information about singke-homed vES.
Get
Outlook for Android
I am concerned about Ali's response to one of Bryan's comments (copied below):
MTU size, control word, flow label, and other L2 attributes are carried in EVPN L2-Attribute Extended Community which is sent along with IMET route or Ether A-D per
EVI route. These are independent of whether an Ethernet Segment is physical or virtual.
EVPN L2-Attributes Extended Community has been introduced in RFC 8214 for usage with EVPN-VPWS and per-EVI Ethernet A-D routes only.
Its extension to "bridging" EVPN and its usage with IMET routes has been proposed in 7432bis, but the Virtual Ethernet Segment draft does not reference this document.
Get
Outlook for Android
Hi Brian,
Thanks for the review and your comments. I have incorporated your comments into the rev14 of this draft. Please refer to my inline responses below marked with [AS].
Reviewer: Brian Haberman
Review result: Ready with Issues
I am an assigned INT directorate reviewer for
draft-ietf-bess-evpn-virtual-eth-segment. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see
https://datatracker.ietf.org/group/intdir/about/.
Major Issues:
Minor Issues:
* Section 1.2 talks about this document defining extensions for RFCs 7432 and
7623. Should this document formally update those RFCs?
[AS] The draft does not update the procedures for RFC7432 and RFC7623 but rather it defines the concept of a vES and the extensions needed to support a vES. I have changed the text in section 1.2 to reflect this clarification.
* I am by no means an EVPN expert, so I am curious if there is additional
functionality needed to ensure consistency of ethernet-level configuration
options across the vES (e.g., Max Frame Size) given the mix of technologies
supported.
[AS] MTU size, control word, flow label, and other L2 attributes are carried in EVPN L2-Attribute Extended Community which is sent along with IMET route or Ether A-D per EVI route. These are independent of whether an Ethernet Segment is physical or virtual.
Nits:
* General
- There are multiple instances of confusing sentence structure throughout
the document. Highly recommend getting a native English speaker familiar
with the technology to make an editorial pass through the document. - Are
phrases such as "out-of-franchise customer sites" well-known in this
community?
[AS] change the sentence for better clarification from “to reach out-of-franchise customer sites …” to “to reach remote customer sites …”
* Abstract
- Using undefined acronyms in the Abstract is a bit confusing.
- The second-half of the first sentence is difficult to parse.
[AS] expanded EVPN and PBB-EVPN acronyms.
* Introduction
- The first sentence has the same parsing issues as the first sentence in
the Abstract.
[AS] changed that as well.
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.
|
