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. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
