Med, The new revision 16 of the draft addresses your final point. Please take a look and confirm.
Thanks, Rishabh. On Thu, Oct 16, 2025 at 10:20 AM Rishabh Parekh <[email protected]> wrote: > Med, > I will add some text about scalability etc for SR P2MP trees. > > Thanks, > Rishabh. > > On Thu, Oct 16, 2025 at 3:38 AM <[email protected]> wrote: > >> Hi Rishabh, >> >> Your proposed resolutions address all points, except this one: >> >> [RP2] Can you elaborate on what you mean by "scalability implications, >> means to diagnose installed state". Is this about MVPN and EVPN procedures >> with SR P2MP trees, or about SR P2MP trees and the Replication segments >> that are used to construct these trees? >> >> This is about the second one. Thank you. >> >> Cheers, >> >> Med >> >> *De :* Rishabh Parekh <[email protected]> >> *Envoyé :* jeudi 16 octobre 2025 02:33 >> *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> >> *Cc :* The IESG <[email protected]>; >> [email protected]; [email protected]; >> [email protected]; [email protected] >> *Objet :* Re: [bess] Mohamed Boucadair's Discuss on >> draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT) >> >> >> >> >> >> Med.. >> >> Follow up @ [RP2] >> >> >> >> On Tue, Oct 14, 2025 at 11:01 PM <[email protected]> wrote: >> >> Hi Rishabh, >> >> >> >> Thanks for the follow-up. >> >> >> >> Please see inline. >> >> >> >> Cheers, >> >> Med >> >> >> >> *De :* Rishabh Parekh <[email protected]> >> *Envoyé :* mercredi 15 octobre 2025 07:22 >> *À :* BOUCADAIR Mohamed INNOV/NET <[email protected]> >> *Cc :* The IESG <[email protected]>; >> [email protected]; [email protected]; >> [email protected]; [email protected] >> *Objet :* Re: [bess] Mohamed Boucadair's Discuss on >> draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT) >> >> >> >> >> >> Med, >> >> Thanks for the review. Responses inline @ [RP] >> >> >> >> -Rishabh >> >> >> >> On Mon, Oct 13, 2025 at 4:27 AM Mohamed Boucadair via Datatracker < >> [email protected]> wrote: >> >> Mohamed Boucadair has entered the following ballot position for >> draft-ietf-bess-mvpn-evpn-sr-p2mp-15: Discuss >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Hi Rishabh, Daniel, Clarence, Hooman, and Jeffrey, >> >> Thank you for the effort put into this specification. >> >> Please find some points for discussion: >> >> # Updates RFC 6514 >> >> CURRENT: >> For SR P2MP P-Tunnels, these procedures remain unchanged >> except as described in the following paragraphs. >> >> … >> Procedure for receiving Intra-AS I-PMSI A-D routes, as described in >> RFC 6514 Section 9.1.2 (https://tools.ietf.org/html/rfc6514#section- >> 9.1.2), remain unchanged for SR P2MP P-Tunnels except as described in >> the following paragraphs. >> >> .. >> >> RFC 6514 Section 12.1 (https://tools.ietf.org/html/rfc6514#section- >> 12.1) describes procedures for originating S-PMSI A-D routes. For SR >> P2MP P-Tunnels, these procedures remain unchanged except as described >> in the following paragraphs. >> >> .. >> Etc. >> >> The spec seems to update many parts of RFC6514. >> >> # Updates RFC 7988 >> >> CURRENT: >> The PTA carried in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, >> Selective PMSI A-D and Leaf A-D routes is constructed as specified in >> RFC 7988 with modifications as below: >> >> ..but this is not reflected as an explicit update header. >> >> >> >> [RP] Is the discuss about updating RFC 6514 and 7988 using the update >> header? >> >> *[Med] Yes* >> >> >> >> [RP2] Added the updates attribute. >> >> >> # RFC 7899 is normative >> >> CURRENT: >> PEs MAY also implement procedures for damping other >> Auto-Discovery and BGP C-multicast Source Tree Join and Shared Tree >> Join routes as described in [RFC7899]. >> >> 7899 is required to address this key operational issue. >> >> >> >> [RP] This section might be removed based on a separate discussion with >> Ketan, but if it is not, I will make this normative. >> >> *[Med] ACK.* >> >> >> >> >> # RFC 8293 is normative >> >> CURRENT: >> SRv6 P2MP trees MAY be used as an underlay multicast mechanism, as >> described in RFC 8293 Section 3.4 (https://tools.ietf.org/html/ >> rfc8293#section-3.4). In this case, a Network Virtualization Edge >> (NVE) MUST encapsulate tenant packets in an SRv6 header and deliver >> them over SRv6 P2MP trees to other NVEs. >> >> ## RFC 8293 is normative. Please note that when added, this will create a >> downref. >> >> ## Why this is discussed at the first place? >> >> >> >> [RP] The inclusion of text related to RFC 8293 is also under discussion >> with Ketan precisely for the same point: is it required to be in this >> document because RFC 8293 does not mention SRv6 at all. So, this text might >> also be removed. >> >> *[Med] ACK.* >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> # I’m not sure the first sentence of the abstract adds much. >> >> # Better flow >> >> OLD: >> P-Tunnels can be instantiated via different >> technologies. A service provider network that uses >> >> NEW: >> P-Tunnels can be instantiated via different >> technologies. For example, a service provider network that uses >> >> [RP] Changed. >> >> *[Med] Thanks.* >> >> >> >> >> >> # Precision >> >> CURRENT: >> In a Segment Routing network, a P2MP tree allows efficient delivery >> of traffic from a Root to set of Leaf nodes. >> >> It is an optimization if that traffic has to be sent to all these nodes. >> I’m >> not sure this sentence is t currently stands is accurate or adds much to >> the >> discussion. >> >> >> >> [RP] Are you saying the "efficient delivery" does not add much or the >> whole sentence? >> >> *[Med] I think the full sentence can be removed. We don’t need to justify >> the use of P2MP schemes.* >> >> >> >> [RP2] Done. >> >> >> >> >> >> >> # Tree or Tree instance >> >> I guess >> >> OLD: >> An SR P2MP tree is defined by a Candidate path of an SR P2MP >> policy [I-D.ietf-pim-sr-p2mp-policy]. >> >> Should be >> >> NEW: >> An SR P2MP tree instance is defined by a Candidate path of an SR P2MP >> policy [I-D.ietf-pim-sr-p2mp-policy]. >> >> [RP] Done. >> >> *[Med] ACK* >> >> >> >> >> >> # The document does not discuss operational (including manageability) >> considerations >> >> ## For example, consider: >> >> CURRENT: >> The PTA identifies the P-Tunnel that is used to instantiate a >> Provider Multicast Service Interface (PMSI). >> >> Can we clarify in the text the intended behavior for making use of the >> attributes, especially: >> >> ### Should the use of the PTA with SR-triggered tunnel be conditioned by >> explicit activation or should be by default used when at least of the >> >> >> >> [RP] Usually, the MVPN Auto-discovery routes that use the PTA, are >> triggered by some provisioning, >> >> *[Med] ..which belongs to the spec, and hence my comment :-)* >> >> >> >> but is't that specific to an implementation, >> >> *[Med] what is implementation-specific is how the provisioning is done.* >> >> >> >> >> >> [RP2] Ok. I will add some text about provisioning. >> >> >> >> or at least not directly related to this document? RFC 6514 that defines >> many of the P-tunnel types does not explicitly have text about >> configuration. >> >> >> ### Should a node advertise an SR tunnel type independent of whether the >> underlying SR data plane function is supported/enabled? >> >> >> >> [RP] I suppose not, >> >> *[Med] ACK. Can we please record that in the text?* >> >> >> >> but again, isn't this more about the implementation than the >> specification in this document? >> >> *[Med] This is about providing key operational considerations for the >> proposed extension.* >> >> >> >> [RP2] Will add this text along with provisioning. >> >> >> >> >> ## There is also no discussion on scalability implications, means to >> diagnose >> and installed state, etc. Pointing to where these are discussion would be >> sufficient. >> >> *[Med] What about this one?* >> >> >> >> [RP2] Can you elaborate on what you mean by "scalability implications, >> means to diagnose installed state". Is this about MVPN and EVPN procedures >> with SR P2MP trees, or about SR P2MP trees and the Replication segments >> that are used to construct these trees? >> >> >> >> >> ## Let's consider this one: >> >> CURRENT: >> A P2MP tree PTA is constructed as specified below: >> >> * Tunnel Type: From the "P-Multicast Service Interface Tunnel (PMSI >> Tunnel) Tunnel Types" registry >> >> - 0x0C for SR-MPLS P2MP Tree >> >> - TBD for SRv6 P2MP Tree >> >> ## The introductory sentence should scope it the use defined in this >> document. >> Reading separately this text can be interpreted as if these are the only >> allowed values, which is not the intent here. >> >> >> >> [RP] I have changed the text to clarify these code points are added to >> the registry in this document. >> >> *[Med] Thanks* >> >> >> ## The tunnel type should be configurable. >> >> >> >> *[Med] What about this one?* >> >> [RP] Added text about this with provisioning. >> >> >> # Without an SLA >> >> CURRENT: >> Procedures of [RFC7988] are sufficient to create a SR-MPLS Ingress >> Replication for MVPN service without a SLA. >> >> I don’t parse this sentence, especially the last part. >> >> >> >> [RP] It means that the unicast MPLS "tunnel" between the ingress PE and a >> particular egress PE for an ingress replication is usually the IGP shortest >> path (algorithm 0) between the two. The enhanced IR procedures with color >> extended community in this document allows the path between the ingress and >> egress PEs to satisfy an SLA. >> >> *[Med] Thanks for clarifying. Please reword as I don’t get what is >> “without a SLA”.* >> >> >> >> [RP] Will do. >> >> >> >> >> >> >> # IMET >> >> OLD: >> BGP MPLS Ethernet VPN specified in [RFC7432] specifies Inclusive >> Multicast Ethernet Tag route to support Broadcast, Unknown Unicast >> and Multicast (BUM) traffic. >> >> NEW: >> BGP MPLS Ethernet VPN specified in [RFC7432] specifies Inclusive >> Multicast Ethernet Tag (IMET) route to support Broadcast, Unknown >> Unicast >> and Multicast (BUM) traffic. >> >> >> >> [RP] Fixed. >> >> *[Med] ACK.* >> >> >> >> >> # Ambiguity >> >> CURRENT: >> That document defines new BGP route types that MUST be >> advertised with a PMSI Tunnel Attribute (PTA), including the >> Selective PMSI (S-PMSI) Auto-Discovery route. >> >> Which doc? Why normative language is used here? >> >> >> >> [RP] Reworded the text to make it clear RFC 9572 defines new route types >> advertised with PTA and remove the normative MUST, >> >> *[Med] Thank you.* >> >> >> >> >> Cheers, >> Med >> >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
