Re: [Teas] New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt Thu, 22 October 2020 11:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7A683A0A35; Thu, 22 Oct 2020 04:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 1jU1f045PIA7; Thu, 22 Oct 2020 04:41:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B6B23A0A2D; Thu, 22 Oct 2020 04:41:28 -0700 (PDT)
Received: from (unknown [xx.xx.xx.4]) by (ESMTP service) with ESMTP id 4CH56Z5DSHz30q0; Thu, 22 Oct 2020 13:41:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1603366886; bh=aNYrwEqD+rJ5zvrNF72Mfp+Fq7sqCGmxHP78tJVJAiw=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=O0z+mgrgQ2S6kD1jnQbHBYJSMU6S0WIXx8tnPRTZETa94tnXzyCL5zd7iM8MKq3Qa p0nnabKZFwQ12mPQC4jmbBtCWPRo8xmR/9C9671fLBHVekx8xVfIsl1OvowbRQOBDu h5DUYRBNxz5MCX800Jtmo1uHOdlA960ulUFWzRSc4OFkW4R2zR+JI31+2fAVMJkAsE HqqfeSkHrJjDPe/J4rXnCZ5GrBVs+X6M3bWMPM5GnEDAvyABCbeJqhV6raIi800Z/X i8d1JF0ZQ7ct8al0Dbyswmbe6sH323c/z5jz2LQHH1Sb4oMmMPRO47+0QjJlam7P6g wXrcrFuYPyaog==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by (ESMTP service) with ESMTP id 4CH56Z47rpzCqkP; Thu, 22 Oct 2020 13:41:26 +0200 (CEST)
From: <>
To: Kiran Makhijani <>, "" <>, TEAS WG <>
Thread-Topic: New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt
Thread-Index: AQHWqDiHF7SMzkTWgkOAunq66Da6wamjIPdQgAA8QAA=
Date: Thu, 22 Oct 2020 11:41:25 +0000
Message-ID: <4718_1603366886_5F916FE6_4718_480_1_787AE7BB302AE849A7480A190F8B933031564F1F@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Teas] New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.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: Thu, 22 Oct 2020 11:41:30 -0000

Hi Kiran, all, 

Thank you for sharing this updated version. 


It seems that the scope is still connectivity:

   An IETF Network Slice is a well-defined structure of connectivity
   requirements and associated network behaviors.  IETF Network Slices
   are defined such that they are independent of the underlying
   infrastructure connectivity and technologies used.  This is to allow
   an IETF Network Slice consumer to describe their network connectivity
   and relevant objectives in a common format, independent of the
   underlying technologies used. 

Which is fine by me but the use of "network slice" is misleading. 


I already made this comment during the call for adoption, but I don't see it addressed in this version: It would be really cool if we can identify attributes that are **specific** to slicing vs generic ones. I'm particularly referring to the CPP defined in RFC7297:

   3.  Connectivity Provisioning Profile (CPP) 
     3.1.  Customer Nodes Map 
     3.2.  Scope  
     3.3.  QoS Guarantees   
     3.4.  Availability   
     3.5.  Capacity   
     3.6.  Conformance Traffic  
     3.7.  Overall Traffic Guarantees   
     3.8.  Traffic Isolation  
     3.9.  Flow Identification  
     3.10. Routing and Forwarding   
     3.11. Activation Means   
     3.12. Invocation Means   
     3.13. Notifications  


Both clarifications are important to be worked out for the following reasons: 
* If the "IETF Network slice" is more than connectivity, then its connectivity component does not need to signal explicitly this is about a "slice" because its presence in the "IETF Network slice" is sufficient to infer that.

* If there are no connectivity-related attributes that are specific to slicing, then we need to factorize and use a generic modelling for the connectivity component. For example, an ABNF inspired from RFC7297 would look like:   

                 <Some_Non_Connectivity_Component> ...
                 <Connectivity Provisioning Component> ...
   <Connectivity Provisioning Component> ::=
                              <CONNECTIVITY_PROVISIONING_PROFILE> ...
                              <Customer Nodes Map>
                              <QoS Guarantees>
                              <Traffic Isolation>
                              <Conformance Traffic>
                              <Flow Identification>
                              <Overall Traffic Guarantees>
                              <Routing and Forwarding>
                              <Activation Means>
                              <Invocation Means>
                              <Optional Information Element> ...


> -----Message d'origine-----
> De : Teas [] De la part de Kiran
> Makhijani
> Envoyé : jeudi 22 octobre 2020 08:12
> À :; TEAS WG <>
> Objet : [Teas] FW: New Version Notification for draft-nsdt-teas-
> ietf-network-slice-definition-00.txt
> Hello Teas and teas-ns-dt,
> FYI: Please find new version of  IETF network slices (previously
> called transport slices) definition document.
> This is still a work in progress document but several comments and
> feedback received till now have been addressed. We want to share
> updates so far and look forward to further comments and discussion.
> Thanks
> -Authors


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.