Subject: [Teas-ns-dt] FW: New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt

From: Kiran Makhijani <[email-masked]>
Date: Thu, 22 Oct 2020 06:12:22 +0000

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 

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, October 21, 2020 11:00 PM
To: Kiran Makhijani <[email-masked]>; Luis Contreras <[email-masked]>; Reza Rokui <[email-masked]>; Shunsuke Homma <[email-masked]>; Jeff Tantsura <[email-masked]>; Luis M. Contreras <[email-masked]>
Subject: New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt

A new version of I-D, draft-nsdt-teas-ietf-network-slice-definition-00.txt
has been successfully submitted by Kiran Makhijani and posted to the IETF repository.

Name:		draft-nsdt-teas-ietf-network-slice-definition
Revision:	00
Title:		Definition of IETF Network Slices
Document date:	2020-10-21
Group:		Individual Submission
Pages:		17
URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-nsdt-teas-ietf-network-slice-definition-00.txt&amp;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=7wm50bc73lEQm0WsZuuDrtMBr0hhmz3dUsSHLUji5r8%3D&amp;reserved=0
Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-nsdt-teas-ietf-network-slice-definition%2F&amp;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=diwg0Oe8QVWtuRFoP21aAAN%2FQ046hCe%2F1DI5vNgOH08%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-definition&amp;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=H%2BuJYcBjXiSrz1raGpMrRthMlWHAAjvdZIQuOcAp1YE%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-definition-00&amp;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798744414%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZMr1EeR5CXXBvuPd0SndoJYxehAdgAmmaLkEz%2BkXrXE%3D&amp;reserved=0

Abstract:
   This document provides a definition of the term "IETF Network Slice"
   for use within the IETF and specifically as a reference for other
   IETF documents that describe or use aspects of network slices.

   The document also describes the characteristics of an IETF network
   slice, related terms and their meanings, and explains how IETF
   network slices can be used in combination with end-to-end network
   slices or independent of them.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Oct 2020 09:43:48 +0100

Kiran, all,

I want to thank the authors of this draft for their work and for listening.
This version of the draft is a *substantial* improvement.

Of course, I still have some issues I'd like to work through. Some of my
concerns are "just" language usage where the choice of words or phrasing
means something that I don't think the authors intend. Other concerns are
about the details. But all in all, this is going in the right direction.

I still think there is too much text in this definitions document. I think
that is a natural result of having several documents in the pipe at the same
time. There is explanation of how things work and hang together that, in my
opinion, should relocate to other documents - maybe the framework, maybe
dedicated applicability statements. For example, I can see value in a
document explaining how IETF network slices fit into the models of
"end-to-end network slices" as conceived in other SDOs.

Best,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Kiran Makhijani
Sent: 22 October 2020 07:12
To: [email-masked]; TEAS WG <[email-masked]>
Subject: [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 

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, October 21, 2020 11:00 PM
To: Kiran Makhijani <[email-masked]>; Luis Contreras
<[email-masked]>; Reza Rokui
<[email-masked]>; Shunsuke Homma <[email-masked]>; Jeff
Tantsura <[email-masked]>; Luis M. Contreras
<[email-masked]>
Subject: New Version Notification for
draft-nsdt-teas-ietf-network-slice-definition-00.txt

A new version of I-D, draft-nsdt-teas-ietf-network-slice-definition-00.txt
has been successfully submitted by Kiran Makhijani and posted to the IETF
repository.

Name:		draft-nsdt-teas-ietf-network-slice-definition
Revision:	00
Title:		Definition of IETF Network Slices
Document date:	2020-10-21
Group:		Individual Submission
Pages:		17
URL:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.o
rg%2Farchive%2Fid%2Fdraft-nsdt-teas-ietf-network-slice-definition-00.txt&amp
;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C
0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
%7C2000&amp;sdata=7wm50bc73lEQm0WsZuuDrtMBr0hhmz3dUsSHLUji5r8%3D&amp;reserve
d=0
Status:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracke
r.ietf.org%2Fdoc%2Fdraft-nsdt-teas-ietf-network-slice-definition%2F&amp;data
=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0fee8
ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CUnknown%7CTWFpbGZ
sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C20
00&amp;sdata=diwg0Oe8QVWtuRFoP21aAAN%2FQ046hCe%2F1DI5vNgOH08%3D&amp;reserved
=0
Htmlized:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracke
r.ietf.org%2Fdoc%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-definition&amp;
data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0
fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CUnknown%7CTWF
pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
7C2000&amp;sdata=H%2BuJYcBjXiSrz1raGpMrRthMlWHAAjvdZIQuOcAp1YE%3D&amp;reserv
ed=0
Htmlized:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf
.org%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-definition-00&amp;data=04%7
C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5%7C0fee8ff2a3
b240189c753a1d5591fedc%7C1%7C1%7C637389431798744414%7CUnknown%7CTWFpbGZsb3d8
eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&am
p;sdata=ZMr1EeR5CXXBvuPd0SndoJYxehAdgAmmaLkEz%2BkXrXE%3D&amp;reserved=0

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: <[email-masked]>
Date: Thu, 22 Oct 2020 11:41:25 +0000

Hi Kiran, all, 

Thank you for sharing this updated version. 

(1)

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. 

(2)

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

(3)

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:   

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

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:[email-masked]] De la part de Kiran
> Makhijani
> Envoyé : jeudi 22 octobre 2020 08:12
> À : [email-masked]; TEAS WG <[email-masked]>
> Objet : [Teas] FW: New Version Notification for draft-nsdt-teas-
> ietf-network-slice-definition-00.txt
> 
> 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.

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 23 Oct 2020 17:46:42 +0000

Hi Med,
Many thanks for reviewing the updated text. 

Let ask naïve questions on (1) Can you explain what's misleading? and " **specific** to slicing vs generic ones."?  How do you see CPP/7297 relates to IETF network slices?

On (2) and (3): Terminology document is motivated to establish minimal common understanding independently - upon which further work can progress, as well as previous efforts can relate to. 

With that in mind, there are 2 ways to tie down RFC7297 -  we have applicability section in framework and appropriate text on how CPP applies can go there. Another option is to establish CPP relationship briefly with SLOs in section  4.1.1 to slices with a reference to 7297. In both cases we need your help to provide the right text. 

But that's secondary. Lets first cover (1).
-Kiran

> From: [email-masked] <[email-masked]>
> Sent: Thursday, October 22, 2020 4:41 AM
> To: Kiran Makhijani <[email-masked]>; [email-masked]; TEAS WG
> <[email-masked]>
> Subject: RE: New Version Notification for draft-nsdt-teas-ietf-network-slice-
> definition-00.txt
> 
> Hi Kiran, all,
> 
> 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:
> 
> ====
> * 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:
> 
>    <NETWORK_SLICE> ::=
> > De : Teas [mailto:[email-masked]] De la part de Kiran Makhijani
> > Envoyé : jeudi 22 octobre 2020 08:12 À : [email-masked]; TEAS WG
> > <[email-masked]> Objet : [Teas] FW: New Version Notification for
> > draft-nsdt-teas- ietf-network-slice-definition-00.txt
> >
> ___________________________________________________________________
> ______________________________________________________
> 
> 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.

---

From: <[email-masked]>
Date: Mon, 26 Oct 2020 09:27:22 +0000

Hi Kiran,

> Let ask naïve questions on (1) Can you explain what's misleading?

Sure.

Changing the name without adjusting the scope is what is misleading. The actual description is more about connectivity which is exactly what you had in previous versions of the draft but the use of "network slice" suggests this is not exclusively restricted to connectivity but can include "something else". There is a disconnect if you will between the scope as described in the draft and the current name. This discussion is meant to hopefully clarify this.

> and " **specific** to slicing vs generic ones."?  How do you see

The question is whether the required attributes to characterize the connectivity part of a slice can be used beyond slicing or there are attributes that are "tied" to slicing. We need to call out these exclusive attributes, if any. This is important from a modelling standpoint.

> CPP/7297 relates to IETF network slices?

This depends on the answer to the previous question, but from the current draft, the connectivity component of an "IETF Network Slice" can be expressed as a CPP. 

Cheers,
Med

> De : Kiran Makhijani [mailto:[email-masked]]
> Envoyé : vendredi 23 octobre 2020 19:47
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; teas-
> [email-masked]; TEAS WG <[email-masked]>
> Objet : RE: New Version Notification for draft-nsdt-teas-ietf-
> network-slice-definition-00.txt
> 
> Hi Med,
> Let ask naïve questions on (1) Can you explain what's misleading?
> and " **specific** to slicing vs generic ones."?  How do you see
> CPP/7297 relates to IETF network slices?
> 
> On (2) and (3): Terminology document is motivated to establish
> minimal common understanding independently - upon which further work
> can progress, as well as previous efforts can relate to.
> 
> With that in mind, there are 2 ways to tie down RFC7297 -  we have
> applicability section in framework and appropriate text on how CPP
> applies can go there. Another option is to establish CPP
> relationship briefly with SLOs in section  4.1.1 to slices with a
> reference to 7297. In both cases we need your help to provide the
> right text.
> 
> > To: Kiran Makhijani <[email-masked]>; [email-masked];
> TEAS
> > WG <[email-masked]>
> > 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:
> >
> > ====
> > * 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:
> >
> >    <NETWORK_SLICE> ::=
> > > Makhijani Envoyé : jeudi 22 octobre 2020 08:12 À :
> > > [email-masked]; TEAS WG <[email-masked]> Objet : [Teas] FW:
> New
> > > Version Notification for

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 28 Oct 2020 15:32:33 +0000

Hi Med, 
Well! while working on this major revision authors did not feel that primary scope need to be adjusted. Although a lot of re-write has happened. Deflating the tension with naming and addressing major comments  were the first steps. 

Our proposed definition has 2 parts, first one is connectivity (because we concern with network specific characteristics) and second is meeting service specific requirements, which allows consumer to specify its application/service needs. One could extend those objectives if they can be well-described through NBI and are feasible in the realized network.

I still do not know what is that "something else" you are alluding to? Terminology document should be very clear so it will be good to know what other things you have in mind that have been overlooked.

You are also asking whether required attributes to characterize an IETF network slice can be used beyond slicing. Without clearly knowing what you want, I see them being usable in the context of end-to-end slice (last section before security) which is broader than the IETF network slice. 

Thanks
Kiran

> Sent: Monday, October 26, 2020 2:27 AM
> Changing the name without adjusting the scope is what is misleading. The
> actual description is more about connectivity which is exactly what you had in
> previous versions of the draft but the use of "network slice" suggests this is not
> exclusively restricted to connectivity but can include "something else". There is
> a disconnect if you will between the scope as described in the draft and the
> current name. This discussion is meant to hopefully clarify this.
> 
> The question is whether the required attributes to characterize the connectivity
> part of a slice can be used beyond slicing or there are attributes that are "tied"
> to slicing. We need to call out these exclusive attributes, if any. This is
> important from a modelling standpoint.
> 
> This depends on the answer to the previous question, but from the current
> draft, the connectivity component of an "IETF Network Slice" can be expressed
> as a CPP.
> 
> Cheers,
> Med
> 
> > De : Kiran Makhijani [mailto:[email-masked]] Envoyé : vendredi
> > 23 octobre 2020 19:47 À : BOUCADAIR Mohamed TGI/OLN
> > <[email-masked]>; teas- [email-masked]; TEAS WG
> > <[email-masked]> Objet : RE: New Version Notification for
> > draft-nsdt-teas-ietf- network-slice-definition-00.txt
> >
> > Hi Med,
> > On (2) and (3): Terminology document is motivated to establish minimal
> > common understanding independently - upon which further work can
> > progress, as well as previous efforts can relate to.
> >
> > applies can go there. Another option is to establish CPP relationship
> > briefly with SLOs in section  4.1.1 to slices with a reference to
> > 7297. In both cases we need your help to provide the right text.
> >

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 28 Oct 2020 15:52:38 +0000

Thanks Adrian, 
According to authors the current text in this document is just enough to provide clarity on the IETF network slice concept. 
I remember you wanted current section 5 to be removed but we felt it's important and pruned it quite a bit - we will further combine section 5 and 10 to define end-to-end slices relationship and the structure in one place. 
Other than that, we are waiting for revision on isolation contribution from Jie, Luis, and Jeff.  

Yes, end-to-end slicing will need quite a bit of explanation but minimal description here is also important to show the scope of IETF network slices in the broader concept. 

I hope that the mailing list this time agrees that it is a reasonable terminology-set. 
-Kiran

> From: Adrian Farrel <[email-masked]>
> Sent: Thursday, October 22, 2020 1:44 AM
> To: Kiran Makhijani <[email-masked]>; [email-masked]; 'TEAS WG'
> <[email-masked]>
> Subject: RE: [Teas] FW: New Version Notification for draft-nsdt-teas-ietf-
> Of course, I still have some issues I'd like to work through. Some of my concerns
> are "just" language usage where the choice of words or phrasing means
> something that I don't think the authors intend. Other concerns are about the
> details. But all in all, this is going in the right direction.
> 
> I still think there is too much text in this definitions document. I think that is a
> natural result of having several documents in the pipe at the same time. There
> is explanation of how things work and hang together that, in my opinion,
> should relocate to other documents - maybe the framework, maybe dedicated
> applicability statements. For example, I can see value in a document explaining
> how IETF network slices fit into the models of "end-to-end network slices" as
> conceived in other SDOs.
> 
> Best,
> Adrian
> 
> Subject: [Teas] FW: New Version Notification for draft-nsdt-teas-ietf-network-
> slice-definition-00.txt
> 
> <[email-masked]>; Shunsuke Homma
> <[email-masked]>; Jeff Tantsura <[email-masked]>;
> Luis M. Contreras <[email-masked]>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=04%7C01%7Ckiranm%40futu
> rewei.com%7C6dad12e7b3d147f151ce08d876669af2%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C0%7C637389530342292715%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=KTwJI1b62%2BemHwnZjOgc8v446%2Bgxhl8N3
> Gy4QP6BdU0%3D&amp;reserved=0

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2020 16:20:24 -0000

I hope this debate is not dancing on the head of a pin, but it does seem to
be quite fundamental to what we are trying to achieve.

On the one hand, a network contains many "resources" such as storage,
compute, virtual functions, and access to content. If the process of slicing
is to 'share out' the network resources by building "virtual networks," then
those virtual networks surely need to include all the sorts of things that a
physical network includes.

On the other hand, the primary need is clearly connectivity. Without
connectivity we have nothing.

Maybe we have two concepts:
- IETF network slicing
- IETF connectivity network slicing

The second of these is a subset of the first.
The second is what Kiran is seeking to discuss in this draft (I think,
reading her emails and having talked with her).
The first is, I think, what Med is talking about.

Notwithstanding, all of this, Kiran's approach is the right one for this
draft at the moment. That is, fix the most inflammatory issues first; pick
up a pile of nits along the way; reduce the text to only that which is
necessary (work in progress); and then come up with something we can debate
a bit more clearly.

Cheers,
Adrian

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Kiran Makhijani
Sent: 28 October 2020 15:33
To: [email-masked]; [email-masked]; TEAS WG
<[email-masked]>
Subject: Re: [Teas-ns-dt] New Version Notification for
draft-nsdt-teas-ietf-network-slice-definition-00.txt

Hi Med, 
Well! while working on this major revision authors did not feel that primary
scope need to be adjusted. Although a lot of re-write has happened.
Deflating the tension with naming and addressing major comments  were the
first steps. 

Our proposed definition has 2 parts, first one is connectivity (because we
concern with network specific characteristics) and second is meeting service
specific requirements, which allows consumer to specify its
application/service needs. One could extend those objectives if they can be
well-described through NBI and are feasible in the realized network.

I still do not know what is that "something else" you are alluding to?
Terminology document should be very clear so it will be good to know what
other things you have in mind that have been overlooked.

You are also asking whether required attributes to characterize an IETF
network slice can be used beyond slicing. Without clearly knowing what you
want, I see them being usable in the context of end-to-end slice (last
section before security) which is broader than the IETF network slice. 

Thanks
Kiran

> If you have received this email in error, please notify the sender and
delete this
> message and its attachments.

-- 
Teas-ns-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Oct 2020 16:20:24 -0000

Thanks Kiran,

It is getting markedly better.
I'll wait for Jie, Luis, and Jeff before I look at the draft again.

A

-----Original Message-----
From: Kiran Makhijani <[email-masked]> 
Sent: 28 October 2020 15:53
To: [email-masked]; [email-masked]; 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] FW: New Version Notification for

Thanks Adrian, 
According to authors the current text in this document is just enough to
provide clarity on the IETF network slice concept. 
I remember you wanted current section 5 to be removed but we felt it's
important and pruned it quite a bit - we will further combine section 5 and
10 to define end-to-end slices relationship and the structure in one place. 
Other than that, we are waiting for revision on isolation contribution from
Jie, Luis, and Jeff.  

Yes, end-to-end slicing will need quite a bit of explanation but minimal
description here is also important to show the scope of IETF network slices
in the broader concept. 

I hope that the mailing list this time agrees that it is a reasonable
terminology-set. 
-Kiran

> Of course, I still have some issues I'd like to work through. Some of my
concerns
> I still think there is too much text in this definitions document. I think
that is a
> Subject: [Teas] FW: New Version Notification for
draft-nsdt-teas-ietf-network-
> FYI: Please find new version of  IETF network slices (previously called
transport
> slices) definition document.
> 
feedback
> tf.o

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 28 Oct 2020 13:16:16 -0400

Hmmm.  I had understood something slightly different.   I may well have 
misunderstood.
I thought we would adopt as a WG document a document with place-holders 
for things like isolation.  Then folks could see if they could come up 
with something to fill those holes that the WG would accept during teh 
WG work on the document.  If we reached the end, and could not fill 
those gaps, then we would see if we could agree to remove the 
placeholder sections.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 29 Oct 2020 09:38:33 +0000

Hi Adrian, 

You got it well. Especially, 

> - IETF connectivity network slicing

Kiran, I fully agree with you that "Terminology document should be very clear". This is why I do think that explicitly pointing to the concept we are looking at will help us progress.

Thanks. 

Cheers,
Med

> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : mercredi 28 octobre 2020 17:20
> À : 'Kiran Makhijani' <[email-masked]>; BOUCADAIR Mohamed
> TGI/OLN <[email-masked]>; [email-masked]; 'TEAS
> WG' <[email-masked]>
> Objet : RE: [Teas-ns-dt] New Version Notification for draft-nsdt-
> teas-ietf-network-slice-definition-00.txt
> 
> I hope this debate is not dancing on the head of a pin, but it does
> seem to be quite fundamental to what we are trying to achieve.
> 
> On the one hand, a network contains many "resources" such as
> storage, compute, virtual functions, and access to content. If the
> process of slicing is to 'share out' the network resources by
> building "virtual networks," then those virtual networks surely need
> to include all the sorts of things that a physical network includes.
> 
> The second is what Kiran is seeking to discuss in this draft (I
> think, reading her emails and having talked with her).
> Notwithstanding, all of this, Kiran's approach is the right one for
> this draft at the moment. That is, fix the most inflammatory issues
> first; pick up a pile of nits along the way; reduce the text to only
> that which is necessary (work in progress); and then come up with
> something we can debate a bit more clearly.
> 
> Cheers,
> Adrian
> 
> Subject: Re: [Teas-ns-dt] New Version Notification for draft-nsdt-
> teas-ietf-network-slice-definition-00.txt
> 
> Hi Med,
> Well! while working on this major revision authors did not feel that
> primary scope need to be adjusted. Although a lot of re-write has
> happened.
> Deflating the tension with naming and addressing major comments
> were the first steps.
> 
> Our proposed definition has 2 parts, first one is connectivity
> (because we concern with network specific characteristics) and
> second is meeting service specific requirements, which allows
> consumer to specify its application/service needs. One could extend
> those objectives if they can be well-described through NBI and are
> feasible in the realized network.
> 
> Terminology document should be very clear so it will be good to know
> what other things you have in mind that have been overlooked.
> 
> You are also asking whether required attributes to characterize an
> IETF network slice can be used beyond slicing. Without clearly
> knowing what you want, I see them being usable in the context of
> end-to-end slice (last section before security) which is broader
> than the IETF network slice.
> 
> Thanks
> Kiran
> 
> 
> > Changing the name without adjusting the scope is what is
> misleading.
> > The actual description is more about connectivity which is exactly
> > what you
> had in
> > previous versions of the draft but the use of "network slice"
> suggests
> this is not
> > exclusively restricted to connectivity but can include "something
> else".
> There is
> > a disconnect if you will between the scope as described in the
> draft
> > and
> the
> > The question is whether the required attributes to characterize
> the
> connectivity
> > part of a slice can be used beyond slicing or there are attributes
> > that
> are "tied"
> > to slicing. We need to call out these exclusive attributes, if
> any.
> > This
> is
> > This depends on the answer to the previous question, but from the
> > current draft, the connectivity component of an "IETF Network
> Slice"
> > can be
> expressed
> > as a CPP.
> >
> > Cheers,
> > Med
> >
> > > reference to 7297. In both cases we need your help to provide
> the right text.
> > >
> > > >    requirements and associated network behaviors.  IETF
> Network
> > > Slices
> > > >    infrastructure connectivity and technologies used.  This is
> to
> > > allow
> > > > > This is still a work in progress document but several
> comments
> > > and
> > confidentielles ou privilegiees et ne doivent donc pas etre
> diffuses,
> exploites ou
> > signaler a l'expediteur et le detruire ainsi que les pieces
> jointes.
> > Les
> messages
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should
> not
> > be distributed,
> used
> > As emails may be altered, Orange is not liable for messages that
> have
> > been modified, changed or falsified.
> > Thank you.
> 
> --
> Teas-ns-dt mailing list
> [email-masked]

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 30 Oct 2020 01:51:14 +0000

[have the discussion in design team first]

Hi Kiran, Adrian and Team,

Recently Luis, Jeff and I had some discussion on isolation and produced the text below which consolidates with the text in section 9 of the current definition draft. Please review and share your opinions on it, thanks. 

Best regards,
Jie (on behalf of Luis and Jeff)

-------
9.  Isolation in IETF Network Slices

9.1. Isolation as an IETF Network Slice Requirement

A customer may request, either explicitly or implicitly through the description of SLOs and attributes that the IETF Network Slice delivered to them is isolated from any other network slices of services delivered to any other customers. This could be the requirement of network slices for e.g. critical services, emergencies, etc. That is, that changes to the other network slices of services do not have any negative impact on the delivery of the IETF network slice.

This requirement may be met by simple conformance with other SLOs. For example, traffic congestion (interference from other services) might impact the latency experienced by an IETF Network Slice. Thus, in this example, conformance to a latency SLO would be the primary requirement for delivery of the IETF network slice service, and isolation from other services might be only a means to that end.

In a more general sense, isolation can be interpreted as several detailed requirements:

1)	Traffic separation. Traffic of one network slice must not be shared with the endpoints in other network slices. On the other hand, traffic of other network slices or services must not be shared to the endpoints of this network slice. 
 
2)	Interference avoidance. Changes in other network slices should not have negative impact to the SLOs of the network slice. Here the changes in other network slice may include the changes in connectivity, traffic volume, traffic pattern, etc.

3)	Service continuity. The IETF Network Slice with a high degree of isolation will provide service continuity even in case of network situations producing general service degradation (e.g., major congestion events, etc.). This could imply the reservation of resources in the network to be used for a reduced set of IETF Network Slices.

How delivery of isolation is achieved in the realization of an IETF network slice is implementation and technology dependent.  The customer of a network slice may not be aware of how the isolation requirement is achieved. The realization of the network slice isolation may further depend on how a network operator decides to operate its network and deliver services on top of it. 

9.2. Isolation in realization of IETF Network Slice

The realization of isolation is implementation and technology dependent. The isolation requirement can be achieved with existing, in-development, and potential new technologies in IETF. 

Isolation may be achieved in the underlying network by various forms of resource partitioning ranging from dedicated allocation of resources for a specific IETF Network Slice, to sharing or resources with safeguards.

For example, traffic separation between different IETF network slices may be achieved using VPN technologies, such as L3VPN, L2VPN, EVPN, etc. as well as optical and or LSP/tunnel levels.

Interference avoidance may be achieved by network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing in using shared network resources, etc. Finally, service continuity may be ensured by reserving backup paths for critical traffic, dedicating specific network resources for a selected number of network slices, etc.

9.3. Relationship with Isolation in 5G Network Slice
 
In the context of 5G network slice, "isolation level" is listed as one of the attributes which can be used to characterize the type of network slice [GSMA Generic Network Slice Template]. For 5G network slice, different types of isolation are considered, including physical and logical isolation. Physical isolation refers to different physical network entities, and logical isolation is further classified into virtual resource isolation, network function isolation and tenant/service isolation. 
 
The isolation attribute of IETF network slice may be considered as corresponding to physical or virtual resource isolation and tenant/service isolation in 5G network slice.

> From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Kiran
> Makhijani
> Sent: Wednesday, October 28, 2020 11:53 PM
> Subject: Re: [Teas-ns-dt] [Teas] FW: New Version Notification for
> description here is also important to show the scope of IETF network slices in
> the broader concept.
> 
> > Of course, I still have some issues I'd like to work through. Some of
> > my concerns are "just" language usage where the choice of words or
> > phrasing means something that I don't think the authors intend. Other
> > concerns are about the details. But all in all, this is going in the right
> direction.
> >
> > I still think there is too much text in this definitions document. I
> > think that is a natural result of having several documents in the pipe
> > at the same time. There is explanation of how things work and hang
> > together that, in my opinion, should relocate to other documents -
> > maybe the framework, maybe dedicated applicability statements. For
> > example, I can see value in a document explaining how IETF network
> > slices fit into the models of "end-to-end network slices" as conceived in
> other SDOs.
> >
> > Best,
> > Adrian
> >
> > draft-nsdt-teas-ietf-network- slice-definition-00.txt
> >
> > <[email-masked]>; Jeff Tantsura
> > <[email-masked]>; Luis M. Contreras
> > A new version of I-D,
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.
> > ie
> > tf.o
> > ;data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d2
> 08d
> > 8764fa8e5%7C
> >
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419
> %7
> > CUnknown%7CTW
> >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VC
> > I6Mn0%3D
> > %7C2000&amp;sdata=7wm50bc73lEQm0WsZuuDrtMBr0hhmz3dUsSHLUji
> 5r8
> > %3D&amp;reserve
> > d=0
> > Status:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tra
> > cke
> =04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d876
> 4f
> > a8e5%7C0fee8
> >
> ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%7CU
> nk
> > nown%7CTWFpbGZ
> >
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n
> > 0%3D%7C20
> >
> 00&amp;sdata=diwg0Oe8QVWtuRFoP21aAAN%2FQ046hCe%2F1DI5vNgOH0
> 8
> > %3D&amp;reserved
> > =0
> > Htmlized:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tra
> > cke
> data=04%7C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208
> d8
> > 764fa8e5%7C0
> >
> fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637389431798734419%
> 7C
> > Unknown%7CTWF
> >
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI
> > 6Mn0%3D%
> >
> 7C2000&amp;sdata=H%2BuJYcBjXiSrz1raGpMrRthMlWHAAjvdZIQuOcAp1YE
> %3
> > D&amp;reserv
> > ed=0
> > Htmlized:
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> > s.ie
> > tf
> C01%7Ckiranm%40futurewei.com%7C80aac7efa01d43e055d208d8764fa8e5
> %
> > 7C0fee8ff2a3
> >
> b240189c753a1d5591fedc%7C1%7C1%7C637389431798744414%7CUnkno
> wn
> > %7CTWFpbGZsb3d8
> >
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D
> > %7C2000&am
> >
> p;sdata=ZMr1EeR5CXXBvuPd0SndoJYxehAdgAmmaLkEz%2BkXrXE%3D&amp;
> re
> > served=0
> >
> >
> > Abstract:
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.
> > ie