Date: Tue, 18 Aug 2026 15:38:17 +0000
To: Dhruv Dhody <dd@dhruvdhody.com>
From: Mike Koldychev <mkoldych@proton.me>
Message-ID: 
 <WZgoOY_0Vm-80SEsfW0qs7UyAaAJqipGL2baJAVjVEY28OZTg2H38YpcFXAkaK9ZgKP_sVJd3K9KFNHpR347CdLnFiOzPW0tNscCiYKL5ZQ=@proton.me>
In-Reply-To: 
 <178341908550.413483.15283611983977799329@dt-datatracker-57b5d8f849-zrqfx>
References: 
 <178341908550.413483.15283611983977799329@dt-datatracker-57b5d8f849-zrqfx>
Feedback-ID: 98235495:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 5EDDCPP4KVQMETPLYVW2GJ6WKUM7HSVO
CC: andrew.stone@nokia.com, draft-ietf-pce-sr-p2mp-policy@ietf.org,
 pce-chairs@ietf.org, pce@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BPce=5D_Re=3A_WG_Last_Call_for_draft-ietf-pce-sr-p2mp-policy-19_?=
	=?utf-8?q?=28Ends_2026-08-04=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/pce/wRD3W_invIOfJjkNrX3sUrhnoN8>

I have read the latest version and support progression to RFC. Some minor f=
eedback:

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

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

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 ove=
r traffic when there is a series of back-to-back path switches.

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 t=
hink it's a "MUST"? Or are they allowed to be different numbers on differen=
t nodes? Would be simpler if it was forced to be the same number.


Thanks,
Mike.


On Tuesday, July 7th, 2026 at 6:11 AM, Dhruv Dhody via Datatracker <noreply=
@ietf.org> wrote:

> This message starts a WG Last Call for: draft-ietf-pce-sr-p2mp-policy-19
>=20
> This Working Group Last Call ends on 2026-08-04 (intentionally longer to =
accommodate IETF126 and travels)
>=20
> 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.
>=20
> Please indicate your support or concern for this draft on the mailing lis=
t. If you are opposed to the progression of the draft to RFC, please articu=
late your concern. If you support it, please indicate that you have read th=
e latest version and that it is ready for publication in your opinion. As a=
lways, review comments and nits are most welcome.
>=20
> A general reminder to the WG to be more vocal during the last-call/adopti=
on.
>=20
> Thanks,
> Dhruv & Julien
>=20
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-sr-p2mp-policy/
>=20
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-p2mp-policy-19
>=20
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-pce-sr-p2mp-policy=
-19
>=20
> _______________________________________________
> Pce mailing list -- pce@ietf.org
> To unsubscribe send an email to pce-leave@ietf.org
>