This is quite informative, Greg, but an off-topic red-herring. Perhaps you can start a new thread (not referencing this draft) about it.
Carlos. > On Jun 4, 2025, at 4:07 AM, Greg Mirsky <[email protected]> wrote: > > Hi Tal, > thank you for pointing out to the management plane mechanism that allows > overwriting the p-bits configured by Ethernet switches. I am curious, how > many operators use that overwriting capability? I think that you're referring > to the following text in RFC 7369: > How CCM > priority is determined is out of the scope of this document. Note > that the highest priority should be used as the default CCM > priority. > It appears that the question of setting the p-bits is, quite appropriately, > left for an operator to decide, as the text about using "the highest > priority" (highest compared to what?) is informational. > On that topic. I am aware of the technique for defect detection in services > carrying aggregated flows, which consist of multiple levels of CoS. This > technique involves monitoring path connectivity at the highest CoS level > among the CoS levels used by the constituent data flows. However, this > technique may produce false positives for flows at lower CoS levels, failing > to detect loss of connectivity due to severe congestion at lower CoS levels. > An operator is expected to evaluate the tradeoff between using per-CoS defect > detection and not detecting defects that impact low-level CoS data flows. > > Regards, > Greg > > Regards, > Greg > > On Wed, Jun 4, 2025 at 4:46 PM Tal Mizrahi <[email protected] > <mailto:[email protected]>> wrote: >> Hi Greg, >> >> > GIM2>> Before trying to normalize terminology, one needs to understand >> > that both topological and forwarding equivencies between OAM and the >> > monitored data flow must be provided to make the results of OAM >> > observation viable. What is the value of, e.g., performance measurement, >> > if there is only topological equivalency between data and OAM flows, but >> > respective packets receive different forwarding treatment from the >> > network? On the other hand, what would be the operational value of the >> > network detection while the topological equivalency is not ensured, but >> > only the forwarding equivalency is? The answer is evident in both cases - >> > no value. That is why I am asking about the benefit of defining two >> > characteristics, which only complicates the definition of what is required >> > from an OAM to be a viable operational tool. >> >> [TM] In some cases OAM packets are expected to be treated differently >> than data traffic that is forwarded through the same path. One example >> is CCMs, which are sent at the highest possible priority by default >> (see RFC 7369 for example). >> >> Cheers, >> Tal. >> >> On Wed, Jun 4, 2025 at 8:31 AM Greg Mirsky <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > Hi Carlos, >> > please find my notes below tagged GIM2>>. >> > >> > Regards, >> > Greg >> > >> > On Tue, Jun 3, 2025 at 1:21 AM Carlos Pignataro <[email protected] >> > <mailto:[email protected]>> wrote: >> >> >> >> 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] >> >> <mailto:[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. >> > >> > GIM2>> That is your personal opinion, not the opinion of other authors, >> > and even less the opinion of PWE3 (later PALS) WG. As the PALS WG is >> > winding down, the MPLS WG may be the community to provide a more >> > authoritative interpretation of RFC 5085. >> >> >> >> >> >> 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 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. >> > >> > GIM2>> Before trying to normalize terminology, one needs to understand >> > that both topological and forwarding equivencies between OAM and the >> > monitored data flow must be provided to make the results of OAM >> > observation viable. What is the value of, e.g., performance measurement, >> > if there is only topological equivalency between data and OAM flows, but >> > respective packets receive different forwarding treatment from the >> > network? On the other hand, what would be the operational value of the >> > network detection while the topological equivalency is not ensured, but >> > only the forwarding equivalency is? The answer is evident in both cases - >> > no value. That is why I am asking about the benefit of defining two >> > characteristics, which only complicates the definition of what is required >> > from an OAM to be a viable operational tool. >> >> >> >> >> >> >> >> "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 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... >> > >> > GIM2>> Asked and answered. If the OPSAWG is looking for the authoritative >> > opinion on RFC 5085, it would be reasonable to post the question to the >> > MPLS 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]
