Re: [auth48] AUTH48: RFC-to-be 9572 <draft-ietf-bess-evpn-bum-procedure-updates-14> 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] Document title:
Running (abbreviated) title (PDF output):  We changed
"evpn-bum-procedure-update" to "EVPN BUM Procedures: Updates" so
that the title is more descriptive.

Title:  We changed "Updates on EVPN BUM Procedures" to "Updates to
EVPN Broadcast, Unknown Unicast, or Multicast (BUM) Procedures" per
similar titles of published RFCs (i.e., there aren't any published
RFCs to date that have "Updates on" in the document title).

Please let us know any objections to these updates.

Original:
 evpn-bum-procedure-update
 Updates on EVPN BUM Procedures

Currently (PDF output for the running title):
 Running title: EVPN BUM Procedures: Updates
 Title: Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) 
 Procedures -->


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:  We had trouble parsing this sentence due to
comma usage.  If the suggested text is not correct, please provide
clarifying text.

Original:
 This document specifies updated procedures for handling broadcast,
 unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),
 including selective multicast, and provider tunnel segmentation.

Suggested:
 This document specifies updated procedures for handling Broadcast,
 Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs),
 including selective multicast and segmentation of provider tunnels. -->


4) <!-- [rfced] We restructured Sections 1 and 2 of this document per
standard practice (e.g., RFCs 9251 and 9252, which are also part of
Cluster 448 (https://www.rfc-editor.org/cluster_info.php?cid=C448))
and per Section 4.8.1 ("Introduction Section") of RFC 7322
("RFC Style Guide" - https://www.rfc-editor.org/info/rfc7322).
Please let us know any concerns.

Original:
 1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.1.  Tunnel Segmentation . . . . . . . . . . . . . . . . . . .   4
     2.1.1.  Reasons for Tunnel Segmentation . . . . . . . . . . .   5
 3.  Additional Route Types of EVPN NLRI . . . . . . . . . . . . .   6
...

Currently:
 1.  Introduction
   1.1.  Requirements Language
   1.2.  Terminology
 2.  Tunnel Segmentation
   2.1.  Reasons for Tunnel Segmentation
 3.  Additional Route Types of EVPN NLRI
... -->


5) <!-- [rfced] Introduction:  We cannot follow the meaning of this
sentence.  If the suggested text is not correct, please clarify "are
referred to [RFC7117]" and "yet with quite some feature gaps like".

Original:
 A lot of details are referred to [RFC7117], yet with
 quite some feature gaps like selective tunnel and tunnel segmentation
 (Section 2.1).

Suggested:
 [RFC7117] provides many details but leaves quite a few feature gaps
 related to selective tunnels and tunnel segmentation (Section 2). -->


6) <!-- [rfced] Introduction:  Looking at RFC 7432, we could not
determine the meaning of "same editorial choice".  Will this
expression be understood by readers?

Original (the previous sentence is included for context):
 This document aims at filling the gaps - cover the use of selective
 and segmented tunnels in EVPN.  It follows the same editorial choice
 as in RFC7432 and only specifies differences from relevant procedures
 in [RFC7117] and [RFC7524], instead of repeating the text. -->


7) <!-- [rfced] Introduction:  Please clarify the meaning of "same
term S-PMSI A-D routes".  Does this mean that "S-PMSI A-D routes" is
the same term as something else?  If yes, what would that other term
be?  Also, please clarify "they all do use"; does this mean "they all
use" or something else?

Original:
 For selective tunnels, they all do use the same
 term S-PMSI A-D routes.

Possibly:
 In the case of selective tunnels, all of these technologies use
 Selective PMSI (S-PMSI) A-D routes. -->


8) <!-- [rfced] Introduction:  The original sentence did not parse.
We updated it as follows.  If this is incorrect, please provide
clarifying text.

Original:
 Many places of this document involve the I-PMSI concept that is all
 the same for all three technologies.

Currently:
 This document often refers to the I-PMSI concept, which is the
 same for all three technologies. -->


9) <!-- [rfced] "Terminology" section:  For ease of the reader, we added
definitions of "IBGP" and "EBGP", per Section 3.2.3 of RFC 1164.
We also added a definition of "RT" (per RFC 7117), as "RT" is used
later in this document but is not defined.  Please let us know any
objections.

Original:
...
 o  PMSI Tunnel Attribute (PTA): An optional transitive BGP attribute
    that may be attached to PMSI/Leaf A-D routes to provide
    information for a PMSI tunnel.

Currently:
...
 PMSI Tunnel Attribute (PTA):  An optional transitive BGP attribute
    that may be attached to PMSI/Leaf A-D routes to provide
    information for a PMSI tunnel.

 IBGP:  Internal BGP.  Provides communications with neighbors in the
    same AS.

 EBGP:  External BGP.  Provides communications with neighbors in
    different ASes.

  RT:  Route Target.  Enables the management of routing information. -->


10) <!-- [rfced] "Tunnel Segmentation" section:  We found both quoted and
unquoted forms of "Leaf Information Required" in this document.  We
then found "Leaf Information Required (L)" in RFC 6514.  We updated
this sentence accordingly, and we changed the quoted "Leaf
Information Required" in Section 4 to "L flag" (no quotes).  Please
let us know any objections.

Original:
 For inter-area segmentation, [RFC7524] requires the use of Inter-area
 P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting
 of "Leaf Information Required" L flag in PTA in certain situations.

Currently:
 For inter-area segmentation, [RFC7524] requires the use of the Inter-
 Area Point-to-Multipoint (P2MP) Segmented Next-Hop Extended Community
 (S-NH-EC) and the setting of the Leaf Information Required (L) flag
 in the PTA in certain situations. -->


11) <!-- [rfced] "Reasons for Tunnel Segmentation" section:  For ease of
the reader, we expanded "ABR" as "Area Border Router" per the second
sentence in Section 6.1 ('However, if "area" is replaced by "region"
and "ABR" is replaced by "RBR" ...').  Please let us know any
objections.

Original:
 For example,
 instead of Ingress Replicating to 100 PEs in the entire AS, with
 inter-area segmentation [RFC7524] a PE only needs to replicate to
 local PEs and ABRs.

Currently:
 For example,
 instead of ingress-replicating to 100 PEs in the entire AS, with
 inter-area segmentation [RFC7524] a PE only needs to replicate to
 local PEs and Area Border Routers (ABRs). -->


12) <!-- [rfced] Please note that we updated some of these names to match what 
appears at <https://www.iana.org/assignments/evpn/>.  Please let us know if 
corrections are needed. 

Original: 
   So far eight route types have been defined in [RFC7432],
   [I-D.ietf-bess-evpn-prefix-advertisement], and
   [I-D.ietf-bess-evpn-igmp-mld-proxy]:

         + 1 - Ethernet Auto-Discovery (A-D) route
         + 2 - MAC/IP Advertisement route
         + 3 - Inclusive Multicast Ethernet Tag route
         + 4 - Ethernet Segment route
         + 5 - IP Prefix Route
         + 6 - Selective Multicast Ethernet Tag Route
         + 7 - Multicast Join Synch Route
         + 8 - Multicast Leave Synch Route

Current (note that row separators (hyphyens) have been removed so the list can be included within an XML comment): 
   So far, eight route types have been defined in [RFC7432], [RFC9136],
   and [RFC9251]:

            +=======+=========================================+
            | Value | Description                             |
            +=======+=========================================+
            | 1     | Ethernet Auto-discovery                 |
            | 2     | MAC/IP Advertisement                    |
            | 3     | Inclusive Multicast Ethernet Tag        |
            | 4     | Ethernet Segment                        |
            | 5     | IP Prefix                               |
            | 6     | Selective Multicast Ethernet Tag Route  |
            | 7     | Multicast Membership Report Synch Route |
            | 8     | Multicast Leave Synch Route             |

-->


13) <!-- [rfced] Is "route" needed as part of the names, since these are registered 
in the "EVPN Route Types" registry?  If you prefer to keep "route" as part of the 
description, should it be capitalized (i.e., Route) to match the descriptions for 
values 6-8?  We will udpate the IANA Considerations section based on your reply. 

Original: 
   This document defines three additional route types:

         + 9  - Per-Region I-PMSI A-D route
         + 10 - S-PMSI A-D route
         + 11 - Leaf A-D route
-->


14) <!-- [rfced] Section 3:  For ease of the reader, we defined "RD" as
"Route Distinguisher" per RFC 9251, which says "The Route
Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]."  We also
defined "EVI" as "EVPN instance" per RFCs 9251 and 9252.  Please let
us know any objections.

Also, please note that the citation "non-Leaf A-D (Section 3.3)" is
confusing, as we do not see any mention of "non-Leaf" in
Section 3.3.  Would the "Possibly" text below help to clarify?
If not, please provide clarifying text.

Original:
 The "Route Type specific" field of the type 9 and type 10 EVPN NLRIs
 starts with a type 1 RD, whose Administrator sub-field MUST match
 that of the RD in all current non-Leaf A-D (Section 3.3) EVPN routes
 from the same advertising router for a given EVI.

Currently:
 The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs
 starts with a Type 1 RD (Route Distinguisher), whose Administrator
 sub-field MUST match that of the RD in all current non-Leaf A-D
 (Section 3.3) EVPN routes from the same advertising router for a
 given EVPN instance (EVI).

Possibly:
 The "Route Type specific" field of the Type 9 and Type 10 EVPN NLRIs
 starts with a Type 1 RD (Route Distinguisher), whose Administrator
 sub-field MUST match that of the RD in all current EVPN routes that
 are not Leaf A-D routes (Section 3.3), i.e., non-Leaf A-D routes
 from the same advertising router for a given EVPN instance (EVI). -->


15) <!-- [rfced] Section 3.3:  As it appears that "Inclusive Multicast
Tag route" means "IMET A-D route" and "triggers" refers to the
routes and not to the future, we updated this sentence accordingly.
If this is incorrect, please provide clarifying text.
(FYI that we don't see "Inclusive Multicast Tag" used anywhere else
in this document or in any published RFC except for RFC 9489.)

Original:
 A Leaf A-D route is originated in response to a PMSI route, which
 could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D
 route, an S-PMSI A-D route, or some other types of routes that may be
 defined in the future that triggers Leaf A-D routes.

Currently:
 A Leaf A-D route is originated in response to a PMSI route, which
 could be an IMET A-D route, a per-region I-PMSI A-D route, an S-PMSI
 A-D route, or some other types of routes that may be defined in the
 future that trigger Leaf A-D routes. -->


16) <!-- [rfced] Section 4:

a) As it appears that "IR" stands for "ingress replication" per
RFC 9251 and is only used three times in this document, we spelled
it out per the rest of this document.  If this is incorrect, please
provide the correct definition for "IR".

Original
 It assumes
 selective forwarding is always used with IR for all flows (though the
 same signaling can also be used for an ingress PE to find out the set
 of egress PEs for selective forwarding with BIER).
...
 The receiving NVE also uses the SMET routes to
 identify which NVEs need to receive traffic for a particular
 (C-S,C-G) or (C-*,C-G) to achieve selective forwarding using IR or
 BIER.
...
 For that, or for tunnel types
 other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective
 Multicast for VPLS in [RFC7117] are used.

Currently:
 It assumes that selective forwarding is
 always used with ingress replication for all flows (though the same
 signaling can also be used for an ingress PE to learn the set of
 egress PEs for selective forwarding with BIER).
...
 The receiving NVE also uses the SMET
 routes to identify which NVEs need to receive traffic for a
 particular (C-S,C-G) or (C-*,C-G) to achieve selective forwarding
 using ingress replication or BIER.
...
 For that, or for tunnel
 types other than ingress replication or BIER, S-PMSI/Leaf A-D
 procedures defined for selective multicast for VPLS in [RFC7117] are
 used.

b) Does "AC" stand for "Attachment Circuit", "Access Circuit", or
something else?  Also, to what does "advertises" refer - the NVE, the
state, or the routes?

Please note in the meantime that for ease of the reader we expanded
"NVE" as "Network Virtualization Edge" per companion
draft-ietf-bess-evpn-optimized-ir and "MLD" as "Multicast Listener
Discovery" per RFC 9251.

Original:
 An NVE proxies
 the IGMP/MLD state that it learns on its ACs to (C-S,C-G) or
 (C-*,C-G) SMET routes that advertises to other NVEs, and a receiving
 NVE converts the SMET routes back to IGMP/MLD messages and sends them
 out of its ACs.

Currently:
 A Network Virtualization Edge (NVE)
 proxies the IGMP/MLD state ("MLD" stands for "Multicast Listener
 Discovery") that it learns on its ACs to (C-S,C-G) or (C-*,C-G) SMET
 routes that advertises to other NVEs, and a receiving NVE converts
 the SMET routes back to IGMP/MLD messages and sends them out of its
 ACs. -->


17) <!-- [rfced] Section 4:

a) To what does "that" refer in the "For that ..." sentence?

Original (the previous sentence is included for context):
 It is possible
 that an operator may not want to track all those (C-S, C-G) or
 (C-*,C-G) state on the NVEs, and the multicast traffic pattern allows
 inclusive forwarding for most flows while selective forwarding is
 needed only for a few high-rate flows.  For that, or for tunnel types
 other than IR/BIER, S-PMSI/Leaf A-D procedures defined for Selective
 Multicast for VPLS in [RFC7117] are used.

b) This sentence does not parse.  Are some words or punctuation
missing?  For example, does "Other than that different route types"
mean "Other than the fact that different route types", "Other than
that, different route types", or something else?  Please provide
clarifying text.

Original:
 Other than that different
 route types and formats are specified with EVPN SAFI for S-PMSI A-D
 and Leaf A-D routes (Section 3), all procedures in [RFC7117] with
 respect to Selective Multicast apply to EVPN as well, including
 wildcard procedures. -->


18) <!-- [rfced] Section 5.1:  We had trouble following this sentence.
If neither suggestion below is correct, please clarify the purpose
of the comma in "... peers, or it has".

Original:
 "If the received Inter-AS A-D route has the L flag set in its PTA,
  then a receiving PE MUST originate a corresponding Leaf A-D route,
  while a receiving ASBR MUST originate a corresponding Leaf A-D route
  if and only if it received and imported one or more corresponding
  Leaf A-D routes from its downstream IBGP or EBGP peers, or it has
  non-null downstream forwarding state for the PIM/mLDP tunnel that
  instantiates its downstream intra-AS segment. ..."

Suggestion #1 ("if and only if ... peers or if it has"):
 |  If the received Inter-AS A-D route has the L flag set in its PTA,
 |  then a receiving PE MUST originate a corresponding Leaf A-D route,
 |  while a receiving ASBR MUST originate a corresponding Leaf A-D
 |  route if and only if it received and imported one or more
 |  corresponding Leaf A-D routes from its downstream IBGP or EBGP
 |  peers or if it has non-null downstream forwarding state for the
 |  PIM/mLDP tunnel that instantiates its downstream intra-AS segment. ...

Suggestion #2 ("if and only if ... peers; otherwise, it has"):
 |  If the received Inter-AS A-D route has the L flag set in its PTA,
 |  then a receiving PE MUST originate a corresponding Leaf A-D route,
 |  while a receiving ASBR MUST originate a corresponding Leaf A-D
 |  route if and only if it received and imported one or more
 |  corresponding Leaf A-D routes from its downstream IBGP or EBGP
 |  peers; otherwise, it has non-null downstream forwarding state for
 |  the PIM/mLDP tunnel that instantiates its downstream intra-AS
 |  segment. ... -->


19) <!-- [rfced] Section 5.2:

a) We changed "set the L flag set" in this sentence to "set the
L flag".  If this is incorrect, please clarify the text.

Original:
 With segmentation, an ingress PE MUST determine the leaves in its AS
 from the BGP next hops in all its received IMET A-D routes, so it
 does not have to set the L flag set to request Leaf A-D routes.

Currently:
 With segmentation, an ingress PE MUST determine the leaves in its AS
 from the BGP next hops in all its received IMET A-D routes, so it
 does not have to set the L flag to request Leaf A-D routes.

b) As it appears that "all those" refers to the routes and not to the
IBGP peers, we updated this sentence accordingly.  If this is not
correct, please clarify "all those".

Original:
 Note
 that in case of Ingress Replication, when an ASBR re-advertises IMET
 A-D routes to IBGP peers, it MUST advertise the same label for all
 those for the same Ethernet Tag ID and the same EVI.

Currently:
 Note
 that in the case of ingress replication, when an ASBR re-advertises
 IMET A-D routes to IBGP peers, it MUST advertise the same label for
 all those routes for the same Ethernet Tag ID and the same EVI. -->


20) <!-- [rfced] Section 5.3:  This sentence is difficult to parse.
If the suggested text is not correct, please clarify "the best
per-region I-PMSI A-D route for the source AS, that the ASBR has
selected of all those".

Original:
 The traffic arrives at the elected ASBR on the tunnel
 announced in the best per-region I-PMSI A-D route for the source
 AS, that the ASBR has selected of all those that it received over
 EBGP or IBGP sessions.

Suggested:
 The traffic arrives at the elected ASBR on the tunnel
 announced in the best per-region I-PMSI A-D route for the source
 AS, as selected by the ASBR from all the routes that it received
 over EBGP or IBGP sessions. -->


21) <!-- [rfced] Sections 5.3 and 6.3:  Do these two instances of "With
this," mean "Using this technique", "Via this process", or something
else?

Also, are all per-PE I-PMSI A-D routes regular Inclusive Multicast
Ethernet Tag routes, or should "i.e." ("that is") be "e.g." ("for
example")?

Original (previous sentences are included for context):
 o  In an ingress/upstream AS, if and only if an ASBR has active
    downstream receivers (PEs and ASBRs), which are learned either
    explicitly via Leaf A-D routes or implicitly via PIM join or mLDP
    label mapping, the ASBR originates a per-PE I-PMSI A-D route
    (i.e., regular Inclusive Multicast Ethernet Tag route) into the
    local AS, and stitches incoming per-PE I-PMSI tunnels into its
    per-region I-PMSI tunnel.  With this, it gets traffic from local
    PEs and send to other ASes via the tunnel announced in its per-
    region I-PMSI A-D route.
...
 Similar to [RFC7524], the upstream RBR MUST (auto-)configure a RT
 with the Global Administrator field set to the Next Hop in the re-
 advertised I/S-PMSI A-D route and with the Local Administrator field
 set to 0.  With this, the mechanisms specified in [RFC4684] for
 constrained BGP route distribution can be used along with this
 specification to ensure that only the needed PE/ABR will have to
 process a said Leaf A-D route. -->


22) <!-- [rfced] Section 5.3:  As this instance of "per-region I-PMSI"
was the only instance not followed by "A-D route(s)" or "tunnel(s)",
we added "A-D routes".  If this is incorrect, please let us know
whether "per-region I-PMSI tunnels" or something else would be
appropriate.

Original:
 Note that, even if there is no backward compatibility issue, the use
 of per-region I-PMSI has the benefit of keeping all per-PE I-PMSI A-D
 routes in their local ASes, greatly reducing the flooding of the
 routes and their corresponding Leaf A-D routes (when needed), and the
 number of inter-as tunnels.

Currently:
 Note that even if there are no backward-compatibility issues, the
 use of per-region I-PMSI A-D routes provides the benefit of keeping
 all per-PE I-PMSI A-D routes in their local ASes, greatly reducing
 the flooding of the routes and their corresponding Leaf A-D routes
 (when needed) and reducing the number of inter-AS tunnels. -->


23) <!-- [rfced] Section 5.3.1:  We expanded "DF" as "Designated
Forwarder" per RFC 9251.  If this is incorrect, please provide the
correct definition.

Original:
 When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
 in which a designated ASBR needs to be used to forward traffic to the
 legacy PEs in the AS, it MUST include a DF Election EC.

Currently:
 When an ASBR re-advertises a per-region I-PMSI A-D route into an AS
 in which a designated ASBR needs to be used to forward traffic to the
 legacy PEs in the AS, it MUST include a Designated Forwarder (DF)
 Election EC. -->


24) <!-- [rfced] Section 6.1:  Does "Instead of automatic region
definition" mean "Instead of automatically defining a region" or
something else?  If the suggested text is not correct, please
clarify.

Original:
 Instead of automatic region definition based on IGP
 areas, a region would be defined as a BGP peer group.

Suggested:
 Instead of automatically defining a region based on IGP
 areas, a region would be defined as a BGP peer group. -->


25) <!-- [rfced] Section 6.1:  This sentence did not parse as written.
We updated it as follows to indicate that the region is one of the
two types of links.  If this is incorrect, please provide clarifying
text.

Original:
 In this case, the inter-region
 segmentation procedures can be used instead - a region is the entire
 (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link).

Currently:
 In this case, the inter-region
 segmentation procedures can be used instead - a region is the entire
 "AS100 + ASBR1-ASBR2" link or the entire "AS300 + ASBR3-ASBR4" link. -->


26) <!-- [rfced] Section 6.1:  This sentence does not parse.  Does
"either a RR or directly with PEs" mean "either (1) with an RR or
(2) directly with PEs" or something else?

Also, does "RR" stand for "Route Reflector" or something else?

Original:
 As illustrated in the diagram below, ASBR2/3 will establish a
 multihop EBGP session with either a RR or directly with PEs in the
 neighboring AS. -->


27) <!-- [rfced] Section 6.2:  The "This may become too many" sentence
did not parse.  We updated the wording as noted below.  If this is
incorrect, please clarify the text.

Original (the previous two sentences are included for context):
 Notice that every I/S-PMSI route from each PE will be propagated
 throughout all the ASes or regions.  They may also trigger
 corresponding Leaf A-D routes depending on the types of tunnels used
 in each region.  This may become too many - routes and corresponding
 tunnels.

Currently:
 This may result in too many routes and corresponding
 tunnels. -->


28) <!-- [rfced] Section 6.2:  As it appears that "best one" in this
sentence means "best route", we updated the wording accordingly.
If this is not correct, please provide clarifying text.

Original:
 Similar to the per-PE I-PMSI
 A-D routes, RBRs/PEs in a downstream region will each select a best
 one from all those re-advertised by the upstream RBRs, hence will
 only receive traffic injected by one of them.

Currently:
 Similar to the
 per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each
 select the best route from all those re-advertised by the upstream
 RBRs and hence will only receive traffic injected by one of them. -->


29) <!-- [rfced] Section 6.2:  Please note that we changed "(s,g) or
(*,g)" to "(S,G) or (*,G)" per RFC 9251 (and also because we do not
see the lowercase form used in any published RFC).  Please let us
know any concerns.

Original:
 MVPN does not aggregate S-PMSI routes from all PEs in an AS like it
 does for I-PMSIs routes, because the number of PEs that will
 advertise S-PMSI routes for the same (s,g) or (*,g) is small.

Currently:
 MVPNs do not aggregate S-PMSI routes from all PEs in an AS like they
 do for I-PMSI routes, because the number of PEs that will advertise
 S-PMSI routes for the same (S,G) or (*,G) is small. -->


30) <!-- [rfced] Section 6.3:  To what does "That" refer in this
sentence?

Original (the previous sentence is included for context):
 [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
 to change the BGP next hop when they re-advertise I/S-PMSI A-D routes
 to downstream areas.  That is only to be consistent with the MVPN
 Inter-AS I-PMSI A-D routes, whose next hop must not be changed when
 they're re-advertised by the segmenting ABRs for reasons specific to
 MVPN. -->


31) <!-- [rfced] The description of the flag bit has been updated per this note 
from IANA: 

... the authors want to change "Bit-S - Segmentation Procedure Support" to "Segmentation Support," ... 

Please verify that the text appears correctly. 
-->


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

Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->


33) <!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 Ingress Replication / ingress replication (per RFCs 9251 and 9252)

 inter-as / inter-AS (segmentation, tree, tunnel) (per published RFCs)

 "L" flag (1 instance) / L flag (11 instances)

 leaf A-D (1 instance) / Leaf A-D (37 instances)

 Per-region I-PMSI A-D route / per-region I-PMSI A-D route

 Selective Forwarding (1 instance) / selective forwarding (6 instances)

 Selective Multicast / selective multicast (per RFC 9251)

 set to zero (1 instance) / set to 0 (5 instances)

 VPLS Multicast / VPLS multicast (per RFC 7117)

b) The following term appears to be used inconsistently in this
document.  Please let us know which form is preferred.

 the next hop / the Next Hop
   Do the instances of "the Next Hop" refer to the Next Hop field,
   or do they refer to next hops in general?

c) Next-hop field vs. Next-Hop field (draft-ietf-bess-evpn-optimized-ir)
vs. Next Hop field (draft-ietf-bess-evpn-bum-procedure-updates)
  (We see "Next-Hop address" in draft-ietf-bess-evpn-optimized-ir.) -->


Thank you.

RFC Editor



On Apr 10, 2024, at 3:30 PM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2024/04/10

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/rfc9572.xml
   https://www.rfc-editor.org/authors/rfc9572.html
   https://www.rfc-editor.org/authors/rfc9572.pdf
   https://www.rfc-editor.org/authors/rfc9572.txt

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

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9572-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/rfc9572.original.v2v3.xml 

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


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

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

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9572 (draft-ietf-bess-evpn-bum-procedure-updates-14)

Title            : Updates on EVPN BUM Procedures
Author(s)        : Z. Zhang, W. Lin, J. Rabadan, K. Patel, A. Sajassi
WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang

Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde