Re: [auth48] AUTH48: RFC-to-be 9572 <draft-ietf-bess-evpn-bum-procedure-updates-14> for your review

[Lynne Bartholomew <[e-mail]>]

Dear authors,

We do not believe that we have heard from you regarding this document and the questions below.

Please review this document and the questions, and let us know how the document should be updated.

The files (links copied from the "Instructions for Completing AUTH48" email below) are 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


Thank you!

RFC Editor/lb


> On Apr 10, 2024, at 3:44 PM, [e-mail] wrote:
> 
> 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
> 
>