Hi Himanshu, Apologies for the delay - been OOO. Thank you for the follow up descriptions below.
1. Thanks for the further explanation in text from the meeting discussion. Similar to Ketan's comment I think there would be benefit having this topic discussed in the document, as without the timer tuning requirement (or turning ti-lfa off) the outcome solution would risk not being feasible. Beyond that no additional comment on this item at this time and thanks again for the clarification. 2. True, N can be increased. I think my comment was more along the lines of requiring pce to signal eligibility incurs an additional failure risk scenario but as you mention N can be increased, so my concern is likely moot. 3. Thank you for the reply on this. I find the human-involvement for accurately pre-emptively describing new-links, timer manipulations, and eligibility control, in aggregate, to introduce the operational complexity, compared to just letting PCE distribute BSIDs as needed. However, evidently that is a trade off some may prefer. Differing opinions :) No further enquiries from my end on this item. Regarding document separation - agree with Ketan and Christian’s replies. It'll likely be better to currently keep this independent and work on it as a separate, parallel activity. Thanks! Andrew From: spring <spring-boun...@ietf.org> on behalf of Ketan Talaulikar <ketant.i...@gmail.com> Date: Saturday, April 27, 2024 at 2:31 AM To: Shah, Himanshu <hs...@ciena.com> Cc: Karboubi, Amal <akarb...@ciena.com>, spring@ietf.org <spring@ietf.org>, z...@cisco.com <z...@cisco.com>, cschm...@cisco.com <cschm...@cisco.com>, Christian Schmutzer (cschmutz) <cschmutz=40cisco....@dmarc.ietf.org> Subject: Re: [spring] Clarifications for draft-karboubi-spring-sidlist-optimized-cs-sr-00.txt Hi Himanshu, Thanks for taking the time to explain the specific deployment design that is required along with the prerequisites for the use of the solution proposed in draft-karboubi. I think it would benefit the WG if those considerations and details were updated in the document so that WG is able to better understand the proposed solution. That would provide a good basis for us to continue our discussions. On whether to merge this into the WG document or proceed as a separate draft, I believe it is best to work on it separately at this stage so it gets focussed review from the WG and all the details of the solution have been considered. Thanks, Ketan On Fri, Apr 12, 2024 at 3:38 AM 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
