From gregimirsky@gmail.com Thu Jan 11 16:09:09 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 5B457C14F6E9; Thu, 11 Jan 2024 16:09:09 -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=ham 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 blxpoz1yY9HR; Thu, 11 Jan 2024 16:09:05 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 D41E8C14F6E4; Thu, 11 Jan 2024 16:09:04 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3373bc6d625so4936594f8f.3; Thu, 11 Jan 2024 16:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705018143; x=1705622943; 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=ox+Nh+1ZEdapwhTqEpJ3fNLrN864hPdCtT89JLfG2Ew=; b=O50O99SLNd94UE7C8pW5/4rqLX0QYXxtuB79+5jeoEjOel0KAAIXOExLHzYG0wmz2q E6QwtIKNqL7UkhqqvVe32cvg/S+zSVj4+OQ4qXhwrqtdBHOToYoQ9iAF99BuaN0wwe1/ E6li/sMqEnw7pMH2mRSJW5CdOa+l570FbJqG+8UByYpnQYqLb5/EiPS0R/6uUyzYs8sw hK5NQq1s8yM9vzVzpgOmlnE3v881U4tzRXA/V+qJnl6Ui151ZZzZZZ9V3nI2EVpX8djt odLqAOI6XmkSRwgaaXobronxaspMblbL3ef9u+BmRVac4IYb5tWftyzHep7lEvJiP+kx dy7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705018143; x=1705622943; 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=ox+Nh+1ZEdapwhTqEpJ3fNLrN864hPdCtT89JLfG2Ew=; b=ZP6NzJMzvshrVkIz3bC2dw/RYSrfndSjshirs0neJ+mZLNIPNMjYCE7tztWghcnT3n Zgi9kQa+rEA2h3RuxhYpDPg+tvdVmDcvJS4qdK5GxcSfEKSDQtycuPoVpjd1MLBRpa1E c2aVMkI876ssqnolLNCf/TIZOmB7GdmjVBF6J+w2vvQ2ayh6ZRHkDpRX9wilNP3MiwP8 83VjFh6/q81y0gQZgc6NaVwj+oh9bASrV5vqNfDQN5HtuWFCMnbjNFF7ziQRbxLhZon5 zwUjIMl6BUjildSPoieH5oPhmQGm/eGsT8DL4Qza1E01uNK+oN/VGY/Z4cNsZEo48z+E tm+w== X-Gm-Message-State: AOJu0YwHuaW/YtgIU8X4Vsct4Q9KNY69R37rXKNM/uRByWeg0O+A3UTB jt82PA1alSFClzX3Ivsy/+d0+Huf+elski7yvqLlHSSNTmk= X-Google-Smtp-Source: AGHT+IHbfLQat7JOyreYkDwIYo3Ff2EfKjhIC6OJHmYnJ1hgtvYdkkzvVUKX9DwyJE8egHSP52rNLlS3qmwjDh/kaGc= X-Received: by 2002:adf:ec8f:0:b0:337:49e0:d19f with SMTP id z15-20020adfec8f000000b0033749e0d19fmr230476wrn.122.1705018142551; Thu, 11 Jan 2024 16:09:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 11 Jan 2024 16:08:50 -0800 Message-ID: To: Carlos Pignataro , Adrian Farrel Cc: Ops Area WG , IETF IPPM WG , mpls , spring , DetNet WG Content-Type: multipart/alternative; boundary="000000000000b8f107060eb478bb" Archived-At: 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 00:09:09 -0000 --000000000000b8f107060eb478bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable - 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. I= s that correct? - 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. - I that DetNet OAM Framework provides sufficiently clear interpretation of terms that can be generali= zed 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. * 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. - I find the use of "path congruence" in inherently meshed packet-switched networks confusing if not misleading. (Note that RFC 666= 9 explains congruence by using in-band term.) Is there evidence of the term being used besides a single case in RFC 6669? - Similarly, "in-packet" vs. "dedicated packet". I believe that RFC 7799 has that addressed by using "active", "passive", and "hybrid" terminology. Although these terms appl= ied to measurement methods, i.e., performance monitoring component of OAM, b= ut, in my opinion, can be extended to fault management OAM. - 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 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. 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. Regards, Greg 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 > --000000000000b8f107060eb478bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
  • Hi Carlos and Adrian,
thank you for startin= g this work. I believe=C2=A0that having a common dictionary helps in having= more productive discussions. I took the liberty of inviting all the WGs wh= ich you invited to review the document and added DetNet WG. Please feel fre= e to trim the distribution list.
I've read the document and h= ave 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 c= annot be understood or correctly attributed, interpreted=C2=A0by the IETF c= ommunity. Is that=C2=A0correct?
  • As we discuss and try to establish = (change) the IETF dictionary, it is important to analyze the terminology us= ed by other SDOs. I believe that it is beneficial to maintain consistent te= rminology which will minimize misunderstandings among experts with differen= t experiences=C2=A0of working at different centers of technological experti= se.
  • I that=C2=A0DetNet OAM Framework provides sufficient= ly clear interpretation of terms that can be generalized for non-DetNet net= works:
=C2=A0 =C2=A0*=C2=A0 In-band OAM is a= n active OAM that is in-band within the monitored
=C2=A0 =C2=A0 =C2=A0 DetNet OAM domain when it traverses the same se= t of links and
=C2=A0 =C2=A0 =C2=A0 interfa= ces receiving the same QoS and Packet Replication,
=C2=A0 =C2=A0 =C2=A0 Elimination, and Ordering Functions (PREOF) tr= eatment as the
=C2=A0 =C2=A0 =C2=A0 monitor= ed DetNet flow.

=
=C2=A0 =C2=A0*=C2=A0 Out-of-band OAM is an active OAM whose path = through the DetNet
=C2=A0 =C2=A0 =C2=A0 dom= ain is not topologically identical to the path of the monitored
=
=C2=A0 =C2=A0 =C2=A0 DetNet flow, or its test packets = receive different QoS and/or
=C2=A0 =C2=A0 = =C2=A0 PREOF treatment, or both.
=
As can be seen, the interpretation of "in-band" accepted by = the DetNet WG includes not only topological equivalence=C2=A0between the mo= nitored data flow and path traversed by active OAM but also QoS equivalence= between them. I believe that is essential in differentiating in-band OAM f= rom out-of-band OAM.
FWIW, I believe that RFC 7799 and DetNet OAM Requirements already provid= e a clear terminology for OAM in general and its elements, i.e., Fault Mana= gement and Performance Monitoring.

Regards,
Gr= eg

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 ar= e discussions on how to best characterize or qualify a particular kind of &= quot;OAM", as well as misunderstandings due to having different defini= tions and contexts for a given term. A case in point is "in-band"= or "out-of-band" OAM, as recently surfaced at=C2=A0https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZ= Nky-RTggpxkuk/.

To alleviate this issue, Adria= n and I wrote a short I-D to provide forward-looking guidance on "foob= ar OAM".

We would appreciate=C2=A0feedback an= d input on this position, which aims at updating the guidelines for the &qu= ot;OAM" acronym, with unambiguous guidelines for their modifiers.

Guidelines for Charactering "OAM":
=

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

Adrian & Carlos.


_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
--000000000000b8f107060eb478bb--