Subject: [Pce] Re: WG Last Call for draft-ietf-pce-sr-p2mp-policy-19 (Ends 2026-08-04)
From: "Hooman Bidgoli (Nokia)" <[email-masked]>
To: Mike Koldychev <[email-masked]>, Dhruv Dhody <[email-masked]>
Cc: "Andrew Stone (Nokia)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 3 Sep 2026 03:00:18 +0000
List-Id: Path Computation Element <pce.ietf.org>

Hi Mike

Appreciate you taking time and reviewing this document! We addressed some of your comments and will publish it in the next version.

Inline

Regards
Hooman

-----Original Message-----
From: Mike Koldychev <[email-masked]> 
Sent: Tuesday, August 18, 2026 11:38 AM
To: Dhruv Dhody <[email-masked]>
Cc: Andrew Stone (Nokia) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-sr-p2mp-policy-19 (Ends 2026-08-04)

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.

I have read the latest version and support progression to RFC. Some minor feedback:

Section 4.1:
 * What is "global optimization"? If same as MBB, then why need 2 terms?

HB> I tried to clean up the explanation and that entire bullet point is cleaned up.

Section 4.2:
 * Clearly separate key vs non-key data.

HB> not sure if I fully follow this, in PCEP there is no key the objects are with PLSP ID which this section is not talking about. Could you please be more specific what you think we should do here.

Maximum number of PTIs:
 * I'm not sure it's a good idea to restrict the number of PTIs to maximum of 2. For example in my experience with RSVP-TE, there is a need to have 3 LSPs: cleanup, active and reopt. The cleanup serves to "drain" any left over traffic when there is a series of back-to-back path switches.

HB> we made it 1 or more. 

Section 4.2.1:
 "each PTI within a CP of an SR P2MP Policy should use the same Instance-ID across the tree on its Root, Transit, and Leaf nodes when programming its replication segments on the PCC."  <-- is this really a "should"? I would think it's a "MUST"? Or are they allowed to be different numbers on different nodes? Would be simpler if it was forced to be the same number.

HB> we talked it over and kept it as a SHOULD but add explanation why we recommend the instance ID to be constant over the tree's path.

Thanks,
Mike.

On Tuesday, July 7th, 2026 at 6:11 AM, Dhruv Dhody via Datatracker <[email-masked]> wrote:

> This message starts a WG Last Call for: draft-ietf-pce-sr-p2mp-policy-19
>
> This Working Group Last Call ends on 2026-08-04 (intentionally longer to accommodate IETF126 and travels)
>
> Abstract:
>    Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of
>    policies that enable architecture for P2MP service delivery.  This
>    document specifies extensions to the Path Computation Element
>    Communication Protocol (PCEP) that allow a stateful PCE to compute
>    and initiate P2MP paths for SR-MPLS from a Root to a set of Leaf
>    nodes.
>
> Please indicate your support or concern for this draft on the mailing list. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and that it is ready for publication in your opinion. As always, review comments and nits are most welcome.
>
> A general reminder to the WG to be more vocal during the last-call/adoption.
>
> Thanks,
> Dhruv & Julien
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-sr-p2mp-policy/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-p2mp-policy-19
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sr-p2mp-policy-19
>
> _______________________________________________
> Pce mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]
>