Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-evpn-prefix-advertisement-10: Discuss
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/ ---------------------------------------------------------------------- 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.) _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
