Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt Fri, 09 July 2021 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B07883A1EE4; Fri, 9 Jul 2021 05:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LqEYnr29-biR; Fri, 9 Jul 2021 05:05:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B1313A1ED9; Fri, 9 Jul 2021 05:05:54 -0700 (PDT)
Received: from (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4GLsLl0kfWz20NG; Fri, 9 Jul 2021 14:05:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1625832351; bh=XbCnVuS+FjyAocgRPkTICa3DzJzP2sJ7EbEhznU9UNY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ZvfzJW7PmWjd0T7IHKUQJTKwDSJgTLBtAlaT5l5WkQm+gsCxroHYYFfOxcGaVV/JQ IF02v79M2Bso+/rDrLhgqmOhE2g7oa+IZqJvbOFNCaCors01a2WqsyN5gaCDi/XPV/ VoRTny+YMBGLYVH7kNpGY2ntulGikhjiJMwZv3Ja071jgKt+ByVFhTqrwp4qKqAdxb /9Okjla5FzEf2NabKt9z3hivOfJzNGCS3Bp4NUhZyqjcLgugWeDAwnLKuz3kyOZOiD t64NdI1Lt58kiATbtrMtF8SmO9uDbSHZPI0FJ6X972TZ585NxYoKDDiqFmW+JHyv4X P7jRkylnA3bqw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (ESMTP service) with ESMTPS id 4GLsLk74qJzDq7y; Fri, 9 Jul 2021 14:05:50 +0200 (CEST)
To: "Wubo (lana)" <>, "" <>
CC: "" <>
Thread-Topic: New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt
Thread-Index: Add0pWXcMR4RO95mToa1bmfXm/Vx9gACuNfQ
Date: Fri, 09 Jul 2021 12:05:49 +0000
Message-ID: <18848_1625832351_60E83B9F_18848_170_1_787AE7BB302AE849A7480A190F8B9330353BAF50@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt
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, 09 Jul 2021 12:06:00 -0000

Hi Bo, all,

Thank you for sharing this updated version. 

I'm supportive of this work, but I think we have a fundamental point to clarify: the document is currently missing data nodes that makes a slice, a slice! 

If we don't have such data nodes, the current module can be used to provision any form of connectivity. If we omit the "ns-" prefix, the module can be used for provisioning the connectivity of VoIP, multicast, etc. services. That’s actually good (as the applicability scope is wider) but we need also to think about network slice specifics.  

I have touched on some of these points in a review I shared with you back in 02/21, but unless I'm mistaken I don't think it was addressed: 

Below an extract of my main comments: 

(1) A proposal to rationalize the discussion and ease progressing the spec is to clearly call that a network slice can be defined as a collection of at least three components: (1) connectivity component, (2) storage component, and (3) compute component. Having a provision for this since early stages of the model will ease grafting other components of an IETF slice easily, but also allows to avoid having a linear model.

(2) For the connectivity part, the following items are important to cover as well:
* Traffic steering and advanced services: a slice may require the invocation of service functions (firewall, for example) in a given order. These policies have to be captured in the slice request. This is also useful when the customer request that its slice should not cross some networks or not span some regions. 
* What to do for out of profile traffic: See the traffic conformance discussion in RFC7297. 
* Activation means: may need to be included in a slice definition. Think about a slice that can be implemented as a VPN service. Such service may require the activation of a given routing protocol between a CE and a PE, otherwise the service won’t be offered. 
* Invocation means: Think about a multicast service that requires IGMP/MLD and so on.
* Notification means: these are important for service assurance and fulfillment purposes.

(3) The model seems to be inspired from the opsawg vpn I-Ds (network-access structure, for example). That's great and appreciated, but I would formalize that by using I-D.ietf-opsawg-vpn-common for data nodes such as connectivity-type, endpoint-role, status-params, etc. 

(4) One last comment, I still don't get what is an "underlay IETF network".

Thank you. 


> -----Message d'origine-----
> De : Teas [] De la part de Wubo (lana)
> Envoyé : vendredi 9 juillet 2021 12:18
> À :
> Cc :
> Objet : Re: [Teas] New Version Notification for draft-wd-teas-ietf-
> network-slice-nbi-yang-03.txt
> Dear WG and chairs,
> The draft has been aligned with changes in the IETF Network Slice
> framework WG I-D.
> The Authors believe that it has been maturing with the inputs from
> the WG, and can be evaluated as a candidate for WG adoption.
> Diff:
> slice-nbi-yang-03
> Best regards,
> Bo (on behalf of the co-authors)
> -----邮件原件-----
> 发件人: []
> 发送时间: 2021年7月9日 17:32
> 收件人: Wubo (lana) <>; Dhruv Dhody
> <>; Liuyan Han <>; Reza
> Rokui <>; Tarek Saad <>
> 主题: New Version Notification for draft-wd-teas-ietf-network-slice-
> nbi-yang-03.txt
> A new version of I-D, draft-wd-teas-ietf-network-slice-nbi-yang-
> 03.txt
> has been successfully submitted by Bo Wu and posted to the IETF
> repository.
> Name:		draft-wd-teas-ietf-network-slice-nbi-yang
> Revision:	03
> Title:		A Yang Data Model for IETF Network Slice NBI
> Document date:	2021-07-09
> Group:		Individual Submission
> Pages:		45
> URL:  
> network-slice-nbi-yang-03.txt
> Status:
> network-slice-nbi-yang/
> Htmlized:
> ietf-network-slice-nbi-yang
> Diff: 
> ietf-network-slice-nbi-yang-03
> Abstract:
>    This document provides a YANG data model for the IETF Network
> Slice
>    Controller (NSC) Northbound Interface (NBI).  The model can be
> used
>    by a IETF Network Slice customer to request configuration, and
>    management IETF Network Slice services from the IETF NSC.
> The IETF Secretariat
> _______________________________________________
> Teas mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.