[bess] Re: Inverse multi-layer OAM
Robert Raszuk <robert@raszuk.net> Wed, 19 March 2025 16:21 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: bess@mail2.ietf.org
Delivered-To: bess@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8E0A8EF0703 for <bess@mail2.ietf.org>; Wed, 19 Mar 2025 09:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Fk8LTvaBvzp for <bess@mail2.ietf.org>; Wed, 19 Mar 2025 09:21:04 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 68A17EF06F1 for <bess@ietf.org>; Wed, 19 Mar 2025 09:21:04 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-ac2963dc379so15920866b.2 for <bess@ietf.org>; Wed, 19 Mar 2025 09:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1742401263; x=1743006063; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2Y1djQucE+ETgynCoIxO3mtiJKog4qc4yEWd4W/TRpI=; b=IbFSBrDoi1piCGF2pmoJnFs2RKBWw/HAGAfW5yF5cQXHNC0cBkmJIEQqi1h9nqW9Tq 2748ar+zb2V4Ey+123ePGCTV7GnVh89XBDUxGjvkxEoIcZbXOJXhhBY7UutxcditNlwV 2dXot/W/TCeN2NVQiXBm/aI02YaZNSkOkeyKXSgPudrA8YjdPAn3V4vMNeTKlbtZEyaW a8asxkSh9SNoi+2WSyFeyfbxFCxKVCX6qehYm0UA+PmnGA3VjH7z8V0PWVFpCWEAqgCV 3XbUuXk07cahtXB1C8FrNdVYE7EZjXAEgg8VzZFOuwgcMgNCQFf69MPG6FmQX1hSS3Hv I3XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742401263; x=1743006063; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2Y1djQucE+ETgynCoIxO3mtiJKog4qc4yEWd4W/TRpI=; b=UE894vy1pGDmdAqpuD/sYwqGYOgS3BfqHLSjOoIpNNMh+Biv6NOsSQALH+yCs5ikU+ ifgDkRh/rCgDuPutOn/y//uLRRy76VHSq9GKpELF8cAvDsfd/ymHPe19iN8GzVcshh+Y N7RYr9r5Gc7TY9N0UnQTO823tqFeLImhSh4exRiBT2Ia+93lUq+l1Yqr1FozJN6j0J6Y B8d3/BbOaG15Kb04PNuUAouX2sqtXnhUgA/HeA++hk5cvWjPs9siF331dWBgXpr21cu4 am1pQcsz/Dk8sJPyQHKkqpG4G9Ua5NOhcRzrIf+U3mAx+qAzpJ45eLC8v6HvLpXP5M6Y VisA==
X-Forwarded-Encrypted: i=1; AJvYcCWAV/1rwOAQTsq0x5hmWCbh+pIH0z1degctFuJ2naTSGHlpB2t0jpyeX8CPC7qjB17/B47q@ietf.org
X-Gm-Message-State: AOJu0YxXzRTSB+/FUigmlFhxlXMEzP5T8OuJoHJneF22rlv2euT5ml0f xBDOs7f8pD3bUz22EzDugIqKVL8LdO4enymUIHEmhZ9W4ZO7o/ebUbkxJlDf5feJZ205GV4tDP6 Iv5jryUseWp5cLg7JFfkvdbkgBoDqC01DoZzVeQ==
X-Gm-Gg: ASbGncv8YjqxyMlFU4Z8DyqMbQSYQ78cG2PjkuVSZFNsJ0/EErz5xsHa6rCzGdZFVDz XXFG40RRskQVFhobWVmf2A7IMe8QwPXoXOvLdM+DsDVwCwUuGaz3+1kty6KQrqdKLt7vvk8eYQb Dtk1WSLc8Bz7WmgR2NN+zpF1LY6pw=
X-Google-Smtp-Source: AGHT+IHmKa+E4FNeeEs3KtT9B3rTyIkBplthp/dGLJftPb9XI+vqqsXEkXZJeF4FxgcPDUBlsJgNaJ8eQyYsFRVT0UE=
X-Received: by 2002:a17:907:d7c7:b0:abf:68b5:f798 with SMTP id a640c23a62f3a-ac3b7a9bc3amr433907766b.9.1742401263050; Wed, 19 Mar 2025 09:21:03 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmWh8aShHPz4NaJxmtZvoTjhjH2Ecw1SAcE0VD7N3KwNdg@mail.gmail.com>
In-Reply-To: <CA+RyBmWh8aShHPz4NaJxmtZvoTjhjH2Ecw1SAcE0VD7N3KwNdg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 19 Mar 2025 17:20:51 +0100
X-Gm-Features: AQ5f1Jp5x7NdabQAwbF0XBx_1NQ9sXu0UZHhp0h17NxS64z2QAknvgsyQ5n4dMo
Message-ID: <CAOj+MMGs-vUwV8V2ieGUF9zYFoRcP6q8emnVKhj9o5vJccD4-A@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000057418d0630b468bf"
Message-ID-Hash: L4Y5U2XPISV4WN4DGXWODHPAXX7RUCBV
X-Message-ID-Hash: L4Y5U2XPISV4WN4DGXWODHPAXX7RUCBV
X-MailFrom: robert@raszuk.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Shah, Himanshu" <hshah@ciena.com>, BESS <bess@ietf.org>, draft-karboubi-spring-sidlist-optimized-cs-sr@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [bess] Re: Inverse multi-layer OAM
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/UheAEl2HWF4agAFewCWnKJSK7mk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>
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 <gregimirsky@gmail.com> wrote: > Hi Himanshu, > > Thank you for the presentation of > draft-karboubi-spring-sidlist-optimized-cs-sr > <https://datatracker.ietf.org/doc/draft-karboubi-spring-sidlist-optimized-cs-sr/>. > 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 -- bess@ietf.org > To unsubscribe send an email to bess-leave@ietf.org >
- [bess] Inverse multi-layer OAM Greg Mirsky
- [bess] Re: [**EXTERNAL**] Inverse multi-layer OAM Shah, Himanshu
- [bess] Re: Inverse multi-layer OAM Robert Raszuk
- [bess] Re: Inverse multi-layer OAM Greg Mirsky
- [bess] Re: Inverse multi-layer OAM Joel Halpern
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Shah, Himanshu
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Joel Halpern
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Shah, Himanshu
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Greg Mirsky
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Shah, Himanshu
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Zafar Ali (zali)
- [bess] Re: [**EXTERNAL**] Re: Re: Inverse multi-l… Shah, Himanshu
- [bess] Re: Inverse multi-layer OAM Zafar Ali (zali)
- [bess] Re: Inverse multi-layer OAM Shah, Himanshu