Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

[Alexander Vainshtein <[e-mail]>]

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:

  1.  I do not have any issues with the latest (-14) version of the Virtual Ethernet Segment draft.
  2.  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.
  3.  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.

Regards,
Sasha

From: BESS <[e-mail]> On Behalf Of Ali Sajassi (sajassi)
Sent: Sunday, September 24, 2023 8:26 PM
To: Alexander Vainshtein <[e-mail]>; Ali Sajassi (sajassi) <sajassi=[e-mail]>; Brian Haberman <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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

From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Sunday, September 24, 2023 at 2:05 AM
To: Ali Sajassi (sajassi) <sajassi=[e-mail]<mailto:sajassi=[e-mail]>>, Brian Haberman <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
Ali and all,
Just to make it clear:
I support advancing the draft "as is".

My earlier comments are just about the responses to one if Brian's comments.

My 2c,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, September 24, 2023 11:33:17 AM
To: Ali Sajassi (sajassi) <sajassi=[e-mail]<mailto:sajassi=[e-mail]>>; Brian Haberman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all,
More of the same...
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.
My 2c,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, September 24, 2023 9:05:18 AM
To: Ali Sajassi (sajassi) <sajassi=[e-mail]<mailto:sajassi=[e-mail]>>; Brian Haberman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

Ali and all,

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.

My 2c,
Sasha



Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Ali Sajassi (sajassi) <sajassi=[e-mail]<mailto:sajassi=[e-mail]>>
Sent: Saturday, September 23, 2023 11:07:23 PM
To: Brian Haberman <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [bess] Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13

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].

From: Brian Haberman via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, September 6, 2023 at 11:49 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
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/<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.