MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: David Mandelberg via Datatracker <noreply@ietf.org>
To: <secdir@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: 
 <177991158535.1173153.17796402122309290957@dt-datatracker-5b4c8598b5-4ztf9>
Date: Wed, 27 May 2026 12:53:05 -0700
Message-ID-Hash: LRDDTBTR6KV3ZBQYU3ZKMGPJ2IPQXF46
CC: draft-ietf-pce-multipath.all@ietf.org, last-call@ietf.org, pce@ietf.org
Reply-To: David Mandelberg <david@mandelberg.org>
Subject: =?utf-8?q?=5BPce=5D_draft-ietf-pce-multipath-25_ietf_last_call_Secdir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/pce/AsOpuGSp5qNRjWtGuhjAAQ0numU>

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.