Hi Rishabh, I believe Ketan is out this week. Maybe best to publish to expedite processing feedbacks and resolve remaining open items.
G/ From: Rishabh Parekh <[email protected]> Sent: Thursday, October 23, 2025 12:58 AM To: Ketan Talaulikar <[email protected]> Cc: The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [bess] Ketan Talaulikar's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Ketan, I have the next revision of the restructured document ready which addresses most of discuss/comments from you and other reviewers. Do you want me to share the updated document on this thread, or do you want me to publish it so it can be reviewed by others too? Thanks, Rishabh. On Fri, Oct 17, 2025 at 3:19 AM Ketan Talaulikar <[email protected]<mailto:[email protected]>> wrote: Hi Rishabh, Thanks for your responses and your patience as we discuss these points. I understand that the changes are not trivial and I would wait for them to be posted or shared before we continue forward. Regarding the normative reference to at least one signaling solution (PCEP?), let me see how the updates are coming out with an informative reference and more details on the interaction/signaling and then we can progress further. Thanks again, Ketan On Fri, Oct 17, 2025 at 9:54 AM Rishabh Parekh <[email protected]<mailto:[email protected]>> wrote: Ketan, Responses inline @ [RP2]. Give us some time to reorganize the document to address some of your discuss/comments Thanks, Rishabh. On Mon, Oct 13, 2025 at 8:28 AM Ketan Talaulikar <[email protected]<mailto:[email protected]>> wrote: Hi Rishabh, Thanks for your quick response. Please check inline below with KT for follow-up and clarifications. I am skipping responding to ones where we have reached an agreement. On Fri, Oct 10, 2025 at 5:30 AM Rishabh Parekh <[email protected]<mailto:[email protected]>> wrote: Ketan, Thanks for a thorough review. Responses inline @ [RP] On Wed, Oct 8, 2025 at 7:50 AM Ketan Talaulikar via Datatracker <[email protected]<mailto:[email protected]>> wrote: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to the authors and the WG for this work. I found the document hard to read and follow perhaps due to its organization. I don't see any major technical issues, but I am concerned that there are some aspects that may have been left out. Please find below some points for discussions. This is my attempt to get a better understanding of the proposals while offering some suggestions that hopefully improve the document. discuss#1: MVPN vs EVPN - clarity of procedures I get the impression that sections 2, 3, 9, and 10 are common. Sections 4,5, and 6 are MVPN specific. Section 7 is EVPN specific. However, section 3 seems not to touch upon EVPN but only MVPN. As a result of this, someone that is interested in implementing only one of two needs to struggle to understand the "bread crumbs" all over the document. This seems especially challenging for EVPN where things are sparse. Notably there is no reference to RFC9252 for EVPN multicast and the level of details are not the same as for MVPN. The comments sections has more details. [RP] Section 3 is meant to specify construction of RFC 6514 BGP PMSI Tunnel Attribute (PTA) for SR P2MP trees for both SR-MPLS and SRv6. This attribute was initially specified for BGP MVPN RFC 6514 and then used for EVPN Inclusive Multicast Ethernet Tag route in RFC 7432 and other EVPN routes defined in RFC 9572. This section is not meant to be specific for MVPN or EVPN. KT> If section 3 (and in general) is supposed to cover both MVPN and EVPN then please follow the same consistent approach for both - for more detailed suggestions please see responses on this further in the comments part below. An example of something that is not clear is if the new behaviors End.DTMC4/6/46 apply to EVPN (as in say RFC9625) ? We can add a reference to RFC 9252 in Section 3.1.2, but I am not sure I understand your comment about "RFC 9252 for EVPN multicast". Section 6.3 of RFC 9252 specifies how PTA is constructed for the Inclusive Multicast Ethernet Tag route over SRv6 core and Section 6.6 briefly mentions how other EVPN routes used for multicast do not have any SRv6 considerations. Besides that, I don't see anything related to EVPN multicast in that RFC. KT> Can SR P2MP Tree be used for EVPN IMET Routes? I believe the answer is yes. However, this document goes into much more detail by not just covering ingress replication (which is what is covered by RFC 9252?) but also SR P2MP Tree usage. Should this document then update RFC 9252 and clarify multicast usage for EVPN? [RP2] I think so, especially for upstream assigned ESI context (similar to upstream assigned ESI label mentioned in Section 8,3.1.2 of RFC 7432 for P2MP MPLS LSPs used for BUM) and how it is encoded in the SRH of SRv6 P2MP tree. Let me see how I can reword Section 3 or split it into two for MVPN and EVPN and also add more details to the EVPN section. discuss#2: The Color EC is specified in RFC9012. What RFC9830 did was to introduce the CO bits for color-only steering. I believe the reference here is not to those CO bits but just the base color EC? If so, then RFC9012 is the right reference and should be a normative one. [RP] I can add a reference to RFC 9012 or replace RFC 9830 reference, though the color-only steering applies here too. Do you want me to make these references normative? KT> Please check https://www.rfc-editor.org/rfc/rfc9256.html#section-8.8.1 and if the types other than Type 0 can be applied for MVPN/EVPN to determine if Color-only steering of RFC9830 applies. This is about null endpoints and any endpoint while VPNs will have a specific context on the PEs. Yes, the reference would need to be normative and RFC9012 is needed for sure; you can determine if RFC9830 also applies. [RP2] Yes, both types 1 and 2 apply in this case too since an egress PE can individually set the color types in the Ext Color community I will make both RFC 9012 and 9830 references normative and also add text about applicability of Color Ext Community to MVPN SAFI. discuss#3: The MVPN and EVPN discovery procedures help the ingress PE (root) discover the egress PEs (leaves). From thereon, there is need for a protocol like PCEP to perform signaling from the ingress PE router to the controller so that the controller can compute and instantiate a P2MP tree in the network. This makes the PCEP spec (draft-ietf-pce-sr-p2mp-policy) a normative reference and required feature for the realization of this solution. At least one signaling protocol spec (I would guess PCEP is the one that is implemented) is required. This is explained in section 2 but is not clear enough on the workflow. Also, "controller" and signaling between routers and controllers is brought up in several other sections without sufficient clarity. Please consider explaining in detail in section 2 and then it can be skipped in the further sections. [RP] This document focuses on MVPN and EVPN Auto-Discovery procedures. The interaction between ingress PE and controller is specified in draft-ietf-pim-sr-p2mp-policy and it is the normative reference in this document. The signaling protocol between PE and controller can be PCEP, BGP, Netconf/YANG or even proprietary protocol. In fact, an ingress PE can itself serve as the controller to compute the P2MP trees (and program these in the network) and this would not require any signalling for Leaf auto-discovery. Therefore, I don't think any one signaling protocol spec needs to be a normative reference in this document. KT> I agree that there may be multiple options for communication between ingress PE and controllers. However this solution, to be implemented and interoperable, requires at least one of them that is standardized in the IETF. And, my understanding is that this has been done by implementations referenced using the PCEP extensions that I was referring to. It does not imply that others are precluded. But IMHO at least one standardized mechanism is a requirement for the solution in this document. Therefore, a normative reference. [RP2] I still think making the PCEP document a normative reference is not required. It may be required for a complete solution, but certainly not a requirement for interoperability. IMO, it might create an impression that PCEP is the preferred protocol. I can add an informative reference if that will help to point to one possible protocol that can be used. Can you please elaborate what is not clear about interaction between ingress PE and controller in Section 2 and other sections? We can try to improve the text to address your concerns. Also, what is repeated from Section 2 in other sections? KT> First, there is no specific text in Section 2 that says that it is only the ingress PE that needs to talk to the controller. There is no text saying that the discovery procedures provide the SR P2MP Policy instantiated on the Ingress PE with the knowledge of the leaves which is then signaled to the controller as indicated in the SR P2MP Policy spec. How is the candidate path instantiated? Basically, I was looking for more detailed and generalized text in this section 2 that references and leverages the SR P2MP Policy spec and explains in more detail the connective tissue between that document and the discovery procedures. I believe it should be possible to generalize them in a way that applies to both MVPN and EVPN in this section. Then the further sections can just touch upon the MVPN/EVPN specifics and refer to this section? [RP2] I will try to add some text in Section 2 providing an overview of interactions with SR P2MP policy covering the points you mentioned above. discuss#4: Some informative references should be normative - please refer to the comments section for details. [RP] Ok, I will respond to the comment. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please find below some comments on this document provided in the idnits output of v15 of the document. Please look for <EoRv15> at the end of this email and if not found, refer to the mailing list for the full review. < general editorial > The document makes the reader jump back and forth and across the text several times which affects the readability and flow. Please consider if you would like to do some reorganization to improve readability by introducing specific common constructs/topics upfront before they are referenced. Some repetition could be avoided. Clearing covering both MVPN and EVPN seperately (in independent sections) and with similar details would also help. [RP] Can you suggest reorganization of the structure to improve the readability and flow? Section 2 and 3 were meant to be the common sections for MVPN and EVPN. Section 7 is an independent section for EVPN. If you want to have two independent sections for MVPN and EVPN, we can move Sections 5 & 6 as sub-sections under Section 4, but MVPN with IR is distinct from MVPN with SR P2MP trees and Section 6 about dampening applies to both. KT> There are different ways to reorganize and ultimately I will leave it to the authors. If there are common sections, please treat both MVPN and EVPN the same - either explain both inline or provide references for both to their respective sections. Then for both MVPN and EVPN, there is ingress replication and P2MP Trees - please cover both flavors (reference/leverage/update what is covered in RFC9252 for EVPN as appropriate). Ideal would be to have more common parts - but this may not be right if there are subtle differences - here I am referring to the SRv6 encoding parts and the transposition specifically. For the MVPN and EVPN, you could have one section for each and then explain the aspects as sub-sections - or keep how it is today as long as there is clarity (which is MVPN and which is EVPN) and coverage. [RP2] We will try to reorganize to keep as many common parts together as we can, and then deal with MVPN and EVPN separately. ... 169 PE routers use the MVPN or EVPN auto-discovery procedures in this 170 document to create, update and delete SR P2MP Policies on the 171 controllers using various methods such BGP, PCEP, NetConf etc., which 172 are outside the scope of this document. <major> Said in a different way, isn't this about discovering the root and leaves for the multicast service and feeding this information into say PCEP for building the P2MP trees using the SR P2MP Policy construct using a controller? Please consider if something like that could be explained more directly and help the reader understand what is happening here. [RP] I think this is related to Discuss #3 above. I will wait for your response to my questions on that discuss before changing the text in Section 2. KT> I hope the clarifications help. [RP2] Yes, it does. ... 225 specific MVPN. For EVPN considerations, see Section 7 section. <major> This is hard to follow when there is a pointer to section 7 for EVPN [RP] What is hard to follow? KT> Let me explain. This section has the following text but section 7 says nothing about the MPLS Label field and encoding for EVPN. This section specifies how the "MPLS Label" field of PTA is filled to provide a context bound to a specific MVPN. For EVPN considerations, see Section 7<https://www.ietf.org/archive/id/draft-ietf-bess-mvpn-evpn-sr-p2mp-15.html#EVPN> section. [RP2] I hope the re-organization of the document helps with this. ... 319 When a PE originates an Intra-AS I-PMSI A-D route with a PTA having 320 SR P2MP P-Tunnel Type, it MUST create a Candidate Path of SR P2MP 321 policy on the controller. The Leaf nodes of P2MP tree are discovered <major> The SR P2MP Policy document says that the SR P2MP Policy and its CPs are instantiated on the root node. In this case, I assume that would be the case (instantiation via BGP based discovery and PCC-init) as opposed to a controller provisioned SR P2MP Policy? It would be better to leave the controller and the controller to router signaling (say via PCEP) in section 2? [RP] You are correct about the details of the procedure, but this text is meant to specify *when* to initiate the constructs necessary for SR P2MP policy so that a controller can compute the tree for the SR P2MP P-Tunnel. Conceptually, the MVPN module interacts with the SR P2MP Policy module on the ingress PE to create a new SR Policy <Ingress PE, Tree-ID> with a CP (with optional constraints and optimization objective). The SR P2MP Policy then uses a signaling protocol to convey these to the controller. Similarly, other sections describe when to modify the Leaf set of the SR P2MP policy and when to delete the CP. Are you suggesting that we put this high level overview in Section 2, and then omit the details in Section 4? KT> Yes, precisely something on those lines is what I am referring to above in discuss#3. [RP2] Response to discuss#3 above should address this. But, I think it is still important to specify when MVPN module interacts with SR P2MP Policy module (and with what operation) when originating or processing MVPN/EVPN Auto-Discovery routes. KT> I agree. However, it should be already clear in existing specs which routes signal the addition/removal of leaves. If those procedures are well-known and covered, then perhaps the explanation can be trimmed. This is entirely up to the authors, more does not hurt - but consider if something else gets added and it is not covered for MVPN/EVPN and it is not covered in this spec. .... 473 field [RFC6514] of the Leaf A-D route. When the PE receives the 474 first Leaf A-D route from a Leaf PE, identified by the Originating 475 Router's IP address field, it MUST add that PE as Leaf of the SR P2MP 476 Policy on the controller. <major> How is "add that PE as Leaf of the SR P2MP Policy on the controller" done? Suggest to explain all these workflows up front in section 2 as they are common/similar for both MVPN and EVPN discovery? [RP] Again related to discuss #3 and some comments above. I will make the change once we have an agreement on what to do. KT> I hope this is clarified. [RP2] Yes. 501 egress PEs using best-effort unicast connectivity. For MVPN service 502 with a SLA from ingress PE to an egress PE, the egress PE colors the 503 Leaf Auto-Discovery route with a Color Extended Community as 504 specified in [I-D.ietf-idr-sr-policy-safi]. The ingress PE <major> This is related to discuss#2. The Color EC is specified in RFC9012. Is this specific to ingress replication? Can it not be used with SR P2MP Tree? [RP] No, this procedure is specific to MVPN IR (over SR) only because each egress PE can independently signal the color and therefore the Point-to-Point SR Policy used to send traffic from the ingress PE to that specific egress PE. It is possible that the SR Policies towards different egress PEs may have differing constraints/objectives and thereby each ingress replicated packet can have its own traffic engineered path to the respective egress PEs.. KT> Please see my response to discuss#2 to clarify the difference between color-only steering and color-based steering. Btw, would this not apply to EVPN IR ? [RP2] Both apply. Of course with color based steering, each egress PE may have different traffic engineering criteria, whereas color-only steering (either with null or any endpoint matching policies) will have uniform traffic engineering to all egress PEs. Yes, this applies to EVPN IR too, but we have not addressed it in this document; though it will be similar to MVPN IR but just for different EVPN routes. For P2MP trees, the ingress PE dictates the traffic engineering treatment (possibly by provisioning of constraints/optimizations on the ingress PE for MVPN) for each SR P2MP tree used for MVPN/EVPN service. This is necessary because packets are efficiently replicated in the SR P2MP tree and therefore it is not feasible to have different traffic engineering treatment towards different egress PEs (leaf nodes) of SR P2MP trees. Therefore, the Color EC is not used with MVPN/EVPN over SR P2MP trees. This also ties in with the identifier of SR P2MP Policy being (Root, Tree-ID) in draft-ietf-pim-sr-p2mp-policy and omitting color from the identifier. KT> This is a very important aspect and it is not reflected in the document. Please capture this in the text - I guess in the common part. That said, the Color from the BGP routes (MVPN/EVPN) can be conveyed by the MVPN/EVPN module to the SR P2MP module which can then convey it via PCEP as additional constraints for the CP. I have not yet reviewed the PCEP document. Perhaps you can say this is outside the scope of this document and leave it for the PCEP document? I hope you are able to see how details that are important for interoperability come out once we get into the connective tissue between these specifications. [RP2] I can try to capture this in the common part, or at least make the distinction clear in the MVPN IR section. As I explained earlier, the ingress PE dictates the traffic engineering criteria for MVPN with SR P2MP trees. Color can be used as an abbreviation for TE constraints and optimization objective for provisioning on ingress PE and even for signalling these as SR P2MP policy CP attributes to the controller. I believe there is a PCEP draft to signal color from PCC to PCE (with consistent definition on PCC and PCE) instead of the traditional constraints PCEP object. However, the Color Extended Community is not required in signalling of MVPN/EVPN A-D routes between the PEs. 570 The SRv6 Multicast Service SID MUST be routable within the AS of the 571 egress PE. As per RFC 7988, the Ingress PE uses the Tunnel 572 Identifier of PTA to determine the unicast tunnel to use in order to 573 send data to the egress PE. For SRv6 IR, the ingress PE MUST use the 574 SRv6 Multicast Service SID to determine the unicast tunnel to be 575 used. For both best-effort MVPN service and SLA-based MVPN service 576 using IGP Flexible Algorithm, the ingress PE MUST encapsulate the 577 payload in an outer IPv6 header, with the SRv6 Multicast Service SID 578 provided by the egress PE used as the destination address. If 579 Transposition Scheme is used, ingress PE MUST merge Function in MPLS 580 Label field of PTA with SRv6 SID in SID Information TLV using the 581 Transposition Offset and Length fields from SID structure sub-sub TLV 582 to create SRv6 Multicast Service SID. <minor> Except for the tunnel type, there is major duplication of the text in this section 5.2 and section 3.1.2 - it would help to perhaps consolidate in a single section and explain just the differences between ingress replication and use of P2MP Tree usage? [RP] Even though there is some duplication, there are also subtle differences between the two besides the tunnel type. For SRv6 MVPN IR, the SRv6 Multicast Service SID must be routable because it carries the packet from ingress PE, or some intermediate P router, to the egress PE. But for MVPN over SRv6 P2MP trees, the SRv6 Multicast Service SID in SRH of packet is only used to derive MVPN context when one SRv6 P2MP P-Tunnel (i.e. SRv6 P2MP tree) is shared across two or more MVPN contexts. In that case, the SRv6 Multicast Service SID may not be routable. In fact, it ideally should not be routable because it should not be mistakenly used to incorrectly forward a packet from an egress PE to the ingress PE or some other SRv6 device. I think it will be difficult to consolidate the text in once section. KT> Sure, as indicated in a previous comment, I thought as much. It is ok to duplicate the text in such cases with clear document organization and text that conveys the applicability. 595 5.2.1. SRv6 Multicast Endpoint Behaviors <major> These behaviors are applicable for both ingress replication and P2MP tree mechanisms but the section has been placed under ingress replication. This is confusing. Also, there are references to these behaviors in the text before they are specified. Please consider moving this section at the top-level and towards the beginning of the draft (say after section 2?). [RP] These behaviors are used for the same purpose both in IR and P2MP tree to derive the MVPN context on egress PE. However, these are only required for P2MP trees when trees are shared across MVPN contexts (optional behavior). If there is one-to-one association between SR P2MP tree and an MVPN instance, the Tree-SID is sufficient to determine the context. I can add a forward reference to Section 5.2.1 in Section 3.1.2. Will that be sufficient? KT> What about EVPN? Are they applicable to EVPN? I would still think it is best to put these upfront in their own section so that the reader is aware of them and then they can be used/referenced directly in the texts further down. Right now, it is buried deep in a section and there is no reference to these new behaviors in either the abstract or the introduction. Quite likely they get missed by reviewers in other WGs - e.g., I don't find this being shared with the SPRING WG for their review. [RP2] No, they are not applicable to EVPN, but we will move these to their own section. AFAIR, Spring WG was CCed either during WG adoption or WGLC of the document. 627 6. Dampening of MVPN routes <minor> I am missing what is SR P2MP specific here. Is this all not generic? [RP] Yes it is generic, but Leaf A-D routes should be dampened as described in the second paragraph of this section. Otherwise, a rapidly flapping Leaf node can impact the volume of ingress PE to controller signalling for Leaf addition/deletion. So this section is just for the SHOULD recommendation. We can remove it if it does not contribute to the document. KT> I was wondering if I am missing something specific to SR P2MP. I will leave it to the authors - no issue in retaining this text from my side. [RP2] Ok. 642 7. SR P2MP Trees for EVPN <major> There is no reference to RFC9252 here for SRv6 which I find strange, perhaps I am missing something. [RP] There is no reference to RFC 9252 because this document does not change any procedures in Section 6.3 (IMET route over SRv6) which clearly is specified for IR because the last paragraph in that section is "Usage of multicast trees as P-tunnels is outside the scope of this document." KT> Correct. However, it is not as clear to some readers (I've gotten complaints as co-author of RFC9252 :-() ... so, it would be good to clarify this part in this document. Note that RFC9252 does not cover IR for EVPN RFC9625 which this document covers? [RP2] I don't think RFC 9625 introduces any new requirements for IR, or am I missing anything? There is no elaborations (subsections) for ingress replication and SR P2MP tree usage. [RP] IR for IMET EVPN is already specified in RFC 7432 and 9252. SR P2MP tree usage for EVPN is mainly about encoding the PTA field in various EVPN routes that carry this attribute. KT> Hope my previous comments have clarified. [RP2] Yes There is no reference to the SRv6 Endpoint Behaviors to be used nor for the SRv6 encoding as explained for MVPN. [RP] The SRv6 Multicast Endpoint behaviors defined in this document are for L3 only because End.DT4/6 are specific for unicast. KT> What are the SRv6 behaviors to be used for EVPN? Just the End.DT2M or also the ones introduced in this document? For both IR and P2MP Tree. [RP2] Yes, just the End.DT2M, but we will add text of how this SID is encoded in SRH for SRv6 P2MP trees and the processing on egress PEs to use the Arg.FE2 portion for ESI filtering. 673 SRv6 P2MP trees can serve as an underlay multicast as described in 674 RFC 8293 Section 3.4 (https://tools.ietf.org/html/rfc8293#section- <major> There is no description of SRv6 in RFC8293 [RP] AFAIR, this text was added based on a comment by Luc Andre Burdet during WG adoption. But I agree, RFC 8293 does not refer to SR and therefore this paragraph can be removed. KT> Perhaps cross-check if there is another better reference and if not, then this document should be covering it? [RP2] We will remove the text related to RFC 8293. ... 765 10. Security Considerations 767 The procedures in this document do not introduce any additional 768 security considerations beyond those mentioned in [RFC6513] and 769 [RFC6514]. For general security considerations applicable to SR P2MP 770 Policy and Replication segments, please refer to 771 [I-D.ietf-pim-sr-p2mp-policy] and [RFC9524] respectively. <major> Anything on EVPN? [RP] Added references to EVPN RFCs 7432 and 9572 887 [I-D.ietf-idr-sr-policy-safi] 888 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and 889 D. Jain, "Advertising Segment Routing Policies in BGP", 890 Work in Progress, Internet-Draft, draft-ietf-idr-sr- 891 policy-safi-13, 6 February 2025, 892 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- 893 policy-safi-13>. <nit> This is now RFC9830 ... but perhaps this reference isn't even required? [RP] Yes, this has been discussed in response to the above comment about Color EC. Once we conclude, I will either remove this reference or change it to RFC 9830. [RP2] Retained the reference as explained above. 895 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 896 Label Assignment and Context-Specific Label Space", 897 RFC 5331, DOI 10.17487/RFC5331, August 2008, 898 <https://www.rfc-editor.org/info/rfc5331>. 900 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 901 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 902 RFC 6625, DOI 10.17487/RFC6625, May 2012, 903 <https://www.rfc-editor.org/info/rfc6625>. 905 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 906 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 907 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 908 2015, <https://www.rfc-editor.org/info/rfc7432>. 910 [RFC7899] Morin, T., Ed., Litkowski, S., Patel, K., Zhang, Z., 911 Kebler, R., and J. Haas, "Multicast VPN State Damping", 912 RFC 7899, DOI 10.17487/RFC7899, June 2016, 913 <https://www.rfc-editor.org/info/rfc7899>. 915 [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, 916 A., and P. Mattes, "Segment Routing Policy Architecture", 917 RFC 9256, DOI 10.17487/RFC9256, July 2022, 918 <https://www.rfc-editor.org/info/rfc9256>. 920 [RFC9572] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 921 Sajassi, "Updates to EVPN Broadcast, Unknown Unicast, or 922 Multicast (BUM) Procedures", RFC 9572, 923 DOI 10.17487/RFC9572, May 2024, 924 <https://www.rfc-editor.org/info/rfc9572>. 926 [RFC9573] Zhang, Z., Rosen, E., Lin, W., Li, Z., and IJ. Wijnands, 927 "MVPN/EVPN Tunnel Aggregation with Common Labels", 928 RFC 9573, DOI 10.17487/RFC9573, May 2024, 929 <https://www.rfc-editor.org/info/rfc9573>. 931 [RFC9625] Lin, W., Zhang, Z., Drake, J., Rosen, E., Ed., Rabadan, 932 J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast 933 (OISM) Forwarding", RFC 9625, DOI 10.17487/RFC9625, August 934 2024, <https://www.rfc-editor.org/info/rfc9625>. <major> Please review the entire set of RFCs above - at least some of them (e.g., 9572, 9256) should be normative? If they are required to implement the solution in this document, then that makes them normative. If they are providing additional information reference then that should reflect in the text where they are referenced. Some clarity on informative vs normative would help. [RP] I have moved EVPN RFCs 7432 and 9572 to the Normative section. I don't think RFC 9256 is normative for this document; it is normative for the base draft-ietf-pim-sr-p2mp-policy document. The rest are Informative references and should remain in that section. KT> Isn't 6625 required for the MVPN discovery that is normative text in this document? [RP2] Not strictly, but I will move it to normative section since RFC 6514 is also normative. Thanks, Ketan <EoRv15> _______________________________________________ BESS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
