Re: [Detnet] WG Last Call: draft-ietf-detnet-mpls-oam-08

Greg Mirsky <gregimirsky@gmail.com> Tue, 29 November 2022 16:49 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 5BF24C1522DA for <detnet@ietfa.amsl.com>; Tue, 29 Nov 2022 08:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CYV1vvUNVDB3 for <detnet@ietfa.amsl.com>; Tue, 29 Nov 2022 08:49:20 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 7467CC14F73A for <detnet@ietf.org>; Tue, 29 Nov 2022 08:49:20 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id c2so10208070qko.1 for <detnet@ietf.org>; Tue, 29 Nov 2022 08:49:20 -0800 (PST)
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:message-id:reply-to; bh=3NaAbEsGYnpG6V9qY3nndL7xmwWyCM2WHmxXC9+jRag=; b=lKSCL5rkWXU4lkouOzmQ0P1JcgMz0jbSL1l3lM1OIWHSEO2zNP5M525GSUHUBp0h0R dN7M43D7vQA1kPe/CP86uQ8LlmZMlSIyPzQ2X2wjTXqvLFD5fVhN9084gX5aWGjwT2Uv 0/HLDViMPYELm1LkwMwy5zH0MnwPQiIFlwpkznALmZMZeuoBQhWcVHanIojOUY2JwRRZ IG+jtliEnyxCbN/fNSUcYOC7o6akwYJsEapJ+ABoGQPXtYZ/T56gbP00t5HVZ6Kiu+YJ ujve6tRbBRkJYbbSLB3QRAukc2tWTxn58Oq4+kAPF7K190u4PQe8u2/vtAawwdjNisDA Arcg==
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:message-id :reply-to; bh=3NaAbEsGYnpG6V9qY3nndL7xmwWyCM2WHmxXC9+jRag=; b=S9Q66hSgTJ/YvldOy8QGFUVQtxzwaI54p9+SHJ4RFzYpe8qxCk+7K7OtdGafFkpgeB 35yaCK2lu9d8kYSITdbiPVZQbWVs9ho4eyi/FHID4LIGB1WrA7dOVp+VFDcYrTDWTZeE 33+kwhXWXB/MAhuATQWgCDGOFIf4S+8Wlj5Bk94n1w9qfPR77agOwRqhSyj2gSNNG9FG fVsUWtkMjUXGaLhTG56gvfNtbdQAJXg1yjRbFCpj+im6P5/Vp9P/T5lI+ljeZ+C0ZhBd uVHDEr6wmUgCGFw0pfBqe2Aebb8thY4eSUdVBMKqtgdi5paXl12ntGWOEninb2THJeoz dlmA==
X-Gm-Message-State: ANoB5pmLd9vd+9k7MR4Z7Z59n3IL+unpUK3S1vUUhbkytL1GzwXMBwIJ IPdJvNRlSzJNVrZOdLENx0aRtdRA31VN+fqOeRY=
X-Google-Smtp-Source: AA0mqf5PC7CogIav5w0aCGLiG67Sd+q6KnVTa6YB+il5TxeauJHx3HQM+wuWgLz91DwVBcARyRjnF11QKdTW5Q0fvqE=
X-Received: by 2002:a05:620a:103a:b0:6fa:324a:a9b5 with SMTP id a26-20020a05620a103a00b006fa324aa9b5mr50578128qkk.660.1669740559330; Tue, 29 Nov 2022 08:49:19 -0800 (PST)
MIME-Version: 1.0
References: <7a938109d69241b99ff3bb89db2eac67@huawei.com>
In-Reply-To: <7a938109d69241b99ff3bb89db2eac67@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 29 Nov 2022 08:49:08 -0800
Message-ID: <CA+RyBmVgGdv36XhM+18ozjcHKhVkMEcUwvgkXkDiLuzxLPFRHQ@mail.gmail.com>
To: Janos Farkas <janos.farkas@ericsson.com>
Cc: "detnet@ietf.org" <detnet@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000e7f0fe05ee9ec4e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/s3hBAvXxsCYVbnNsI_cRfDt9t2o>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-mpls-oam-08
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, 29 Nov 2022 16:49:22 -0000

Hi Janos,
it appears that all the comments we've received during the WG LC have been
addressed.  The authors greatly appreciate constructive comments and
thoughtful suggestions from Ethan and Tianran. Do you see the conclusion of
the WG LC on draft-ietf-detnet-mpls-oam? We're ready for the next steps in
progressing this work.

Regards,
Greg (on behalf of the authors)

On Fri, Nov 11, 2022 at 1:53 AM Tianran Zhou <zhoutianran@huawei.com> wrote:

> Hi Grey,
>
> Thanks very much for taking my suggestion.
>
> I am comfortable with all the changes.
>
>
>
> 3. “Channel Type - contains the value of DetNet Associated Channel Type.”
> This is confusing to me at first sight. It seem you are going to define a
> new channel type. I struggled a while before I understand finally. So it
> would be nice to revise the text.
>
> GIM>> I greatly appreciate your suggestions to clarify the definition of
> the Channel Type field. Could you kindly propose the clarification making
> it clearer?
>
>
>
> ZTR> I am not sure. Maybe “contains -> reuses” could be better? I think in
> somewhere you would better describe something like, the proposed fields are
> attached to existing ACHs as shown in figure *.
>
>
>
> Best,
>
> Tianran
>
>
>
> *发件人:* Greg Mirsky [mailto:gregimirsky@gmail.com]
> *发送时间:* 2022年11月9日 22:24
> *收件人:* Tianran Zhou <zhoutianran@huawei.com>
> *抄送:* Janos Farkas <Janos.Farkas@ericsson.com>; detnet@ietf.org
> *主题:* Re: [Detnet] WG Last Call: draft-ietf-detnet-mpls-oam-08
>
>
>
> Hi Tianran,
>
> I've uploaded the -09 version of the draft that includes clarifications of
> fields in the d-ACH as proposed in the text below. I greatly appreciate
> your feedback and comments about the updates and my responses to your
> questions.
>
>
>
> Kind regards,
>
> Greg
>
>
>
> On Fri, Oct 21, 2022 at 12:15 AM Greg Mirsky <gregimirsky@gmail.com>
> wrote:
>
> Hi Tianran,
>
> thank you for your questions and comments. Please find responses in-lined
> below tagged with GIM>>. Attached are the diff and a copy of the working
> version of the draft.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Oct 12, 2022 at 8:38 PM Tianran Zhou <zhoutianran=
> 40huawei.com@dmarc.ietf.org> wrote:
>
> Hi Authors,
>
>
>
> I read this draft and find it’s useful.
>
> I have several suggestions as follows.
>
> 1. I am not clear why existing PW OAM cannot be used directly for DetNet.
> I think there will be text to describe why 4 bytes are added, and also why
> each field, like node id.
>
> GIM>> As described in RFC 8655, DetNet headers may be needed to support
> DetNet service and forwarding sub-layers. Additional fields are added in
> support of OAM at the DetNet service sub-layer. Furthermore, we can note
> that a DetNet PW is more like an MS-PW, where DetNet service sub-layer
> functions are at the “segment” endpoints. However, DetNet service sub-layer
> functions operate per packet level (not per segment level). These
> per-packet level characteristics of PREOF require additional fields for
> proper OAM packet processing. Would the following update make it clearer:
>
> OLD TEXT:
>
>    DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in
>
>    [RFC4385].  Encapsulation of a DetNet MPLS [RFC8964] active OAM
>
>    packet is shown in Figure 3.
>
> NEW TEXT:
>
>    DetNet OAM, like PW OAM, uses PW Associated Channel Header defined in
>
>    [RFC4385].  At the same time, a DetNet PW can be viewed as a Multi-
>
>    Segment PW, where DetNet service sub-layer functions are at the
>
>    segment endpoints.  However, DetNet service sub-layer functions
>
>    operate per packet level (not per segment level).  These per-packet
>
>    level characteristics of PREOF require additional fields for proper
>
>    OAM packet processing.  Encapsulation of a DetNet MPLS [RFC8964]
>
>    active OAM packet is shown in Figure 3.
>
>
>
> The Node ID field is described in the draft as follows:
>
>
>
>       Node ID - is an unsigned 20 bits-long field.  The value of the
>
>       Node ID field identifies the DetNet node that originated the
>
>       packet.  Methods of distributing Node ID are outside the scope of
>
>       this specification.
>
>
>
> 2. There is no description for Level,  Flags, and Session fields on the
> meaning. I do not know how to use and how to extend.
>
> GIM>> Thank you for pointing out too minimalistic descriptions.  The
> following text is updated in the working version:
>
> OLD TEXT:
>
>       Level - is a 3-bit field.
>
> NEW TEXT:
>
>       Level - is a 3-bit field.  Level field is used to cope with the
>
>       "all active path forwarding" characteristics of the PREOF concept.
>
>       A hierarchical relationship between OAM domains can be created
>
>       using the Level field value.
>
> And another update:
>
> OLD TEXT:
>
>       Session ID is a four-bits field.
>
> NEW TEXT:
>
>       Session ID - is a 4-bit field.  Session field is used to distinguish
>
>       OAM sessions originated from the same node (a given Maintenance
>
>       End Point may have multiple simultaneously active OAM sessions).
>
>
>
> 3. “Channel Type - contains the value of DetNet Associated Channel Type.”
> This is confusing to me at first sight. It seem you are going to define a
> new channel type. I struggled a while before I understand finally. So it
> would be nice to revise the text.
>
> GIM>> I greatly appreciate your suggestions to clarify the definition of
> the Channel Type field. Could you kindly propose the clarification making
> it clearer?
>
> 4. You mentioned hybrid OAM a little bit in section 4. IMHO, it has
> nothing to do with this draft, including the solution, the format. So, I
> would suggest to clean up the hybrid OAM texts in this doc.
>
> GIM>> We've discussed and agreed with your suggestion. Removed the section
> in the working version.
>
>
>
> Best,
>
> Tianran
>
>
>
> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Janos
> Farkas
> *Sent:* Tuesday, October 11, 2022 10:23 PM
> *To:* detnet@ietf.org
> *Subject:* [Detnet] WG Last Call: draft-ietf-detnet-mpls-oam-08
>
>
>
> All,
>
>
>
> This starts working group last call on
>
> https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/
>
>
>
> The working group last call ends on October 25th.
>
> Please send your comments to the working group mailing list.
>
>
>
> No IPR has been disclosed against this document.
>
>
>
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!
>
> This is useful and important, even from authors.
>
>
>
> Thank you,
>
> János (DetNet Co-Chair & doc Shepherd)
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>
>