Hi Tal, I have read the latest version of the draft, and I don't find that any of my concerns have been addressed. Let us continue the discussion.
Regards, Greg On Thu, May 15, 2025 at 9:14 AM Tal Mizrahi <tal.mizrahi....@gmail.com> wrote: > Hi Greg, > > Thanks again for your review, and for some additional comments you > sent us offline about an intermediate version you reviewed. > > We have revised the document in an effort to address the main comments > you raised. > > Link to the current draft: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization > > Diff compared to version 04 (which you previously reviewed): > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-04&url2=draft-ietf-opsawg-oam-characterization-06&difftype=--html > > Please let us know what you think. > > Thanks, > Tal. > > On Sun, Oct 27, 2024 at 1:27 AM Greg Mirsky <gregimir...@gmail.com> wrote: > > > > 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. 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 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> 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 > >> To unsubscribe send an email to opsawg-le...@ietf.org > > > > _______________________________________________ > > OPSAWG mailing list -- opsawg@ietf.org > > To unsubscribe send an email to opsawg-le...@ietf.org >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
