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]
