IP Prefix Advertisement in Ethernet VPN (EVPN)
draft-ietf-bess-evpn-prefix-advertisement-11
Yes
(Alvaro Retana)
No Objection
(Deborah Brungard)
(Martin Vigoureux)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 10 and is now closed.
Warren Kumari
No Objection
Comment
(2018-05-10 for -10)
Unknown
NoObjection in the "I read the protocol action, and I trust the sponsoring AD so have no problem." / ran out of cycles sense.
Alvaro Retana Former IESG member
Yes
Yes
(for -10)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(2018-05-09 for -10)
Unknown
The density of unexpanded acronyms makes this document particularly challenging to read. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - EVPN - NVO - MAC - VXLAN - nvGRE - PE - TOR - IP-VPN - VM - ESI - NLRI - VTEP - VSID - ES - AD - GPE - sBD - DA - ABR - CE
Alissa Cooper Former IESG member
No Objection
No Objection
(2018-05-09 for -10)
Unknown
The Gen-ART reviewer did an in-depth review and I have not seen any response yet: https://datatracker.ietf.org/doc/review-ietf-bess-evpn-prefix-advertisement-10-genart-lc-davies-2018-04-14/
Ben Campbell Former IESG member
No Objection
No Objection
(2018-05-09 for -10)
Unknown
I agree with Alissa that the GenART review should be addressed.
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2018-05-21)
Unknown
Thank you for addressing my comments! I leave the original ballot text below for reference. DISCUSS There are a lot of places where the actual requirements seem (potentially) ambiguously written or incomplete, or the document is internally inconsistent. I expect that at least some of these are just confusion on my part, so hopefully someone can clue me in on where I'm going astray. Not exactly a DISCUSS, but is there a plan for resolving the normative reference to the expired draft-ietf-bess-evpn-inter-subnet-forwarding? Does Section 3's [...] In case two or more NVEs are attached to different BDs of the same tenant, they MUST support RT-5 for the proper Inter-Subnet Forwarding operation of the tenant. apply even when there is a SBD between them in the topology, or does something in the SBD also need to support RT-5 in such cases? Section 3.2's o The ESI and GW IP fields may both be zero, however they MUST NOT both be non-zero at the same time. A route containing a non-zero GW IP and a non-zero ESI (at the same time) SHOULD be treat-as- withdraw [RFC7606]. seems to say that ESI and GW IP cannot both be zero at the same time, but there seem to be entires in Table 1 that have that be the case. There are also potential combinations not included in Table 1 -- are we supposed to infer that anything not listed is an error condition (and thus treat-as-withdraw)? Section 4.4.1's Each RT-5 will be sent with a route-target identifying the tenant (IP-VRF) and two BGP extended communities: seems to say that there will always be these two extended communities, but there seems to be other text later implying that the "Router's MAC" extended community is not always present. COMMENT There seem to be a lot of different mechanisms listed to do the same thing, and not much guidance on in what scenarios each one is better/worse (i.e., some justification for including this much flexibility instead of a smaller number of generally applicable options). Is that something the authors are interested in adding? It might be worth sorting the definitions in Section 1 to help readers find specific definitions as they refer back. (Also, "EVPN" is not marked as well-known on the RFC Editor's list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) and thus would be expected to be defined as well.) Nitpicking, but is "GARP message" or "gratuitous ARP message" the more common usage? "GARP" is only used once other than the definition... "TOR" (actually "ToR"?) is not defined here. "NLRI", "VTEP", "ESI", "ES", "AD" as well. Section 2.1 o Note that the same IP address could exist behind two of these TS. It sounds like this is "same IP address and endpoint" as opposed to "same IP address due to multiple endpoints being assigned the same (e.g., private) IP address in different domains"? Should that be specifically clarified? In Section 3.1, when adapting to other reviews and noting how the IPv4/IPv6 distinction is made, perhaps it would also be good to note that the IP Prefix and GW IP Address must represent the same family. Also, maybe "The GW IP field MUST be zero" should say "all bytes zero". Does the recursive resolution requirement represent a risk of DoS via resource consumption? (Is the recursion depth limited to one additional resolution?) Still in Section 3.1, please say something about the other 4 bits, even if it's "zero on send, ignore on receive". Section 4.1 The parenthetical about "(ND-snooping if IPv6)" does not make much sense in the context of an example that explictly uses IPv4. (Additionally, there should probably be some IPv6 examples.) In Section 4.4.2, does the "GS IP address=IRB-IP" refer to the IP of the SBD? Section 4.4.2 (1) NVE1 advertises the following BGP routes: o Route type 5 (IP Prefix route) containing: . IPL=24, IP=SN1, Label= SHOULD be set to 0. . GW IP=IP1 (sBD IRB's IP) . Route-target identifying the tenant (IP-VRF). o Route type 2 (MAC/IP route for the SBD IRB) containing: . ML=48, M=M1, IPL=32, IP=IP1, Label=10. . A [RFC5512] BGP Encapsulation Extended Community. . Route-target identifying the SBD. This route-target may be the same as the one used with the RT-5. I don't understand how the route-target can be the same for the RT-5 and RT-2 routes -- aren't they identifying different things (tenant and SBD)? Also, "NVE1 IP" is used in the body text, but in the figure I think this would just be "IP1"? I am less sure what "NVE1 IP" is supposed to be in Section 4.4.3. The Security Considerations talk of a security advantage from blocking dynamic routing protocols on the NVE/PE ACs; this would seem more relevant if phrased as "not allowing the tenant to interact with the infrastructure's dynamic routing protocols". (The customer could of course tunnel whatever sort of dynamic routing protocol they want over the EVPN.)
Deborah Brungard Former IESG member
No Objection
No Objection
(for -10)
Unknown
Eric Rescorla Former IESG member
No Objection
No Objection
(2018-05-09 for -10)
Unknown
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?
Ignas Bagdonas Former IESG member
No Objection
No Objection
(2018-05-08 for -10)
Unknown
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
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -10)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -10)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -10)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -10)
Unknown