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. 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. 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 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? _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
