Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

Greg Mirsky <gregimirsky@gmail.com> Sun, 14 April 2024 14:49 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21980C14F5F2 for <opsawg@ietfa.amsl.com>; Sun, 14 Apr 2024 07:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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 XCvF21eyfFUo for <opsawg@ietfa.amsl.com>; Sun, 14 Apr 2024 07:49:48 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 3BFA1C14F69E for <opsawg@ietf.org>; Sun, 14 Apr 2024 07:49:48 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6eb55942409so1565498a34.1 for <opsawg@ietf.org>; Sun, 14 Apr 2024 07:49:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713106187; x=1713710987; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/qLvhqIrWjcLEgZNLo/wUO7mMZs4Q709110pRZ25XFU=; b=d5CLS3LwSgQNNNsybHZlDPyILzdfJpTI3V/1C1Mo/wizHpl9ucolG6J64P16z53vRf a12DJCZ5acD4UzTptO1CYRRU/h6ZOnHf2cPbttt87XbdcRt4zk812vodEA/YSqAy2a0I vCF0pfpyeM4w23Z19iHGMTQJ9uPVZdIPtz1vw03rzjXX5Hnn50ZqmglGbUQ6+sw3HHI3 KLp2ACpDU5MQZ0gVBSATag3eATWzC5wyPh25EtUQSbFh5NI9F6xUsQ7b4impa9z76R62 v6UsTPOjX2Ab+vmShOfRxlu5NvEYGgS5NhgeIKdDqkFGXYq8huwPYXNCpEtj5ScXyqLY Z1HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713106187; x=1713710987; 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=/qLvhqIrWjcLEgZNLo/wUO7mMZs4Q709110pRZ25XFU=; b=lMUHjLBOxY/JIBzyGSeayFgLXrZXKg15WYdWeyt5hjz8j8+RTCiwNkiSfRwIvFa5Nb ftfPGzHDWOrqLSTfcnjl79dnsT5lkvh0Om2fdBQr1gLhFDmIdbHfXlDOPIdqyYp1JJaS WQ3ndPIdSif8AwtDGGgvaweBVjYM7Jpa7MSi6bUnBWkGwYd8n2h+i1oC05qIRFOhgHkD y/5CYkHR4biadhfK1gRLR2HKufhKaU+bRRcVqnMuRMN0C/5yV7MOccWtkocxgRcPP3nC /i3ShlA3Z7744vrBsnSK2UXaMzeLjsNTrLz74D1nOaGWE24mtjW5yAAKNRR/aVU8Qgp6 XA0Q==
X-Gm-Message-State: AOJu0YydUa7bUA7cJCwzzMSUeGrmXJrvHSZ+v3og5PLmdHdZwHImbhmh MxkEGaHFQ+0LHgJ7g0jUJhmSPX/mpmTiEeOte3hLhncj0i2GWisC5BuSQyFk2eRVEdH0FmfU1Ir B9gTuGT4kYggjEz6Jm7U0ACxgg5hwBdznn+I=
X-Google-Smtp-Source: AGHT+IEkf9uq1m1GZVzMj/H3YpTx7Doi38BPkhzXL0HaFYI7WpNCEEUgddO4woY8wbR99P9LILanF/22cWRmoU01IcE=
X-Received: by 2002:a9d:6286:0:b0:6ea:2b4c:945b with SMTP id x6-20020a9d6286000000b006ea2b4c945bmr8005135otk.20.1713106186867; Sun, 14 Apr 2024 07:49:46 -0700 (PDT)
MIME-Version: 1.0
References: <d75cddf8-8872-cb2e-fb13-82e2d978c9bb@ietf.contact>
In-Reply-To: <d75cddf8-8872-cb2e-fb13-82e2d978c9bb@ietf.contact>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 14 Apr 2024 16:48:46 +0200
Message-ID: <CA+RyBmXz9wHOq_R1u5Mv8fnjEQs11Xgn-x+2oxgtTjQ6oYi=0A@mail.gmail.com>
To: Henk Birkholz <henk.birkholz@ietf.contact>
Cc: OPSAWG <opsawg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb1d8906160f9d94"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/9KV5U0qhgSfqJh_T8wH7vL3he6E>
Subject: Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Apr 2024 14:49:52 -0000

Dear All,
I've read the latest version of the draft, Please find my notes and
questions below:

   - All SDOs that standardize methods and/or protocols in the field of OAM
   recognize that, in the FCAPS network management model, OAM is addressing
   the 'F' and 'P', i.e., Fault Management and Performance Monitoring methods
   and protocols. Furthermore, OAM is understood as a collection of
   various methods and protocols, rather than a single protocol, method, or
   tool. Hence, it seems like the document must use the same more granular
   approach in characterizing this or that OAM mechanism, including the
   possible variance in the application of that mechanism.
   - I was under the impression that the discussion about the unfortunate
   choice of the original extended form of IOAM, "In-band OAM", has been put
   to rest with the agreement to extend it as "In-situ OAM". Why bring that
   discussion back? To revisit the decision of the IPPM WG? If so, then, as I
   imagine, that must be discussed in the IPPM WG.
   - "Within the IETF, the terms "in-band" and "out-of-band" cannot be
   reliably understood consistently and unambiguously." That is a very strong
   and powerful statement that, in my opinion, requires serious analysis. For
   example, a survey of the IETF community that undoubtedly demonstrates the
   existence of multiple confronting interpretations that cannot be resolved
   by a mere wordsmithing. Can the authors cite such a survey and its results?
   - And closely following that statement "the terms are not self-defining
   any more and cannot be understood by someone exposed to them for the first
   time" seems to break the very foundation of IETF TAO - learn, learn, and
   learn. I find the expectation of a first-comer to any IETF discussion to be
   able to fully master all the dictionary and terminology of that group to
   be, in my experience, a misguided. Through years, I've been suggesting
   anyone interested in joining and contributing to IETF work to first read
   (drafts, RFCs) and, most of all, the mail archive. Probably, I've been
   wasting their time..
   - The following passage brings additional question:

The guidance in this document is to avoid the terms "*-band" and instead
find finer-granularity descriptive terms. The definitions presented in this
document are for use in all future IETF documents that refer to OAM, and
the terms "in-band OAM" and "out-of-band OAM" are not to be used in future
documents.


   - Is such an overreaching scope of the OPSAWG WG in its charter?
   - I found a number of references to DetNet OAM that, regrettably,
   misinterpreted documents approved by DetNet WG and some already published
   as RFCs. I can only encourage an open communication between the proponents
   of this work and the DetNet WG rather than an attempt to force something
   foreign to the essence of Deterministic Networking and the application of
   OAM in DetNet.
   - It appears that the term "Combined OAM", introduced in this document,
   allows for a combination of "Non-Path Congruent OAM" with
   "Equal-QoS-Treatment OAM". If that is the case, what do you see as the
   value of using such "combined OAM"?
   - In my reading of Section 3 and references to RFC 7799, I find it
   getting close to benign misinterpretation of RFC 7799:
      - Firstly, RFC 7799 appropriately discusses OAM methods and metrics,
      i.e., elements of OAM. Hence, because of, what seems like, a
      misunderstanding of how OAM is composed, the document dismisses RFC 7799
      even though that is the fundamental document with 16 references by IETF
      documents and more by documents in other SDOs.
      - In the definition of the "Compound OAM" it is suggested that a
      combination of Active and Hybrid OAM methods or of Passive and Hybrid OAM
      methods are distinct examples of Compound OAM. If that is the intention,
      how to reconcile that with the definition of a Hybrid OAM method in RFC
      7799:

   Hybrid Methods are Methods of Measurement that use a combination of
   Active Methods and Passive Methods, to assess Active Metrics, Passive
   Metrics, or new metrics derived from the a priori knowledge and
   observations of the stream of interest.

It does appear, that unless this document updates or obsoletes RFC 7799, a
combination of Active and Hybrid or Passive and Hybrid methods will still
be a Hybrid OAM method. Actually, according to the following assesment:
[RFC7799] adds to the confusion by describing "passive methods" as "out of
band". Following the guidelines of this document, OAM may be qualified
according to the terms described in Sections 2 and 3 of this document, and
the term "out of band OAM" is not to be used in future documents.

updating RFC 7799 is the intention of this document. Or am I missing
something here?


As the conclusion. Although the document is well-written, I don't find it
addressing a real problem, nor offering a viable, useful solution. Hence, I
consider this WG AP utterly premature given that the proposal was not at
all socialized outside OPSAWG group. I hope that the WG Chairs and
Responcible AD will discuss the situation with the leadership of IPPM WG,
as well as DetNet, MPLS, BFD, BESS, BIER WGs (to name some) that are
actively developing, enhancing OAM methods and protocols and could be
affected by this proposal.


Regards,
Greg



On Wed, Apr 10, 2024 at 1:06 PM Henk Birkholz <henk.birkholz@ietf.contact>
wrote:

> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
> >
> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
>
> ending on Thursday, May 2nd.
>
> As a reminder, this I-D summarizes how the term "Operations,
> Administration, and Maintenance" (OAM) is used currently & historically
> in the IETF and intends to consolidate unambiguous and protocol agnostic
> terminology for OAM. The summary includes descriptions of narrower
> semantics introduced by added qualifications the term OAM and a list of
> common capabilities that can be found in nodes processing OAM packets.
>
> The chairs acknowledge a positive poll result at IETF119, but there has
> not been much discussion on the list yet. We would like to gather
> feedback from the WG if there is interest to further contribute and
> review. As a potential enabler for discussions, this call will last
> three weeks.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>