Subject: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 09 May 2018 08:14:14 -0700

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

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 9 May 2018 13:17:47 -0700

On May 9, 2018 at 11:14:15 AM, Benjamin Kaduk ([email-masked]) wrote:

Hi!

Not exactly a DISCUSS, but is there a plan for resolving the normative
reference to the expired
draft-ietf-bess-evpn-inter-subnet-forwarding?

There are several overlapping authors and that document already had gone
through WGLC.  I believe the expiration has been due to other issues (day
job, and other documents) capturing the attention of the authors.  I’m not
concerned about their ability to progress it.

Thanks!

Alvaro.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 9 May 2018 21:00:36 +0000

Hi Alvaro,

You are right, the draft-ietf-bess-evpn-inter-subnet-forwarding has passed the WGLC but I need to take care of some last min. comments before publishing the next rev. Since prefix-advertisement draft will become RFC ahead of inter-subnet-forwarding, do we need to move the reference to informative?

Cheers,
Ali

From: Alvaro Retana <[email-masked]>
Date: Wednesday, May 9, 2018 at 1:17 PM
To: Benjamin Kaduk <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Zhaohui Zhang <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Cisco Employee <[email-masked]>
Resent-Date: Wednesday, May 9, 2018 at 1:17 PM

On May 9, 2018 at 11:14:15 AM, Benjamin Kaduk ([email-masked]<mailto:[email-masked]>) wrote:

Hi!

There are several overlapping authors and that document already had gone through WGLC.  I believe the expiration has been due to other issues (day job, and other documents) capturing the attention of the authors.  I’m not concerned about their ability to progress it.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 10 May 2018 06:15:51 -0700

On May 9, 2018 at 5:00:38 PM, Ali Sajassi (sajassi) ([email-masked])
wrote:

Ali:

Hi!

You are right, the draft-ietf-bess-evpn-inter-subnet-forwarding has passed
the WGLC but I need to take care of some last min. comments before
publishing the next rev. Since prefix-advertisement draft will become RFC
ahead of inter-subnet-forwarding, do we need to move the reference to
informative?

No, the reference has to be Normative because the Router's MAC Extended
Community was defined there.

Please focus on addressing the other parts of Benjamin’s DISCUSS.

Thanks!

Alvaro.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 10 May 2018 13:25:32 +0000

Hi Alvaro,

Thank you. We’ll keep it as normative then and try to progress draft-ietf-bess-evpn-inter-subnet-forwarding asap...
We’ll look into Benjamin’s comments first and then try to address the other suggestions given.

Should we wait for the telechat and your go-ahead before we publish a new version?

Thank you.
Jorge

From: Alvaro Retana <[email-masked]>
Date: Thursday, May 10, 2018 at 3:15 PM
To: Benjamin Kaduk <[email-masked]>, The IESG <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Zhaohui Zhang <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, May 10, 2018 at 3:15 PM

On May 9, 2018 at 5:00:38 PM, Ali Sajassi (sajassi) ([email-masked]<mailto:[email-masked]>) wrote:

Ali:

Hi!

No, the reference has to be Normative because the Router's MAC Extended Community was defined there.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 10 May 2018 07:29:52 -0700

On May 10, 2018 at 9:25:35 AM, Rabadan, Jorge (Nokia - US/Mountain View) (
[email-masked]) wrote:

Hi!

Should we wait for the telechat and your go-ahead before we publish a new
version?

We are in the Telechat right now…so please publish when you can.

Short note on process: the document won’t be approved today because it has
that outstanding DISCUSS.

Thanks!

Alvaro.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Mon, 14 May 2018 12:17:38 +0000

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-masked]>
Date: Wednesday, May 9, 2018 at 5:14 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Zhaohui Zhang <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, May 9, 2018 at 5:14 PM

    

    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
[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:"

[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?

[JORGE] Done.

[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"

[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

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

[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

    

    

    
    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.

[JORGE] Added, thank you!

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 May 2018 11:54:48 -0500

>     https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/

Sounds good.

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

Okay, thanks for clarifying.

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

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

>    (IP-VRF) and **may be sent** with two BGP extended communities:"

Okay.

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.

Thanks!

>     Also, maybe "The GW IP field MUST be zero" should say "all bytes

Thanks (for both).

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

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

> "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 va…

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.

> [JORGE] yes, added "IRB-IP of the SBD"

Thanks.

> [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 i…

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!

> [JORGE] Added, thank you!

Thanks for all the updates!

-Benjamin

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 15 May 2018 17:31:29 +0000

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 <[email-masked]>
Date: Tuesday, May 15, 2018 at 6:55 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Cc: The IESG <[email-masked]>, Zhaohui Zhang <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-prefix-advertisement-10: (with DISCUSS and COMMENT)

    Sounds good.

    

    

    Okay.

    
    
    Thanks!

    Thanks (for both).

    

    

    Thanks.

    

    -Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 May 2018 12:39:12 -0500

> 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