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

[[e-mail]]

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]<mailto:[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


# 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.


# 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.

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.

## 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?


## 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?

# 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”.


# 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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[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.