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

[Carlos Pignataro <[e-mail]>]

Dear Greg,

Thank you for the input.

It appears that much of what you write below was already discussed at
https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/

Am I to understand you might be keen on continuing using "in-band OAM" with
different meanings depending on the WG or context?

Please find some follow-ups inline below:

On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky <[e-mail]> wrote:

> 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.
>
> CMP: This document intends to Update RFC 6291, a product of the IETF about
OAM language usage, with support from its lead editor.

>
>    - 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.
>
> CMP: Not really, as explained in the draft already, clearly. See
https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/

>
>    - "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?
>
>
CMP: The document already contains that analysis. It explains why those
terms cannot be reliably understood consistently and unambiguously.

>
>    - 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..
>
> CMP: I am not sure I follow what you mean here -- but, (1)
https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2)
**There is no band**!!!!


>
>    - 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?
>
> CMP: That is a question for the chairs, but this document originating in
opsawg will need to have ietf-wide review...

>
>    - 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?
>
>
CMP: All of these seem to have been already discussed.


>
> 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.
>
>
CMP: This is a WG Adoption, Greg...


> 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.
>
>
CMP: Hopefully we catch all those mis-uses in time!!!

Carlos.


>
> Regards,
> Greg
>
>
>
> On Wed, Apr 10, 2024 at 1:06 PM Henk Birkholz <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsawg
>>
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg
>