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? > > >> 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. > >> 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. > > 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? > > >> 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. > > >> 124 optimization objectives to be satisfied by the P2MP tree. A >> CP has >> 125 zero or more P2MP tree instances (PTI). >> > >> <minor> The term PTI is not used anywhere. Was that an omission? I think >> not, >> but in that case please remove it from this document. >> > > [RP] There are several occurrences of SR P2MP tree instances in the > document. I will replace them with the abbreviation. > > >> >> 133 For BGP MPLS Ethernet VPN specified in [RFC7432] and >> extensions to >> 134 this document, P-Tunnels are advertised for handling multi- >> 135 destination traffic. These P-Tunnels can be instantiated by >> SR-MPLS >> 136 or SRv6 P2MP trees. >> >> <minor> Shouldn't there also be reference to RFC9572 here? >> > > [RP] Added. > > >> >> 146 Replication node. The reader is also expected to be familiar >> with >> 147 [I-D.ietf-pim-sr-p2mp-policy] for teerms like SR P2MP policy, >> >> <nit> s/teerms/terms >> > > [RP] Fixed. > > >> >> 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. > > >> >> 177 nodes of the P2MP tree. Leaf nodes of the P2MP tree deliver >> the >> 178 payload after disposing the Tree-SID. >> >> <minor> Please consider putting a forward reference (to section 3.1 >> perhaps?) >> to indicate how the context of the specific VPN instance is encoded >> besides >> the Tree-SID? >> > > [RP] Ok > >> >> 186 Provider Multicast Service Interface (PMSI). The PTA is >> carried in >> 187 Intra-AS I-PMSI, Inter-AS I-PMSI, Selective PMSI, and Leaf >> Auto- >> 188 Discovery routes. >> >> <minor> The last sentence above is specific to MVPN. Why not move it to >> section 4? >> > > [RP] Done. > > >> >> 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. > > >> >> 255 less than or equal to the Function Length. When Transposition >> scheme >> 256 is not used, the label field MUST be set to zero and >> Transposition >> 257 Length MUST be zero. >> >> <minor> Setting the label field to 0 is coming from RFC6514 to indicate >> that >> there is no label. It would be useful to remind that since RFC9252 >> specifies >> setting the field to implicit null in such cases and readers may wonder >> why >> this is different. >> >> [RP] Ok. > > >> 288 The Egress PEs of a shared SR P2MP P-Tunnel use the SRv6 >> Multicast >> 289 Service SID in SRH to determine the MVPN in which the customer >> >> <nit> s/MVPN/MVPN instance ? > > > [RP] Done. > > >> >> 314 RFC 6514 Section 9.1.1 ( >> https://tools.ietf.org/html/rfc6514#section- >> 315 9.1.1) describes procedures for originating Intra-AS I-PMSI A-D >> >> <nit> URL is not required to be provided this way. This is affecting >> readability >> and is something that is present in multiple places in the text. >> > > [RP] This an eref that renders to direct URLs, but we have seen multiple > comments about this in the past. Will change all to xref with explicit > Section numbers as text. > KT> Thanks. > > >> >> 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. > 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. > > >> 344 When a PE that advertises a SR P2MP P-Tunnel in the PTA of its >> Intra- >> 345 AS I-PMSI A-D route, imports an Intra-AS I-PMSI A-D route from >> some >> 346 PE, it MUST add that PE as a Leaf node to the SR P2MP Policy >> on the >> 347 controller. The Originating IP Address of the Intra-AS i-PMSI >> A-D >> >> <major> Can you please clarify which PE is ingress and which is egress. I >> can >> figure it out, but this very hard to follow. There are other similar >> occurences >> of "PE" and it would help if you could add qualifiers as appropriate. >> > > [RP] Got it. Will try to specify the PE role in this and other sections. > > >> >> 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. > >> 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 ? > > 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. > >> 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. > > >> 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. > >> 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? > > 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. > > >> 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. > > >> 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? > > >> 675 3.4). A NVE encapsulates a tenant packet in an SRv6 header and >> > >> <nit> Expand NVE >> >> > [RP] I can if we decide to keep this text based on the comment about RFC > 8293 above. > > >> 749 This document requests IANA to allocate the following code >> points in >> 750 "SRv6 Endpoint Behaviors" sub-registry of "Segment Routing >> 751 Parameters" top-level registry. >> >> 753 +=======+========+===================+===========+ >> 754 | Value | Hex | Endpoint behavior | Reference | >> 755 +=======+========+===================+===========+ >> 756 | 76 | 0x004C | End.DTMC4 | [This.ID] | >> 757 +-------+--------+-------------------+-----------+ >> 758 | 77 | 0x004D | End.DTMC6 | [This.ID] | >> 759 +-------+--------+-------------------+-----------+ >> 760 | 78 | 0x004E | End.DTMC46 | [This.ID] | >> 761 +-------+--------+-------------------+-----------+ >> >> <major> Those codepoints are already allocated. What is required is to >> update >> the change controller from the individual author's name to the IETF. >> Please >> add the change controller column to the above table. >> > > [RP] Will do. > > >> >> 763 Table 1: IETF - SRv6 Endpoint Behaviors >> >> <nit> s/IETF - SRv6 Endpoint Behaviors/Multicast Service SRv6 Endpoint >> Behaviors ... or something like that >> > > [RP] Done. > > >> >> 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. > > >> 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? 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]
