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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux