Re: [Teas] clarification to actn-vn-yang

Dhruv Dhody <dhruv.ietf@gmail.com> Sun, 19 July 2020 04:36 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC33A08E2; Sat, 18 Jul 2020 21:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bi37Gbif8xHW; Sat, 18 Jul 2020 21:36:34 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B2A3A08E1; Sat, 18 Jul 2020 21:36:33 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id k6so10558479ili.6; Sat, 18 Jul 2020 21:36:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ot3XwmKG23G9fMHUzsbsh68a32PwIcR0SmT1dRunzJ8=; b=Xlnqfhxy26K5M8K3ILZ9h04+B0KBsi1C/mLRS7uD1GfAuzKswiIJeJA+xPFLbFP52W 2XekaY8mO5oyp1DTiHv74MBuIkLqDNwmPkL9x2Lil+sFH92+Apg0/q+qPyrGfSVLHK/T CcsHiVW4VyjnrYJQYfhqOYratKpnuXLe9hZ0YLlhjymZrUNfiOwK0Kc7PCWFdPNjJZOp inULhWDbKQeZen02OMBVpW0x/IoOgxy80TqKSZUz6rwEOLjsscOi871eOss92B+I7jYq lG4q3RYvb3O9Pqkg1KnyV64fxqD3/8abqB/Hkf1FG689SLpWEfLVoolCwrBzMs6Y7vWA ix5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ot3XwmKG23G9fMHUzsbsh68a32PwIcR0SmT1dRunzJ8=; b=pSD9dhpxj0Vqhxu6ZKdZmF3QBm2GFTYQu6NzJ+2usEtTk3M14HbWHjqXTywRcl4txU 69RvqkKOYMt6jWQXnMSi9O4OH1afdCBXvrCGc6PTkhWlhyYMDzYPfcTg8h8UM8RMZsrm tOSgPC6L29V0BJWRfPc/v5Pv52Ys81eYJXByOpNLa4C/4+nbcjCONZo0BsnOjAVUGlVs ZXPJqW0SMeelNVKv3AzvBLRNjMEzbaxknKXmrTfHoubLTyu599ddt8v493LBYX7kZY3C 3dr1EH3vzEaTr+tlmogVuO6wjAy7X/oGOkfq8fwRs6pO38bncyZoxl1BrHKgtZ+yG3Er rfLA==
X-Gm-Message-State: AOAM5321bDRPrs4KgrCSAKs1YfPODWKFHGXjTBaOHWse9nj8vq5Lk134 1qE1ITtmqzNNmA8TU8kgKjZX6wWmWuawNxcU6BU=
X-Google-Smtp-Source: ABdhPJzm3f4rBloZ2Zwg2f3UBXLyWIj/CxtZ5rygEt1ml6oL392f1yJTiTm0PpnK39er5/h2fcxCKuBANBypBB4PMZU=
X-Received: by 2002:a92:cb03:: with SMTP id s3mr17446974ilo.1.1595133392854; Sat, 18 Jul 2020 21:36:32 -0700 (PDT)
MIME-Version: 1.0
References: <004d01d656a8$677ae4d0$3670ae70$@kddi.com> <CAB75xn5VTc97_Zyea27Tngq+zsEX5ttTwRvLO_2o1xK5gL_HEQ@mail.gmail.com> <CA+RyBmVeuA_orrDJUBMSQdLi4s7JJ2XRydUa7pfyBG0WFowpNQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVeuA_orrDJUBMSQdLi4s7JJ2XRydUa7pfyBG0WFowpNQ@mail.gmail.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Sun, 19 Jul 2020 10:05:55 +0530
Message-ID: <CAB75xn5w+wQD0pO-k-JfoovMoe=C=P10VDwOhCdRkPcsZfUnDw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "Ogaki, Kenichi" <ke-oogaki@kddi.com>, =?UTF-8?B?5Li55769IOacneS/oQ==?= <to-niwa@kddi.com>, draft-ietf-teas-actn-vn-yang@ietf.org, =?UTF-8?B?5a6u5Z2CIOaLk+S5nw==?= <ta-miyasaka@kddi.com>, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ThfPyt5qKHVK7U7I3EuiQFAuevM>
Subject: Re: [Teas] clarification to actn-vn-yang
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jul 2020 04:36:36 -0000

Hi Greg,

Good suggestion. I can use your help to hunt those references down. I
will reach out to you offline.

Have a good weekend!

Thanks!
Dhruv

On Sun, Jul 19, 2020 at 7:22 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Druv,
> in your response you've mentioned:
> "... this model provides the (1) measured telemetry data .."
> Does that apply to the performance metrics listed in Use Cases:
>      Customer services have various Service Level Agreement (SLA)
>       requirements, such as service availability, latency, latency
>       jitter, packet loss rate, Bit Error Rate (BER), etc.
> If "yes", I would greatly appreciate it if you can reference measurement methodology for service availability, latency jitter, and packet loss rate.
>
> Regards,
> Greg
>
> On Mon, Jul 13, 2020 at 11:52 AM Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>>
>> Hi Kenichi,
>>
>> Thank you for your comments and insight.
>>
>> On Fri, Jul 10, 2020 at 4:34 PM Ogaki, Kenichi <ke-oogaki@kddi.com> wrote:
>>>
>>> Hi actn-vn-yang authors,
>>>
>>> Can I clarify the following two questions?
>>>
>>>
>>> 1) consideration of the key network performance constraints
>>>
>>> I'd like to clarify how actn-vn-yang considers key network performance constraints in the sense of RFC8233 Appendix A, latency, delay variation, loss,...?
>>>
>>
>> We rely on the te-topology connectivity matrix for this. Refer the path-metric-bounds and optimization, there based on the metric-types these can be supported. The common te-types in RFC 8776 include some of them and I would guess other modules would augment more types.
>>
>>>
>>> As an operator, we at KDDI are internally discussing to adopt actn-vn-yang to compute/setup VN (topology) as NBI consumed by our OSS/BSS corresponding to CNC. Then, we ask you to accommodate the consideration of the key network performance constraints into the model, for example at the same level of vn-level-diversity in both a vn-list entity and vn-compute/input.
>>>
>>
>> This was our approach initially, but the WG did not like that and wanted us to re-use the existing TE topology model, and thus we came up with an approach where a reference to an abstract node (of the TE topology YANG model) is put in VN Yang model and we rely on the connectivity-matrix structure to assign the constraints. See the backup pages in https://datatracker.ietf.org/meeting/105/materials/slides-105-teas-sessb-04-a-yang-data-model-for-vn-operation-00.. I have added some descriptions in the appendix as well in the latest version.
>>
>>
>>>
>>> As the same context, actn-pm-telemetry-autonomics, some authors overwrap, already considers the key network performance data and compute/setup VN as autonomic scaling intent as follows. In that sense, CMI of ACTN must support this capability and it's natural for actn-vn-yang to do so, too.
>>>
>>> actn-pm-telemetry-autonomics says:
>>> 2.  Use-Cases
>>>    o  Customer services have various Service Level Agreement (SLA)
>>>       requirements, such as service availability, latency, latency
>>>       jitter, packet loss rate, Bit Error Rate (BER), etc.  The
>>>       transport network can satisfy service availability and BER
>>>       requirements by providing different protection and restoration
>>>       mechanisms.  However, for other performance parameters, there are
>>>       no such mechanisms.  In order to provide high quality services
>>>       according to customer SLA, one possible solution is to measure the
>>>       SLA related performance parameters, and dynamically provision and
>>>       optimize services based on the performance monitoring results.
>>>
>>> 3.2.  VN KPI Telemetry Model
>>>    This module also allows autonomic traffic engineering scaling intent configuration mechanism on the VN
>>>    level.
>>>
>>> 4.  Autonomic Scaling Intent Mechanism
>>>    o  performance-type: performance metric type (e.g., one-way-delay,
>>>       one-way-delay-min, one-way-delay-max, two-way-delay, two-way-
>>>       delay-min, two-way-delay-max, utilized bandwidth, etc.)
>>>
>>>    o  threshold-value: the threshold value for a certain performance-
>>>       type that triggers scale-in or scale-out.
>>>
>>
>> You are correct to note that this model provides the (1) measured telemetry data and (2) specify threshold based on different metric-type on for scaling purposes. This is a new advanced feature defined in this I-D for the first time.
>>
>> But, the WG felt that specifying constraints at the time of VN creation can be achieved by the existing connectivity matrix construct and thus we were asked to reuse it.
>>
>>>
>>>
>>> 2) VNAP level bandwidth control
>>>
>>> The current model can indicate the max/available bandwidth to Access Point corresponding to (physical) customer's end point. However, we also want to do so at Virtual Network Access Point level, which corresponds to traffic engineering of vn-member level. Is there any problem?
>>>
>>
>> My initial feeling was we could get it from the bandwidth at the VN-member level but I think it would be still useful to put it in vnap as well. I have added it now.
>>
>> Thanks!
>> Dhruv
>>
>>>
>>>
>>> We of course understand augmentations to solve these requirements, but we believe these are general requirements, and then desire to accommodate to the model.
>>>
>>> Thanks in advance,
>>> Kenichi
>>>
>>> --
>>> Kenichi Ogaki
>>> KDDI Corp. | Operation Automation Promotion Dept.
>>> +81-(0)80-5945-9138 | www.kddi.com
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas