Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping
draft-ietf-pim-p2mp-policy-ping-25

Thanks to Wes Hardaker for their secdir review.

I found the referenced security considerations in RFC 8029 to be quite good.  In fact, it discusses rate limiting to avoid DOS attacks.
[Note:  I wasn't going to send this ballot to the list, but it might help w/ one of the discusses]

Thanks for preparing this document, and for adding text to the Security Considerations to address my DISCUSS.

The following set of COMMENTS is mostly non-blocking comments, which the authors should consider as part of improving the readability of the draft.

"Abstract", paragraph 2
>    Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to
>    define and manage explicit P2MP paths within a network.  These
>    policies are typically calculated via a controller-based mechanism
>    and installed via, e.g., a Path Computation Element (PCE).  In other
>    cases these policies can be installed via using NETCONF/YANG or CLI.
>    They are used to steer multicast traffic along optimized paths from a
>    Root to a set of Leaf routers.
> 
>    This document defines extensions to Ping and Traceroute mechanisms
>    for SR-P2MP Policy with MPLS encapsulation to provide OAM
>    (Operations, Administration, and Maintenance) capabilities.  The
>    extensions enable operators to verify connectivity, diagnose failures
>    and troubleshoot forwarding issues within P2MP Policy multicast
>    trees.
> 
>    By introducing new mechanisms for detecting failures and validating
>    path integrity, this document enhances the operational robustness of
>    P2MP multicast deployments.  Additionally, it ensures that existing
>    MPLS and SR-based OAM tools can be effectively applied to networks
>    utilizing P2MP Policies.

I believe the Abstract is too long and can easily be shortened. How about saying:

"Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to define and manage explicit P2MP paths within a network. This document defines extensions to Ping and Traceroute mechanisms for SR-P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) capabilities."

Or something similar. All the justification for why and how it is improves OAM can go into the introduction.

Section 3, paragraph 1
>    A P2MP Policy and its corresponding Replication Segments are
>    typically provisioned via a centralized controller or configured
>    using NETCONF/YANG or CLI.  The root and the leaves are discovered in
>    accordance with [draft-ietf-pim-sr-p2mp-policy] and the multicast
>    tree is computed from the root to the leaves.  However, there is no
>    underlay signaling protocol to distribute the P2MP Policy from the
>    root to the leaf routers.  Consequently, when a P2MP tree fails to
>    deliver user traffic, identifying the failure can be challenging
>    without ping and traceroute mechanisms to isolate faults along the
>    tree.
> 
>    To address this challenge, P2MP Policy ping and traceroute can be
>    utilized to detect and localize faults within the P2MP tree and its
>    associated Replication Segments, as defined in [RFC9524].  These OAM
>    tools enable periodic ping operations to verify connectivity between
>    the root and the leaves.  In cases where a ping fails, a traceroute
>    can be initiated to determine the point of failure along the tree.
>    This diagnostic process can be initiated from the node responsible
>    for establishing the P2MP Policy, ensuring proactive monitoring and
>    rapid fault detection.

I beleive the Motivation section should come before the text in Introduction as it is not clear reading the Introduction why this extension is needed in the first place till you read the Motivation section.

Section 3.1, paragraph 0
>    This document specifically addresses Replication Segments that use
>    MPLS encapsulation.  Future documents will extend support for
>    Replication Segments using SRv6 encapsulation.  Packets are processed
>    based on the standard behavior when their Time-to-Live (TTL) expires
>    or when they reach the egress (leaf) router.  The appropriate
>    response is sent back to the root node following the procedures
>    outlined in [RFC6425].

Are the first two statements a repeat of the statements in the last paragraph of the Introduction?

Section 3.1.1, paragraph 0
>    1.  Egress Address P2MP Responder Sub-TLVs: Multicast LDP, as per
>        section 3.2.1 of [RFC6425], does not allow for the inclusion of
>        Egress Address P2MP Responder Sub-TLVs, as upstream LSRs lack
>        visibility into downstream leaf nodes.  Similarly, P2MP SR
>        Policies often rely on a Path Computation Element (PCE) for
>        programming transit routers, meaning these routers do not have
>        knowledge of the leaf nodes.  Only the Root node, where the P2MP
>        SR Policy is programmed, may have visibility into the leaf nodes.
>        Consequently, these Sub-TLVs SHOULD NOT be used when an echo
>        request carries a P2MP Policy MPLS Candidate Path FEC.  If a node
>        receives these TLVs in an echo request, then it will not respond
>        since it is unaware of whether it lies on the path to the address
>        in the sub-TLV.

There is multiple use of "these" in this paragraph, and it not clear what "these" is referring to. For example, it is better to say "transit routers" than "these routers". Similarly, what does "these Sub-TLVs" " or "these TLVs" refer to?

No reference entries found for these items, which were mentioned in the text:
[RFC7942].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3.1, paragraph 0
>    Ping/Traceroute packets are forwarded on the P2MP Policy, on a
>    specific CP and its TIs toward the designated leaf routers.  These
>    packets are replicated at the replication point based on the
>    Replication Segment forwarding information on the corresponding
>    router.

s/forwarded on the P2MP Policy/forwarded based upon the P2MP Policy/

Section 3.1.1, paragraph 0
>    The procedures in [RFC6425] define fault detection and isolation
>    mechanisms for P2MP MPLS LSPs.  These mechanisms extend the LSP ping
>    techniques described in [RFC8029] such that they may be applied to
>    P2MP MPLS LSPs, ensuring alignment with existing fault management
>    tools.  [RFC6425] emphasizes the reuse of existing LSP ping
>    mechanisms designed for Point-to-Point P2P LSPs, adapting them to
>    P2MP MPLS LSPs to facilitate seamless implementation and network
>    operation.

s/These mechanisms/The mechanisms defined in this document/

Duplicate normative references to: rfc2119.


These URLs in the document can probably be converted to HTTPS:

 * http://www.iana.org/assignments/address-family-numbers

"Table of Contents", paragraph 1
> andidate Paths (CPs). The CP with highest preference is designated as the ac
>                                   ^^^^^^^
A determiner may be missing.

Section 3.1.2, paragraph 1
> eplication Segment is transiting over a Unicast SR domain, it must be only pr
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2.1, paragraph 4
>  of the Root. * Address Length: (1 octets) specifying the length of the Root
>                                  ^^^^^^^^
Please verify that the plural noun "octets" is in agreement with the quantifier
"1". Did you mean to use the singular form?

Understandably, this document is fairly deep in the SR/MPLS stack and assumes a familiarity with many basic terms from that technology. Thank you for referencing sources for much of your terminology in Section 1.1. It would be helpful to spell out some of these initialisms (CP, TI, etc.), particularly as they are used in their expanded form later in the document. I also do not see the term LSP referenced here; perhaps a reference to RFC 3031 Sections 2.2 and 2.3 should be added to this section, possibly with a list of terms which are defined there and used in this document?

Hi Hooman, Zafar, Jeffrey, Anuj, and Dan,

Thank you for the effort put into this document. 

Also, thanks to Linda Dunbar for the OPSDIR. I’m not reiterating any of the points raised by Linda. I trust that agreed changes will be made to the spec to reflect the ongoing discussion.

Having some examples to illustrate the use of the extensions would be helpful.

Please find below some comments; major ones are tagged with (*).  

# Candidate Policy (*)

The following is not consistent with the definition of CP:

OLD: Each P2MP Policy can have multiple Candidate Paths (CPs).   

Please consider updating to

NEW: A P2MP Policy can have one or multiple Candidate Paths (CPs).   

# Inappropriate use of normative language

CURRENT:
   The CP
   with highest preference is designated as the active CP, while all
   other CPs are the backup CPs.  To enable seamless global optimization
   a CP MAY consist of multiple Path Instances (PIs), 

Please s/MAY/may

# Root, Root-ID, rootID (*)

This document uses rootID, which deviates from draft-ietf-pim-sr-p2mp-policy. 

draft-ietf-pim-sr-p2mp-policy says:

   A SR P2MP Policy is uniquely identified by the tuple <Root, Tree-ID>,
   where:

   *  Root: The IP address of the Root node of P2MP trees instantiated
      by the SR P2MP Policy.  This is equivalent to the Headend of SR
      Policy identifier tuple.

+ have one instance of Root-ID

   A shared Replication Segment SHOULD be identified using a Root-ID set
   to zero (0.0.0.0 for IPv4 and :: for IPv6) along with a Replication-

(1) I guess this is an issue to be fixed in draft-ietf-pim-sr-p2mp-policy.

(2) Both specs have to be consistent. Please fix that.

# Deviation vs base P2MP SR Policy Spec 

OLD:
   A PI is identified on the Root node by the rootID
   which is the Root's node IP address, tree ID and PI's instance ID.

NEW:
   A PI is identified on the Root node by the Root-ID
   which is the Root's node IP address, Tree-ID and PI's Instance-ID.

# Deviation, again

CURRENT:
   [draft-ietf-pim-sr-p2mp-policy] section 2, defines terms and concepts
   specific to SR P2MP Policy including the CP and the PI.

There is no PI thing there :-(

# Remind behavior

CURRENT:
       Consequently, these Sub-TLVs SHOULD NOT be used when an echo
       request carries a P2MP Policy MPLS Candidate Path FEC.

Can we remind in the text what happens if these were included?

# Concretely

CURRENT:
   P2MP SR Policies SHOULD adhere to the common procedures specified in
   [RFC6425] for P2MP MPLS LSPs.  

What does “adhere” concretely means?

# Problematic MUSTs

CURRENT:
   The Ping and Traceroute packets MUST be forwarded along
   the specified CP and its PI, traversing the associated Replication
   Segments.  When a downstream node receives a Ping or Traceroute
   packet, it MUST process the request and generate a response even if
   the CP and its PI are not currently the active path.

These two absolute MUSTs may be problematic as there are conditions where this should not be the case. A typical example, is when there is a rate-limit in place to protect a node against overload/DDoS, etc. 

I would adjust these two accordingly. 

# Inappropriate use of normative language

CURRENT:
   For
   example, when a P2MP Policy Ping or Traceroute packet between two
   Replication Segment is transiting over a Unicast SR domain, it MUST
   be only processed on Replication Segments, based on the Replication
   SID and its TTL value.  

This is an example. Please s/MUST/must

# Replication ID TTL (*)

CURRENT:
   The SR domain itself SHOULD be treated as a
   single hop, meaning that the Replication SID TTL MUST be decremented
   by one before pushing the Unicast SR SIDs onto the Replication SID
   stack.  

(1) Under which condition the SHOULD can be ignored?

(2) I failed to find where “Replication SID TTL” is defined. Can you please clarify that? Thanks.

# Address Family (*)

CURRENT:
   *  Address Family: (2 octets) containing a value from ADDRESS FAMILY
      NUMBERS in [IANA-AF] , indicating the address family of the Root
      Address.

(1) Shouldn’t this be restricted to IPv4/IPv6?

(2) There is no “Root Address” field. Root is defined in the base spec as an address. Please update accordingly.






# Please find below some minor comments

## Better title that reflect the content

OLD: P2MP Policy Ping
NEW: Segment Routing Point-to-Multipoint (P2MP) Policy Ping


## Abstract

OLD:
   Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to
   define and manage explicit P2MP paths within a network.  These
                                                ^^^^^^^^ 
   policies are typically calculated via a controller-based mechanism
   and installed via a Path Computation Element (PCE).  In other cases
                 ^^^^^^^^^^^^ 
   these policies can be installed manually via using YANG models or CLI.
                         ^^^^^^^^^^^^^^^^^^    
   They are used to steer multicast traffic along optimized paths from a
   Root to a set of Leaf routers.

   This document defines extensions to Ping and Traceroute mechanisms
   for SR-P2MP Policy with MPLS encapsulation to provide OAM
   (Operations, Administration, and Maintenance) capabilities.  The
   proposed extensions enable operators to verify connectivity, diagnose
   ^^^^^^^^
   failures and troubleshoot forwarding issues within P2MP Policy
   multicast trees.


NEW:
   Segment Routing Point-to-Multipoint (SR-P2MP) Policies are used to
   define and manage explicit P2MP paths within an SR domain.  These
   policies are typically calculated via a controller-based mechanism
   and installed via, e.g., a Path Computation Element (PCE).  In other cases
   these policies can be installed via using NETCONF/YANG or CLI.
   They are used to steer multicast traffic along optimized paths from a
   Root to a set of Leaf routers.

   This document defines extensions to Ping and Traceroute mechanisms
   for SR-P2MP Policy with MPLS encapsulation to provide OAM
   (Operations, Administration, and Maintenance) capabilities.  The
   extensions enable operators to verify connectivity, diagnose
   failures and troubleshoot forwarding issues within P2MP Policy
   multicast trees.

## Introduction

OLD:
   This specification applies exclusively to Replication Segments
   (Replication SIDs) that use MPLS encapsulation for forwarding and
    ^^^^^^^^^^^^^^^^
   does not cover Segment Routing over IPv6 (SRv6).  The mechanisms
   described herein build upon the concepts established in [RFC6425] for
   P2MP MPLS Operations, Administration, and Maintenance (OAM).  All
   consideration and limitations described in section 6 of [RFC6425]
               ^^^^^^
   applies apply to this document as well.
   ^^^^^^

NEW:
   This specification applies exclusively to Replication Segments
   (Replication-SIDs) that use MPLS encapsulation for forwarding and
   does not cover Segment Routing over IPv6 (SRv6).  The mechanisms
   described herein build upon the concepts established in [RFC6425] for
   P2MP MPLS Operations, Administration, and Maintenance (OAM).  All
   considerations and limitations described in section 6 of [RFC6425]
   apply to this document as well.

## Section 3

OLD:
   A P2MP Policy and its corresponding Replication Segments are
   typically provisioned via a centralized controller or configured
   statically using YANG models or CLI. 
   ^^^^^^^^^^^^^^^^^^^^ 

NEW:
   A P2MP Policy and its corresponding Replication Segments are
   typically provisioned via a centralized controller or configured
   using NETCONF/YANG or CLI.  


## Section 3.1

Which mechanisms extend 8029?

CURRENT:
   The procedures in [RFC6425] define fault detection and isolation
   mechanisms for P2MP MPLS LSPs.  These mechanisms extend the LSP ping
   techniques described in [RFC8029] such that they may be applied to
   P2MP MPLS LSPs, ensuring alignment with existing fault management
   tools.  

Cheers,
Med

I support Éric's and Gory's easy to fix DISCUSS items

Thank you to Meral Shirazipour for the GENART review.

Thanks for the work done and for addressing all DISCUSS & COMMENT issues in my previous ballot (see https://mailarchive.ietf.org/arch/msg/pim/atp3SIaldV1j9Vk4fEn0f_6n7yc/ )