[nvo3] Lars Eggert's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)
Lars Eggert via Datatracker <noreply@ietf.org> Mon, 24 April 2023 14:50 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: nvo3@ietf.org
Delivered-To: nvo3@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E63C153CA8; Mon, 24 Apr 2023 07:50:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nvo3-evpn-applicability@ietf.org, nvo3-chairs@ietf.org, nvo3@ietf.org, Sam Aldrin <aldrin.ietf@gmail.com>, aldrin.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 10.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <168234784191.28048.2470003306531458498@ietfa.amsl.com>
Date: Mon, 24 Apr 2023 07:50:41 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/Sh9uV6duJv8xXuLZDYR6AlIZntc>
Subject: [nvo3] Lars Eggert's No Objection on draft-ietf-nvo3-evpn-applicability-05: (with COMMENT)
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Apr 2023 14:50:42 -0000
Lars Eggert has entered the following ballot position for draft-ietf-nvo3-evpn-applicability-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-nvo3-evpn-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # GEN AD review of draft-ietf-nvo3-evpn-applicability-05 CC @larseggert Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/aaqvb7lSJAu_1M2KpEt2AVal4bQ). ## Comments ### Section 2, paragraph 17 ``` * Ethernet Tag: Used to represent a Broadcast Domain that is configured on a given ES for the purpose of Designated Forwarder election. Note that any of the following may be used to represent a Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs, VNIs (Virtual Extensible Local Area Network (VXLAN) Network Identifiers), normalized VIDs, I-SIDs (Service Instance Identifiers), etc., as long as the representation of the Broadcast Domains is configured consistently across the multihomed PEs attached to that ES. The Ethernet Tag value MUST be different from zero. ``` The "MUST" in the last sentence is the only RFC2119 keyword in the document. Can we rephrase to avoid it, and loose the BCP14 boilerplate text entirely? (You could IMO just remove the entire last sentence.) ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `traditional`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 2, paragraph 19 ``` - Route-Distinghisher (RD) and Route-Target(s) (RTs) are required - ^ + Route-Distinguisher (RD) and Route-Target(s) (RTs) are required + ^ ``` #### Section 2, paragraph 21 ``` - Route Distinghisher (RD) and Route Target(s) (RTs) are required - ^ + Route Distinguisher (RD) and Route Target(s) (RTs) are required + ^ ``` #### Section 3, paragraph 9 ``` - configured egress NVE destination IP addresss in the Broadcast - - ``` #### Section 4.7.5, paragraph 3 ``` - * All-active multi-homing means per-flow load-balanding for unicast - ^ + * All-active multi-homing means per-flow load-balancing for unicast + ^ ``` ### Outdated references Document references `draft-sajassi-bess-secure-evpn-05`, but `-06` is the latest available revision. Document references `draft-ietf-bess-evpn-lsp-ping-08`, but `-09` is the latest available revision. Document references `draft-ietf-bess-evpn-geneve-04`, but `-05` is the latest available revision. Document references `draft-ietf-bess-rfc7432bis-04`, but `-07` is the latest available revision. Document references `draft-ietf-bess-evpn-pref-df-09`, but `-10` is the latest available revision. Document references `draft-ietf-nvo3-encap-08`, but `-09` is the latest available revision. Document references `draft-ietf-bess-evpn-irb-mcast-07`, but `-09` is the latest available revision. Document references `draft-ietf-bess-evpn-mvpn-seamless-interop-04`, but `-05` is the latest available revision. ### Grammar/style #### Section 2, paragraph 19 ``` VRF and they are normally different than the ones defined in the associated ^^^^ ``` Did you mean "different from"? "Different than" is often considered colloquial style. #### Section 3, paragraph 1 ``` nels. When the destination host replies back and the frames arrive at the NVE ^^^^^^^^^^^^ ``` Consider using "replies". #### Section 4.1, paragraph 2 ``` , where MACs and the information to setup flooding trees are distributed by M ^^^^^ ``` The verb "set up" is spelled as two words. The noun "setup" is spelled as one. #### Section 4.2.2, paragraph 1 ``` in MAC/IP Advertisement routes in a similar way. * The remote NVEs can then ^^^^^^^^^^^^^^^^ ``` Consider replacing this phrase with the adverb "similarly" to avoid wordiness. #### Section 4.3, paragraph 5 ``` 3. In addition, NVE2 would advertise a IP Prefix route with TS3's IP address ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". #### Section 4.7.2, paragraph 3 ``` iven Broadcast Domain. For instance, an virtual-switch NVE that learns all it ^^ ``` Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". #### Section 4.7.4, paragraph 3 ``` RFs in NVE1 and NVE2 are connected by a SBD (Supplementary Broadcast Domain) ^ ``` Use "an" instead of "a" if the following word starts with a vowel sound, e.g. "an article", "an hour". ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
- [nvo3] Lars Eggert's No Objection on draft-ietf-n… Lars Eggert via Datatracker
- Re: [nvo3] Lars Eggert's No Objection on draft-ie… Jorge Rabadan (Nokia)