Thanks Ketan,

Will update the draft accordingly to clarify the points stated below. Happy to 
continue discussion and carry this as independent work until then.

Cheers,
Amal.

From: Ketan Talaulikar <ketant.i...@gmail.com>
Sent: Saturday, April 27, 2024 2:31 AM
To: Shah, Himanshu <hs...@ciena.com>
Cc: Karboubi, Amal <akarb...@ciena.com>; spring@ietf.org; z...@cisco.com; 
cschm...@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 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

Reply via email to