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.
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
