Re: [Detnet] OAM terms

gregory.mirsky@ztetx.com Thu, 08 July 2021 00:34 UTC

Return-Path: <gregory.mirsky@ztetx.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 B83213A1BA1; Wed, 7 Jul 2021 17:34:58 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Zs9o6AFFX-F2; Wed, 7 Jul 2021 17:34:53 -0700 (PDT)
Received: from mxus.zteusa.com (mxus.zteusa.com [4.14.134.162]) (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 780A53A1BA0; Wed, 7 Jul 2021 17:34:52 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id CA8F5D78E0208D5E7B07; Thu, 8 Jul 2021 08:34:51 +0800 (CST)
Received: from mgapp01.zte.com.cn ([10.36.9.142]) by mse-us.zte.com.cn with SMTP id 1680YjgR002977; Thu, 8 Jul 2021 08:34:45 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Thu, 8 Jul 2021 08:34:45 +0800 (CST)
Date: Thu, 8 Jul 2021 08:34:45 +0800 (CST)
X-Zmail-TransId: 2af960e648255aa31b82
X-Mailer: Zmail v1.0
Message-ID: <202107080834456919720@zte.com.cn>
In-Reply-To: <CO1PR11MB488183610A5998E038A85E1ED81A9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: 202107070450210858113@zte.com.cn, CO1PR11MB488183610A5998E038A85E1ED81A9@CO1PR11MB4881.namprd11.prod.outlook.com
Mime-Version: 1.0
From: <gregory.mirsky@ztetx.com>
To: <pthubert@cisco.com>
Cc: <detnet@ietf.org>, <raw@ietf.org>, <theoleyre@unistra.fr>, <David.Black@dell.com>, <balazs.a.varga@ericsson.com>, <Janos.Farkas@ericsson.com>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-us.zte.com.cn 1680YjgR002977
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/C0WX4o6NAvJ6XLqNleZGtBuqREQ>
Subject: Re: [Detnet] =?utf-8?q?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: Thu, 08 Jul 2021 00:34:59 -0000

Hi Pascal,
thank you for your kind consideration of my notes and the detailed answers to questions. I've been thinking about the Reverse OAM. As I understand the use case, please correct me if it is wrong, the goal of a Reverse OAM is not a measurement of any performance metric or making a snapshot of resource utilization, e.g., buffer utilization on ingress/egress interface. As I understand it, the Reverse OAM is to collect compounded, i.e., calculated over a period of time, based on a sequence of singleton metrics, information from nodes traversed by the monitored flow. In other words, the Reverse OAM is tasked with collecting the telemetry information. If that is the case, we may look into extending the HTS to be used in it. Based on my assumption and understanding, I'm updating the HTS draft to make it possible for an arbitrary node to transmit the HTS Follow-up packet with characteristic information of the monitored data flow. As a result, an egress node can transmit such packet di
 recting it towards the ingress of the flow with the engineered path that crosses nodes of interest. What do you think?

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: gregory mirsky10211915;
CC: detnet@ietf.org;raw@ietf.org;theoleyre@unistra.fr;David.Black@dell.com;balazs.a.varga@ericsson.com;Janos.Farkas@ericsson.com;
Date: 2021/07/07 06:34
Subject: RE: Re:[Detnet] OAM terms
Hello Greg:
Many thanks!
I committed https://raw.githubusercontent.com/raw-wg/raw-architecture/main/raw-architecture.txt?token=ABYHN4L5D5UAWDLRS6YK2XTA4WWSE 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 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. 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 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