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 <gregimir...@gmail.com> 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 <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 >> > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
