Hi Med, thank you for sharing your thoughts about the draft. I've added my notes below under GIM>> tag.
Regards, Greg On Tue, Apr 16, 2024 at 2:01β―PM <mohamed.boucad...@orange.com> wrote: > Hi Greg, all, > > > > Having this discussion is by its own sufficient to justify why we need to > amend rfc6291 with terms that reflect recent needs/usages in a manner that > can be easily and generally visible to the target audience. > GIM>> I don't think that the proposed updates are in any way related to the scope of RFC 6291. In fact, they are only affecting RFC 7799, which is the product of the IPPM WG. > > > For example, Michael indicated that he wished he had a better name for > "Virtual In-Band OAM" (I still donβt digest what does that mean actually). > GIM>> I've read the definitions of 'in-band' and "out-of-band" in RFC 8994. I agree with these definitions with a note that "in-band" also includes sharing the same schedulers as the data flow(s) being managed/controlled using management/control plane. In other words, the management and control plane receive the same QoS as the data plane. I also indicated that I wished I had terms for the following when I edited > RFC 9451: > > - βOAM packet that exclusively includes OAM dataβ > - βOAM packet that includes user dataβ > > GIM>> RFC 7799, AFAICS, defines the first case as an active OAM, i.e., using specifically constructed synthetic packet. The second case - an example of hybrid OAM method as it combines elements of Active (inclusion of OAM-specific construct in a data packet) with Passive . Of course, RFC 9451 could have defined its own terms and explicitly list in Terminology section. > > > I think that we can leverage some definition entries in various documents > out there (detnet, for example) when this makes sense. Some of the existing > terms, although used in RFCs, fail to unambiguously convey the intended > meaning. I donβt think it is problematic to acknowledge that fact and > consider alternate terms. > GIM>> As I've noted before, a term cannot be expected to be self-explanatory. That is the responcibility of the authors, WG, and all of us to have explicitly defined dictionary being used in our documents. > > > Of course, this is a cross-WG effort and a pre-requisite I expect for it > is that the authors commit in soliciting the feedback from relevant WGs. > > > > I donβt think it is premature to consider adopting this work here in > OPSAWG. As you know, the content is not frozen given that this is simply a > call for adoption, not a Last Call. > GIM>> I think that we have different perspective and expectations of the process. That's is okay. I believe that WG Chairs and the Responcible AD will find the way forward to further advance the development of Internet and technologies that enable its continuous growth. > > > Cheers, > > Med > > > > *De :* OPSAWG <opsawg-boun...@ietf.org> *De la part de* Greg Mirsky > *EnvoyΓ© :* mardi 16 avril 2024 10:11 > *Γ :* Carlos Pignataro <cpign...@gmail.com> > *Cc :* OPSAWG <opsawg@ietf.org> > *Objet :* Re: [OPSAWG] π WG Adoption Call for > draft-pignataro-opsawg-oam-whaaat-question-mark-03 > > > > Dear Carlos, > > thank you for making my point even clearer. I do believe that a term may > have interpretation in different scopes - a document, a series of > documents, or across all IETF documents. RFC 9551 established the > interpretation of terms for all DetNet OAM documents. The document under > discussion, draft-pignataro-opsawg-oam-whaaat-question-mark, as I > understand its intention, is to establish the scope across all IETF > documents. That, IMHO, imposes on the decision already made by the DetNet > WG (and, AFAICS, shared by several other WGs). That is why I consider the > WG AP premature and encourage the authors to reach out across the WG and > Area boundaries to socialize the document more before taking any steps to > progress it. > > > > Regards, > > Greg > > > > On Tue, Apr 16, 2024 at 4:52β―AM Carlos Pignataro <cpign...@gmail.com> > wrote: > > Greg, > > > > Repeating something does not make it soβ¦ > > > > You had argued that those were definitions only within the context of > DetNet, and each context can have different ones. You really cannot have it > both ways. This is confusing. > > > > I-Ds follow causality β lots of things were approved to then be corrected. > > > > In-band β out-of-band β what do they really mean whenβ¦ > > > > There is no βbandβ > > > > > > > > C > > > > Thumb typed by Carlos Pignataro. > > Excuze typofraphicak errows > > > > On Apr 15, 2024, at 09:03, Greg Mirsky <gregimir...@gmail.com> wrote: > > ο»Ώ > > Hi Carlos, > > I have to repeat that the definitions of terms "in-band OAM", "out-of-band > OAM", and "on-path telemetry" > > In-band OAM: an active OAM method that is in band within the > > monitored DetNet OAM domain when it traverses the same set of > > links and interfaces receiving the same QoS and Packet > > Replication, Elimination, and Ordering Functions (PREOF) treatment > > as the monitored DetNet flow. > > > > Out-of-band OAM: an active OAM method whose path through the DetNet > > domain may not be topologically identical to the path of the > > monitored DetNet flow, its test packets may receive different QoS > > and/or PREOF treatment, or both. > > > > On-path telemetry: on-path telemetry can be realized as a hybrid OAM > > method. The origination of the telemetry information is > > inherently in band as packets in a DetNet flow are used as > > triggers. Collection of the on-path telemetry information can be > > performed using in-band or out-of-band OAM methods. > > > > have been adopted by DetNet WG, approved by IESG and published as part of RFC > 9551 <https://datatracker.ietf.org/doc/rfc9551/>. I believe that a > constructive approach would be to use the already accepted terminology, not > to attempt to negate what has already been achieved in building up the IETF > dictionary, particularly in the OAM area. > > > > Regards, > > Greg > > > > On Mon, Apr 15, 2024 at 2:00β―PM Carlos Pignataro <cpign...@gmail.com> > wrote: > > 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 > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
