Hi Eric, Thank you very much for your review. I addressed all your comments, please see below.
Thanks. Jorge -----Original Message----- From: Eric Rescorla <[email protected]> Date: Thursday, May 10, 2018 at 2:44 AM To: The IESG <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, Zhaohui Zhang <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Eric Rescorla's No Objection on draft-ietf-bess-evpn-prefix-advertisement-10: (with COMMENT) Resent-From: <[email protected]> Resent-To: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent-Date: Thursday, May 10, 2018 at 2:44 AM Eric Rescorla 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: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4698 I found this document pretty dense and only gave it a light read. COMMENTS S 2.2 > independent of and not subject to the interpretation of the IPL and > the IP value. E.g.: a default IP route 0.0.0.0/0 must always be > easily and clearly distinguished from the absence of IP > information. > > o In MAC/IP routes, the MAC information is part of the NLRI, so if IP You need to define NLRI on first use. [JORGE] done. S 3.1 > > o The total route length will indicate the type of prefix (IPv4 or > IPv6) and the type of GW IP address (IPv4 or IPv6). Note that the > IP Prefix + the GW IP should have a length of either 64 or 256 > bits, but never 160 bits (IPv4 and IPv6 mixed values are not > allowed). Really shaving the bits tight here, I see. [JORGE] this is now changed, please see the new text. S 3.2 > Table 1 shows the different RT-5 field combinations allowed by this > specification and what Overlay Index must be used by the receiving > NVE/PE in each case. Those cases where there is no Overlay Index, are > indicated as "None" in Table 1. If there is no Overlay Index the > receiving NVE/PE will not perform any recursive resolution, and the > actual next-hop is given by the RT-5's BGP next-hop. How do I behave if something appears that is not on this table [JORGE] this is now clarified in the new rev. S 6. > overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc. > > d) An EVPN implementation not requiring IP Prefixes can simply > discard them by looking at the route type value. > > 6. Security Considerations I'm not sure that this is a security consideration, but does the ability to specify an IP as the next hop mean that you could route packets somewhere totally off EVPN? [JORGE] I think this should be covered by this sentence: "In addition, the security considerations in [RFC4364] should also be understood, since this document and [RFC4364] may be used in similar applications." That can also happen in IP-VPN... _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
