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
<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
<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]
