Hi All, I agree with Greg on his points. I think a lot of terms do not get wide consensus. RFC7799 did the same thing. Why this draft could do better than it? I have a suggestion not to define new terms any more. Just use descriptive language to classify OAM tools in different ways.
Cheers, Tianran ________________________________ Sent from WeLink 发件人： Greg Mirsky<gregimir...@gmail.com<mailto:gregimir...@gmail.com>> 收件人： Joe Clarke (jclarke)<jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> 抄送： opsawg@ietf.org<mailto:opsawg@ietf.org> 主题： [OPSAWG]Re: WG LAST CALL: Guidelines for Charactering "OAM" 时间： 2024-10-27 01:27:13 Dear All, I read the draft. Although I find it easy to read, I don't see its publication in its current form to be helpful to the IETF community and the networking industry in general. Furthermore, despite several calls for a broader discussion by WGs outside the OPSAWG, I don't find any threads in the mail archive. It seems like the lack of a wider discussion of the proposed changes in terminology related to OAM protocols and methods contradicts the intended BCP status of the document as not sufficiently discussed by the IETF community involved in the development of OAM 's Fault management (FM) and Performance measurement (PM) protocols. I encourage reaching out to those WGs who are actively involved in developing and extending these OAM mechanisms. For example, IPPM WG is the recognized center of competence in developing OAM PM protocols. Many WGs in the Routing Area define various network layers that require specification of the applicability of the existing FM and PM OAM protocols. AFAICS, these groups have been using terminology that this document proposes to uplift and replace with a very different set of terms. That would be confusing and detrimental to the work of these groups. Please find my notes on the draft below. Introduction * I disagree with the assertion that RFC 7799 "does not substantially discuss OAM". OAM is the collection of methods and protocols in the FCAPS network management model and framework that fulfill 'F' (fault management) and 'P' (performance monitoring) functions. As RFC 7799 defined the principles of classification of performance measurement methods, it is an integral part of any discussion related to OAM. In-Band and Out-of-Band OAM * What is the basis for the following assertion? Within the IETF, the terms "in-band" and "out-of-band" cannot be reliably understood consistently and unambiguously. Perhaps that is because the document was not discussed with DetNet WG, which defined these terms in RFC 9551<https://datatracker.ietf.org/doc/rfc9551/>. Additionally, these terms are accepted and consistenly used in OAM documents by RAW and BIER WGs (as noted in Section 2 of the draft). The argument that interpreting these terms may require familiarity with the context is too weak for the IETF community, as it is customary to expect that a reader of an IETF document is familiar with the terminology specific to the subject and established in prior publications. * The use of the term "conrguent" is really confusing for anyone familiar with its interpretation in geometry: identical in form; coinciding exactly when superimposed Let me share a simple expmple to demonstrate where term "congruent" fails. Imagine a network with ECMP as below: C----------D / \ A----------B E------------F \ / G-------------I Graphs A-B-C-D-E-F and A-B-G-I-E-F are congruent as one can be superimposed onto another using mirror reflection. However, if OAM packets follow the former while data traverse the latter, an operator would get information that does not reflect the state of the monitored data flow. * I find the assertion that newly defined "In-packet OAM" is analogous to how DetNet OAM defines in-band OAM and "Dedicated-Packet OAM" is analogous to how "out-of-band" is used in DetNet OAM a clear misrepresentation that, AFAICS, is the result of not discussing this document outside of OPSAWG. * Furthermore, IPPM WG discussed and adopted the draft that combines the use of IOAM and STAMP. How would such a method be characterized in relation to the packet? * RE: the change from "In-band" to "In-situ" terminology. The proponents of using "In-band" missed that a specially constructed test packet, i.e., active OAM per RFC 7799, can also be in-band with the monitored data flow. Once that was cleared, then the interpretation of 'I' in IOAM was changed. * Please provide a reference where RFC 9551<https://datatracker.ietf.org/doc/rfc9551/> Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) "uses Combined OAM". AFAIK, it does not. * And note that BIER WG in draft-ietf-bier-oam-requirements also uses in-band/out-of-band terminology in a manner consistent with its use by DetNet and RAW WGs. Active, Passive, Hybrid, and Compound OAM * RFC 7799 defines a hybrid performance measurement method as combining elements of passive and active measurement methods. Given that, a combination of active and passive is already characterized as hybrid per RFC 7799. Also, combinations that include a hybrid method are hybrid methods. Hence, the introduction of the term "Compound" is superfluous. In conclusion, this document is not ready for publication in its current form. It must be discussed with groups that are recognized centers of competence in the field of network OAM protocols, both FM OAM and PM OAM. The feedback from these discussions must be reflected in the document, and then its value must be reassessed. Regards, Greg On Mon, Oct 21, 2024 at 9:25 AM Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: This starts a two week WG LC https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/. The authors have been polled and there is no known IPR on this work that has been disclosed at this time. Please post comments and thoughts on this document’s readiness to the list. We ultimately want to run publication of this in conjunction with the on-path telemetry document. Thanks to Greg Mirsky who agreed to shepherd this draft. The WG LC will run until November 4. Thanks. Joe _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org>
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
