Hi Tal, thank you for explaining updates. Please find my follow-up notes below tagged GIM>>.
Regards, Greg On Thu, May 29, 2025 at 5:59 PM Tal Mizrahi <tal.mizrahi....@gmail.com> wrote: > 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 <gregimir...@gmail.com> 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. > GIM>> I don't think that your interpretation of "in-band" in RFC 5085 is accurate. The VCCV message not only traverses the same path as a data packet because the same labels are applied along the path, but it also receives the same forwarding treatment by the network because the same Traffic Class is used for the VCCV message as for the data packet. Thus, it is in-band with the monitored data flow, and topological equivalence is only one element, while it must be complemented by the QoS equivalence. > > 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". > GIM>> I find historical references not relevant to my questions. Furthermore, AFAICS, [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa], as individual drafts, do not reflect an agreement of any of IETF WGs. Additionally, both individual drafts have been expired for over 6 months. On the other hand, several RFCs published by IETF, e.g., RFC 9772 <https://datatracker.ietf.org/doc/rfc9772/> give clear and useful interpretation of "in-band OAM": * In-band OAM is an active or hybrid OAM method, as defined in [RFC7799], that traverses the same set of links and interfaces and receives the same Quality of Service treatment as the monitored object. In this context, the monitored object refers to either the entire Geneve tunnel or a specific tenant flow within a given Geneve tunnel. As well as in RFC 9551 <https://datatracker.ietf.org/doc/rfc9551/> we find the following interpretations of in-band and out-of-band OAM: 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. Out-of-band OAM: an active OAM method whose path through the DetNet domain may not be topologically identical to the path of the monitored DetNet flow, its test packets may receive different QoS and/or PREOF treatment, or both. > > > 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. > GIM>> As noted above, I find that the interpretations of "in-band OAM" in RFC 5085, RFC 9551 (and RFC 9772) are, if not identical, then very close, as both require topological and QoS equivalencies between OAM and data packets. > > > 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. > GIM>> Asked and answered above. > > > > > 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. > GIM>> Can you point me to where in the document it is clarified that the interpretation of "congruent" departs from the definition accepted everywhere except in this draft? Isn't that the same as the document states regarding the use of "in-band" for OAM packets? > > > 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. > GIM>> As I pointed out above, I believe that your interpretation of how "in-band" is interpreted in RFC 5085 falls short of recognizing that a VCCV message experiences not only topological equivalency with the data packet but also QoS equivalency. > > > 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". > GIM>> IOAM in RFC 9197 is classified as: In terms of the classification given in [RFC7799], IOAM could be portrayed as Hybrid Type I. And this document, as it appears, defines IOAM as an "in-packet OAM". Does that updates RFC 9197 by changing IOAM classification? Or tries to introduce a new term for Hybrid Type I? Can you please clarrify that in the document? > > > > > 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. > GIM>> As I noted above, a VCCV message uses not only the same label information but the same Traffic Class marking as the data flow. > > > > > 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 <gregimir...@gmail.com> > 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 <tal.mizrahi....@gmail.com> > 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 <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. 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) <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 >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
