On Tue, May 15, 2018 at 05:31:29PM +0000, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Benjamin, > > Thank you again for replying. > About this comment: > > "Okay. I would suggest adding a note in the table's caption about > the status of cases not listed in the table, but your text above > does seem to cover everything." > > I added the following note: > "If the combination of ESI, GW IP, MAC and Label in the receiving RT-5 is > different than the combinations shown in Table 1, the router will process the > route as per the rules described at the beginning of this section (3.2)." > > With that, I think we've addressed all your concerns. Let us know if it is > not the case.
The above works for me; thanks again. -Benjamin > We'll make a few more changes suggested by the other reviewers and then > publish the revision 11. > > Thank you! > Jorge > > > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Date: Tuesday, May 15, 2018 at 6:55 PM > To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com> > Cc: The IESG <i...@ietf.org>, Zhaohui Zhang <zzh...@juniper.net>, > "bess-cha...@ietf.org" <bess-cha...@ietf.org>, > "draft-ietf-bess-evpn-prefix-advertisem...@ietf.org" > <draft-ietf-bess-evpn-prefix-advertisem...@ietf.org>, "bess@ietf.org" > <bess@ietf.org>, "aretana.i...@gmail.com" <aretana.i...@gmail.com> > Subject: Re: Benjamin Kaduk's Discuss on > draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT) > > On Mon, May 14, 2018 at 12:17:38PM +0000, Rabadan, Jorge (Nokia - > US/Mountain View) wrote: > > 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 <ka...@mit.edu> > > Date: Wednesday, May 9, 2018 at 5:14 PM > > To: The IESG <i...@ietf.org> > > Cc: "draft-ietf-bess-evpn-prefix-advertisem...@ietf.org" > <draft-ietf-bess-evpn-prefix-advertisem...@ietf.org>, Zhaohui Zhang > <zzh...@juniper.net>, "aretana.i...@gmail.com" <aretana.i...@gmail.com>, > "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "zzh...@juniper.net" > <zzh...@juniper.net>, "bess@ietf.org" <bess@ietf.org> > > Subject: Benjamin Kaduk's Discuss on > draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT) > > Resent-From: <alias-boun...@ietf.org> > > Resent-To: <jorge.raba...@nokia.com>, <wim.henderi...@nokia.com>, > <jdr...@juniper.net>, <w...@juniper.net>, <saja...@cisco.com> > > 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. > > Sounds good. > > > 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. > > Okay, thanks for clarifying. > > > 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]." > > Ah, this was just a misreading on my part, sorry for the confusion. > The proposed text does help, thanks. > > > > > > > > > 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.**" > > Okay. I would suggest adding a note in the table's caption about > the status of cases not listed in the table, but your text above > does seem to cover everything. > > > > > 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:" > > Okay. > > > > > > ---------------------------------------------------------------------- > > 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? > > When I was reading the text in Sections 4.1-4.3 it seemed more like > "[prefix-advertisement] can be used in a topology like this" rather > than "someone might want to use [prefix-advertisement] in a topology > like this because [reason]". But I guess that a lot of the time the > topology is already determined by the existing deployment, and the > options for this new protocol are not going to impact what topology > gets used anyway, so maybe the existing text is fine for its > intended audience. > > > > > 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." > > Thanks! > > > > > 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. > > Thanks (for both). > > > 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. > > Okay, with only a single additional resolution there shouldn't be > much DoS risk. > > > 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. > > I guess that is okay, especially if (as far as I can tell in a quick > skim) RFC 7432 doesn't say what to do with the other 4 bits, either. > > > > > 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." > > I mentioned this in the context of > https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ which has "We > recommend that [...] use IPv6 examples". But my comment is not > blocking. > > > > > 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" > > Thanks. > > > > > 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. > > It sounds like this should be pretty clear to people who understand > the surrounding protocol (as opposed to me), so I don't see a need > to change the text. Thank you for the explanation! > > > 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! > > Thanks for all the updates! > > -Benjamin > > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
