Again, what you are referring to as a “general practice”, nothing wrong with that. We are not opposing that at all, in fact that is probably works the best in all other cases. However, for the use case that we have in CS-SR-Optimized, inverse multi-layer OAM works the best. AND it can co-exist for other use cases that can continue to use multi-layer OAM in traditional manner.
Again, SR-Policies that are created for CS-SR with compressed SIDs, it will use inverse multi-layer OAM. For those operators who wishes to also use the network for traditional services, we would recommend the link 1hop-BFD OAMs to be set at 10ms for 3 miss – still good convergence within 50ms for all other traffic and services while be able to handle the CS-SR optimized use case simultaneously. Thanks, Himanshu From: Greg Mirsky <gregimir...@gmail.com> Date: Thursday, March 20, 2025 at 11:45 AM To: Shah, Himanshu <hs...@ciena.com> Cc: Zafar Ali (zali) <z...@cisco.com>, Joel Halpern <j...@joelhalpern.com>, Robert Raszuk <rob...@raszuk.net>, draft-karboubi-spring-sidlist-optimized-cs...@ietf.org <draft-karboubi-spring-sidlist-optimized-cs...@ietf.org>, SPRING WG <spring@ietf.org> Subject: [**EXTERNAL**] Re: [bess] Re: Inverse multi-layer OAM I am sorry for misaddressing my first note. I removed BESS from the thread. Yes, the proposed OAM arrangement will, although both local and e2e recovery mechanisms will be deployed. Making e2e more aggressive, in my opinion, doesn't matter here, as that saves and avoids nothing. Also, in the usual multi-layer OAM scheme, the e2e detection period is set sufficiently longer not only for the link-layer failure detection time but to allow for the local protection mechanism to complete its work. For example, if link-layer detection is 10 ms, then e2e is usually set at 300 ms. I don't think that can be applied in the inverse multi-layer OAM case. I believe that what is presented creates two disconnected OAM layers that may be cause for some unpredictable scenarios. Regards, Greg On Thu, Mar 20, 2025 at 11:27 AM Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>> wrote: Yes you did. Concerns are misplaced. The thread has progressed and it is unfortunate that – * Greg wrongfully commented on BESS WG list. This thread SHOULD NOT BE in BESS WG email list. It belongs in SPRING WG list. The draft was discussed in SPRING WG. * It would really help if one was to comment on the running thread rather than middle of the thread causing the forks. Please take this discussions to the SPRING mailing list. Thanks, Himanshu From: Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>> Date: Thursday, March 20, 2025 at 11:19 AM To: Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Cc: Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>, BESS <b...@ietf.org<mailto:b...@ietf.org>>, draft-karboubi-spring-sidlist-optimized-cs...@ietf.org<mailto:draft-karboubi-spring-sidlist-optimized-cs...@ietf.org> <draft-karboubi-spring-sidlist-optimized-cs...@ietf.org<mailto:draft-karboubi-spring-sidlist-optimized-cs...@ietf.org>>, Zafar Ali (zali) <z...@cisco.com<mailto:z...@cisco.com>> Subject: [**EXTERNAL**] Re: [bess] Re: Inverse multi-layer OAM Hi I agree with Joel (as I also mentioned during the Spring session). Thanks Regards … Zafar From: Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Date: Thursday, March 20, 2025 at 10:42 AM To: Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>>, Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> Cc: Shah, Himanshu <hs...@ciena.com<mailto:hs...@ciena.com>>, BESS <b...@ietf.org<mailto:b...@ietf.org>>, draft-karboubi-spring-sidlist-optimized-cs...@ietf.org<mailto:draft-karboubi-spring-sidlist-optimized-cs...@ietf.org> <draft-karboubi-spring-sidlist-optimized-cs...@ietf.org<mailto:draft-karboubi-spring-sidlist-optimized-cs...@ietf.org>> Subject: [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. The implied information race conditions seem an invitation to trouble. Yours, Joel On 3/19/2025 11:14 PM, Greg Mirsky wrote: Hi Robert, I wholeheartedly agree that local and e2e OAM are complementary tools in an operator's toolbox. Usually, a multi-layer OAM is constructed so that e2e provides the network with a safety net. In that manner, local repair of a link failure is expected to restore services before the failure is detected on the e2e level. As I understand it, the proposal uses a different scheme. According to it, e2e network detection is expected to be more aggressive than the link-level OAM. To me, that's an unusual arrangement. As for performance monitoring, although some performance metrics can be measured spatially to compose e2e metrics, e2e performance monitoring is easier to deploy in many environments. Regards, Greg On Wed, Mar 19, 2025 at 11:21 PM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: Hi Greg, I am very much in support of end to end path assurance. And by assurance I mean not only e2e liveness but also e2e loss, delays, jitter etc ... The main reason is that link layer failures (even if done on every link in the path) does not provide any information about transit via network devices. And those can be subject to packet drops, selective packet drops (brownouts), delays and jitter via box fabrics in distributed systems etc ... So to me even if e2e is slower then local link detection it still very much a preferred way to assure end to end path quality. Sure some of them is done at the application layer, but then it is done mainly for statistics and reporting. Doing it at network layer opens up possibilities to choose different path (quite likely via different provider) when original path experiences some issues or service degradation which with link by link failure detection is invisible to the endpoints. I think at the end of the day those two are not really competing solutions but complimentary. And of course end to end makes sense especially in deployments when you can have diverse paths end to end. Cheers Robert On Wed, Mar 19, 2025 at 4:58 AM Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote: Hi Himanshu, Thank you for the presentation of 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!LbhSBMT2wYNpD-4Kr0InSvL5Ni-XWsSQRQWODSn5AS0CFfsX3cH6SbQKWDUbxUEookTWNw$>. If I understood your response to Ali correctly, the proposed mechanism is expected to use more aggressive network failure detection than the link layer. If that is correct, I have several questions about the multi-layer OAM: * AFAIK link-layer failures are detected within 10 ms using a connectivity check mechanism (CCM of Y.1731 or a single-hop BFD) with a 3.3 ms interval. * If the link failure is detectable within 10 ms, what detection time for the path, i.e., E2E connection failure detection, is suggested? What interval between test probes will be used in that case? * Furthermore, even if the path converges around the link failure before the local protection is deployed, the link failure will be detected, and the protection mechanism will be deployed despite the Orchestrator setting up its recovery path in the network. If that is correct, local defect detection and protection are unnecessary overheads. Would you agree? Regards, Greg _______________________________________________ BESS mailing list -- b...@ietf.org<mailto:b...@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org> _______________________________________________ BESS mailing list -- b...@ietf.org<mailto:b...@ietf.org> To unsubscribe send an email to bess-le...@ietf.org<mailto:bess-le...@ietf.org>
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
