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

Greg Mirsky <gregimirsky@gmail.com> Thu, 20 October 2022 23:15 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 20D56C14F692 for <detnet@ietfa.amsl.com>; Thu, 20 Oct 2022 16:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.095
X-Spam-Level:
X-Spam-Status: No, score=-6.095 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_HI=-5, 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=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 diR6BIK2SLeh for <detnet@ietfa.amsl.com>; Thu, 20 Oct 2022 16:15:19 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 D7E82C14F738 for <detnet@ietf.org>; Thu, 20 Oct 2022 16:15:18 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id b1so2129353lfs.7 for <detnet@ietf.org>; Thu, 20 Oct 2022 16:15:18 -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:message-id:reply-to; bh=k+ZkL3se3qS+BHYallOsDXwWYcCsHZNPxCZ2TgJttM0=; b=jQejOxxRIwGS8RcjWUd0BhbqTof5a3Ni7F8k+1egXWVGf3v7KtjiWdL7IqbrbpAY0f 4wiYrFff8psh4j3Cs7cXttj+e0S1GmWZ1atjjrtdBTbgiEdKTLinaziEyHZ0EXLSJ6Up VzQW3BMVYMZaDJTnwkhP7hPkbOZkX3Ld/P21LRfKO9H+RUyFU2UJHt9e0sIh5DPuRWLm tAteweVyMzgoCZBcGr41h6dAoxt4Pjf/Pw8f2cMfrqj6NaWP95ZiK2cF8WQxx7MA6E0J rGioVrA7sGUWnoHmFXGlb/gEAhXc+C3jA7Cgm77v2EJhhyUql+7tvoqVCJIeJ9U7kQoC g3Hw==
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=k+ZkL3se3qS+BHYallOsDXwWYcCsHZNPxCZ2TgJttM0=; b=IGkUjWcamzfeVUGADfKuKV5852WXwv6YMdxGBjk+FOjzjuPh8/UiT1dXnTiiedR1JE v0ugONI5LEugvL+K11tz9gfjJTCiZBjTgOBoqWI9c7Hlx3zfvKJVKfEEW3PFHBmqHQen JCv11pfs7hYMnF0sKwb4i1IlWkScWkPJLO4oX9VbHlac+9VzfiSCSjaJtXZSyU4RsMfq bPmhr3KBkpMMTE83TOGwD3CuEPoDfSHLsP+Fj4KoEcSMqBlHScNXg/MZD/HCUmsj3wxl MxpDpU+MKSyX/U/9mAExB6ZRnIYwXMNbMKAaBSzD76dxuguYprLe3MinfMgXqWZoItNP 5lLQ==
X-Gm-Message-State: ACrzQf32hp9HJuLacSM8GEiFvbg4FoEdTfWQfX1uZCjjRQXljnb9TS2i Z72wLbvgt1AZNNn1eUOPnOma7prOxkFoHAvsVX35nIwhTVk=
X-Google-Smtp-Source: AMsMyM78bCHmn3j/zyxtS0fIeUkpYq6et8L39R6tIz3WGlcpnoaFarm/XzyX1fNwVXrlfpExqEPt26aQc7gM1K6CH8M=
X-Received: by 2002:ac2:58fb:0:b0:4a2:3eb5:b089 with SMTP id v27-20020ac258fb000000b004a23eb5b089mr6036594lfo.310.1666307716303; Thu, 20 Oct 2022 16:15:16 -0700 (PDT)
MIME-Version: 1.0
References: <AS8PR07MB8298C35F4BFC3B9BF74227C4F2239@AS8PR07MB8298.eurprd07.prod.outlook.com> <d482aeccbf074657aa3079e144816aaf@huawei.com>
In-Reply-To: <d482aeccbf074657aa3079e144816aaf@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 20 Oct 2022 16:15:05 -0700
Message-ID: <CA+RyBmWMGHosqrbUE5jrc53Vw1JGuG0oJ=fD7MLwt7uR_ENbEg@mail.gmail.com>
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
Cc: Janos Farkas <Janos.Farkas=40ericsson.com@dmarc.ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Content-Type: multipart/mixed; boundary="00000000000084eaf405eb7f7f29"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/ME_YK-uTKXS_JAgHGFsNZVVCcYA>
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: Thu, 20 Oct 2022 23:15:24 -0000

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
>