Re: [Detnet] OAM terms

gregory.mirsky@ztetx.com Tue, 06 July 2021 20:50 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 B37583A0BD2; Tue, 6 Jul 2021 13:50:29 -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 zwrYx5iHqeh8; Tue, 6 Jul 2021 13:50:25 -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 0814C3A0BC6; Tue, 6 Jul 2021 13:50:24 -0700 (PDT)
Received: from mse-us.zte.com.cn (unknown [10.36.11.29]) by Forcepoint Email with ESMTPS id F01738EE61D6744C41DA; Wed, 7 Jul 2021 04:50:23 +0800 (CST)
Received: from mgapp02.zte.com.cn ([10.36.9.143]) by mse-us.zte.com.cn with SMTP id 166KoLiA080761; Wed, 7 Jul 2021 04:50:21 +0800 (GMT-8) (envelope-from gregory.mirsky@ztetx.com)
Received: from mapi (mgapp02[null]) by mapi (Zmail) with MAPI id mid81; Wed, 7 Jul 2021 04:50:21 +0800 (CST)
Date: Wed, 7 Jul 2021 04:50:21 +0800 (CST)
X-Zmail-TransId: 2afa60e4c20d04feb66c
X-Mailer: Zmail v1.0
Message-ID: <202107070450210858113@zte.com.cn>
Mime-Version: 1.0
From: <gregory.mirsky@ztetx.com>
To: <pthubert=40cisco.com@dmarc.ietf.org>
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 166KoLiA080761
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/ZqRj9ZxtUUHNQB0KBrmuetschcU>
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: Tue, 06 Jul 2021 20:50:31 -0000

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

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 it be described without giving it a distinct name?