Dear Carlos, please find my notes below tagged GIM>>. Regards, Greg
On Mon, Nov 11, 2024 at 11:07 AM Carlos Pignataro <cpign...@gmail.com> wrote: > 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)> > ? > GIM>> I didn't seek to be assigned the Shepherd for this document, but the WG Chairs asked after I clearly expressed my views during the WG AP. Hence, you can direct your question about whether there's a conflict of interest to Joe and Benoit. > > 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 :-)] > GIM>> In a packet-switched network, the band is the monitored flow. Hence, "being in-band" means traversing the same set of nodes and links and receiving the same forwarding treatment as the monitored flow. > > 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> 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
