[Pce] Re: draft-ietf-pce-multipath-25 ietf last call Secdir review

["Andrew Stone (Nokia)" <[e-mail]>]

Hi Samuel,

Proposed text looks good to me - thanks!

Andrew

From: Samuel Sidor (ssidor) <[e-mail]>
Date: Wednesday, June 3, 2026 at 6:16 AM
To: Andrew Stone (Nokia) <[e-mail]>; David Mandelberg <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: draft-ietf-pce-multipath-25 ietf last call Secdir review


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.



Thanks David for comments and Andrew for responding.

I agree with Andrew that this is already covered by RFC9256, but I can potentially add some informative statement to indicate that segment-list with weight 0 is considered invalid, e.g.

If the Weight value is 0, the corresponding Segment List is declared invalid per Section 5.1 of {{!RFC9256}} and carries no traffic. If all paths within an LSP have Weight 0, the sum of weights is zero, making the candidate path invalid per Section 2.11 of {{!RFC9256}}. Signaling a zero-weight path alongside paths with non-zero weights can be used to drain traffic from a path while retaining its forwarding instructions.

Andrew - I assume that would still be compatible with draft-stone-spring-mpte-sr (last statement is specifically trying to cover that).

Thanks,
Samuel

From: Andrew Stone (Nokia) <[e-mail]>
Date: Tuesday, 2 June 2026 at 18:45
To: David Mandelberg <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: draft-ietf-pce-multipath-25 ietf last call Secdir review

Apologies, [3] should have been a link not to GitHub but the posted draft. Didn’t notice it in the browser history auto complete 😊

[3] https://datatracker.ietf.org/doc/html/draft-stone-spring-mpte-sr-01#name-load-balancing

From: Andrew Stone (Nokia) <[e-mail]>
Date: Tuesday, June 2, 2026 at 12:32 PM
To: David Mandelberg <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: draft-ietf-pce-multipath-25 ietf last call Secdir review

Hi David, authors,

As a non-author, wg participant:

 The weight TLV is geared towards SR Policy, and since this draft has scoped towards SR Policy and not necessarily PCEP generic, I don’t think weight zero should or needs to be blocked as it’s not prohibited by RFC9256 and indirectly indicates it can be set [1].  Certainly, worth a remark on it though that divide by zero is a risk.

RFC 9256 formula for weight does not prohibit a zero value but if all/only weights are zero [2] then that divide by zero risk is there. In addition, section 5.1 [1] indicates an example of the SID List going invalid if it has a weight of zero. In other words, you can configure it / signal it, but the SID list goes invalid and should not forward (no different than if the label is an incorrect value). The top- level candidate path is only invalid once it has no valid segment list(s).

The reason I’m mentioning this as there could be some value in signalling a zero-weight SID list, to keep the forwarding instructions encoded but drain the traffic from that path. I have some remarks on it in [3]

Thanks
Andrew


[1] https://datatracker.ietf.org/doc/html/rfc9256#name-explicit-candidate-path

A segment list of an explicit candidate path MUST be declared invalid when any of the following is true:

  *   It is empty.
  *   Its weight is 0.
  *   It comprises a mix of SR-MPLS and SRv6 segment types.
  *   The headend is unable to perform path resolution for the first SID into one or more outgoing interface(s) and next-hop(s).
  *   The headend is unable to perform SID resolution for any non-first SID of type C through K into an MPLS label or an SRv6 SID.
  *   The headend verification fails for any SID for which verification has been explicitly requested.


[2] https://datatracker.ietf.org/doc/html/rfc9256#name-instantiation-of-an-sr-poli  The fraction of the flows associated with a given segment list is w/⁠Sw, where w is the weight of the segment list and Sw is the sum of the weights of the segment lists of the selected path of the SR Policy.


[3] https://astone282.github.io/draft-stone-spring-mpte-sr/draft-stone-spring-mpte-sr.html#name-load-balancing )

From: David Mandelberg via Datatracker <[e-mail]>
Date: Wednesday, May 27, 2026 at 3:53 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: draft-ietf-pce-multipath-25 ietf last call Secdir review


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.



Document: draft-ietf-pce-multipath
Title: Path Computation Element Communication Protocol (PCEP) Extensions for
Signaling Multipath Information Reviewer: David Mandelberg Review result: Has
Nits

(nit) Could zero weights in the MULTIPATH-WEIGHT TLV trigger a denial of
service from dividing by zero? Would it make sense to require Weight to be
non-zero?

(nit) Section 3.4 says "If no opposite-direction path exists, then this field
MUST be set to 0, a value reserved to indicate the absence of a Path ID." What
should an implementation do if it receives a PATH-ATTRIB with multiple
MULTIPATH-OPPDIR-PATH TLVs, some of which have zero Opposite Direction Path ID
and some have non-zero Opposite Direction Path ID? If one implementation treats
that as no opposite path (ignoring the non-zeroes) and another implementation
ignores the zeroes, could that be a security issue?

Otherwise, looks good.