Sent: Sunday, September 24, 2023 11:33:17 AM
To: Ali Sajassi (sajassi) <sajassi=40cisco.com@xxxxxxxxxxxxxx>; Brian Haberman <brian@xxxxxxxxxxxxxxxxxx>; int-dir@xxxxxxxx <int-dir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>; draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx <draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
- Just one IMET route is advertised per BD and so the information it carties cznnot be associated with any specific ES
- 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.
Sent: Sunday, September 24, 2023 9:05:18 AM
To: Ali Sajassi (sajassi) <sajassi=40cisco.com@xxxxxxxxxxxxxx>; Brian Haberman <brian@xxxxxxxxxxxxxxxxxx>; int-dir@xxxxxxxx <int-dir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>; draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx <draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: Intdir telechat review of draft-ietf-bess-evpn-virtual-eth-segment-13
Sent: Saturday, September 23, 2023 11:07:23 PM
To: Brian Haberman <brian@xxxxxxxxxxxxxxxxxx>; int-dir@xxxxxxxx <int-dir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>; draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx <draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>
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 <noreply@xxxxxxxx>
Date: Wednesday, September 6, 2023 at 11:49 AM
To: int-dir@xxxxxxxx <int-dir@xxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>, draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx <draft-ietf-bess-evpn-virtual-eth-segment.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
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/.
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
