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]
