Hi Ran, Alvaro, Do you think a title change of this draft would also help clarify its purpose? i.e. while the eligibility draft main intent is to generically update RFC9256 regarding path selection, draft-liu-spring-sr-policy-flexible-path-selection essentially define performance related attributes and procedures that could govern and act on the eligibility based on forwarding path quality. e.g. a title with CP eligibility use cases or quality-driven eligibility use cases?
-Regards, -Amal. From: [email protected] <[email protected]> Sent: Tuesday, November 25, 2025 10:08 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [spring] Re: Follow-up on IETF 124 Presentation of draft-liu-spring-sr-policy-flexible-path-selection and draft clarification Dear Alvaro， Thank you very much for your detailed and candid feedback. We agree that rigorous review is essential, and your comments accurately identify where our draft needs to be strengthened to achieve Standards Track. We accept comments that the current draft is too descriptive and relies too heavily on examples when defining the core switching mechanism. Our Plan Moving Forward We will immediately focus our efforts on converting the draft from a conceptual document to a prescriptive specification by taking the following steps: 1.Refining the Scope: We will further clarify the distinction between the generic Eligibility attribute (the information model knob defined in draft-karboubi) and the Quality-Driven CP Switching defined here, ensuring our document only specifies the conditions and rules for dynamic performance management. 2.Introducing Switching Logic: We will improve Sections 4 and 5 by introducing standard language description of switching logic and decision rules, and explicitly defining performance-based triggering and recovery procedures. 3.Connecting the Suite: We will clearly reference our submitted companion drafts (BGP/PCEP extensions) to confirm that the full protocol specification for the required signaling exists, thus addressing the protocol specification gap. We appreciate the clear guidance on what is needed to satisfy the Standards Track requirements. We will submit a new version as soon as possible. BR, Ran Original From: AlvaroRetana <[email protected]<mailto:[email protected]>> To: Yisong Liu <[email protected]<mailto:[email protected]>>;spring-chairs <[email protected]<mailto:[email protected]>>;spring <[email protected]<mailto:[email protected]>>; Cc: draft-liu-spring-sr-policy-flexible-path-selection <[email protected]<mailto:[email protected]>>; Date: 2025年11月19日 21:36 Subject: [spring] Re: Follow-up on IETF 124 Presentation of draft-liu-spring-sr-policy-flexible-path-selection and draft clarification _______________________________________________ spring mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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 [mailarchive.ietf.org]<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/search/?q=*22draft-liu-spring-sr-policy-flexible-path-selection*22&f_list=spring__;JSU!!OSsGDw!NNVlDOtcGb66yONzAOywzJ3jVSLLR_0QfkqSnCMCjIubjvvygUkC311zT6-aO_WMKcqbEU1ePnLQweBKDg7O7Mk$> [2] https://wiki.ietf.org/en/group/spring/WG_Policies [wiki.ietf.org]<https://urldefense.com/v3/__https:/wiki.ietf.org/en/group/spring/WG_Policies__;!!OSsGDw!NNVlDOtcGb66yONzAOywzJ3jVSLLR_0QfkqSnCMCjIubjvvygUkC311zT6-aO_WMKcqbEU1ePnLQweBKzdH2cQ8$>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
