Re: [Detnet] DetNet OAM drafts progressing

Greg Mirsky <gregimirsky@gmail.com> Thu, 09 June 2022 20:24 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54198C157B4F; Thu, 9 Jun 2022 13:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.536
X-Spam-Level:
X-Spam-Status: No, score=0.536 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, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSZdBdzQiMxd; Thu, 9 Jun 2022 13:23:55 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33562C157B5C; Thu, 9 Jun 2022 13:23:55 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id h23so39716078lfe.4; Thu, 09 Jun 2022 13:23:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KfqlZ9ICI8iZ2Vj6YON7nG5zQbRlNLOSAgx+jkgNPII=; b=Cvj+CljrE+0H4TmRiC6uuWnKIv3cHve0dTVSHS6rtjoTb/K7gjuJh7+cEhhzkLf28P wKSlkvviJJkHYMHwIlvFNHXRVounvmyMQ/ke7y6nZFkoElUnDdp+ofvynplze/EiNqGi kteGq9sCYI8PPol0N0UOzmF3RpU4YQEE7HNhDm7gfGP0dSPhX4UyRbwKUwivOQ4cZVJM WZB+coo3/wSu1zZTMBYPuF9rJq2x93FkaVL9BOv3RppiwtzssprKVDDO7r3gWgeQ7A2/ 1ZyvSZqDtvIO3us/vmLtWVdMcnY4gxKMsU7ei3tNZTelV48Y/aAF4vrhwCEKnH4YnN8c Mp7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KfqlZ9ICI8iZ2Vj6YON7nG5zQbRlNLOSAgx+jkgNPII=; b=NAT5ROOxA/4iBGi7xKZbJgCsORnhf4nFbJothR/FSLDpvQ097Efjwq1YH2Tz2h+WSV 358/a8Z5YBawTxB3ViG/ftndF2RAvD9FTdYn/WxQOhI7War0Oo+JPf1btS795IqYiMBg b2mNt5z15smlCQfLuH5f0g4/Z7Uxqx9jQC6RU2m7ftJErI5Os+hsvHH5W48sgaUJPgwE Nr/e07lZWEiX5k7vVcd1Z9BrdbwJdIOyIhQusboR0PK5x6aN10MKYt27WcmHU/WoD3r/ EB29TDhqE6WO2vC/8OiO4Hv3pU1E9Vzq74XDj1qBfysMCEp/B6mEkMw6dy/aZM8HJGJG BjVQ==
X-Gm-Message-State: AOAM5338NIrmMPUPTgP4vHbhPL7L6LpS7FbaIfugasFZ3I/fr3LecISk a586HOOFBhV8FAHA8zAdAHFtVm+uRwHmc0uKkTg=
X-Google-Smtp-Source: ABdhPJxdSp17MMBEAGxxna/YztHHSWudyPJkkG2cs9LXwp/05tqu5CzxnOfglFhQ9mmUOmQiERVdr41irA1brgmvOF8=
X-Received: by 2002:a19:5f5e:0:b0:479:3fd7:e6fd with SMTP id a30-20020a195f5e000000b004793fd7e6fdmr14384654lfj.209.1654806231890; Thu, 09 Jun 2022 13:23:51 -0700 (PDT)
MIME-Version: 1.0
References: <AM0PR07MB53474166BDEDDD4114193E94ACA59@AM0PR07MB5347.eurprd07.prod.outlook.com> <5D91EA22-DFC0-4630-8A89-04384E732B5B@unistra.fr>
In-Reply-To: <5D91EA22-DFC0-4630-8A89-04384E732B5B@unistra.fr>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 09 Jun 2022 13:23:40 -0700
Message-ID: <CA+RyBmXj5Y=ZTTibObmC19bWz-g5hmGzepYW_ntF6Ove4BZreA@mail.gmail.com>
To: Fabrice Theoleyre <theoleyre@unistra.fr>
Cc: Balázs Varga A <balazs.a.varga@ericsson.com>, "draft-ietf-detnet-oam-framework@ietf.org" <draft-ietf-detnet-oam-framework@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000a044e405e109991a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/8fFOhP-WAhrcbm8zgT-3hCcHI6c>
Subject: Re: [Detnet] DetNet OAM drafts progressing
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2022 20:24:00 -0000

Hi Balazs and Fabrice,
thank you for the discussion. I agree with the solutions proposed by
Fabrice. I've updated the draft and welcome your comments. Attached, please
find the diff and new version of the draft. Would these updates be
acceptable?

Regards,
Greg

On Wed, Jun 8, 2022 at 1:13 AM Fabrice Theoleyre <theoleyre@unistra.fr>
wrote:

> Dear Bala'zs,
>
> Please see online my comments.
>
>
> In today’s call we have discussed two topics regarding section 5
> “Maintenance”
> of the OAM framework document
> (https://www.ietf.org/archive/id/draft-ietf-detnet-oam-framework-05.txt):
>
> Sorry, I zapped the interim meeting. It was too late when I noticed it.
>
>
> A) Section 5.1.  Replication / Elimination
> “ … Each MEP
>    will decide to trigger the packet replication, elimination or the
>    ordering process when a set of metrics passes a threshold value.”
> We may need some clarification here. Changing of PREOF functions is
> a task for the DetNet controller, the MP (MEP or MIP) will only trigger
> the controller to take actions. An update might be needed with better
> phrasing.
>
>
> Actually, this scenario is rather for wireless links. When the link
> quality degrades (under a threshold), some additional features may be
> triggered locally. These features have been installed by the controller,
> but the node decides by itself to activate them.
> However, that’s rather for RAW. We can probably safely remove it from the
> detnet draft.
>
>
> B) Section 5.3.  Soft transition after reconfiguration
> The need for such a sub-section regarding OAM may worth for some
> discussions. PREOF itself is a tool for soft transition. It may the
> implementation of PREOF that allow the soft configuration changes,
> not the related OAM tools. So, the question for the WG: do we need
> OAM specific soft transition? If yes, for what (any example)?
>
> Any comments/views are appreciated.
>
>
>
> I had the feeling that the monitoring process has to be adapted after a
> soft reconfiguration.
> Else, states may be inconsistent.
>
> However, a metric may perfectly reflect the SLO of a complex path, or
> individual subpaths as well.
> Thus, I don’t find a relevant example where it would be required.
>
> Best regards,
> Fabrice
>
>