Hi Rishabh, Thanks for the update. I shall try to update this week but, this being IETF week, it is possible that I will get to this only next week.
Thanks, Ketan On Sat, Nov 1, 2025 at 1:31 PM Rishabh Parekh <[email protected]> wrote: > Ketan, > Have you got a chance to review the new version? > > Thanks, > Rishabh > > On Tue, Oct 28, 2025 at 8:05 AM Rishabh Parekh <[email protected]> wrote: > >> 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]
