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> 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) <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> > *Date: *Friday, April 5, 2024 at 11:32 AM > *To: *spring@ietf.org <spring@ietf.org> > *Cc: *Shah, Himanshu <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
