Hi Greg, Thanks again for reviewing the draft. Your comments for the previous versions have helped in improving the draft. Please see my responses to the latest comments that you have sent to the authors off-list when you kindly reviewed an intermediate version of the draft.
On Tue, May 13, 2025 at 8:38 PM Greg Mirsky <[email protected]> wrote: > > Hi Tal, > > Thank you for your work on addressing my comments. I reviewed the working > version of the draft and have some comments and questions, which are below. > Section 2: > > It is noted that "A frequently encountered case is the use of "in-band" to > mean either in-packet or on-path." If that is the case, and there are many > IETF documents that use these interpretations of "in-band," it seems like it > would be easy to provide several references in support of that assumption. [TM] Following your comment we have focused the following two paragraphs. The following paragraph demonstrates the use of the term "in-band" in the context of path-congruent OAM: Connectivity Verification (VCCV), described is Section 6 of [RFC5085] as "The VCCV message travels in-band with the Session and follows the exact same path as the user data for the session". Thus, the term "in-band" in [RFC5085] refers to using the same path as the user data. This term is also used in Section 2 of [RFC6669] with the same meaning, and the word "congruent" is mentioned as synonymous. On the other hand, the following paragraph demonstrates the use of "in-band" in the context of in-packet OAM: Initially, "In situ OAM" [RFC9197] was also referred to as "In- band OAM" [I-D.brockners-inband-oam-data], but was renamed due to the overloaded meaning of "In-band OAM". Further, [RFC9232] also intertwines the terms "in-band" with "in situ", though [I-D.song-opsawg-ifit-framework] settled on using "in Situ". Other similar uses, including [P4-INT-2.1] and [I-D.kumar-ippm-ifa], still use variations of "in-band", "in band", or "inband". > I think the following assertion, also without any reference, is > unsubstantiated. > > Within the IETF, the terms "in-band" and "out-of-band" cannot be > > reliably understood consistently and unambiguously. > [TM] This assertion is demonstrated throughout Section 2.1, including the two paragraphs cited above. Another relevant paragraph that demonstrates this point is the following: There are many examples of "in-band OAM" and "out-of-band OAM" in published RFCs. For instance, the term "in-band" appears in both [RFC5085] and [RFC9551]. While the context in each of these documents is clear, the term carries different meanings in each case. > More so, the Routing Area has published or is in the process of publishing > several documents (passed the IESG review) that use the terms "in-band" and > "out-of-band"—for example, RFC 9551 and draft-ietf-nvo3-geneve-oam. At least > in the Routing Area, these terms seem to be understood unambiguously. If that > is the case, perhaps other WGs can look at how the WGs in the Routing Area > interpret these terms. > > That is followed by > > "Context-specific definitions of these terms are inconsistent and therefore > cannot be generalized." > > That, without any example, reference to where the interpretation of "in-band" > and "out-of-band" terms is established seems like an unsubstantiated > assertion. [TM] Indeed, RFC9551 is mentioned 5 times in the draft, and its interpretation of "in-band" is clear. The point that is emphasized in the draft is regarding inconsistency across the RFC series: For instance, the term "in-band" appears in both [RFC5085] and [RFC9551]. While the context in each of these documents is clear, the term carries different meanings in each case. > > Section 2.1 > > AFAIK, the term congruent in geometry is not limited to the definition > proposed in this draft. Hence, the proposed term "Path Congruent" is > re-defining the original interpretation of the term "congruent" by omitting > that congruence between two figures is not limited to them being of the same > size, shape, and also traversing the same set of points, but that the > congruence may be demonstrated by moving figures, e.g., rotating, flipping. > Thus, the proposed term seems as artificial and non-intuitive as "in-band". [TM] The term "congruent" is used figuratively in the current draft, and is therefore not identical to the geometrical definition. > Reference to RFC 6669 in the context of using "congruent" vs. "in-band" > terminology is incomplete and inaccurate. Firstly, "congruent" is used only > once while "in-band" - is used six times in RFC 6669. But more importantly, > "share their fate with data packets" is not reflected in the proposed > definition since the fate sharing includes not only topological equivalence > between the path traversed by the monitored data flow and the OAM packets, > but also that they received the same QoS treatment. Thus, the reference to > RFC 6669 more in support of "in-band" terminology rather than the proposed in > the draft. [TM] Following your comment we have rephrased the sentence referring to RFC6669: Thus, the term "in-band" in [RFC5085] refers to using the same path as the user data. This term is also used in Section 2 of [RFC6669] with the same meaning, and the word "congruent" is mentioned as synonymous. > The introduction of "in-packet OAM" seems confusing and unnecessary: > > In-Packet OAM: > > The OAM information is carried in the packets that also carry > > the data traffic. This was sometimes referred to as "in-band". > > Firstly, this definition repeats the definition of Hybrid OAM in RFC 7799. > Secondly, note in the second sentence without a reference to the IETF > document is unsubstantiated and erroneous as it is not how in-band OAM is > defined in the IETF approved documents, e.g., RFC 9551 and > draft-ietf-nvo3-geneve-oam. Furthermore, characterization of IOAM as an > example of in-packet OAM misses cases when IOAM is combined with active OAM, > e.g., STAMP, as proposed in draft-ietf-ippm-stamp-ext-hdr. Classification per > RFC 7799 is clear - such combination is an example of Hybrid OAM. But how > does the proposed terminology work in this case? According to "In situ OAM > [RFC9197] is an example of "In-Packet OAM", it is In-packet OAM. On the other > hand, packet doesn't carry data traffic but is a specially constructed test > packet, and, per RFC 7799 is an example of Hybrid OAM. Seems like > introduction of the new class of In-packet OAM is superfluous, and > terminology defined in RFC 7799, already broady used in IETF documents, is > sufficient. [TM] Following your comment we have added a more detailed explanation highlighting the difference between hybrid and in-packet OAM by providing an example of hybrid OAM which is not in-packet OAM: In situ OAM [RFC9197] is an example of "In-Packet OAM", given that it: '...records OAM information within the packet while the packet traverses a particular network domain. The term "in situ" refers to the fact that the OAM data is added to the data packets rather than being sent within packets specifically dedicated to OAM.' On the other hand, direct loss measurement [RFC6374] is an example of "Hybrid OAM" which is not classified as "In-Packet OAM". > > What could be the benefit of separating the topological aspect of OAM from > the QoS behavior OAM experiences in the network? For example, a Path > non-congruent OAM cannot provide useful information about the monitored data > flow. The same is the case of Different-Forwarding-Treatment OAM. Only Path > Congruent with Equal-Forwarding-Treatment OAM can produce information that is > relevant to the monitored data flow. And that is how RFC 9551 defines In-band > OAM for a DetNet domain. It seems reasonable to generalize definitions > already accepted by the Routing Area through an open discussion with WGs, > including the recognized center of competence in the Performance measurement > OAM, the IPPM WG. [TM] One example, which is cited in the draft is RFC5085, defining VCCV: Connectivity Verification (VCCV), described is Section 6 of [RFC5085] as "The VCCV message travels in-band with the Session and follows the exact same path as the user data for the session". Thus, the term "in-band" in [RFC5085] refers to using the same path as the user data. While "in-band" in this case refers to using the same path, there is no guarantee about Equal-Forwarding-Treatment. > > My conclusion, proposed "In-packet OAM" is superfluous and classification > defined in RFC 7799 is sufficient. Separation of topological aspects of OAM > from the QoS treatment OAM packet receives from the network is artificial and > doesn't add any value. If anyone cannot accept the terminology defined in RFC > 9551, perhaps "in-flow/out-of-flow" may be defined. As the document exists > now, I don't find it helpful, and, certainly, not at the level of the Best > Current Practice document. > > Regards, > Greg > > Thanks, Tal. On Thu, May 29, 2025 at 12:22 AM Greg Mirsky <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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) >> > <[email protected]> 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 -- [email protected] >> >> To unsubscribe send an email to [email protected] >> > >> > _______________________________________________ >> > OPSAWG mailing list -- [email protected] >> > To unsubscribe send an email to [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
