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. 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. > 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? > > 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. 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? > 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. > 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. > > 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? > > 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. > > 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? 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. > 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. > > 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.. 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. > > 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. > 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? > 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. > > 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." 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. > 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. > 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. > 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. > > <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]
