[auth48] Re: Final Review: RFC-to-be 10018 (draft-ietf-bess-mvpn-evpn-sr-p2mp) in XML

[Madison Church <[e-mail]>]

Hi Rishabh,

Thank you for your reply! We have updated the document according to your responses to our questions. We just have a few followup items for your review (marked with [rfced] below in this thread). Updated files are also posted below.

> On Jul 21, 2026, at 7:32 PM, Rishabh Parekh <rishabh=[e-mail]> wrote:
> 
> RFC editors,
> Please find responses inline @  [RP]
> 
> Thanks,
> Rishabh
> 
> From: [e-mail] <[e-mail]>
> Date: Monday, July 20, 2026 at 9:46 PM
> To: Rishabh Parekh <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Re: Final Review: RFC-to-be 10018 (draft-ietf-bess-mvpn-evpn-sr-p2mp) in XML
> 
> Authors,
> 
> While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in the source file.
> 
> 
> 1) <!-- [rfced] Document title
> 
> a) Please note that the title of the document has been updated as
> follows. The abbreviation "P2MP" has been expanded per Section 3.6 of RFC
> 7322 ("RFC Style Guide"). Please review.
> 
> Original:
>   Multicast and Ethernet VPN with Segment Routing P2MP and Ingress
>   Replication
> 
> Current:
>   Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint
>   (P2MP) and Ingress Replication
> 
> b) In the abbreviated title (appears in the running header at top of each page
> in the PDF output), may we remove "BGP" to align more closely with the
> document title?
> 
> Original:
>   BGP MVPN and EVPN with SR P2MP and IR
> 
> Perhaps:
>   MVPN and EVPN with SR P2MP and IR
> —>
> 
> [RP] Fine.
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->

[rfced] We wanted to highlight question 2 just in case it may have been overlooked. Please confirm if you would like to add any keywords for this document.

> 3) <!-- [rfced] Please review the placement of the [RFC7988] citation. Is the
> intent to state the that "This document extends procedures in [RFC7988]"? Note
> that we also added "an" before "SR-MPLS data plane" and "SRv6 data plane".
> 
> Current:
>  This document extends procedures for MVPN service with IR over an SR-MPLS
>  [RFC7988] data plane with an SLA.  New procedures are defined for MVPN
>  service with IR over an SRv6 data plane with or without an SLA.
> 
> Perhaps:
>  This document extends procedures in [RFC7988] for MVPN service with IR over an SR-MPLS
>  data plane with an SLA.  New procedures are defined for MVPN
>  service with IR over an SRv6 data plane with or without an SLA.
> —>
> 
> [RP] Looks good to me.
> 
> 
> 4) <!-- [rfced] Please review "is by". Is a word missing here?
> 
> Original:
>    An SR P2MP tree instance is by a Candidate path of an SR
>    P2MP Policy [I-D.ietf-pim-sr-p2mp-policy].
> —>
> 
> [RP] Yes the word “instantiated is missing”, but the fix should change the preceding sentence too.
> 
> Section 2.
> 
> OLD:
> 
> For MVPN or EVPN, Provider Edge (PE) routers can steer customer
>  traffic into a P-tunnel that can be instantiated by SR-MPLS or SRv6
>  P2MP trees.  An SR PTI is by a CP of an SR P2MP Policy [RFC9960].
> 
> NEW:
> 
> For MVPN or EVPN, Provider Edge (PE) routers can steer customer
>  traffic into a P-tunnel realized by an SR-MPLS or SRv6
>  PTI.  An SR PTI is instantiated by a CP of an SR P2MP Policy [RFC9960].
> 
> 
> 5) <!-- [rfced] FYI - We updated "IR over SR-MPLS or SRv6 data plane" as follows
> to improve readability.
> 
> Current:
> MVPN service can be provided using SR P2MP trees or IR over SR-MPLS
> or SRv6 data plane.
> 
> Updated:
> MVPN service can be provided using SR P2MP trees or IR over either an SR-MPLS
> or SRv6 data plane.
> —>
> 
> [RP] Looks good to me.
> 
> 6) <!-- [rfced] FYI - We updated "Leaf Info Required" here to "Leaf Information
> Required" to align with usage in Section 3.2.2.
> 
> Original:
>    *  Flags: See Section 3.2.2 for use of "Leaf Info Required bit".
> 
> Current:
>    *  Flags: See Section 3.2.2 for use of the "Leaf Information Required" flag.
> —>
> 
> [RP] Fine.
> 
> 
> 7) <!-- [rfced] RFC 9960 appears to use "<Root, Tree-ID>" rather than "<Tree-ID,
> Root>". Should the following be updated accordingly, or is the current
> correct?
> 
> Current:
>    Tunnel Identifier: The SR P2MP P-tunnel identifies an SR P2MP Policy
>    with the identifier <Tree-ID, Root> [RFC9960] in
>    the order below:
> 
>    -  Tree-ID: A 32-bit unsigned value that uniquely identifies an SR
>       P2MP Policy at the Root.
> 
>    -  Root: An IP address identifying the Root of the SR P2MP Policy.
>       This can be either an IPv4 or IPv6 address.  The address type
>       can be inferred from the PTA length.
> 
> Perhaps:
>    Tunnel Identifier: The SR P2MP P-tunnel identifies an SR P2MP Policy
>    with the identifier <Root, Tree-ID> [RFC9960] in
>    the order below:
> 
>    -  Root: An IP address identifying the Root of the SR P2MP Policy.
>       This can be either an IPv4 or IPv6 address.  The address type
>       can be inferred from the PTA length.
> 
>    -  Tree-ID: A 32-bit unsigned value that uniquely identifies an SR
>       P2MP Policy at the Root.
> —>
> 
> [RP] The order is significant because it keeps the fixed length Tree-ID (32 unsigned value) before the variable length Root address (32-bit IPv4 or 128-bit IPv6  address) in the encoding of the PTA. This enables decoding  logic to use the last sentence in the Root field : “The address type can be inferred from the PTA length” since all preceding fields are fixed length. Perhaps a combination of the two approaches with strict directive on encoding  as shown below:
> 
> Section 3.2.1
> 
> NEW
> 
>    Tunnel Identifier: The SR P2MP P-tunnel identifies an SR P2MP Policy
>    with the identifier <Root, Tree-ID> [RFC9960] encoded in
>    the exact order below:
> 
>    -  Tree-ID: A 32-bit unsigned value that uniquely identifies an SR
>       P2MP Policy at the Root.
> 
>    -  Root: An IP address identifying the Root of the SR P2MP Policy.
>       This can be either an IPv4 or IPv6 address.  The address type
>       can be inferred from the PTA length.
> 
> 
> 
> 8) <!-- [rfced] Is "Function" correct below, or should it be updated to "Function
> part" or something else? Note that this text appears 3 times in the
> document.
> 
> Original:
> If Transposition scheme is used, ingress PE MUST merge Function in
> MPLS Label field of PTA with SRv6 SID in SID Information TLV using
> the Transposition Offset and Length fields from SID structure
> sub-sub TLV to create SRv6 Multicast Service SID.
> 
> Perhaps:
> If the Transposition Scheme is used, the ingress PE MUST merge the
> Function part of the MPLS Label field of the PTA with the SRv6 SID in the SID
> Information TLV using the Transposition Offset and Length fields
> from the SID Structure sub-sub-TLV to create the SRv6 Multicast Service
> SID.
> —>
> 
> [RP] Update to “Function part”. I see inconsistent usage of “Function” and “function” in the text, but question is which is correct? SRv6 RFC 8986 uses “function” but BGP SRv6 services RFC 9252 (normative reference for Prefix SID and Transposition scheme uses “Function”, so I would go with “Function part”. Of course, without the quotes.    
> 
> 
> 9) <!-- [rfced] Is "look at next SID in SRH" supposed to be quoted text from
> [RFC9524]?  We are unable to find the quote in that RFC, though we do see
> one instance of "looking at the next SID".
> 
> Current:
>    The egress PE, in role of Leaf or Bud node of Replication segment
>    associated with shared SR P2MP P-tunnel tree, uses "look at next SID
>    in SRH" [RFC9524] behavior to process the SRv6 Multicast Service SID.
> —>
> 
> [RP] This refers to the following text in Section 2.2 of RFC 9524, supported by the last bullet in the Section - starting with "There MAY be SIDs after the Replication-SID in the SRH of a packet. …"
> 
> For leaf and bud nodes, local delivery off the tree is per Replication-SID or the next SID (if present in the SRH). For some usages, this may involve getting the necessary context either from the next SID (e.g., MVPN with a shared tree) or from the Replication-SID itself (e.g., MVPN with a non-shared tree). 
> 
> Processing of “next SID” is captured in the below pseudo-code statement in Section 2.1.1 
> 
> S20.       Derive packet processing context (PPC) from Segment List
> 
> 
> 
> 10) <!-- [rfced] Should "constrains" be updated to "constraints" in the following
> sentence?
> 
> Current:
>    A PE interacts with an SR P2MP Policy module to create a CP, with
>    optional traffic engineering constrains and optimization objective,
>    of an SR P2MP Policy when it originates an Intra-AS I-PMSI A-D
>    route [RFC6514], or an Inter-AS I-PMSI A-D route for intra-AS segment
>    [RFC6514], or a S-PMSI A-D route [RFC6514], or "wildcard" S-PMSI A-D
>    route [RFC6625], with a PTA having SR P2MP P-tunnel type.
>    ...
>    A PE interacts with SR P2MP Policy module to create a CP, with
>    optional traffic engineering constrains and optimization objective,
>    of an SR P2MP Policy when it it originates an IMET A-D route
>    [RFC7432], or a S-PMSI A-D route [RFC9572], with a PTA having SR P2MP
>    P-tunnel type.
> 
> Perhaps:
>    A PE interacts with an SR P2MP Policy module to create a CP, with
>    optional traffic engineering constraints and optimization objectives,
>    of an SR P2MP Policy when it originates an Intra-AS I-PMSI A-D route
>    [RFC6514], an Inter-AS I-PMSI A-D route for an intra-AS segment
>    [RFC6514], an S-PMSI A-D route [RFC6514], or a "wildcard" S-PMSI A-D
>    route [RFC6625] with a PTA that has an SR P2MP P-tunnel type.
>    ...
>    A PE interacts with an SR P2MP Policy module to create a CP, with
>    optional traffic engineering constraints and optimization objectives,
>    of an SR P2MP Policy when it originates an IMET A-D route [RFC7432]
>    or an S-PMSI A-D route [RFC9572] with a PTA that has an SR P2MP P-tunnel type.
> —>
> 
> [RP] Yes, please fix this typo with same copy-and-paste typo in Section 4.1.3.1     
> 
> 
> 11) <!-- [rfced] The series in this sentence includes both "or" and "and". Is the
> intent to just use one of these?
> 
> Original:
>    A PE advertises Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D,
>    or Selective PMSI A-D and Leaf A-D routes with PTA for IR.
> 
> Perhaps:
>    A PE advertises Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D,
>    Selective PMSI A-D, and Leaf A-D routes with the PTA for IR.
> —>
> 
> [RP] A PE can use a combination of these route types it PTA for IR. For example, just an Intra-AS I-PMSI route, or a combination of an Inter-AS I-PMSI route and Leaf A-D route from another PE in response, or a combination of an S-PMSI A-D route and Leaf A-D  route from another PE in response depending on different policies and use cases. So it a combination of “and" and “or” and “and/or” 😊
> 
> 
> 
> 12) <!-- [rfced] Use of "Split Horizon"
> 
> a) Should "Split Horizon" in this title be updated to "Split-Horizon
> Filtering"?
> 
> Original:
>   4.1.2.  Split Horizon for ES Multihoming
> 
> Perhaps:
>   4.1.2.  Split-Horizon Filtering for ES Multihoming
> 
> 
> b) In the first sentence below, we updated "split-horizon" to "split-horizon
> filtering". In the second sentence, we updated "split-horizon filter" to
> "split-horizon filtering". Let us know any concerns.
> 
> Original:
>    Note, the
>    MPLS label stack may have ESI label at the bottom of label stack if
>    ESI-based split-horizon is used.
>    ...
>    Note, the End.DT2M
>    SID S10 may also have an Arg.FEs Argument if ESI-based split-horizon
>    filter is used.
> —>
> 
> [RP] Looks good to me.
> 
> 
> 13) <!-- [rfced] Should "and ES of origin" be "an ES of origin" in the sentence below?
> 
> Original:
> For an SR P2MP P-tunnel, the Arg.FE2 SID Argument is an
> upstream-assigned value assigned by an ingress PE and identifies
> and ES of origin.
> 
> Perhaps:
> For an SR P2MP P-tunnel, the Arg.FE2 SID argument is an
> upstream-assigned value assigned by an ingress PE and identifies
> an ES of origin.
> —>
> 
> [RP] Yes.   
> 
> 
> 14) <!-- [rfced] TLV names
> 
> a) We see both of the following forms in this document:
> 
>   SID structure sub-sub TLV
>   SRv6 SID Structure Sub-Sub-TLV
> 
> Should instances of "SID structure sub-sub TLV" be updated to "SRv6 SID
> Structure Sub-Sub-TLV" (per RFC 9252)?
> 
> b) We also see both of the following:
> 
>   SRv6 SID Information Sub-TLV
>   SID Information TLV
> 
> Are these referring to the same thing or to different things? Let us know if
> any updates are needed.
> —>
> 
> [RP]
>     • Yes
>     • These are the same thing. Please update to SRv6 SID Information Sub-TLV everywhere.
> 
> 15) <!-- [rfced] Terminology
> a) RFC 7432 uses "BGP MPLS-Based Ethernet VPN" rather than "BGP MPLS Ethernet
> VPN". If there are no objections, we will update the instances below as follows
> for consistency.
> Current:
>    For BGP MPLS Ethernet VPN specified in [RFC7432] and extensions
>    [RFC9572], P-tunnels are advertised for handling multi-destination
>    traffic.
>    ...
>    BGP MPLS Ethernet VPN specified in [RFC7432] specifies IMET route to
>    support BUM traffic.
> Perhaps:
>    For BGP MPLS-Based EVPN specified in [RFC7432] and extensions
>    [RFC9572], P-tunnels are advertised for handling multi-destination
>    traffic.
>    ...
>    BGP MPLS-Based EVPN, specified in [RFC7432], specifies IMET route to
>    support BUM traffic.
> b) We see the following forms in this document. We updated to the second form,
> (no quotation marks).
> MPLS Label field
> "MPLS Label" field
> We also see "label field" in the document. We updated to "Label field"
> (capitalized). Should these be further updated to "MPLS Label field"?
> c) We see the following inconsistencies in the document. We updated to the
> latter form per usage in RFC 8986. Please review and let us know any concerns.
> SRv6 endpoint behavior
> SRv6 Endpoint Behavior
> SRv6 Endpoint behavior
> d) Should "optimization objective" be updated to "optimization objectives"
> (plural) in the sentences below?
> Original:
>    This CP can have optional traffic
>    engineering constraints and/or optimization objective by provisioning
>    or by a local policy.
>    ...
>    The SR P2MP Policy module signals the CP along
>    with the constraints and optimization objective to the controller
>    using a protocol mentioned above.
>    ...
>    Given a Leaf set of an SR P2MP Policy and a CP with constraints and
>    optimization objective, the controller computes and instantiates the
>    PTI on the nodes that are part of the tree by stitching Replication
>    segments [RFC9524] at Root (ingress PE) node, intermediate
>    replication nodes and Leaf nodes (egress PEs).
>    ...
>    A PE interacts with SR P2MP Policy module to create a CP, with
>    optional traffic engineering constrains and optimization objective,
>    of an SR P2MP Policy when it it originates an Intra-AS I-PMSI A-D
>    route [RFC6514], or an Inter-AS I-PMSI A-D route for intra-AS segment
>    [RFC6514], or a S-PMSI A-D route [RFC6514], or "wildcard" S-PMSI A-D
>    route [RFC6625], with a PTA having SR P2MP P-tunnel type.
>    ...
>    A PE interacts with SR P2MP Policy module to create a CP, with
>    optional traffic engineering constrains and optimization objective,
>    of an SR P2MP Policy when it it originates an IMET A-D route
>    [RFC7432], or a S-PMSI A-D route [RFC9572], with a PTA having SR P2MP
>    P-tunnel type.
> —>
> 
> [RP]
>     • Fine
>     • Fine and yes please change the occurrences of Label field to MPLS Label field
>     • Fine
>     • A CP may have one optional optimization objective (usually with a default when the objective is not specified)  but may have zero or more  constraints (optional too).

[rfced] Thanks for your clarification! To further clarify that a CP may have one optional optimization objective, may we update the instances below as follows?

Original:
   This CP can have optional traffic
   engineering constraints and/or optimization objective by provisioning
   or by a local policy.
   ...
   Given a Leaf set of an SR P2MP Policy and a CP with constraints and
   optimization objective, the controller computes and instantiates the
   PTI on the nodes that are part of the tree by stitching Replication
   segments [RFC9524] at Root (ingress PE) node, intermediate
   replication nodes and Leaf nodes (egress PEs).
   ...
   A PE interacts with SR P2MP Policy module to create a CP, with
   optional traffic engineering constrains and optimization objective,
   of an SR P2MP Policy when it it originates an Intra-AS I-PMSI A-D
   route [RFC6514], or an Inter-AS I-PMSI A-D route for intra-AS segment
   [RFC6514], or a S-PMSI A-D route [RFC6514], or "wildcard" S-PMSI A-D
   route [RFC6625], with a PTA having SR P2MP P-tunnel type.
   ...
   A PE interacts with SR P2MP Policy module to create a CP, with
   optional traffic engineering constrains and optimization objective,
   of an SR P2MP Policy when it it originates an IMET A-D route
   [RFC7432], or a S-PMSI A-D route [RFC9572], with a PTA having SR P2MP
   P-tunnel type.

Perhaps:
   This CP can have optional traffic
   engineering constraints and/or an optional optimization objective by provisioning
   or by a local policy.
   ...
   Given a Leaf set of an SR P2MP Policy and a CP with optional traffic 
   engineering constraints and an optimization objective, the controller 
   computes and instantiates the PTI on the nodes that are part of the tree 
   by stitching Replication segments [RFC9524] at Root (ingress PE) node, intermediate
   replication nodes and Leaf nodes (egress PEs).
   ...
   A PE interacts with SR P2MP Policy module to create a CP, with
   optional traffic engineering constrains and an optional optimization objective,
   of an SR P2MP Policy when it it originates an Intra-AS I-PMSI A-D
   route [RFC6514], or an Inter-AS I-PMSI A-D route for intra-AS segment
   [RFC6514], or a S-PMSI A-D route [RFC6514], or "wildcard" S-PMSI A-D
   route [RFC6625], with a PTA having SR P2MP P-tunnel type.
   ...
   A PE interacts with SR P2MP Policy module to create a CP, with
   optional traffic engineering constrains and an optional optimization objective,
   of an SR P2MP Policy when it it originates an IMET A-D route
   [RFC7432], or a S-PMSI A-D route [RFC9572], with a PTA having SR P2MP
   P-tunnel type.

The files have been posted here:
   https://www.rfc-editor.org/authors/rfc10018.txt
   https://www.rfc-editor.org/authors/rfc10018.pdf
   https://www.rfc-editor.org/authors/rfc10018.html
   https://www.rfc-editor.org/authors/rfc10018.xml

Diff files are posted below:
   https://www.rfc-editor.org/authors/rfc10018-diff.html
   https://www.rfc-editor.org/authors/rfc10018-rfcdiff.html (side by side)
   https://www.rfc-editor.org/authors/rfc10018-auth48diff.html
   https://www.rfc-editor.org/authors/rfc10018-auth48rfcdiff.html (side by side)

For the Final Review status page, please see: https://queue.rfc-editor.org/final-review/rfc10018/.

Thank you!
Madison Church
RFC Production Center

> 16) <!-- [rfced] We added articles (i.e., "a", "an", and "the") in a number of
> instances, for example, before names of fields, flags, and attributes.
> Please review and let us know if any further updates are needed.
> —>
> 
> [RP] Looks good to me.
> 
> 17) <!-- [rfced] Abbreviations
> a) How should the following abbreviations be expanded in this document?
> SLA
>   Note: Perhaps as "Service Level Agreement (SLA)"?
> LOC
> BoS label
>   Note: Perhaps as "label at the bottom of the stack"?
> b) FYI - We have added expansions for abbreviations upon first use
> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness.
> Label Switched Paths (LSPs)
> Path Computation Element Communication Protocol (PCEP)
> Network Configuration Protocol (NETCONF)
> Segment Routing over MPLS (SR-MPLS)
> Segment Routing over IPv6 (SRv6)
> —>
> 
> [RP]
>     • Service Level Agreement (SLA) works. 
>               LOC is the locator part of SRv6 SID - Section 3.1 RFC 8986. Perhaps locator (LOC)
>              BoS label is Bottom-of-Stack MPLS label but I cannot remember the RFC reference for this.>
>         b) Fine
> 
> 
> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed.  Updates of this nature typically
> result in more precise language, which is helpful for readers.
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
> —>
> 
> [RP] Looks good to me.
> 
> Thank you.
> Madison Church and Rebecca VanRheenen
> RFC Production Center
> On Jul 20, 2026, at 9:43 PM, [e-mail] wrote:
> *****IMPORTANT*****
> RFC Author(s):
> --------------
> Final Review for RFC-to-be 10018 <draft-ietf-bess-mvpn-evpn-sr-p2mp>
> Your document is now available for Final Review (previously 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;
> see the Unavailable Authors section
> (https://authors.ietf.org/rfc-publication-process#unavailable-authors)
> 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 an archival mailing list
>      to preserve discussion about the document while in the RPC editorial
>      queue; 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/rfc10018.xml
>   https://www.rfc-editor.org/authors/rfc10018.html
>   https://www.rfc-editor.org/authors/rfc10018.pdf
>   https://www.rfc-editor.org/authors/rfc10018.txt
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc10018-diff.html
>   https://www.rfc-editor.org/authors/rfc10018-rfcdiff.html (side by side)
> Alt-diff of the text (allows you to more easily view changes
> where text has been deleted or moved):
>   https://www.rfc-editor.org/authors/rfc10018-alt-diff.html
> Diff of the XML:
>   https://www.rfc-editor.org/authors/rfc10018-xmldiff1.html
> Tracking progress
> -----------------
> Details on the status of your Final Review are here:
>   https://queue.rfc-editor.org/final-review/rfc10018/
> Please let us know if you have any questions.
> Thank you for your cooperation,
> RFC Editor
> --------------------------------------
> RFC 10018 (draft-ietf-bess-mvpn-evpn-sr-p2mp)
> Title            : Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication
> Author(s)        : R. Parekh, Ed.,
>                   D. Voyer, Ed.,
>                   C. Filsfils,
>                   H. Bidgoli,
>                   Z. Zhang
> WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui Zhang
> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
> [EXTERNAL]