Dear Greg, [it seems you added Ops Dir and an old email address for Benoit to the email’s To header. Correcting the latter. ops-...@ietf.org, Benoit Claise <bcla...@cisco.com>]
Thank you for your quick response! This is very useful! Please see inline as “CMP2:" > On Nov 11, 2024, at 11:39 AM, Greg Mirsky <gregimir...@gmail.com> wrote: > > 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 > <mailto: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. CMP2: I did not ask whether you sought to be assigned. CMP2: I asked if you thought there might be potential conflicts with you "agreeing to be a document shepherd” given your strong views. CMP2: Since I asked based on you _agreeing_ to take on the role, I’m still asking you, and I’d appreciate your response in regards to whether you consider there is conflict. CMP2: It’s not a trick question — just trying to understand your perspective. CMP2: And please note that there is no judgement or accusation on my questions — only a question on how you individually see the dual role. CMP2: Of course, chairs will chime in if they consider, and their perspective is always welcome. >> >> 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. CMP2: Great! Could you please provide a normative reference to that definition? Or is it in Greg’s dictionary? CMP2: Additionally (after providing the normative reference), CMP2: 1. would _you_ consider that definition is different than the other definitions of “in-band” that do not consider the forwarding treatment? CMP2: 2. Would _you_ consider that definition is different than your DetNet definition, since for “DetNet In-band” you need active OAM? For example, in-packet/shared-packet OAM also "traverse the same set of nodes and links receiving the same forwarding treatment” (your above definition) but fail the Detnet in-band definition. CMP2: Ambiguous, inconsistent uses. CMP2: Q.E.D. Thanks, Carlos. >> >>> On Oct 27, 2024, at 12:26 AM, Greg Mirsky <gregimir...@gmail.com >>> <mailto: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 <mailto:opsawg@ietf.org>>, IETF IPPM >> WG <i...@ietf.org <mailto:i...@ietf.org>>, mpls <m...@ietf.org >> <mailto:m...@ietf.org>>, spring <spr...@ietf.org <mailto:spr...@ietf.org>>, >> DetNet WG <det...@ietf.org <mailto: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
