Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks
draft-ietf-nvo3-evpn-applicability-06

This is a nicely written document and I have no specific technical comments. From an editorial perspective:

- The placement of Section 6 "Conventions Used in this Document" is odd as it appears after the conclusion section of the document. I would suggest moving it closer to the beginning of the document. 
- There are several references that are outdated so please correct these:

  == Outdated reference: A later version (-09) exists of
     draft-ietf-nvo3-encap-08

  == Outdated reference: A later version (-09) exists of
     draft-ietf-bess-evpn-lsp-ping-08

  == Outdated reference: A later version (-10) exists of
     draft-ietf-bess-evpn-pref-df-09

  == Outdated reference: A later version (-09) exists of
     draft-ietf-bess-evpn-irb-mcast-07

  == Outdated reference: A later version (-05) exists of
     draft-ietf-bess-evpn-geneve-04

  == Outdated reference: A later version (-05) exists of
     draft-ietf-bess-evpn-mvpn-seamless-interop-04

  == Outdated reference: A later version (-06) exists of
     draft-sajassi-bess-secure-evpn-05

  == Outdated reference: A later version (-07) exists of
     draft-ietf-bess-rfc7432bis-04

# John Scudder, RTG AD, comments for draft-ietf-nvo3-evpn-applicability-05
CC @jgscudder

Thanks for this document, I found it easy to read and understand, which is a real credit to the authors considering the complexity of the subject matter. I have some minor comments below which I hope may be helpful.

## COMMENTS

### Section 2, spelling of "Clos"

You've spelled "Clos" as "CLOS" as if it were an acronym. It's not, it's the inventor's name (indeed you've cited him, [CLOS1953]) so should be spelled mixed-case. (https://en.wikipedia.org/wiki/Clos_network, https://en.wikipedia.org/wiki/Clos). (Also in Section 3.)

### Section 2, sorting

I found this section very useful. It looks like it started out sorted alphabetically but the sorting falls apart part-way through? It would be even more useful if the sorting were maintained.

### Section 2, VIDs

Seems like "VIDs" needs a definition also.

### Section 2, 2119 keyword

You have a MUST in your definition of Ethernet Tag. Since as you rightly say in your abstract, "This document does not introduce any new procedures in EVPN", you probably don't need that MUST, I suggest making it some plain-English word, either "must" or "has to", for instance.

If you make that change, then you can and should remove Section 6 (the 2119 citation).

### Section 3, "fairly optimal"

"Fairly optimal" gave me a smile, if one is strict about the meaning of "optimal" it's kind of a contradiction, like "orthogonal but related". :-) It's clear from context so leave it if you like, fine with me, but if you want a replacement it could be "... ECMP generally distributes utilization well across all the links".

### Section 3, PIC ref

You might want to add a reference for PIC.

### Section 3, MAP/IP

Did you mean MAC/IP? (Also in Section 5.) If not, then please say what MAP/IP is?

### Section 4.1, confusing description of RT-1

I don't understand what you mean by "Multi-homing: Per-ES: Mass withdrawal". I guess maybe it means something like

	Multi-homing:
		Per-ES: Mass withdrawal
		Per-EVI: aliasing/backup
		
But (assuming that's right) without the additional context of whitespace/indents, I think it's not straightforwardly or unambiguously understandable. You might need to write this out in complete sentences.

### Section 4.3, confusing sentence

I couldn't make out what you meant by

           EVPN uses MAC/IP Advertisement and IP Prefix routes for the
   exchange of host IP routes (in the case of the MAC/IP Advertisement
   and the IP Prefix routes)
   
The problematic bit is the stuff in parentheses. It parses as meaning that host routes are used in the case of IP Prefix routes, which makes no sense. This sentence probably needs a rewrite for clarity.

### Section 4.7.2 bug in description of MAC duplication extension

I was surprised by this,

                                                the NVE may install it
   as a black-hole MAC and drop received frames with source MAC address
   and destination MAC address matching that duplicate MAC
   
since it implies only the case SA == DA == duplicate MAC is covered. Looking at rfc7432bis S. 15.3, the actual condition is SA == dup MAC || DA == dup MAC, so perhaps change the "and" to "or" in the quoted text.

Also you might as well cite the relevant section and not just rfc7432bis, to save the reader the effort of searching for it.

Also you may want to consider rewording "black-hole" in some other way (others may also flag this, and so might the RFC Editor). 

### Section 4.7.5, ES2?

When you write ES2, did you mean ESI? (If not, what did you mean?)

### Section 4.7.6, GW

You don't expand or gloss "GW" anywhere. Yes it's pretty common usage, but I think it bears expanding on first use.

### Section 4.7.8, "often"?

You have,

   Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must be

wouldn't it be right to insert "often", as in

   Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must often be

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. 

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

Abstract:

I find the "Conclusion" section (with the word 'justifies' replaced
with 'documents') a clearer Abstract of the document than the
current Abstract. Maybe move the Conclusion as Abstract, and move
some technical details of the current Abstract to the Introduction?

Section 1:

        TOR/Leaf switches

I had to follow the link a few sentences down to RFC 7365 to realize
TOR here does not mean Tor Onion Routing but Top of Rack switch.

RFC 7365 uses "ToR" and not "TOR" as well. So maybe expand and fix
the capitalization.

Section 2:

The terminology is listed alphabetically, but some items are referred
in items before they are explained. It might be better to re-order
them. But perhaps not - me as a newbie in this space didn't know any,
but perhaps people familiar with terms find this sorting method easier
to use when reading the document.


        NVO3 tunnels or simply Overlay tunnels will be used interchangeably

Why not stick to one term for simplicity ?

Thank you to Kyle Rose for the SECDIR review.

** Section 1.  Editorial. Consider either expanding “TOR” (which I first read as an onion routing protocol) or use the “ToR” spelling that comes from https://www.rfc-editor.org/materials/abbrev.expansion.txt.

** Section 3.  Typo. s/addresss/addresses/

** Section 4.4

   The Generic Network Virtualization Encapsulation [RFC8926] has been
   recommended to be the proposed standard for NVO3 Encapsulation.

Recommended how?

** Section 4.4

   The NVO3 encapsulation design team has made a recommendation in
   [I-D.ietf-nvo3-encap] for a control plane to:

Practically, isn’t this a WG document?  Shouldn’t this document make these recommendations?

# GEN AD review of draft-ietf-nvo3-evpn-applicability-05

CC @larseggert

Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/aaqvb7lSJAu_1M2KpEt2AVal4bQ).

## Comments

### Section 2, paragraph 17
```
     *  Ethernet Tag: Used to represent a Broadcast Domain that is
        configured on a given ES for the purpose of Designated Forwarder
        election.  Note that any of the following may be used to represent
        a Broadcast Domain: VIDs (including Q-in-Q tags), configured IDs,
        VNIs (Virtual Extensible Local Area Network (VXLAN) Network
        Identifiers), normalized VIDs, I-SIDs (Service Instance
        Identifiers), etc., as long as the representation of the Broadcast
        Domains is configured consistently across the multihomed PEs
        attached to that ES.  The Ethernet Tag value MUST be different
        from zero.
```
The "MUST" in the last sentence is the only RFC2119 keyword in the document.
Can we rephrase to avoid it, and loose the BCP14 boilerplate text entirely?
(You could IMO just remove the entire last sentence.)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2, paragraph 19
```
-       Route-Distinghisher (RD) and Route-Target(s) (RTs) are required
-                    ^
+       Route-Distinguisher (RD) and Route-Target(s) (RTs) are required
+                    ^
```

#### Section 2, paragraph 21
```
-       Route Distinghisher (RD) and Route Target(s) (RTs) are required
-                    ^
+       Route Distinguisher (RD) and Route Target(s) (RTs) are required
+                    ^
```

#### Section 3, paragraph 9
```
-          configured egress NVE destination IP addresss in the Broadcast
-                                                      -
```

#### Section 4.7.5, paragraph 3
```
-    *  All-active multi-homing means per-flow load-balanding for unicast
-                                                        ^
+    *  All-active multi-homing means per-flow load-balancing for unicast
+                                                        ^
```

### Outdated references

Document references `draft-sajassi-bess-secure-evpn-05`, but `-06` is the
latest available revision.

Document references `draft-ietf-bess-evpn-lsp-ping-08`, but `-09` is the latest
available revision.

Document references `draft-ietf-bess-evpn-geneve-04`, but `-05` is the latest
available revision.

Document references `draft-ietf-bess-rfc7432bis-04`, but `-07` is the latest
available revision.

Document references `draft-ietf-bess-evpn-pref-df-09`, but `-10` is the latest
available revision.

Document references `draft-ietf-nvo3-encap-08`, but `-09` is the latest
available revision.

Document references `draft-ietf-bess-evpn-irb-mcast-07`, but `-09` is the
latest available revision.

Document references `draft-ietf-bess-evpn-mvpn-seamless-interop-04`, but `-05`
is the latest available revision.

### Grammar/style

#### Section 2, paragraph 19
```
VRF and they are normally different than the ones defined in the associated 
                                    ^^^^
```
Did you mean "different from"? "Different than" is often considered colloquial
style.

#### Section 3, paragraph 1
```
nels. When the destination host replies back and the frames arrive at the NVE
                                ^^^^^^^^^^^^
```
Consider using "replies".

#### Section 4.1, paragraph 2
```
, where MACs and the information to setup flooding trees are distributed by M
                                    ^^^^^
```
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

#### Section 4.2.2, paragraph 1
```
in MAC/IP Advertisement routes in a similar way. * The remote NVEs can then 
                               ^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

#### Section 4.3, paragraph 5
```
3. In addition, NVE2 would advertise a IP Prefix route with TS3's IP address
                                     ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.7.2, paragraph 3
```
iven Broadcast Domain. For instance, an virtual-switch NVE that learns all it
                                     ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 4.7.4, paragraph 3
```
RFs in NVE1 and NVE2 are connected by a SBD (Supplementary Broadcast Domain)
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Hi,

Thanks for this document.  I only have minor, editorial type comments.

Minor level comments:                                                                                                                                                                                                                                        
                                                                                                                                                                                                                                                             
(1) p 6, sec 3.  Why is EVPN Needed in NVO3 Networks?                                                                                                                                                                                                        
                                                                                                                                                                                                                                                             
   Why is a control-plane protocol along with NVO3 tunnels required?                                                                                                                                                                                         
   There are three main reasons:                                                                                                                                                                                                                             
                                                                                                                                                                                                                                                             
Given that you give an example of why a control-plane protocol isn't required for the first two, would it be fairer to write 'helpful' or 'useful' rather than 'required'?                                                                               


(2) p 23, sec 6.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

It is really unusual to have this boilerplate text need the end of the document, I don't recall seeing it done in other RFCs.  It would probably be better before the current section 2, or as part of the current section 2.

Nit level comments:

(3) p 6, sec 3.  Why is EVPN Needed in NVO3 Networks?

   On this architecture and as discussed by [RFC7364], multi-tenant
   intra-subnet and inter-subnet connectivity services are provided by
   NVO3 tunnels, being VXLAN [RFC7348] or GENEVE [RFC8926] two examples
   of such tunnels.

The latter part of the sentence (, being ...) doesn't scan well for me.


(4) p 7, sec 3.  Why is EVPN Needed in NVO3 Networks?

   *  "Flood and learn" solves the issues of auto-discovery and learning
      of the MAC to VNI/tunnel IP mapping on the NVEs for a given
      Broadcast Domain.  However, it does not provide a solution for
      advanced features and it does not scale well (mostly due to the
      need for constant flooding and the underlay PIM states that are
      needed to maintain).

I suggest "must be maintained" rather than "needed to maintain".

Regards,
Rob