[Teas] clarification to actn-vn-yang

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Fri, 10 July 2020 11:04 UTC

Return-Path: <ke-oogaki@kddi.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AE7663A0817; Fri, 10 Jul 2020 04:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id L-uzwg_KEHsZ; Fri, 10 Jul 2020 04:04:00 -0700 (PDT)
Received: from kddi.com (athena3.kddi.com []) by ietfa.amsl.com (Postfix) with ESMTP id 936A63A0810; Fri, 10 Jul 2020 04:03:59 -0700 (PDT)
Received: from LTMC2123.kddi.com (post-send []) by kddi.com (KDDI Mail) with ESMTP id 94FEEE0081; Fri, 10 Jul 2020 20:03:58 +0900 (JST)
Received: from LTMC2144.kddi.com ([] []) by LTMC2123.kddi.com with ESMTP; Fri, 10 Jul 2020 20:03:58 +0900
Received: from LTMC2144.kddi.com (localhost []) by localhost.kddi.com (Postfix) with ESMTP id 6A55B4C005E; Fri, 10 Jul 2020 20:03:58 +0900 (JST)
Received: from LTMC2154.kddi.com (post-incheck []) by LTMC2144.kddi.com (Postfix) with ESMTP id 5F07D4C005C; Fri, 10 Jul 2020 20:03:58 +0900 (JST)
Received: from LTMC2154.kddi.com (localhost.localdomain []) by LTMC2154.kddi.com with ESMTP id 06AB3w9i102395; Fri, 10 Jul 2020 20:03:58 +0900
Received: from LTMC2154.kddi.com.mid_87066582 (localhost.localdomain []) by LTMC2154.kddi.com with ESMTP id 06AArt3I094439; Fri, 10 Jul 2020 19:53:55 +0900
X-SA-MID: 87066582
Received: from KDDI1801PC1319 ([] []) by post-smtp2.kddi.com with ESMTPA; Fri, 10 Jul 2020 19:53:54 +0900
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: <draft-ietf-teas-actn-vn-yang@ietf.org>
Cc: <teas@ietf.org>, =?iso-2022-jp?B?GyRCNVw6ZBsoQiAbJEJCc0xpGyhC?= <ta-miyasaka@kddi.com>, =?iso-2022-jp?B?GyRCQzAxKRsoQiAbJEJEKz8uGyhC?= <to-niwa@kddi.com>
Date: Fri, 10 Jul 2020 19:53:54 +0900
Message-ID: <004d01d656a8$677ae4d0$3670ae70$@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdZWoeCx9a8pv7TBTKWKmUIQhfo6Lw==
Content-Language: ja
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/dOJLarjlD4dzK3lpr3a6V4BdvI0>
Subject: [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: Fri, 10 Jul 2020 11:04:02 -0000

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

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.

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

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.

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?

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 Ogaki
KDDI Corp. | Operation Automation Promotion Dept.
+81-(0)80-5945-9138 | www.kddi.com