Hi Rishabh, Apologies for the delay to follow-up.
-16 fixes all mu DISCUSS/COMMENT points. Many thanks. I will clear my ballot right now. Please find below some nits I tagged when reviewing the latest version: 3.2.1.1.2: The SRv6 Endpoint Behavior of the SRv6 SID Information Sub-TLV encodes one of End.DTMC4, End.DTMC6 or End.DTMC46 Section 3.1 code point values. 3.3.2 : The SRv6 Endpoint Behavior of the SRv6 SID Information Sub-TLV MUST encode one of End.DTMC4, End.DTMC6 or End.DTMC46 Section 3.1 code point value. 4.1.2.1: The split-horizon procedures specified in P2MP MPLS LSPs Section 8.3.1.2 of [RFC7432] are sufficient for SR P2MP P-tunnels. Cheers, Med De : Rishabh Parekh <[email protected]> Envoyé : mercredi 29 octobre 2025 15:58 À : 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, 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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Envoyé : jeudi 16 octobre 2025 02:33 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>> Cc : The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]>> wrote: Hi Rishabh, Thanks for the follow-up. Please see inline. Cheers, Med De : Rishabh Parekh <[email protected]<mailto:[email protected]>> Envoyé : mercredi 15 octobre 2025 07:22 À : BOUCADAIR Mohamed INNOV/NET <[email protected]<mailto:[email protected]>> Cc : The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[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. ____________________________________________________________________________________________________________ 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]
