Re: [spring] Clarifications for draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt

["Shah, Himanshu" <[e-mail]>]

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=[e-mail]> /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 <[e-mail]>
Date: Friday, April 5, 2024 at 11:32 AM
To: [e-mail] <[e-mail]>
Cc: Shah, Himanshu <[e-mail]>
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.