Greg: While I’ll defer to Tal for a detailed response, I’ve provided three key points inline. See “CMP:” below
> On Jun 1, 2025, at 7:49 PM, Greg Mirsky <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[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. > 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. CMP: As an author of RFC 5085, I can confirm that you are completely wrong on this. CMP: That said, you do not need to be an author to know this, you can actually **read** the RFC, where it says: CMP: "in-band (i.e., following the same data-plane faith as PW data).” CMP: “ travels in-band with the Session and follows the exact same path as the user data for the session" CMP: Let’s not make up ‘interpretations’. >> >> 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 CMP: This is *exactly* the problem that we are trying to solve with this document, and truly an argument for moving forward with this document. CMP: You are citing protocol-specific context-specific wg-specific definitions. CMP: If the goal is to write a lot of RFCs with almost overlapping text, sure. CMP: If the goal is clarity and removing ambiguity, the per-protocol approach does not work. > "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. CMP: Clearly you are “reading’ much beyond the words on the RFCs. RFC 5085 did not consider QoS. CMP: Please search all archives and share one mention of QoS along with 5085. CMP: Now, “the very close” is the whole problem. You are inclined in defining the same term, in-band, with **very close** but not the same definitions per WG... >> >> > 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 <[email protected] >> <mailto:[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] >> > <mailto:[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] >> >> <mailto:[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] >> >> > <mailto:[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] <mailto:[email protected]> >> >> >> To unsubscribe send an email to [email protected] >> >> >> <mailto:[email protected]> >> >> > >> >> > _______________________________________________ >> >> > OPSAWG mailing list -- [email protected] <mailto:[email protected]> >> >> > To unsubscribe send an email to [email protected] >> >> > <mailto:[email protected]>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
