RFC editors, Please find responses inline @ [RP] Thanks, Rishabh
From: [email protected] <[email protected]> Date: Monday, July 20, 2026 at 9:46 PM To: Rishabh Parekh <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> 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. --> 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] 1. Yes 2. 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] 1. Fine 2. Fine and yes please change the occurrences of Label field to MPLS Label field 3. Fine 4. 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). 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] 1. 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, [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 [EXTERNAL]
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
