From adrian@olddog.co.uk Fri Jan 12 11:25:34 2024 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43620C14F5F6; Fri, 12 Jan 2024 11:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UXg6HeuSKFc; Fri, 12 Jan 2024 11:25:29 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5C3C14F5EE; Fri, 12 Jan 2024 11:25:18 -0800 (PST) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 40CJPFxF031102; Fri, 12 Jan 2024 19:25:15 GMT Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4A8B54604A; Fri, 12 Jan 2024 19:25:15 +0000 (GMT) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3349446043; Fri, 12 Jan 2024 19:25:15 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Fri, 12 Jan 2024 19:25:15 +0000 (GMT) Received: from LAPTOPK7AS653V ([148.252.140.233]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 40CJPCPi009417 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jan 2024 19:25:13 GMT Reply-To: From: "Adrian Farrel" To: "'Greg Mirsky'" , "'Carlos Pignataro'" Cc: "'Ops Area WG'" References: In-Reply-To: Date: Fri, 12 Jan 2024 19:25:12 -0000 Organization: Old Dog Consulting Message-ID: <019101da458d$112c9290$3385b7b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01DA458D.112E6750" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQB25zH1MM+Sp115EjuA/TYDVUSlMAJoPwTks4nwuGA= Content-Language: en-gb X-Originating-IP: 148.252.140.233 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=18HXCW7FT9Y+FatnBtvFm CgxhftxCAtUltqjMRUzRBI=; b=AysGAhgDDaMe26Cs4og1anm0BY49spqOOF249 AadlqWuhfOCFJqEb09U9lSenv99gWU2GYO69b0dQBOhE0KSZMOmfEgxmoWtsThi/ upFzizlCPGWVYHhTC9OD4alZAOAAcov7+4cpjBzwKcqE0JXMsrOBnz6ft5F1Viul zTIIEmEp7zhGWYxYmburlai1+b1/PrMyaE73m7BUMPvBCxhytWpeeZCbyRMvU4EI 4EwO2aJDzkN5gshyFwmhJ2nrWzkx1fEOW1XJBgKCgb1tP3II/nLT08PydDLTwweB eflovKOuvFFT5DlbRHOyE/5lb3YdoTR5btDHsJ55p3ZDkDJsw== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-28116.001 X-TM-AS-Result: No--17.846-10.0-31-10 X-imss-scan-details: No--17.846-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-28116.001 X-TMASE-Result: 10--17.845800-10.000000 X-TMASE-MatchedRID: Z/tjqhsgM6c7iuZ/mdYYtu2O/JycxPgddDgJT0cEhOIugPi2f29YklmZ x0N5i/DXDfI/ed0jMY4ybAoj9KKYiBSJ8houaz8CmkiDENWA6PzZGAD5GwW8htKFZcTVK6iBQiJ lXXQibaOHf4Ivz8X+zQzrPeIO/OIHwdP+8YXeAckF/rgEFhBwcHLTizRHVDEoc/39lfktP/+c47 U2nSNfcUZJKPeRz7CMlVHM/F6YkvSX2rvknNYlE3LWbnbHhz0tbc0YRoReacC5ss0kHXBGRbdSv 1HlUd6orZUabAXNvDMK3Ma88LL+bqUfpvLQYumSL5XY4LEdIZz9h5nHGTspyAOOQpFyXt5P+D+e 2IRHW2WjqGSzm1CS4N+pUF0HsjxRyeUl7aCTy8g1XDsfhOTl8MGPPyZDnOYMpzYzXM5CUANLvW+ ssUrId7yBmVBNNVKmmqdQuKXkmosWQSsunIDX1RHfiujuTbediwOYVASrRss2Uqucj0YEnzwSas /EhcgSLTVVeVyNwJSG/X7YnfJAXKVjgXyvS9c/OJUqCG/fu69opiM29am9T3SLlahFgOAhHUIvY uTx5PP5/6JuVxOsv2MugLQMu2GXb5NyYlw4+HXW/36Ltv3HJMVbR35quRzISAzErue2Unk9to03 GYMMhjzr4TJKjukKfid4LSHtIANK4f4Z+CZAZ/mrkkH6JvZB2vCBbPHoleO+lnJvFLaM3LsEc0a mEy8O4HhAe/Sb9R4c9jA4mLo8uQfDeEgMBiKOF0dfZ5kV9l9qPeYrNy5TV+GmGqKmcRfcfp/v8z SjwvBdoD7eNiqVOsNoRi8z9LMONi8L88UV9IBCb9sS4MpIz6PFjJEFr+ol6AvlZUR4Tsiypq0eC 3FVtj/cZn50ezHqi2QFaYS1v22rEHfaj14ZyfNjq6soDWcmSHw5WWKvEW6elLKT79A3v4c3GB5H YPNNGln3U+bKluk= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: X-Mailman-Approved-At: Mon, 15 Jan 2024 02:04:29 -0800 Subject: Re: [ippm] [OPSAWG] New I-D -> Guidelines for Charactering "OAM" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2024 19:25:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0192_01DA458D.112E6750 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Greg, =20 Thanks for your thoughtful inspection of our draft.=20 =20 Carlos and I wanted to be sure that all of the discussions of this draft = were indexed on one list, and we wanted to avoid multiple copies going = to people who are subscribed to multiple lists. So we asked that = follow-ups went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and = DetNet to BCC on this email. =20 It was certainly not our intent to disparage any work that was being = done in any other working group, and I understand the effort that has = gone into the DetNet OAM Framework to ensure that the terminology is = clear and unencumbered in the DetNet context. =20 Our concern was, however, that different contexts are applying different = definitions of the terms =E2=80=9Cin-band=E2=80=9D and = =E2=80=9Cout-of-band=E2=80=9D. Those definitions are (often) clear and = precise, but they are not consistent across contexts. Thus, a = water-tight definition in the DetNet context is not universally = applicable, and a reader coming to DetNet from another context may bring = with them their own understanding of the terms. =20 Our intent, therefore, is to select a finer-grained set of terms that = have universal applicability and that can be selected within a context = without loss of generality. =20 This is a tricky little subject and I know that Carlos and I expected it = to generate more than a little discussion. If we end up with = =E2=80=9Ceverything is OK and nothing needs to change=E2=80=9D that will = be OK with us. If we discover that some work is using terms too = generally, while others already have perfect definitions, that will lead = to something similar to this document to bring the good into the light. =20 Further comments in line=E2=80=A6 =20 =20 From: Greg Mirsky =20 Sent: 12 January 2024 00:09 To: Carlos Pignataro ; Adrian Farrel = Cc: Ops Area WG ; IETF IPPM WG ; mpls = ; spring ; DetNet WG Subject: Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM" =20 * Hi Carlos and Adrian, thank you for starting this work. I believe that having a common = dictionary helps in having more productive discussions. I took the = liberty of inviting all the WGs which you invited to review the document = and added DetNet WG. Please feel free to trim the distribution list. I've read the document and have several general questions to start our = discussion: * It seems that the motivation of this document is the assumption that = "in-band OAM" and "out-of-band OAM" are not representative or cannot be = understood or correctly attributed, interpreted by the IETF community. = Is that correct? I think the wording here would be =E2=80=9Ccannot be reliably understood = consistently=E2=80=9D. That is, without looking at a context-specific = definition (such as that which you supply in the DetNet OAM Framework), = the use of the terms may be misinterpreted. This is an assertion, but one (we think) is founded on observation of = recent conversations on mailing lists, and also of witnessing many years = of people talking passed each other. * As we discuss and try to establish (change) the IETF dictionary, it is = important to analyze the terminology used by other SDOs. I believe that = it is beneficial to maintain consistent terminology which will minimize = misunderstandings among experts with different experiences of working at = different centers of technological expertise. This is a good point. It is certainly true that if other SDOs working = with packet networks have established terminology that we can agree with = and which is not, itself, subject to context-specific definitions, then = there is no reason to choose other terms. Do you have any suggested = sources? It is notable that the ITU-T has long worked with non-packet transport = networks and has used the terms in-band and out-of-band. But even there = we see some fragmentation with terms such as =E2=80=9Cin-fibre, but = out-of-band=E2=80=9D becoming necessary. * I that DetNet OAM Framework = = provides sufficiently clear interpretation of terms that can be = generalized for non-DetNet networks: * In-band OAM is an active OAM 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. =20 This, of course, does not distinguish between = =E2=80=9Cin-packet=E2=80=9D (such as IOAM), and having its own packet = (such as ping). =20 * Out-of-band OAM is an active OAM whose path through the DetNet domain is not topologically identical to the path of the monitored DetNet flow, or its test packets receive different QoS and/or PREOF treatment, or both. As can be seen, the interpretation of "in-band" accepted by the DetNet = WG includes not only topological equivalence between the monitored data = flow and path traversed by active OAM but also QoS equivalence between = them. I believe that is essential in differentiating in-band OAM from = out-of-band OAM. =20 Right. But is there terminology to talk about a packet that does follow = the topology, but does not receive the same QoS treatment? =20 It is perhaps a little strong to say this, but what you have done is = define two classes of OAM (both good things and meaningful in the DetNet = context) and then assigned existing names to those classes. What we are = suggesting is that you have some finer granularity categorisation of OAM = available, and that for the purposes of your DetNet work, you are = collecting those granularities into two different sets. * I find the use of "path congruence" in inherently meshed = packet-switched networks confusing if not misleading. (Note that RFC = 6669 explains congruence by = using in-band term.) Is there evidence of the term being used besides a = single case in RFC 6669? Well, I would say that 6669 is an example of how = =E2=80=9Cin-band=E2=80=9D has been used, and I=E2=80=99d point out that = it does not match your DetNet OAM Framework definition (as there is no = mention of identical treatment). Note that the text from RFC 6669 is = replicated into RFC 7276 (same authors, same subject). You don=E2=80=99t say what you find misleading or confusing. Is it that, = in a meshed packet network, each individual packet might be forwarded = differently so that congruence cannot be guaranteed? That could be true, = but we hope for greater stability than that, I think. If =E2=80=9Cpath congruence=E2=80=9D was a new term (with only one = previous use) that might make it a really neat term to use (because it = would lack all previous meanings). However, it is not. It has been used = (to mean the same set of links, ports, and nodes) in our more = path-oriented work such as RFC 5828, RFC 6373, right up to RFC 9059. Perhaps =E2=80=9Ccongruent=E2=80=9D is overloaded given that we are not = talking about =E2=80=9Ctopological congruence=E2=80=9D, a term that is = also quite widely used (e.g., RFC 2796, RFC 4258, RFC 5059, RFC 6549, = RFC 8795) * Similarly, "in-packet" vs. "dedicated packet". I believe that RFC 7799 = has that addressed by using = "active", "passive", and "hybrid" terminology. Although these terms = applied to measurement methods, i.e., performance monitoring component = of OAM, but, in my opinion, can be extended to fault management OAM. Well, we agree that RFC 7799 can be used to generate the terms "active = OAM", "passive OAM", and "hybrid OAM". Although we think, for the = benefit of clarity, the reader should not be left to examine RFC 7799 = and project meaning from performance monitoring to OAM in general: they = should be presented with a clear set of definitions (per our section 3). = It is further our belief that the definitions of active and passive OAM = do not match with =E2=80=9Cin-packet=E2=80=9D and = =E2=80=9Cdedicated-packet=E2=80=9D. Indeed, possibly, the closest is = that =E2=80=9Cactive OAM=E2=80=9D is =E2=80=9Cdedicated-packet=E2=80=9D, = and =E2=80=9Chybrid OAM=E2=80=9D is =E2=80=9Cin-packet=E2=80=9D leaving = =E2=80=9Cpassive OAM=E2=80=9D to be just observation. * It seems like the definition of Compound/Combined misses the point = that RFC 7799 already defines a hybrid measurement method (not OAM but = measurement methods) as a method in which elements of active and passive = measurement methods are used. Hence, hybrid is already a combination of = active and passive measurement methodologies and the introduction of = compound or combined terms is unnecessary, a duplication of the existing = and accepted terminology (at least in IPPM WG). And = "Active-Hybrid-Passive OAM" is the result of that omission because, = according to the definition in RFC 7799, Active-Passive is Hybrid. Thus, = Active-Hybrid-Passive is nothing else but Hybrid-Hybrid. Does that make = sense? I should certainly have preferred it had RFC 7799 not used the term = =E2=80=9Chybrid=E2=80=9D to actually refer to a third category that is = not a hybrid of the first two categories. For the definitions of active = OAM and passive OAM, I don=E2=80=99t think the combination matches the = definition of hybrid OAM. So, perhaps, let=E2=80=99s stop referring to RFC 7799=E2=80=99s = definitions of not-actually-OAM-packets, and nail down our own = definitions. That will tell us whether we need two, three, four, or more = terms. * I cannot agree that RFC 7799 "adds to the confusion" by pointing that Passive performance metrics are assessed independently of the packets or traffic flows, and solely through observation. Some refer to such assessments as "out of band". Indeed, passive measurement methods are not required to use packets that = are in-band with the monitored data flow. Usually, the management plane = protocol is used to collect, to perform the observation function. In = some cases, in-band active OAM packets may be used, e.g., direct loss = measurement in ETH-OAM. =20 Yes, but where is this =E2=80=9Cin-band with the monitored data = flow=E2=80=9D defined for a packet network? And you say =E2=80=9Care not = required to=E2=80=9D rather than =E2=80=9CMUST NOT=E2=80=9D. That means = that the passive methods might send their packets with the monitored = data flow or might not.=20 We live in a world where there is not necessarily a distinction between = the MCN and DCN.=20 =20 I find that throw-away sentence in RFC 7799 both helpful and unhelpful. = It is helpful to know that some people call this =E2=80=9Cout of = band=E2=80=9D. It is unhelpful to refer to an assessment method as = =E2=80=9Cout of band=E2=80=9D as there is no message or packet involved = to be in or out of band. =20 FWIW, I believe that RFC 7799 and DetNet OAM Requirements already = provide a clear terminology for OAM in general and its elements, i.e., = Fault Management and Performance Monitoring. =20 OK. I suspect that we are going to have to come up with a set of OAM = techniques and ask you to categorise them according to your terminology = to see whether all bases are covered. =20 But I am also going to have to review your text from the DetNet OAM = Framework because it contains phrases that are not clear (to = me)=E2=80=A6 =20 In-band OAM is an active OAM 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. =20 There is something broken here. Maybe too many words. Perhaps you = mean=E2=80=A6 =20 In-band OAM is an active OAM that 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 within the monitored DetNet OAM domain =20 =E2=80=A6and=E2=80=A6 =20 Out-of-band OAM is an active OAM whose path through the DetNet domain is not topologically identical to the path of the monitored DetNet flow, or its test packets receive different QoS and/or PREOF treatment, or both. =20 As noted before, this leaves a few gaps. * Active OAM that follows the same path, but does not receive the same = QoS treatment * There is no distinction between instrumentation of data packets and = dedicated instrumentation packets =20 Cheers, Adrian =20 On Fri, Jan 5, 2024 at 12:39=E2=80=AFPM Carlos Pignataro = > wrote: Hi, Ops Area WG, =20 Every now and again, there are discussions on how to best characterize = or qualify a particular kind of "OAM", as well as misunderstandings due = to having different definitions and contexts for a given term. A case in = point is "in-band" or "out-of-band" OAM, as recently surfaced at = https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/= . =20 To alleviate this issue, Adrian and I wrote a short I-D to provide = forward-looking guidance on "foobar OAM". =20 We would appreciate feedback and input on this position, which aims at = updating the guidelines for the "OAM" acronym, with unambiguous = guidelines for their modifiers. =20 Guidelines for Charactering "OAM": https://datatracker.ietf.org/doc/draft-pignataro-opsawg-oam-whaaat-questi= on-mark/ =20 Look forward to input and comments to make this more clear and = effective! =20 Adrian & Carlos. =20 =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org =20 https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_0192_01DA458D.112E6750 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Greg,

 

Thanks for your = thoughtful inspection of our draft.

 

Carlos and I wanted = to be sure that all of the discussions of this draft were indexed on one = list, and we wanted to avoid multiple copies going to people who are = subscribed to multiple lists. So we asked that follow-ups went only to = OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC on this = email.

 

It was certainly not = our intent to disparage any work that was being done in any other = working group, and I understand the effort that has gone into the DetNet = OAM Framework to ensure that the terminology is clear and unencumbered = in the DetNet context.

 

Our concern was, = however, that different contexts are applying different definitions of = the terms =E2=80=9Cin-band=E2=80=9D and =E2=80=9Cout-of-band=E2=80=9D. = Those definitions are (often) clear and precise, but they are not = consistent across contexts. Thus, a water-tight definition in the DetNet = context is not universally applicable, and a reader coming to DetNet = from another context may bring with them their own understanding of the = terms.

 

Our intent, = therefore, is to select a finer-grained set of terms that have universal = applicability and that can be selected within a context without loss of = generality.

 

This is a tricky = little subject and I know that Carlos and I expected it to generate more = than a little discussion. If we end up with =E2=80=9Ceverything is OK = and nothing needs to change=E2=80=9D that will be OK with us. If we = discover that some work is using terms too generally, while others = already have perfect definitions, that will lead to something similar to = this document to bring the good into the light.

 

Further comments in = line=E2=80=A6

 

 

From: Greg Mirsky = <gregimirsky@gmail.com>
Sent: 12 January 2024 = 00:09
To: Carlos Pignataro <cpignata@gmail.com>; Adrian = Farrel <adrian@olddog.co.uk>
Cc: Ops Area WG = <opsawg@ietf.org>; IETF IPPM WG <ippm@ietf.org>; mpls = <mpls@ietf.org>; spring <spring@ietf.org>; DetNet WG = <detnet@ietf.org>
Subject: Re: [OPSAWG] New I-D -> = Guidelines for Charactering = "OAM"

 

  • Hi Carlos and Adrian,

thank you for starting this work. I believe that = having a common dictionary helps in having more productive discussions. = I took the liberty of inviting all the WGs which you invited to review = the document and added DetNet WG. Please feel free to trim the = distribution list.

I've = read the document and have several general questions to start our = discussion:

  • It seems that the motivation of this document is the = assumption that "in-band OAM" and "out-of-band OAM" = are not representative or cannot be understood or correctly attributed, = interpreted by the IETF community. Is = that correct?

I think the wording here would be = =E2=80=9Ccannot be reliably understood consistently=E2=80=9D. That is, = without looking at a context-specific definition (such as that which you = supply in the DetNet OAM Framework), the use of the terms may be = misinterpreted.

This is an assertion, but one (we think) is = founded on observation of recent conversations on mailing lists, and = also of witnessing many years of people talking passed each = other.

  • As we discuss and try to establish (change) the IETF = dictionary, it is important to analyze the terminology used by other = SDOs. I believe that it is beneficial to maintain consistent terminology = which will minimize misunderstandings among experts with different = experiences of working at different centers of technological = expertise.

This is a good point. It is certainly true that = if other SDOs working with packet networks have established terminology = that we can agree with and which is not, itself, subject to = context-specific definitions, then there is no reason to choose other = terms. Do you have any suggested sources?

It is notable that the ITU-T has long worked = with non-packet transport networks and has used the terms in-band and = out-of-band. But even there we see some fragmentation with terms such as = =E2=80=9Cin-fibre, but out-of-band=E2=80=9D becoming = necessary.

  • I that DetNet OAM Framework provides sufficiently clear interpretation of = terms that can be generalized for non-DetNet = networks:

   *  In-band OAM is an active OAM 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.

 

This, of course, does = not distinguish between =E2=80=9Cin-packet=E2=80=9D (such as IOAM), and = having its own packet (such as = ping).

 

<= p class=3DMsoNormal>   *  Out-of-band OAM is an active = OAM whose path through the = DetNet

      domain is not topologically = identical to the path of the = monitored

      DetNet flow, or its test packets = receive different QoS = and/or

      PREOF treatment, or = both.

As can be seen, the interpretation of = "in-band" accepted by the DetNet WG includes not only = topological equivalence between the monitored data flow and path = traversed by active OAM but also QoS equivalence between them. I believe = that is essential in differentiating in-band OAM from out-of-band = OAM.

 

Right. But is there = terminology to talk about a packet that does follow the topology, but = does not receive the same QoS treatment?

 

It is perhaps a little = strong to say this, but what you have done is define two classes of OAM = (both good things and meaningful in the DetNet context) and then = assigned existing names to those classes. What we are suggesting is that = you have some finer granularity categorisation of OAM available, and = that for the purposes of your DetNet work, you are collecting those = granularities into two different = sets.

  • I find the use of "path congruence" in inherently = meshed packet-switched networks confusing if not misleading. (Note that = RFC = 6669 explains congruence by using in-band term.) Is there = evidence of the term being used besides a single case in RFC = 6669?

Well, I would say that 6669 is an example of how = =E2=80=9Cin-band=E2=80=9D has been used, and I=E2=80=99d point out that = it does not match your DetNet OAM Framework definition (as there is no = mention of identical treatment). Note that the text from RFC 6669 is = replicated into RFC 7276 (same authors, same = subject).

You don=E2=80=99t say what you find misleading = or confusing. Is it that, in a meshed packet network, each individual = packet might be forwarded differently so that congruence cannot be = guaranteed? That could be true, but we hope for greater stability than = that, I think.

If =E2=80=9Cpath congruence=E2=80=9D was a new = term (with only one previous use) that might make it a really neat term = to use (because it would lack all previous meanings). However, it is = not. It has been used (to mean the same set of links, ports, and nodes) = in our more path-oriented work such as RFC 5828, RFC 6373, right up to = RFC 9059.

Perhaps =E2=80=9Ccongruent=E2=80=9D is = overloaded given that we are not talking about =E2=80=9Ctopological = congruence=E2=80=9D, a term that is also quite widely used (e.g., RFC = 2796, RFC 4258, RFC 5059, RFC 6549, RFC 8795)

  • Similarly, "in-packet" vs. "dedicated = packet". I believe that RFC 7799 has = that addressed by using "active", "passive", and = "hybrid" terminology. Although these terms applied to = measurement methods, i.e., performance monitoring component of OAM, but, = in my opinion, can be extended to fault management = OAM.

Well, we agree that RFC 7799 can be used to = generate the terms "active = OAM", "passive OAM", and "hybrid OAM". Although = we think, for the benefit of clarity, the reader should not be left to = examine RFC 7799 and project meaning from performance monitoring to OAM = in general: they should be presented with a clear set of definitions = (per our section 3).

It is further our belief that the definitions of = active and passive OAM do not match with =E2=80=9Cin-packet=E2=80=9D and = =E2=80=9Cdedicated-packet=E2=80=9D. Indeed, possibly, the closest is = that =E2=80=9Cactive OAM=E2=80=9D is =E2=80=9Cdedicated-packet=E2=80=9D, = and =E2=80=9Chybrid OAM=E2=80=9D is =E2=80=9Cin-packet=E2=80=9D leaving = =E2=80=9Cpassive OAM=E2=80=9D to be just = observation.

  • It seems like the definition of Compound/Combined misses = the point that RFC 7799 already defines a hybrid measurement method = (not OAM but measurement methods) as a method in which elements of = active and passive measurement methods are used. Hence, hybrid is = already a combination of active and passive measurement methodologies = and the introduction of compound or combined terms is unnecessary, a = duplication of the existing and accepted terminology (at least in IPPM = WG). And "Active-Hybrid-Passive OAM" is the result of that = omission because, according to the definition in RFC 7799, = Active-Passive is Hybrid. Thus, Active-Hybrid-Passive is nothing else = but Hybrid-Hybrid. Does that make sense?

I should certainly have preferred it had RFC = 7799 not used the term =E2=80=9Chybrid=E2=80=9D to actually refer to a = third category that is not a hybrid of the first two categories. For the = definitions of active OAM and passive OAM, I don=E2=80=99t think the = combination matches the definition of hybrid = OAM.

So, perhaps, let=E2=80=99s stop referring to RFC = 7799=E2=80=99s definitions of not-actually-OAM-packets, and nail down = our own definitions. That will tell us whether we need two, three, four, = or more terms.

  • I cannot agree that RFC 7799 "adds to the = confusion" by pointing = that

   Passive performance metrics are assessed = independently of the = packets

   or traffic flows, and solely through = observation.  Some refer to = such

   assessments as "out of = band".

Indeed, passive measurement methods are not required = to use packets that are in-band with the monitored data flow. Usually, = the management plane protocol is used to collect, to perform the = observation function. In some cases, in-band active OAM packets may be = used, e.g., direct loss measurement in ETH-OAM.

 

Yes, but where is this =E2=80=9Cin-band with the = monitored data flow=E2=80=9D defined for a packet network? And you say = =E2=80=9Care not required to=E2=80=9D rather than =E2=80=9CMUST = NOT=E2=80=9D. That means that the passive methods might send their = packets with the monitored data flow or might not. =

We live in a world where there is not = necessarily a distinction between the MCN and DCN. =

 

I find that throw-away = sentence in RFC 7799 both helpful and unhelpful. It is helpful to know = that some people call this =E2=80=9Cout of band=E2=80=9D. It is = unhelpful to refer to an assessment method as =E2=80=9Cout of = band=E2=80=9D as there is no message or packet involved to be in or out = of band.

 

FWIW, I believe that RFC 7799 and DetNet OAM = Requirements already provide a clear terminology for OAM in general and = its elements, i.e., Fault Management and Performance = Monitoring.

 

OK. I suspect that we are going to have to come = up with a set of OAM techniques and ask you to categorise them according = to your terminology to see whether all bases are = covered.

 

But I am also going to = have to review your text from the DetNet OAM Framework because it = contains phrases that are not clear (to = me)=E2=80=A6

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In-band OAM is an = active OAM 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.

 

There is something = broken here. Maybe too many words. Perhaps you = mean=E2=80=A6

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In-band OAM is an = active OAM that 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 = within the monitored DetNet OAM domain

 

=E2=80=A6and=E2=80=A6

 

  = =C2=A0=C2=A0  Out-of-band OAM is an active OAM whose path through = the DetNet

      domain is not topologically = identical to the path of the monitored

      = DetNet flow, or its test packets receive different QoS = and/or

      PREOF treatment, or = both.

 

As noted before, this = leaves a few gaps.

  • Active = OAM that follows the same path, but does not receive the same QoS = treatment
  • There is = no distinction between instrumentation of data packets and dedicated = instrumentation packets

 

Cheers,

Adrian

 

On = Fri, Jan 5, 2024 at 12:39=E2=80=AFPM Carlos Pignataro <cpignata@gmail.com> = wrote:

Hi, = Ops Area WG,

 

Every now and again, there are discussions on how to = best characterize or qualify a particular kind of "OAM", as = well as misunderstandings due to having different definitions and = contexts for a given term. A case in point is "in-band" or = "out-of-band" OAM, as recently surfaced at https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ= -uxZNky-RTggpxkuk/.

 

To alleviate this issue, Adrian and I wrote a short = I-D to provide forward-looking guidance on "foobar = OAM".

 

We would appreciate feedback and input on this = position, which aims at updating the guidelines for the "OAM" = acronym, with unambiguous guidelines for their = modifiers.

 

Guidelines for Charactering = "OAM":

 

Look forward to input and comments to make this = more clear and effective!

 

Adrian & Carlos.

 

 

_______________________________________________
OPSA= WG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

------=_NextPart_000_0192_01DA458D.112E6750--