Hi Rishabh, Thanks for sharing this update. I am yet to go over it in detail, but from a quick look it does address a whole bunch of my DISCUSS points and comments.
A few quick observations/comments: - I find the informative reference to draft-ietf-pce-sr-p2mp-policy that we discussed to be missing in Section 2. There is reference to PCEP, BGP, and Netconf. The document would benefit if the PCEP spec was used as an example by reference in this section. While my DISCUSS brought up this being normative reference, the updated text can make things work with an informative reference. - Please check for grammar and spelling errors before submission. If you could do a manual posting of this version (given the submission window being closed), it would help us make progress and I will update my ballot. It would also help address other IESG reviews. Thanks, Ketan On Mon, Oct 27, 2025 at 10:30 PM Rishabh Parekh <[email protected]> wrote: > Ketan, > I am attaching rev 16 along with the diff.I am fine to meet this week if > we need to discuss further. > > Thanks, > Rishabh > > On Sun, Oct 26, 2025 at 11:19 PM Ketan Talaulikar <[email protected]> > wrote: > >> Hi Rishabh, >> >> I am happy to work this out over emails (or other means) with the updated >> draft and diffs as attachments. Please let me know if the authors would >> like to meet this week for further discussions. Next week will be difficult >> with the IETF. >> >> Thanks, >> Ketan >> >> >> On Thu, Oct 23, 2025 at 8:50 PM Rishabh Parekh <[email protected]> >> wrote: >> >>> 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]
