Ignas Bagdonas has entered the following ballot position for draft-ietf-bess-evpn-prefix-advertisement-10: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- NVGRE and VXLAN-GPE references throughout the document – would be better to replace with Geneve, as NVGRE is historic, and GPE will wait until Geneve progresses. This does not change the logic of operation for non-Ethernet NVO tunnels. s2.1, last bullet: TS4 connectivity is not required to be physical, it is just connectivity. s3.2: s/fail to install/MUST not install s4.3, steps 1 and 2: what if MAC address is both signaled and learned by policy? How would such conflict be resolved? Which one would take precedence? s2: s/program/propagate A few assorted nits: Document would benefit from reduction of hyphenation of common terms and normalizing the spelling of the terms throughout the document (as an example, there are forms of route type, route-type, and Route Type intermixed). Re-advertise, stripped-off, mass-withdrawal, ip-lookup, mac-lookup, re-used, inter-subnet-forwarding, next-hop. s/route-target/Route Target s/layer-2/layer 2 s/layer-3/layer 3 RT-2, RT-5: please consider unifying the terminology and use route type 2/route type 5, RFC7432 does not use RT-x notation. S4.4.2: s/IP10/IP1 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
