Re: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments

Zhenghaomian <zhenghaomian@huawei.com> Mon, 18 May 2020 01:23 UTC

Return-Path: <zhenghaomian@huawei.com>
X-Original-To: teas-ns-dt@ietfa.amsl.com
Delivered-To: teas-ns-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0C3A041A for <teas-ns-dt@ietfa.amsl.com>; Sun, 17 May 2020 18:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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 aZzPbWCtYyVM for <teas-ns-dt@ietfa.amsl.com>; Sun, 17 May 2020 18:23:33 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 60F6E3A0415 for <teas-ns-dt@ietf.org>; Sun, 17 May 2020 18:23:33 -0700 (PDT)
Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C020498179C1ADEDB34E; Mon, 18 May 2020 02:23:31 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 18 May 2020 02:23:31 +0100
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Mon, 18 May 2020 02:23:30 +0100
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.180]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0487.000; Mon, 18 May 2020 09:23:25 +0800
From: Zhenghaomian <zhenghaomian@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>
CC: "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>, "Luis M. Contreras" <contreras.ietf@gmail.com>, Jari Arkko <jari.arkko@ericsson.com>
Thread-Topic: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments
Thread-Index: AdYssth/CXjYPx5xSYiVc2wIhM5arw==
Date: Mon, 18 May 2020 01:23:25 +0000
Message-ID: <E0C26CAA2504C84093A49B2CAC3261A43F85F4D7@dggeml511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.24.176.178]
Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A43F85F4D7dggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas-ns-dt/36xM2NYsbuQW_Xx_y7Lk7YTRjzg>
Subject: Re: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments
X-BeenThere: teas-ns-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TEAS Network Slicing Design Team <teas-ns-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas-ns-dt/>
List-Post: <mailto:teas-ns-dt@ietf.org>
List-Help: <mailto:teas-ns-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas-ns-dt>, <mailto:teas-ns-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2020 01:23:36 -0000

(re-sending as the upper bound of recipients was achieved for previous one…)

FYI, some description about the (un)availability in ITU-T, refer to G.827 section 6.1 as follow:

The term "availability" refers to the availability ratio (AR), which is the proportion of time that a path is in the available state during an observation period. AR is calculated by dividing the total available time during the observation period by the duration of the observation period.
The converse of AR, the unavailability ratio (UR), is the proportion of time that an end-to-end path is in the unavailable state during an observation period. UR is calculated by dividing the total unavailable time during the observation period by the duration of the observation period.
AR + UR = 1
The observation period is recommended to be one year.

Regarding the text so far, we miss the characteristic about the ‘ratio’, which specified the measurement is based on time; and we also have not indicated whether a ‘degradation’ should be counted as ‘available’ or ‘unavailable’, as Greg proposed. Personally I slightly prefer the degradation to be available.

My 2 cents,
Haomian


发件人: Zhenghaomian
发送时间: 2020年5月18日 9:09
收件人: 'Greg Mirsky' <gregimirsky@gmail.com>om>; Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org>
抄送: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>om>; teas-ns-dt@ietf.org; Luis M. Contreras <contreras.ietf@gmail.com>om>; Jari Arkko <jari.arkko@ericsson.com>om>; Shunsuke Homma <shunsuke.homma.fp@hco.ntt.co.jp>jp>; Kiran Makhijani <kiranm@futurewei.com>om>; Shunsuke Homma <s.homma0718@gmail.com>om>; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>
主题: 答复: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments

FYI, some description about the (un)availability in ITU-T, refer to G.827 section 6.1 as follow:

The term "availability" refers to the availability ratio (AR), which is the proportion of time that a path is in the available state during an observation period. AR is calculated by dividing the total available time during the observation period by the duration of the observation period.
The converse of AR, the unavailability ratio (UR), is the proportion of time that an end-to-end path is in the unavailable state during an observation period. UR is calculated by dividing the total unavailable time during the observation period by the duration of the observation period.
AR + UR = 1
The observation period is recommended to be one year.

Regarding the text so far, we miss the characteristic about the ‘ratio’, which specified the measurement is based on time; and we also have not indicated whether a ‘degradation’ should be counted as ‘available’ or ‘unavailable’, as Greg proposed. Personally I slightly prefer the degradation to be available.

My 2 cents,
Haomian

发件人: Teas-ns-dt [mailto:teas-ns-dt-bounces@ietf.org] 代表 Greg Mirsky
发送时间: 2020年5月16日 8:40
收件人: Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org<mailto:eric.gray=40ericsson.com@dmarc.ietf.org>>
抄送: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com<mailto:luismiguel.contrerasmurillo@telefonica.com>>; teas-ns-dt@ietf.org<mailto:teas-ns-dt@ietf.org>; Luis M. Contreras <contreras.ietf@gmail.com<mailto:contreras.ietf@gmail.com>>; Jari Arkko <jari.arkko@ericsson.com<mailto:jari.arkko@ericsson.com>>; Shunsuke Homma <shunsuke.homma.fp@hco.ntt.co.jp<mailto:shunsuke.homma.fp@hco.ntt.co.jp>>; Kiran Makhijani <kiranm@futurewei.com<mailto:kiranm@futurewei.com>>; Shunsuke Homma <s.homma0718@gmail.com<mailto:s.homma0718@gmail.com>>; Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com<mailto:reza.rokui@nokia.com>>
主题: Re: [Teas-ns-dt] draft-nsdt-teas-transport-slice-definition-02-comments

Hi Erik, et al.,
thank you for all the comments and suggestions to strengthen the document. I want to touch on the use of the term "availability" (with updates you've proposed):
o Availability: concerns with how often a service is lost (or degraded to the point of unacceptable performance) due to a fault, and how quickly the lost service network becomes available after a fault. The requirements are specified through mean time between failures (MTBF), and mean time to repair (MTTR) to acquire availability metrics.
I agree with you that availability is affected by both network failures and network performance degradation below a certain threshold. Then, if I follow that definition, the way of measuring or calculating the availability noted in the second sentence does not appear to be accurate as it only includes failure and does not consider periods of performance degradation. Since this draft, as I understand, is intended to provide the definitions to be used throughout other TS drafts, perhaps leaving in the definition will be sufficient, while the availability measurement/calculation method will be outside the scope of the document.
What do you think?

Regards,
Greg

On Wed, May 13, 2020 at 6:41 AM Eric Gray <eric.gray=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> wrote:
Authors/Editors of draft-nsdt-teas-transport-slice-definition-02:

              Please consider the attached revised and annotated version of your -02 version of this draft.

              This version shows markup for removing or modifying some highly contentious or questionable text and sections – including annotations as to why this text should be removed.

              It also includes comments and questions about other text that may not be necessary, or should be reworded.

              One section (section 4.1.1) is shown as removed, but Jari had made a couple of other suggestions about that text immediately prior to the last meeting.  I do not recall if there was any decision about these alternatives and I could not track down the meeting notes from that meeting.

              A key observation about this draft is that it is supposed to be a definitions draft – i.e. – it defines the terminology we are using or expect to use in other drafts related to this work..

              There is some danger in having the ambition to see “definition” as something we can stretch to encompass “specification” in this draft.

              It is important also to realize that the parameters and objectives of transport slice services listed in this draft are explicitly intended to be representative examples, rather than an exhaustive list – hence it is not necessary to include any for which there is no consensus to include.

--
Eric
--
Teas-ns-dt mailing list
Teas-ns-dt@ietf.org<mailto:Teas-ns-dt@ietf.org>
https://www.ietf.org/mailman/listinfo/teas-ns-dt