[pim] Re: Mohamed Boucadair's No Objection on draft-ietf-p im-p2mp-policy-ping-15: (with COMMENT)

Hi Mohamed

Thanks for taking time reading the document and your comments, some good catches!

Inline

Thanks
Hooman

-----Original Message-----
From: Mohamed Boucadair via Datatracker <[email protected]> 
Sent: Wednesday, August 6, 2025 6:48 AM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Mohamed Boucadair's No Objection on draft-ietf-pim-p2mp-policy-ping-15: (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.



Mohamed Boucadair has entered the following ballot position for
draft-ietf-pim-p2mp-policy-ping-15: 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:
----------------------------------------------------------------------

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

HB> thanks done.

# 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

HB> thanks done

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

HB> changed to Root-ID

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

HB> ok done thanks

# 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 :-(

HB> good point! tree Instance and path instance are the same. Talking to other co-authors we change all drafts to tree instance (TI)! Thanks again!

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

HB> ok added a sentence 

# Concretely

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

What does "adhere" concretely means?

HB> changed to "follow"

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

HB> ok remassaged

# 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

HB> done

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


HB> Replication SID is a label so the TTL is the label TTL

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

HB> ok updated. 

# Please find below some minor comments

HB> ok thanks considered some of your suggestions including title for version 16


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



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