Hi Ignas, Thank you very much for your review. We addressed all your comments. Please see below.
Thanks, Jorge -----Original Message----- From: Ignas Bagdonas <ibagd...@gmail.com> Date: Tuesday, May 8, 2018 at 9:25 AM To: The IESG <i...@ietf.org> Cc: "draft-ietf-bess-evpn-prefix-advertisem...@ietf.org" <draft-ietf-bess-evpn-prefix-advertisem...@ietf.org>, Zhaohui Zhang <zzh...@juniper.net>, "aretana.i...@gmail.com" <aretana.i...@gmail.com>, "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "zzh...@juniper.net" <zzh...@juniper.net>, "bess@ietf.org" <bess@ietf.org> Subject: Ignas Bagdonas' No Objection on draft-ietf-bess-evpn-prefix-advertisement-10: (with COMMENT) Resent-From: <alias-boun...@ietf.org> Resent-To: <jorge.raba...@nokia.com>, <wim.henderi...@nokia.com>, <jdr...@juniper.net>, <w...@juniper.net>, <saja...@cisco.com> Resent-Date: Tuesday, May 8, 2018 at 9:25 AM 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. [JORGE] ok, done. s2.1, last bullet: TS4 connectivity is not required to be physical, it is just connectivity. [JORGE] I removed "physical" s3.2: s/fail to install/MUST not install [JORGE] added MUST NOT 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? [JORGE] added: ", however the MAC in the Extended Community is preferred if sent with the route." s2: s/program/propagate [JORGE] ok, done. 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. [JORGE] ok, I removed some s/route-target/Route Target [JORGE] ok, done. s/layer-2/layer 2 [JORGE] ok, done. s/layer-3/layer 3 [JORGE] ok, done. RT-2, RT-5: please consider unifying the terminology and use route type 2/route type 5, RFC7432 does not use RT-x notation. [JORGE] since they are defined in the terminology section, I think it should be fine? I left them S4.4.2: s/IP10/IP1 [JORGE] I think IP10 is correct _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess