Re: [auth48] AUTH48: RFC-to-be 9469 <draft-ietf-nvo3-evpn-applicability-06> for your review

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.

1) <!-- [rfced] Please note that the title of the document has been
updated. Abbreviations have been expanded per Section
3.6 of RFC 7322 (“RFC Style Guide”).

Also, we note that the title of the document is the same as the title
of Section 4. Would the document title be more in line with the
Abstract and Introduction if EVPN is referred to as a "scalable
solution" for NVO3 networks, or would you like to keep the wording as
is? Please let us know your preference.

Original:
   Applicability of EVPN to NVO3 Networks

Current: 
   Applicability of Ethernet Virtual Private Network (EVPN) to Network
   Virtualization over Layer 3 (NVO3) Networks

Perhaps:
   Ethernet Virtual Private Network (EVPN) Scalable Solution for Network
   Virtualization over Layer 3 (NVO3) Networks-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on https://www.rfc-editor.org/search. -->


3) <!--[rfced] Abstract. Please clarify "that solves" in the following. Is the
intended meaning "that solves the issues of...in a scalable way"?
Note that there is similar wording in Section 3.
 
Original:
   Ethernet Virtual Private Network (EVPN) provides a unified
   control-plane that solves the Network Virtualization Edge (NVE)
   auto-discovery, tenant MAC/IP dissemination and advanced features
   required by Network Virtualization Over Layer-3 (NVO3) networks.

Perhaps:  
   An Ethernet Virtual Private Network (EVPN) provides a unified
   control plane that solves the issues of Network Virtualization
   Edge (NVE) auto-discovery, tenant Media Access Control (MAC) /
   IP dissemination, and advanced features in a scalable way as 
   required by Network Virtualization over Layer 3 (NVO3) networks.

Section 3 
Original:
   EVPN provides a unified control-plane that solves the NVE
   auto-discovery, tenant MAC/IP dissemination and advanced
   features in a scalable way and keeping the independence of the
   underlay IP Fabric, i.e., there is no need to enable PIM in the
   underlay network and maintain multicast states for tenant 
   Broadcast Domains.

Perhaps:
   EVPN provides a unified control plane that solves the issues of NVE
   auto-discovery, tenant MAC/IP dissemination, and advanced features in
   a scalable way and keeps the independence of the underlay IP Fabric;
   i.e., there is no need to enable PIM in the underlay network and
   maintain multicast states for tenant Broadcast Domains.
-->


4) <!-- [rfced] We rephrased this sentence as follows to improve clarity
and the overall flow of the text. Please let us know if any
further changes are needed.

Original: 
   This document describes the use of EVPN for NVO3 networks, discusses
   its applicability to basic Layer-2 and Layer-3 connectivity requirements, as
   well as advanced features such as MAC-mobility, MAC Protection and Loop
   Protection, multi-homing, Data Center Interconnect (DCI) and much more.

Current: 
   This document describes the use of EVPN for NVO3 networks and
   discusses its applicability to basic Layer-2 and Layer-3 connectivity
   requirements and to advanced features such as MAC Mobility, MAC 
   Protection and Loop Protection, multihoming, Data Center 
   Interconnect (DCI), and much more.-->


5) <!--[rfced] We removed the expansion of "VNI" within the definition of
"Ethernet Tag" since "VNI" is a defined in the terminology list. Also
note that this avoids confusion since the expansion we removed
("VXLAN Network Identifiers (VNIs)") was different than that of
the defined term ("Virtual Network Identifier (VNI)"). Please let
us know if this is agreeable or if you prefer otherwise.

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

Current:
   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, normalized VIDs, Service Instance Identifiers (I-SIDs),
      etc...-->


6) <!-- [rfced] We note that RFC 7432 does not provide a concise definition of EVPN and
mostly uses the term as a modifier (e.g., EVPN instance). Would you like to
propose a clear and concise definition that aligns with your use of the term
in this document? -->


7) <!-- [rfced] RFC 7432 uses the term "interface" in place of "model" for "EVPN
VLAN-aware bundle service model", "EVPN VLAN-based service model", and
"EVPN VLAN-bundle service model". Should we update the definitions in
Section 2 and instances throughout the document to match RFC 7432, or
should they be left as is?

Original:
   EVPN VLAN-aware bundle service model: similar to the VLAN-bundle
   model...

   EVPN VLAN-based service model: one of the three service models defined in
   [RFC7432]...

   EVPN VLAN-bundle service model: similar to VLAN-based but uses a 
   bundle of VLANS...

Perhaps: 
   EVPN VLAN-Aware Bundle Service Interface: Similar to the VLAN-bundle
   interface...

   EVPN VLAN-Based Service Interface: One of the three service interfaces...

   EVPN VLAN-Bundle Service Interface: Similar to VLAN-based, but uses a
   bundle of VLANs... -->


8) <!-- [rfced] Please confirm if "Route Distinguisher" should be
singular (option A) or plural (option B) in the following
sentence. Note that we will also apply these changes to the
definition of MAC-VRF, as it contains similar wording.

Original:
   Route Distinguisher (RD) and Route Target(s) (RTs) are required
   properties of an IP-VRF.

Perhaps:
A) A Route Distinguisher (RD) and one or more Route Targets (RTs) are 
   required properties of an IP-VRF. 
or

B) Route Distinguishers (RDs) and one or more Route Targets (RTs) are
   required properties of an IP-VRF.  -->


9) <!-- [rfced] We suggest rephrasing the following sentence.
Specifically, can "allows to forward packets" be updated or
condensed? Additionally, is an article missing before
"destination"? Also, note that we would like to remove
"interface" after the expansion for consistency with the other
terms in the list. Please let us know if option A or B retains
the intended meaning or if you prefer otherwise.

Original: 
    IRB: Integrated Routing and Bridging interface. It refers to the logical 
      interface that connects a Broadcast Domain instance (or a BT) to an 
      IP- VRF and allows to forward packets with destination in a different 
      subnet.

Perhaps: 
A)  IRB: Integrated Routing and Bridging. It refers to the logical 
      interface that connects a Broadcast Domain instance (or a BT) to an 
      IP-VRF and forwards packets with a destination in a different subnet. 
or

B)  IRB: Integrated Routing and Bridging. It refers to the logical 
      interface that connects a Broadcast Domain instance (or a BT) 
      to an IP-VRF and allows the forwarding of packets with a 
      destination in a different subnet. -->


10) <!--[rfced] May we remove "device" after the expansion of "NVE" and
"router" after the expansion of "PE" for consistency with the
other expansions in the list?

Current:
    NVE:  Network Virtualization Edge device.

Perhaps:
    NVE:  Network Virtualization Edge.

...
Current:
   PE:  Provider Edge router.
   
Perhaps:
   PE:  Provider Edge. -->


11) <!--[rfced] Would you like to add a link to the "EVPN Route Types"
IANA registry as follows?

Original:
   RT-1, RT-2, RT-3, etc.: they refer to Route Type followed
   by the type number as defined in the IANA registry for 
   EVPN route types.

Perhaps:
   RT-1, RT-2, RT-3, etc.: These refer to the Route Types followed
   by the type numbers as defined in the "EVPN Route Types" IANA 
   registry (see <https://www.iana.org/assignments/evpn/>).-->


12) <!-- [rfced] We rephrased "(PIC) like functionality" to "functionality
similar to Prefix Independent Convergence (PIC)" since PIC is an
adjective describing this functionality and a hyphen in this
position may introduce awkward phrasing. Please let us know of
any objections.

Original: 
   Advanced features such as MAC Mobility, MAC Protection, BUM and
   ARP/ND traffic reduction/suppression, Multi-homing, Prefix Independent
   Convergence (PIC) like functionality [I-D.ietf-rtgwg-bgp-pic], Fast
   Convergence, etc.

Current: 
   Advanced features, such as MAC Mobility, MAC Protection, BUM and
   ARP/ND traffic reduction/suppression, Multi-homing, functionality similar to
   Prefix Independent Convergence (PIC) [RTGWG-BGP-PIC], fast convergence, etc. -->


13) <!-- [rfced] We suggest rephrasing this sentence for readability. Does the
following suggestion retain the intended meaning?

Original: 
   "Flood and learn" refers to not using a specific control-plane on
   the NVEs, but rather "flood" BUM traffic from the ingress NVE to all the
   egress NVEs attached to the same Broadcast Domain.

Perhaps: 
   "Flood and learn" refers to "flooding" BUM traffic from the ingress
   NVE to all the egress NVEs attached to the same Broadcast Domain instead of
   using a specific control plane on the NVEs. -->


14) <!-- [rfced] FYI - We have updated "Multiple-instance Spanning Tree Protocol"
to "Multiple Spanning Tree Protocol" to match what appears in recently
published RFCs. Please let us know if this change is incorrect.

Original: 
   If the multi-homed Tenant System or network are running protocols
   such as LACP (Link Aggregation Control Protocol) [IEEE.802.1AX_2014], MSTP
   (Multiple-instance Spanning Tree Protocol), G.8032, etc...

Current: 
   If the multi-homed Tenant System or network is running protocols,
   such as the Link Aggregation Control Protocol (LACP) [IEEE.802.1AX_2014], 
   the Multiple Spanning Tree Protocol (MSTP), G.8032, etc... -->


15) <!-- [rfced] We suggest rephrasing the following sentence for clarity. Does
the suggestion below retain the intended meaning?

Original: 
   Note that, if the EVPN service model is VLAN-based or VLAN-bundle,
   implementations do not normally have a specific provisioning for the
   Broadcast Domain (since it is in that case the same construct as the 
   MAC-VRF).

Perhaps: 
   Note that if the EVPN service model is VLAN-based or VLAN-bundle,
   implementations do not normally have a specific provisioning for the 
   Broadcast Domain since, in this case, it is the same construct as the 
   MAC-VRF. -->


16) <!-- [rfced] We suggest rephrasing the following list items for easy
readability and removing parentheses to match the text that describes the
"Symmetric model" below Figure 2. Does the suggestion below retain the
intended meaning or do you prefer otherwise?

Original:
   In Figure 2, if TS1 and TS2 are in different
   subnets, and TS1 sends IP packets to TS2, the following lookups are
   required in the data path: a MAC lookup (on BD1's table), an IP
   lookup (on the IP-VRF) and a MAC lookup (on BD2's table) at the
   ingress NVE1 and then only a MAC lookup at the egress NVE.

Perhaps:
   In Figure 2, if TS1 and TS2 are in different
   subnets and TS1 sends IP packets to TS2, the following lookups are
   required in the data path: a MAC lookup at BD1's table, an IP
   lookup at the IP-VRF, a MAC lookup at BD2's table at the
   ingress NVE1, and only a MAC lookup at the egress NVE. -->


17) <!-- [rfced] We have updated the following definition for
clarity. Specifically, we have clarified "all-active" as
"all-active mode". Please let us know any objections.

Original: 
   DF (Designated Forwarder) election: the Designated Forwarder is the
   NVE that forwards the traffic to the Ethernet Segment in single-active
   mode. In case of all-active, the Designated Forwarder is the NVE that forwards
   the BUM traffic to the Ethernet Segment.

Current: 
   Designated Forwarder (DF) election: The Designated Forwarder is the
   NVE that forwards the traffic to the Ethernet Segment in single-active
   mode. In the case of all-active mode, the Designated Forwarder is the NVE that
   forwards the BUM traffic to the Ethernet Segment. -->


18) <!-- [rfced] We suggest specifying the action in this sentence for
clarity. Specifically, does the Non-Designated Forwarder NVE
flood the TS (option A) or flood the BUM frames back to the TS
(option B)?

Original: 
   This is especially relevant in all-active Ethernet Segments, where
   the Tenant System may forward BUM frames to a non-Designated Forwarder NVE
   that can flood the BUM frames back to the Designated Forwarder NVE and then
   the Tenant System.

Perhaps: 
A) This is especially relevant in all-active ESes where the
   TS may forward BUM frames to a Non-Designated Forwarder NVE that
   can flood the BUM frames back to the Designated Forwarder NVE and 
   then flood the TS. 
or

B) This is especially relevant in all-active ESes where the
   TS may forward BUM frames to a Non-Designated Forwarder NVE that
   can flood the BUM frames back to the Designated Forwarder NVE and 
   then back to the TS. -->


19) <!-- [rfced] We rephrased the sentence below as follows for
clarity. Does the rephrase retain the intended meaning?

Original: 
   As an example, in Figure 1, assuming NVE4 is the Designated
   Forwarder for ESI-2 in BD1, BUM frames sent from TS3 to NVE5 will be received
   at NVE4 and, since NVE4 is the Designated Forwarder for BD1, it will forward
   them back to TS3.

Current: 
   As an example, assuming NVE4 is the Designated Forwarder for ESI-2 in
   BD1, Figure 1 shows that BUM frames sent from TS3 to NVE5 will be received at
   NVE4. NVE4 will forward them back to TS3 since NVE4 is the Designated
   Forwarder for BD1. -->


20) <!-- [rfced] Would you like the references to be alphabetized (set to
sortRefs="true") or left in their current order? -->


21) <!--[rfced] FYI - Since "draft-sajassi-bess-secure-evpn-06" is expired
and has been replaced by "draft-ietf-bess-secure-evpn-00", we
updated the reference entry as follows.

Original:
[I-D.sajassi-bess-secure-evpn] 
    Sajassi, A., Banerjee, A., Thoria, S., Carrel, D., Weis, B., 
    and J. Drake, "Secure EVPN", Work in Progress, Internet-Draft, 
    draft-sajassi-bess-secure-evpn-06, 13 March 2023,
    <https://datatracker.ietf.org/doc/html/draft-sajassi-bess-secure-evpn-06>.

Current:
 [BESS-SECURE-EVPN]
     Sajassi, A., Banerjee, A., Thoria, S., Carrel, D., Weis, B., 
     and J. Drake, "Secure EVPN", Work in Progress, Internet-Draft, 
     draft-ietf-bess-secure-evpn-00, 20 June 2023, 
     <https://datatracker.ietf.org/doc/html/draft-ietf-bess-secure-evpn-00>
-->


22) <!-- [rfced] Abbreviations

a) We have added expansions for abbreviations upon first use per Section 3.6
of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document
carefully to ensure correctness.

b) We note that some abbreviations that appear often throughout the document
use their expanded forms in the body of the text despite being defined upon
first use in Section 2. We also note that some terms are defined multiple
times. The Web Portion of the Style Guide
(https://www.rfc-editor.org/styleguide/part2/) suggests using the abbreviated
form of a term after the abbreviation has been introduced. Should we update the
following terms to follow this style?

 Bridge Table (BT)
 Designated Forwarder (DF)
 Non-Designated Forwarder (NDF)
 Equal-Cost Multipath (ECMP)
 Ethernet Segment (ES)
 Generic Network Virtualization Encapsulation (Geneve)
 Route Distinguisher (RD) 
 Route Target (RT)
 Tenant System (TS)
 Virtual Network Identifier (VNI)
 Wide Area Network (WAN) -->


23) <!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used 
inconsistently. We will update the document to use the forms on the right if 
there are no objections.

 all-active -> All-Active (per RFC 7432)
 single-active -> Single-Active (per RFC 7432)
 Flood-and-Learn -> "flood and learn"
 Designated Forwarder Election -> Designated Forwarder election (per RFC 8584)
 Inter Subnet Forwarding -> inter-subnet forwarding (per RFCs 7432 and 9135)
 IP Multicast Group -> IP multicast group (per the majority of RFCs)
 Multicast traffic -> multicast traffic (per RFCs 7364 and 7365)

b) We strongly suggest making the following updates to the terminology listed
below to match recently published RFCs and/or use in the normative references. If
there are no objections, we will update the following terms to use the form on
the right.

 Broadcast Domain -> broadcast domain
    [Note: this term is lowercased in RFCs 7364 and 7432 and capitalized in RFC 9161; 
    please let us know your preference. Or all instances can be replaced with "BD".]

 Broadcast frames -> broadcast frames (per RFC 7348)
 Broadcast traffic -> broadcast traffic (per RFC 7432)
 EVPN route types -> EVPN Route Types
 GENEVE -> Geneve (per RFC 9136)
 Inter Subnet Multicast Forwarding -> inter-subnet multicast forwarding
 IPVPN -> IP VPN (per RFC 4364)

 Layer-2 -> Layer 2 (per RFCs 7364, 7365, and 7432)
 Layer-3 -> Layer 3
    [Note: our current practice is to not hyphenate  
    "Layer 2" or "Layer 3" even when it is in attributive
    position (i.e., followed by a noun).]

 MAC-mobility / MAC mobility -> MAC Mobility (per RFC 7432)
 Multicast frames -> multicast frames (per RFC 8365)
 multi-home -> multihom (per RFC 7432)
 multi-homing / Multi-homing -> multihoming

 Proxy-ARP -> Proxy ARP
 Proxy-ARP/ND -> Proxy ARP/ND
 Proxy-ND -> Proxy ND
    [Note: the majority of RFCs do not use the hyphen
    for the proxy terms, including RFC 9161.]

c) Questions related to "BUM" and "Unknown unicast"

i) Should the expansion of "BUM" be capitalized (which would match
use in the majority of RFCs) or should it be lowercase (which would 
match use in the normative references)?

Original:
   BUM:  Broadcast, Unknown unicast, and Multicast frames.

Perhaps:
   BUM:  Broadcast, Unknown Unicast, and Multicast frames.
   or
   BUM:  Broadcast, unknown unicast, and multicast frames.

ii) Should "Broadcast, Multicast, or Unknown unicast" be
reordered as "Broadcast, Unknown Unicast, and Multicast" 
or updated simply as "BUM" in the following sentence?

Current:
   In addition, [BESS-EVPN-OPTIMIZED-IR] describes a procedure to avoid
   sending Broadcast, Multicast, or Unknown unicast to certain NVEs that
   do not need that type of traffic. 

Perhaps:
   In addition, [BESS-EVPN-OPTIMIZED-IR] describes a procedure to avoid
   sending BUM to certain NVEs that do not need that type of traffic. 

iii) Please let us know how to update "Unknown unicast" and "unknown unicast" 
for consistency in the running text.

Original:
   ...due to Unknown unicast and Broadcast frames
   ...reduce the unknown unicast flooding 
   ...the Broadcast Domain's Unknown unicast traffic -->


24) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.

For example, please consider whether "black holes" should be updated. -->


Thank you.

RFC Editor/mc/kc


On Aug 25, 2023, at 6:00 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2023/08/25

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published.  Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all 
the parties CCed on this message need to see your changes. The parties 
include:

  *  your coauthors

  *  [e-mail] (the RPC team)

  *  other document participants, depending on the stream (e.g., 
     IETF Stream participants are your working group chairs, the 
     responsible ADs, and the document shepherd).

  *  [e-mail], which is a new archival mailing list 
     to preserve AUTH48 conversations; it is not an active discussion 
     list:

    *  More info:
       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

    *  The archive itself:
       https://mailarchive.ietf.org/arch/browse/auth48archive/

    *  Note: If only absolutely necessary, you may temporarily opt out 
       of the archiving of messages (e.g., to discuss a sensitive matter).
       If needed, please add a note at the top of the message that you 
       have dropped the address. When the discussion is concluded, 
       [e-mail] will be re-added to the CC list and 
       its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication.  Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9469.xml
  https://www.rfc-editor.org/authors/rfc9469.html
  https://www.rfc-editor.org/authors/rfc9469.pdf
  https://www.rfc-editor.org/authors/rfc9469.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9469-diff.html
  https://www.rfc-editor.org/authors/rfc9469-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9469-xmldiff1.html

The following files are provided to facilitate creation of your own 
diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
  https://www.rfc-editor.org/authors/rfc9469.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates 
only: 
  https://www.rfc-editor.org/authors/rfc9469.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9469

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9469 (draft-ietf-nvo3-evpn-applicability-06)

Title            : Applicability of EVPN to NVO3 Networks
Author(s)        : J. Rabadan, Ed., M. Bocci, S. Boutros, A. Sajassi
WG Chair(s)      : Matthew Bocci, Sam Aldrin
Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston