[spring] Re: Follow-up on IETF 124 Presentation of draft-liu-spring-sr-policy-flexible-path-selection and draft clarification
Alvaro Retana <aretana.ietf@gmail.com> Wed, 19 November 2025 13:36 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: spring@mail2.ietf.org
Delivered-To: spring@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F1B298C6BDFC for <spring@mail2.ietf.org>; Wed, 19 Nov 2025 05:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qeM4_52Hijmf for <spring@mail2.ietf.org>; Wed, 19 Nov 2025 05:36:34 -0800 (PST)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 2DD888C6BDE1 for <spring@ietf.org>; Wed, 19 Nov 2025 05:36:34 -0800 (PST)
Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-7aad4823079so6202078b3a.0 for <spring@ietf.org>; Wed, 19 Nov 2025 05:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763559393; x=1764164193; darn=ietf.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=GuSolCCXGU2wCqo/V2EWWSQtNTu+qAm8Nq/HQUFUFbk=; b=fhZ5jxDPytKCTtfZlMeAwsOpkN7fJ9YTyiu3y8UZeLfsOOdyr+24MPecofM/8LmAi4 EH/y+7N0D7cXMcLidgsIzvbsmydJquOcNsMc6RochVtJ6wwOIGBR6nWInCcYcND06EoC mEC5Y/gXsWh9PtofQSRYa4T0Cxsw4B2U4f/OgSugTqg063/RHURY4zaPxBXNP+kMCEGS a+LvnHFx3LLRQtBmsAe6DeDVtPt06skNKiu+nF2ax9MqdYikbvN/KgHD1XRo+JL4AI23 NJrLffHC79WSfReOKQe9obCdv6PbbQfvf/JhDOpDWheZmAzlSpf6ppqiwmWuV6/RBw3E /ZLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763559393; x=1764164193; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GuSolCCXGU2wCqo/V2EWWSQtNTu+qAm8Nq/HQUFUFbk=; b=PAcD8t0WfetWauIPXCuhyB4B3PrDkERw3gktmorvm2N/pFLh4Ec7JLO1coHrcFgMGZ 3cN0woObeYxFukpfMet6DUJOziV3blRIV4CCwb9NmXaNwoNX32tPitDC8QqoS0TNcyS2 G5wuzhXfuuV8gpH8U9jFQRALw1c+U5mneHjtcbwXONSfHwVf8mcHo7j+DDk3ckaty32+ j/xDvKBvB5sqjqo7yEgzpZyg225bWp9PJJAEKhS5HBz0hdVjqaUjvlRAcY6/contIeDa eq5bCO3BbHI5eKXZv12na/tZPJGurTrMeH+nxOaQaUf0w+DOHqXfAs5cm1bAup2i/nBQ OCag==
X-Forwarded-Encrypted: i=1; AJvYcCXhJ7UhHymQBtEye10PBdClS3bKXAUaR58VEmqm4XWeYOpD9zzc+CElrJ5J50ll2IJZ+RjM/Vo=@ietf.org
X-Gm-Message-State: AOJu0YyP2+ryOCV2EN7SgGceKINB9PKoijJ6vpVJfhSrn1RQmR1j7zw2 rnV7OVzNyrSPFRI3E8Z1HE8Jf2zt1W2rJTGio48QdOoZj3lwGJfaZ0kEaHtFZEZxnFo2JsrijkQ T/NH6Wq8+ssXJEdrbFxqXC1rAv34u0mc=
X-Gm-Gg: ASbGnctG0As/kGGUmtxt2oY6E2ZqHD3Tp92HpCt0U6KNM6+WI/KrULFAPw7+U6zFXHl xFeYe205AT0AAbjblahPC8cBMCkwTZ+EoVsh0F2x0KzADy8u3Tn/2AUsZCsm+MV6A810uabX5Xz 6gJ4C8/ZkyTE7wJEQ/FfcP680OA77Kl9nv6KvB0hHXuSMawygP3JLRD7Tq9ay1cGIVMvEIbeE/G NUB7zEKZUQg+uP7C4ExdufsPbboUX4ytQyfQ3c3/OHce43nBS1QSDgRoMFpQY9srIX5kuiBl0+x Q9LV5ds6BqpeUwMrwJOhB+UqCjPhS99ujehz
X-Google-Smtp-Source: AGHT+IFe+PjQ3iifEdovzFlYYpn0SzRDBW2lZinr3MAzEXH9N0++6kjGqAlgna1QubxpIk0uHQuP2F+wtmxl0D+d+C8=
X-Received: by 2002:a05:7022:68a3:b0:11a:2ec8:de1c with SMTP id a92af1059eb24-11b4130b653mr10518092c88.36.1763559392902; Wed, 19 Nov 2025 05:36:32 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 19 Nov 2025 07:36:32 -0600
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 19 Nov 2025 07:36:32 -0600
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <2b07691d0db1434-00050.Richmail.00005082154910795526@chinamobile.com>
References: <2b07691d0db1434-00050.Richmail.00005082154910795526@chinamobile.com>
MIME-Version: 1.0
Date: Wed, 19 Nov 2025 07:36:32 -0600
X-Gm-Features: AWmQ_bn0-wmu8ZOY19vI-A8p6HGisLeBlE6JHfQVBiY9k1GQhgFfpbJEKvhKljE
Message-ID: <CAMMESsz05sfrUKMkLAG2CAPgXSyv7sD7uHVemhXq4NeWiStCnA@mail.gmail.com>
To: Yisong Liu <liuyisong@chinamobile.com>, spring-chairs <spring-chairs@ietf.org>, spring <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002783a40643f2ab0b"
Message-ID-Hash: MD5VESJ2W5KSU2J2JWB2L676SPXEZ3SC
X-Message-ID-Hash: MD5VESJ2W5KSU2J2JWB2L676SPXEZ3SC
X-MailFrom: aretana.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-liu-spring-sr-policy-flexible-path-selection <draft-liu-spring-sr-policy-flexible-path-selection@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Re: Follow-up on IETF 124 Presentation of draft-liu-spring-sr-policy-flexible-path-selection and draft clarification
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/3V5jcq27QK-CUoLeogXC_2V70uY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>
On November 18, 2025 at 8:26:51 PM, Yisong Liu wrote:
Yisong:
Hi! How are you?
> Thank you for the valuable feedback following our presentation at
> IETF 124. We would like to offer some clarification to ensure our
> draft's purpose is properly understood.
>
> In our latest revision, we have referenced
> draft-karboubi-spring-sr-policy-eligibility, though we wish to
> emphasize that the two drafts serve distinctly different purposes.
> The eligibility draft introduces new concepts for path qualification,
> while our draft focuses specifically on defining a mechanism for path
> selection and switching based on forwarding performance metrics such
> as latency, jitter, and bandwidth. Our approach predefines quality
> requirements for SR policies and enables rapid path selection or
> switching when real-time monitoring indicates these requirements are
> no longer met. The reference to eligibility is included to maintain
> compatibility with the SR Policy architecture defined in RFC 9256.
>
> We believe there is no significant overlap between our draft and
> eligibility draft and see value in advancing them independently.
I understand what you're saying, but I am having a hard time seeing that
reflected in the document.
(1) From §4:
When a candidate path fails to meet forwarding quality
requirements, its Eligibility attribute SHOULD be set to false,
thereby excluding it from active candidate path selection.
This text is effectively the same as what
draft-karboubi-spring-sr-policy-eligibility says in §3.2 (Example 2:
Delay sensitive paths):
...the policy could have a constraint to not use a path when its
end-end delay exceeds a given value D1. ... In this case, a
system could set the eligibility as false when it detects that
path delay exceeds D1 (e.g. using STAMP) rendering path
ineligible for selection...
The main difference I see is that
draft-karboubi-spring-sr-policy-eligibility focuses the example on
delay, while your document mentions other possible "threshold
parameters" (§4.1). Your document also includes examples in §4.1 and
§5. If I may go further, the document is a more detailed version of
the example in §3.2/draft-karboubi-spring-sr-policy-eligibility.
The comments at the meeting in Montreal also mentioned a "high
amount of overlap" (even from one of the authors of this document).
(2) From above: "our draft focuses specifically on defining a mechanism for
path selection and switching based on forwarding performance metrics".
A mechanism is described in §4.3 (Flexible Candidate Path Selection
Process):
1) The document mentions that a "headend may be informed about the
forwarding quality requirements...through various means", and
points at BGP and PCEP drafts (§4).
2) Examples of how the path can be monitored are listed in §4.3,
but I see no specification...only examples.
3) The Rules for Setting the Eligibility Attribute (§4.2) are
basically the same as what is defined in
draft-karboubi-spring-sr-policy-eligibility: if the constraints are
met, set the Eligibility to True; otherwise, it can be set to False.
4) Finally, "whether to revert to the previous active candidate
path can be specified by the configuration" is mentioned as a
possibility, but no explicit specification.
In summary, if the intent is to define/specify a mechanism, there's
significant work to be done, given that the document only mentions
examples at this point. The current content does not justify the
Intended Status of putting this document in the Standards Track.
> We would appreciate if the chairs can give the guidance on how to
> proceed with our draft. Additionally, we have formally requested an
> adoption call during our presentation and would be grateful if the
> chairs can help to schedule this.
In addition to the comments above, the main action item at this time is to
build WG engagement and interest. I only found comments from one other
non-author in the archive (Joel) [1]. We need to see explicit engagement
and interest [2] before moving forward.
Thanks!
Alvaro.
[1]
https://mailarchive.ietf.org/arch/search/?q=%22draft-liu-spring-sr-policy-flexible-path-selection%22&f_list=spring
[2] https://wiki.ietf.org/en/group/spring/WG_Policies
- [spring] Follow-up on IETF 124 Presentation of dr… Yisong Liu
- [spring] Re: Follow-up on IETF 124 Presentation o… Alvaro Retana
- [spring] Re: Follow-up on IETF 124 Presentation o… Andrew Stone (Nokia)
- [spring] Re: Follow-up on IETF 124 Presentation o… Karboubi, Amal
- [spring] Re: Follow-up on IETF 124 Presentation o… Yisong Liu
- [spring] Re: Follow-up on IETF 124 Presentation o… Yisong Liu
- [spring] Re: Follow-up on IETF 124Presentationofd… Liyan Gong
- [spring] Re: Follow-up on IETF 124 Presentation o… JinMing LI
- [spring] Re: Follow-up on IETF 124 Presentation o… Dongjie (Jimmy)
- [spring] Re: Follow-up on IETF 124 Presentation o… chen.ran
- [spring] Re: Follow-up on IETF 124 Presentation o… Karboubi, Amal
- [spring] Re: Follow-up on IETF 124 Presentation o… Yingying Su
- [spring] Re: [Internet]Follow-up on IETF 124 Pres… wisdomtan(谭智)