Re: [Detnet] [Raw] OAM terms

"Wangyali(Yali,Data Communication Standards and Patents Dept)" <wangyali11@huawei.com> Wed, 07 July 2021 07:42 UTC

Return-Path: <wangyali11@huawei.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 75B4D3A0B0A; Wed, 7 Jul 2021 00:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 RDEWnyhk0cPO; Wed, 7 Jul 2021 00:42:51 -0700 (PDT)
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 9BF653A0B12; Wed, 7 Jul 2021 00:42:51 -0700 (PDT)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GKWMj32kzz6J65G; Wed, 7 Jul 2021 15:32:01 +0800 (CST)
Received: from dggpeml100024.china.huawei.com (7.185.36.115) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 7 Jul 2021 09:42:45 +0200
Received: from dggpeml500024.china.huawei.com (7.185.36.10) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 7 Jul 2021 15:42:44 +0800
Received: from dggpeml500024.china.huawei.com ([7.185.36.10]) by dggpeml500024.china.huawei.com ([7.185.36.10]) with mapi id 15.01.2176.012; Wed, 7 Jul 2021 15:42:44 +0800
From: "Wangyali(Yali,Data Communication Standards and Patents Dept)" <wangyali11@huawei.com>
To: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>, "pthubert=40cisco.com@dmarc.ietf.org" <pthubert=40cisco.com@dmarc.ietf.org>
CC: "theoleyre@unistra.fr" <theoleyre@unistra.fr>, "balazs.a.varga@ericsson.com" <balazs.a.varga@ericsson.com>, "David.Black@dell.com" <David.Black@dell.com>, "Janos.Farkas@ericsson.com" <Janos.Farkas@ericsson.com>, "raw@ietf.org" <raw@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Raw] [Detnet] OAM terms
Thread-Index: AQHXcqiz47kw7gdzkE2fC2jj5FfZfqs3D5iQ
Date: Wed, 07 Jul 2021 07:42:44 +0000
Message-ID: <e71f79aea349496dab977402f0f5797b@huawei.com>
References: <202107070450210858113@zte.com.cn>
In-Reply-To: <202107070450210858113@zte.com.cn>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.136]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/Lmu0ruEdpHHpnacxPVkBwKHzmOU>
Subject: Re: [Detnet] [Raw] 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 07:42:57 -0000

Hi Greg and Pascal,
Glad to join in this discussion. Please find my questions and notes inline Yali>>.
Thanks,
Yali

-----Original Message-----
From: RAW [mailto:raw-bounces@ietf.org] On Behalf Of gregory.mirsky@ztetx.com
Sent: Wednesday, July 7, 2021 4:50 AM
To: pthubert=40cisco.com@dmarc.ietf.org
Cc: theoleyre@unistra.fr; balazs.a.varga@ericsson.com; David.Black@dell.com; Janos.Farkas@ericsson.com; raw@ietf.org; detnet@ietf.org
Subject: Re: [Raw] [Detnet] OAM terms

Hi Pascal,
thank you for driving this important discussion. I wholeheartedly agree that consistency in terminology is fundamental for the successful development of technology as that helps us to communicate, avoiding unnecessary arguments and misunderstandings.
Please find my notes in-lined below under the tag GIM>>.

Kind regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: gregory.mirsky@ztetx.com
www.zte.com.cn
------------------Original Mail------------------
Sender: PascalThubert(pthubert)
To: DetNet WG;raw@ietf.org;
CC: Fabrice Theoleyre;Black, David;gregory mirsky10211915;Balázs Varga A;Janos Farkas;
Date: 2021/07/06 07:03
Subject: [Detnet] OAM terms
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet

Dear all
There’s a need in the DetNet OAM framework and in the RAW architecture/framework to agree on definitions that can be used on both sides to mean the same thing. At the DetNet OAM  call today, we agreed to work on that issue before cut off and publish aligned documents.
As a starting point, please find below the current text in the RAW document, largely based on a mix of RFC 6291 ans Greg’s sentences in the previous thread on this subject; you’ll  note the 2 original terms for reverse OAM and Limited OAM that need more refining.
Fire at will!
Pascal
AOM:
GIM>> This seems as a typo. s/AOM/OAM?
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.
Yali>> As described in this sentence that '' the system observed by the RAW OAM is the Track'' and based on my understand after reading the draft-pthubert-raw-architecture-08 and draft-ietf-raw-oam-support-02, the Track is categorized as  a simple Track and a complex Track, which stands for a multi-hop path or multi-hop N-ECMP. So my question is that do we only consider the Track (i.e. path) monitored in the RAW OAM domain? Or do we also consider the RAW flow? If the RAW flow for measuring its performance metrics, I suggest to fill up a RAW flow in this sentence " the system observed by the RAW OAM is the Track and a RAW flow".

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 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.

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. 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.
Yali>> Do we also consider "in-situ" OAM?

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 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)?

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?
Yali>> Does "Reverse OAM'' mean a packet generated by egress node and copy measurements metrics from Forward OAM packet, then transmitted by egress node to ingress node? If it is, my consider is that the "Reverse OAM" packet may not traverse the same Track with the "Forward OAM" packet traverses along. Besides, what's the North-South Track?