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]
