Re: [Detnet] OAM terms

Balázs Varga A <balazs.a.varga@ericsson.com> Wed, 07 July 2021 14:59 UTC

Return-Path: <balazs.a.varga@ericsson.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6AC3A1ABA; Wed, 7 Jul 2021 07:59:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_BTC_ID=0.498, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oml_R5FbZY9K; Wed, 7 Jul 2021 07:59:03 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00087.outbound.protection.outlook.com [40.107.0.87]) (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 64C2C3A1AB7; Wed, 7 Jul 2021 07:58:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XgjiVJ2wvrsFMbJ6aMWhZ/ZBSXpZibHhmB3dwPWY/XBb1tCTzFRwIimD06rnK+vZ2D7ZsbbaEI1OhBN+MxvE2Kmlat7Iu1rTftphStIsc4Y2tA9U4j+GGeebsbcv2mobzKmavZqUVM+JETqsivFwQdHU4lrGfipkDGOyv16u6ce8k2PIURcgDoWlxlyBSoUAyDjPICdqrA0D/JiIl3X0utITARI0f/5fsDD3JvLCOU4C16upDNuBd4X8J4ROFrQT0F2qerTzgZ0acmQmzq4qutL7xmGr180x1Y4NFftQ7V+ADBLAPRTU9irFlCjSMWxsQoJg7VTDmQfIy/PObD/yxA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+XM+W2DI4/UkcM1lX+dTt75hDQI4TSuHcC0Tf3cI60E=; b=aaSs9tQFIBzHSN0qQi+z3y1yyOJhgHs7Jt4zFhBw6pOlWZHpB7TAxRlu7sWiHDe2W2DGlZAj8nGsFSw5rZ9G7TzrOffBF+LQhJJKvdGsuXua3VJFkd9QBvaMis101m8MQz+eUBHCWswwhh5dAJ7IRji366Q0hmw4n6qV3BanoqKTOrW9+fi6gxvJnmQMQekLRh4bTz2epOlRwMdmQpdOKXsJ5olBy6OY+0TSq+6TpwMBFNRjSFOzgMYci+PDdzBHrHmzc3BegKYMlcKCntjMvSI8NbN1nan/RXZ+d20q83W4BE+vW6mKiOo+N5C7Tgah6dIV3zKu9Xuh8Om7ox3sAA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+XM+W2DI4/UkcM1lX+dTt75hDQI4TSuHcC0Tf3cI60E=; b=Xoo/5i62pZrAQmxGbqMrROnHqatI0H4mOwXuJBw8yUfIrir3R4hWehidWNKLbz/RUVaAyYqeQJ22oB0REcu8/rbx7zjyl2awe96Jz7sTFv6PRcaW3b9U2v5EAbD1BTzDzUUWGpNDkuAi3wL8e8UIRaER8ug6Lazu/fwNi4dugpM=
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com (2603:10a6:208:e7::31) by AM9PR07MB7284.eurprd07.prod.outlook.com (2603:10a6:20b:2c5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.14; Wed, 7 Jul 2021 14:58:50 +0000
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com ([fe80::e046:6a3b:148e:d7b9]) by AM0PR07MB5347.eurprd07.prod.outlook.com ([fe80::e046:6a3b:148e:d7b9%6]) with mapi id 15.20.4308.020; Wed, 7 Jul 2021 14:58:50 +0000
From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga@ericsson.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>
CC: "detnet@ietf.org" <detnet@ietf.org>, "raw@ietf.org" <raw@ietf.org>, "theoleyre@unistra.fr" <theoleyre@unistra.fr>, "David.Black@dell.com" <David.Black@dell.com>, Janos Farkas <Janos.Farkas@ericsson.com>
Thread-Topic: Re:[Detnet] OAM terms
Thread-Index: AQHXcqiSdISoKkPAlkGUapAlJFPL36s3hASAgAAUIRA=
Date: Wed, 7 Jul 2021 14:58:50 +0000
Message-ID: <AM0PR07MB53470C04D00AC0B898B101ACAC1A9@AM0PR07MB5347.eurprd07.prod.outlook.com>
References: <202107070450210858113@zte.com.cn> <CO1PR11MB488183610A5998E038A85E1ED81A9@CO1PR11MB4881.namprd11.prod.outlook.com>
In-Reply-To: <CO1PR11MB488183610A5998E038A85E1ED81A9@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ed68433f-7d0e-4e5b-556d-08d94157bb21
x-ms-traffictypediagnostic: AM9PR07MB7284:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM9PR07MB7284FDCD3EBFC6768DD8D52BAC1A9@AM9PR07MB7284.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LC/HOqic6osnybi7D6bNNhashq/kplXMHN3dUqEMDBYin0jNkt0opyqwp48S4OVmWgxALM0xrDAm8IYG+87BX2z3LoBKbEajkdd8t3viWSmjjB+PRBrEGKrwNjjPYfDH+P54sHo20prLAKlefk0KHiiJcEr1rnMfvqze/U+sj8l94927CMkEk2q0w0ZE57tKDC7mqlCirAUGI+YZ6QdN18hI/4h3pmIGyr8d3Q8ocUThqly0DkawcLbcmyBxK5AdiCnYI+oK3HRsepWbmqvSdXmX7wLqftssMwqWLt+OkPvXYOttwsOKXDiXv3X6rwHkByy9zVeeX51qLXscqSaRLRUUISljDmkQW0jjtDYx/CtikzfOSEbiN3tyXTXup9HKsowWrSDhZylhzB6IixwMi0JzJda/gpFT87wrHW+ynfZcx82Sid7gNcwVrrlzRbp6La7fJzZ5vys+jZx3e7OaI5TtOAWNQpodDOeSlnSX/GCAcqyioviciF0Mr3/UhVJ+ord0wgg/FqJDH9/mePKbbm5Y+LS790xYZ1edpi7vMiWVsD0FJ9DpLOddIHb3Roolw1MDxhOw+/6m4ix2DuSqqinreBng1HKz2V+n7A+GU8vAn/IIAVe61hCq+sJpcJzz3jlOlDLtMswyU9xXFu31CxOvfYU6LbjTEsp1g/2LRADYyzjbnQt+kXQJb984khFZf9JTlT/vlZJhnXH2xZC21uHEmqbjcKaN0DYQYVRsnbs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB5347.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(366004)(136003)(376002)(346002)(6506007)(83380400001)(26005)(86362001)(8676002)(85202003)(71200400001)(9686003)(5660300002)(38100700002)(55016002)(7696005)(122000001)(8936002)(53546011)(66574015)(186003)(110136005)(54906003)(52536014)(2906002)(478600001)(966005)(316002)(64756008)(4326008)(66556008)(76116006)(66946007)(107886003)(66476007)(66446008)(33656002)(85182001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VnVsUGNscHZJZDFLOSs3OHNmSTNUQVRrYkdTUTdMR2YvSTlmRW9RUUN2Y1k4?= =?utf-8?B?dWJYQ1NYaEgvZ2FQVGxYYXBpaXhQNmJmd1hxbUoxNGRxQ0g3YU91YU1xUnRw?= =?utf-8?B?K2RIS1V5MmVzUVNJb1BFT2NjSlpwa1kxVWRVbUtmNG1QOGloOGZTZ3FNSXFz?= =?utf-8?B?bG1GbnpVK0MvbXJ6cVh3czJ2K29wcGcvM1h2TnFPMW93V25kbXlRM2NNZEZO?= =?utf-8?B?Q3lJamtNQ1QzdW43UzVhdUtuUm9pRDBpTHg2NzdrdmhJQ0tsbEFXM2VwR1Vz?= =?utf-8?B?dFFOK3U3bXFGOWQxSmg0WlY4VE04UEgyZm5hZ2Rna3oxaVJGdHpZRGEramZn?= =?utf-8?B?T01hQ3NKWnVkQ0V5clRQNDEybml1bFpSVEFHYWQ3WDRIWE5xMTQ4TFZITVE3?= =?utf-8?B?QWVRaExOZFdKcUNhQVA0Q21CeGpNWU1FRVVLNVgydnZqRFFWRjZ0U1NpWHVn?= =?utf-8?B?cUFyT1JZTkxIZVNoSlJTTmJEOXU0WW92ZGg5bWREVzR4M1NEeExvMkN3dEFW?= =?utf-8?B?ZC9FOEFSN0RwZHdnN3lsMkNpK2w2OG5ISTlpdnowTVo2WTUxMTE5SjZXcys3?= =?utf-8?B?N0ZzY2k1L2RwZzZaRG9SNkljMm5wQ0Q1WEk1ekhMd0pVSEZIVmFWUXNlbFNy?= =?utf-8?B?ejl3N0dGSGg5L2dpMk5Pa2ppUHEzYUFTYlZiRmkzT3RkTGhBcTkzTGVSdmlz?= =?utf-8?B?ZHg0aFRyRnU3N0xYU3MzbEplUTdJSERJdmVyaC9abit0Zk40N01maktidWF3?= =?utf-8?B?aFNEOENJUXN1ekZtOG1FR3FwSDJLajRlNGRYa1BSYklBN29BQXE5Y3VxTzZq?= =?utf-8?B?ZXVRY3BBN0hiREpPbXY1Tms2OXlDM3U0VTdBbEcrYkVHb3EzMXljR3N5RDFy?= =?utf-8?B?dFRmMmRiYmRmOXpPY1NNZ3FoSlp4SkJZQkJPaHpmU3RhNzk3dkNpRmZ6N0Jl?= =?utf-8?B?RmtBMlBVMkM1Y2I0bnEvN05DS2NzNm5jWUlSQjBBT2VjNGZLTVQrM2x3VWlG?= =?utf-8?B?cW45QmN6R3dpMlNabTdKMWNYWnhJWU0vbmQwZFBTREx1WjNJankvU3NZckcz?= =?utf-8?B?NExraEtLdlVFZXhrWURzbDNsQzEyeEtLSXRVcTA5OFo5UGZ5bkR6cUozWjh4?= =?utf-8?B?Yy9TWUVYL1NWWnpCNklHNkRJeTh0SkZMd1E4L1RNTXpGSlJwNkxaU0hJdWxT?= =?utf-8?B?YVN5TkZPbXZTaEdJTXhzNEp1Mjk3SFFyMjZITkVkeWJNdjhhQ1lCcXcrS0VZ?= =?utf-8?B?Z1VMT2k4dk1VWGdpdmFwRml6NStGMHRCc3pGb1JTWjFFQ1ZudkxIZG14bzJs?= =?utf-8?B?MktTVkdyUlZkKzNvS0hPa2dFVHNtT0tvQ1RzVEdTZHlkdk1PZmRURWI5VXU4?= =?utf-8?B?b1hqN0gxQmtuVDZnV2liMWx5eUVSSlRuWnJneHpPdTZ0a255THlrc2h1clhH?= =?utf-8?B?Mkl6d1kwekFzSDYxaW92UHV4R1A0c0hhT1VCVFMwbm9zbnNOZkM5OUFMZkg2?= =?utf-8?B?Z3BRWjEraVZsNEZJQzJ6RUhFYjkxU3M3WVJld1kxMi9CZWFIVmRnTk1EdUFY?= =?utf-8?B?ZkNnRHZpTTNSbWRGNTBCQVdlMUNsVHNsRitBU1VvS0Q1WXdnaVgvVUhqUENS?= =?utf-8?B?MG5STVhQUW5sMzA2dmNiaXArMmFlYlhvL0pXem5MemI0L052eFhMbGhqY2VQ?= =?utf-8?B?NG5STCtsNmc2VlJHNGovem8wQWJ5c0dSRC9JbHUrRFA0bStaZXFuRDZraDM4?= =?utf-8?Q?ItK+I5yR7586tPzZzM=3D?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB5347.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ed68433f-7d0e-4e5b-556d-08d94157bb21
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 14:58:50.6020 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OvXribJH1uELHxZ369dZNqKlICLj+nTq9j9FOWTX4EzetBdnb9YKv8p+YyXNMqahVJJF25h3Jc8KoyvvHWl7dyjvW3YzSeVavDKqBwr7bDk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR07MB7284
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/56KkzVYJUFCk0tUhpq-ZvbzE3-U>
Subject: Re: [Detnet] OAM terms
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2021 14:59:09 -0000

Hi Pascal, All,

thanks for the initiatives and the great suggestions. I think before 
editing/fine-tuning the definitions we may need a common understanding,
what minimum terminology is necessary.

We may want to characterize an OAM session with just two characteristics:
(I.) what path OAM packets are using during forwarding and 
(II.) what resources OAM packets are using during forwarding.

General comments:
1, The terms MEP/MIP are well anchored with OAM. It would be great to
use them.
2, Discussion on the position of the originator entity of an OAM session.
This entity is a MEP. In my view this is an essential part of OAM discussion.
I fully support Greg's comment in this email-thread regarding the 
"Sub-Path Maintenance Element".
3, I have found terms "Track/SubTrack/Segment of a Track" confusing.
No such terms are defined for DetNet. If needed they have to be 
specified as well, but in my view they all refer to an OAM session 
between two MEPs (i.e., the originator MEP and the targeted MEP).

More in particular:
4, I am OK with the following terms after some massage:
- OAM: I am fine with the definition
- Active OAM: I would prefer a definition based on MEPs
- In-Band/Out-of-Band OAM: I would prefer a definition based on MEPs (and not Track)

5, I am not sure we need these definitions:
- Limited OAM: depends on the result of the originator-MEP placement discussion
whether such a term is needed (see item 3). This is also an OAM session, but the MEPs 
of the OAM session are not at the source/destination of the flow, but somewhere 
along the path.
- Reverse OAM: this seems to be a response OAM packet of a MEP/MIP sent 
to the originator of the OAM packet. So why not simple call it OAM-Response.
Furthermore, why is it highlighted, that it is an "out-of-band OAM packet"?
E.g., DetNet flows are unidirectional, therefore it cannot be in-band.

Have I missed something?

6, Some other terms may worth for consideration to cover all possible characteristics
(i) how OAM packets are forwarded and (ii) what resources they are using:
- In-path OAM/Out-path OAM: this is a characteristic how OAM packets reach their 
destination. "In-path" means using the same path as the related data flow. Note,
that an in-path OAM session can be in-band (usig the same resources as the dataflow) 
or out-of-band (not using the dataflow resources).
"Out-path" means that any path to destination can be used. Out-path OAM is always
"out-of-band" as well.

Thanks
Bala'zs


-----Original Message-----
From: Pascal Thubert (pthubert) <pthubert@cisco.com> 
Sent: Wednesday, July 7, 2021 3:33 PM
To: gregory.mirsky@ztetx.com
Cc: detnet@ietf.org; raw@ietf.org; theoleyre@unistra.fr; David.Black@dell.com; Balázs Varga A <balazs.a.varga@ericsson.com>om>; Janos Farkas <Janos.Farkas@ericsson.com>
Subject: RE: Re:[Detnet] OAM terms

Hello Greg:

Many thanks!

I committed https://protect2.fireeye.com/v1/url?k=3f207e70-60bb4775-3f203eeb-86959e472243-7f691555596d8b47&q=1&e=8befdca4-5db8-4c69-8706-08551b827e2e&u=https%3A%2F%2Fraw.githubusercontent.com%2Fraw-wg%2Fraw-architecture%2Fmain%2Fraw-architecture.txt%3Ftoken%3DABYHN4L5D5UAWDLRS6YK2XTA4WWSE for the discussion below, if you can please recheck that we are aligned so I can publish; more below:

> AOM:
> GIM>> This seems as a typo. s/AOM/OAM?

Yes typo sorry

> OAM stands for Operations, Administration, and Maintenance, and covers 
> the processes, activities, tools, and standards involved with 
> operating, administering, managing and maintaining any system.  This 
> document uses the terms Operations, Administration, and Maintenance, 
> in conformance with the IETF 'Guidelines for the Use of the "OAM" Acronym in the IETF'
> [RFC6291] and the system observed by the RAW OAM is the Track.
> Active OAM:  Active OAM uses specially constructed test packets 
> crafted to observe a particular Track, subTrack, or Segment of a Track.

> GIM>> Perhaps adding a reference to RFC 7799 Active and Passive 
> GIM>> Metrics
> and Methods (with Hybrid Types in-Between)? RFC 7799 provides clear 
> definitions for Active, Passive, and Hybrid OAM methods, particularly 
> when classifying Performance Monitoring OAM protocols.

Added in supplemental text

> In-Band OAM:  An active OAM packet is considered in-band in the 
> monitored Track when it traverses the same set of links and interfaces 
> receiving the same QoS and PAREO treatment as the data flows that are 
> injected in the Track.
> Out-of-Band OAM:  An active OAM packet is out-of-band if its datapath 
> is topologically the same as of that of the Track, subTrack or Segment 
> being observed, but the QoS or PAREO treatment is different (e.g., lower CoS).


> GIM>> I agree that that is a good example of out-of-band active OAM. 
> GIM>> Also,
> an out-of-band OAM may be using a diverse path, e.g., management network.
> Below is the text from the updated version of draft-ietf-detnet-oam-
> framework:
>    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.

I adapted that new text to RAW 

> 
> Limited OAM:  An active OAM packet is a Limited OAM packet when it is 
> observes the RAW operation over a node, a segment, or a subTrack of 
> the Track, though not from Ingress to Egress.  It is injected in the 
> datapath and extracted from the datapath around the particular 
> function or subnetwork (e.g., around a relay providing a service layer 
> replication
> point) that is being tested.

> GIM>> Can a node, a subTrack, and a segment be considered as examples 
> GIM>> of
> the same construct? In the course of describing OAM in MPLS-TP, a 
> Sub-Path Maintenance Element was introduced in Section 3.13 of RFC 
> 5921 (https://datatracker.ietf.org/doc/html/rfc5921#section-3.13). An 
> SPME is needed in the MPLS data plane because an active OAM packet 
> cannot be injected into an LSP by an LSR (only LER can inject a test 
> packet). An SPME is a hierarchical LSP that tunnels a section of the 
> transport LSP and creates MEPs at the section's end-points. Can we 
> re-use any of MPLS-TP OAM terminology (even though no one likes to be reminded of MPLS-TP)?

A Track is a networking graph where the edges are Segments and the vertices are (service layer) detnet relays, where a Segment is a sequence of Links connected by (forwarding layer) detnet transit nodes.
I believe these are all different concepts. 

That terminology seems useful beyond RAW though, because the term path is really anything and everything, see the definition of path in RFC 9049 vs. the detnet expectations. As you know there's hardly anything better than an approximate terminology to be completely misunderstood.

On the bright side, the logic of defining a sub-Track is consistent with that of defining a sub-path.

> 
> Reverse OAM:  A Reverse OAM packet is an Out-of-Band OAM packet that 
> traverses the Track from West to East and North-South in one of either 
> direction, to capture and report OAM measurements upstream.
> GIM>> As this is one method of collecting telemetry information, could 
> GIM>> it be described without giving it a distinct name?

The term is used in the main text. It appears useful. But are you saying that it is misleading?

Many thanks!

Pascal