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

Dhruv Dhody <> Mon, 13 July 2020 18:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F2D73A1727; Mon, 13 Jul 2020 11:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dHvPkItv7cTj; Mon, 13 Jul 2020 11:52:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FB6F3A172A; Mon, 13 Jul 2020 11:52:49 -0700 (PDT)
Received: by with SMTP id i18so12117838ilk.10; Mon, 13 Jul 2020 11:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=auwWrGDodrFY1DZCGYSKxV24nb3KD5OtAzTsuqXotHE=; b=GUeevsFJ1QCQM+o+ZsWg+xlNsd0RCsSG4HpKF9B05It8bsGbXxAG9C6r+J522BC7rb LdBXp4aCpH6u3bfPd1FxmbYo1+2jOcLUDYffr+5UYSutQbzr2dj4vcgzR3AALLilbEY6 RYuyCQ2IlZBvgc97uggx5a/6ZEGqL5bV/fDSeUgx1HlOPXA24IbWzGXuMPw19L9c04Ba 1MvmUcXnlZbipQgN+xT3g1Y9SvuUO5O8fP7OEOzCeGgLrYjJA1XXc5VHN4SiDQhOWIg5 StDxKszsJfLCjcUZN8IkOWNjJ56IZVLB2RyCWZVcHOH6RIBVWZJ4C8F56G4kUlU9Te7p oqgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=auwWrGDodrFY1DZCGYSKxV24nb3KD5OtAzTsuqXotHE=; b=uY5z8S8fGBeZQoLbpoXHuzN6Ejrop8G3lkG54k0mnGoVenrovAm4GONLE9y8gmzEVB HW9Ni1hPOKVlHqVVSeSHRDVGlYU2tmewgGQgjBUNCFZYSnF5OIn4pRTd7NoJ8wZ3wv43 aAhzvJR55n2XCEMuN2HfRwg0h8BEOjAPLkqypZDnBgQXBVEqjuRRxd9pyG8idNLvwk7P 6eg7xPiXa1w7c5Ac9L3lOr0sG5Ke0dO3Y0BtBrFZOWa8KrLwq7XPP4Lg0LjG4sw5fvMb xT3hrC8Zbx2IRpjCjKcuk0qlFuGQIv9tpzCi8v7ItQ7b+LHQh5wfbyquQfFRbJH6raMC c3vw==
X-Gm-Message-State: AOAM530tkG0ujgDNCD7Blq41zPUwZ4Vx/S+F954LOCXrsRy1ihrqy3dB dKlzQQMJxjN+wIkns/hDgUSVHkc1JQ/89IWN/npd+XW6
X-Google-Smtp-Source: ABdhPJwywZMNYMu1wRz1kjruQgzBaRJ1db37CnLgJX9yOnLd15nkBmytzPA/8yYBNon8NnQFFVqgoitLiaq0OhRB5Xo=
X-Received: by 2002:a92:cb03:: with SMTP id s3mr1202753ilo.1.1594666368304; Mon, 13 Jul 2020 11:52:48 -0700 (PDT)
MIME-Version: 1.0
References: <004d01d656a8$677ae4d0$3670ae70$>
In-Reply-To: <004d01d656a8$677ae4d0$3670ae70$>
From: Dhruv Dhody <>
Date: Tue, 14 Jul 2020 00:22:11 +0530
Message-ID: <>
To: "Ogaki, Kenichi" <>
Cc:, "TEAS WG (" <>, =?UTF-8?B?5a6u5Z2CIOaLk+S5nw==?= <>, =?UTF-8?B?5Li55769IOacneS/oQ==?= <>
Content-Type: multipart/alternative; boundary="0000000000006b09d205aa573215"
Archived-At: <>
Subject: Re: [Teas] clarification to actn-vn-yang
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jul 2020 18:52:51 -0000

Hi Kenichi,

Thank you for your comments and insight.

On Fri, Jul 10, 2020 at 4:34 PM Ogaki, Kenichi <> 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
I have added some descriptions in the appendix as well in the latest

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


> 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 |