Hi Adrian, thank you for catching my mistake in terminology. Indeed, that is "In-Data-Packet OAM". Please find my notes below tagged GIM>>.
Regards, Greg On Wed, Sep 3, 2025 at 12:00 PM Adrian Farrel <[email protected]> wrote: > Thanks for the pointer to this draft, Greg. > > > > Help me here, please. The draft you point to only discusses the use of > synthetic test packets? Am I right? > > > > Now, unless I have not being paying attention, > draft-ietf-opsawg-oam-characterisation-10 does not define “in-packet OAM”. > It does talk about in-data-packet OAM, but this is clearly not the case for > synthetic data packets. > > > > Some confusion might arise from: > > - IOAM can be applied to synthetic test packets. While the IOAM is > “in-packet”, the packets that it is in are not data packets, so the > methodology is purely Active OAM : it uses dedicated OAM packets. > > GIM>> Yes, and that is what, in my opinion, mixes the characterization of OAM protocols according to RFC 7799 with how an OAM protocol can be applied. The fact that IOAM or the Alternate Marking method is used in combination with a data or synthetic packet doesn't change the characterization of the protocol. Furthermore, the definition of In-Data-Packet OAM in Section 3.1 of draft-ietf-opsawg-oam-characterization <https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/> is incorrect: 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". The combination of active and passive OAM, as defined in RFC 7799, is the only case of In-Data-Packet OAM, since the combination of hybrid and active methods produces the active OAM. Thus, the proposed term merely rewords the definition in RFC 7799 and doesn't add value. > > - Alternate marking can be applied to data packets, making it Hybrid > OAM. But I don’t read draft-fioccola to be talking about this mode. > > GIM>> I support the adoption of the draft as it provides a solid foundation for continued work. I intend to work and contribute to it, including adding the Alternate Marking method. > > > Cheers, > > Adrian > > > > *From:* Greg Mirsky <[email protected]> > *Sent:* 03 September 2025 19:36 > *To:* [email protected] > *Cc:* Tal Mizrahi <[email protected]>; opsawg <[email protected]>; > IETF IPPM WG <[email protected]>; Adrian Farrel <[email protected]>; Carlos > Pignataro <[email protected]>; Med Boucadair < > [email protected]>; Tim Chown <[email protected]> > *Subject:* Re: Updating Med and Benoit on our discussion > > > > 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 [email protected] < > [email protected]> 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 <[email protected]> > wrote: > > [Resending with Benoit's new address] > > On Sun, Aug 10, 2025 at 12:52 PM Tal Mizrahi <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> > 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 -- [email protected] To unsubscribe send an email to [email protected]
