Re: [ippm] [OPSAWG] Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)

Italo Busi <Italo.Busi@huawei.com> Tue, 19 December 2023 11:05 UTC

Return-Path: <Italo.Busi@huawei.com>
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 A2601C17C536; Tue, 19 Dec 2023 03:05:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 rRRmZ3qPkEFV; Tue, 19 Dec 2023 03:05:02 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AFCDC1AE940; Tue, 19 Dec 2023 03:04:59 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SvYgv4C4Bz6K99X; Tue, 19 Dec 2023 19:02:51 +0800 (CST)
Received: from frapeml100008.china.huawei.com (unknown [7.182.85.131]) by mail.maildlp.com (Postfix) with ESMTPS id 1864E140390; Tue, 19 Dec 2023 19:04:55 +0800 (CST)
Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100008.china.huawei.com (7.182.85.131) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 19 Dec 2023 12:04:44 +0100
Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.035; Tue, 19 Dec 2023 12:04:44 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "xiong.quan@zte.com.cn" <xiong.quan@zte.com.cn>, "gregimirsky@gmail.com" <gregimirsky@gmail.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "pascal.thubert@gmail.com" <pascal.thubert@gmail.com>, "opsawg@ietf.org" <opsawg@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [OPSAWG] Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)
Thread-Index: AQHaMSPHK6WZL88W9UWjdONd3hvH3rCwcybQ
Date: Tue, 19 Dec 2023 11:04:44 +0000
Message-ID: <9ddfe667b23f4d11b36282f4829e7ea5@huawei.com>
References: <202312141056289511089@zte.com.cn> <017501da3008$fcf69120$f6e3b360$@olddog.co.uk> <PH0PR03MB63004603BF3973114F028D75F691A@PH0PR03MB6300.namprd03.prod.outlook.com> <PH0PR03MB630063FCBBFC5C9686DF75CBF691A@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB630063FCBBFC5C9686DF75CBF691A@PH0PR03MB6300.namprd03.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.111]
Content-Type: multipart/alternative; boundary="_000_9ddfe667b23f4d11b36282f4829e7ea5huaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/UnM079CJQpOPdhtAG40UJ9-xDhc>
X-Mailman-Approved-At: Tue, 19 Dec 2023 04:13:42 -0800
Subject: Re: [ippm] [OPSAWG] Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Dec 2023 11:05:06 -0000

Hi Sasha,

IMHO, LSP ping and BFD are examples of in-band OAM which may have either an in-band or an out-of-band return path (upstream OAM from the terminology below)

An example of out-of-band OAM can be the RSVP-TE notification messages. There are other examples of out-of-band OAM mechanisms in the WDM network but I am not sure whether they are or not in the scope of this thread.

In a nutshell:

  *   I think it is useful to distinguish between in-band and out-of-band OAM in the definition
  *   The definition for upstream OAM is incomplete since there are examples where the upstream OAM can be sent in-band

My 2 cents

Italo

From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Sent: domenica 17 dicembre 2023 07:33
To: adrian@olddog.co.uk; xiong.quan@zte.com.cn; gregimirsky@gmail.com
Cc: mpls@ietf.org; ipv6@ietf.org; ippm@ietf.org; pascal.thubert@gmail.com; opsawg@ietf.org; detnet@ietf.org
Subject: Re: [OPSAWG] Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)

Hi all,
My previous message inadvertently have been sent before completion.

Please see the completed text now.

Regards,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Sent: Sunday, December 17, 2023 8:29:11 AM
To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk> <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>; xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn> <xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn>>; gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org> <mpls@ietf.org<mailto:mpls@ietf.org>>; ipv6@ietf.org<mailto:ipv6@ietf.org> <ipv6@ietf.org<mailto:ipv6@ietf.org>>; ippm@ietf.org<mailto:ippm@ietf.org> <ippm@ietf.org<mailto:ippm@ietf.org>>; pascal.thubert@gmail.com<mailto:pascal.thubert@gmail.com> <pascal.thubert@gmail.com<mailto:pascal.thubert@gmail.com>>; opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>>; detnet@ietf.org<mailto:detnet@ietf.org> <detnet@ietf.org<mailto:detnet@ietf.org>>
Subject: Is out-of-band OAM relevant? (Was: IOAM, iOAM, and oOAM abbreviations)

Hi all,
For me this thread triggered a presumably naive question reflected in the changed subject line:

Why is out-of-band OAM useful or relevant?

I have looked the definition of out-if-band OAM in Section 2.6.3 of the RAW Architecture draft, and it says:

<quote>

Out-of-band OAM is an active OAM whose path is not topologically congruent to the Track, or its test packets receive a QoS and/or PAREO treatment that is different from that of the packets of the data flows that are injected in the Track, or both.
<end quote>

There is only one reference to this definition in Section 2.6.5 "Upstream OAM" of the draft that says:

<quote>

An upstream OAM packet is an Out-of-Band OAM packet that traverses the Track from egress to ingress on the reverse direction, to capture and report OAM measurements upstream. The collection may capture all information along the whole Track, or it may only learn select data across all, or only a particular DetNet Path, or Segment of a Track.
<end quote>

Of course, this is quite useful and quite common (Ping, LSP Ping and Seamless BFD are three examples that come first to my mind.

But I seriously doubt this common mechanism deserves a special term, and an abbreviation for this term looks quite unnecessary.

Regards,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Sent: Saturday, December 16, 2023 12:18:32 PM
To: xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn> <xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn>>; gregimirsky@gmail.com<mailto:gregimirsky@gmail.com> <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org> <mpls@ietf.org<mailto:mpls@ietf.org>>; ipv6@ietf.org<mailto:ipv6@ietf.org> <ipv6@ietf.org<mailto:ipv6@ietf.org>>; ippm@ietf.org<mailto:ippm@ietf.org> <ippm@ietf.org<mailto:ippm@ietf.org>>; pascal.thubert@gmail.com<mailto:pascal.thubert@gmail.com> <pascal.thubert@gmail.com<mailto:pascal.thubert@gmail.com>>; opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto:opsawg@ietf.org>>; detnet@ietf.org<mailto:detnet@ietf.org> <detnet@ietf.org<mailto:detnet@ietf.org>>
Subject: [EXTERNAL] Re: [mpls] [Detnet] IOAM, iOAM, and oOAM abbreviations

<My hats are off>

I suppose that I don’t object to the definition of new abbreviations if people are keen.

Personally, I don’t get the value of “inb-OAM” compared with “in-band OAM”. It’s not like it can be said faster (one additional syllable to say it) and it only saves four characters in typing.
“oob-OAM” is also marginal. Same number of syllables to say (I don’t think anyone pronounces “oob” as a single syllable), and a little more saving in typing.

Are the abbreviations worth it for the loss of clarity resulting from not using real words?

Cheers,
Adrian

From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of xiong.quan@zte.com.cn<mailto:xiong.quan@zte.com.cn>
Sent: 14 December 2023 02:56
To: gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; ipv6@ietf.org<mailto:ipv6@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>; pascal.thubert@gmail.com<mailto:pascal.thubert@gmail.com>; opsawg@ietf.org<mailto:opsawg@ietf.org>; detnet@ietf.org<mailto:detnet@ietf.org>
Subject: Re: [mpls] [Detnet] IOAM, iOAM, and oOAM abbreviations




Hi Greg,



Thanks for bringing this problem up!

I support to define the new abbreviations to help with the in-band OAM and out-of-band OAM.

And I prefer the inb-OAM and oob-OAM to precisely indicate the two original OAM and to distinguish from IOAM.



Best Regards,

Quan







<<Dear All,

<<Loa and I have discussed these abbreviations to help us find a solution

<<that avoids the confusion we found when we came across them. Firstly, what

<<they stand for:



   - IOAM - In-situ OAM (RFC 9197

   <https://datatracker.ietf.org/doc/rfc9197/>)

   - iOAM - in-band OAM (RAW architecture

   <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13>)

   - oOAM - out-of-band OAM (RAW architecture

   <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13>)



<<We discussed the issue with Pascal and came to slightly different

<<abbreviations for the last two:



   - inb-OAM

   - oob-OAM



<<We also discord these abbreviations with the RFC Editor. Resulting from

<<that, RFC Editor agreed to add IOAM to the RFC Editor Abbreviation List

<https://www.rfc-editor.org/materials/abbrev.expansion.txt>. The other two

abbreviations cannot be added at this time. If that is needed, we can ask

the RFC Editor to add them once the respective RFC is published.

We are seeking your feedback on the following:



   - Do you see the benefit of introducing two new abbreviations for

   in-band OAM and out-of-band OAM?

   - Which set of abbreviations (iOAM/oOAM vs. inb-OAM/oob-OAM) do you

   prefer for being used in IETF?

   - Or would you propose another set of abbreviations?



Regards,

Loa and Greg






Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.