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 > <[email protected]> wrote: > > 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. --> [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, [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]
