Hi Benjamin, Please see my comments in-line with [JORGE]. And please, let us know if we are addressing your concerns with this, before publishing the new version.
Thank you for the thorough review! Jorge -----Original Message----- From: Benjamin Kaduk <[email protected]> Date: Wednesday, May 9, 2018 at 5:14 PM To: The IESG <[email protected]> Cc: "[email protected]" <[email protected]>, Zhaohui Zhang <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT) Resent-From: <[email protected]> Resent-To: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent-Date: Wednesday, May 9, 2018 at 5:14 PM 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? [JORGE] as already discussed, we'll keep draft-ietf-bess-evpn-inter-subnet-forwarding as a Normative reference and update that one as soon as possible. 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? [JORGE] Yes, it does apply. The SBD is a special BD that connects NVEs of the same tenant that are not attached to the same BD. The use cases where the SBD is needed are described in 4.4.2 and 4.4.3. Section 4.4.1 does not need an SBD. The sentence above describes any of the cases in 4.4 and in all of them the RT-5 is needed. 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. [JORGE] well, not really. ESI and GW IP cannot both be NON-ZERO at the same time. That's why there are no combinations in the table where both are non-zero. I understand it may be confusing.. I changed it slightly trying to make it clearer: " o The ESI and GW IP fields may both be zero at the same time. 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]." 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)? [JORGE] The Table shows the combinations that are needed/described in the use-cases. The combinations that are not shown in the table were almost covered by these two first bullets, however I extended the second bullet and added a third one. With this, all the combinations are addressed: " o The ESI and GW IP fields may both be zero at the same time. 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]. o If either the ESI or GW IP are non-zero, then one of them is the Overlay Index, regardless of whether the Router's MAC Extended Community is present or the value of the Label. **In case the GW IP is the Overlay Index (hence ESI is zero), the Router's MAC Extended Community is ignored if present.** o **A route where ESI, GW IP, MAC and Label are all zero at the same time SHOULD be 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. [JORGE] good point. I modified the sentence: "Each RT-5 will be sent with a route-target identifying the tenant (IP-VRF) and **may be sent** with two BGP extended communities:" ---------------------------------------------------------------------- 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? [JORGE] there is text already that tries to justify why we need the use-cases 4.1, 4.2 and 4.3. Among those three it really depends on the capabilities of the Tenant Systems. Those use-cases were the ones that we agreed over the years that had to be covered. The use-cases in 4.4 are different, and the text refers to the [EVPN-INTERSUBNET] draft for the justification, only with the additional requirement of advertising prefixes rather than only host routes. Based on this, would you think adding extra text in 4.4, as opposed to only refer to the other draft would help? It might be worth sorting the definitions in Section 1 to help readers find specific definitions as they refer back. [JORGE] Done. (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.) [JORGE] done. Nitpicking, but is "GARP message" or "gratuitous ARP message" the more common usage? "GARP" is only used once other than the definition... [JORGE] Replaced by "GARP message" "TOR" (actually "ToR"?) is not defined here. [JORGE] I expanded ToR. "NLRI", "VTEP", "ESI", "ES", "AD" as well. [JORGE] I added this sentence at the end of the terminology section: "This document also assumes familiarity with the terminology of [RFC7432]." 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? [JORGE] ok, changed to: "o Note that the same IP address and endpoint could exist behind two of these TSes." 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. [JORGE] I modified the last bullet to reflect this better: " o IP Prefix and GW IP address in the route must be of the same family. 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 (since IPv4 and IPv6 mixed values are not allowed)." Also, maybe "The GW IP field MUST be zero" should say "all bytes zero". [JORGE] done. Does the recursive resolution requirement represent a risk of DoS via resource consumption? (Is the recursion depth limited to one additional resolution?) [JORGE] yes, it is limited to one additional resolution only, indicated by the overlay index. An RT-5 cannot be resolved to another RT-5. Still in Section 3.1, please say something about the other 4 bits, even if it's "zero on send, ignore on receive". [JORGE] I added this: "o The MPLS Label field is encoded as 3 octets, where the high-order 20 bits contain the label value, ***as per [RFC7432].***" Since the encoding must follow the same rules as the rest of the routes in the AFI/SAFI. 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.) [JORGE] I removed it and added this in section 4, let me know: "Although the examples use IPv4 Prefixes and subnets, the descriptions of the RT-5 are valid for the same cases with IPv6, only replacing the IP Prefixes, IPL and GW IP by the corresponding IPv6 values." In Section 4.4.2, does the "GS IP address=IRB-IP" refer to the IP of the SBD? [JORGE] yes, added "IRB-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)? [JORGE] Absolutely, RT-5 and RT-2 identify different things, however, since RT-5s can only populate the IP-VRF and the RT-2 the L2 FIB and ARP tables, they can use the same route-target and there is no ambiguity for a receiving router. In current deployments, we find both cases, people using the same route-target in IP-VRF and SBD, and people using different route-targets in both IP-VRF and SBD. Let us know if you think we need to clarify the text in this respect. 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. [JORGE] you are right, good catch. It's fixed now. 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.) [JORGE] Added, thank you! _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
