Hi Carlos, I will wait for the WG leadership (Chairs and/or AD) to respond to your ad hominem line of questioning about the possible conflict of interest. As for the definition of "in-band OAM", I've listed works of BIER <https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/>, DetNet <https://datatracker.ietf.org/doc/rfc9551/>, and NVO3 <https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam/>WGs that are harmonized and are well-understood by these groups. I'm waiting for the substantive response of the authors of the document to my comments.
Regards, Greg On Mon, Nov 11, 2024 at 12:00 PM Carlos Pignataro <cpign...@gmail.com> wrote: > 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> > 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> 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
