Hi Rishabh, *Gunter, *Gunter - As responsible AD for this document, please review the changes in the first paragraph in Section 2 (see https://auth48-transition.rfc-editor.org/authors/rfc10018-auth48diff.html). Additionally, please review followup question 2 below and let us know if you approve the added sentence in the Abstract.
Rishabh - Thank you for confirming! We have two final followup questions. 1) For the following: > 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). 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. 2) May we add this sentence to the end of the abstract to indicate that this document updates RFCs 6514 and 7988? See https://authors.ietf.org/en/required-content#abstract. Perhaps: This document updates RFCs 6514 and 7988. 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 > On Jul 23, 2026, at 6:26 PM, Rishabh Parekh <[email protected]> wrote: > > Madison, > Inline @ [RP2] > > From: Madison Church <[email protected]> > Date: Wednesday, July 22, 2026 at 10:47 AM > To: Rishabh Parekh <[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]>; [email protected] > <[email protected]> > Subject: Re: Final Review: RFC-to-be 10018 > (draft-ietf-bess-mvpn-evpn-sr-p2mp) in XML > > IRONSCALES couldn't recognize this email as this is the first time you > received an email from this sender mchurch @ staff.rfc-editor.org > > 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 wrote: > > > > RFC editors, > > Please find responses inline @ [RP] > > > > Thanks, > > Rishabh > > > > From: [email protected] > > Date: Monday, July 20, 2026 at 9:46 PM > > To: Rishabh Parekh ; [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] > > 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] 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. > > [RP2] I can’t think of any other keywords. > > > 3) > > 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 > > and are set correctly. See details at > > . > > * 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] > > [EXTERNAL] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
