Dear Greg, Thank you for your continued interest! Let’s work towards improving the document.
Net-net, there are a couple of places where there are potential editorial changes to improve clarity — as well as a lot of re-hashing. Please find some responses inline, as well as two top-level questions: 1. Do you think there might potentially be, or have you considered a conflict of interest between agreeing to be a document shepherd, and this set of strong views, uncompromising, that you had already shared <https://mailarchive.ietf.org/arch/search/?q=(text:(draft-pignataro-opsawg-oam-whaaat-question-mark)+OR+text:(draft-ietf-opsawg-oam-characterization))+AND+from:(Mirsky)>? 2. When you insist in using “in-band” to define different things, which “band” are you referring to? [please respond to the actual question of which “band” is it. No need to respond on the “define different things” part, that’s in-band below in the email :-)] > On Oct 27, 2024, at 12:26 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. CMP: This is incorrect. CMP: See for example posting in DetNet: https://mailarchive.ietf.org/arch/msg/detnet/SF9H7jF8MBkLq5segJjPHHMD6JU/ and your cross-posting https://mailarchive.ietf.org/arch/msg/detnet/HTySe1p6paiQGbTlTLUjY4MXjNA/ which included: CMP: Cc: Ops Area WG <opsawg@ietf.org>, IETF IPPM WG <i...@ietf.org>, mpls <m...@ietf.org>, spring <spr...@ietf.org>, DetNet WG <det...@ietf.org> CMP: So my first observation, is that you are demonstrating either a fragile memory or lack of search skills. This is not a judgement but an observation, since the search facility shows all the lists. CMP: Here’s spring: https://mailarchive.ietf.org/arch/msg/spring/byG9i-pvdgfn_F2Kp3jT9uX40h0/ CMP: Here’s IPPM: https://mailarchive.ietf.org/arch/msg/ippm/KQseRmMujO4aa3YEG0fhsPm2Xy4/ CMP: etcetera. CMP: The net of this outreach is that, when we test all these lists, we only find….. the same response from Greg Mirsky. > 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. CMP: Two points: (1) This is what IETF LC is for, and (2) the document is very clear that it’s not a time-machine, where it writes: "This document does not change the meaning of any terms in any prior RFCs." > 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. CMP: You can disagree all you want, but let’s stick to facts: The only mention of “OAM” in RFC 7799 is on Sub-Section 4.4, which is titled "Brief Discussion of OAM Methods”. And “brief” seems to imply not comprehensively and not substantially. The statement is consistent with the text and RFC7799 and belief system in the English language and logic. If you are still stuck with “substantially”, we can say “briefly with only 4 mentions in a subsection” Please advise. > 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. CMP: Well, this was also already responded to. CMP: Please read the first sentence of the acknowledgements, and the paragraph that precedes the statement. But re-re-re-repeating, since there is no “band” in IP, different readers think of something different to have “band” relate to. > 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. CMP: This was also explained several times. There are no “DetNet-only readers” or “BIER-only readers”. The fact that “in-band” means something different in each context makes the case for the document. > 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. CMP: Greg, you are saying “there are two things, A and B. If I change B then they are the same, therefore they are the same”. The “I” in IETF is not for Geometry, but regardless, if you transform one graph then you do not have the same graph… Not sure how else to respond to this. CMP: But geometry aside, feel free to volunteer another term. > 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. CMP: Again, the only responder we found in all of those lists is you, Greg. And screaming “did not tell those lists” a red-herring. CMP: The document cannot correct past mistakes. CMP: First, the document does not say what you wrote: > "In-packet OAM" is analogous to how DetNet OAM defines in-band OAM” CMP: Please read it. It says combined. CMP: For completeness once more: CMP: Detnet’s rfc9551 says: Active measurement methods: (as defined in [RFC7799]) these methods modify a DetNet flow by injecting specially constructed test packets [RFC2544]. […] 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. CMP: Which has 3 parts: in-band needs to (1) be an active method (inject packets), (2) traverse the same links and interfaces as a monitored flow, and (3) receive the same QoS and PREOF treatment as a monitored flow. CMP: This seems to apply only to “measurement OAM” as per “Active measurement methods” definition, not fault management for example. Somehow. CMP: But besides, exploding your definition into its characteristics, it is a new packet, it is congruent with traffic, it receives the same packet treatment. CMP: As the text explains, it is Combined because it uses various characteristics, which can be independent. CMP: Previous versions said: 4. DetNet OAM packets MUST be in-band, i.e., follow precisely the same path as DetNet data plane traffic. CMP: This is captured in the document already, if the text is not clear we can improve it. Combined: OAM in relation to multiple criteria. For example, in relation to both topological congruence and packet treatment. [I-D.ietf-detnet-oam-framework] uses Combined OAM when it says "In-band OAM is an active OAM 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". [I-D.ietf-raw-architecture] uses similar text. > 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? CMP: In regards to IPPM and RFC7799, that’s for metrics, correct? Monitoring, measurement. It is not for other OAM uses, right? CMP: This document, purposefully targeting OPSAWG to have a single common definition and not copy/paste of the same text, is for all OAM. > 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. CMP: Saying that (paraphrasing) "someone else missed the the way I use the terms and then they got cleared up” is a misrepresentation. CMP: For in-situ OAM, the term was changed when it was realized that “in-band” was used for different things — I was in the room when Erik N. suggested in-situ to keep the acronym. CMP: Now, here you are again making the point for the need for the document. CMP: You have a complex, interdepent definition of in-band for Detnet. Here you have a different definition for in-band, only when "in-band with the monitored data flow”. > 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. CMP: See above and please read it in the document. It is explained in the paragraph that follows the definition of Combined. > 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. CMP: BIER does not have PREOF, so NO! CMP: BIER says: * In-band OAM is an active OAM or hybrid OAM method ([RFC7799]) that traverses the same set of links and interfaces receiving the same QoS treatment as the monitored BIER flow. CMP: Which is yet another definition to in-band. CMP: More important to note, you can cite several WGs, but the text is traced to a single same contributor. In other words, you wrote similar (but different) text in all those documents. > 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. CMP: Not really, when you are writing definitions that add “and same PREOF” “and same QoS treatment” in different documents. > > 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. CMP: As stated above, we tried and engaged those WGs. Only Greg replied. You also cross-posted to all those WGs. This sounds like a red-herring… CMP: And for completeness, can you explain the "recognized centers of competence in the field of network OAM protocols”? Citation *please*! Does that mean Opsawg is clueless? CMP: In practice, it is the same people — and we purposefully targeted Opsawg so that we do not re-re-re-invent in every WG as seems to be current OAM practice. > CMP: I seem to suspect that you have a frame-of-reference that, because it;s rigid and inflexible, it does not let you see beyond and outside. You seem to have inflexible terms and ideas based on your past point uses and exposure. That is fine, except when those uses collide and cause confusion within the bigger picture. I would encourage you to read to understand the document’s viewpoint instead of read to contend and respond. I mention this because we have responded to the exact same things in this email various times. This document does not have the truth, but we are kindly exploring (I think with success) a solution to an issue we see over and over and over. Instead of redefining with obscurity in some corner-wg a term, and redefining in another one, let us put some social boundaries on the use of these colliding terms… CMP: Should this document proceed, you can ask the same questions at IETF LC :-) CMP: Best Regards, Carlos. > 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
