Re: [RTG-DIR] RtgDir Early review: draft-ietf-detnet-oam-framework

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Wed, 01 February 2023 09:49 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07DBC15DD6A; Wed, 1 Feb 2023 01:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 uWTPMevwHlcS; Wed, 1 Feb 2023 01:49:50 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 27C93C15C509; Wed, 1 Feb 2023 01:49:50 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id u7so6127142ilg.4; Wed, 01 Feb 2023 01:49:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F/Djn2mW1lQ9vRMpjke7/uvgfYi2/KRMuoXlyYJR8Qc=; b=MxKfQ/GrCGevWcJCRJdY+EdqJfiZiNWB8TAVLWrRYd2s3JjWBzwiuRLip6HMY4mTCM GSuED6K2XOaTCsuGoy1Xj3XT6fvxOXSA39iRm1P0heFLqrj4l/yQJNwehrTb9J0TCevk zkfrvNYqgcV/H/vgpZWwFD6JM0iP63P1KnwkwQriuqPTgWWXnTO45z6+mTkMfSYh2swN aI/nFNFbyrclGo6qGdklFEJViQLClpS8rNawD525EPyy91Mw7upxz2CFoN0fon36RK7p ZhDFopg55r60UX4o/dYWNjvWqmZvSoTnznXdVP7EBhu4LBEUn/H0qTpB7aQYNkJmvC6t S+SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=F/Djn2mW1lQ9vRMpjke7/uvgfYi2/KRMuoXlyYJR8Qc=; b=ovqLRUVs7LyyFEjeZNvpcgabUnQSZ+YRUSuUv2ft18cCm2tICvX3EJG5wNTUuJ+S0r GGgxlx+z8gGV8ZF0nNSZwtgtsZz/LRxQLLiDulW6byd0qNlyXhUvIWs+HVVcB6I4vdyh tVVjNEOmI4D4Hr1LiIbEGBZniThN8IIGBuWpWOWFFEmEvgNZ00CIET3BoIKHnGr6lV0B 6JK0guWi787MHZzYyziFByS435hGoctR6O4Peewdh386OLoZmAPEl5bY93FUGgeS2/LF 8JmOXQz6/elHGPd8JFc62yaDdIJov+4u0Wpu6tzcd23+OpCRDamKjM2zueZe8RkAi/nw dQIg==
X-Gm-Message-State: AO0yUKXI6kAA3KrOiCX0Uipb8sEaibxU3OXGLns3Y2zNZkKtsicKN2BH Dad5vAD8Cj7s8UHO5BBLSuBtOf4q0prT5xt+lAU=
X-Google-Smtp-Source: AK7set+XpCvf3lpxwUGG7aN9rBjGHwVSA1tYMEHkjyK60iho7i51n3SvQvYHcBUkCCWeVXDHogV/WFb1RNoE+To4BN0=
X-Received: by 2002:a05:6e02:1909:b0:310:dd97:397 with SMTP id w9-20020a056e02190900b00310dd970397mr438790ilu.105.1675244989024; Wed, 01 Feb 2023 01:49:49 -0800 (PST)
MIME-Version: 1.0
References: <CABUE3XnFjW=BXpEn6NGz+oMv82CYtk7SYtUoewOvesp3xM2GBw@mail.gmail.com> <CA+RyBmUutELOsTKaM9WykuaHPMQAzL84iSPcNkP2J4XkPCbkXg@mail.gmail.com>
In-Reply-To: <CA+RyBmUutELOsTKaM9WykuaHPMQAzL84iSPcNkP2J4XkPCbkXg@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Wed, 01 Feb 2023 11:49:37 +0200
Message-ID: <CABUE3X=hrh9KdG4Zr9r=YrR1c5vDdiWDS2HJa95b64cpS5Tw3g@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: DetNet Chairs <detnet-chairs@ietf.org>, detnet-ads@ietf.org, draft-ietf-detnet-oam-framework@ietf.org, rtg-dir@ietf.org, DetNet WG <detnet@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/Z0KlYk7BeKfWKnbkXQxF85_i3DU>
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-detnet-oam-framework
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2023 09:49:51 -0000

Dear Greg,

Thanks for considering my comments.
I believe the suggested changes resolve my comments.

Cheers,
Tal.

On Tue, Jan 31, 2023 at 10:42 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Tal,
> many thanks for your thorough review and thoughtful comments. Please find our responses below under the GIM>> tag. Also, the attached diff highlights the proposed updates.
>
> Best regards,
> Greg
>
> On Thu, Jan 19, 2023 at 2:32 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
>>
>> Hello,
>>
>> I have been selected to do a routing directorate “early” review of this draft.
>> https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/
>>
>> The routing directorate will, on request from the working group chair,
>> perform an “early” review of a draft before it is submitted for
>> publication to the IESG. The early review can be performed at any time
>> during the draft’s lifetime as a working group document. The purpose
>> of the early review depends on the stage that the document has
>> reached.
>>
>> For more information about the Routing Directorate, please see
>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>
>> Document: draft-ietf-detnet-oam-framework-07
>> Reviewer: Tal Mizrahi
>> Review Date: January 19th, 2023
>> Intended Status: Informational
>>
>> Summary:
>> This document is basically ready for publication, but has nits that
>> should be considered prior to being submitted to the IESG.
>>
>> Comments:
>>
>> The document summarizes the OAM requirements of DetNet networks. The
>> document provides a good background of the necessary OAM components
>> and presents the requirements of the OAM solutions.
>>
>>> Issues:
>>>
>>> - It would be helpful if the abstract would say that the target
>>>
>>> audience of this document is the DetNet working group members, and is
>>>
>>> intended to be used as a set of requirements for future work in the
>>>
>>> DetNet working group.
>>>
>>> GIM>> Thank you for the suggestion. Would adding the following sentence be helpful?
>>>
>>> NEW TEXT:
>>>
>>>    The document will
>>>
>>>    be used in future work that defines the applicability of and extension
>>>
>>>    of OAM protocols for a deterministic network.
>>>
>>>
>>> - Section 3 - Operation:
>>>
>>>   - For each of the sections 3.2-3.7 it would be helpful if you could
>>>
>>> specify how PREOF affects each of these functions. For example,
>>>
>>> continuity checking: what happens if MEP A and MEP B are two PREOF
>>>
>>> endpoints - is continuity checking performed individually for each of
>>>
>>> the PREOF paths, or is PREOF transparent to the CC?
>>>
>>> GIM>> Thank you for your thoughtful suggestion. We've added notes in Sections 3.2 and 3.3. As CC and CV are used in DetNet forwarding sub-layer, PREOF does not affect them. Section 3.4 notes that route tracing, i.e., ping and traceroute, can be used to discover PREOF capabilities. Other sections added text referencing CC, CV, and ping/traceroute. Do these changes clearly describe the interaction between PREOF and OAM?
>>>
>>>   - "information is collected and sent using the DetNet Controller
>>>
>>> Plane" - isn't it collected by the management plane? It may be worth
>>>
>>> clarifying in the document the exact breakdown between the management
>>>
>>> plane and the controller plane in the context of this document.
>>>
>>> GIM>> Section 4.4.2 of RFC 8655 defines the DetNet Controller Plane as the aggregation of Management and Control Planes. Thus, based on the interpretation of the DetNet Controller Plane, the management plane plays the essential role in collecting OAM information.
>>>
>>>
>>> - Section 8 - Security Considerations:
>>>
>>>   You may want to mention that specifically, the security
>>>
>>> considerations of OAM in the context of DetNet are discussed in
>>>
>>> Section 9 of [RFC 9055].
>>>
>>> GIM>> Thank you for the suggestion. Done.
>>>
>>>
>>> Nits:
>>>
>>> GIM>> Thank you for your careful review and pointing out these nits. Fixed them all. Please see in the attached diff.
>>>
>>> - Section 2.1 [RFC8655]  ==> Section 2.1 of [RFC8655]
>>>
>>> - Maintenance Intermediate endPoint (MIP) ==> [according to IEEE
>>>
>>> 802.1] Maintenance Intermediate Point (MIP)
>>>
>>> - In-band OAM is an active OAM is considered ==> In-band OAM is an
>>>
>>> active OAM considered
>>>
>>> - therefore, PM is a key topic ==> please add "PM" to the acronym list
>
> GIM>> Done
>>>
>>> - DetNet service sub-layer functions using a sequence number. ==>
>>>
>>> DetNet service sub-layer functions use sequence numbers for PREOF.
>
> GIM>> Agree, thank you.
>>>
>>> - Control Plane / Controller Plane - please be consistent, or clarify
>>>
>>> the difference between the two terms.
>>>
>>> GIM>> As noted above, the DetNet Controller Plane is viewed as the aggregation of the management and control planes. The reference to the control plane is specific to the use of the distributed control model.
>
> - perfromence metris ==> performance metrics
> - systemto ==> system to
> GIM>> Done and done.
> - downstream MEP ==> the term is used without definition
>  GIM>> Updated text as follows:
>
>    1.   It MUST be possible to initiate a DetNet OAM session from a MEP
>         located at a DetNet node towards MEP(s) downstream from that
>         DetNet node within the given domain at a particular DetNet sub-
>         layer.
>
>