Gunter, The draft submission cutoff for IETF 124 is in effect now. I will not be able to publish it till the IETF starts.
Rishabh. On Wed, Oct 22, 2025 at 10:52 PM Gunter van de Velde (Nokia) < [email protected]> wrote: > 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]> > 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]> 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]> > 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]> 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]> 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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
