Summary: Needs 6 more YES or NO OBJECTION positions to pass.
Only minor comments here; please consider them, but there’s no need for a detailed reply. A number of abbreviations need to be expanded on first use, including EVPN, PE, ND, IRB, and CE. — Abstract — The Abstract is exactly, word for word, the same as the first two paragraphs of the Introduction, except that the Introduction helpfully splits it into two paragraphs. I have comments about the text below, but for the Abstract I suggest shortening it by removing the explanatory stuff and just leaving the summay of what this document is doing — just the final sentence looks fine, I think. — Section 1 — An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or IPv6 addresses associated with a MAC address. Nit: Change “an IPv4” to just “IPv4”, I think, yes? the PE would not know if that particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address Two things here: This is a case where a comma after “router” will really help readability. And isn’t “a host with an anycast address” also “a host”? Can you rephrase this to make the distinction between the first and third list items clearer? — Section 1.1 — Shouldn’t “ND” also have a reference citation (RFC4861)? — Section 2 — Bits 0-3 and 5 are not assigned by this document. Shouldn’t this have the customary “MUST be set to zero, and ignored on receipt” text? — Section 4 — This will cause all the PEs in the BD to reply Neighbor Solicitations for the IPv6 with Neighbor Advertisement messages containing the wrong R and O Flags. There’s a word missing here after “reply”: I presume the missing word is “to”.
Thank you for the work put into this document. Even if I mainly rely on the int-dir review (see below), I quickly reviewed the document and found it very useful and readable. Thanks to Ralf Weber who did the INT directory review, at https://datatracker.ietf.org/doc/review-ietf-bess-evpn-na-flags-05-intdir-lc-weber-2020-08-28/ Please find below a couple of non-blocking COMMENT and NIT points. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2 -- For my curiosity sake, why bit 5 of the 'Flags field' is not described? I would have naively assumed that all flags would be contiguous. == NITS == -- Section 2 -- While it is specified that the reserved fields are set to 0, the usual 'and ignored by the receiver' is not present. When describing the 'Router Flag', I suggest s/belongs to a router. /belongs to an IPv6 router./ even if fairly obvious