[Pce] Shepherd review of draft-ietf-pce-state-sync

Dhruv Dhody <dd@dhruvdhody.com> Thu, 30 October 2025 15:48 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@mail2.ietf.org
Delivered-To: pce@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3D72F7EF57B2 for <pce@mail2.ietf.org>; Thu, 30 Oct 2025 08:48:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20230601.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww8_EpPm7n6v for <pce@mail2.ietf.org>; Thu, 30 Oct 2025 08:48:05 -0700 (PDT)
Received: from mail-oa1-x43.google.com (mail-oa1-x43.google.com [IPv6:2001:4860:4864:20::43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 889A67EF57A5 for <pce@ietf.org>; Thu, 30 Oct 2025 08:48:05 -0700 (PDT)
Received: by mail-oa1-x43.google.com with SMTP id 586e51a60fabf-3c9aef8fea5so166337fac.0 for <pce@ietf.org>; Thu, 30 Oct 2025 08:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20230601.gappssmtp.com; s=20230601; t=1761839279; x=1762444079; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zR8+76rpoFPsemUiaebvRu8DD4adB6jjVY14oRje36w=; b=k9KQGafrsn7a+GQNInWRs+rJKUk+SHYQ9JYUieM93FVvCW2T8W6qjt/kY/U8iZk9yk hp3hMH77FV3giDU3raBeW6aKZCCc1Ixvxl48iTveOSmyYjmlS4gCp482+qRsOH7Y4zic uoGPc/8LzDT1faobfnvBI0q1ilnxkwVsT1fVA9xhpibm9oAkEY9wRd4v1/cRxZvZat5x iJKXczSQE7nCciCYB0OecK/ku+mCCVIPVatt3JVTa6xgWMir879B69gkVNqXnEw1vRXW bzdrDhMWfr+C+8IGkKOnb1ZamPZUr2Uf09VJKgioHFeOs2PAs0UQf0PRswWnArZV1kbH tivg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761839279; x=1762444079; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zR8+76rpoFPsemUiaebvRu8DD4adB6jjVY14oRje36w=; b=N7P8tTKeMzppVqxyQgDmMdxjQJsZzJUoQPFVF/kTvvO7W80lctMaYEALre/chKH8LK of/7qw5QpUsCKynKXW9xqtxhfJXqid5yxGHI6TnKGfDdFkxmKnp5u09zg5GksTPcX/8V VrF/tjxv+Gq0Vy8OQS72sCZjRIBqpEN1QqUfCGs19UDljLyOs1uDZgUCsZQSq3AmZYYm VQkyL35nyCNNV98A2+/9DBkTz/lGvteu0V/YPKhf+0PwDuBfk5ZjnrfbE0VbHJX1BK8g 7WtZCO0+p9OPb36xVqSimMDpuUcih8suDHTEYXivAsqpwKw8a8SJYB5hIijiIHNkGVkT NznA==
X-Gm-Message-State: AOJu0Yy0n2v/NDhBQXpl6YXM1inLoFJjt4saGjt4A2BI760UEZ7qg/k7 FZQmgxwc8tBixSR5TCRvrIxjGBfi9Hx2JbZIlBuUjGWeG1HdJLKE2d9igtlNsTrNYWCsMIXDas/ bW4KZp4gZozx3bBqKotxpeT8luBzCdxI3LJvpaWnapA==
X-Gm-Gg: ASbGnctHJdJTZ0Gzh2adZEwlx2st7GGfiiEF9480GrQn9a9lnsXSQeRDXkyfloxxiWI 7bvURFAK4ZbDgOYK0+szqCPA5jcBT8CjowTyJ8v3k6a2kve/91PoiMl4/AljiBfjl8moTKRqJs0 RmEJAwJDmZ8aX3e7Kl1MI0jAC2+LBIqmVbQGuX/wlYhOwurmKdiXZBbQ1FgYo2jh/10rKyXgRDc aVmmBQsY5net1LvIdsdssUL8J5bk2SLw+c1GgiHEKzyUxzHj4RAFgnxPL64imbtH7f7qU2bfouW UAo28YNbcHqDX7zh3dAlzEzE2pCkLsky52wG47eGYwawuBmXgZj0458IRSdEzItgEUwL0xQV+qh HLSQNXLyiWJOTXOHXuZT1vFm0gt/wo2fwDzgyhpYAhwmQezLPX3KhS/plRgjZ
X-Google-Smtp-Source: AGHT+IFAGXY0LDlgZ0Kru8zSNaDjqlSVcsAqsP7aTnpjP4Q2GmgtkUq63Cb99SpLiBR+7QpvIbCLyy7MjdjEJ9PQ7bM=
X-Received: by 2002:a05:6820:6288:b0:654:f102:31e2 with SMTP id 006d021491bc7-6568a1a73a0mr57781eaf.0.1761839278848; Thu, 30 Oct 2025 08:47:58 -0700 (PDT)
MIME-Version: 1.0
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 30 Oct 2025 15:47:22 +0000
X-Gm-Features: AWmQ_bmoPnL7O403_KArcYpqWo_QxhPBIWoWL-4JToRsFJxfwq94QTOFABorn3E
Message-ID: <CAP7zK5a+PKWAdaY7Bj=B=frvf7=zRrL9YDudi7zY6EAQf3fkxQ@mail.gmail.com>
To: draft-ietf-pce-state-sync@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005e0b7c0642622c14"
Message-ID-Hash: JBU3HZ2JRCTPMMSXSQBCUQGQGCRKKIGB
X-Message-ID-Hash: JBU3HZ2JRCTPMMSXSQBCUQGQGCRKKIGB
X-MailFrom: dd@dhruvdhody.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pce.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "pce@ietf.org" <pce@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Pce] Shepherd review of draft-ietf-pce-state-sync
List-Id: Path Computation Element <pce.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/_7zMXstGuc3FdV37O_6MdxahjvA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Owner: <mailto:pce-owner@ietf.org>
List-Post: <mailto:pce@ietf.org>
List-Subscribe: <mailto:pce-join@ietf.org>
List-Unsubscribe: <mailto:pce-leave@ietf.org>

Hi Authors,

I have done the Shepherd review of the I-D. Once the update is posted, I
will send this to the AD.

# Shepherd review of draft-ietf-pce-state-sync

## Minor

- Section 3.3, "When a PCE receives a new PCRpt from a PCC without the
LSP-DB-VERSION, it SHOULD NOT forward the PCRpt on any state-sync sessions
and SHOULD log such an event on the first occurrence", when can the SHOULD
NOT be ignored? Otherwise make it a MUST NOT.

- Related to above, there are a lot of SHOULD in the draft, check them
against the IESG statement
https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

- Section 3.5, "The computation priority is a number...", it is important
to go a little more in detail like an unsigned integer of range 0-7 (same
as delegation-pref in the PCEP YANG model) with 7 reflecting the highest
preference. Update the examples to keep the priority in this range.

- Section 3.5, "the highest IP address has more priority", we need to
handle the case for comparing IPv4 and IPv6 address as well, perhaps say
when comparan IPv4 address MUST first be converted to its IPv4-mapped IPv6
form [RFC4291] before comparison.

- Section 3.5, "...the operator MAY decide to instruct a switch-over to
delegate the LSP to the next highest priority PCE or to take back control
of the LSP. It is a local policy decision", is it the operator or the PCC?

- I suggest explicitly clarifying that the full mesh of PCEP sessions
between PCEs should be okay from scalability point of view. Perhaps in
Section 8.6? Something like - 'The “full mesh” requirement applies only
among PCEs that participate in inter-PCE state synchronization for the same
set of PCCs or associations. In operational deployments, this typically
involves a small number of PCEs (e.g., two or three for redundancy), making
a full mesh feasible for deterministic state consistency and loop
prevention.'


## Nits

- s/updates all PCEs/updates to all PCEs/

- Add reference on first mention of association groups

Thanks!
Dhruv