Hi Himanshu, Thank you for your endorsement for this draft.
The case you are outlining can be dealt by the headends detecting the SID list failure via the per SID list connectivity verification failing. We did not have explicit text saying that, so I added the following text to Section 7.1 in the newly uploaded -04 version of draft-ietf-spring-cs-sr-policy. "For cases where multiple segment lists are used by a candidate path, the headends will declare a candidate path down after connectivity verification has failed for one or more segment lists because the bandwidth requirement of the candidate path can no longer be met." Dear WG members, The newly updated -04 version does further address * editorial comments I got offline * Cleared idnits check issues * Offline comment to also cover the PCE-init use case * Sasha V.’s concern discussed on the SPRING mailer about TI-LFA and uloop avoidance potentially using the same adjacency SIDs as CS-SR Policies in section 3.1 cheers Christian On 05.02.2025, at 00:31, Shah, Himanshu <hshah=40ciena....@dmarc.ietf.org> wrote: WG, I endorse the WG document and believe that it is ready for the next step. It is an important work that is addressing the need of some service providers. Having said that, (we – Amal and myself) would like to bring up a point that was made to the author, a couple of meetings ago. This is about a candidate path (CP) using multiple SID lists for the b/w advantage. In such configuration, if a SID list has faulted, B/W is technically degraded but candidate path hosting the multiple SID lists will continue to be operational. To that point, we believe that ‘eligibility’ flag for the candidate path to influence the use of the CP or not, can be helpful (very much like LAG min link). There are two options for added verbiage that describes the scenario and how to tackle. A) not-a-problem if CP uses single SID list (which is most common implementation anyways) OR B) provide reference to ‘eligibility’ draft as a possible solution (you are part of that effort…). Either option works. This is a recommendation for authors to consider. Thanks, Himanshu (ciena corp) -------- Forwarded Message -------- Subject: IETF WG state changed for draft-ietf-spring-cs-sr-policy Resent-Date: Mon, 20 Jan 2025 08:52:25 -0800 (PST) Resent-From: alias-boun...@ietf.org<mailto:alias-boun...@ietf.org> Resent-To: aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>, bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>, j...@joelhalpern.com<mailto:j...@joelhalpern.com>, pengshup...@huawei.com<mailto:pengshup...@huawei.com> Date: Mon, 20 Jan 2025 08:52:11 -0800 From: IETF Secretariat <ietf-secretariat-re...@ietf.org><mailto:ietf-secretariat-re...@ietf.org> To: draft-ietf-spring-cs-sr-pol...@ietf.org<mailto:draft-ietf-spring-cs-sr-pol...@ietf.org>, spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> The IETF WG state of draft-ietf-spring-cs-sr-policy has been changed to "In WG Last Call" from "WG Document" by Joel Halpern: https://datatracker.ietf.org/doc/draft-ietf-spring-cs-sr-policy/ Comment: This starts the working group last call for this draft. There was sufficient engagement and interest to justify issueing this call. Even so, we need to see support to pass the last call. Please comment, preferably with explanations, as to your support or opposition to handing this draft to our AD for processing. Silence is not consent. This call will end at the end of the day on Monday, Feb 3. _______________________________________________ spring mailing list -- spring@ietf.org<mailto:spring@ietf.org> To unsubscribe send an email to spring-le...@ietf.org<mailto:spring-le...@ietf.org>
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
