Hi Christian, The link up/down events are automatically covered by the proposal and do not require manual intervention/coordination. The statement “We assume these changes are done during maintenance-windows and under the supervision of an SDN controller and can be coordinated with the PCE directly." was meant for changes carried as new configuration either new links being created, or a property change of an existing link itself (e.g cost, affinity , downshifted capacity, etc). Such changes would require re-evaluation of pinned LSPs and would be needed for MPLS-TP or CS-SR based policies to make sure the original intent is still preserved. I have taken section 7.3 and 8.2 in CS SR policy draft to allude to this type of intervention as well. We also believe that these configuration-based changes events are not as frequent.
Such Controller role providing automation and coordination between different layers and workflows is not uncommon and is beneficial for self-optimizing network. I will update the section in the draft to make it clearer. We can continue to discuss more and happy to pursue this work independently until then. Cheers, Amal. From: Christian Schmutzer (cschmutz) <cschm...@cisco.com> Sent: Tuesday, April 23, 2024 2:24 PM To: Shah, Himanshu <hs...@ciena.com>; Karboubi, Amal <akarb...@ciena.com> Cc: Christian Schmutzer (cschmutz) <cschm...@cisco.com>; spring@ietf.org; Ketan Talaulikar <ketant.i...@gmail.com>; Zafar Ali (zali) <z...@cisco.com>; Christian Schmutzer (cschmutz) <cschmutz=40cisco....@dmarc.ietf.org> Subject: [**EXTERNAL**] Re: Clarifications for draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt Hi Amal and Himanshu, Related to the Q&A during last meeting and the following paragraph in draft-karboubi-spring-sidlist-optimized-cs-sr "We assume these changes are done during maintenance-windows and under the supervision of an SDN controller and can be coordinated with the PCE directly." I think we should have a discussion on what (new or existing) protocol mechanisms can be used to eliminate any dependency on human intervention or a proprietary SDN controller function for coordinating link up events with the PCE to ensure traffic is never forwarded outside the intended path. The use case(s) of your proposal seem quite specific and the approach fairly different to the general solution defined in draft-ietf-spring-cs-sr-policy, so I think it is better to keep this work separate. cheers Christian On 12.04.2024, at 00:08, Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>> wrote: Tagging Ketan, Zafar, Christian and Andrew – who provided some feedback in the previous IETF meetings on this draft. We believe we have addressed their comments/concerns and would appreciate their feedback on such, in order to make progress. If there is no further input, we would assume that proposal is good-to-go and ask for WG adoption. @Christian Schmutzer (cschmutz)<mailto:cschmutz=40cisco....@dmarc.ietf.org> /others/all – Would like your opinion on to pursue this work with consolidation to your draft or as separate activity. Thanks, Himanshu From: Karboubi, Amal <akarb...@ciena.com<mailto:akarb...@ciena.com>> Date: Friday, April 5, 2024 at 11:32 AM To: spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>> Cc: Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>> Subject: Clarifications for draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt Hello, We have presented draft https://datatracker.ietf.org/doc/draft-karboubi-spring-sidlist-optimized-cs-sr/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-karboubi-spring-sidlist-optimized-cs-sr/__;!!OSsGDw!JuOOWdWJpAKFPyfqzj8D3LWBSpQuSOjTNxgPYzaQbKQuSSH0geOrNV4dqy5Abzvk00UOD8PTJONfl3da0JlA$> in Brisbane last month and would like to continue discussion on mailing list and address few concerns that were raised during the presentation. 1. Dealing with TI-LFA during fiber-cut/link failures: the idea is to have head end detect end-to-end failures before any local repair / IP convergence occurs. One way to achieve / implement this is to have the CCV protocol (e.g. S-BFD or STAMP) run for these SR Policies at a lower interval than the IP link BFD. This will not impact non-CS SR policies which will continue to benefit from TI-LFA local repairs with same detection/repair time as before. Note that CCV is mandatory for CS SR policies, so the only new addition we are imposing is regarding its detection timer (i.e. inverted hierarchical fault detection – e2e fault is detected before 1-hop fault). 2. There was concern about double failures : This is dependent on protection/ restoration scheme the operator may choose, Traditional SR-Policy schemes can handle multiple failure by using N (where N>2) candidate paths , The proposed draft leverages the same. 3. There was concern about operational complexity : We believe the concern about operational complexity is misplaced. The proposed scheme provides simpler controller/node interaction as compared to sprinkling BSIDs throughout the network to handle MSD capacity of each node. We have successfully implemented and deployed the solution with a few utility providers that has complex networks. In fact, BSID was the first approach we looked in to and soon discovered that we needed simpler solution. Please let us know if further details/clarifications are required or if I missed some of your concerns. Looking fwd to discussing this further. Thanks, Amal.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
