[Pce] Re: WG Last Call for draft-ietf-pce-sr-p2mp-policy-19 (Ends 2026-08-04)

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

Hi Samuel

Much appreciated your detail review! We addressed most of your comments and will upload in the next version. Next version should be available sometime next week.

Inline

Regards
Hooman

From: Samuel Sidor (ssidor) <[e-mail]>
Sent: Tuesday, August 25, 2026 7:08 AM
To: [e-mail]
Cc: Andrew Stone (Nokia) <[e-mail]>; [e-mail]; Dhruv Dhody <[e-mail]>; [e-mail]
Subject: Re: [Pce] Re: 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.


Hi authors of draft-ietf-pce-sr-p2mp-policy,

Sorry for delayed response, I support WGLC of this document, but it would be good to fix a few things (ignore if any of them was reported already by other reviewers) in the draft:


  1.  Instance ID assignment
It seems to be a bit unclear about who is assigning instance ID. E.g. section 4.2.1 is saying “Instance-ID: serves as the PTI identifier and is assigned by the PCE” (same seems to be indicated in multiple sections), but 4.3.2.2 is saying “Instance-ID: value MUST be set to zero. The PCC generates the PTI's Instance-ID of the CP.”. I assume that it is just typo.

HB> thanks you fixed section 4.3.2.2


  1.  Instance ID length
The diagrams showing SR-P2MP-INSTACE-ID-TLV in section 5.6.1 are using Instance-ID with 16 bits length, but text is saying: “Instance-ID : Identifier of PTI, Contains 32 Bit instance ID”. Note that also appendix is showing instance-ID with 32bits.

HB> changed to 16 bit


  1.  SR-P2MP-POLICY-CAPABILITY TLV Reserved field handling
Add statement clarifying how “Reserved” space is supposed to be handled, e.g. “Reserved: 16 bits, MUST be set to 0 on transmission and ignored on receipt”. Also TLV type is marked as TBD, but IANA section was already updated with allocated type for that TLV, so “Type=TBD” can be updated as well (same applies to multiple diagrams).

HB> changed thanks


  1.  Strange “SR P2MP incompatible leaf types” error
In section 5.1, there is last paragraph talking about PCEP peer checking whether leaf-types are acceptable, but capability TLV does not have any information about supported leaf types. It contains only number of supported instances and replications. If it is still applicable and not just some outdated text, it would be good to add details.

HB> removed you are right.


  1.  Not matching error type
In section 4.3.1, the text is saying “The PCInitiate message sent to the root MUST set the Tree-ID to 0. If not the PCC must send a PCEP Error message (PCErr) with Error-Type = X2 (SR P2MP Policy General Error) and Error value = 1 (PCInit Invalid Root-ID).” So error is indicating that Root-ID was incorrect, but in reality Tree-ID was incorrectly. Wouldn’t it be better to have dedicated error value for that? It seems to be a bit misleading.

HB> thanks good catch


  1.  Missing association object error
When association object is missing, then error “Error-Type = X2 (SR P2MP Policy General Error) and Error value = 4 (Invalid Instance-ID)” is used. Is that really intentional? It seems to be re-used for unrelated purpose.

HB> ok thanks cleaned the errors now create a new error for missing association object


  1.  Node role TLV which was not defined
In Appendix ("SR P2MP Policy Candidate Path Init” part), there is TLV with “Type=Node Role” used, but I don’t see any such TLV defined anywhere. Was this really replaced by “role” field from CCI object? Note there is also another instance, but with TLV type specified as TBD:
|           Type=TBD            |           Length=4            |
|Role = ingress |                 Reserved                      |

HB> ok thanks



  1.    Referenced PCE CC capability Sub TLV which is not used
In section 4.1, description of RFC9050 is talking about "A new PCE CC Capability sub Tlv is introduced to indicated the support to handle PCE CC based label download for SR P2MP.”, but how that is relevant to this draft? I don’t see that new sub TLV used anywhere.

HB> you are correct removed.


  1.  Terminology for node role
Section 5.7.2 introduced enumeration with role types, where type 1 is “Head”, but even text of that section is calling it already also “ingress”, which is then repeated in Appendix as “Role = ingress”. Also then text of the document is something referring to same node as a “Root”. It would be good to make it consistent.

HB> thanks we changed it to ingress


  1.  PCC with local optimization support only
Section 4.3.5 is describing that PCE can detect that PCC is not capable of global optimization and it is indirectly referring to field "Number of Instances" from "SR-P2MP-POLICY-CAPABILITY” TLV. It would be good to have some normative text explaining that if “Number of Instances” is 1, then PCE MUST not use global optimization and also what PCC is supposed to do if it advertised that it does not support multiple instances, but it still received second instance as well. Also there is no text saying what PCE is supposed to set to that value SR-P2MP-POLICY-CAPABILITY TLV (e.g. MUST be set to 0 by PCE and ignored by PCC).  Also please define scope of “Number of instances” (per CP, per tree,…).

HB> great catch added the following to section 4.3.4
When a PCC Open Message indicates support for only one instance of PTI, then the PCE MUST NOT include the PCC as part of global optimization procedures.



  1.  Error handling for MUST statements
There are multiple MUST statements, e.g. section 5.5.1.1, which is saying that "Extended Association ID TLV" MUST be included, but there is no behavior defined for what MUST happen if it was not included.

HB> thanks added a new error  Missing Extended Association ID


  1.  Outdated reference to section 8.1
In section 4.4.1, there is a statement “described further in section 5.5.2 and with an example in section 8.1”, but section 8.1 is implementation section pointing to Cisco implementation, so I assume that is outdated.

HB> changed to Appendix A thanks!


  1.  N flag in LSP object
Examples in appendix are using LSP object flags “A:1,D:1,N:1”, where N flag was introduced in RFC8623 (which is not mentioned anywhere in references), that RFC introduced multiple MUST requirements if that flag is set, e.g. “The S2LS object MUST be carried in a PCRpt message along with the END‑POINTS object when an N (P2MP) flag is set” or "If the N bit is set … but the P2MP‑LSP‑IDENTIFIER TLV is absent, the PCE MUST respond with … error‑value 14 … and close the PCEP session.”. Is that flag supposed to be used? Is that clarified anywhere in this draft (besides examples)?

HB> removed the N flags.


  1.  A lot of typos in the document, e.g.

  *   Section-title typos: "SR-P2MP-INSTACE-ID-TLV" (many times), "Replicatoin Segment Instantiation", "local optimizatoin", "PCEP Prodecures", "Operatoin Consideration".
  *   "Multipath weight TLV … SHOULD be ignored when revived" → "received".
  *   "trigger a local optimization … and triger" → "trigger".
  *   Incomplete sentence in "Operatoin Consideration": "Otherwise the PCE control needs to be able to The operation consideration of P2MP policy…"
  *   “artwork” word in section 4.4.3
  *   Some typos in authors metadata, e.g. initials for Daniel is “V.”, but should be “D.”, full name for Rishabh is fullname=“Rishabh" only
  *   Terminology inconsistent: "P2MP END POINT OBJECT" vs "P2MP-END-POINTS Object"; "Head" vs "Root" vs "ingress"; "LSP-ID" vs "Instance-ID"
  *   ...

HB> thanks going through the doc to address some of these.

Thanks a lot,
Samuel

From: Dhruv Dhody <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 9 August 2026 at 19:05
To: [e-mail]<mailto:[e-mail]> <[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]> <[e-mail]<mailto:[e-mail]>>
Subject: [Pce] Re: WG Last Call for draft-ietf-pce-sr-p2mp-policy-19 (Ends 2026-08-04)
Hi WG,

To accommodate the Aug break, we are extending the WGLC till 24th Aug. Please use this opportunity to be explicit during WGLC if you wish this I-D to be published as an RFC!

Thanks!
Dhruv

On Tue, Jul 7, 2026 at 3:41 PM Dhruv Dhody via Datatracker <[e-mail]<mailto:[e-mail]>> 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