Re: [Detnet] Comments on I-D Action: draft-ietf-detnet-oam-framework-01.txt
Balázs Varga A <balazs.a.varga@ericsson.com> Sun, 06 June 2021 10:58 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 498723A1632 for <detnet@ietfa.amsl.com>; Sun, 6 Jun 2021 03:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 4eufDtxd9CcZ for <detnet@ietfa.amsl.com>; Sun, 6 Jun 2021 03:58:09 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2074.outbound.protection.outlook.com [40.107.21.74]) (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 A02113A1631 for <detnet@ietf.org>; Sun, 6 Jun 2021 03:58:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jmqnu9Z54sxE1wvm+8QotX2FRh4okR+rZNlt4p7qPC0kZaEnGUkjUcIH9wQR1ZSMW9Yk5fikIQ1Ih7iEMMKZmRrP7tZU4R8oKoxzvQHu/Q9eR7EKFPWpe5yvZ4tqljiZHTvVVyfINmsIbNNSOJiv+CjXBLTELiLOdCMnw9cQfz8cqacpdcxiuhE50pmWpyaU2dHKKc43IEiZHuplndTMddXZxL5Dadnm6PV4rswrZPAF97XApPOkTZTPSlpERufN8/p3x9nQe95oM7oe//pEcZbArrydSs38zNdLW4ty87T+7x9mVmR5imefzLHboInWCwYto6F+jYQLgFgNA9tlcA==
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=IZCvGIhTHBdOtzR4HrjNAXPIH4l5riJKBsemmfL/MTY=; b=HSInrgG9B4tymAuiz9Is5Y8fXcfoqThoAOJF+ALPIbePqxXxZZg1kzhpZyAI7YMihzGXRlsF7pf6nXBAoDet0i0EvPgRi2ks0MWWhF5RRRkFFOtUgzDr8wQJ3rNIlr7v+z3lhDob0uJS/Pr2Lgz1i60sX0H8aHxQ8f9U/hdwOvFtFoHDIaFVONsuoZOfdO8BR2Exk0Hl4AITfXjiaupmR2U+bBzsYK74N2/vvjvHfCUTQ852txo14oIWRYA3ZauEXznzFw6If6JHkvkzzjsGxbhxM/1bvZXpKfJTSrfd/hLsjSL5TfuDOuepri2JPB7dWU3B8bpo0bqnsuy3LKYQ4w==
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=IZCvGIhTHBdOtzR4HrjNAXPIH4l5riJKBsemmfL/MTY=; b=C/ZK2PHVsnrjqUE1ciFGR97oSOH3T/0VE33EChDE1a8VEtRldv4B/QfLfKDbmM8O/rLpSwU3DEOkMHFEXGvdpvfd0abybtOix+net71na4+0qW9UDgiwTe46Edptn6cwhkWo1VEqLcsAqnY6c8hRFILHOyntM4Tf+PAFieoCQRY=
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com (2603:10a6:208:e7::31) by AM9PR07MB7236.eurprd07.prod.outlook.com (2603:10a6:20b:2c3::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.14; Sun, 6 Jun 2021 10:58:05 +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.4219.019; Sun, 6 Jun 2021 10:58:05 +0000
From: Balázs Varga A <balazs.a.varga@ericsson.com>
To: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: Comments on I-D Action: draft-ietf-detnet-oam-framework-01.txt
Thread-Index: AddORN6NEfqoJxNTRoyMjNrzF4hSewMfRdlw
Date: Sun, 06 Jun 2021 10:58:05 +0000
Message-ID: <AM0PR07MB53479743A9F260FDA3D73261AC399@AM0PR07MB5347.eurprd07.prod.outlook.com>
References: <AM0PR0702MB3603BAEF938F4C59539C059BAC299@AM0PR0702MB3603.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR0702MB3603BAEF938F4C59539C059BAC299@AM0PR0702MB3603.eurprd07.prod.outlook.com>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [91.82.190.48]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1fef7691-f19d-4e6e-cdd1-08d928d9f669
x-ms-traffictypediagnostic: AM9PR07MB7236:
x-microsoft-antispam-prvs: <AM9PR07MB72364001BA897132CF9060D4AC399@AM9PR07MB7236.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NNZSCaTfxRl75blbH7dGtueQCFYigHM4TmsPHSNr9cR7u6cIOGVBHDLAOZEqeECr45CCwgBjv4LWfu1Mf+cX7FHVrn9rSX8EaOOANeu+JoNI9yPAbLWHN0YXNSUk05kqs/r97Q4RQbY1T4uYuDjzTn3nlbW00clwkBmCOTTwicWyTzZtHbSPueQuLk5hmgHpd0VAwXdryNb57LheM/9gD4uDzAKtjpaYqAV2+IsK9WZUYuxjz4990Do/WcjvZjSHoeOyD4qQFXayswF6tw7sG/46BQLScA5dEuIDovaf9wOuK4Hu3ctkZvztqv/j+XpvNIY3v4tOgtV9irXm7N9zJ1WNV+Jf4ymRij06ugS7n6iDbJAByGduoSZjV9/NmS0Z7wqGoBD/XhhgB6QQxuRNA5KGGioWlN/2ODZG00/SXV5QTJrLlPbMlB7ftQwSHPJSqupo1GQWG2hDl6yoynnHeqSSfL2XmZkkTcwfZggy0MBPPDyUCJ3OxjcfENMN9752zsixBKr815giXeDo09IVGhpjjk6Q9cpIH8ydtmUDCCe+Iv2ZlqfESYQYD/iHRufCKOc8nqoL/k2B7u7hQD0Yci4tHHCJQrQZQeTWkIjjD4uKfPCHFJ24XdEtOMV2ELcJziR8fBrEWgcIiAo1K+2k/aebL1thQU2mlM3nVNJltobNkl9GN6hVap+1+ZKiNh2GkuY19wiMGroh3hR3jKERgPKP6u5zGhYnEL4bXr2FTaeP7AIW2MqvtNIGJHzfyDk5
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)(366004)(39860400002)(376002)(396003)(346002)(136003)(9686003)(55016002)(86362001)(38100700002)(2906002)(966005)(6916009)(33656002)(52536014)(122000001)(83380400001)(7696005)(6506007)(478600001)(53546011)(316002)(76116006)(8676002)(26005)(71200400001)(66556008)(66946007)(64756008)(66476007)(66446008)(66574015)(5660300002)(30864003)(8936002)(186003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ylxLTj1CXIKjUxjMYuw777lmruLMUJESJc0bYfBYA4EGW6H4wdNrlNvNa3WQXc8AxkvrVvr2zwcH0e4HuO7GPFtma7Y5lvUNpvcKIqblZyS4Rp88xtjz4W+Mlbt8im6uEnAVh4QKTu2nkxcpdIW85yWUNHWqnjDDiKI2qwMPJPl5BGWxYaFjHQGjrcaahPwkdpIC9SDxGXbBIo7xTAPTnUWI2YMxy7EzZ8QQMVwSY+xQjWHVd/k/BDJ7mZGHQdlyWwt9W8cZDrFYr8jUlNV//lcTbjK9f9FEicASg7BRDgqIy68BLOFaajwHe4g/KuEKVeLSungViO39ECBbFEgjGjxOf9vwZAiJTVNYtgthS/djcctDb1P4Yvo5AYwuXnP+ogCVXkHZyCzIkMpNmr+iR5YrsepNbFTdkwqgxvJs53WJsXlVXVjYbM7J/o3rOOrjXQxZ4ypX2U+wpJalrETZu8X2ICtaKvYB9YlROUqcyzZLd7NJsMvUpzJy4UgPwWRPxe9uQPlxYOPf9sJLOutJhietEAg+WqsXi1OKX9vS4qAirYcQcSf5En2QWrj2B45MBhJuwFAwpiyCxxJuFlavkj2YkBQfZ3bXclg1N0XsedD3Cpp2CfB85ITKB1C3ph3efDQ+eHPx4oSpWaXm/grSvQyBOcoZNfmfPgYMIgcMJ0scLdHL7FhcGnbewJg/g/DdNmR8yXgQAoxyr5vV2bEtusoAMPZRxaHo+tTERSGBa/lCiIOpo7Jr+UVjwOVdmq7pGriQBolWFAgJ3dFwVRS+Yp9u3C8GtWmMQmj2TNQOHJqvpVnKL+xFFyWvYQvewczuka3msgcX6EmIxSzR6L98D7h4wid3WJzSgawWuOASFKFLBz2ZovlW8LmlvmmhHI/y4RMtJ2/9nmIOXaeFfP7S0NikihWqvhpgBdrEhXtORlYHIQLMfK/3BqcNg8+Zb1FyGR/Z7Wm37McJ6KS5rSFPNUj4fVWggwG87eED2TfRxipAL+5c0ZdJb4+hx+RZV19/y38xwjuW0dUManJ0/mVBhv8qGiwSzNdKqzj/eYRSjqL5pxS/9kr6fZ04d+4z5Gk+hjaNt+FaYmgs/4m6TCijkloJA9pPSm/PIgemGYbjufikJpCd2me3t86ad70Fii7QuvvEm3tvZ7VTcMvkbKna4vP7giLSENT3NlWDQUbeI/cbwlYcoHjee4EmArmz61PiV6yn5KZjTDF/K8gMiSq+0FgktgQ2PBt2+I5rh4E+h6OLxE3mHUDDWzXc+cxYTvs1yvdbZT2ResWS8PpheZma382C7g89NCelvZ8BMxb87sA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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: 1fef7691-f19d-4e6e-cdd1-08d928d9f669
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2021 10:58:05.5919 (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: F/3EqJupNplmeV4ot3CTieEQHwMuQIpcm2rA+m2AhdYDSvAnJUNx5Zn6Z4qcNvRDS38UEqoneGrwV4lhQjzKAgWicJ8mRBi5fg9cbEk8a5s=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR07MB7236
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/kcztLxvYa-WpGLCssgj5QcrSTgc>
Subject: Re: [Detnet] Comments on I-D Action: draft-ietf-detnet-oam-framework-01.txt
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: Sun, 06 Jun 2021 10:58:16 -0000
Hi, As discussed on the last OAM call, please find below some text proposal to update section 2. Please feel free to take it or modify it. Cheers Bala'zs ORIGINAL TEXT 2. Role of OAM in DetNet DetNet networks expect to provide communications with predictable low packet delay and packet loss. Most critical applications will define an SLO to be required for the data flows it generates. To respect strict guarantees, DetNet can use an orchestrator able to monitor and maintain the network. Typically, a Software-Defined Network (SDN) controller places DetNet flows in the deployed network based on their the SLO. Thus, resources have to be provisioned a priori for the regular operation of the network. OAM represents the essential elements of the network operation and necessary for OAM resources that need to be accounted for to maintain the network operational. Fault-tolerance also assumes that multiple paths could be provisioned so that an end-to-end circuit is maintained by adapting to the existing conditions. The central controller/orchestrator typically controls the Packet Replication, Elimination, and Ordering Functions (PREOF) on a node. OAM is expected to support monitoring and troubleshooting PREOF on a particular node and within the domain. Note that PREOF can also be controlled by a set of distributed controllers, in those scenarios where DetNet solutions involve more than one single central controller. NEW TEXT 2. Role of OAM in DetNet DetNet networks expect to provide communications with predictable low packet delay and packet loss. Most critical applications will define an SLO to be required for the data flows it generates. To respect strict guarantees, DetNet can use an orchestrator able to monitor and maintain the network. Typically, a Software-Defined Network (SDN) controller places DetNet flows in the deployed network based on their the SLO. Thus, resources have to be provisioned a priori for the regular operation of the network. OAM represents the essential elements of the network operation and necessary for OAM resources that need to be accounted for to maintain the network operational. Many legacy OAM tools can be used in DetNet networks, but they are not able to cover all the aspects of deterministic networking. Fulfilling strict guarantees is essential for DetNet flows, what resulted in new DetNet specific functionalities which must be covered with OAM as well. Filling these gaps are inevitable and needs accurate consideration of DetNet specifics. Similar to DetNet flows itself, their OAM needs careful end-to-end engineering as well. For example, proper placing of MEPs along the path of a DetNet flow is not always a trivial task and may require proper design together with the design of the service component of a given DetNet flow. There are several DetNet specific challenges for OAM. Bounded network characteristics (e.g., delay, loss) are inseparable service parameters, therefore PM is a key topic for DetNet. OAM tools needed to prove the SLO without impacting the data flow characteristics. A further challenge is the strict resource allocation. Resources used by OAM must be considered and allocated to avoid disturbing data flow(s). The DetNet Working Group has defined two sub-layers: (1) DetNet service sub-layer, at which a DetNet service (e.g., service protection) is provided and (2) DetNet forwarding sub-layer, which optionally provides resource allocation for DetNet flows over paths provided by the underlying network. OAM mechanisms exist for the DetNet forwarding sub-layer, nonetheless, OAM for the service sub-layer requires new OAM procedures. These new OAM functions must allow, for example, to recognize/discover DetNet relay nodes, to get information about their configuration, and to check their operation or status. DetNet service sub-layer functions using a sequence number. That creates challenge for inserting OAM packets in the DetNet data flow. Fault-tolerance also assumes that multiple paths could be provisioned so that an end-to-end circuit is maintained by adapting to the existing conditions. The central controller/orchestrator typically controls the Packet Replication, Elimination, and Ordering Functions (PREOF) on a node. OAM is expected to support monitoring and troubleshooting PREOF on a particular node and within the domain. Note that PREOF can also be controlled by a set of distributed controllers, in those scenarios where DetNet solutions involve more than one single central controller. DetNet forwarding sub-layer is based on legacy technologies and has a much better coverage regarding OAM. However, the forwarding sub-layer is terminated at DetNet relay nodes, so end-to-end OAM state of forwarding may be created only based on the status of multiple forwarding sub-layer segments serving a given DetNet flow (e.g., in case of DetNet MPLS, there may be no end-to-end LSP below the DetNet PW). END -----Original Message----- From: detnet <detnet-bounces@ietf.org> On Behalf Of Balázs Varga A Sent: Friday, May 21, 2021 3:27 PM To: detnet@ietf.org Subject: [Detnet] Comments on I-D Action: draft-ietf-detnet-oam-framework-01.txt 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 >Comment3> 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 >Comment15> paths within itself. Does it meant a segment here? (E.g., >Comment15> Per segment to detect misbehaving path when multiple paths >Comment15> 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 <detnet-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org Sent: Wednesday, May 19, 2021 10:02 PM To: i-d-announce@ietf.org Cc: detnet@ietf.org 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 detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
- [Detnet] Comments on I-D Action: draft-ietf-detne… Balázs Varga A
- Re: [Detnet] Comments on I-D Action: draft-ietf-d… gregory.mirsky
- Re: [Detnet] Comments on I-D Action: draft-ietf-d… Balázs Varga A
- Re: [Detnet] Comments on I-D Action: draft-ietf-d… gregory.mirsky
- Re: [Detnet] Comments on I-D Action: draft-ietf-d… gregory.mirsky
- Re: [Detnet] Comments on I-D Action: draft-ietf-d… Fabrice Theoleyre
- Re: [Detnet] Comments on I-D Action: draft-ietf-d… Balázs Varga A