Hi Himanshu All the customers I spoke with wants to run SR Circuit Style on a common IP network infrastructure (think $$$). Hence, turning off TI-LFA is off the table.
In order to have e2e detection win the local detection, you will have to beat the transmission delays. You mentioned the main goal for you to implement this work around is to avoid use of transit policies means that you have many hops. Also, like Joel mentioned, think about the race condition. The architecturally correct solution is to use unprotected Adj SIDs and use transit BSID * Aside: With uSID, I have hardly seen the need for transit BSIDs for most implementations from different vendors I am aware of. Thanks Regards … Zafar From: Shah, Himanshu <hshah=40ciena....@dmarc.ietf.org> Date: Thursday, March 20, 2025 at 11:16 AM To: Greg Mirsky <gregimir...@gmail.com> Cc: Robert Raszuk <rob...@raszuk.net>, BESS <bess@ietf.org>, draft-karboubi-spring-sidlist-optimized-cs...@ietf.org <draft-karboubi-spring-sidlist-optimized-cs...@ietf.org> Subject: [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-layer OAM C&P some texts from the earlier mail that got short circuited.. -- We recommend that for the purpose of networks that want to take advantage of Eligibility mechanism for intent verification especially for fault detection scheme, the e2e fault detection Timers are kept more aggressive than local link fault detection timers. This is a better choice than turning off TI-LFA at each node. For example - 1hop timers at 10 ms interval with 3 miss and s-bfd at 5ms interval or 10ms with 2 miss. This is just an example. It’s a choice, if one wants e2e protection to take higher precedence over local protection. As I mentioned, this behavior is more preferable to transport centric service providers that we have talked to. -- I believe this addresses your comments below. Do note that we have successfully deployed this solution in running networks for multiple years. Thanks, Himanshu From: Greg Mirsky <gregimir...@gmail.com> Date: Thursday, March 20, 2025 at 11:00 AM To: Shah, Himanshu <hs...@ciena.com> Cc: Joel Halpern <j...@joelhalpern.com>, Robert Raszuk <rob...@raszuk.net>, BESS <bess@ietf.org>, draft-karboubi-spring-sidlist-optimized-cs...@ietf.org <draft-karboubi-spring-sidlist-optimized-cs...@ietf.org> Subject: Re: [**EXTERNAL**] Re: [bess] Re: Inverse multi-layer OAM Hi Himanshu, I agree with Joel that inversing multi-layer OAM is a tricky and untested proposal. Consider the usual multi-layer OAM arrangement. Link failure detection is within 10 ms using 3.3 ms intervals. You stressed that e2e uses more aggressive network failure detection. Would that be based on 1 ms intervals for multi-hop BFD? AFAIK, in the usual multi-layer OAM, the e2e network failure detection is based on 100 ms to ensure that the local protection mechanism can converge without firing e2e recovery. However, in the case of the inverse multi-layer OAM you presented, it appears that both recovery mechanisms, i.e., local and e2e, will be deployed. In my opinion, that is inefficient, confusing, and unnecessary. Am I missing something here? Regards, Greg On Thu, Mar 20, 2025 at 10:46 AM Shah, Himanshu <hs...@ciena.com> wrote: > Disagree. > > We have discussed the motivation (for prioritizing e2e protection over > local protection) in the draft. > > It serves the purpose without having to disable TI-LFA on each node – not > a desirable option. > > > > Thanks, > > Himanshu > > > > > > *From: *Joel Halpern <j...@joelhalpern.com> > *Date: *Thursday, March 20, 2025 at 10:41 AM > *To: *Greg Mirsky <gregimir...@gmail.com>, Robert Raszuk < > rob...@raszuk.net> > *Cc: *Shah, Himanshu <hs...@ciena.com>, BESS <bess@ietf.org>, > draft-karboubi-spring-sidlist-optimized-cs...@ietf.org < > draft-karboubi-spring-sidlist-optimized-cs...@ietf.org> > *Subject: *[**EXTERNAL**] Re: [bess] Re: Inverse multi-layer OAM > > It seems rather counter-intuitive to want to try to repair things > end-to-end faster than one expects local devices to detect local failures
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
