[Pce] Re: [Tsv-art] draft-ietf-pce-multipath-25 ietf last call Tsvart review

["Samuel Sidor (ssidor)" <[e-mail]>]

Thanks a lot, Vidhi.

Please check version 27.

Fixed S11 - there was some discussion with other co-authors/chairs/AD about whether it is supposed to be normative or informative, so I originally skipped it (since that discussion was still in progress, I just forget to mention in my response), but it should be updated now.

Also added clarification for M5 and S4.

Regards,
Samuel

From: Vidhi Goel <vidhi_goel=[e-mail]>
Date: Friday, 5 June 2026 at 22:32
To: Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Tsv-art] draft-ietf-pce-multipath-25 ietf last call Tsvart review

Hi Samuel,

  Thanks for the thorough responses and the quick turnaround on -26. I went through the diff against -25 and
  almost everything I raised has been addressed cleanly. A few notes:

  One item that didn't make it into -26:

  - S11 (sr-bidir-path normative → informative): your reply said "I'll update it to informative", but in -26 it's
  still listed under §12.1 Normative References. Could you move it to §12.2 in the next revision? That also avoids
  the downref.

  Two items where I accept the disposition but a one-line rationale in the document would help future readers:

  - M5 (Updates: 8231, 8281): I take your point that capability gating means legacy peers don't see the new RBNF
  productions, and I see the WG already removed the Updates clause earlier. A short sentence in §5 stating that
  the new RBNF is additive and applies only when MULTIPATH-CAP is negotiated would prevent this question from
  coming back.
  - S4 (asymmetric over-cap error): your reasoning ("PCRpt is a state report, the PCE has no basis to reject") is
  sound. One sentence in §4.1.1 capturing that asymmetry would make it self-evident from the document.

  Items I'm closing as defended/acceptable:

  - M6 — the §9.6 text on flow-based hashing is enough; I'll drop the SHOULD ask.
  - M8 — state amplification is now covered; deferring steering manipulation and forged OPPDIR bindings to the
  base PCEP TLS/auth model is reasonable.
  - S9 — fine to keep F-without-C as future-proofing.
  - S12 — the existing "Unexpected PATH-ATTRIB" text covers it.

  Other observations on -26 (not from my original review):

  - The new §3.3 paragraph on weight=0 (Segment List drain via RFC 9256 §5.1) is a nice addition.
  - M2 was handled really well — §3.4 + §4.4 + Appendix A.3 are all consistent now, and reusing the existing TBD4
  error code for the Path ID=0 case is clean.

  With S11 fixed, I'm happy to update my review status from "Ready with Issues" to "Ready" (modulo the two
  optional clarifications above, which I'll leave to your and the AD's judgment).

  Thanks again,
  Vidhi

On Jun 5, 2026, at 2:45 AM, Samuel Sidor (ssidor) <ssidor=[e-mail]> wrote:

Hi Vidhi,

Updated version v26 submitted. I hope that I haven’t missed anything.

Thanks for your review and comments,
Samuel

From: Samuel Sidor (ssidor) <[e-mail]>
Date: Wednesday, 3 June 2026 at 11:48
To: Vidhi Goel <[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 Tsvart review

Thanks a lot, Vidhi,

Please find inline responses marked with <S>. I’ll submit version 26 with those changes soon.

Regards,
Samuel

From: Vidhi Goel via Datatracker <[e-mail]>
Date: Friday, 29 May 2026 at 01:15
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 Tsvart review

Document: draft-ietf-pce-multipath
Title: Path Computation Element Communication Protocol (PCEP) Extensions for
Signaling Multipath Information Reviewer: Vidhi Goel Review result: Ready with
Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

and well-motivated, and the encoding fits cleanly into existing PCEP
constructs.

However, there are several normative inconsistencies, two important
internal contradictions, an IANA registry omission, and transport-related
guidance that should be added before publication. None are showstoppers,
but the spec-level bugs (items M1–M4) should be fixed.

---

## Major issues (M)

### M1. Load-balancing ratio wording excludes the referent path
Two places describe the traffic share using "all other", which in English
excludes the path being described and therefore does not describe a valid
distribution (the per-path fractions do not sum to 1).

- §3.3 (Weight field):
> "The fraction of flows that a specific ERO/RRO carries is derived
> from the ratio of its weight to the sum of the weights of **all
> other paths**: see Section 4.3 for details."

- §4.3 step 3:
> "The PCC derives the fraction of flows carried by a specific primary
> path from the ratio of its weight to the sum of **all other
> multipath weights**."

Suggested rewording (matches RFC 9256 §2.11 and standard W-ECMP):

- §3.3:
> "The fraction of flows that a specific ERO/RRO carries is derived
> from the ratio of its weight to the **sum of the weights of all
> paths in the multipath (including this path)**: see Section 4.3 for
> details."

- §4.3 step 3:
> "The PCC derives the fraction of flows carried by a specific primary
> path from the ratio of its weight to the **sum of the weights of all
> paths in the multipath**.”

<S> I’ll update based on suggestion.

### M2. Contradiction on encoding "no opposite-direction path"
- §3.4 (MULTIPATH-OPPDIR-PATH TLV, "Opposite Direction Path ID"):
  "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."
- §4.4 step 5: "For paths that have no opposite-direction counterpart, the
  MULTIPATH-OPPDIR-PATH TLV is **omitted** from the PATH-ATTRIB object."

These two normative statements directly conflict — implementers cannot tell
whether to omit the TLV or include it with ID=0. Appendix A.3 (POL1 CP2,
Path ID=2; POL2 CP2, Path ID=2) actually exercises the "include with ID=0"
form, contradicting §4.4 step 5. Pick one and align all three locations.

<S> David raised similar comment as part of Secdir review. I’ll update to block value of 0, TLV should not be needed if opposite-direction path does not exist.

### M3. Wrong Error-Type for "Conflicting Path ID"
- §4.2: "MUST send PCError message with **Error-Type = 1** ('Reception of
  an invalid object') and Error-Value = 38 ('Conflicting Path ID')."
- §7.3 (IANA): allocation is under **Error-Type = 10** ("Reception of an
  invalid object").

Error-Type 1 in the IANA registry is "PCEP session establishment failure",
not "Reception of an invalid object". The IANA table is correct; §4.2
should read "Error-Type = 10”.

<S> Thanks for catching, I’ll update to type 10.

### M4. IANA registry for MULTIPATH-OPPDIR-PATH TLV flags is missing bit 13
§7.6 lists:
```
0-12  Unassigned
14    L-flag: Link co-routed
15    N-flag: Node co-routed
```
Bit 13 is unaccounted for. Either extend "0-12" to "0-13" or add an
explicit "13 | Unassigned" row.

<S> I’ll update to "0-13”.

### M5. RBNF in §5 updates RFC 8281 but the document does not formally update it
§5 modifies `<PCE-initiated-lsp-instantiation>` from RFC 8281 (and the
`<intended-path>` / `<actual-path>` productions from RFC 8231). Documents
that change normative RBNF of an existing RFC should carry an explicit
`Updates: 8231, 8281` clause in the front matter. If the WG intent is
"extends but does not update", that should be stated and the RBNF changes
should be framed as additive grammar for the new capability path.

<S> This was discussed in the past. Since inclusion of PATH-ATTRIB object is gated by capability, it is not considered as an update to RBNF of those 2 RFCs.
Note that this draft was already even marked as update for those 2 RFCs (see for example https://www.ietf.org/archive/id/draft-ietf-pce-multipath-19.html) and it was removed based on that discussion.

### M6. No flow-affinity / reordering guidance (transport concern)
§4.3 phrases the split as "fraction of **flows**", which implicitly assumes
flow-preserving load-balancing (per-5-tuple hashing or similar). This is
critical: per-packet striping across multiple Segment Lists in a Candidate
Path will reorder TCP/QUIC and break performance.

Recommend adding a normative SHOULD that PCC implementations preserve
flow-to-path affinity when distributing traffic across paths within an LSP,
and a non-normative note that per-packet load-balancing is harmful to
transport-layer performance unless paths have near-identical RTT/MTU
characteristics.

<S>The term 'fraction of flows' already implies flow-preserving load-balancing rather than per-packet striping. Per-flow hashing is standard practice for ECMP/W-ECMP in SR networks and is not unique to this extension. Detailed forwarding-plane implementation guidance is out of the scope of signaling protocol (PCEP).

### M7. No discussion of asymmetric per-path properties
Paths within a single LSP may have very different MTU, PMTU, latency, and
loss characteristics. Two relevant operational hazards are not addressed:

- **MTU/PMTU divergence:** flow-hashing across paths with different MTUs
  yields per-flow black-holes for the high-MTU packets that happen to be
  hashed onto the low-MTU path. PMTUD then becomes path-specific, which
  hashing breaks. Worth at least an Operational Consideration.
- **Latency divergence:** advertising weighted ECMP across paths with very
  different one-way delay degrades transport performance regardless of
  flow affinity (head-of-line in shared queues, RTT estimation skew when
  paths rebalance, etc.). Worth a note.

<S>I believe this is out of scope of PCEP and I can make some notes into “Impact On Network Operations” in “Operational Considerations”.

### M8. Security Considerations is too thin for what this draft enables
§8 only inherits considerations from the base PCEP RFCs. Multipath
introduces specific new attack surfaces that should be called out:

- **State amplification / DoS.** A misbehaving (or compromised) PCE can
  push an order-of-magnitude more LSP state into a PCC by maximizing
  multipath fan-out. The "Number of Multipaths = 0 (unlimited)" sentinel
  in §4.1.1 makes this worse. Recommend the spec require a non-zero
  configured cap by default and discourage the unlimited value in
  production.
- **Traffic steering manipulation.** A compromised PCE can shape
  weighted-ECMP ratios to drive flows onto attacker-observed paths or
  congest a specific link. Worth one paragraph.
- **Bidirectional mapping abuse.** Forged MULTIPATH-OPPDIR-PATH bindings
  can cause a PCC to install/monitor return paths that don't actually
  carry the return traffic, defeating BFD/PM described in §2.3.

<S> I'll extend Security Considerations sections for state amplification noting that the "Number of Multipaths" field provides a bound. The other concerns (traffic steering manipulation, bidirectional mapping abuse) are generic PCE compromise scenarios already covered by the base PCEP security model (TLS + authentication)
---

## Minor / semantic issues (S)

### S1. Operational state of the LSP vs. per-path O field (§3.1)
The 3-bit O field per path inherits RFC 8231 LSP-object semantics, but the
draft never says how per-path O combines into the LSP-level O state. If 2
paths are UP and 1 is DOWN, is the LSP UP, DOWN, or some new "partially
up" state? Either reference an existing rule or define one.

<S>I can specify in 4.1.1 that it is out of scope (implementation specific) and being solved in separate PCEP drafts (e.g. for SR as part of draft-chen-pce-sr-policy-cp-validity).

### S2. O-flag semantics in MULTIPATH-CAP LSP object (§4.1.1)
The same bit is overloaded as both "I support reverse paths" (in OPEN)
and "I want / am providing reverse path info" (in LSP object), and within
the LSP-object use it conflates request and provision. Recommend
explicitly stating the directional rule: PCC-sent bit = request,
PCE-sent bit = provision, and clarify behavior when both peers set
inconsistent values.

<S>The draft is already specifying what per-LSP behavior is:
"When set by the PCC (in PCRpt/PCReq), it requests the PCE to provide reverse path information. When set by the PCE (in PCInit/PCUpd/PCRep), it indicates the PCE is providing or will provide reverse path information.”
For session-level inconsistency (one peer advertises O-flag in OPEN, other does not), the existing statement already covers it:
"if a PCEP speaker receives a TLV within the PATH-ATTRIB object but the corresponding capability flag was not set in the negotiated MULTIPATH-CAP TLV, it MUST treat this as an error.”
For per-LSP inconsistency, I'll add:
"For PCC-originated LSPs, if the PCC has not set the O-flag in the MULTIPATH-CAP TLV of the LSP object, the PCE SHOULD NOT include reverse path information in the corresponding response. If the PCC receives unsolicited reverse path information, it MAY ignore it."

### S3. "Number of Multipaths" scope ambiguity (§4.1.1)
The text describes the field as "how many forward primary multipaths the
PCE can compute" — but doesn't state up front whether this is per-LSP or
per-session. The later text makes it per-LSP. State this in the field
definition.

<S> I’ll clarify it.

### S4. Asymmetric error handling for over-cap signaling (§4.1.1)
"If a PCC receives more paths than it advertised support for, it MUST send
a PCError…" The reverse direction (PCE receiving more than its computed
cap from a PCC PCRpt) is not specified. Make the rule symmetric or
explicitly say it only applies in one direction and why.

<S> The error is intentionally one-directional. A PCC reporting paths via PCRpt is describing
existing forwarding state; the PCE has no basis to reject this. When PCE is advertising number of paths, it is used as an indicating of how many paths PCE is capable of computing.

### S5. Path ID ownership after delegation change (§4.2)
"If the LSP is delegated to the PCE, then the PCE allocates the Path IDs.
If the LSP is locally computed on the PCC, then the PCC allocates the
Path IDs." What happens on delegation revocation or re-delegation — do
Path IDs persist, get reallocated, or invalidated? Real implementations
will hit this; please clarify.

<S> I’ll add something like “When LSP delegation changes (e.g., the PCC revokes delegation from the PCE), the new path owner SHOULD retain the existing Path IDs to simplify path correlation in the event of re-delegation. If the new owner cannot retain them, it MAY allocate new Path IDs."

### S6. Many-to-many vs. "symmetric" constraint (§4.4)
§4.4 step 3 explicitly allows many-to-many opposite-direction mappings,
while a few lines later: "When path A references path B as its
opposite-direction path, path B MUST also reference path A." Both can
coexist (each (A,B) edge appears in both directions), but the wording
could be read as bijective. Add a sentence: "For each (A → B) reference,
the reverse (B → A) reference MUST also be present; multiple such
references per path are permitted.”

<S> I personally consider original text as already covering it, but I don’t see harm in adding that extra statement (even if it is partially redundant).

### S7. "Informational only" reverse paths vs. §2.3 BFD/PM use
- §3.1 R-flag: "Paths with this flag set serve only informational purpose
  to the PCC."
- §2.3: reverse Segment Lists are used by PM/BFD to drive bidirectional
  liveness sessions.

§2.3 makes the reverse path operationally load-bearing, not just
informational. Soften §3.1 to "Reverse paths are not installed for
forward-direction load-balancing; they MAY be used for purposes such as
PM/BFD as described in §2.3.”

<S> Agreed, I’ll update to something like “Paths with this flag set are not installed in forwarding for load-balancing purposes, but MAY be used by the PCC for operations such as Performance Measurement (PM) or Bidirectional Forwarding Detection (BFD)."

### S8. Composite Candidate Path — no recursion-depth bound (§3.5)
A Composite CP signals traffic recursively into other SR Policies on the
same headend. Nothing in the draft bounds the recursion depth or
specifies loop-detection behavior if policy A recurses into B and B
recurses into A (directly or transitively). At minimum, an Operational
Consideration acknowledging this is needed; a normative MUST-NOT against
cycles would be stronger.

<S> Since this is already covered by RFC9256, I’ll add clarification into operational considerations at least.

### S9. F-flag without C-flag has no defined semantics
§4.1.1: "the F-flag MAY be set without the C-flag" for future use cases.
There is no defined consumer of MULTIPATH-FORWARD-CLASS today outside
Composite/Per-Flow CP. Either state that "F-only" today has no defined
semantics (reserved for future use) or remove the allowance until a
consumer exists.

<S> This is intentional "future-proof” design (as stated already). The text already states 'to allow for future use cases’.

### S10. Inconsistent terminology: "Reserved" vs "Flags" (§3.5.1 vs §7.7)
In Figure 4 the area holding the T flag is labeled "Reserved", but §7.7
creates a "Flags in the MULTIPATH-FORWARD-CLASS TLV" registry covering
bits 0–31. Either rename Figure 4's field to "Flags" (consistent with
PATH-ATTRIB and OPPDIR-PATH TLVs) or rename the registry.

<S>I’ll update to “Flags”.

### S11. Normative vs informative reference classification
[I-D.ietf-pce-sr-bidir-path] is listed as **normative**, but the
MULTIPATH-OPPDIR-PATH TLV is defined **by this document**. The sr-bidir-path
draft is a *consumer*, not a producer, of definitions used here. Unless
implementing this document strictly requires reading sr-bidir-path,
demote it to informative — that also avoids a downref dependency.

<S> I’ll update it to informative.

### S12. Capability presence on a single side (§4.1.1)
"The PCC MUST NOT include this TLV in the LSP object if the TLV was not
present in the OPEN objects of **both** PCEP peers." Good. But the
inverse case isn't stated: if only one peer advertised in OPEN, what
happens at message processing time on the unaware peer? Presumably the
"Unexpected PATH-ATTRIB" error fires, but say so explicitly.

<S> There is already following statement: “"If a PCEP speaker receives a PATH-ATTRIB object but the multipath capability was not successfully negotiated during session establishment, it MUST send a PCError... TBD2.” in same section.

### S13. Appendix A.3 internal asymmetry
POL1 has 2 Segment Lists in CP2 (one with reverse, one without), while
POL2 CP2 only has 1 forward Segment List. The state-reports therefore
include "reverse" PATH-ATTRIBs whose Opposite Direction Path ID = 0,
which exercises the very ambiguity called out in M2. Once M2 is resolved
the example should be regenerated to match.

<S> I’ll fix it.

---

## Nits / grammar / wording (N)

(Line numbers from the html-rendered text; section numbers from the doc.)

- **§1.2 ECMP / W-ECMP**: prefer hyphenated "Equal-Cost Multi-Path" and
  "Weighted Equal-Cost Multi-Path" (RFC 2992 spelling).
- **§2.2**: "two paths, that can together carry 80 Gbps" — drop the
  comma; "that" introduces a restrictive clause.
- **§2.2**: "have only 60 Gbps capacity" → "have only 60 Gbps of capacity
  each" (or "are limited to 60 Gbps").
- **§3.1**: "preceded by **an** PATH-ATTRIB object" → "**a** PATH-ATTRIB
  object" (article matches the consonant sound).
- **§3.1**: "serve only informational purpose to the PCC" → "serve only
  an informational purpose for the PCC".
- **§3.3 / §3.4 / §3.5.1 / §4.1.1** all open with "New X TLV is defined…"
  → "A new X TLV is defined…" (missing indefinite article).
- **§3.3 / §3.4**: "Length (16 bits): 4 bytes." / "8 bytes." → IETF
  convention is "octets". RFC 5440 uses "octets" throughout.
- **§3.4 N-flag**: "node co-routed with its opposite direction path,
  specified in this TLV" — comma turns the clause non-restrictive;
  either remove the comma or change to "specified by this TLV".
- **§3.5**: "we make use of the COLOR TLV" → "this document makes use of
  the COLOR TLV".
- **§3.5**: "An ERO MUST be included as per the existing RBNF, this ERO
  MUST contain no sub-objects." — comma splice; use a period or
  semicolon.
- **§3.5.1**: "builds on top of the concept" → "builds on the concept".
- **§4.1.1**: "From the PCC, the MULTIPATH-CAP TLV MAY also be present in
  the LSP object" → "The PCC MAY also include the MULTIPATH-CAP TLV in
  the LSP object".
- **§4.2**: "MUST send PCError message" → "MUST send **a** PCError
  message".
- **§4.2**: "across all these path types" → "across forward and reverse
  paths" (forward/reverse are roles, not types).
- **§4.3**: "(un)equal load-balancing" → "equal or unequal load-balancing".
- **§4.4**: "established **atomically**" — too strong a claim for a
  message-level operation; suggest "established in a single message
  exchange".
- **§5**: "The RBNF of PCRpt and PCUpd messages, as defined in
  [RFC8231], **use** a combination…" → subject is "RBNF" (singular);
  should be "**uses**".
- **§9.4** last bullet: missing trailing period.
- **§6 Implementation Status**: the "Note to RFC Editor — remove" is
  present and correct, good.
- **§3.1 Path ID** vs **§4.2 Value 0 semantics**: §3.1 describes Path ID
  without mentioning 0=unallocated. Add a sentence pointing forward to
  §4.2.

<S> Thanks for those - I’ll fix them.
---

## Suggested edit order for the authors

1. Fix M1 (load-balancing ratio wording: "all other" → "all paths
   including this one") — single-word change, two locations.
2. Resolve M2 (TLV omission vs ID=0) — pick one rule and propagate to
   §3.4, §4.4, and Appendix A.3.
3. Fix M3 (Error-Type 1 → 10) — one-character fix.
4. Fix M4 (missing bit 13 in IANA registry).
5. Decide M5 (Updates: 8231, 8281 header) with the WG / AD.
6. Add a paragraph in §4.3 covering M6 (flow-affinity SHOULD).
7. Expand §8 (Security) and §9.6 (Operational) per M7 and M8.



_______________________________________________
Tsv-art mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]