Re: [auth48] AUTH48: RFC-to-be 9574 <draft-ietf-bess-evpn-optimized-ir-12> 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] We updated the document title as follows.  Please let us
know any objections.

Original:
 Optimized Ingress Replication Solution for Ethernet VPN (EVPN)

Currently:
 Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs) -->


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


3) <!-- [rfced] Section 1:  Does "as many copies of the frame as remote
NVEs/PEs are attached" mean "as many copies of the frame as the
number of remote NVEs/PEs that are attached"?  If the suggested text
is not correct, please clarify.

Original:
 In the Ingress Replication approach, the ingress NVE receving a BUM
 frame from the Tenant System will create as many copies of the frame
 as remote NVEs/PEs are attached to the BD.

Suggested ("receving" has been fixed):
 In the ingress replication approach, the ingress NVE receiving a BUM
 frame from the Tenant System (TS) will create as many copies of the
 frame as the number of remote NVEs/PEs that are attached to the BD. -->


4) <!-- [rfced] Section 1:  We changed "NV3" to "NVE3" per Figure 1.  If
this is incorrect, please define "NV".

Original:
 On the left-hand
 side, NVE1 uses Ingress Replication to send a BUM frame (originated
 from Tenant System TS1) to the remote nodes attached to the BD, i.e.,
 NVE2, NV3, PE1.

Currently:
 On the left-hand
 side of the diagram, NVE1 uses ingress replication to send a BUM
 frame (originated from Tenant System TS1) to the remote nodes
 attached to the BD, i.e., NVE2, NVE3, and PE1. -->


5) <!-- [rfced] Figure 1:  Should the three instances of "to-G" be
"to G1", in which case perhaps we should also change "To-WAN" to
"To WAN")?  (in other words, do these hyphenated entries mean
"(from the) OIF to G" and "To (the) WAN"?

Original:
 To-WAN
...
 OIF to-G ... -->


6) <!-- [rfced] Sections 1 and subsequent:  We do not see the hyphenated
form "Pruned-Flood-Lists" in any published RFCs to date.  However, we
see "Pruned Flood Lists (PFLs)" in RFC 9469.  May we remove the
hyphens?

Also, RFC 9469 appears to be the only published RFC to date that uses
"Flood List" (via case-insensitive search).  Perhaps
"Pruned Flooding Lists"? -->


7) <!-- [rfced] Sections 1 and subsequent:  We see that RFC 6514 uses
"Next Hop field" (no hyphen) and that the only published RFCs to date
that use "Next-Hops" are RFCs 2749 and 5286.  May we change
instances of "Next-Hop" to "Next Hop" where it is used as a noun
(e.g., "will set the Next-Hop to an IP address") and change instances
of "Next-Hops" to "next hops"
(per draft-ietf-bess-evpn-bum-procedure-updates and most published
RFCs)? -->


8) <!-- [rfced] Section 2:  We see that the list of terms is mostly
alphabetized.  Would you like the list to be alphabetized? -->


9) <!-- [rfced] Sections 2 and 6.1:  These two instances of
"destination IP AR-IP" read oddly.  Should they be "destination AR-IP"?
Are some words missing?

Original:
 -  Asisted Replication forwarding mode: for an AR-LEAF, it means
    sending an Attachment Circuit BM packet to a single AR-REPLICATOR
    with tunnel destination IP AR-IP.
...
 The
 tunnel destination IP AR-IP will be an indication for the
 remote Selective AR-REPLICATOR that the packet needs
 further replication to its AR-LEAFs. -->


10) <!-- [rfced] Section 3:  For ease of the reader, we expanded "CE" as
"Customer Edge".  If this is incorrect, please provide the correct
definition.

Original:
 c.  The solution is compatible with [RFC7432] and [RFC8365] and has
     no impact on the CE procedures for BM traffic.

Currently:
 c.  The solution is compatible with [RFC7432] and [RFC8365] and has
     no impact on the Customer Edge (CE) procedures for BM traffic. -->


11) <!-- [rfced] Sections 4 and 7:  As this document discusses several
solutions, which solution is referred to in these sentences - the
ingress replication optimization solution in general or one of the
solutions discussed in Sections 5 and 6?

Original:
 This solution extends the [RFC7432] Inclusive Multicast Ethernet Tag
 routes and attributes so that an NVE/PE can signal its optimized
 Ingress Replication capabilities.
...
 In addition to AR, the second optimization supported by this solution
 is the ability for the all the BD nodes to signal Pruned-Flood-Lists
 (PFL).

Possibly:
 The ingress replication optimization solution specified in this
 document extends the Inclusive Multicast Ethernet Tag routes and
 attributes described in [RFC7432] so that an NVE/PE can signal its
 optimized ingress replication capabilities.
...
 In addition to AR, the second optimization supported by the ingress
 replication optimization solution specified in this document is the
 ability of all the BD nodes to signal PFLs. -->


12) <!-- [rfced] Figure 2:  We changed "Inclusive Multicast Tag" to
"Inclusive Multicast Ethernet Tag" per "Inclusive Multicast Ethernet
Tag route [RFC7432] is shown in Figure 2" in the paragraph just prior
to the figure and "the above Inclusive Multicast Ethernet Tag route
(Figure 2)" a few paragraphs later.  If this is incorrect, please
define this new term, which we don't see anywhere else in this
document or in any published RFC except for RFC 9489.

Original:
 Figure 2: EVPN Inclusive Multicast Tag Route's NLRI

Currently:
 Figure 2: EVPN Inclusive Multicast Ethernet Tag Route's NLRI -->


13) <!-- [rfced] Sections 4 and 7:  These sentences are difficult to
follow.  Does "prune-me" mean "prune me (from the indicated list)"?
If yes, may we update as suggested?

Original:
 o  Broadcast and Multicast (BM) flag.  BM=1 means "prune-me" from
    the BM flooding list.  BM=0 means regular behavior.

 o  Unknown (U) flag.  U=1 means "prune-me" from the Unknown
    flooding list.  U=0 means regular behavior.
...
 -  BM is the Broadcast and Multicast flag.  BM=1 means "prune-me"
    from the BM flood-list.  BM=0 means regular behavior.

 -  U is the Unknown flag.  U=1 means "prune-me" from the Unknown
    flood-list.  U=0 means regular behavior.

Suggested (assuming that "flood-list" and "flooding list" mean the
  same thing):
 -  Broadcast and Multicast (BM) flag.  BM = 1 means "prune me from
    the BM flooding list".  BM = 0 indicates regular behavior.

 -  Unknown (U) flag.  U = 1 means "prune me from the Unknown
    flooding list".  U = 0 indicates regular behavior.
...
 *  BM is the Broadcast and Multicast flag.  BM = 1 means "prune me
    from the BM flooding list".  BM = 0 indicates regular behavior.

 *  U is the Unknown flag.  U = 1 means "prune me from the Unknown
    flooding list".  U = 0 indicates regular behavior. -->


14) <!-- [rfced] Section 4:  The text in this paragraph was difficult to
follow from the standpoint of whether some terms were field names or
were used generally.  We updated as follows.  If this is incorrect,
please provide clarifying text.

Also, please note that per our previous question about "Next-Hop", we
suggest removing the hyphen in the field name per more common usage
in published RFCs.

Original:
 +  The Tunnel Identifier and Next-Hop SHOULD be set to the same
    IP address as the Originating Router's IP address when the
    NVE/PE originates the route, that is, when the NVE/PE is not
    an ASBR as in section 10.2 of [RFC8365].  Irrespective of
    the values in the Tunnel Identifier and Originating Router's
    IP Address fields, the ingress NVE/PE will process the
    received Replicator-AR route and will use the IP Address in
    the Next-Hop field to create IP tunnels to the AR-
    REPLICATOR.

Currently:
 -  The Tunnel Identifier and Next-Hop fields SHOULD be set to
    the same IP address as the Originating Router's IP Address
    field when the NVE/PE originates the route - that is, when
    the NVE/PE is not an ASBR; see Section 10.2 of [RFC8365].
    Irrespective of the values in the Tunnel Identifier and
    Originating Router's IP Address fields, the ingress NVE/PE
    will process the received Replicator-AR route and will use
    the IP address setting in the Next-Hop field to create IP
    tunnels to the AR-REPLICATOR. -->


15) <!-- [rfced] Section 4:  Per Section 11 and per "Tunnel Type MUST be
set to Assisted-Replication Tunnel" used earlier in this section, we
changed "set to AR" to "set to Assisted-Replication Tunnel".  Please
let us know any concerns.

Original:
 o  The Leaf Auto-Discovery route MUST include the PMSI Tunnel
    attribute with the Tunnel Type set to AR (Section 11), T (AR
    role type) set to AR-LEAF and the Tunnel Identifier set to the
    IP address of the advertising AR-LEAF.

Currently:
 *  The Leaf A-D route MUST include the PMSI Tunnel Attribute with
    Tunnel Type set to Assisted-Replication Tunnel (Section 11), T (AR
    role type) set to AR-LEAF, and Tunnel Identifier set to the IP
    address of the advertising AR-LEAF. -->


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

a) We see "Inclusive Multicast Ethernet Tag route" in RFC 7432 but
not "inclusive multicast route" or "Inclusive Multicast Route".
Will these distinctions be clear to readers, or should "Ethernet Tag"
be added?

Original:
 b.  In this non-selective AR solution, the AR-LEAF MUST advertise a
     single Regular-IR inclusive multicast route as in [RFC7432].
...
 c.  In a BD where there are no AR-REPLICATORs due to the AR-
     REPLICATORs being down or reconfigured, the AR-LEAF MUST use
     regular Ingress Replication, based on the remote Regular-IR
     Inclusive Multicast Routes as described in [RFC7432].
...
 The AR-REPLICATOR-activation-timer SHOULD be
 configurable in seconds, and its value account for the time it
 takes for the AR-LEAF Regular-IR inclusive multicast route to get
 to the AR-REPLICATOR and be programmed.

b) We had trouble following the meaning of "make any difference for"
here.  If the suggested text is not correct, please provide
clarifying text.

Original:
 Note that although this field does not make any difference
 for the remote nodes when creating an EVPN destination to the AR-
 LEAF, this field is useful for an easy operation and
 troubleshooting of the BD.

Suggested:
 Note that although this field does not affect the remote nodes when
 creating an EVPN destination to the AR-LEAF, this field is useful
 from the standpoint of ease of operation and troubleshooting of the
 BD. -->


17) <!-- [rfced] Section 5.2:  This sentence does not parse.  Should "and
its value account for" say "and its value SHOULD account for",
"and its value needs to account for", or something else?  In other
words, to what does "SHOULD" apply in this sentence?

Original:
 The AR-REPLICATOR-activation-timer SHOULD be
 configurable in seconds, and its value account for the time it
 takes for the AR-LEAF Regular-IR inclusive multicast route to get
 to the AR-REPLICATOR and be programmed. -->


18) <!-- [rfced] Section 5.2:  As it appears that "a matter of local
policy" indicates whether or not to change to a new preferred
AR-REPLICATOR (as opposed to always making the change), we updated
this sentence accordingly.  If this is incorrect, please provide
clarifying text.

Original:
 f.  If the AR-LEAF has selected an AR-REPLICATOR, it is a matter of
     local policy to change to a new preferred AR-REPLICATOR for the
     existing BM traffic flows.

Currently:
 f.  If the AR-LEAF has selected an AR-REPLICATOR, whether or not to
     change to a new preferred AR-REPLICATOR for the existing BM
     traffic flows is a matter of local policy. -->


19) <!-- [rfced] Figure 5:  We changed "LEAF-set1" to "LEAF-set-1",
but is it correct to have two "LEAF-set-1"s in the diagram?  In other
words, are three distinct LEAF-sets shown here, or two?

Original:
 | LEAF-set1 |        |LEAF-set-1 |       |LEAF-set-2 |

Currently:
 |LEAF-set-1 |        |LEAF-set-1 |       |LEAF-set-2 |

Possibly (if there should be three LEAF-sets):
 |LEAF-set-1 |        |LEAF-set-2 |       |LEAF-set-3 | -->


20) <!-- [rfced] Section 6:  We found this sentence confusing, as it
seems that the AR roles are defined more clearly in Section 5 than
in Section 4.  Should Section 5 also be cited here?

Original:
 The same AR roles
 defined in Section 4 are used here, however the procedures are
 different. -->


21) <!-- [rfced] Section 6.1:  This sentence is difficult to follow.  May
we update the text per item a. in Section 5.1?  If not, please
clarify "part of an Assisted-Replication-enabled BD as the AR role
itself".

Original:
 a.  The Selective AR-REPLICATOR capability SHOULD be an
     administrative choice in any NVE/PE that is part of an Assisted-
     Replication-enabled BD, as the AR role itself.

Suggested:
 a.  The AR-REPLICATOR role SHOULD be an
     administrative choice in any NVE/PE that is part of an Assisted-
     Replication-enabled BD. -->


22) <!-- [rfced] Section 6.1:  It seems odd to repeat "Replicator-AR
route" in this sentence.  May we update as suggested, or should the
wording be revised?

Original:
 o  The Replicator-AR route MUST include L=1 (Leaf Information
    Required) in the Replicator-AR route.

Suggested:
 *  The Replicator-AR route MUST have the L flag set to 1. -->


23) <!-- [rfced] Section 6.1:  This sentence does not parse.  Does the
"MUST" in this sentence also apply to "but skipping"?  If the
suggested text is not correct, please provide clarifying text.

Original:
 o  If the destination IP address matches its AR-IP and the source
    IP address does not match any IP address of its Selective AR-
    LEAF-set, the AR-REPLICATOR MUST forward the BM packet to
    flood-list #2 but skipping the AR-REPLICATOR-set.  Non-BM
    overlay tunnels are skipped when sending BM packets.

Suggested (assuming that "MUST" applies to both forwarding and
  skipping):
 -  If the destination IP address matches its AR-IP and the source
    IP address does not match any IP address of its Selective AR-
    LEAF-set, the AR-REPLICATOR MUST forward the BM packet to
    flood-list #2, skipping the AR-REPLICATOR-set.  Non-BM
    overlay tunnels are skipped when sending BM packets. -->


24) <!-- [rfced] Section 6.2:  We updated this sentence per item a. in
Section 5.2.  If this is incorrect, please clarify "role selective
capability".

Original:
 a.  The AR-LEAF role selective capability SHOULD be an administrative
     choice in any NVE/PE that is part of an Assisted-Replication-
     enabled BD.

Currently:
 a.  The AR-LEAF role SHOULD be an administrative choice in any NVE/PE
     that is part of an Assisted-Replication-enabled BD. -->


25) <!-- [rfced] Section 6.2:  As the original text seemed to indicate
that the AR-LEAF should wait for a timer, we updated the text to
indicate that the AR-LEAF should wait for some interval to pass.  If
this is incorrect, please provide clarifying text (e.g., are some
words missing?).

Original:
 It is RECOMMENDED that the Selective AR-LEAF waits for an AR-
 LEAF-join-wait-timer (in seconds, default value is 3) before
 sending the Leaf Auto-Discovery route, so that the AR-LEAF can
 collect all the Replicator-AR routes for the BD before
 advertising the Leaf Auto-Discovery route.

Currently:
 It is
 RECOMMENDED that the Selective AR-LEAF wait for a period
 specified by an AR-LEAF-join-wait-timer (in seconds, with a
 default value of 3) before sending the Leaf A-D route, so that
 the AR-LEAF can collect all the Replicator-AR routes for the BD
 before advertising the Leaf A-D route. -->


26) <!-- [rfced] Section 6.2:

a) We changed "a timer AR-REPLICATOR-activation-timer" to "an
AR-REPLICATOR-activation-timer", but we still find this sentence
difficult to follow.  Should "behavior for an
AR-REPLICATOR-activation-timer" be "behavior after a specified
AR-REPLICATOR-activation-timer interval"?  If not, please provide
clarifying text.

Original:
 In case of failure of the active Selective AR-
 REPLICATOR, it is RECOMMENDED for the Selective AR-LEAF to
 revert to Ingress Replication behavior for a timer AR-
 REPLICATOR-activation-timer (in seconds, default value is 3)
 to mitigate the traffic impact.

Currently:
 In the
 case of failure of the active Selective AR-REPLICATOR, it is
 RECOMMENDED that the Selective AR-LEAF revert to ingress
 replication behavior for an AR-REPLICATOR-activation-timer (in
 seconds, with a default value of 3) to mitigate the traffic
 impact.

b) Does "the same configurable parameter as in Section 5.2" mean
"the same configurable parameter as the parameter discussed in
Section 5.2", "the same configurable parameter, as discussed in
Section 5.2", or something else?  Please clarify.

Original:
 The AR-REPLICATOR-activation-timer
 MAY be the same configurable parameter as in Section 5.2. -->


27) <!-- [rfced] Section 7.1:  As it appears that "the solution described
in this document" refers to the PFLs solution and not to the
Assisted-Replication solution as mentioned in Section 1 ("The
Assisted-Replication solution described in this document") or the
optimized ingress replication solution in general, we updated this
sentence accordingly.  If this is incorrect, please provide
clarifying text.

Original:
 In order to illustrate the use of the solution described in this
 document, we will assume that BD-1 in Figure 4 is optimized Ingress
 Replication enabled and:

Currently:
 In order to illustrate the use of the PFLs solution, we will assume
 that BD-1 in Figure 4 is optimized ingress replication enabled and: -->


28) <!-- [rfced] Section 7.1:  As it appears that "will reply ARP
Requests" means "will reply to ARP Requests", we updated this
sentence accordingly.  If this is incorrect, please provide
clarifying text.

Original:
 Proxy-ARP
 [I-D.ietf-bess-evpn-proxy-arp-nd] on the remote NVE/PEs will
 reply ARP Requests locally, and no other Broadcast is expected.

Currently:
 Proxy ARP
 [RFC9161] on the remote NVEs/PEs will reply to ARP Requests
 locally, and no other broadcast traffic is expected. -->


29) <!-- [rfced] Section 8:  As it appears that "Ingress Replication or
Assisted Replication forwarding mode" means "Ingress Replication
forwarding mode or Assisted Replication forwarding mode" as opposed
to "ingress replication or Assisted Replication forwarding mode", we
updated this paragraph accordingly.  If this is incorrect, please
clarify the text.

Original:
 -  An AR-REPLICATOR will perform Ingress Replication or Assisted
    Replication forwarding mode for the incoming Overlay packets based
    on an ingress VNI lookup, as opposed to the tunnel IP DA lookup.
    Note that, when replicating to remote AR-REPLICATOR nodes, the use
    of the IR-VNI or AR-VNI advertised by the egress node will
    determine the Ingress Replication or Assisted Replication
    forwarding mode at the subsequent AR-REPLICATOR.

Currently:
 *  An AR-REPLICATOR will perform Ingress Replication forwarding mode
    or Assisted Replication forwarding mode for the incoming overlay
    packets based on an ingress VNI lookup as opposed to the tunnel IP
    DA lookup.  Note that when replicating to remote AR-REPLICATOR
    nodes, the use of the IR-VNI or AR-VNI advertised by the egress
    node will determine whether Ingress Replication forwarding mode or
    Assisted Replication forwarding mode is used at the subsequent AR-
    REPLICATOR. -->


30) <!-- [rfced] Section 10:

a) As it appears that the AR-LEAF nodes are the entities making
selections (per "other AR-LEAFs' selections" in Section 5.2), we
updated this sentence accordingly.  If this is incorrect, please
provide clarifying text.

Original:
 Also, an attack on the AR-REPLICATOR and
 change of the advertised AR type will modify the selection on the AR-
 LEAF nodes.

Currently:
 Also, an attack on the AR-REPLICATOR and any change to the
 advertised AR type will modify the selections made by the AR-LEAF
 nodes.

b) We could not follow the meaning of "attracted" as used in this
sentence.  Per <https://www.merriam-webster.com/dictionary/attracted>,
it does not appear to be a good fit.  Please provide alternative text.

Original:
 The forwarding of Broadcast and Multicast (BM)
 traffic is modified, and BM traffic from the AR-LEAF nodes will be
 attracted by the existence of AR-REPLICATORs in the BD. -->


31) <!-- [rfced] Would you like to list the references in alphanumeric
order? -->


32) <!-- [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.

 flags field / Flags field (per Cluster 448)

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

 NVE/PEs / NVEs/PEs

 nvGRE (Figures 4 and 5) / NVGRE

 Originating Router's IP address / Originating Router's IP Addr /
   Originating Router's IP Address (per RFC 9252)

 PMSI Tunnel attribute / PMSI Tunnel Attribute (per RFC 9252)

 regular-IR (2 instances) / Regular-IR (24 instances)
   (We see one instance of "regular IR-IP Address"; please confirm
    that this is correct.)

 regular-IR behavior described in [RFC7432] (1 instance) /
   regular ingress replication behavior described in [RFC7432]
     (4 instances)

 Split-horizon / split-horizon (per RFC 9252)

 Tunnel Type / tunnel type (where used generally)

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

 AR-IP Address / AR-IP address

 Assisted-Replication / Assisted Replication
   (e.g., "Assisted-Replication (AR)", "Assisted Replication (AR)")
   (We suggest that, after selecting one form, we use the
   abbreviation "AR" after the initial definition in Section 1.)

 Assisted-Replication Type field (4 instances) /
   AR type field (1 instance)
   (Are these two distinct fields, or do they both mean the same
    thing?  If the same, which form should be used?)

 core network / network core (Abstract)

 IP Source Address / source IP address*
   * (e.g., as used in RFC 9251)

 IR-IP Address / IR-IP address

 multi-staged / multi-stage

 non-selective / Non-selective / Non-Selective (in running text,
   e.g., 'non-selective AR', 'solution is called "non-selective"',
   'Non-Selective solution', 'Non-selective AR-REPLICATORs',
   'non-selective mode', 'Non-Selective and Selective modes',
   'Non-Selective mode')

   Suggested (with the exception of 'Non-selective mode', per other
     mode names in this cluster):
     non-selective, because we do not see a precedent for
       'Non-selective' in any published RFC.  However, we see
       'Non-Selective Mode' used once in RFC 9469, but this appears
       to be an outlier.

 selective AR(...) / Selective AR(...)
   (e.g., selective AR, selective AR-LEAF-set, Selective AR-LEAF-set,
   selective AR-REPLICATOR, Selective AR-REPLICATOR)

   Suggested:  selective AR(...)

 Please note that we also see 'Selective solution' and
   'Selective mode'.
   We suggest 'selective solution', because it does not appear to be
     a proper term.
   We suggest 'Selective mode' per other mode names in this cluster.

 Single-IP AR-REPLICATOR
   ("in the Single-IP AR-REPLICATOR ..." (Section 2)) /
   single-IP AR-REPLICATOR (Section 10)

 T (AR role type) (2 instances) /
   T (Assisted-Replication type) (1 instance)

 Unknown Unicast / Unknown unicast / unknown unicast
   (where used generally)

c) This is the only document in Cluster 448
(https://www.rfc-editor.org/cluster_info.php?cid=C448) that uses
"flood-list" (e.g., "Unknown flooding list", "Unknown flood-list").
We also could not find any instances of "flood-list", "Flood-List",
or "Flood-list" in any published RFC to date.

May we change these instances to "flooding list" as used elsewhere in
this document, and also per
draft-ietf-bess-evpn-bum-procedure-updates?  If not, how can the
distinction between these two terms be clarified for readers? -->


33) <!-- [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. -->


Thank you.

RFC Editor


On Apr 10, 2024, at 3:41 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/rfc9574.xml
   https://www.rfc-editor.org/authors/rfc9574.html
   https://www.rfc-editor.org/authors/rfc9574.pdf
   https://www.rfc-editor.org/authors/rfc9574.txt

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

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

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


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

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

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9574 (draft-ietf-bess-evpn-optimized-ir-12)

Title            : Optimized Ingress Replication Solution for Ethernet VPN (EVPN)
Author(s)        : J. Rabadan, Ed., S. Sathappan, W. Lin, M. Katiyar, A. Sajassi
WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang

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