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

["Jorge Rabadan (Nokia)" <[e-mail]>]

Thank you Karen!

(btw, I think the auth48 status page is not correct, I think it should be AUTH48 Status: RFC-to-be 9469 » RFC Editor (rfc-editor.org)<https://www.rfc-editor.org/auth48/rfc9469> ??)

Thanks.
Jorge

From: Karen Moore <[e-mail]>
Date: Wednesday, September 6, 2023 at 9:34 AM
To: Jorge Rabadan (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9469 <draft-ietf-nvo3-evpn-applicability-06> for your review

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Hi Jorge,

Thank you for catching the typo; that fix has been made and is now reflected in our files, and we have noted your approval on the AUTH48 status page for this document.

We now await further changes (if needed) and approvals from Ali, Matthew, and Sami.

FILES (please refresh):

The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9469.xml

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

This diff file shows all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9469-auth48diff.html

This diff file shows all changes made to date:
 https://www.rfc-editor.org/authors/rfc9469-diff.html

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9468

Best regards,

RFC Editor/kc


> On Sep 6, 2023, at 12:57 AM, Jorge Rabadan (Nokia) <[e-mail]> wrote:
>
> Hi Karen,
>
> I went through the document and it looks pretty good.
> Just found the following typo:
>
> Section 4.7.1:
> s/remoter NVE/remote NVE/
>
> Once that is fixed, I’m good with the document and I’ll approve it for publication.
>
> Thanks!
> Jorge
>
> From: Karen Moore <[e-mail]>
> Date: Tuesday, September 5, 2023 at 5:52 PM
> To: Jorge Rabadan (Nokia) <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9469 <draft-ietf-nvo3-evpn-applicability-06> for your review
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> Dear Jorge,
>
> Thank you again for your reply to our questions; we have updated our files accordingly. Please note one additional change:
>
> 1) In Section 2, we removed the periods after the expanded terms that contained no additional text (e.g., BUM, ECMP, PE, PMSI, and PTA). If you have any concerns about this change, please let us know.
>
> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
>
> The updated XML file is here:
>  https://www.rfc-editor.org/authors/rfc9469.xml
>
> The updated output files are here:
>  https://www.rfc-editor.org/authors/rfc9469.txt
>  https://www.rfc-editor.org/authors/rfc9469.pdf
>  https://www.rfc-editor.org/authors/rfc9469.html
>
> This diff file shows all changes made during AUTH48:
>  https://www.rfc-editor.org/authors/rfc9469-auth48diff.html
>
> This diff file shows all changes made to date:
>  https://www.rfc-editor.org/authors/rfc9469-diff.html
>
> Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.
>
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9468
>
> Thank you.
>
> RFC Editor/kc
>
>
> > On Aug 28, 2023, at 2:53 AM, Jorge Rabadan (Nokia) <[e-mail]> wrote:
> >
> > Dear RFC Editor,
> >
> > Please see some comments in-line with [jorge].
> >
> > Thanks very much for your work on this document.
> > Jorge
> >
> > From: [e-mail] <[e-mail]>
> > Date: Friday, August 25, 2023 at 6:02 PM
> > To: Jorge Rabadan (Nokia) <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>
> > Cc: [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>, [e-mail]<[e-mail]>, [e-mail]<[e-mail]>, [e-mail] <[e-mail]>
> > Subject: Re: AUTH48: RFC-to-be 9469 <draft-ietf-nvo3-evpn-applicability-06> for your review
> >
> >
> > CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
> >
> >
> >
> > 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-->
> >
> > [jorge] the current one is fine.
> >
> >
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> > title) for use on https://www.rfc-editor.org/search. -->
> >
> > [jorge] EVPN, Applicability, NVO3
> >
> >
> > 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.
> >
> > [jorge] I agree with your suggestion, thanks
> >
> > 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.
> > -->
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> > 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.-->
> >
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> > 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...-->
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> > 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? -->
> >
> > [jorge] I don’t think that is necessary. EVPN is specified in RFC7432, this document is informational and uses EVPN, but I’d prefer not to provide a definition here that may be perceived as incomplete.
> >
> >
> >
> > 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... -->
> >
> > [jorge] I agree with your suggestion, it is better to follow RFC7432 as much as possible
> >
> >
> >
> > 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.  -->
> >
> > [jorge] “A” is correct, “B” is wrong
> >
> >
> >
> > 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. -->
> >
> > [jorge] Please use the text in “A”
> >
> >
> >
> > 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. -->
> >
> > [jorge] Yes, that’s fine, we can use the suggested text
> >
> >
> >
> > 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/>).--<https://www.iana.org/assignments/evpn/%3e).-->>
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> >
> > 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. -->
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> >
> > 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. -->
> >
> > [jorge] I agree with your suggestion, it retains the meaning
> >
> >
> >
> > 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... -->
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> >
> > 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. -->
> >
> > [jorge] If we are consistent with a previous comment you had, we should say:
> >
> > OLD:
> >    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).
> >
> > NEW:
> >    Note that if the EVPN service interfaces are 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. -->
> >
> > [jorge] I agree with your suggestion, thanks, it retains the meaning
> >
> >
> >
> >
> > 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. -->
> >
> > [jorge] I agree with your suggestion, thanks
> >
> >
> > 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. -->
> >
> > [jorge] Please use suggestion “B”
> >
> >
> > 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. -->
> >
> > [jorge] I agree with your suggestion, thanks, it retains the meaning
> >
> >
> > 20) <!-- [rfced] Would you like the references to be alphabetized (set to
> > sortRefs="true") or left in their current order? -->
> >
> > [jorge] alphabetized, please
> >
> >
> > 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>
> > -->
> >
> > [jorge] I agree, thanks
> >
> >
> > 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.
> >
> > [jorge] I think it looks good
> >
> > 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) -->
> >
> > [jorge] Some reviewers complained that the document had too many abbreviations, so we should probably leave the expanded forms of most. You can certainly use just the abbreviation in the following cases:
> >  Equal-Cost Multipath (ECMP)
> >  Generic Network Virtualization Encapsulation (Geneve)
> >  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)
> >
> > [jorge] no objections, thx
> >
> > 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".]
> >
> > [jorge] I’d prefer capitalized as in RFC9161
> >
> >  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)
> >
> > [jorge] all the above suggestions look good
> >
> >
> >  multi-home -> multihom (per RFC 7432)
> >
> > [jorge] should be “multihome”
> >
> >
> >  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.]
> >
> > [jorge] the above suggestions look good
> >
> > 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.
> >
> >
> > [jorge] Pleas use “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.
> >
> > [jorge] OK, use the suggestion please
> >
> > 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 -->
> >
> > [jorge] you can use “Unknown Unicast”
> >
> >
> > 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. -->
> >
> > [jorge] please use “”packet drops” instead of “black holes”
> >
> >
> > 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
> >
>