[pim] Re: Mahesh Jethanandani's No Objection on draft-ietf -pim-p2mp-policy-ping-16: (with COMMENT)

HI Mahesh

Thanks for your comments inline

Thanks
Hooman


-----Original Message-----
From: Mahesh Jethanandani via Datatracker <[email protected]>
Sent: Monday, August 18, 2025 12:36 AM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Mahesh Jethanandani's No Objection on draft-ietf-pim-p2mp-policy-ping-16: (with COMMENT)


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



Mahesh Jethanandani has entered the following ballot position for
draft-ietf-pim-p2mp-policy-ping-16: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-p2mp-policy-ping/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

HB> Hi Mahesh thanks for the comment, to be honest we been through couple of iteration of this abstract, and if you don't mind I am reluctant to fine tune it again.

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.

HB> In the introduction we are just pointing out that this draft is specifically for fault detection of P2MP policy and its Tis.
HB> in the motivation we are just pointing out that the fact that P2MP SR policy is a PCE based protocol. The OAM extensions has nothing to do with this fact, the extensions are really needed as per introduction, because a P2MP policy has candidate paths and Tis.

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?

HB> thanks! Good point. Revised.

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?

HB> ok thanks made some modification.

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

HB> thanks! But RFC7942 is in Implementation status which will be removed at the publication of the document.
-------------------------------------------------------------------------------
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/

HB> ok thanks updated.

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/

HB> ok modified.

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

HB> thanks modified
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?

HB> thanks! Modified.

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]