In line..

Thanks,
Himanshu


From: Zafar Ali (zali) <zali=40cisco....@dmarc.ietf.org>
Date: Thursday, March 20, 2025 at 12:07 PM
To: Shah, Himanshu <hs...@ciena.com>, 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>, Zafar Ali (zali) 
<z...@cisco.com>
Subject: Re: [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-layer OAM
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.

Himanshu> Totally agree. We are not recommending disabling TI-LFA

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.

Himanshu> Look we have deployed this solution and the networks have been 
running fine. So all these concerns are somewhat theoretical.

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.

Himanshu> There is no disagreement here either. We are NOT saying that 
uncompressed persistent adj-sids based path does not work. That absolutely 
works. But CS-SR optimized with compressed SID list ALSO works – we have 
deployed it. Not sure what other proof is needed. It is OK for some to remain 
skeptical with theoretical or passion based reasons, it does not change the 
fact in the field.

Thanks,
Himanshu

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

Reply via email to