Ketan, I will add the informative reference to the PCEP draft and initiate manual submission after proofreading.
Thanks, Rishabh On Tue, Oct 28, 2025 at 12:00 AM Ketan Talaulikar <[email protected]> wrote: > 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]
