[pim] Re: Ketan Talaulikar's Discuss on draft-ietf-pim-p2m p-policy-ping-19: (with DISCUSS and COMMENT)

Sorry I hit send to early, more comments

-----Original Message-----
From: Hooman Bidgoli (Nokia) 
Sent: Monday, August 25, 2025 6:34 PM
To: 'Ketan Talaulikar' <[email protected]>; The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: RE: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-19: (with DISCUSS and COMMENT)

Hi Ketan

Inline

HB3>

Hooman

-----Original Message-----
From: Ketan Talaulikar via Datatracker <[email protected]> 
Sent: Monday, August 25, 2025 5:11 AM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-19: (with DISCUSS and 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.



Ketan Talaulikar has entered the following ballot position for
draft-ietf-pim-p2mp-policy-ping-19: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for their work on this document.

I have a few points that I would like to discuss with the authors and the WG.

This is an updated ballot for the v19 posted by the authors. Note that the numbering of open points in the DISCUSS position is being retained as in the original ballot for ease of tracking.

discuss#2 This is related to a point of discussion that I've also raised on the p2mp policy document. It arises from the lack of clarity on whether the SR P2MP Policy construct is instantiated on the root node or not. There is text in section 3.1.1 which seems to leave this critical aspect to implementations and will result in interoperability problems. The base spec needs to be very clear on this point and then this document updated to reflect it. I believe having the construct instantiated in the root will greatly benefit and simplify OAM operations. And things would then become very similar to RSVP-TE P2MP trees?

< update for v19 > Note that the base document now clarifies that the P2MP Policy construct is instantiated on the root. This document is not in sync with the base - this point remains open for discussion.

HB3> this is clearly been explain in the Abstract. Please read the Abstract in detail one more time. And I quote " They are used to steer multicast traffic along optimized paths from a Root to a set of Leaf routers."



Quoting some text from section 3.1.1 that is problematic:

"Only the Root node, where the P2MP SR Policy is programmed, may have visibility  into the leaf nodes."

"In the case of P2MP SR Policies, the Root of the tree may have full visibility into the egress nodes if the P2MP SR Policy is PCC-initiated. If the P2MP SR Policy is PCE-initiated, the Root may or may not have visibility into the egress  nodes, as this depends on the specific implementation and configuration of the PCE. "

Further dependencies like the following seem unnecessary:

"Based on this, a P2MP SR Policy SHOULD follow the recommendations in Section
4.3.1 of [RFC6425], depending on the level of visibility the Root has into the  egress nodes. For example, in a PCC-initiated P2MP SR Policy, the Root can learn egress node identities through Next-Generation MVPN procedures and BGP, as described in [RFC6514]. In contrast, for a PCE-initiated P2MP SR Policy, the PCE may not provide the egress node information to the Root, making this process optional and implementation-specific."

The lack of clarity hurts interoperability and would affect operations in a multi-vendor network. I would like to discuss why all of this cannot be simplified by ensuring that the SR P2MP Policy construct is instantiated on the root node.

HB3> these are the different scenarios that can exist which are controller dependent and have been explained in the PCE draft. I think we need to spell them out as there were requests from other ADs to be more specific on these cases. 

discuss#3 My understanding is that the P2MP MPLS trees that are setup by MLDP or RSVP-TE are hop by hop in nature. While in this case, the packet can travel multiple hops from one node to the next intermediate node using that next intermediate node's Prefix SID. In this case, how would operation like traceroute (or even errors in the case of ping) work when the packet is exposed at a node that is doing unicast forwarding and has no replication segment context for that specific P2MP Tree? Now, section 3.1.3 is covering this, but talking about it as "unicast SR domains" is very misleading since there is only an SR domain and it is just that the specific P2MP tree context is not required to be instantiated on a transit node. Does this mean that this mechanism works only when the P2MP Tree is setup up hop-by-hop? If so, this should be clearly called out as a caveat upfront and the text in 3.1.3 updated appropriately.

< update for v19 > This point remains open for discussion.

HB3> sure lets discuss, but my entire point here is, as you said the unicast routers don't understand the replication SID, so the unicast SR-Policy or SR tunnel has to be debugged via its own tools (Ping, TraceRoute) and the SR-P2MP policy has to be debugged wit its own tool. The replication SID SHOULD not be exposed in the unicast domain as the unicast routers don't know what it is.

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

Please also find below some comments provided inline in the idnits format of the v18 of this document. On all editorial and minor comments, I will leave it to the authors discretion. On the major ones, I would appreciate responses and clarifications.

Note: the comments are updated by removing those that were addressed in v19

Please look for <EoRv18> at the end of this review and if it is not there, then likely the email has gotten truncated by your client (please refer to the mailing list in that case).

94      1.  Introduction

96         A P2MP Policy can have one or multiple Candidate Paths (CPs).  The CP

<minor> Please align terminologies with the SR P2MP policy draft. Term is SR P2MP Policy, then there is P2MP Tree (Instance), etc. Would be nice to avoid introducing new terms (e.g., TI) in this document related to any of the constructs.

< update for v19 > Please use the term "SR P2MP Policy" in this document to be consistent with the base document. Thanks for aligning the other terms.

HB3> ok thanks

142     3.  Motivation

144        A P2MP Policy and its corresponding Replication Segments are
145        typically provisioned via a centralized controller or configured
146        using NETCONF/YANG or CLI.  The root and the leaves are discovered in

<minor> Perhaps you mean that the network topology that includes the root and leaves is discovered?

319        *  Address Length: (1 octet) specifying the length of the Root
320           Address in octets (4 octets for IPv4, 16 octets for IPv6).

<major> reserved is missing; also I believe it MBZ

< update for v19 > It should be ... MUST be set to zero by sender and ignored by the receiver (or something like that).

HB3> ok thanks.

<EoRv18>



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