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
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
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.
-->
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].
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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)
-->
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.
-->
Thank you.
Madison Church and Rebecca VanRheenen
RFC Production Center
On Jul 20, 2026, at 9:43 PM, [email protected] 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
* [email protected] (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).
* [email protected], 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,
[email protected] 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
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
