Just to keep mail thread updated - version 19 was submitted now (it should handle comments from Cheng).
Regards, Samuel From: Mike Koldychev <[email protected]> Date: Monday, 26 January 2026 at 12:51 To: Samuel Sidor (ssidor) <[email protected]> Cc: Koldychev, Mike <[email protected]>, Cheng Li <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Pce] Re: [**EXTERNAL**] draft-ietf-pce-multipath-18 early Rtgdir review I don't have a strong opinion on the Multicast / Protection part. I guess let the community decide on this one. Thanks, Mike. On Friday, January 23rd, 2026 at 3:53 AM, Samuel Sidor \(ssidor\) <[email protected]> wrote: Hi Cheng, Please check if updated version (attached) is handling your comments. For #2 (Section 3.4) The detailed explanation of how P2MP policies are using backup path assignment from this draft is covered in: https://www.ietf.org/archive/id/draft-ietf-pce-sr-p2mp-policy-13.html#name-path-attribute-object. The intent of this document is to provide the generic protocol extension to support backup path assignment. We are explicitly trying to avoid specifying the details of specific use cases here, as those are out of scope. P2MP draft above is explaining that backup path may be assigned separately for each outgoing interface. Mike - for unblocking it for P2P - there was recent discussion on IETF124 and also follow-up mail thread (“Re: Multiple Paths for Protection”), where it was actually explicitly agreed to block it for P2P. Regards, Samuel From: Koldychev, Mike <[email protected]> Date: Thursday, 22 January 2026 at 23:24 To: Cheng Li <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: [**EXTERNAL**] draft-ietf-pce-multipath-18 early Rtgdir review Hi Cheng, Thanks for the feedback! Replies to Questions: 1. The mapping is: ERO == SL PLSP == CANDIDATE_PATH Prior to our draft, there was always just 1 ERO per PLSP, so it was impossible to encode many EROs in a PLSP, and hence impossible to represent many SLs in a CANDIDATE_PATH. Is that clear? 2. I believe we can just relax the P2MP requirement and just let it apply to P2P as well. In P2MP it applies to backups for each of the egress replications. Hooman may comment more? 3. Thanks for noticing valid point. Thanks, Mike. -----Original Message----- From: Cheng Li via Datatracker <[email protected]> Sent: January 22, 2026 4:02 AM To: [email protected] Cc: [email protected]; [email protected] Subject: [**EXTERNAL**] draft-ietf-pce-multipath-18 early Rtgdir review Document: draft-ietf-pce-multipath Title: Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information Reviewer: Cheng Li Review result: Has Nits This document is well-written, and clear. Thanks to the authors. I have some comments and questions below, please check. BTW, it looks like we have 7 authors now, you might need to address this. Questions: 1. Section 2.1 However, each PCEP Label Switched Path (LSP) can contain only a single ERO, which prevents the encoding of multiple Segment Lists within the same SR Candidate Path. [Cheng]I do not understand the logic of this sentence and the previous sentence.one single ERO,presnets the encoding of multiple SL? 2. Section 3.4 This functionality is not part of the SR Policy Architecture [RFC9256], but is something optional that may be implemented for certain specialized use cases. One such use case is the Point-to-Multipoint (P2MP) SR Policy [I-D.draft-ietf-pce-sr-p2mp-policy]. [Cheng]I can understand this TLV is used for backup. But how this is used for multicast? The traffic will be copied N times and forward to each path? 3 Section 3.5 Length (16 bits): 16. [3].Suggest to clarify more, to describe the length. 16 is not clear to me. >From the figure, it is a 12 bytes TLV. Please also clarify the length field in >other TLVs, same problem. Thank you. Nits： 1. Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. Returning a single traffic path does not provide a valid solution. [Cheng] __New__ Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. However, current PCEP extension can only return a single traffic path, which can not meet the requirements. 2. The new Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, where possible, to allow for future re-use outside of SR Policy. [Cheng] __NEW__ The new Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, which allows for future re-use outside of SR Policy. 3. The fraction of flows a specific ERO/RRO carries is derived from the ratio of its weight to the sum of the weights of all other paths. ？ [Cheng]The fraction of flows _that_ a ? 4. B: If set, indicates a pure backup path. [Cheng]what is the definition of 'pure backup path?'
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
