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 <tal.mizrahi....@gmail.com>
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 <gregimir...@gmail.com> wrote:
> >
> > Hi Carlos,
> > please find my notes below tagged GIM2>>.
> >
> > Regards,
> > Greg
> >
> > On Tue, Jun 3, 2025 at 1:21 AM Carlos Pignataro <cpign...@gmail.com>
> 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 <gregimir...@gmail.com> 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 <tal.mizrahi....@gmail.com>
> 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 <gregimir...@gmail.com>
> 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 <gregimir...@gmail.com>
> 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 <
> tal.mizrahi....@gmail.com> 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 <gregimir...@gmail.com>
> 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) <jclarke=
> 40cisco....@dmarc.ietf.org> 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 -- opsawg@ietf.org
> >>> >> >> To unsubscribe send an email to opsawg-le...@ietf.org
> >>> >> >
> >>> >> > _______________________________________________
> >>> >> > OPSAWG mailing list -- opsawg@ietf.org
> >>> >> > To unsubscribe send an email to opsawg-le...@ietf.org
> >>
> >>
>
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
