Hi Jie，
Thank you for your valuable feedback on the latest version of our draft, which will certainly help us improve the draft. In scenarios with multiple SLs, if an SL does not meet certain criteria (e.g., latency, packet loss, jitter), its eligibility attribute will be set to false and it will be excluded from its associated CP when forwarding traffic. This may indeed affect the total available bandwidth of the CP, especially if multiple SLs are disqualified. We agree that it would be beneficial to clarify this process further. In the next version of the draft, we will add a dedicated subsection to explicitly describe the handling of multiple SLs within a CP, including how SL excluding impacts CP bandwidth and overall eligibility. In practice, bandwidth metric value derived from multiple measurements over time. The exact number of measurements may depend on network conditions and configuration, aiming to smooth out transient variations and provide a more stable estimate. We will also enhance the draft to better explain how these metrics are collected and applied in the path selection process to mitigate the impact of sudden changes. Once again, thank you for your insightful comments. We will incorporate these clarifications into the next revision and look forward to your continued feedback. Best Regards Yisong ----邮件原文---- 发件人："Dongjie (Jimmy)" <[email protected]> 收件人：Yisong Liu <[email protected]>,AlvaroRetana <[email protected]>,spring-chairs <[email protected]>,spring <[email protected]> 抄 送: draft-liu-spring-sr-policy-flexible-path-selection <[email protected]> 发送时间：2025-12-23 18:28:54 主题：RE: [spring] Re: Follow-up on IETF 124 Presentationofdraft-liu-spring-sr-policy-flexible-path-selectionand draft clarification Hi Yisong, Thanks for the update of this draft. I’ve read its latest version and think this could be a useful approach for selecting the eligible candidate path according to specific service requirements. I have one quick comments regarding the threshold parameters. Some of the parameters (e.g., jitter, latency, packet loss) can be used to determine the eligibility of each segment list, while the bandwidth related parameters require to take the total bandwidth of all the valid segment lists into consideration. Does this imply some specific order in comparing these threshold parameters with the attribute of the segment lists/candidate path? It would be clearer to have separate sub-sections on the eligibility of segment list and the eligibility of candidate path. And one related question is, how is the actual available bandwidth of the segment lists obtained? As the actual available bandwidth may change frequently, is it suitable to be used as one parameter for path selection? Best regards, Jie From: Yisong Liu <[email protected]> Sent: Monday, December 15, 2025 5:10 PM To: AlvaroRetana <[email protected]> spring-chairs <[email protected]> spring <[email protected]> Cc: draft-liu-spring-sr-policy-flexible-path-selection <[email protected]> Subject: [spring] Re: Follow-up on IETF 124 Presentation ofdraft-liu-spring-sr-policy-flexible-path-selectionand draft clarification Hi Alvaro and WG, Thank you for your valuable feedback on the previous version of our draft. We have carefully considered the comments and have just submitted an updated version (draft-liu-spring-sr-policy-flexible-path-selection-12) to address them. The key technical updates in this revision are as follows: Clarified Reference to Eligibility Concept (section 1): The document now explicitly references and builds upon the eligibility attribute introduced in the related eligibility draft and also clarifies not simply an expansion of the eligibility draft's use cases. Updated Information Model for Performance Thresholds (section 4.2): We have defined a structured information model that specifies performance threshold parameters (e.g., latency, jitter, bandwidth) for each SR Policy candidate path. Detailed Forwarding Quality Measurement (section 4.4): Added specifics on performance measurement methods, including the use of STAMP for metrics like delay and formulas for calculating available bandwidth. Refined Selection Rules (section 4.5): The rules for the path selection have been refined to mandate its use in excluding paths that fail to meet quality thresholds from active selection. Wait-to-Restore (WTR) Timer Mechanism (section 4.6): Introduced a WTR timer to prevent flapping by delaying a path's return to service until its quality stabilizes. With these updates, the document is now more comprehensive and detailed. We kindly request your continued review and guidance on this version. Your feedback is invaluable to us, and we look forward to hearing from you at your earliest convenience. The updated draft is available at: URL: https://www.ietf.org/archive/id/draft-liu-spring-sr-policy-flexible-path-selection-12.txt Status: https://datatracker.ietf.org/doc/draft-liu-spring-sr-policy-flexible-path-selection/ HTMLized: https://datatracker.ietf.org/doc/html/draft-liu-spring-sr-policy-flexible-path-selection Diff: https://author-tools.ietf.org/iddiff?url2=draft-liu-spring-sr-policy-flexible-path-selection-12 Thank you for your time and support. Best Regards, Yisong ----邮件原文---- 发件人：Yisong Liu <[email protected]> 收件人：AlvaroRetana <[email protected]>,spring-chairs <[email protected]>,spring <[email protected]> 抄 送: draft-liu-spring-sr-policy-flexible-path-selection <[email protected]> 发送时间：2025-11-20 10:20:22 主题：Re:Re: Follow-up on IETF 124 Presentation ofdraft-liu-spring-sr-policy-flexible-path-selectionand draft clarification Hi Alvaro, Thank you for your detailed feedback and guidance. This is highly valuable for improving our draft. I woud like to provide some additional clarification. Our draft, draft-liu-spring-sr-policy-flexible-path-selection, was initially presented at IETF 117 in 2023, predating the eligibility draft. Our work is not simply an expansion of the eligibility draft's use cases. From the beginning, we proposed a mechanism for Candidate Path switching based on forwarding quality thresholds and monitoring results. While this approach originally modified the active candidate path status, we later incorporated the eligibility concept following AD feedback to better align with the SR Policy architecture defined in RFC 9256, as we believe this concept better reflects path state definitions. Our focus remains on the CP switching mechanism based on forwarding quality. We have already submitted related drafts covering BGP and PCEP extensions for forwarding quality notification, though our current priority is advancing the main spring draft: draft-liu-idr-bgp-sr-policy-cp-threshold draft-liu-pce-sr-policy-cp-threshold draft-liu-idr-bgp-ls-srp-flexible-path-selection Per your suggestions, we will promptly enhance Section 4.3 with detailed explanations of path quality measurement methodologies and the revertive procedures. Thank you for your suggestions and guidance. Best regards, Yisong ----邮件原文---- 发件人：Alvaro Retana <[email protected]> 收件人：Yisong Liu <[email protected]>,spring-chairs <[email protected]>,spring <[email protected]> 抄 送: draft-liu-spring-sr-policy-flexible-path-selection <[email protected]> 发送时间：2025-11-19 21:36:32 主题：Re: Follow-up on IETF 124 Presentation of draft-liu-spring-sr-policy-flexible-path-selectionand draft clarification On November 18, 2025 at 8:26:51PM, 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 mailing list -- [email protected] To unsubscribe send an email to [email protected]
