[bess] Re: Mohamed Boucadair's Discuss on draft-ietf-bess-mvpn-evpn-sr-p2mp-15: (with DISCUSS and COMMENT)

[Rishabh Parekh <[e-mail]>]

Med..
Follow up @ [RP2]

On Tue, Oct 14, 2025 at 11:01 PM <[e-mail]> wrote:

> Hi Rishabh,
>
>
>
> Thanks for the follow-up.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Rishabh Parekh <[e-mail]>
> *Envoyé :* mercredi 15 octobre 2025 07:22
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* The IESG <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *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 <
> [e-mail]> 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
>
>
>
> _______________________________________________
> BESS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> ____________________________________________________________________________________________________________
> 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.
>
>