Re: [Gen-art] Genart early review of draft-ietf-bess-extended-evpn-optimized-ir-05

[Wen Lin <[e-mail]>]

 Hi Thomas,

Thank you so much for your thorough review and valuable inputs.  Please see replies inline below and diffs in the following link.

https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-extended-evpn-optimized-ir-05&url2=draft-ietf-bess-extended-evpn-optimized-ir-06&difftype=--html

Wen



Juniper Business Use Only
From: Thomas Fossati via Datatracker <[e-mail]>
Date: Sunday, December 17, 2023 at 4:37 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Genart early review of draft-ietf-bess-extended-evpn-optimized-ir-05
[External Email. Be cautious of content]


Reviewer: Thomas Fossati
Review result: Ready with Issues

I am not able to provide any feedback on the technical aspects as it is
beyond my expertise. However, I have marked the content as "ready with
issues" because I believe that the writing can be improved to make it
more accessible to people who are not hardcore BESS hackers :-) I have
made a few editorial suggestions to try and address this concern.

> Abstract
>
>    [EVPN-AR] specifies an optimized ingress replication solution for

Please define [EVPN-AR].  [1] says:

"An abstract should be complete in itself, so it should not contain
 citations unless they are completely defined within the abstract."

[1] https://urldefense.com/v3/__https://authors.ietf.org/en/required-content__;!!NEt6yMaO-gk!HGNzVL5O3SuONL68ID9RkgvWVXQKE5p02Ng1HujKkz2fCOkhjoniaBHBMkrcrGlaW-MTcaLsjamXDg$<https://urldefense.com/v3/__https:/authors.ietf.org/en/required-content__;!!NEt6yMaO-gk!HGNzVL5O3SuONL68ID9RkgvWVXQKE5p02Ng1HujKkz2fCOkhjoniaBHBMkrcrGlaW-MTcaLsjamXDg$>

Besides, the [EVPN-AR] entry in §10 is pretty broken :-)
Wen: Fixed

>    more efficient multicast and broadcast delivery in a Network
>    Virtualization Overlay (NVO) network for EVPN.

Please expand EVPN
Wen: Done

>    This document extends the optimized ingress replication procedures
>    specified in [EVPN-AR] to overcome the limitation that an AR-
>    REPLICATOR may have.  An AR-REPLICATOR may be unable to retain the
>    source IP address or include the expected ESI label that is
>    required for EVPN split-horizon filtering when replicating the
>    packet on behalf of its multihomed AR-LEAF.  Under this
>    circumstance, the extended procedures specified in this document
>    allows the support of EVPN multihoming on the AR-LEAFs as well as
>    optimized ingress replication for the rest of the EVPN overlay
>    network.

I had to jump back and forth between this document and [EVPN-AR] three
times to get the definitions of AR-REPLICATOR, AR-LEAF and ESI.  I'm
wondering if there's a way to make the abstract less heavy on acronyms.
Wen: I updated the abstract based on your input.

> 1.  Terminology
>    BD: Bridge Domain, as it is defined in the[RFC7432]

Suggestion:

     BD: Bridge Domain, as defined in [RFC7432]
Wen: Changed to Broadcast Domain based on RFC 7432,  and also modified based on your input .

>    RNVE: Regular Network Virtualized Edge router that performs the
>    procedure specified in the [RFC8365]

Suggestion:

     RNVE: Regular Network Virtualized Edge router that performs the
     procedure specified in [RFC8365]
Wen: Done.

>    This document heavily uses the terminology specified in [EVPN-AR].

Suggestion:

     This document extensively employs the terminology defined in
     [EVPN-AR].
Or, more simply:

     This document makes use of the terminology defined in [EVPN-AR].
Wen: done.

> 2.1.1.  EVPN Multihoming and split-horizon Filtering Rule
>
>    [...]
>    unicast or Multicast (BUM) packet received from an ES that is a
>    part

Suggestion:

     unicast or Multicast (BUM) packet received from an ES that is part
Wen: Fixed

>    [...] For EVPN with VXLAN encapsulation, the split-horizon
>    filtering rule is based on the egress NVE examining the source IP
>    address of the BUM packet received from an overlay tunnel.

Suggestion:

     When using EVPN with VXLAN encapsulation, the split-horizon
     filtering rule is applied by the egress NVE based on the source IP
     address of the BUM packet received from an overlay tunnel.
Wen: Done

>    For ingress replication, an ESI label is downstream assigned per
>    multihomed ES.

What does "downstream assigned" mean?
Wen: It is in the direction of packet destination, assigned by the egress PE.

>    packet to the egress NVE if the BUM traffic is form the AC that is

s/form/from/
Wen: Fixed

> 2.2.  Optimized-IR and the Need to Maintain the Original Source IP
>       address or Include the ESI Label
>
>    [EVPN-AR] specifies an optimized ingress replication solution for
>    the delivery of Multicast and Broadcast (BM) traffic within a
>    bridge

Should the acronym be "MB" instead?  (Ignorant question: is this
different from BUM traffic?)
Wen: Fixed.

>    [...] To support EVPN AR-LEAF multihoming, [EVPN-AR] recommends
>    that split-horizon filtering rule based on "Local-Bias" procedures
>    is used for EVPN NVO network using either 24-bit VNI or MPLS label.

This is a bit heavy.

(tentative) Suggestion:

     To support EVPN AR-LEAF multihoming, [EVPN-AR] recommends using
     split-horizon filtering based on "Local-Bias" procedures using
     either 24-bit VNI or MPLS labels.
Wen: Done

>    To support EVPN all-active multihoming based on "Local-Bias"
>    procedures, when an AR-REPLICATOR performs assisted replication on
>    behalf of a multihomed AR-LEAF, the AR-REPLICATOR shall use the

Is this "shall" a BCP14 SHALL?  (If so, maybe use MUST.)
Wen: changed to MUST.

>    To support EVPN all-active multihoming with MPLSoGRE or MPLSoUDP,
>    sometimes it is desirable to continue using the existing split-
>    horizon filtering rule based on [RFC7432] procedures.  In this
>    case, when performing assisted replication on behalf of a
>    multihomed AR- LEAF, an AR-REPLICATOR shall include the ESI label
>    advertised by a

ditto (SHALL?)
Wen: Changed to MUST

>               +----------------+
>               | AR-REPLICATOR  |    <--- set the source IP to its own
>               +-------+--------+         IP address when replicating
>                       |                  the traffic to AR-LEAF2
>                       |
>     +-----------------+----------------------------------+
>     |                                                    |
>     |        NVO for EVPN with VXLAN encapslation        |

s/encapslation/encapsulation/
Wen: Fixed

>     |                                                    |
>     +------+---------------------+-----------------------+
>            |  ^                  |
>            |  |                  |
>     +------+------+       +------+------+
>     |   AR-LEAF1  |       |   AR-LEAF2  |  <--- unable to detect the

s/the/that/
Wen: Fixed

>     +------+------+       +------+------+       the original sender
>            |  ^                  | (DF)         was AR-LEAF1
>            |  | (S,G)            |
>            +-------- TS1 --------+
>
>        Figure 1: AR-Replicator and the VXLAN Source IP Address
>
>    For instance, let's consider a scenario with VXLAN encapsulation as
>    it is shown in Figure 1, where TS1 is multihomed to both AR-LEAF1
>    and

s/it is//
Wen: Fixed

>    AR-LEAF2 through a multihomed ES.  When AR-LEAF1 receives an IP
>    multicast packet from TS1, it forwards the packet to its AR-
>    REPLICATOR, setting the source IP address to AR-LEAF1's IR-IP and

s/,//
Wen: no change was made.

>    When AR-LEAF2 receives this packet from the AR-REPLICATOR, it
>    examines the source IP address.  Regrettably, it cannot detect that
>    the original sender was AR-LEAF1.

Suggestion:

     Upon receiving the packet from AR-REPLICATOR, AR-LEAF2 checks the
     source IP address, but it cannot identify AR-LEAF1 as the original
     sender.
Wen: Done.

>    In cases where AR-LEAF2 functions as the Designated Forwarder (DF)
>    for the multihomed ES linked to TS1, it proceeds to forward the
>    packet to TS1.  This results in the same IP multicast packet being
>    looped back to TS1.

Suggestion:

     In cases where AR-LEAF2 serves as the Designated Forwarder (DF) for
     the multihomed ES linked to TS1, it forwards the packet to TS1,
     resulting in the IP multicast packet being looped back to TS1.
Wen: Done

>    The same problem can also happen to EVPN with MPLS over IP network
>    if an AR-REPLICATOR cannot include the ESI label to the remote NVE
>    for the multihomed ES when the split-horizon filtering rule based
>    on [RFC7432] is used.

Suggestion:

     The issue can also occur with EVPN using MPLS over IP network if an
     AR-REPLICATOR is unable to include the ESI label for the multihomed
     ES to the remote NVE due to split-horizon filtering based on
     [RFC7432].
Wen: Done

> 3.  Solution
>
>    This document extends the procedures defined in the [EVPN-AR] to
>    support EVPN multihoming on AR-LEAFs when an NVE acts as an AR-
>    REPLICATOR is incapable of retaining the source IP address or
>    including an ESI label for its AR-LEAF due to either hardware
>    limitations or implementation complexity.

Suggestion:

     This document extends the procedures defined in [EVPN-AR] to enable
     EVPN multihoming on AR-LEAFs. It addresses the situation where an
     NVE serves as an AR-REPLICATOR but cannot retain the source IP
     address or include an ESI label for its AR-LEAF due to hardware
     constraints or implementation complexity.
Wen: Done

>    The solution presented in this document is designed for EVPN over
>    IP- based network, utilizing NVO tunnel with either 24-bit VNI or
>    MPLS label.  This solution relies on the use of either [RFC7432] or
>    "Local-Bias" split-horizon filtering rules to prevent BM traffic
>    looping while achieving optimized ingress replication.  We refer to
>    the procedures specified in this document as the extended
>    Optimized- IR procedures.  These extended Optimized-IR procedures
>    also work with RNVE.

Suggestion:

     This document presents a solution for EVPN over IP-based networks,
     which uses an NVO tunnel with either a 24-bit VNI or an MPLS label.
     In order to prevent BM traffic looping while achieving optimized
     ingress replication, this solution relies on the use of either
     [RFC7432] or "Local-Bias" split-horizon filtering rules. The
     procedures specified in this document are referred to as the
     extended Optimized-IR procedures.  These extended Optimized-IR
     procedures are also compatible with RNVE.
Wen: Done

> 3.1.  AR-REPLICATOR Announcing Multihoming Assistant Capability for
>       Optimized-IR
>
>    [...]
>    the section 6, in the multicast flags extended community, and b) it

s/the section/Section/
Wen: Fixed

>    [...]
>    REPLICATOR are further explained in detail in section 5.2.

s/section/Section/
Wen: Fixed

> 3.2.  Multihomed AR-LEAF and Extended-MH AR-REPLICATOR
>
>    An AR-LEAF follows the control plane and forwarding plane
>    procedures specified in [EVPN-AR].  In addition, if a multihomed
>    AR-LEAF detects that one of its AR-REPLICATORs is Extended-MH
>    AR-REPLICATOR based on

s/is Extended/is an Extended/
Wen: Fixed

>    For an AR-LEAF, please note that the additional forwarding
>    procedures specified above apply to BM packets coming from any of
>    its ACs in the same BD, whether that AC is a single homed ES or a
>    part of a multihomed ES.

Suggestion:

     Please note that for an AR-LEAF, the additional forwarding
     procedures specified above apply to BM packets that originate from
     any of its ACs within the same BD. These ACs can either be a
     single-homed ES or be part of a multihomed ES.
Wen: Done

>    It may also apply to Unknown unicast traffic.  This is to further
>    alleviate the burden of an Extended-MH AR-REPLICATOR as

s/further alleviate the burden/ease the burden/
Wen: Done

>    it may be unable to detect whether a packet received on its AR-IP
>    tunnel was originally received from a single-homed or multihomed
>    ES.
>      |                         NVO Network                          |
>      |                                                              |
>      +--+-------+---------+--------+--------+--------------------+--+
>         |       |         |        |        |        |           |
>         |       |         |        |        |        |           |
>      +--+--+  +--+--+  +--+--+  +--+--+  +--+--+  +--+--+     +--+--+
>      |AR-L1|  |AR-L2|  |AR-L3|  |AR-L4|  |AR-L5|  |AR-L6| ... |AR-Lm|
>      +--+--+  +--+--+  +--+--+  +--+--+  +--+--+  +--+--+     +--+--+
>        | |       |        |        |        |        |           |
>        | +-------|------+ |        +---+ +--+       TS4   ...   TSm
>        +---+ +---+      | |            TS3
>       ESI-1| |     ESI-2| |     ^                                   ^
>            + +          + +     |<-- An Extened-MH AR-RREPLICATOR   |

s/Extened/Extended/
s/AR-RREPLICATOR/AR-REPLICATOR/
Wen: Fixed

>    Consider an EVPN NVO network illustrated in Figure 2, the tenant
>    domain comprises a set of m AR-LEAFs in BD X.  To save the space
>    shown in the Figure 2, AR-L is used to denote AR-LEAF.  TS1 is


     Consider the EVPN NVO networkin Figure 2.  The tenant domain
     consists of a set of m AR-LEAFs in BD X. For brevity, we will use
     "AR-L" to represent "AR-LEAF."

>    AR-LEAF1 will detect that its AR-REPLICATORs are Extended-MH AR-
>    REPLICATORs.

How?
Wen: Added more text in the draft.

> 3.3.  The Benefit of the Extended Optimized-IR Procedure
>
>    [...]
>    It frees all AR-REPLICATORs from performing multihoming assisted
>    replication while at the same time, it allows the support of EVPN
>    multihoming on the AR-LEAFs with the existing multihoming
>    procedures and split-horizon filtering rules

Suggestion:

     It allows EVPN multihoming on AR-LEAFs with existing multihoming
     procedures and split-horizon filtering rules, freeing
     AR-REPLICATORs from multihoming assisted replication.
Wen: Done.

>    For EVPN with MPLS over IP-based encapsulation, an NVE can continue
>    to use the split-horizon filtering rule based on the ESI label.
>    Furthermore, it still allows the support of efficient Optimized-IR
>    for the rest of an EVPN NVO network.
>
>    [...] In an NVO network consisting of many NVEs, the AR-REPLICATOR
>    is still responsible for replicating the BM packet to the most of
>    NVEs for its AR-LEAF and thus it inherits the benefit of optimized
>    ingress replication for the most of its NVO network.

Suggestion:

     In an NVO network that comprises multiple NVEs, the AR-REPLICATOR
     is still responsible for replicating the BM packet to most of the
     NVEs for its AR-LEAF. Therefore, it gets the advantage of optimized
     ingress replication for the majority of its NVO network.
Wen: Done

> 3.4.  Support for Mixed AR-REPLICATORs
>
>    [...]
>
>    When there are mixed AR-REPLICATORs, this document recommends that
>    all MH-capable-assistant AR-REPLICATORs to be administratively
>    provisioned to behave as Extended-MH AR-REPLICATORs.  In this case,
>    each AR-REPLICATOR originates its REPLICATOR-AR route with the
>    Extended-MH-AR flag set in the multicast flags extended community.

Suggestion:

     In situations where there are different types of AR-REPLICATORS, it
     is recommended that all MH-capable-assistant AR-REPLICATORS be
     provisioned administratively to behave as Extended-MH
     AR-REPLICATORS. In such cases, each AR-REPLICATOR originates its
     REPLICATOR-AR route with the Extended-MH-AR flag set in the
     multicast flags extended community.

Also, should the recommendation use RFC2119 terms?
Wen: updated text and added SHALL.

> 4.1.  AR-LEAF Procedure
>
>    This section covers the extended Optimized-IR procedures required
>    for an AR-LEAF in further detail when at least one of the
>    AR-REPLICATORs is an Extended-MH AR-REPLICATOR.

s/in further detail//
Wen: Fixed

>    It is assumed that an AR-LEAF follows the procedures defined in
>    [EVPN-AR] unless it is specified otherwise.

s/unless it is specified otherwise/unless otherwise specified/
Wen: Fixed

> 4.1.1.  Control Plane Procedure for AR-LEAF
>
>    [...]
>    An AR-REPLICATOR originating a REPLICATOR-AR route without a
>    multicast flags extended community or with the Extended-MH-AR flag
>    unset is considered to be multihoming assistant capable.

Suggestion:

     If an AR-REPLICATOR originates a REPLICATOR-AR route without a
     multicast flags extended community or with the Extended-MH-AR flag
     unset, it is considered to be multihoming assistant capable.
Wen: Done

>    If an AR-LEAF does not have any locally attached segment that is a
>    part of a multihomed ES, then there is no additional extended
>    Optimized-IR procedure for an AR-LEAF to follow and we can go
>    directly to section 4.2.

Suggestion:

     If an AR-LEAF does not have a locally attached segment that is part
     of a multihomed ES, it does not need to follow any additional
     extended Optimized-IR procedure, and we can proceed directly to
     Section 4.2.
Wen: Done

>    In addition, an AR-LEAF builds a peer-multihomed-flood-list for
>    each BD it attaches.

s/attaches/attaches to/
Wen: Fixed

>    Per normal EVPN procedures defined in [RFC7432], an

Suggestion:

     As per the standard EVPN procedures defined in [RFC7432], an
Wen: Done

>    [...]
>    Please section 5 for detail.

Suggestion:

     Please refer to Section 5 for details.
Wen: Fixed

> 4.1.2.  Forwarding Procedure for AR-LEAF
>
>    Suppose that a multihomed AR-LEAF detects through the control plane
>    procedure that at least one of its AR-REPLICATORs is an Extended-MH
>    AR-REPLICATOR, then in addition to follow the forwarding procedures
>    defined in [EVPN-AR], the AR-LEAF will use regular ingress
>    replication to send the BM packet, received from one of its ACs, to
>    each NVE in that BD's peer-multihomed-flood-list.

Suggestion (split the very long sentence):

     Suppose a multihomed AR-LEAF detects through a control plane
     procedure that one or more of its AR-REPLICATORS are Extended-MH
     AR-REPLICATORS. In that case, in addition to following the
     forwarding procedures defined in [EVPN-AR], it will use regular
     ingress replication to send the BM packet received from one of its
     ACs to each NVE in that BD's peer-multihomed-flood-list.
Wen: Done

>    In the case that there are no more AR-REPLICATORs in the tenant
>    domain, the AR-LEAF reverts back to the regular IR behavior as it
>    is defined in [RFC7432].

Suggestion:

     If there are no more AR-REPLICATORs within the tenant domain, the
     AR-LEAF will revert to its regular IR behavior, as defined in
     [RFC7432].
Wen: Done

>    An AR-LEAF will follow the regular EVPN procedures when it receives
>    a packet from an overlay tunnel and it will never send the packet
>    back to the core.

Are these two "will" MUSTs?
Wen: Updated the text.


> 4.2.1.  Control Plane Procedure for AR-REPLICATOR
>
>    An NVE that performs an AR-REPLICATOR role follows the control
>    plane procedures for AR-REPLICATOR defined in the [EVPN-AR].

s/in the [EVPN-AR]./in [EVPN-AR]./
Wen: Fixed

>    [...]
>    refer to section 5 for the common multihomed ES an AR-LEAF shares

s/section/Section/
Wen: Fixed

>    with its remote NVE.
>
>    Consider an EVPN NVO network specified in the section 3.2.  Both
>    AR-

Suggestion:

     Consider the EVPN NVO network described in Figure 2.  Both AR-

>    LEAF1 and AR-LEAF2 originate its Ethernet A-D per EVI route for ES1
Wen: Done

s/originate/send/
s/its/their/
Wen: Fixed

>    respectively.  Both AR-LEAF1 and AR-LEAF3 originate its Ethernet
>    A-D

s/respectively//
s/originate/send/
s/its/their/
Wen: Fixed.

>    per EVI route for ES2 respectively.  Per normal EVPN procedures,
>    each

s/respectively//
s/Per normal/As per normal/
Wen: Fixed.

>    AR-REPLICATOR imports and processes Ethernet A-D per EVI routes.

>    Each AR-REPLICATOR builds an AR-LEAF1's multihomed-list for BD X
>    that consists of AR-LEAF2 and AR-LEAF3.  Each AR-REPLICATOR also
>    builds AR-LEAF's multihomed-lists for other AR-LEAFs.

Suggestion:

     Each AR-REPLICATOR creates an AR-LEAF1 multihomed-list for BD X
     that consists of AR-LEAF2 and AR-LEAF3, as well as for other
     AR-LEAFs.
Wen: Done

> 4.2.2.  Forwarding Procedure for AR-REPLICATOR
>
>    When an AR-REPLICTOR determines that it is an Extended-MH AR-
>    REPLICATOR or determines that it SHALL fall back to become an

s/SHALL/shall/
Wen: Fixed

>    Extended-MH AR_REPLICATOR, it MUST follow the forwarding procedures
>    described in this section.
>
>    For a given BD, when an AR-REPLICATOR replicates the packet,
>    received from its AR-IP tunnel, to other overlay tunnels on behalf
>    of its ingress AR-LEAF, the AR-REPLICATOR MUST skip any NVE that is
>    in that ingress AR-LEAF's multihomed-list built for that said BD.

Suggestion:

     When an AR-REPLICATOR replicates a packet from an AR-IP tunnel to
     other overlay tunnels on behalf of an ingress AR-LEAF, it MUST skip
     any NVE that is in the multihomed-list of that ingress AR-LEAF
     built for the corresponding BD.
Wen: Done

>    [...] It is assumed under the scope of this document that an
>    AR-LEAF does not share any common multihoming ES with any
>    AR-REPLICATOR.

Suggestion:

     It is assumed that no AR-LEAF shares any common multihoming ES with
     any AR-REPLICATOR.
Wen: Done

>    When replicating the traffic to other RNVEs, an AR-REPLICATOR should
>    set the source IP address to its own IR-IP.  This is because an RNVE
>    does not recognize the AR-IP.

Is this "should" a SHOULD?
Wen: changed to MUST

> 5.  AR-LEAF's Peer multihomed NVE in the Extended Optimized-IR
>     Procedure
>
>    For the extended Optimized-IR procedures specified in this
>    document, a multihomed AR-LEAF may keep track of the common
>    multihomed ES it

Is this "may" a MAY?
Wen: Fixed

>    A multihomed AR-LEAF maintains a peer-multihomed-flood-list for
>    each BD it attaches.

s/attaches/attaches to/
Wen: Fixed

>    If the common multihomed ES is tracked in a per EVI scope, an
>    AR-LEAF's peer-multihomed-flood-list for a given BD X contains all
>    the NVEs in BD X that have at least one multihomed ES in common
>    with it, regardless whether each common multihomed ES contains BD X
>    or not.

Suggestion:

     If the common multihomed ES is tracked within a specific EVI scope,
     the peer-multihomed-flood-list of an AR-LEAF for a particular BD X
     will include all the NVEs in BD X that have at least one common
     multihomed ES with it. This is regardless of whether each common
     multihomed ES has BD X or not.
Wen: Done

>    If the common multihomed ES is tracked in a BD specific scope, for
>    a given BD X, each common multihomed ES must contain BD X.

Is this "must" a MUST?
Wen: Fixed

>    The same MUST be applied to the AR-LEAF's multihomed-list for BD X
>    an AR-REPLICATOR maintains for its AR-LEAF.  When the Ethernet A-D
>    per EVI route is advertised at the granularity of per ES, the
>    common multihomed ES is tracked in a per EVI scope.

I could not parse these last two sentences.
Wen: Updated the text.

> 6.  Multicast Flags Extended Community
>
>    The EVPN multicast flags extended community is defined in the

s/in the/in/
Wen: Fixed.

>    [...].  An AR Replicator uses one bit for the Extended-MH-
>    AR flag, and it is shown as E in the Flags bit vector below.

Suggestion:

     An AR Replicator utilizes one bit for the Extended-MH-AR flag,
     which is designated as E in the Flags bit vector below.
Wen: Done.

>    [...] When this flag is set, the AR-REPLICATOR indicates to other
>    NVEs that it is an Extended-MH AR Replicator and it supports the
>    extended Optimized-IR procedures defined in this document.

Suggestion:

     By setting this flag, the AR-REPLICATOR informs other NVEs that it
     is an Extended-MH AR Replicator and supports the extended
     Optimized-IR procedures specified in this documen
Wen: Done.

> 7.  IANA Considerations
>
>    IANA has opened the Flags registry for EVPN multicast Extended
>    Community.  IANA has allocated bit 13 in the Flags registry field
>    for the Extended-MH-AR flag specified in this document.
>
>            Bit Value           Name                Reference
>            13                  Extended-MH-AR      This document
>
> 8.  Security Considerations
>
>    This document inherits the same securities as they are defined in the
>    [RFC7432], [RFC8365] and [EVPN-AR].

Suggestion:

     The security considerations in [RFC7432], [RFC8365] and [EVPN-AR]
     apply to this document.
Wen: Fixed

>    [EVPN-AR]  Rabadan, J., Ed., "Optimized Ingress Replication solution
>               for EVPN", internet-draft ietf-bess-evpn-optimized-ir-
>               12.txt, January 2022, <https://urldefense.com/v3/__https://tools.ietf.org/id/ietf-__;!!NEt6yMaO-gk!HGNzVL5O3SuONL68ID9RkgvWVXQKE5p02Ng1HujKkz2fCOkhjoniaBHBMkrcrGlaW-MTcaLwE2a3aA$
>               bess-evpn-optimized-ir-12.txt>.

Broken ref
Wen: Fixed