Hi Tal, Thank you for your kind consideration of my notes—apologies for the belated response. As the new version has been published, I hope that you agree to bringing our discussion to the attention of OPSAWG and IPPM WGs. I reread the latest version, and I can formulate my primary concern about the document. If I understand the position of the supporters of the document correctly, they believe that there are OAM methods and protocols that inherently behave as either non-path-congruent, different-forwarding-treatment, or both. And, continuing that logic, there are OAM protocols, e.g., In-situ OAM or the Alternate Marking method, that inherently behave as path-congruent and equal-forwarding-treatment. I believe that in the course of our discussion, we established that OAM protocols, whether active or hybrid, can be deployed in a way that they behave as path-congruent and with equal-forwarding-treatment of OAM packets. And in some deployments, the packets of the same OAM protocol would behave as non-path-congruent while receiving equal-forwarding-treatment. And that fundamental distinction between the characteristic of an OAM protocol (already defined in RFC 7799) and how the protocol is deployed in the network, in my opinion, is the remaining problem with this draft. I think that clarifying that in the document and providing recommendations for better OAM deployment practices, e.g., use of explicit entropy source as in RFC 9790 <https://datatracker.ietf.org/doc/rfc9790/>, will substantially increase the value and bring it to the level we expect from a Best Current Level document.
Regards, Greg On Sun, Aug 10, 2025 at 4:35 AM Tal Mizrahi <tal.mizrahi....@gmail.com> wrote: > [Resending with Benoit's new address] > > On Sun, Aug 10, 2025 at 12:52 PM Tal Mizrahi <tal.mizrahi....@gmail.com> > wrote: > > > > Hi Greg, > > > > [Copying Benoit and Med for a wider perspective] > > > > Greg, many thanks for reviewing the revised version of the draft (on > > Github) and taking the time to explain your comments. > > While we might have a slightly different perspective on some of the > > comments, others have been very helpful in improving the draft. > > > > I have created a revised version on Github, following the latest > comments. > > > https://github.com/talmi/oam-what-q/blob/ver-10-revised/draft-ietf-opsawg-oam-characterization.txt > > > > Here is a diff compared to the datatracker version 09: > > > https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-09.txt&url_2=https://raw.githubusercontent.com/talmi/oam-what-q/refs/heads/ver-10-revised/draft-ietf-opsawg-oam-characterization.txt > > > > In my opinion this version is ready-to-go. It addresses the comments > > we received in IETF 123, as well as the insights from this email > > thread. > > > > Please see other responses/comments below, marked [TM]. > > > > > > > > On Sun, Aug 10, 2025 at 5:13 AM Greg Mirsky <gregimir...@gmail.com> > wrote: > > > > > > Hi Tal, > > > > > > thank you for your attention to my comments and the proposed updates > to address those issues. I read the new version and have several thoughts > to share: > > > > > > It seems that "A frequently encountered case is the use of "in-band" > to mean either In-Data-Packet or on-path" is not supported by the text that > follows. For example, VCCV is presented as a mechanism that ensures that > active OAM follows the same set of nodes and links as the monitored PW. But > upon careful examination, it is apparent that that is the case only for > VCCV Type I, i.e., when PW uses PW Control Word and VCCV uses PW ACH. Types > II and III may follow the same path, although that is not guaranteed. I > propose to add clarification that the "in-band" interpretation of RFC 5085 > applies only to VCCV Type I. > > > > [TM] Agreed. The text has been updated and now refers specifically to > > VCCV Type 1 in the example of Path-Congruent OAM: "An example of > > "Path-Congruent OAM" is the Virtual Circuit Connectivity Verification > > (VCCV) Type 1 [RFC5085], which was also referred to as In-Band VCCV." > > > > > Since the document is not intended to update RFC 7799, what is the > value in repeating definitions provided in RFC 7799? I suggest the removal > of text in Section 3.1 that repeats or rewords definitions and examples > from RFC 7799, and concentrate on the definition of In-Data-Packet OAM: > > > > [TM] These definitions and examples are brought here for context. It > > is explicitly emphasized that "This document does not update or change > > the terms of [RFC7799]". The examples are especially important to > > emphasize the difference between the term "Hybrid" and the term > > "In-Data-Packet" - this is the result of multiple comments calling for > > a clearer explanation of the difference including some examples. > > > > > > > > In-Data-Packet OAM: > > > > > > The OAM information is carried in the packets that also carry the > > > > > > data traffic. This is a specific case of Hybrid OAM. It was > > > > > > sometimes referred to as "in-band". > > > > > > > > > Firstly, the last sentence doesn't add any value to the definition. > Furthermore, the discussion at that time has demonstrated that such a > referral is rooted in a misunderstanding of what the IPPM WG deems as > "in-band" OAM. I propose removing the last sentence altogether. > > > > [TM] Agreed. The last sentence was removed from here and also from the > > definitions of Path-Congruent OAM and Equal-Forwarding-Treatment OAM. > > The appendix includes this information now. > > > > > > > > Secondly, as we discussed, Hybrid Type I OAM methods can be applied > not only to data packets but also to specially constructed test packets. > Hence, a reasonable question: How to characterize that case from the point > of the new sub-type of OAM? "In-Non-Data-Packet" sounds unclear. > "In-Test-Packet" is only marginally better. Which brings me to a more > general question: What is the value of introducing the In-Data-Packet term > in the first place, compared with the broadly accepted (by IOAM and the > AMM) term from RFC 7799, Hybrid Type I? > > > > [TM] To answer this question we added several examples "Hybrid" and > > "In-Data-Packet" to section 3.1. In my opinion the current text and > > examples illustrate what the term "In-Data-Packet" is intended to > > capture. > > > > > > > > After closer consideration of Section 3.4 and the discussion during > the OPSAWG meeting in Madrid, I find the root of my concern with terms > introduced in Sections 3.2 and 3.3. These terms, as I understand Section > 3.4 and Tal's responses at the meeting, are positioned as inherent in the > particular OAM protocol. For example, IOAM is presented as an inherently > path-congurent and equal-forwarding-treatment OAM protocol. That is the > case for application of IOAM as described in RFC 9127 and RFC 9326, but it > is not necessarily true for IOAM combined, for example, with STAMP (see > draft-ietf-ippm-stamp-ext-hdr). The same is true for the Alternate Marking > Method. For the case of active OAM methods (per RFC 7799), path-congruency > and equal-forwarding-treatment of the test packet are not guaranteed, but > it can be achieved by using some mechanisms. Thus, I conclude that terms > introduced in Sections 3.2 and 3.3 cannot be used to characterize an OAM > protocol or method, but only its application. I believe that without making > that clear, the document cannot be progressed. > > > > [TM] We might have a different perspective regarding this conclusion. > > However, based on this comment I have rephrased the text that > > describes IOAM and alternate marking so that it specifically talks > > about integrating an IOAM trace option or AM bits in data packets: > > - "An example of "Hybrid OAM" that is also "In-Data-Packet OAM", is an > > IOAM [RFC9197] trace option that is incorporated into data packets." > > - "Another example of "Hybrid OAM" that is also "In-Data-Packet OAM" > > is Alternate Marking [RFC9341], when applied todata packets.". > > I believe this resolves the gap by providing a more accurate example > > of "In-Data-Packet OAM". > > > > > > > > > > > Regards, > > > > > > Greg > > > > > > Cheers, > > Tal. > > > > > > > > > > > > > > On Sun, Aug 3, 2025 at 11:33 PM Tal Mizrahi <tal.mizrahi....@gmail.com> > wrote: > > >> > > >> Hi Greg, > > >> > > >> Thanks again for the discussion in IETF 123. Based on the three main > > >> issues we talked about, here is a proposed version that addresses > > >> these issues, as well as other issues raised in IETF 123: > > >> > > >> Proposed version: > > >> > https://github.com/talmi/oam-what-q/blob/ver-10/draft-ietf-opsawg-oam-characterization.txt > > >> > > >> Diff compared to version 09: > > >> > https://author-tools.ietf.org/diff?url_1=https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-09.txt&url_2=https://raw.githubusercontent.com/talmi/oam-what-q/refs/heads/ver-10/draft-ietf-opsawg-oam-characterization.txt > > >> > > >> Please let us know if there are further comments. > > >> > > >> Thanks, > > >> Tal. > > >> > > >> On Wed, Jul 23, 2025 at 2:21 PM Tal Mizrahi < > tal.mizrahi....@gmail.com> wrote: > > >> > > > >> > Hi Greg, > > >> > > > >> > Thanks for the discussion today. > > >> > Here is a brief summary of what we discussed: > > >> > - We will consider an alternative to the term "in-packet" that > > >> > emphasizes the focus on data packets. Perhaps "in-data-packet". > > >> > - Examples of the use of the term "in-band" can be moved to an > appendix. > > >> > - We will emphasize the difference between measurement protocols and > > >> > other types of OAM: measurement requires path congruence and equal > > >> > forwarding treatment. For other types of OAM, such as BFD, this may > > >> > not be the case. > > >> > > > >> > I will propose new text based on these items and send it to you > folks > > >> > for review. > > >> > > > >> > Cheers, > > >> > Tal. > > >> > > > >> > On Wed, Jul 23, 2025 at 2:03 PM Greg Mirsky <gregimir...@gmail.com> > wrote: > > >> > > > > >> > > Hi, > > >> > > Med and Benoit expressed interest and supported us working on > resolving remaining concerns. Do you think that we already can update them > or need a bit more discussion to be specific about the updates we agreed on? > > >> > > > > >> > > Regards, > > >> > > Greg >
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
