[Detnet] Comments on I-D Action: draft-ietf-detnet-oam-framework-01.txt

[Balázs Varga A <[e-mail]>]

Hi Greg, co-authors,

Many thanks for the update. I have some further comments below.
I would propose to discuss them during the next DetNet OAM call
on 25th May if appropriate.

Comments:
Section 1. Introduction
TEXT 
   ... its ability to respect the Service Level
   Objectives (SLO), such as packet delay, delay variation, and packet
   loss ratio, assigned to each data flow.
>Comment1> Please, consider to add here "in-order-delivery" as well. It is also part of the SLO.

Section 1.1.  Terminology
TEXT
   *  OAM entity: a data flow to be monitored for defects and/or its
      performance metrics measured.
>Comment2> This definition is more the object of OAM. Would fit better to define "OAM entity" as a function that provides OAM related actions.

Section 2. Role of OAM in DetNet
General comment on the content.
>Comment3> It should be made clear here that general legacy OAM tools can be used for DetNet as well, however some DetNet specifics 
extensions may be needed.

>Comment4> Please consider to add here DetNet specifics, i.e., DetNet service sub-layer and forwarding sub-layer. Service sub-layer is service protection (i.e., PREOF) and forwarding sub-layer is for explicit route + dedicated/allocated resources. DetNet defines some new functions or use existing functions with some special requirements. Checking these functions with new or updated OAM tools is part of the framework document.

Section 3.  Operation
>Comment5> General question: should this chapter contain DetNet specific statements?

>Comment6> Specific question: I miss here the performance management related aspects. In case of DetNet, too late is also a failure.
PM should cover: loss, delay, delay variation and in-order-delivery.

Section 3.1. Information Collection
TEXT 
   Also, we can characterize methods of transporting OAM information
   relative to the path of data.
>Comment7> Please consider to extend the terminology. As processing of DetNet flow packets is time critical we may distinguish 4 scenarios:
- inside-flow: OAM information is placed inside a regular DetNet flow data packet
- outside-flow: OAM information is placed in extra packet(s)
- in-band (or in-path): OAM information uses same resources allocated for the monitored DetNet flow
- out-of-band (or out-of-path): OAM information uses different resources than allocated for the monitored DetNet flow

TEXT
   In the latter, information
   is collected in a sequence of follow-up packets that traverse the
   same path as the data packet of the monitored DetNet flow.
>Comment8> This text intends to refer to an out-of-band method. Is this statement correct? Should it say the opposite?

Section 3.2.  Continuity Check
TEXT
   Continuity check is used to monitor the continuity of a path, i.e.,
   that there exists a way to deliver the packets between two endpoints
   A and B.
>Comment9> Why are they called endpoints? Are A and B MEPs? Or A and B can any node along the e2e path, between them we intend to check the continuity?

Section 3.4. Route Tracing
TEXT
   DetNet with IP data plane is NOT RECOMMENDED to use multiple paths or
   links,
>Comment10> Why only IP? ECMP is in general not recommended for DetNet. It is valid for both IP and MPLS data plane.

3.7.  Use of Hybrid OAM in DetNet
General comment on section content.
>Comment11> Would fit better to section 2. Text is more a general statement of what OAM technics used for what in case of DetNet.

TEXT
   Hybrid OAM methods are used in performance monitoring and defined in
   [RFC7799] as:
>Comment12> PM should be covered in a dedicated section, not only in section 3.

Section 4.  Administration
TEXT
   The network SHOULD expose a collection of metrics to support an
   operator making proper decisions, including:
>Comment13> List should be extended. Adding here e.g., service sub-layer specific metrics, like packet processing resources, etc.

TEXT
   *  per virtual circuit to measure ...
>Comment14> This term is not used for DetNet. How is it related to DetNet? Should we use DetNet flow / member flow / compound flow instead?

TEXT
   *  per path to detect misbehaving path when multiple paths are
      applied.
>Comment15> What it intends to say? It sounds strange that a path has paths within itself. Does it meant a segment here? (E.g., Per segment to detect misbehaving path when multiple paths are applied.)

TEXT
   *  per device to detect misbehaving node, when it relays the packets
      of several flows.
>Comment16> "node" --> "function"? What is the relation of device/node?

Section 4.1. Collection of metrics
General comment.
>Comment17> Agree with the content but it is general text not a DetNet specific one. I think it would be good to add rationale, e.g., strict resource allocation/reservation per DetNet flow.

Section 5.1. Replication / Elimination
TEXT
   When multiple paths are reserved between two maintenance endpoints,
   packet replication may be used to introduce redundancy and alleviate
   transmission errors and collisions.
>Comment18> I do not think this is a valid statement. Placing MEPs and PREOF points are orthogonal. They may or may not be in the same node.
>Comment19> "alleviate transmission errors and collisions" are not really the target of PREOF. Are these RAW specifics?

TEXT
   ... Each maintenance endpoint will decide to trigger the packet
   replication, elimination or the ordering process when a set of
   metrics passes a threshold value.
>Comment20> I think such a function is not defined so far in DetNet. Is it something RAW specific? PREOF is not on-demand but something defined before data-flow forwarding starts.

TEXT
   Figure 1.
>Comment21> What is a "root" in the figure?

Section 5.2.  Resource Reservation
TEXT
   ... We need to provide mechanisms to patch the network
   configuration.
>Comment22> What does it mean " to patch the network configuration"? Is this a management function? In DetNet, the service sub-layer functions are envisioned to cope with such situations. However, in DetNet we consider failure of a path, not QoS degradation. Sound like a radio link specific statement ...

Section 5.3.  Soft transition after reconfiguration
TEXT
   Since DetNet expects to support real-time flows, DetNet OAM MUST
   support soft-reconfiguration,
>Comment23> Why OAM must support this? Is it not more a functionality implementation characteristics to be able to reconfigure without service interruption?

Section 6. Requirements
TEXT
   1.   It MUST be possible to initiate DetNet OAM session from any
        DetNet node towards another DetNet node(s) within given domain.
>Comment24> Do we need a definition in the Terminology section for DetNet OAM Session? 
(E.g., DetNet OAM session: exchanging OAM data between MEPs, or a better definition ...)

TEXT
   2.   It MUST be possible to initialize DetNet OAM session from a
        centralized controller.
>Comment25> Depending on the previous comment resolution: --> via a centralized controller? The SDNc is not a MEP.

TEXT
   3.   DetNet OAM MUST support proactive and on-demand OAM monitoring
        and measurement methods.
>Comment26> Why only these aspects (monitoring and management) of OAM? Proposed to be deleted and leave "... OAM methods."

TEXT
   5.   DetNet OAM MUST support unidirectional OAM methods, continuity
        check, connectivity verification, and performance measurement.
>Comment27> Is it an exhaustive list? What about e.g., fault localization / characterization?

TEXT
   6.   DetNet OAM MUST support bi-directional OAM methods.  Such OAM
        methods MAY combine in-band monitoring or measurement in the
        forward direction and out-of-bound notification in the reverse
        direction, i.e., from egress to ingress end point of the OAM
        test session.
>Comment28> " egress to ingress end point" Are these the MEPs?

TEXT
   8.   DetNet OAM MUST support Path Maximum Transmission Unit
        discovery.
>Comment29> Why is it DetNet specific? It is a general tool, not?

TEXT
   13.  DetNet OAM MUST support unidirectional performance measurement
        methods.  Calculated performance metrics MUST include but are
        not limited to throughput, packet loss, delay and delay
        variation metrics.  [RFC6374] provides detailed information on
        performance measurement and performance metrics.
>Comment30> How is this point related to requirement 6.5 (also mentioning PM)?
>Comment31> To be discussed whether adding "out-of-order" characteristics as well here.

TEXT
   15.  DetNet OAM MUST support methods to enable survivability of the
        DetNet domain.  These recovery methods MAY use protection
        switching and restoration.
>Comment32> " survivability" term not used in DetNet so far. How it is related to DetNet sub-layers? Is it a forwarding sub-layer functionality?

TEXT
   16.  DetNet OAM MUST support the discovery of Packet Replication,
        Elimination, and Order preservation sub-functions locations in
        the domain.
   17.  DetNet OAM MUST support testing of Packet Replication,
        Elimination, and Order preservation sub-functions in the domain.
>Comment33> "Order" --> "Ordering"
>Comment34>  "sub-functions" --> "functions". These are functions not sub-functions.

Special thanks if You have read so far ... :--)))))

Cheers
Bala'zs




-----Original Message-----
From: detnet <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, May 19, 2021 10:02 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Detnet] I-D Action: draft-ietf-detnet-oam-framework-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Deterministic Networking WG of the IETF.

        Title           : Framework of Operations, Administration and Maintenance (OAM) for Deterministic Networking (DetNet)
        Authors         : Greg Mirsky
                          Fabrice Theoleyre
                          Georgios Z. Papadopoulos
                          Carlos J. Bernardos
	Filename        : draft-ietf-detnet-oam-framework-01.txt
	Pages           : 14
	Date            : 2021-05-19

Abstract:
   Deterministic Networking (DetNet), as defined in RFC 8655, is aimed
   to provide a bounded end-to-end latency on top of the network
   infrastructure, comprising both Layer 2 bridged and Layer 3 routed
   segments.  This document's primary purpose is to detail the specific
   requirements of the Operation, Administration, and Maintenance (OAM)
   recommended to maintain a deterministic network.  With the
   implementation of the OAM framework in DetNet, an operator will have
   a real-time view of the network infrastructure regarding the
   network's ability to respect the Service Level Objective, such as
   packet delay, delay variation, and packet loss ratio, assigned to
   each data flow.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-detnet-oam-framework-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-oam-framework-01


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
detnet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet