From gregimirsky@gmail.com Sat Jan 13 16:52:23 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 DE9BAC14F5F7 for ; Sat, 13 Jan 2024 16:52:23 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 N7_wFdd_nnuQ for ; Sat, 13 Jan 2024 16:52:19 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1175EC14F5FB for ; Sat, 13 Jan 2024 16:52:19 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-42987bc95ffso50896391cf.1 for ; Sat, 13 Jan 2024 16:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705193538; x=1705798338; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4L17THFup3ErbCxZ7RAa48FIUd1lcwx0xeXixavdCD0=; b=HXQ7knfpH0ZMEdMFFWBN1uwntyWsTxWhJmlHVCJNW4TuLmtrhxWhK1spbw7mMxjGzS nRv12I20ybG/M9SuzLmzzvW1GvWthb9rfED0RQlyG7Pqz7EW9eK5JFiSX53+sYVsJZiC hOBkcL6Gup7imisJ42B/X0ePbIJb9iAHZ3qSGtpIslzF6iYYuHIdjg082AVlHHgV8X4K SGwu7TtAs3aL3HO3DwVO//2uAYDMje5mFUXUwsdUQj+70E0g7KGAKTDgjwgTFBLSggo+ MhuIgAVtf9zA7HBFedLJfBDNz1L++g9k2QTaXYCuhryvmUnnST+Sh4Gci2v5UXn0ZacB o7+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705193538; x=1705798338; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4L17THFup3ErbCxZ7RAa48FIUd1lcwx0xeXixavdCD0=; b=vO1rRmQsCocde9nCK/OR8n+9QSeZaE90+rQW4RAkbt6Q/1AEbxo1tgkm7VFuteQl1j xmpq9TNxFPHilpR3eoxJIsj/fVmZAAb1f0mS5JRWF/KsZUEru5tLdwlP+K1SFdBoSuMP awqBVrCjORCQqpJqypdMfkqwAemPzwhi1uACoA7qp1S9ehN8VtlVNpI5kfp1AcmY+TIa JlMRnbp9o+URDNo4Fp72JIqcWDaaNVrFpEwctxr4sZUSoCJkugNrD3vL8ZyG7ouwbSm2 IctUrBdiCH180tec7frHK2VbUZ/wOia/bOj9KA78c1KnjB/r0Bng7zikQlhUr7gweK7K Xvow== X-Gm-Message-State: AOJu0YxlP8V6VkN+0+SefzD3gOQmmZW+D00b2uxxo7X73lfikg9Vxi9g 17sg19augX1kqtate9qEieGmqJzmlRoMBPZXQlU= X-Google-Smtp-Source: AGHT+IG1uUnWwbhgWkzdkbKXsIL6s7L1Vt4yhC1Lp/DSHFqXm/cIPO4mjFOms3JSwtDJ05/EqrtUnkt6NFodfv/7Tb8= X-Received: by 2002:ac8:4e51:0:b0:429:b7c7:1f8a with SMTP id e17-20020ac84e51000000b00429b7c71f8amr5261725qtw.30.1705193537493; Sat, 13 Jan 2024 16:52:17 -0800 (PST) MIME-Version: 1.0 References: <019101da458d$112c9290$3385b7b0$@olddog.co.uk> In-Reply-To: <019101da458d$112c9290$3385b7b0$@olddog.co.uk> From: Greg Mirsky Date: Sat, 13 Jan 2024 16:52:06 -0800 Message-ID: To: Adrian Farrel Cc: Carlos Pignataro , Ops Area WG Content-Type: multipart/alternative; boundary="00000000000013606b060edd4f55" Archived-At: X-Mailman-Approved-At: Mon, 15 Jan 2024 02:04:40 -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: Sun, 14 Jan 2024 00:52:24 -0000 --00000000000013606b060edd4f55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, thank you for your kind consideration of my notes. Please find my follow-up notes below tagged by GIM>>. Regards, Greg On Fri, Jan 12, 2024 at 11:25=E2=80=AFAM Adrian Farrel wrote: > 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 o= n > this email. > GIM>> Thank you. > > > 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 int= o > 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-ba= nd=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. > GIM>> Although the wording in the DetNet OAM Framework is indeed specific for DetNet environment, for example, the reference to DetNet service sub-layer and PREOF, the authors and the WG strived to make the definitions generic. I believe that we achieved a reasonable level of generality because the interpretation of "in-band/out-of-band" terminology in RAW OAM was based on our work in DetNet. I believe that it could be a reasonable way of building common understanding through a discussion of existing terms instead of fork-lifting and trying to invent something different that has not been used by any WG. > > > Our intent, therefore, is to select a finer-grained set of terms that hav= e > universal applicability and that can be selected within a context without > loss of generality. > GIM>> I agree with that wholeheartedly. > > > 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=9Ceve= rything is > OK and nothing needs to change=E2=80=9D that will be OK with us. If we di= scover > 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 > *Sent:* 12 January 2024 00:09 > *To:* Carlos Pignataro ; Adrian Farrel < > adrian@olddog.co.uk> > *Cc:* Ops Area WG ; IETF IPPM WG ; mpls < > mpls@ietf.org>; spring ; DetNet WG > *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 libert= y > of inviting all the WGs which you invited to review the document and adde= d > 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 b= e > 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 def= inition > (such as that which you supply in the DetNet OAM Framework), the use of t= he > 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 minimiz= e > 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 wit= h > 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? > IEEE 802.1Q 2014 uses in-band/out-of-band > 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 w= e > see some fragmentation with terms such as =E2=80=9Cin-fibre, but out-of-b= and=E2=80=9D > becoming necessary. > > - I that DetNet OAM Framework > > provides sufficiently clear interpretation of terms that can be genera= lized > 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). > > GIM>> The definition is for active OAM. Hybrid OAM, which, as I understan= d it, is referred to in the document as "in-packet", is inherently "in-band" with the monitored data flow. Looking back, perhaps we could have noted that in DetNet OAM Framework. Furthermore, I note that what is referred to as "in-packet" is identified as "on-path telemetry". What do you think about that term? > > > * 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? > > GIM>> Is there a case of useful information that an operator obtains in that scenario, i.e., when a test packet is topologically with the monitored flow but is marked by a different CoS and, as a result, receives a different QoS treatment? In other words, can topology and CoS marking be different between the monitored data flow and specially constructed test packets that are aimed to monitor that data flow? Personally, I am not aware of any useful information (except for direct loss measurement) that can be obtained using that setup and I conclude that active OAM must repeat topology of the data paths and use the same CoS marking. > > > 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. > > GIM>> As I noted above, I believe that topology and CoS are both requirements for an active OAM method and separating them "throws baby out of water". > > - 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 Framewor= k > definition (as there is no mention of identical treatment). Note that the > text from RFC 6669 is replicated into RFC 7276 (same authors, same subjec= t). > > 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 previo= us use) that > might make it a really neat term to use (because it would lack all previo= us > 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 t= alking about > =E2=80=9Ctopological congruence=E2=80=9D, a term that is also quite widel= y used (e.g., RFC > 2796, RFC 4258, RFC 5059, RFC 6549, RFC 8795) > GIM>> My concern with using "congruence" is most likely caused by how the term is used in geometry.And saying that "congruent paths" are paths that cross the same set of nodes and links seems like too narrow compared to the definition in geometry. And that raises my next question: Why not simply define the relationship between the data path and the path traversed by a test packet without introducing, what seems, an unnecessary term? > > - Similarly, "in-packet" vs. "dedicated packet". I believe that RFC > 7799 has that addressed by > using "active", "passive", and "hybrid" terminology. Although these te= rms > 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 d= o > 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 j= ust observation. > GIM>> I consider OAM to define a toolbox that contains tools based on active, passive, and hybrid methods in support of OAM functions (connectivity check, continuity verification, automatic protection switchover, and performance monitoring among others). Thus, I prefer to use the terminology of RFC 7799 that classifies measurement methods, not OAMs. > > - 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 duplicati= on 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. Thu= s, > Active-Hybrid-Passive is nothing else but Hybrid-Hybrid. Does that mak= e > 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 no= t 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 definitio= ns of > not-actually-OAM-packets, and nail down our own definitions. That will te= ll > us whether we need two, three, four, or more terms. > GIM>> I would note that the terminology introduced in RFC 7799 has been accepted and broadly used not only in the documents produced by IPPM WG but also many groups in the Routing area. > > - I cannot agree that RFC 7799 "adds to the confusion" by pointing tha= t > > 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 rathe= r 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. > > GIM>> Although there might be no topological distinction between MCN and DCN, it is more likely that they use different CoS markings. If that is the case, from the point of the definitions in DetNet OAM Framework, MCN is out-of-band relative to DCN. > > > I find that throw-away sentence in RFC 7799 both helpful and unhelpful. I= t > 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 t= o > 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 > > > > 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 > > > > In-band OAM is an active OAM that traverses the same set of links a= nd > > 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 > > > > 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. > GIM>> Many thanks for your thoughtful suggestion. I'll make sure that we apply this change in the course of AUTH48. > > > As noted before, this leaves a few gaps. > > - Active OAM that follows the same path, but does not receive the same > QoS treatment > > GIM>> That would be out-of-band > > - > - There is no distinction between instrumentation of data packets and > dedicated instrumentation packets > > GIM>> That is the distinction between hybrid and active OAM methods. > > - > > > > Cheers, > > Adrian > > > > On Fri, Jan 5, 2024 at 12:39=E2=80=AFPM Carlos Pignataro > 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 poi= nt > 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 guideline= s > for their modifiers. > > > > Guidelines for Charactering "OAM": > > > https://datatracker.ietf.org/doc/draft-pignataro-opsawg-oam-whaaat-questi= on-mark/ > > > > Look forward to input and comments to make this more clear and effective! > > > > Adrian & Carlos. > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > --00000000000013606b060edd4f55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
thank you= for your kind consideration of my notes. Please find my follow-up notes be= low tagged by GIM>>.

Regards,
Greg=

On Fri, Jan 12, 2024 at 11:25=E2=80=AFAM Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Greg,

=C2=A0

<= p class=3D"MsoNormal">Thanks for your th= oughtful inspection of our draft.

=C2=A0

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

GIM>> Thank you.=C2=A0

=C2=A0

It was certainly not our inte= nt to disparage any work that was being done in any other working group, an= d I understand the effort that has gone into the DetNet OAM Framework to en= sure that the terminology is clear and unencumbered in the DetNet context.<= u>

=C2=A0

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 prec= ise, but they are not consistent across contexts. Thus, a water-tight defin= ition in the DetNet context is not universally applicable, and a reader com= ing to DetNet from another context may bring with them their own understand= ing of the terms.

GIM>>= Although the wording in the DetNet OAM Framework is indeed specific for De= tNet environment, for example, the reference to DetNet service sub-layer an= d PREOF, the authors and the WG strived to make the definitions generic. I = believe that we achieved a reasonable level of generality because the inter= pretation of "in-band/out-of-band" terminology in RAW OAM was bas= ed on our work in DetNet. I believe that it could be a reasonable way of bu= ilding common understanding through a discussion of existing terms instead = of fork-lifting and trying to invent something different that has not been = used by any WG.

=

=C2=A0<= /u>

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

GIM>> I= agree with that wholeheartedly.=C2=A0

=C2=A0

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 w= ith =E2=80=9Ceverything is OK and nothing needs to change=E2=80=9D that wil= l 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 somethin= g similar to this document to bring the good into the light.<= /span>

= =C2=A0

Further comments in line=E2=80=A6

=C2=A0

= =C2=A0

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: 12 J= anuary 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>; spr= ing <spring@ietf.or= g>; DetNet WG <detnet@ietf.org>
Subject: Re: [OPSAWG] New I-D -> Gu= idelines for Charactering "OAM"

=C2=A0

  • Hi Carlos and Adrian,

thank you for starting this work. I belie= ve=C2=A0that having a common dictionary helps in having more productive dis= cussions. I took the liberty of inviting all the WGs which you invited to r= eview the document and added DetNet WG. Please feel free to trim the distri= bution list.

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

  • It s= eems that the motivation of this document is the assumption that "in-b= and OAM" and "out-of-band OAM" are not representative or can= not be understood or correctly attributed, interpreted=C2=A0by the IETF com= munity. Is that=C2=A0correct?

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.<= /u>

This is an assertion, but one (we think) is founded on observation of r= ecent 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 IE= TF dictionary, it is important to analyze the terminology used by other SDO= s. I believe that it is beneficial to maintain consistent terminology which= will minimize misunderstandings among experts with different experiences= =C2=A0of working at different centers of technological expertise.=

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

<= /div>
IEEE= 802.1Q 2014 uses in-band/out-of-band=C2=A0

It is notable that the ITU-T has l= ong worked with non-packet transport networks and has used the terms in-ban= d 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.<= u>

  • I that=C2=A0DetNet OAM Framework provides sufficiently clear inter= pretation of terms that can be generalized for non-DetNet networks:<= u>

=C2=A0 =C2=A0*=C2=A0 In-band= OAM is an active OAM that is in-band within the monitored

=C2=A0 =C2=A0 =C2= =A0 DetNet OAM domain when it traverses the same set of links and=

=C2=A0 =C2= =A0 =C2=A0 interfaces receiving the same QoS and Packet Replication,=

=C2=A0 = =C2=A0 =C2=A0 Elimination, and Ordering Functions (PREOF) treatment as the<= u>

= =C2=A0 =C2=A0 =C2=A0 monitored DetNet flow.

=C2=A0

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

=
GIM>> The definition is for active OAM. Hybri= d OAM, which, as I understand it, is referred=C2=A0to in the document as &q= uot;in-packet", is inherently "in-band" with the monitored d= ata flow. Looking back, perhaps we could have noted that in DetNet OAM Fram= ework. Furthermore, I note that what is referred to as "in-packet"= ; is identified as "on-path telemetry". What do you think about t= hat term?

<= /span>

= =C2=A0

= =C2=A0 =C2=A0*=C2=A0 Out-of-band OAM is an active OAM whose path through th= e DetNet

=C2=A0 =C2=A0 =C2=A0 domain is not topologically identical to the pa= th of the monitored

=C2=A0 =C2=A0 =C2=A0 DetNet flow, or its test packets rec= eive different QoS and/or

=C2=A0 =C2=A0 =C2=A0 PREOF treatment, or both.

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

=C2=A0

Right. But is there terminolo= gy to talk about a packet that does follow the topology, but does not recei= ve the same QoS treatment?

<= /div>
GIM>> Is there a case = of useful information that an operator obtains in that scenario, i.e., when= a test packet is topologically with the monitored flow but is marked by a = different CoS and, as a result, receives a different QoS treatment? In othe= r words, can topology and CoS marking be different between the monitored da= ta flow and specially constructed=C2=A0test packets that are aimed to monit= or that data flow? Personally, I am not aware of any useful information (ex= cept for direct loss measurement) that can be obtained using that setup and= I conclude that active OAM must repeat topology of the data paths and use = the same CoS marking.
<= div>

<= u>

= =C2=A0

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 D= etNet context) and then assigned existing names to those classes. What we a= re suggesting is that you have some finer granularity categorisation of OAM= available, and that for the purposes of your DetNet work, you are collecti= ng those granularities into two different sets.

GIM>= > As I noted above, I believe that topology and CoS are both requirement= s for an active OAM method and separating them "throws baby out of wat= er".=C2=A0

=

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

Well, I would say that 66= 69 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 definiti= on (as there is no mention of identical treatment). Note that the text from= RFC 6669 is replicated into RFC 7276 (same authors, same subject).<= u>

= 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 differe= ntly so that congruence cannot be guaranteed? That could be true, but we ho= pe for greater stability than that, I think.

If =E2=80=9Cpath congru= ence=E2=80=9D was a new term (with only one previous use) that might make i= t 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, righ= t 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 5= 059, RFC 6549, RFC 8795)

GIM>> My concern with using "congruence"= ; is most likely caused by how the term is used in geometry.And saying that= "congruent paths" are paths that cross the same set of nodes and= links seems like too narrow compared to the definition in geometry. And th= at raises my next question: Why not=C2=A0simply define the relationship bet= ween the data path and the path traversed by a test packet without introduc= ing, what seems, an unnecessary term?

  • Similarly, "in-packet" vs. "dedicated packet".= I believe that RFC 7799=C2=A0has that addressed by using "active"= ;, "passive", and "hybrid" terminology. Although these = terms applied to measurement methods, i.e., performance monitoring componen= t of OAM, but, in my=C2=A0opinion, 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 o= f clarity, the reader should not be left to examine RFC 7799 and project me= aning from performance monitoring to OAM in general: they should be present= ed with a clear set of definitions (per our section 3).

It is furth= er our belief that the definitions of active and passive OAM do not match w= ith =E2=80=9Cin-packet=E2=80=9D and =E2=80=9Cdedicated-packet=E2=80=9D. Ind= eed, 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=9C= in-packet=E2=80=9D leaving =E2=80=9Cpassive OAM=E2=80=9D to be just observa= tion.

GIM>> I consider OAM to define a toolbox that contains tools based o= n active, passive, and hybrid methods in support of OAM functions (connecti= vity check, continuity verification, automatic protection switchover, and p= erformance monitoring among others). Thus, I prefer to use the terminology = of RFC 7799 that classifies measurement methods, not OAMs.

  • It seems like the definition of Compound/Comb= ined misses the point that RFC 7799 already defines a hybrid=C2=A0measureme= nt method (not OAM but measurement methods) as a method in which=C2=A0eleme= nts of active and passive=C2=A0measurement methods are used. Hence, hybrid = is already a combination of active and passive measurement methodologies an= d the introduction of compound or combined terms is unnecessary, a duplicat= ion of the existing and accepted terminology (at least in IPPM WG). And &qu= ot;Active-Hybrid-Passive OAM" is the result of that omission because, = according to the definition in RFC 7799, Active-Passive is Hybrid. Thus, Ac= tive-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 an= d 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 77= 99=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 t= erms.

GIM>> I would note that the terminology introduced in RFC 7799 has b= een accepted and broadly used not only in the documents produced by IPPM WG= but also many groups in the Routing area.=C2=A0

=

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

=C2=A0 =C2=A0Passive perfor= mance metrics are assessed independently of the packets

=C2=A0 =C2= =A0or traffic flows, and solely through observation.=C2=A0 Some refer to su= ch

=C2=A0 =C2=A0assessments as "out of band".<= /u>

Indeed, passive measur= ement methods are not required to use packets that are in-band with the mon= itored data flow. Usually, the management plane protocol is used to collect= , to perform the observation function. In some cases, in-band active OAM pa= ckets may be used, e.g., direct loss measurement in ETH-OAM.<= /p>

=C2=A0

Yes, but where is this =E2=80=9Cin-band wi= th the monitored data flow=E2=80=9D defined for a packet network? And you s= ay =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 t= he monitored data flow or might not.

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

=
GIM>> Although= there might be no topological distinction between MCN and DCN, it is more = likely that they use different CoS markings. If that is the case, from the = point of the definitions in DetNet OAM Framework, MCN is out-of-band relati= ve to DCN.=C2=A0

=C2=A0

I find tha= t 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 un= helpful to refer to an assessment method as =E2=80=9Cout of band=E2=80=9D a= s there is no message or packet involved to be in or out of band.=

=C2=A0

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

=C2=A0

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

<= u>=C2=A0

But I am also going to have to review your text from the DetNe= t 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=C2=A0 In-band OAM is a= n active OAM that is in-band within the monitored

<= p class=3D"MsoNormal">=C2=A0 =C2=A0 =C2= =A0 DetNet OAM domain when it traverses the same set of links and=

= =C2=A0 =C2=A0 =C2=A0 interfaces receiving the same QoS and Packet Replicati= on,

=C2=A0 =C2=A0 =C2=A0 Elimination, and Ordering Functions (PREOF)= treatment as the

=C2=A0 =C2=A0 =C2=A0 monitored DetNet flow.=

=C2=A0

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

=C2=A0

=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

= =C2=A0 =C2=A0 =C2=A0 interfaces receiving the same QoS and Packet Replicati= on,

=C2=A0 =C2=A0 =C2=A0 Elimination, and Ordering Functions (PREOF)= treatment as the

=C2=A0 =C2=A0 =C2=A0 monitored DetNet flow within = the monitored DetNet OAM domain

=

=C2=A0<= /u>

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

=C2=A0

=C2=A0 =C2=A0=C2=A0=C2=A0 Out-of-ba= nd OAM is an active OAM whose path through the DetNet<= /p>

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

=C2=A0 =C2=A0 =C2=A0 DetNet flow, or its test packets receive differe= nt QoS and/or

=C2=A0 =C2=A0 =C2=A0 PREOF treatment, or both.<= /p>

GIM>> Many thanks = for your thoughtful suggestion. I'll make sure that we apply this chang= e in the course of AUTH48.=C2=A0=C2=A0

=C2=A0

As noted before, this leaves a few gaps.

  • Active OAM that follows the same path, but does not receive the = same QoS treatment
GIM>> That would be out-of-band=C2=A0
  • There is = no distinction between instrumentation of data packets and dedicated instru= mentation packets
= GIM>> That is the distinction between hybrid and active OAM methods.<= /div>

    • =C2=A0=

    Ch= eers,

    Adrian

=C2=A0

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

Hi, Ops Area W= G,

=C2=A0

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

=C2=A0

<= /div>

Guidelines for Charactering "OAM"= ;:

=C2=A0

Look forward t= o input and comments to make this more=C2=A0clear and effective!<= /u>

=C2=A0

Adrian & Carlos.

=C2=A0

=C2=A0

____________= ___________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.= ietf.org/mailman/listinfo/opsawg

--00000000000013606b060edd4f55--