Hi Benoit, Thank you for recognizing the progress of the draft resulting from our constructive discussion with Tal. I want to bring to your and OPSAWG's attention draft-fioccola-ippm-on-path-active-measurements <https://datatracker.ietf.org/doc/draft-fioccola-ippm-on-path-active-measurements/>, which is currently in the IPPM WG AP <https://mailarchive.ietf.org/arch/browse/ippm/?gbt=1&index=EY2_Y5g_U5vK9Wi1M4zK4cJjRPM>. This work and the interest of the IPPM WG indicate that characterization of IOAM as in-packet OAM, given the definition of in-packet OAM in the draft, misses the use cases analyzed in draft-fioccola-ippm-on-path-active-measurements <https://datatracker.ietf.org/doc/draft-fioccola-ippm-on-path-active-measurements/> .
Regards, Greg On Wed, Sep 3, 2025 at 1:53 AM ben...@everything-ops.net < ben...@everything-ops.net> wrote: > Dear all, > > As expressed during the last IETF 123 OPSAWG by some of us, we are glad > that you guys are converging. > Special thanks to Tal for the heavy lifting lately. > > I looked at the diff between the last two versions, and I am happy with > the changes. > > Regarding the scope "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.", it's best not extend the scope at this point in time. > > I requested a last OPS-DIR review by Tim. > After this, assuming no issue, I intend to progress the draft. > > Regards, Benoit (as OPSAWG chair and doc shepherd) > > 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
