[bess] Lars Eggert's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-14: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-bess-evpn-inter-subnet-forwarding-14: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with John's point that the presentation of the material in this document
is very dense and likely doesn't lend itself to easily writing interoperable
implementations.

This document uses RFC2119 keywords, but does not contain the recommended
RFC8174 boilerplate. (It contains some text with a similar beginning.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditionally"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".

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

Section 2. , paragraph 6, nit:
-    traffic is treated as L2 traffic and it is bridged.  Also vise versa,
-                                                                ^
+    traffic is treated as L2 traffic and it is bridged.  Also vice versa,
+                                                                ^

Section 7. , paragraph 6, nit:
-    Depending on the expexted TS's behavior, an NVE needs to handle at
-                         ^
+    Depending on the expected TS's behavior, an NVE needs to handle at
+                         ^

Section 7. , paragraph 7, nit:
- 7.1.  Initiating a gratutious ARP upon a Move
-                          -
+ 7.1.  Initiating a gratuitous ARP upon a Move
+                         +

Section 5.5. , paragraph 2, nit:
> ese subnets. The reason for this is because ingress PE needs to do forwarding
>                                  ^^^^^^^^^^
The word "because" means "for the reason that" and thus introduces redundancy.

Section 9.1. , paragraph 5, nit:
> e actual implementation may differ. Lets consider data-plane operation when T
>                                     ^^^^
Did you mean "Let's" (let's = let us; lets = 3rd person singular of "let")?

Section 9.1. , paragraph 6, nit:
> n the egress NVE, if the packet arrives on Ethernet NVO tunnel (e.g., it is
>                                 ^^^^^^^^^^
The usual preposition after "arrives" is "at", not "on". Did you mean "arrives
at"?

Section 9.2. , paragraph 2, nit:
> e actual implementation may differ. Lets consider data-plane operation when a
>                                     ^^^^
Did you mean "Let's" (let's = let us; lets = 3rd person singular of "let")?

Document references draft-ietf-idr-tunnel-encaps, but that has been published
as RFC9012.

Document references draft-ietf-bess-evpn-irb-extended-mobility-03, but -05 is
the latest available revision.

Document references draft-ietf-nvo3-vxlan-gpe-10, but -11 is the latest
available revision.