Re: [Detnet] comments on draft-ietf-detnet-oam-framework-06

Greg Mirsky <gregimirsky@gmail.com> Tue, 04 October 2022 16:00 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 E2398C14CE2B; Tue, 4 Oct 2022 09:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.094
X-Spam-Level:
X-Spam-Status: No, score=-1.094 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_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 xMUGN_0LDQTt; Tue, 4 Oct 2022 09:00:04 -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 C11AEC1522B8; Tue, 4 Oct 2022 09:00:03 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id 25so11503244lft.9; Tue, 04 Oct 2022 09:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=M4S9jlr38T7QzcwEPwky+4Hk4uH3If8O3LMW59/iTnE=; b=mKyHy6UO7LNwld6TjAd0OmZW6+3DQHYfHZPlQtx0/yjubbrEAkLaweFR2IdR4oW2G3 qIBuvofFkcJh/Yth40EJeTMZVeDfTuQUlDFgp0yIfd72fvklBnHXAMiq0kuK6riWmFEY /WIW7jlnwaRf/3RS7SYPJPj3R6nP7cKtVALsSnCgh/0Qwaa/SMQiZgdiGkHAH56xWNII bP7FuqNVmUooDVwAy/uAQwnW0Ave6wdto7XEFXJS32WX+668p03dHHfKcNQomPdaCBO3 Rqaq2GdznAG+Id79rGVKGgxTRQeyUke8gc2hGvAJxVnmyY9UBJ5LvD7jF3sQk2skpVTg O8gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=M4S9jlr38T7QzcwEPwky+4Hk4uH3If8O3LMW59/iTnE=; b=o14l09/4Wg7hMvJSc3Gx7+lyKceuLUHJSVMO7RR6QCWAgMy+lyoL+c/9DqmaeTQOwr 4tcjEFcluHJdrG/RZBBrgtjGFP9wR7vi99asiC0q1CDdD3eYgxFawVO5jVKLs/T8sujL 65aL64EaRN30eFvOvWQYOkOdQS2+CD0+YNMa28NGi//CNK+aR8HKCNXmtD3Xi7gQekKK Cu5NT+Zxq0tqWHq7YJJPbrbDtt9mCedZxQtlDNqXm0wVes4wSLAku5lfnhgIN2thlzqf V5Vwnxe6iBR5VNg+7wf1Z4WZdkam832tjQlQcDAynZ0jNrxSG2MqrnBEbfR7rAw1aCX0 VIsg==
X-Gm-Message-State: ACrzQf2ZWLOgW8aWNw65TdID3pnT416ema7g5qFQUHPjaelEOYC67bif /G44rnTZnUAFuEGtv3j0QpciSR5hPE4J8Y5FVfY=
X-Google-Smtp-Source: AMsMyM7U3ZmCMl/vuTf2Mpyyw6Tuw0RDh33BQozeZR3KPJGbMez34VRa9Dd8eJFb4xRv+z4FXaAuU37bYh/RyLWLE9s=
X-Received: by 2002:ac2:47e1:0:b0:4a2:40e5:781a with SMTP id b1-20020ac247e1000000b004a240e5781amr3081027lfp.335.1664899201161; Tue, 04 Oct 2022 09:00:01 -0700 (PDT)
MIME-Version: 1.0
References: <0d9b80ac-cdbf-3586-ebde-8fc4a4e7c8ec@labn.net> <CA+RyBmW=6Xv2+KgKzAu0yEm1AkXXOCxvWDk1MsC-2k9cCUOhzA@mail.gmail.com> <a2964bfa-45a8-4b94-276d-285df2d43317@labn.net> <CA+RyBmVEW7xy3hPB0ZQt5GbFLJyFeVd0mZZMpJV5PJJkwMgKxg@mail.gmail.com> <4a21be7f-d06b-dfb2-7a59-e14149a16796@labn.net> <CA+RyBmVFSH9D2aaC6Pqr6JdPhyUb8GatCnCVKXFZe9Et_MmuYw@mail.gmail.com> <aa011709-5c03-9fc7-4f05-70c5bd3f19df@labn.net>
In-Reply-To: <aa011709-5c03-9fc7-4f05-70c5bd3f19df@labn.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 04 Oct 2022 08:59:49 -0700
Message-ID: <CA+RyBmW_9uNbaaqhPj1n0dJtA5pCxgC0rcvQ=nMMdPoo2JNeCw@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: draft-ietf-detnet-oam-framework@ietf.org, DetNet WG <detnet@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000791bb005ea378d01"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/cOm295dD-Qt8q8fD2P2nFJoyH5s>
Subject: Re: [Detnet] comments on draft-ietf-detnet-oam-framework-06
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: Tue, 04 Oct 2022 16:00:09 -0000

Hi Lou,
I've switched the reference as you suggested (also removed the unnecessary
I've introduced). I've updated the text to reference the DetNet Control
Plane with "controller" as an example.
Many thanks for your patience and help.

Attached are the diff and the working version of the draft.

Regards,
Greg

On Mon, Oct 3, 2022 at 1:17 PM Lou Berger <lberger@labn.net> wrote:

> Greg,
>
> I suggest you instead reference RFC8655, the Deterministic Networking
> Architecture. It uses consistent capitalization for the "DetNet Controller
> Plane" term.
>
> I think you still have a few more instances of " centralized/central"
> controller to clarify.
>
> Thanks!
>
> Lou
> On 10/3/2022 4:08 PM, Greg Mirsky wrote:
>
> Hi Lou,
> apologies for missing the normative verbs and necessary updates to "DetNet
> controller plane" terminology. I've added the reference to
> draft-ietf-detnet-controller-plane-framework
> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-02> as
> Informational. A minor question about the capitalization of "DetNet
> controller plane". It seems like the draft uses
> capitalization interchangeably. I've used only lower case in the OAM draft.
> Please let me know if that is acceptable.
>
> Attached, please find the diff and the new working version of the draft.
>
> Regards,
> Greg
>
> On Fri, Sep 30, 2022 at 5:17 AM Lou Berger <lberger@labn.net> wrote:
>
>> Hi Greg,
>>
>> see below. I think the version you sent doesn't address everything
>> discussed below.
>>
>> Also - this is important -  please update the draft with a current email
>> address for Georgios as his current address bounces. If you don't have one,
>> he must be moved to contributor.
>> On 9/28/2022 12:47 PM, Greg Mirsky wrote:
>>
>> Hi Lou,
>> thank you for your quick response and helpful suggestions to improve the
>> document. I've applied them all. As usual, I've attached the diff to
>> highlight all the updates and the working version of the draft.
>> RE: the number of authors on the first page. I agree with the response
>> you've proposed. I hope that IESG will thoughtfully consider this case.
>>
>> Regards,
>> Greg
>>
>> On Wed, Sep 28, 2022 at 4:52 AM Lou Berger <lberger@labn.net> wrote:
>>
>>> Hi Greg,
>>>
>>>     Thanks for the response/update -- please see below.
>>> On 9/27/2022 5:52 PM, Greg Mirsky wrote:
>>>
>>> Hi Lou,
>>> thank you for the review, comments, and helpful suggestions. Please find
>>> my notes and responses inlined below under the GIM>> tag. Attached is the
>>> working version of the draft and the diff highlighting all updates.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Fri, Sep 23, 2022 at 11:13 AM Lou Berger <lberger@labn.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> In preparing my shepherd write up, I noticed a few minor/editorial
>>>> points that should be addressed before submission for publication to
>>>> the
>>>> IESG.
>>>>
>>>> - Number of authors:
>>>> The IESG requires justification for more than 5 authors listed on the
>>>> font page.  This document has 6.  Is anyone willing to move to
>>>> contributor? If not, can you provide a justification for more than 5
>>>> authors
>>>>
>>> GIM>> I believe that all authors, in the course of developing this
>>> document, provided essential contributions.
>>>
>>>
>>> The question that needs to be answered in the Shepherd write up is as
>>> follows:
>>>
>>>
>>> 13. ... If the total number of authors and editors on the front page
>>>     is greater than five, please provide a justification.
>>>
>>> Do you want me to just say?
>>>
>>>     The authors believe all listed have provided essential contributions
>>> in the course of developing this document.
>>>
>>> Keep in mind the IESG pushes back hard on more than 5 authors. If the
>>> authors have a stronger justification, can you (authors) provide it.
>>>
>> I will try, but I expect that we will receive strong push back on this.
>>
>>
>>
>>>> - Inclusion of conformance boilerplate (Section 1.3) and conformance
>>>> language.
>>>>
>>>> Generally informational documents do not include the conformance
>>>> boilerplate or related language.  For example, there is none in the
>>>> DetNet framework, RFC8939.  On the other hand RFC 4377, OAM
>>>> Requirements
>>>> for MPLS Networks, does.
>>>>
>>>> Is there really a need for such in this document? If you do, the scope
>>>> of the requirement needs to be clear. (E.g, the requirements are on
>>>> future solutions "DetNet OAM solutions MUST..." or "solutions providing
>>>> DetNet OAM MUST..."). Or perhaps just a statement to this effect at the
>>>> end of section 1.3 or start of section 6.
>>>>
>>>  GIM>>  I propose appending Section 1.3 with the following:
>>>    The requirements language in Section 6
>>>    applies to future implementations of DetNet OAM.
>>>
>>> How about
>>>
>>> The requirements language is used in Section 6 and applies to future
>>> implementations of DetNet OAM.
>>>
>> I still see requirements terms in sections other than 6 in the version
>> you sent out, e.g.,
>>
>>   3.  Operation
>>
>>    OAM features will enable DetNet with robust operation both for
>>    forwarding and routing purposes.
>>
>>    It is worth noting that the test and data packets MUST follow the
>>    same path, i.e., the connectivity verification has to be conducted
>>    in-band without impacting the data traffic.  Test packets MUST share
>>    fate with the monitored data traffic without introducing congestion
>>    in normal network conditions.
>>
>>
>>>> Section 3-5 I really don't see the need for conformance language in
>>>> this
>>>> section.
>>>>
>>> GIM>> Upon reviewing the last paragraph, propose to remove it altogether:
>>> OLD TEXT:
>>>    DetNet OAM mechanisms SHOULD allow a fault detection in real time.
>>>    They MAY, when possible, predict faults based on current network
>>>    conditions.  They MAY also identify and report the cause of the
>>>    actual/predicted network failure.
>>>
>>>
>>>>
>>>> - Section 3.4, s/NOT RECOMMENDED/expected
>>>>
>>> GIM>> We've discussed this and propose the following update:
>>>  OLD TEXT:
>>>    DetNet is not expected to use multiple paths or links, i.e., Equal-
>>>    Cost Multipath (ECMP) [RFC8939].  As the result, OAM in ECMP
>>>    environment is outside the scope of this document.
>>> NEW TEXT
>>>    DetNet is not expected to use Equal-Cost Multipath (ECMP) [RFC8939].
>>>    As the result, DetNet OAM in ECMP environment is outside the scope of
>>> this
>>>    document.
>>>
>>>
>>>> - Section 5.2
>>>> Can you rephrase/clarify the following sentence.  I frankly have no
>>>> idea
>>>> what is meant by it:
>>>>
>>>>      We need to provide mechanisms to patch the network
>>>>     configuration.
>>>>
>>> GIM>> Thank you for pointing out this sentence to us. It is not really
>>> related to OAM but seems more in place in a discussion of the management
>>> plane. Hence, propose removing the sentence.
>>>
>>>>
>>>> That's it!
>>>>
>>> The above all looks good -- thanks!
>>>
>>> GIM>> In the course of addressing your comments, we've come up with
>>> several more editorial updates. Please let us know if these are helpful:
>>> In Section 4:
>>> OLD TEXT
>>>    *  per path to detect misbehaving path when multiple paths are
>>>       applied.
>>> NEW TEXT
>>>    *  per path to detect misbehaving path(s) when multiple paths are
>>>       used for service protection.
>>>
>>> In Section 5, prepend the following new text to the first paragraph:
>>> NEW TEXT:
>>>    Service protection (provided by the DetNet service sub-layer) is
>>> designed
>>>    to cope with simple network failures, and it mitigates the immediate
>>> reaction
>>>    of the DetNet controller to network events.
>>>
>>> What about the case where a controller is not used? Do you perhaps mean
>>> "DetNet Controller Plane"?
>>>
>> Note this is a general comment: The document mentions controller in many
>> places.  To be consistent with the DetNet Architecture the document should
>> allow for any 'Controller Plane' solution.  This should be easily fixed,
>> starting in section 2.
>>
>> Thank you,
>>
>> Lou
>>
>> Lou
>>>
>>>
>>>
>>>> Thank you,
>>>> Lou
>>>>
>>>