Subject: [Teas-ns-dt] New document: IETF definition of transport slice

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 28 Oct 2019 06:10:03 +0000

All,

As per network slicing DT meeting on Oct 21st , Shunsuke, Kiran and I was given the task of defining the transport slice.

Attached please find the first version of document “IETF Definition of Transport Slice”. We believe that this will be a basis for a new draft to clearly define the transport slice for IETF.
All feedback and comments are welcome.

Jari, please allocate 10-15 min slot in our next meeting on Oct 31st to discuss this.

Cheers,

Reza

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 28 Oct 2019 15:42:52 +0800

The concept of slice emphasizes mainly the separation, not the connection.  Do we need to add the definition of physical resource separation or logical resource separation?  Certainly all separation should meet the SLA requirement of the applications.

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Rokui, Reza (Nokia - CA/Ottawa)
发送时间: 2019年10月28日 14:10
收件人: Jari Arkko; [email-masked]; Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
抄送: Rokui, Reza (Nokia - CA/Ottawa)
主题: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 28 Oct 2019 08:33:54 +0000

Of course the transport slice implementation shall support any sort of physical or virtual separations. It shall be fully supported. I will add it to document.

however as discussed in document, the definition of transport slice does not change. During the transport slice implementation, operator ( based on local policy or policies passed in as part of transport slice api) decides how to implement, i.e. whether physical or virtual separation needed.

Cheers,

Reza

Sent from my iPhone

On Oct 28, 2019, at 7:42 AM, Aijun Wang <[email-masked]> wrote:

Best Regards.

Aijun Wang
China Telecom

All,

Cheers,

Reza

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 28 Oct 2019 15:15:51 +0000

Hi,

I remember that on last conference call it was suggested by Xuesong or Kiran that we firstly collect the definition of network slicing from existing drafts, then pick or suggest definitions for transport network slice. Thus maybe we should also go through the collection of definitions in existing drafts on next conference call? This could also help us to understand the status and relationship of the existing drafts.

As for this document, my understanding is it gives examples which help to understand the relationship between transport network slice and End-to-End network slice. And it is good to know that the definition in this document aligns with the definition in draft-ietf-teas-enhanced-vpn.

However, I’m a little confused with the statement “the endpoints of Transport Slice definition might be different from endpoints of its implementation”. Does this actually mean that the same network connectivity requirement can be described either from the customer’s view or from the network’s view?

And since “network function” is mentioned many times in this document and can refer to gNBs, FW and routers, maybe we need to have a definition of “network function”.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 2:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 29 Oct 2019 00:58:14 +0000

Hi,

I understand the document represents the connections of transport network slice based on implementations. It is very helpful to understand, but in addition, isolation consideration from service(3GPP) perspective should be added, I think. For example, in "Implementation of Scenario-2", at least two types of 3GPP network slicing (gNB -> UPF2/3) will share a same Tunnel. It is a natural approach but definition/clarification of it is necessary in the document; strict isolation and loose isolation from service perspective. It will impact on monitoring SLA.
(Figure-8 has same label: R1. It is typo.)

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 29 Oct 2019 02:28:45 +0000

Hi Reza,

Thank you for starting the work and provide context to summarize your understanding about “Transport Network Slice”.
As I proposed in the last call meeting, I listed all the definition that has been defined in the current IETF drafts. I think this could also be a good start to consider all the possible  ideas and helpful to come to an agreement.

P.S. I think there is some confusion between me and Kiran. I volunteer to handle this part of work in the last call meeting. It will be great if we could do this together.

Best Regards
Xuesong

All,

Cheers,

Reza

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 30 Oct 2019 14:33:43 +0900

As some members raised a question, we may need to clarify the treat of "isolation levels (physical vs. logical, hard/strict vs. soft/loose)" in IETF.

In my understanding, the most important role of "transport slice" is providing "connectivity" between/among endpoints (i.e., network functions or edge nodes of domains) "with fulfilling specific SLA", and "isolation" is one of key factors for maintaining the SLA.

SLA is decided between slice provider and tenant, and the appropriate isolation level would be selected on the basis of the SLA. In other words,  "isolation level" should be described together with what kind of SLA is required. It will take time to sort it, and it will be better to quote some definitions of other SDOs, such as 3GPP, if there is. Tomonobu, could you please tell us which 3GPP document describes service perspectives and isolation considerations?

BTW, there are some IETF technologies (e.g., DiffServ, RSVP) to provide isolation, and I assume it will be useful to organize how strength of isolation each technology can provide.

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

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

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 30 Oct 2019 14:48:23 +0900

Hi Xuesong,

Thank you for list up the I-Ds related to network slicing. And this discussion is opened and your contribution would be welcomed.

I’m checking the list, and I assume we need to make criteria to judge which document we need refer because there are a lot of documents and some of them are already expired. For example, should we refer WG documents on a priority basis? 

Also, digesting the definitions would be help for clarifying the gaps against the definition Reza shared. 

Regards,

Shunsuke

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Tuesday, October 29, 2019 11:29 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Jari Arkko; [email-masked]; Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi Reza,

Best Regards

Xuesong

All,

Cheers,

Reza

---

From: <[email-masked]>
Date: Wed, 30 Oct 2019 15:39:11 +0800 (CST)

Hi Shunsuke,

Thank you for starting the work and I think this work is necessary.

I would like to update the item 27 ：  draft-peng-lsr-network-slicing  Expired " of the list to "draft-peng-teas-network-slicing-00 Active", and the active draft link is :https://tools.ietf.org/html/draft-peng-teas-network-slicing-00.

Regards,

Ran

原始邮件

发件人：ShunsukeHomma <[email-masked]>
收件人：'Gengxuesong (Geng Xuesong)' <[email-masked]>;'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>;'Jari Arkko' <jari.arkko=[email-masked]>;[email-masked] <[email-masked]>;'Kiran Makhijani' <[email-masked]>;'Kiran Makhijani' <[email-masked]>;'Shunsuke Homma' <[email-masked]>;
日 期 ：2019年10月30日 13:49
主 题 ：Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi Xuesong,

 

 

 

Regards,

Shunsuke

 

 

Hi Reza,

 

 

Best Regards

Xuesong

 

 

All,

 

 

 

Cheers,

Reza

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 30 Oct 2019 08:43:41 +0000

Hi Shunsuke,

Regarding isolation level, as far as I know, there is no concrete definition in 3GPP. However, TS 22.261 shows the concept of service requirements while it is not clear how transport slice should follow it: http://www.3gpp.org/ftp//Specs/archive/22_series/22.261/22261-h01.zip

6.1 Network slicing
"Traffic and services in one network slice shall have no impact on traffic and services in other network slices in the same network."
"Creation, modification, and deletion of a network slice shall have no or minimal impact on traffic and services in other network slices in the same network."
"The 5G system shall enable the network operator to define a minimum available capacity for a network slice. Scaling of other network slices on the same network shall have no impact on the availability of the minimum capacity for that network slice."
"The 5G system shall enable the network operator to define a priority order between different network slices in case multiple network slices compete for resources on the same network."
"The 5G system shall support means by which the operator can differentiate policy control, functionality and performance provided in different network slices."

Thanks,
Tomonobu

-----Original Message-----
From: Shunsuke Homma <[email-masked]> 
Sent: Wednesday, October 30, 2019 2:34 PM
To: 丹羽 朝信 <[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Shunsuke Homma' <[email-masked]>
Cc: [email-masked]; 'Jari Arkko' <jari.arkko=[email-masked]>
Subject: RE: [Teas-ns-dt] New document: IETF definition of transport slice

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 30 Oct 2019 09:06:08 +0000

I agree with Shunsuke. It is important to keep definition generic (and simple to understand). isolation is part of SLA requirement.
With SLAs in template, it should be possible to describe isolation - this could be in terms of a service/network function or link attributes.
Thanks
Kiran

[Kiran Makhijani - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=85uz9)	[85uz9]

On October 30, 2019 at 5:34 GMT, Shunsuke Homma <[email-masked]> wrote:

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 30 Oct 2019 09:33:34 +0000

Hi Kiran and Shunsuke,

I also agree that isolation can be considered as part of SLA requirement, while it may not be reflected by the existing parameters used to describe SLA. Thus as I mentioned in one previous email, isolation could be another dimension to describe the requirement.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Kiran Makhijani
Sent: Wednesday, October 30, 2019 5:06 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; jari.arkko=[email-masked]
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

[图像已被发件人删除。]

Kiran Makhijani - Chat @ Spike<https://www.spikenow.com/?ref=spike-organic-signature&_ts=85uz9>

[图像已被发件人删除。 85uz9]

On October 30, 2019 at 5:34 GMT, Shunsuke Homma <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]<mailto:[email-masked]>; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

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

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 30 Oct 2019 10:24:38 +0000

Ok, can I say we agree on the current definition and that Isolation as a requirement?
I think it is an important requirement and as we progress, among other terms we will need a lot more discussion on isolation so that corresponding template will have means to express them.

[Kiran Makhijani - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=85ym3)	[85ym3]

On October 30, 2019 at 9:33 GMT, Dongjie Jimmy <[email-masked]> wrote:

Hi Kiran and Shunsuke,

Best regards,

Jie

Thanks

Kiran

[图像已被发件人删除。]

[Kiran Makhijani - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=85uz9)

[图像已被发件人删除。 85uz9]

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 30 Oct 2019 21:16:08 -0400

While it is true that isolation is one parameter in the SLA, it is the key
characteristic to separate a network slice from a generic network, so I
would agree that the keyword "isolation" or its equivalent should be in the
definition.

In the attached document, the definition is described as:

*A Transport Slice* is an abstract network topology *connecting* different
network functions (NFs) with appropriate isolation and specific Service
Level Agreement (SLA) described in terms of shared or dedicated network
resources.

Here are some thoughts on it:
- NFs: why a slice can only connect NFs? Is it too restrictive? A network
transporting data traffic may or may not use NFs.

- SLA: Eric has brought up some good aspects of SLA. My reading is that:

An SLA:
* Covers a broader scope of requirements than transport characteristics,
including something like measurement methodologies bond to legal terms.
* Is defined slowly and statically.
* Can be based on one of several commonly defined ones.

If SLA is used in the definition, this term would need to be defined also.

3GPP TS 23.501 uses the following to define the network slice:
Network Slice: A logical network that provides specific network
capabilities and network characteristics.

Here the term "network characteristics" is used instead of SLA, and it may
be more appropriate here also. Restricting the scope to "transport" does
not have to alter other aspects of the base definition, especially
considering what Eric described and the fact that our slices are managed
more dynamically.

Thanks,
- Xufeng

On Wed, Oct 30, 2019 at 6:24 AM Kiran Makhijani <[email-masked]> wrote:

> I think it is an important requirement and as we progress, among other
> terms we will need a lot more discussion on isolation so that corresponding
> template will have means to express them.
>
>   *Kiran Makhijani* - Chat @ Spike
> <https://www.spikenow.com/?ref=spike-organic-signature&_ts=85ym3> [image:
> 85ym3]
>
> I also agree that isolation can be considered as part of SLA requirement,
> while it may not be reflected by the existing parameters used to describe
> SLA. Thus as I mentioned in one previous email, isolation could be another
> dimension to describe the requirement.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Teas-ns-dt [mailto:[email-masked]] *On Behalf Of *Kiran
> Makhijani
> *Sent:* Wednesday, October 30, 2019 5:06 PM
> *To:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Cc:* [email-masked]; jari.arkko=[email-masked]
> *Subject:* Re: [Teas-ns-dt] New document: IETF definition of transport
> slice
>
>
>
> I agree with Shunsuke. It is important to keep definition generic (and
> simple to understand).  isolation is part of SLA requirement.
>
>  With SLAs in template, it should be possible to describe isolation - this
> could be in terms of a service/network function or link attributes.
>
> Thanks
>
> Kiran
>
>
>
>
>
>
>
>
>
>
> *Kiran Makhijani* - Chat @ Spike
> <https://www.spikenow.com/?ref=spike-organic-signature&_ts=85uz9>
>
>
>
> As some members raised a question, we may need to clarify the treat of
> "isolation levels (physical vs. logical, hard/strict vs. soft/loose)" in
> IETF.
>
> In my understanding, the most important role of "transport slice" is
> providing "connectivity" between/among endpoints (i.e., network functions
> or edge nodes of domains) "with fulfilling specific SLA", and "isolation"
> is one of key factors for maintaining the SLA.
>
> SLA is decided between slice provider and tenant, and the appropriate
> isolation level would be selected on the basis of the SLA. In other words,
> "isolation level" should be described together with what kind of SLA is
> required. It will take time to sort it, and it will be better to quote some
> definitions of other SDOs, such as 3GPP, if there is. Tomonobu, could you
> please tell us which 3GPP document describes service perspectives and
> isolation considerations?
>
> BTW, there are some IETF technologies (e.g., DiffServ, RSVP) to provide
> isolation, and I assume it will be useful to organize how strength of
> isolation each technology can provide.
>
> Best regards,
>
> Shunsuke
>
> I understand the document represents the connections of transport network
> slice based on implementations. It is very helpful to understand, but in
> addition, isolation consideration from service(3GPP) perspective should be
> added, I think. For example, in "Implementation of Scenario-2", at least
> two types of 3GPP network slicing (gNB -> UPF2/3) will share a same Tunnel.
> It is a natural approach but definition/clarification of it is necessary in
> the document; strict isolation and loose isolation from service
> perspective. It will impact on monitoring SLA.
> To: Jari Arkko <jari.arkko=[email-masked]>;
> [email-masked]; Kiran Makhijani <[email-masked]>; Kiran
> Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
> As per network slicing DT meeting on Oct 21st , Shunsuke, Kiran and I was
> given the task of defining the transport slice.
>
>
>
> Attached please find the first version of document “IETF Definition of
> Transport Slice”. We believe that this will be a basis for a new draft to
> clearly define the transport slice for IETF.
>

---

From: Shunsuke Homma <[email-masked]>
Date: Thu, 31 Oct 2019 11:51:47 +0900

Hi Tomonobu,

Thank you for telling us the document and summarizing key points about network slicing. They are useful to understand their thoughts on network slicing.

As far as I read the characteristics, it seems that 3GPP requires strict isolation for network slicing. 
(e.g., the first point describes "one network slice shall have no impact on traffic and services in other network slices")
Is it correct?

In my understanding, strict isolation will have scalability problem (e.g., it may need queue separation) and raise service cost. If possible, I'd like to allow IETF transport slice to support not only strict isolation but also loose isolation.

Anyway, we will need to have our own thought on isolation and SLA.

Regards,

Shunsuke

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 30, 2019 5:44 PM
To: Shunsuke Homma; 'Rokui, Reza (Nokia - CA/Ottawa)'; 'Kiran Makhijani'; 'Kiran Makhijani'; 'Shunsuke Homma'
Cc: [email-masked]; 'Jari Arkko'
Subject: RE: [Teas-ns-dt] New document: IETF definition of transport slice

Hi Shunsuke,

6.1 Network slicing

Thanks,
Tomonobu

-----Original Message-----
From: Shunsuke Homma <[email-masked]> 
Sent: Wednesday, October 30, 2019 2:34 PM
To: 丹羽 朝信 <[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Shunsuke Homma' <[email-masked]>
Cc: [email-masked]; 'Jari Arkko' <jari.arkko=[email-masked]>
Subject: RE: [Teas-ns-dt] New document: IETF definition of transport slice

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 31 Oct 2019 09:32:38 +0000

Hi all,

Regarding the Isolation topic, some thoughts from my side.

To keep consistency with the document from Reza, Shunsuke and Kiran, the transport slice definition is technology agnostic, and as such, no detail about how to realize the isolation should be included in the definition. However, some characterization could be specified. To this respect let me come back to the attributes defined in the generic slice template from GSMA with respect to Isolation. There, this attribute is characterized as:
.- No isolation
.- Physical isolation
.- Logical isolation

This should be enough for the NBI of the Transport Slice Manager. The later realization would depend on the specific transport technology. The characterization of what Physical or Logical isolation implies for the transport network is not described, so it could be matter of development of this design team.

Best regards

Luis

-----Mensaje original-----
De: Teas-ns-dt <[email-masked]> En nombre de Shunsuke Homma
Enviado el: jueves, 31 de octubre de 2019 3:52
Para: [email-masked]; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Shunsuke Homma' <[email-masked]>
CC: [email-masked]; 'Jari Arkko' <jari.arkko=[email-masked]>
Asunto: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi Tomonobu,

As far as I read the characteristics, it seems that 3GPP requires strict isolation for network slicing.
(e.g., the first point describes "one network slice shall have no impact on traffic and services in other network slices") Is it correct?

Regards,

Shunsuke

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 30, 2019 5:44 PM
To: Shunsuke Homma; 'Rokui, Reza (Nokia - CA/Ottawa)'; 'Kiran Makhijani'; 'Kiran Makhijani'; 'Shunsuke Homma'
Cc: [email-masked]; 'Jari Arkko'
Subject: RE: [Teas-ns-dt] New document: IETF definition of transport slice

Hi Shunsuke,

6.1 Network slicing

Thanks,
Tomonobu

-----Original Message-----
From: Shunsuke Homma <[email-masked]>
Sent: Wednesday, October 30, 2019 2:34 PM
To: 丹羽 朝信 <[email-masked]>; 'Rokui, Reza (Nokia - CA/Ottawa)' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Kiran Makhijani' <[email-masked]>; 'Shunsuke Homma' <[email-masked]>
Cc: [email-masked]; 'Jari Arkko' <jari.arkko=[email-masked]>
Subject: RE: [Teas-ns-dt] New document: IETF definition of transport slice

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Eric Gray <[email-masked]>
Date: Thu, 31 Oct 2019 12:02:53 +0000

See attached revised and annotated version of your document.  Rather than use Word markup, I tried to show changed text in red.

There are a number of general comments, for example:

  *   The document lacks significantly in terms of required Internet Draft format and content.
  *   Use “realization” consistently, rather than sometimes using implementation and sometimes using both implementation and realization; for many (if not most) of us, implementation is quite different than how implementations are used in deployment.
  *   Avoid use of the term “midhaul” as this term is not consistently defined in the industry; examples (and associated text) that include it do not seem to be necessary.
  *   Please use SLA correctly, or not at all (I recommend not using it at all, as “Service Level Agreements” are – AFAIK – definitely out of scope for IETF specifications).

As an additional general comment, not included explicitly in the specification, I believe we want to avoid anything (such as explicitly listing “authors” in this early version) that might be construed as creating a “design team within the design team.”

Thanks!
--
Eric

Sent: Monday, October 28, 2019 2:10 AM

All,

Cheers,

Reza

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Oct 2019 13:39:44 +0000

Hi,

In our context, we are trying to allocate underlay network resources to specific a specific overlay network, and the underlay network consists only of links and routers.  Any network function (nee service function) exists only in the context of an overlay network and is reachable through a router in the underlay network.

Yours Irrespectively,

John

Juniper Business Use Only

All,

Attached please find the first version of document "IETF Definition of Transport Slice". We believe that this will be a basis for a new draft to clearly define the transport slice for IETF.
All feedback and comments are welcome.

Cheers,

Reza

---

From: Eric Gray <[email-masked]>
Date: Thu, 31 Oct 2019 13:53:08 +0000

John,

              It seems an unnecessary complication to assert that functions exist only in the overlay, for any definition of overlay.

              Certainly from an E2E perspective, exactly where a function (that is part of a service) actually exists is irrelevant to the end-points.

              How a service function is accessed in the underlay shouldn't necessarily be visible in any way in the overlay.

              And we need to be cognizant of the fact that in a hierarchy of underlays and overlays, there may very well be an overlay in one context that is at the same time an underlay in another context.

              I suspect that where network functions exist in any particular network slice realization will be largely determined not by specification, but by operator choice.

              Once we allow that an arbitrarily complex set of functions may be implemented using a "virtual box" we should avoid defining arbitrary boundaries for that box.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of John E Drake
Sent: Thursday, October 31, 2019 9:40 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Yours Irrespectively,

John

To: Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>

All,

Cheers,

Reza

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 31 Oct 2019 10:18:53 -0400

Agree with Eric. In the current TEAS documents and models, such a "virtual
box" is called a node, which can be physical or virtual, possibly with its
internal hierarchical underlays and abstractions.
Thanks,
- Xufeng

On Thu, Oct 31, 2019 at 9:53 AM Eric Gray <eric.gray=
[email-masked]> wrote:

> John,
>
>
>
>               It seems an unnecessary complication to assert that
> functions exist only in the overlay, for any definition of overlay.
>
>
>
>               Certainly from an E2E perspective, exactly where a function
> (that is part of a service) actually exists is irrelevant to the end-points.
>
>
>
>               How a service function is accessed in the underlay shouldn’t
> necessarily be visible in any way in the overlay.
>
>
>
>               And we need to be cognizant of the fact that in a hierarchy
> of underlays and overlays, there may very well be an overlay in one context
> that is at the same time an underlay in another context.
>
>
>
>               I suspect that where network functions exist in any
> particular network slice realization will be largely determined not by
> specification, but by operator choice.
>
>
>
>               Once we allow that an arbitrarily complex set of functions
> may be implemented using a “virtual box” we should avoid defining arbitrary
> boundaries for that box.
>
>
>
> --
>
> Eric
>
>
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of *John E
> Drake
> *Sent:* Thursday, October 31, 2019 9:40 AM
> *To:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko
> <jari.arkko=[email-masked]>; [email-masked]; Kiran
> Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>;
> Shunsuke Homma <[email-masked]>
> In our context, we are trying to allocate underlay network resources to
> specific a specific overlay network, and the underlay network consists only
> of links and routers.  Any network function (nee service function) exists
> only in the context of an overlay network and is reachable through a router
> in the underlay network.
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Teas-ns-dt <[email-masked]> *On Behalf Of *Rokui,
> Reza (Nokia - CA/Ottawa)
> *Sent:* Monday, October 28, 2019 2:10 AM
> *To:* Jari Arkko <jari.arkko=[email-masked]>;
> *Cc:* Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* [Teas-ns-dt] New document: IETF definition of transport slice
>
>
>
> All,
>
>
>
> Attached please find the first version of document *“IETF Definition of
> Transport Slice”. *We believe that this will be a basis for a new draft
> to clearly define the transport slice for IETF.
>

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Oct 2019 14:29:42 +0000

Eric,

In my reading of the Generic Slice Template I don't see any mention of what we are now calling network functions (nee service functions).  Furthermore, I think bounding the problem to just links and nodes simplifies it.  Additional capabilities can be layered on top of this, as the IETF has worked forever.

Yours Irrespectively,

John

Juniper Business Use Only
From: Eric Gray <eric.gray=[email-masked]>
Sent: Thursday, October 31, 2019 9:53 AM
To: John E Drake <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Subject: RE: New document: IETF definition of transport slice

John,

--
Eric

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, October 31, 2019 9:40 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Yours Irrespectively,

John

All,

Cheers,

Reza

---

From: John E Drake <[email-masked]>
Date: Thu, 31 Oct 2019 14:38:38 +0000

Hi,

My reading of the ACTN RFC is that it is pretty much limited to providing connectivity.  I don't see any mention of network functions (nee service functions).

Yours Irrespectively,

John

Juniper Business Use Only
From: Xufeng Liu <[email-masked]>
Sent: Thursday, October 31, 2019 10:19 AM
To: Eric Gray <[email-masked]>
Cc: John E Drake <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Agree with Eric. In the current TEAS documents and models, such a "virtual box" is called a node, which can be physical or virtual, possibly with its internal hierarchical underlays and abstractions.
Thanks,
- Xufeng

On Thu, Oct 31, 2019 at 9:53 AM Eric Gray <eric.gray=[email-masked]<mailto:[email-masked]>> wrote:
John,

--
Eric

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, October 31, 2019 9:40 AM
To: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Yours Irrespectively,

John

All,

Cheers,

Reza

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas-ns-dt__;!8WoA6RjC81c!WqttxCnOAwb7d7puaHKJIxLk9GbRG54BTwD37ldRZqPhmhIUHEsP_VIDBOo0vvk$>

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 31 Oct 2019 11:02:04 -0400

Hi John,
My reading is the same.
Network functions (service functions) are considered by
https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model,
<https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model> but the
model only references NFs from other SDO's, without describing their
designs and implementations.

I'd agree with your simplified approach using the link and node. It could
be better to take out the term "NF" or rephrase it in the definition in our
context.

Thanks,
- Xufeng

On Thu, Oct 31, 2019 at 10:38 AM John E Drake <[email-masked]> wrote:

> Hi,
>
>
>
> My reading of the ACTN RFC is that it is pretty much limited to providing
> connectivity.  I don’t see any mention of network functions (nee service
> functions).
>
>
>
> Yours Irrespectively,
>
>
>
> John
>
>
>
>
>
> *From:* Xufeng Liu <[email-masked]>
> *Sent:* Thursday, October 31, 2019 10:19 AM
> *To:* Eric Gray <[email-masked]>
> *Cc:* John E Drake <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <
> [email-masked]>; Jari Arkko <[email-masked]>;
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas-ns-dt__;!8WoA6RjC81c!WqttxCnOAwb7d7puaHKJIxLk9GbRG54BTwD37ldRZqPhmhIUHEsP_VIDBOo0vvk$>
>
>

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 31 Oct 2019 01:58:55 +0000

How about this:

Transport Slice is an abstract network topology connecting different networks and service functions....

If we use 3gpp example, then networks represent say RAN and/or 5G. Service functions can be NFs or SFs as ietf defines them.

As for SLA - I agree with everything said. What I liked is that SLA expresses an operator’s  perspective, going forward this may give us more flexibility. Essentially, slice will offer a service, and any part of that slice should meet the SLA.

After we converge on this, let’s tackle isolation accordingly.

Thanks
Kiran
On Oct 30, 2019, 22:16 -0300, Xufeng Liu <[email-masked]>, wrote:
While it is true that isolation is one parameter in the SLA, it is the key characteristic to separate a network slice from a generic network, so I would agree that the keyword "isolation" or its equivalent should be in the definition.

A Transport Slice is an abstract network topology connecting different network functions (NFs) with appropriate isolation and specific Service Level Agreement (SLA) described in terms of shared or dedicated network resources.

Here are some thoughts on it:
- NFs: why a slice can only connect NFs? Is it too restrictive? A network transporting data traffic may or may not use NFs.

An SLA:
* Covers a broader scope of requirements than transport characteristics, including something like measurement methodologies bond to legal terms.
* Is defined slowly and statically.
* Can be based on one of several commonly defined ones.

3GPP TS 23.501 uses the following to define the network slice:
Network Slice: A logical network that provides specific network capabilities and network characteristics.

Here the term "network characteristics" is used instead of SLA, and it may be more appropriate here also. Restricting the scope to "transport" does not have to alter other aspects of the base definition, especially considering what Eric described and the fact that our slices are managed more dynamically.

Thanks,
- Xufeng

On Wed, Oct 30, 2019 at 6:24 AM Kiran Makhijani <[email-masked]<mailto:[email-masked]>> wrote:
Ok, can I say we agree on the current definition and that Isolation as a requirement?
I think it is an important requirement and as we progress, among other terms we will need a lot more discussion on isolation so that corresponding template will have means to express them.

[https://res.gethop.com/c/?id=bosvgqdx9nr9kuf8&s=48&m=c&_ts=85ym3]              Kiran Makhijani - Chat @ Spike<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spikenow.com%2F%3Fref%3Dspike-organic-signature%26_ts%3D85ym3&data=02%7C01%7Ckiranm%40futurewei.com%7Cbb76daa0aa89405fa0f508d75d9ff02b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637080813846888829&sdata=rJ23%2Ba5pVavm64NVHXfYmFFHTje1EJsrrp8mUDv3JGU%3D&reserved=0>  [85ym3]

On October 30, 2019 at 9:33 GMT, Dongjie Jimmy <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kiran and Shunsuke,

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kiran Makhijani
Sent: Wednesday, October 30, 2019 5:06 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; jari.arkko=[email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

[图像已被发件人删除。]

Kiran Makhijani - Chat @ Spike<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spikenow.com%2F%3Fref%3Dspike-organic-signature%26_ts%3D85uz9&data=02%7C01%7Ckiranm%40futurewei.com%7Cbb76daa0aa89405fa0f508d75d9ff02b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637080813846898822&sdata=M6oU2Qjv%2FdkqNpHWBtU4c8suPHXCQoIuvQMhLKQVAtk%3D&reserved=0>
[图像已被发件人删除。 85uz9]

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]<mailto:[email-masked]>; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7Cbb76daa0aa89405fa0f508d75d9ff02b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637080813846898822&sdata=yfkNeFV8ull6FoYluYGLmhjmKgiyyRnAZEx6buqJvoY%3D&reserved=0>

--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7Cbb76daa0aa89405fa0f508d75d9ff02b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637080813846908817&sdata=24HtmjfvBckfjJw8Baw15RHTlieCXnrQ8LvWJhuBawY%3D&reserved=0>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 31 Oct 2019 15:55:00 +0000

Agreed with Shunsuke as well. Just looking at this from different perspective; the SLA requirement might contain B/W, Latency, Jitter, packet lose etc for a transport slice. In addition, it might contains other aspects such as level of physical or virtual separation, level of security etc which translates on how the transport slice will be implemented (aka realized) in the network.
In other words, the SLA requirements will dictate the Implementation of the transport slice.

BTW, is there any IETF draft or RFC describing the parameter in an SLA?

Thanks,
Reza

From: Kiran Makhijani <[email-masked]>
Date: Wednesday, October 30, 2019 at 5:06 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "jari.arkko=[email-masked]" <jari.arkko=[email-masked]>
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

[https://res.gethop.com/c/?id=bosvgqdx9nr9kuf8&s=48&m=c&_ts=85uz9]

[85uz9]

Best regards,

Shunsuke

-----Original Message-----
From: Teas-ns-dt [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, October 29, 2019 9:58 AM
To: Rokui, Reza (Nokia - CA/Ottawa); Kiran Makhijani; Kiran Makhijani; Shunsuke Homma
Cc: [email-masked]<mailto:[email-masked]>; Jari Arkko
Subject: Re: [Teas-ns-dt] New document: IETF definition of transport slice

Hi,

Best regards,
Tomonobu

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, October 28, 2019 3:10 PM
To: Jari Arkko <jari.arkko=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Subject: [Teas-ns-dt] New document: IETF definition of transport slice

All,

Cheers,

Reza