Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04

Dhruv Dhody <> Fri, 17 September 2021 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8053E3A1F8A for <>; Fri, 17 Sep 2021 08:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 z7Ma8LKVyHeR for <>; Fri, 17 Sep 2021 08:38:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D89173A1F89 for <>; Fri, 17 Sep 2021 08:38:22 -0700 (PDT)
Received: by with SMTP id a22so12704218iok.12 for <>; Fri, 17 Sep 2021 08:38:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XLqjC9KStQTHBAnT4yb2yLeccedid1GCWQ8GiwavBd4=; b=fwvDcPRa9lmLw9gJQnXosh94ymRoftobfr7rUn0agQkX1PGwF7GGNfAunK//pGhYkV lpw59KAu39K6N2Fh6Q4SI5YNu8XHofVrLSQwoqZHprB3iyXfIlnhcLWqp8e3ziszQ3PC ehzlRIeu91hmiurR7MxyigTyY2GuOeBVW9rc+lnxf/hbEE8f7+jblQyyWxctw5XAvdAp MFeK9WYOYd9+PVq3+hfHo6MSt7NqBWPrLKyEn467+Het2JM1S/l4NmlkI7I5D/y+vm/Y 680+5DTos0LO6VssydlMBViL+O3AM06Ge9ZefeLjIKT68xfLbpCTrmMLbchL0i4zvCk0 mKVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XLqjC9KStQTHBAnT4yb2yLeccedid1GCWQ8GiwavBd4=; b=VWxBPLqrWsP0pc66R511VRGm5q5gyhkd3O0USbgEjjJ/Y5tNTGNpj3tUpsRgx6W3Fq LJl9G22YAvR/TYbDW11kMLZBYnXUuQz8wTJ4F+kJsVHszHTsUbIyr7Fs+wfevanf/tuo HO2OMs956BtAjuEorEz3F4ARJo7hEfQnq8awC+3eyUjeEx7vROpkOomtLnt7/svMUSQ7 zbs85maW+VhXh/y+l57QSwrtk8+TTZu9ytek1KcCQXZB+fXEEMzeQM7Exbi+tze4Pig7 Yjy8NBgD9dx2fHxnKTdFQQAt05aordDMvIonasQvjjr+2UtM92y9xPLezeHjMc9yMXaE ToNQ==
X-Gm-Message-State: AOAM532LuFognonqBI1HhJUAC68n/Gnkw4ukrTssno4ZBwlyGOt5vOnJ DjLS/hm10QjoW/J561GScFxOVl+rdqbQbi0r9jtKExwk
X-Google-Smtp-Source: ABdhPJyTy6cCSVp+N2W8/MrtENKl4GbtYBCPngBnWCwb377QxF9jTX9OCRfBVu88uMJZyKJ9J+zcKrvJ7hQTXfFtniE=
X-Received: by 2002:a05:6602:3404:: with SMTP id n4mr9013904ioz.45.1631893100945; Fri, 17 Sep 2021 08:38:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Fri, 17 Sep 2021 21:07:43 +0530
Message-ID: <>
To: TEAS WG <>
Content-Type: multipart/alternative; boundary="00000000000097e3af05cc32b886"
Archived-At: <>
Subject: Re: [Teas] WG Adoption Poll - draft-wd-teas-ietf-network-slice-nbi-yang-04
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: Fri, 17 Sep 2021 15:38:28 -0000


This is a consolidated reply to multiple messages. I have snipped to the
key points. Apologies if I missed some.
<>Sergio said

Originally when VN model was presented in a couple of IETF meeting, the
YANG model was completely decoupled from TEAS topology, but comments from
most of TEAS WG, was to avoid defining “new YANG constructs” and instead to
use what we have already in TEAS topology, and the authors have updated the
model accordingly. This comment applies also to the YANG model for IETF
network slicing.

[Dhruv]: I agree with the history but disagree with the conclusion :)

The main objective is to model based on the definition and framework of the
IETF network slices (which does not describe the IETF network slice in
terms of VN, AP, VNAP…).

The modeling approach we used is more akin to a fully independent LxSM
model that does not describe the service in terms of topology. Further, we
wanted to avoid any coupling with TE models as there are other ways to
realize slice such as MT, FlexAlgo, etc. So to do a tight coupling with TE
topo for the IETF network slice would be a mistake.

Based on another comment from the TEAS WG,the term ACTN has also been
removed from the draft not to limit the VN YANG model applicability only to
ACTN. Therefore, it is possible to use the VN YANG model also in other

[Dhruv]: As of the current state of the models, the tight coupling with TE
topo is a hindrance.

There is a current on going draft in TEAS, that I like and contribute,,
that already describe how TEAS topology can be profiled to address not TE

[Dhruv]: That would be nice, but the key here is to define IETF network
slice service independently and not in the terms of a topology (same as

This model defines the customer view (intent?) of the IETF network slice in
the easiest terms independently without the extra baggage!
<>Xueyan said

If there is existing technology (such as ACTN VN, L2SM, L3SM, TE YANG,
etc.) can be reused with necessary augmentations for the realization of NSC
NBI YANG, we should refer to them but not to specify a new one.

[Dhruv]: Surely, if the WG thought there is a need for new concepts and
terms to describe IETF network slices in draft-ietf-teas-network-slices, it
is logical to model them on their own. Yes, they have a similar structure,
but that is normal for most of the service models.
<>Kenichi asked

why don’t we discuss to enhance/augment an existing nbi as the nbi solution?

[Dhruv]: We did try to capture this in the Appendix. It's clear that we
need to bring that discussion back up into the main text on the design
philosophy behind this model.

   - The VN model is tightly coupled with TE topology. The IETF network
   slice can be realized with non-TE techniques such as FlexAlgo/MT and thus
   any tight coupling is not acceptable.
   - The constraints (which are TE specific) are buried deep inside the TE
   topology abstract node connectivity matrix and do not map easily with
   - The IETF network slice endpoint is not described in terms of AP/VNAP
   and thus does not map with ease.

According to Figure 1 of draft-king-teas-applicability-actn-slicing-10, NSC
NBI can be replaced with CMI. If the new nbi is created, we have to
parallelly implement two nbis or just wrap CMI with NSC NBI. From one of
mobile operators’ capex perspective, we don’t want to do such effort, since
we believe major ietf network slice requirements can be covered by ACTN.

[Dhruv]: CMI is not one YANG model, there are a bunch of them
Our model could join the group. One would use this technology (and TE)
agnostic model only if it needs to, if the existing set of
technology-specific models are found to be appropriate by the consumer it
is perfectly fine to use that interface. It is akin to use the slice
realization technique directly. The key is that there is a gap identified
for the technology-agnostic model and this fills that gap.

We’re wondering what’s difficulty to augment the VN model.

[Dhruv]: See above. We plan to also document them in the draft.
<>Young said

One resolution I can think of would be to combine the two models into one
single model. I believe this is still possible from a modeling standpoint.
This may result in some delay for implementation, yet this option might be
much better than having two standards models.

[Dhruv]: You could do that if we go back and redesign the whole thing and
also define the IETF network slicing concepts in terms of VN and AP/VNAP. I
don't think that's a good idea!
pointed out in the other thread

If multiple options are acknowledged by the WG, then there should be a
document saying something like:

In case X, option A should be used
In case Y, option B should be used
In case Z, options A and C should be used

[Dhruv]: That is a good suggestion. At least in this document, we can add
where do we see a need for a technology-agnostic model and how it does not
mean that this NBI is the only way to deliver the IETF network slice

Have a good weekend!


On Tue, Sep 14, 2021 at 5:39 PM Vishnu Pavan Beeram <>

> WG,
> Clearly, there needs to be more discussion on this topic before we can
> draw consensus on the progress of this document. There will be
> dedicated time set aside at the upcoming interim meeting (Sept 27th)
> to debate the approach advocated in this draft (define a new service
> model from scratch) and other alternatives specified on the list
> (use ietf-vn as is; define a new service model by augmenting ietf-vn).
> The authors of draft-wd-teas-ietf-network-slice-nbi-yang will have a
> slot in the interim to reiterate their rationale for choosing the current
> approach. If anyone wants to present a counter approach, please do
> send in a slot request.
> In the meantime, we do expect the debate/discussion to continue
> on this thread.
> Regards,
> Pavan and Lou
> On Fri, Aug 27, 2021 at 10:07 AM Vishnu Pavan Beeram <
>> wrote:
>> All,
>> This is start of a *two* week poll on making
>> draft-wd-teas-ietf-network-slice-nbi-yang-04 a TEAS working group
>> document.
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".
>> If indicating no, please state your reservations with the document. If
>> yes, please also feel free to provide comments you'd like to see
>> addressed once the document is a WG document.
>> The poll ends September 10th.
>> Thank you,
>> Pavan and Lou
> _______________________________________________
> Teas mailing list