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

["Hooman Bidgoli (Nokia)" <[e-mail]>]

Hello

Version 21 of the draft was posted based on today’s conversation.

Thanks
Hooman

From: Hooman Bidgoli (Nokia) <[e-mail]>
Sent: Monday, August 25, 2025 8:13 AM
To: Ketan Talaulikar <[e-mail]>; Rishabh Parekh (editor) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-18: (with DISCUSS and COMMENT)

HI Keta

I think we should have one meeting with @Rishabh Parekh (editor)<mailto:[e-mail]> for both (Ping and P2MP Policy) document to conclude.

Thanks
Hooman

From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Monday, August 25, 2025 5:12 AM
To: Hooman Bidgoli (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-18: (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.


Hi Hooman,

Thanks for posting the updated version. I've revised the ballot to remove the points that have been closed.

Please check a few points where this document does not seem to be in sync with the base. If you would like to discuss between the authors of these two documents and post an update, then please do so.

For the open items, we'll discuss over a call (I will schedule it).

Thanks,
Ketan


On Mon, Aug 25, 2025 at 7:22 AM Hooman Bidgoli (Nokia) <[e-mail]<mailto:[e-mail]>> wrote:
Uploaded version 19

Hooman

From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Friday, August 22, 2025 8:01 AM
To: Hooman Bidgoli (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-18: (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<http://nok.it/ext> for additional information.


Hi Hooman,

Thanks for the continued discussion. Please check inline for follow-ups with KT2.

At this point, I think it would be great if you (and your co-authors) could post an update with the changes discussed and agreed so far. This way we can focus on the outstanding points alone. I am asking the same for the base SR P2MP Policy document as well - this way can ensure that both are in sync and consistent.

Note: My responses may be slow next week.


On Fri, Aug 22, 2025 at 4:09 AM Hooman Bidgoli (Nokia) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan

Inline HB2>
Addressing your major concerns

Thank

From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 21, 2025 3:25 AM
To: Hooman Bidgoli (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-18: (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<http://nok.it/ext> for additional information.


Hi Hooman,

Thanks for your quick response. Please check inline below for clarifications.


On Wed, Aug 20, 2025 at 11:23 PM Hooman Bidgoli (Nokia) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ketan

Thanks for your comments

Inline

Thanks
Hooman


-----Original Message-----
From: Ketan Talaulikar via Datatracker <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, August 20, 2025 7:00 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Ketan Talaulikar's Discuss on draft-ietf-pim-p2mp-policy-ping-18: (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<http://nok.it/ext> for additional information.



Ketan Talaulikar has entered the following ballot position for
draft-ietf-pim-p2mp-policy-ping-18: 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.

discuss#1 This one should be easy to fix. Since the document is about MPLS and not SRv6, the correct title for this document would be "Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping" ?

HB> sorry I am not following, as per draft this doc only addresses the MPLS encapsulation and not the SRv6. SRv6 will be in future documents.

KT> Can you change the title of the draft from "Segment Routing Point-to-Multipoint (P2MP) Policy Ping" to "Segment Routing MPLS Point-to-Multipoint (P2MP) Policy Ping" or better still "LSP Ping for Segment Routing Point-to-Multipoint (P2MP) Policy" ?

 HB2> ok done thanks


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?

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.

HB> Thanks but I think this is clearly been explained in the introduction, as per below paragraph. I clearly says P2MP Policy finest object is a TI which is the actual P2MP tunnel setup from the "Root" to a set of leaves.

KT> And I see issues with that approach.


"A P2MP Policy can have one or multiple Candidate Paths (CPs). 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 Tree Instances (TIs), allowing for Make-Before-Break (MBB) procedures between an active TI and a newly established, optimized TI. A TI is the actual P2MP tunnel set up from the Root to a set of Leaves via transit routers. A TI is identified on the Root node by the Root-ID which is the Root's node IP address, treeID and TI's instance ID."

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.

HB> That is not correct, a P2MP MPLS tree for mLDP, P2MP RSVP-TE or treeSID is signalled from the root to the a let of leaves. There is no difference on the datapath between mLDP, P2MP RSVP-TE or treeSID. They all use MPLS switching to forward a multicast stream from the root to a set of leaves.

KT> MLDP and RSVP-TE P2MP are signalled hop-by-hop through the network and as such the state for the P2MP LSP is present in all hops/routers along the path. While the SR P2MP tree is provisioned on specific (intermediate) nodes in the network and, therefore, there can be transit routers which do not have any state for the SR P2MP Tree. Am I correct about this fundamental difference?

HB2> that is not the case, it is exactly like mLDP and RSVP-TE P2MP. If there is a replication segment there needs to be a state. That said like mLDP where 2 mLDP routers can tunnel over unicast RSVP-TE in some segments of the network, treeSID can also tunnel over a unicast tunnel including SR Policy, SR-TE etc… but the replication SID needs to be at the bottom of the stack so when the unicast labels are popped at the destination the downstream replication router can take action based on the replication SID.

KT2> Perhaps it is better if we discuss this over a call? Next week is tough for me, but I'll reach out with some suitable slots.




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.

HB> the replication SID is at the bottom of the stack, so a transit node that is capable of treeSID can push adjacency SID or node SID of another treeSID router that is multi-hop away. As such 2 treeSID capable routers can be connected via a unicast SR domain, i.e. treeSID tunnel over Unicast SR tunnel (tunnel over tunnel). Only the treeSID routers will decrement the treeSID TLL and make appropriate decisions if the TLL has expired. This tunnel in tunnel concept is nothing new to treeSID and it is the concept of segment routing which treeSID is part of.

KT> The concept of "unicast SR domain" as you describe above is misleading. Consider a single SR domain and all routers have SR P2MP capabilities. While the root, intermediate and leaf nodes have state for a specific SR P2MP tree, the other transit routers don't have that specific SR P2MP tree state. There isn't a tunnel per se (it's a stack of labels) that is going multi-hop across these transit routers, but even if one were to call it a tunnel then it is going to break the OAM procedures - or at least they are no longer the same as existing P2MP LSPs. I am OK if this is called out as a caveat of this proposal and operational guidance provided to avoid multi-hop such that all replication branches for every replication segment are just going single hop.

HB2> Sure I can call out this draft does not address the case when a SR P2MP OAM packet is traversing a unicast portion of the SR domain. i.e. if the corresponding unicast labels TTLs value expires while the label stack contains a replication SID is not covered by this draft.

KT2> I have a problem with the characterization of "unicast portion". While this is an improvement over "Unicast SR domain", it does not address my point. Can we take this over a call ?



discuss#4 This is an easy one to fix - the following is not a normative reference, please move to informative.

[IANA-AF]
"IANA Assigned Port Numbers, "http://www.iana.org/assignments/address-family-numbers"".

HB> ok thanks done in version 19.

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

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.

HB> ok thanks, changed to p2mp policy and p2mp tree instance

97         with highest preference is designated as the active CP, while all
98         other CPs are the backup CPs.  To enable seamless global optimization

<minor> The CP preference is only the first tiebreaker in the selection of active CP. Perhaps "One of the CPs (e.g., with highest preference) is designated ..."
HB> this might be implementation specific. In the SR p2mp policy the candidate path with highest preference is the active CP.

KT> This isn't implementation specific. The SR P2MP Policy draft says that it is following RFC9256 (see https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#section-2.3) - is there a disconnect? This is one of my comments on the SR P2MP Policy draft - to provide more clarity.

The Root node selects the active Candidate Path based on the tie breaking rules defined in[RFC9256<https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#RFC9256>].

HB2> I see, I’ll change the text to point to pim-sr-p2mp-policy for CP selection, thanks.

KT2> Sure, or you can consider the text that I had suggested - "One of the CPs (e.g., with highest preference) is designated ..."



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

<minor> I couldn't find TI defined in that document. Please introduce in the base.

HB> it is introduced in the introduction
"To enable seamless global optimization a CP may consist of multiple P2MP Tree Instances (TIs), allowing for Make-Before-Break (MBB) procedures between an active TI and a newly established, optimized TI."

KT> Please introduce architectural constructs in the architectural spec (i.e. the SR P2MP Policy draft) where it can be references by all protocol specs - this LSP Ping is one document, but I would expect it to be used in PCEP as well as perhaps in the YANG model.


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?

HB> no, the controller sucks up the topology but the controller initiates the P2MP policy and its replication segments on the root, transit and leaf nodes.

KT> What is there to be discovered about these nodes by the controller? Aren't they provisioned by the controller? My comment is that the choice of the word "discovered" is odd and unclear. Please clarify.


161        This diagnostic process can be initiated from the node responsible
162        for establishing the P2MP Policy, ensuring proactive monitoring and
163        rapid fault detection.

<minor> Is use of "rapid" appropriate here? Rapid as in BFD?

HB> There are cases and implementations, that rapid pings are send for fault detection.

KT> Let me ask the question if the spec is going to suffer if "rapid" were to be removed. Or can you find a reference to an existing LSP Ping spec that talks about "rapid pings"? Implementations are free to make their own choices but we need to get consensus from MPLS WG if this document is introducing the concept of "rapid pings".

HB2> I don’t understand this comment sorry. Rapid is implementation, if you send one ping or one ping a second or 1000 ping a second that is up to your implementation.
HB2> that said knowing this implementation I have no issue removing the word “rapid”

KT2> If you can remove the word rapid, then we please consider this point closed. If you would like to discuss further, we can take this up as well over a call?



295     3.2.1.1.  P2MP Policy CP FEC Stack Sub-TLVs

297        The P2MP Policy MPLS Candidate Path sub-TLV value field follows the

<major> Please consider changing the name of this TLV since it is not about CP but about the P2MP Tree instance under a CP. Perhaps "SR P2MP Policy Tree FEC Stack sub-TLV" ... or something similar. I was trying to not make it too long by including the CP in there, but that would also be ok.

HB> It is actually detecting fault on a CP. A CP can have single TI or multiple TI. Hence why we choose the CP as part of the name.

KT> But as you say above, it is monitoring the TI under the CP and more importantly the FEC specifies a unique TI and not the CP. i.e. if the CP has multiple TI then each TI needs a separate LSP Ping session with its unique FEC.

HB2> This is early allocation in IANA changing the name might be difficult. That said my next response might satisfy your concern.

KT2> There is no issue with changing the TLV names until the final allocation and RFC publication.




298        format specified in Section 2 of [draft-ietf-pim-sr-p2mp-policy].
299        The structure of this sub-TLV is illustrated in the figure below.

<major> Please add text to clarify here that the CP identifiers are not required since the Instance-ID is unique within the SR P2MP Policy context (with a reference to section 2.3 of the p2mp policy draft).

HB> There is no CP identifier in any text or document. Adding this would create more confusion and have the reader searching for what is a CP identifier.

KT> This looks like a disconnect. Refer https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#section-2.3 .. and this is why I've provided comments on the SR P2MP policy document to clarify some of those things inline.

An SR P2MP Policy has one or more CPs. Identification of a CP in context of the P2MP Policy is as specified in Section 2.9 of [RFC9256<https://www.ietf.org/archive/id/draft-ietf-pim-sr-p2mp-policy-18.html#RFC9256>]

HB2> I can add a text to say that this sub-TLV is testing a P2MP Tree Instance as such it is not necessary to identify the candidate path.
HB2> hopefully this will solve your concern with regards to the sub-tlv name as well.

KT2> Yes, that text would help. Do still consider the change of sub-TLV name though - IANA doesn't have an issue with that - so the question is for the authors/WG really.

Thanks,
Ketan



315        *  Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS as
316           specified in [IANA-AF] , indicating the address family of the
317           Root.

<major> Are all AFIs allowed? I believe it has to allow only IPv4 or IPv6?

HB> as per text "Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS as specified in"

KT> Could you be more specific and disallow AFI values other than 1 and 2 in the text?

HB2> ok done thanks.

Thanks,
Ketan


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
HB> good point thanks!

382     5.  IANA Consideration

384        IANA has assigned a TEMPORARY code point for the "P2MP Policy MPLS
385        Candidate Path" Sub-TLV Name.  This Sub-TLV is assigned from TLV type
386        1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS)
387        Label Switched Paths (LSPs) Ping Parameters" registry group.  The
388        Sub-TLVs for TLV type 1 are listen under "Sub-TLVs for TLV Types 1,

<minor> s/listen/listed

HB> thanks! Updated.

397     6.  Security Considerations

399        Overall, the security needs for P2MP policy ping are the same as
400        [RFC8029].  The P2MP policy ping is susceptible to the same three
401        attack vectors as explained in RFC8029 section 5.  The same
402        procedures and recommendations explained in [RFC8029] section 5
403        should be taken and implemented to mitigate these attack vectors for
404        P2MP policy Ping as well.

<major> Should this not include reference to the security considerations of the SR P2MP policy draft as well?

HB> ok thanks added a text

<EoRv18>