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? > > # 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. > > # 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. > > > ---------------------------------------------------------------------- > 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. > # 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? > > # 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. > # 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, but is't that specific to an implementation, 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, but again, isn't this more about the implementation than the specification in this document? > > ## There is also no discussion on scalability implications, means to > diagnose > and installed state, etc. Pointing to where these are discussion would be > sufficient. > > ## 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. > > ## The tunnel type should be configurable. > > # 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. > > # 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. > > # 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, > > Cheers, > Med > > > > _______________________________________________ > 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]
