Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

From: "De Foy, Xavier" <[email-masked]>
Date: Mon, 6 Mar 2017 16:47:33 +0000

Hi Kiran, all,

  We have just submitted a draft on network slicing in 3GPP.

  https://www.ietf.org/internet-drafts/draft-defoy-netslices-3gpp-network-slicing-00.txt

  Your feedback before the meeting will be appreciated. I would also like to request a slot in the agenda of the side meeting.

  Best Regards,

Xavier

From: Netslices [mailto:[email-masked]] On Behalf Of Kiran.Makhijani
Sent: Monday, February 27, 2017 2:35 PM
To: [email-masked]
Cc: Alex Galis <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; stewart.bryant <[email-masked]>
Subject: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Hello all,

We are planning another side-meeting to continue face to face discussions on the topic and are in the process of setting up agenda and inviting contributions from the community.
Please send your contributions (such as usecases) and suggestions for discussion topics.

In order to collaborate, we have setup github repository. Feel free to use this for reviews, document update and uploading your contributions.

-- Main Repository
https://github.com/netslices/IETF-NetSlices
-- Folder for IETF98 side meeting
https://github.com/netslices/IETF-NetSlices/IETF98_Sidemeeting02

Suggestions welcome
Thanks
Stewart, Dongjie, Alex, Kiran

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 8 Mar 2017 18:19:42 +0000

Good example of use case to be fed into the draft process.

It is not however standalone draft material. I do not see a point in 
having this as a separate draft except for book-keeping purposes.

A.

On 03/06/17 16:47, De Foy, Xavier wrote:
>   Your feedback before the meeting will be appreciated. I would also 
> like to request a slot in the agenda of the side meeting.
>
>   Best Regards,
>
> Xavier
>
> *From:*Netslices [mailto:[email-masked]] *On Behalf Of 
> *Kiran.Makhijani
> *Sent:* Monday, February 27, 2017 2:35 PM
> *To:* [email-masked]
> *Cc:* Alex Galis <[email-masked]>; Dongjie (Jimmy) 
> <[email-masked]>; stewart.bryant <[email-masked]>
> *Subject:* [Netslices] NetSlices IETF 98: side meeting: Call for 
> Contributions
>
> Hello all,
>
> We are planning another side-meeting to continue face to face 
> discussions on the topic and are in the process of setting up agenda 
> and inviting contributions from the community.
>
> In order to collaborate, we have setup github repository. Feel free to 
> use this for reviews, document update and uploading your contributions.
>
> -- Main Repository
>
> _______________________________________________
> Netslices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netslices

---

From: "xuling (F)" <[email-masked]>
Date: Thu, 9 Mar 2017 03:33:21 +0000

Hi, Anton,

This draft gives us much useful information from 3GPP, such as next generation core will be based on CU separation and NFV infrastructure, some control plane function defined in 3GPP architecture will be shared by different slices, some control plane network functions need to communicate with other control plane network functions and  data plane network functions in the same slice, which all will bring much complexity to the connection between network functions in core network. If  transport network slicing is based on current technology VPN, whether current VPN  can fully meets the flexible topology requirements maybe need to be analyzed.

And also it proposes some other requirements from 3GPP point of view, such as QoS differentiation within a given slice and sharing a single slice between multiple services,  network slice management will likely partially exposed to customers, etc..    , which maybe also need to be considered.

E2E slicing involves in RAN ,TN ,CN, useful information at this early stage will not be refused, right? What do you think of that?

Happy receive your reply.

Best regards,
Ling.

________________________________
xuling
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Thursday, March 09, 2017 2:20 AM
To: [email-masked]
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

It is not however standalone draft material. I do not see a point in having this as a separate draft except for book-keeping purposes.

A.

  Best Regards,

Xavier

From: Netslices [mailto:[email-masked]] On Behalf Of Kiran.Makhijani
Sent: Monday, February 27, 2017 2:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Alex Galis <[email-masked]><mailto:[email-masked]>; Dongjie (Jimmy) <[email-masked]><mailto:[email-masked]>; stewart.bryant <[email-masked]><mailto:[email-masked]>
Subject: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Hello all,

-- Main Repository

Suggestions welcome
Thanks

Netslices mailing list

[email-masked]<mailto:[email-masked]>

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 9 Mar 2017 05:12:43 +0000

I did not say the information is not useful. It is a use case - it needs 
to end up as a part of the use cases draft.

It has no entitlement to a life of its own as it is neither an RFC 
candidate, nor an informational draft material.

A.

On 03/09/17 03:33, xuling (F) wrote:
>
> Hi, Anton,
>
> This draft gives us much useful information from 3GPP, such as next 
> generation core will be based on CU separation and NFV infrastructure, 
> some control plane function defined in 3GPP architecture will be 
> shared by different slices, some control plane network functions need 
> to communicate with other control plane network functions and data 
> plane network functions in the same slice, which all will bring much 
> complexity to the connection between network functions in core 
> network. If transport network slicing is based on current technology 
> VPN, whether current VPN can fully meets the flexible topology 
> requirements maybe need to be analyzed.
>
> And also it proposes some other requirements from 3GPP point of view, 
> such as QoS differentiation within a given slice and sharing a single 
> slice between multiple services, network slice management will likely 
> partially exposed to customers, etc.., which maybe also need to be 
> considered.
>
> E2E slicing involves in RAN ,TN ,CN, useful information at this early 
> stage will not be refused, right? What do you think of that?
>

That it belongs as a part of the use case draft and this one needs to be 
terminated as a standalone draft.

> ------------------------------------------------------------------------
>
> xuling
> 华为技术有限公司Huawei Technologies Co., Ltd.
> Company_logo
>
> Phone:
> Fax:
> Mobile:
> Email:
> ------------------------------------------------------------------------
>
> *Anton Ivanov
> *Sent:* Thursday, March 09, 2017 2:20 AM
> *To:* [email-masked]
> *Subject:* Re: [Netslices] NetSlices IETF 98: side meeting: Call for 
> Contributions
>
>       Your feedback before the meeting will be appreciated. I would
>     also like to request a slot in the agenda of the side meeting.
>
>       Best Regards,
>
>     Xavier
>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* Alex Galis <[email-masked]>
>     <mailto:[email-masked]>; Dongjie (Jimmy)
>     <[email-masked]> <mailto:[email-masked]>; stewart.bryant
>     <[email-masked]> <mailto:[email-masked]>
>     discussions on the topic and are in the process of setting up
>     agenda and inviting contributions from the community.
>
>     In order to collaborate, we have setup github repository. Feel
>     free to use this for reviews, document update and uploading your
>     contributions.
>
>     -- Main Repository
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Thu, 9 Mar 2017 06:50:51 +0000

Hello Xuling, Xavier,
Thank you for the contribution. It is very well-written. I think it is good to have 5G specific requirements at one place for the purpose of side meeting discussions.
Later on, as Anton suggests may become part of use cases draft.

Couple of high-level comments:

-          In my opinion, the document becomes extremely useful if it stitches 5G requirements to need for standardization.

-          I find the use of term sub-netslices (to represent sub-network definition from NGMN) a bit risky because it is so easy to misinterpret it.

Regards
Kiran

From: Anton Ivanov <[email-masked]>
Date: Wednesday, March 8, 2017 at 9:12 PM
To: "xuling (F)" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Kiran.Makhijani" <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

I did not say the information is not useful. It is a use case - it needs to end up as a part of the use cases draft.

It has no entitlement to a life of its own as it is neither an RFC candidate, nor an informational draft material.

A.

That it belongs as a part of the use case draft and this one needs to be terminated as a standalone draft.

Best regards,
Ling.

[ompany_logo]

Phone:
Fax:
Mobile:
Email:

A.

  Best Regards,

Xavier

Hello all,

-- Main Repository

Suggestions welcome
Thanks

Netslices mailing list

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Mar 2017 13:29:13 +0100

Hello,

there is a tl;dr at the bottom of this reply - and I also might state 
the obvious here. Sorry.

I don't think that submitting content that is not standalone draft 
material in a separate draft is generally bad.

Due to the significant scope of netslice requirements (and therefore the 
use cases they are derived from), "book-keeping" could be actually one 
of the greatest challenges (and even blocker) here. As always, this 
statement applies also to the corresponding terminology defined and 
used. This covers putting the term use-case in the title of a draft that 
contains a use-case ;)

It seems possible to aggregate all use-cases somehow categorized in a 
single draft. And that's a good approach even if the result might become 
a little bit overwhelming (structure is key to avoid this, I think).

I am more concerned about the step that comes after. The alignment of 
non-conflicting requirements in a single document could potentially pose 
an even greater challenge here.

In respect to "single use cases draft": the assumed challenge just 
illustrated could maybe be somewhat mitigated by clustering use-cases in 
groups that appear to align. In this case, categorizing (a 
specialization of "book-keeping", I think) could be supported by 
submitting, merging and expiring multiple drafts as part of the "draft 
process", in parallel.

One one hand, that might expedite the "draft process", too.

I acknowledge the possibility that, on the other hand, this approach 
might also increase confusion, temporarily introduce 
redundancy/inconsistency and might decrease visibility of valuable input.

Grüße,
Henk

p.s. maybe use "nested (net)slices" instead of "sub-netslices"? In 
general, we are not only trying to slice "networks", I think. "Managing 
isolation" seems to play a big role here.

tl;dr

This is just an individual opinion: Personally, I would like to 
encourage everyone (especially if involved with 5G) to contribute via 
new drafts including a precise scope statement and title as soon as 
possible. Orchestrating contributions in a single draft costs time. 
Maybe we don't have that time. It is 2017 already.

On 03/09/2017 07:50 AM, Kiran.Makhijani wrote:
> Hello Xuling, Xavier,
>
> Thank you for the contribution. It is very well-written. I think it is
> good to have 5G specific requirements at one place for the purpose of
> side meeting discussions.
>
> -          In my opinion, the document becomes extremely useful if it
> stitches 5G requirements to need for standardization.
>
> -          I find the use of term sub-netslices (to represent
> sub-network definition from NGMN) a bit risky because it is so easy to
> misinterpret it.
>
>
>
> Regards
>
> Kiran
>
>
>
> *From: *Anton Ivanov <[email-masked]>
> *Date: *Wednesday, March 8, 2017 at 9:12 PM
> *To: *"xuling (F)" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Kiran.Makhijani"
> <[email-masked]>
> *Subject: *Re: [Netslices] NetSlices IETF 98: side meeting: Call for
> Contributions
>
>
>
>
>     generation core will be based on CU separation and NFV
>     infrastructure, some control plane function defined in 3GPP
>     architecture will be shared by different slices, some control plane
>     network functions need to communicate with other control plane
>     network functions and  data plane network functions in the same
>     slice, which all will bring much complexity to the connection
>     between network functions in core network. If  transport network
>     slicing is based on current technology VPN, whether current VPN  can
>     fully meets the flexible topology requirements maybe need to be
>     analyzed.
>
>
>
>     And also it proposes some other requirements from 3GPP point of
>     view, such as QoS differentiation within a given slice and sharing a
>     single slice between multiple services,  network slice management
>     will likely partially exposed to customers, etc..    , which maybe
>     also need to be considered.
>
>
>
>     E2E slicing involves in RAN ,TN ,CN, useful information at this
>     early stage will not be refused, right? What do you think of that?
>
>
>     ompany_logo
>         *From:*Netslices [mailto:[email-masked]] *On Behalf
>         Of *Kiran.Makhijani
>         <[email-masked]> <mailto:[email-masked]>;
>         stewart.bryant <[email-masked]>
>         <mailto:[email-masked]>

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 9 Mar 2017 14:15:22 +0000

On 03/09/17 12:29, Henk Birkholz wrote:
> Due to the significant scope of netslice requirements (and therefore 
> the use cases they are derived from), "book-keeping" could be actually 
> one of the greatest challenges (and even blocker) here. As always, 
> this statement applies also to the corresponding terminology defined 
> and used. This covers putting the term use-case in the title of a 
> draft that contains a use-case ;)
>
> single draft. And that's a good approach even if the result might 
> become a little bit overwhelming (structure is key to avoid this, I 
> think).

+1

> non-conflicting requirements in a single document could potentially 
> pose an even greater challenge here.

+infty

> illustrated could maybe be somewhat mitigated by clustering use-cases 
> in groups that appear to align. In this case, categorizing (a 

+1

> redundancy/inconsistency and might decrease visibility of valuable input.

I'd rather have some confusion now at this stage instead of having 
confusion or requirements/ideas which cannot be reconciled later. I am 
not going to point fingers but we have a workgroup which is failing to 
agree on something as basic as trasnport protocol for a 5th year in a 
row now. This is despite the subject matter being generally less complex 
than here.

Additionally, I'd rather drop reqs which cannot be reconciled and let 
them run separately in a different WG (or different standard body 
altogether) if this is what it takes to have a viable WG which will 
produce a result BEFORE we build it (not 5+ year after everyone has 
moved on).

By the way, I am will not make it to this IETF due to a scheduling 
conflict. I should be in Prague though.

A.

> general, we are not only trying to slice "networks", I think. 
> "Managing isolation" seems to play a big role here.
>
>
> tl;dr
>

---

From: "De Foy, Xavier" <[email-masked]>
Date: Mon, 13 Mar 2017 18:47:46 +0000

Hi Anton, Xuling, Kiran and Denk

 Thank you all for your comments. Actually we focused on providing technical information to help the barBof  progress further, without planning much about the draft beyond this point. We don't mind if it gets merged into a larger use case draft in the future.

 About the point from Kiran on tying 5G requirements to standardization needs: agreed, identifying standardization needs would be useful. I will think more about it and hopefully discussions in the incoming meeting will help clarifying those needs as well.

 Finally, the term "sub-netslice" is a compact representation for the term used in the 3gpp spec "Network slice subnet". If it does not work one option is to replace it with "Network slice subnet" in a future update.

 Regards,

Xavier.

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Thursday, March 9, 2017 9:15 AM
To: [email-masked]
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

+1

+infty

+1

> redundancy/inconsistency and might decrease visibility of valuable input.

I'd rather have some confusion now at this stage instead of having confusion or requirements/ideas which cannot be reconciled later. I am not going to point fingers but we have a workgroup which is failing to agree on something as basic as trasnport protocol for a 5th year in a row now. This is despite the subject matter being generally less complex than here.

Additionally, I'd rather drop reqs which cannot be reconciled and let them run separately in a different WG (or different standard body
altogether) if this is what it takes to have a viable WG which will produce a result BEFORE we build it (not 5+ year after everyone has moved on).

By the way, I am will not make it to this IETF due to a scheduling conflict. I should be in Prague though.

A.

>> Thank you for the contribution. It is very well-written. I think it
>> is good to have 5G specific requirements at one place for the purpose
>> of side meeting discussions.
>>
>> sub-network definition from NGMN) a bit risky because it is so easy
>> to misinterpret it.
>>
>>
>>
>> Regards
>>
>> Kiran
>>
>>
>>
>> I did not say the information is not useful. It is a use case - it
>> needs to end up as a part of the use cases draft.
>>

---

From: Anton Ivanov <[email-masked]>
Date: Mon, 13 Mar 2017 19:11:58 +0000

>   Thank you all for your comments. Actually we focused on providing technical information to help the barBof  progress further, without planning much about the draft beyond this point. We don't min…

Cool :)

I always take the long view though :)

So my comment is when looking at it from that viewpoint.

A.

>   Finally, the term "sub-netslice" is a compact representation for the term used in the 3gpp spec "Network slice subnet". If it does not work one option is to replace it with "Network slice subnet"…
[snip]

---

From: Satish K <[email-masked]>
Date: Tue, 14 Mar 2017 09:43:39 +0530

Hi Kiran,

As Anton mentioned in his earlier mail, does technologies like VPN
satisfies the network slicing of Transport network or is there any other
standardization work is going on in this area? Or do you have any other
thought process on this like Virtualization of Transport devices as well
and assign each one to corresponding slice?

Regards,
Satish.

On Thu, Mar 9, 2017 at 9:03 AM, xuling (F) <[email-masked]> wrote:

> generation core will be based on CU separation and NFV infrastructure, some
> control plane function defined in 3GPP architecture will be shared by
> different slices, some control plane network functions need to communicate
> with other control plane network functions and  data plane network
> functions in the same slice, which all will bring much complexity to the
> connection between network functions in core network. If  transport
> network slicing is based on current technology VPN, whether current VPN  can
> fully meets the flexible topology requirements maybe need to be analyzed.
>
>
>
> And also it proposes some other requirements from 3GPP point of view, such
> as QoS differentiation within a given slice and sharing a single slice
> between multiple services,  network slice management will likely
> partially exposed to customers, etc..    , which maybe also need to be
> considered.
>
>
>
> ------------------------------
>
> xuling
> ------------------------------
>
> *From:* Netslices [mailto:[email-masked]] *On Behalf Of *Anton
> Ivanov
>   Your feedback before the meeting will be appreciated. I would also like
> to request a slot in the agenda of the side meeting.
>
>
>
>   Best Regards,
>
>
>
> Xavier
>
>
>
> *From:* Netslices [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Kiran.Makhijani
> *Cc:* Alex Galis <[email-masked]> <[email-masked]>; Dongjie
> (Jimmy) <[email-masked]> <[email-masked]>; stewart.bryant
> <[email-masked]> <[email-masked]>
> We are planning another side-meeting to continue face to face discussions
> on the topic and are in the process of setting up agenda and inviting
> contributions from the community.
>
> In order to collaborate, we have setup github repository. Feel free to use
> this for reviews, document update and uploading your contributions.
>
>
>
> -- Main Repository
>

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 14 Mar 2017 14:28:12 +0900

Hi,

Please excuse my intermission in this thread but I must add that here we
have another example of the two main viewpoints of network slicing:

1) From-provider-to-consumer: The transport network is sliced into
several smaller VPNs. In principle, VPN can facilitate comparable
properties to its underlying network so VPN can be considered incomplete
but valid as a method for slicing a transport network.

2) From-consumer-to-provider: The consumer does not receive a set of VPN
resources to build its own VPN. It gets the VPN "as is" and any change
must be requested to the provider. This view lacks the high flexibility
qualities that we are assigning to network slicing.

As a side remark, a VPN consumer is not able to obtain resources from
different providers and compose them as required. I think that such kind
of capability must be considered as part of resource "plasticity", which
is also a key associated to "network slicing" flag. Such qualities would
be part of a reference architecture.

In summary, the VPN technology provides an effective but incomplete
method to slice a transport network, so it must be considered a "legacy
technology" that must be replaced by a proper and improved alternative.

Regards,
Pedro

-- 
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: [email-masked]
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 14 Mar 2017 06:31:41 +0000

> qualities that we are assigning to network slicing.

Use case please. Without one, current VPN technology as it stands is
presently deemed sufficient.

A.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 14 Mar 2017 06:48:21 +0000

Hi Pedro, 

Thanks a lot for your comments. It gives a good example about the requirement of network slicing from the two viewpoints. I agree with your statement that "VPN can be considered incomplete but valid for slicing a transport network".

Your example mentions two important capabilities of network slicing: comparable properties to the underlying network, and flexibility for customers to make changes to their slice. I think both deserves further analysis and discussion on the side meeting. It would be great if you could make a presentation on the side meeting to share your insightful opinion. 

Best regards,
Jie

> From: Netslices [mailto:[email-masked]] On Behalf Of Pedro
> Martinez-Julia
> Sent: Tuesday, March 14, 2017 1:28 PM
> To: Satish K <[email-masked]>
> Cc: xuling (F) <[email-masked]>; [email-masked]; Anton
> Ivanov <[email-masked]>; [email-masked]; Kiran.Makhijani
> Please excuse my intermission in this thread but I must add that here we have
> another example of the two main viewpoints of network slicing:
> 
> 1) From-provider-to-consumer: The transport network is sliced into several
> smaller VPNs. In principle, VPN can facilitate comparable properties to its
> underlying network so VPN can be considered incomplete but valid as a method
> for slicing a transport network.
> 
> resources to build its own VPN. It gets the VPN "as is" and any change must be
> requested to the provider. This view lacks the high flexibility qualities that we are
> assigning to network slicing.
> 
> As a side remark, a VPN consumer is not able to obtain resources from different
> providers and compose them as required. I think that such kind of capability must
> be considered as part of resource "plasticity", which is also a key associated to
> "network slicing" flag. Such qualities would be part of a reference architecture.
> 
> In summary, the VPN technology provides an effective but incomplete method
> to slice a transport network, so it must be considered a "legacy technology" that
> must be replaced by a proper and improved alternative.
> 
> Regards,
> Pedro
> 
> --
> Pedro Martinez-Julia
> Network Science and Convergence Device Technology Laboratory Network
> System Research Institute National Institute of Information and Communications
> Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
> Email: [email-masked]

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Tue, 14 Mar 2017 16:25:56 +0900

> presently deemed sufficient.

For the first perspective, the only "complain" would be that VPNs do not
have all the functions that are present in the underlying transport, but
it is not very decisive.

However, for the second perspective, we can think of a quite simple use
case that cannot be supplied by current VPN:

- There are two VPN providers: A and B.
- There is a customer: C.
- C contracts VPN1 from provider A and VPN2 from provider B.
- Then:
  + C wants to merge VPN1 and VPN2 into a bigger VPN with more B/W.
  + C wants to make VPN2 a backup of VPN1, so they would have the same
    transport configuration but one would be disabled.
  + C wants to chain VPN1 and VPN2, so they would have "compatible"
    transport configuration and should be connected somewhere (where?)
    and by somebody (by whom?).
  [If VPN is as flexible as proposed by network slicing (e.g. SDN), all
  of these requirements, and much more, would be supported.]
- C finishes the contracts and goes elsewhere to meet its requirements.

Notice that if you change VPN by computer, the functions are achievable
without problem with current computing slicing technologies...

Regards,
Pedro

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 14 Mar 2017 07:36:25 +0000

>   of these requirements, and much more, would be supported.]

Can you elaborate on what do you call "transport configuration".

Otherwise:

"C wants to merge VPN1 and VPN2 into a bigger VPN with more B/W" - trivial, multiple ways to do it depending on technology, been there since late 90-es

"C wants to make VPN2 a backup of VPN1, so they would have the same transport configuration but one would be disabled" - again trivial, we are talking 1990-es material here. 

"C wants to chain VPN1 and VPN2, so they would have "compatible"
transport configuration and should be connected somewhere (where?) and
by somebody (by whom?)" - I suspect there is some form of language
barrier at work here, but you are describing a basic MPLS or VPN shared
service. That is again 1990-es material. I spent a large chunk of my
time in 2000 migrating one designed for IP VPNs in 1998-1999 to MPLS L3
VPN. That is what? 17 years ago?

I am going to repeat. Please provide a use case. Something that has not
been solved in 1990es and has not been in the CCNA and (for more
advanced cases CCIE) conspectus for the last 10 years if possible.

A.

A,

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Mar 2017 13:02:47 +0000

> qualities that we are assigning to network slicing.

Doesn't that depend on the UNI we provide the customer with?

> different providers and compose them as required.

They do not, other than to buy network from one provider and cloud compute
from another, but I think the key issue is that it is simpler to buy 
(and cheaper)
to buy from a provider with global reach than buy from multiple and
integrate them. Is there something I am missing here?

> I think that such kind

It certainly needs to be in the architecture, but I think we need to 
understand what the
customer is doing this to achieve, and how the economics work out, since 
it will
be more expensive than buying from a single provider.

> technology" that must be replaced by a proper and improved alternative.

I don't like the term legacy here since that implies that it is 
incapable of a small
migration to the new requirements, and I don't think we know that yet.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Mar 2017 13:52:42 +0000

Pedro

I am concerned that this conflates three things, Flexible VPN, SDN and 
Network
Slicing. If the preferred method of delivering  Flexible VPN is SDN then 
that
can and should be done, regardless of whether NS is needed.

Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 14 Mar 2017 13:59:39 +0000

I suggest looking at the demands of variable bit rate frequency split fronthaul over packet networks like what is being proposed for eCPRI. 

I suspect that we'll need end to end configuration of pre-emption and likely scheduled Q's if we hope to mix the fronthaul and backhaul (and avoid dual physical networks.

20Mhz in time domain is about 1Gb to the antenna (down or up) over packet, but in frequency domain and with unused subcarriers eliminated it varies 30-300M depending on the number of devices and their usage.... now mix all these together for thousands of antennas possibly separated by slice and combine some of the hops with backhaul traffic  ... gets interesting.

Peter

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Tuesday, March 14, 2017 2:32 AM
To: Pedro Martinez-Julia <[email-masked]>; Satish K <[email-masked]>
Cc: xuling (F) <[email-masked]>; [email-masked]; [email-masked]; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

On 14/03/17 05:28, Pedro Martinez-Julia wrote:
> Hi,
>
> Please excuse my intermission in this thread but I must add that here 
> we have another example of the two main viewpoints of network slicing:
>
> properties to its underlying network so VPN can be considered 
> incomplete but valid as a method for slicing a transport network.
>
> 2) From-consumer-to-provider: The consumer does not receive a set of 
> VPN resources to build its own VPN. It gets the VPN "as is" and any 
> change must be requested to the provider. This view lacks the high 
> flexibility qualities that we are assigning to network slicing.

Use case please. Without one, current VPN technology as it stands is presently deemed sufficient.

A.

> different providers and compose them as required. I think that such 
> kind of capability must be considered as part of resource 
> "plasticity", which is also a key associated to "network slicing" 
> flag. Such qualities would be part of a reference architecture.
>
> method to slice a transport network, so it must be considered a 
> "legacy technology" that must be replaced by a proper and improved alternative.
>
> Regards,
> Pedro
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Mar 2017 14:23:03 -0000

I'm a little concerned that the discussion is circular.

The intention of discussions in this thread seems to be to take technologies
that are on the table (VPN, SDN, ...) and use them to say either:

- and so we can achieve Network Slicing with no extra work, but with careful
bolting together of existing technologies

or

- and so we are missing some features to achieve network slicing.

Anton, I think, is asking for use cases as a way of determining what network
slicing seeks to deliver that cannot already be delivered using current tools.

Pedro, I think, is describing what you can achieve using current tools.

What we are (all?) seeking is a concise definition of network slicing that marks
it out as different from what can already be done so that we can identify (and
do) whatever additional work is required.

Adrian

> From: Netslices [mailto:[email-masked]] On Behalf Of Stewart
Bryant
> Sent: 14 March 2017 13:53
> To: Pedro Martinez-Julia; Anton Ivanov
> Cc: xuling (F); [email-masked]; Satish K; [email-masked];
> Kiran.Makhijani

---

From: Alex Galis <[email-masked]>
Date: Tue, 14 Mar 2017 14:30:45 +0000

Hi Stewart 
I am also concerned with the narrow view the "Flexible VPN is SDN then that can and should be done, regardless of whether NS is needed” which is IMHO not very pactical and at best secondary for NS and the emerging new IETF work and potential new WG. 
This would be a perfect subject for VPN++ in IETF. Please reconsider

Alex

> On 14 Mar 2017, at 13:52, Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> I am concerned that this conflates three things, Flexible VPN, SDN and Network
> Slicing. If the preferred method of delivering  Flexible VPN is SDN then that
> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>

---

From: Andrew McLachlan <[email-masked]>
Date: Tue, 14 Mar 2017 14:37:43 +0000

Hey Adrian

A perfect summary and akin to what a number of us have been saying for a while.

Personally I’m still not seeing any use-case denoting new technology requirements, only repetitions of definitions fir what folks believe 5G is/might be.

I still regard this as an orchestration exercise which will require higher layer tools/platforms which are really in the domain of OSS and out of scope of the IETF.

Cheers

Andrew

> On 14 Mar 2017, at 14:23, Adrian Farrel <[email-masked]> wrote:
>

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 14 Mar 2017 14:58:41 +0000

+1, Concur.

Everyone is trying to line up their favourite "ultra-deterministic 
network bugbear" for inclusion. We have been through this many times 
before - MPLS, MPLS-TE, PBB-TE, SDN, etc.

If the most extreme bugbears are included, the standard is moribund and 
dead on arrival (we have seen this with PBB-TE). While the definition of 
"extreme" keeps changing over time, as technology allows us to achieve 
more, there is still a cut-off line. Inclusion of use cases beyond the 
cut-off line makes a standard non-viable because we have to gold plate 
equipment built to the standard spec for the most extreme case.

There has to be a concise definition which describes it and marks it out 
as different from what we have so far. Similarly, we need to have a 
compromise how far do we go in terms of including extreme use cases for 
the whole thing to be viable.

A.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Mar 2017 15:35:06 +0000

> - and so we are missing some features to achieve network slicing.

I am trying to find out which of the two cases applies.

The way I am trying to do that is to write an architecture for what the 
mobile
providers tell me they want to deploy and see how well the bits fit 
together, and
if there are any missing pieces. This seems as good as any way of working
step by step through the system to look for any mismatches rather
than making assumptions.

> slicing seeks to deliver that cannot already be delivered using current tools.

So one of the more demanding applications is wide area augmented 
reality, which
I am told has a low latency ceiling.

I am worried that IoT will stress the scaling. I am also worried by the 
radio engineers
telling me that they cannot afford the energy needed to send a standard 
IP stack.
If that is the case, and it seems intuitively likely, then it is not yet 
clear how we map
that traffic, i.e. with a gateway or with a PW, or something else.

Then there is the need to do a much better job with mobility than we do 
today, particularly
if the mobile architecture embraces a more distributed design than they 
use today.
Current VPNs, be that IP or MPLS don't do an especially good job of 
mobility. There is
work on ID-LOC split, but I don't think that can be described as mature 
yet, nor
as far as I can see have they got to grips with high velocity mobility. 
If they have
great, we can take that an make sure that it is deployable on the VPN 
technology
of choice.

> Pedro, I think, is describing what you can achieve using current tools.

Of course there is a question of whether we are talking current deployed 
tools, or
tools in active development.

> do) whatever additional work is required.

Using  Ocam's definition of concise, that is certainly what I seek.

- Stewart

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Mar 2017 15:40:00 +0000

Hello 

This is very relevant discussion what you have here. This boils down to what is a network slice for the IETF. If a transport network slice is just a VPN then there is very little added value what the IETF can provide here. For 3GPP, ETSI, NGMN, TM have richer view on slicing where management and OSS/BSS play a role. 
 
VPN != slice 

Slice == application/service resources + VPN

Best regards
Hannu 

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Tuesday, March 14, 2017 9:36 AM
To: Pedro Martinez-Julia <[email-masked]>
Cc: xuling (F) <[email-masked]>; [email-masked]; Satish K <[email-masked]>; [email-masked]; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Otherwise:

A.

A,

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 14 Mar 2017 15:48:31 +0000

> This is very relevant discussion what you have here. This boils down to what is a network slice for the IETF. If a transport network slice is just a VPN then there is very little added value what t…

Not quite, see below.

> Slice == application/service resources + VPN

That has an obvious IETF role, specifically the interworking with 
datacenter, NVO3, SFC and friends.

That also clearly delineates the whole fronthaul RAN spaghetti out of scope.

I like it. In fact, my view is nearly identical. Let's keep it to this 
exact scope.

+1

A.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Mar 2017 15:52:21 -0000

Thanks Hannu,

This is the clearest and simplest statement I've seen on what a slice is.

Perhaps I am struggling because I need to see things in their simplest form :-)

> Slice == application/service resources + VPN

But, of course, this has just pushed the problem along the road a little.
What is an "application resource"?
I take it to mean that it is a network resource that has been assigned for the
sole control/use by a specific application.
If so, is there a difference between this being an actual physical resource and
a virtual resource so long as the capability of the resource is guaranteed?

And, indeed, what is a resource?

Thanks,
Adrian

---

From: <[email-masked]>
Date: Tue, 14 Mar 2017 15:58:41 +0000

Anton

"That also clearly delineates the whole fronthaul RAN spaghetti out of scope."

If the RAN is an eCPRI/nFAPI implementation, then the "slice" could be a combination of application (here C-RAN elements) and transport to the RRH (network).   As the requirements of application + network are very much determined by the exact MAC/PHY split point (in this particular example), I would say that RAN (to some extent) is in scope!

The same could also be true for IoT RAN where we want as-little processing as possible on the remote radio head with baseband processing centralised.

So, maybe we should say that air interface is out-of-scope, but any other element associated with transport is in scope?

Thoughts?

David

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: 14 March 2017 15:49
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; Pedro Martinez-Julia <[email-masked]>
Cc: xuling (F) <[email-masked]>; [email-masked]; Satish K <[email-masked]>; [email-masked]; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Not quite, see below.

> Slice == application/service resources + VPN

That has an obvious IETF role, specifically the interworking with datacenter, NVO3, SFC and friends.

I like it. In fact, my view is nearly identical. Let's keep it to this exact scope.

+1

A.

> Cc: xuling (F) <[email-masked]>; [email-masked]; 
> Satish K <[email-masked]>; [email-masked]; Kiran.Makhijani 
>>>> Please excuse my intermission in this thread but I must add that 
>>>> here we have another example of the two main viewpoints of network slicing:
>>>>
>>>> 2) From-consumer-to-provider: The consumer does not receive a set 
>>>> of VPN resources to build its own VPN. It gets the VPN "as is" and 
>>>> any change must be requested to the provider. This view lacks the 
>>>> high flexibility qualities that we are assigning to network slicing.
>> For the first perspective, the only "complain" would be that VPNs do 
>> not have all the functions that are present in the underlying 
>> transport, but it is not very decisive.
>>
>> However, for the second perspective, we can think of a quite simple 
>> use case that cannot be supplied by current VPN:
>>
> "C wants to merge VPN1 and VPN2 into a bigger VPN with more B/W" - 
> trivial, multiple ways to do it depending on technology, been there 
> since late 90-es
>
> barrier at work here, but you are describing a basic MPLS or VPN 
> shared service. That is again 1990-es material. I spent a large chunk 
> of my time in 2000 migrating one designed for IP VPNs in 1998-1999 to 
> MPLS L3 VPN. That is what? 17 years ago?
>
> I am going to repeat. Please provide a use case. Something that has 
> not been solved in 1990es and has not been in the CCNA and (for more 
>> Notice that if you change VPN by computer, the functions are 
>> achievable without problem with current computing slicing technologies...
>>
>> Regards,
>> Pedro
>>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 14 Mar 2017 16:18:11 +0000

Agreed 100%
- packet fronthaul eCPRI/ROE is the new hard bit with impacts on the cran / dran costs size / diameter etc.

From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked];
Cc: xuling (F); [email-masked]; [email-masked]; [email-masked]; Kiran.Makhijani;
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions
Time: 2017-03-14 10:59:36

Anton

Thoughts?

David

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: 14 March 2017 15:49
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; Pedro Martinez-Julia <[email-masked]>
Cc: xuling (F) <[email-masked]>; [email-masked]; Satish K <[email-masked]>; [email-masked]; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Not quite, see below.

+1

A.

---

From: <[email-masked]>
Date: Tue, 14 Mar 2017 16:40:28 +0000

" What is an "application resource"?"

Well, what is an "application?"   Take, for example, an IoT solution and the application here is something that terminates the session and carries out some higher-layer function.   "Application Resources" here would include compute, memory, storage and network requirements (often the latter just "there be a network connection").

If the "application" is a packet-forwarding engine (for example, an S-GW), then it could just be the definition of interfaces to the rest of the network.  However, in NFV terminology, a "virtualised" S-GW will have a VNFD (poorly defined acronym but seems to be bandied about by all-and-sundry) which could just describe compute, memory storage and network requirements for the virtual function.

It is all rather messy, IMvHO.

David

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 14 March 2017 15:52
To: 'Flinck, Hannu (Nokia - FI/Espoo)' <[email-masked]>; 'Anton Ivanov' <[email-masked]>; 'Pedro Martinez-Julia' <[email-masked]>
Cc: 'xuling (F)' <[email-masked]>; [email-masked]' <[email-masked]>; 'Satish K' <[email-masked]>; [email-masked]; 'Kiran.Makhijani' <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Thanks Hannu,

But, of course, this has just pushed the problem along the road a little.
What is an "application resource"?
I take it to mean that it is a network resource that has been assigned for the sole control/use by a specific application.
If so, is there a difference between this being an actual physical resource and a virtual resource so long as the capability of the resource is guaranteed?

Thanks,
Adrian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Mar 2017 16:43:00 +0000

Alex, you have only partially quoted what I said.

I said:

If the preferred method of delivering  Flexible VPN is SDN then that
can and should be done, regardless of whether NS is needed.

If customers need a flexible, SDN driven, VPN, we should design it.

If customers need NS (and they tell us they do) we should design it.

If the first turns out to be a subset of the second, then great, but if the
first is needed, that need stands in its own right and should not be
constrained by the second.

- Stewart

On 14/03/2017 14:30, Alex Galis wrote:
>
> Hi Stewart
>
> I am also concerned with the narrow view the "Flexible VPN is SDN then 
> that can and should be done, regardless of whether NS is needed” which 
> is IMHO not very pactical and at best secondary for NS and the 
> emerging new IETF work and potential new WG.
>
>> On 14 Mar 2017, at 13:52, Stewart Bryant <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 14 Mar 2017 16:44:38 +0000

> So, maybe we should say that air interface is out-of-scope, but any other element associated with transport is in scope?

Somewhere there.

We need to find a place where we can clearly draw the line so it fits a 
logical boundary of some sort.

It would have been easier if we had more use-cases. Then we can just 
draw it as of "up to this use case are in, the rest are out, consider 
them elsewhere".

A.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Mar 2017 16:52:05 +0000

> Slice == application/service resources + VPN
Close, it is application/service resources + a VPN with enhanced features.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 14 Mar 2017 16:58:15 +0000

> And, indeed, what is a resource?

Assuming we move all the latency and b/w consideration to the VPN component

It is the compute and storage resources needed for

- On path NFV functions
- Topology management, which includes routing, but these days is more
- OAM and telementry and monitoring
- Configuration management
- Interface to the slicing system.

- Stewart

---

From: Andrew McLachlan <[email-masked]>
Date: Tue, 14 Mar 2017 17:28:06 +0000

Hey Stewart

Comments inline

> On 14 Mar 2017, at 16:58, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 

These would be hop by hop characteristics, which I believe we would control / model for any services in orchestration, since they are both device dependant and also infrastructure dependent.

> - Topology management, which includes routing, but these days is more

The ‘more' bit -  much of the data we would need to implement predictable paths/slices will be historical and also non-network related, for example the public utility outages info and so on, and not in the characteristic of an IGP/BGP.  Before anyone starts saying hurrah there is a use-case, it is not one. There is zero reason to carry around in BGP/IGP this type of info since it comes from high layers and needs to be consumed by them. The network is just a tool in this chain, and not a source of truth in this instance.

> - OAM and telementry and monitoring

As we begin the move to streaming telemetry this is getting taken care of in there, and also by exiting OAMs, including those at the application level which are outside the network and again at the higher layer reporting direct to the application controllers. 

> - Configuration management

Orchestration 

> - Interface to the slicing system.

As proved by countless attempts to simply the interface to the network/devices we have actually added to the number of interface protocols, BGP-LS PCEP NETConf OVSDB and so on…. we really don’t need another ;)

---

From: Andrew McLachlan <[email-masked]>
Date: Tue, 14 Mar 2017 17:42:27 +0000

Hey Stewart

Comments inline

> On 14 Mar 2017, at 16:58, Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 

Orchestration

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 14 Mar 2017 17:56:45 +0000

> Assuming we move all the latency and b/w consideration to the VPN 

Most of that is out of scope. As Andrew noted it is either 
orchestration, model or something else.

What is clearly in-scope and not covered is the boundary and the 
inter-relationship between the VPN component of a slice and a datacenter 
overlay +/- SFC.

That also has "other civilian applications" besides the obvious use case 
for virtualized mobile core.

A.

---

From: Alex Galis <[email-masked]>
Date: Tue, 14 Mar 2017 22:30:37 +0000

Hi Stewart

It looks that you are using a narrow view of what NS is (i.e. only a partition of network resources) which was the initial view 10 years ago.

Comments on line. 

> On 14 Mar 2017, at 16:43, Stewart Bryant <[email-masked]> wrote:
> 

[Alex] Delivering Flexible VPN ( I.e. partitions of networking resources) via SDN or any other means is an old problem area. I am not sure what ‘new problems’  you are planning to solve.

> If customers need a flexible, SDN driven, VPN, we should design it.

[Alex] If Operators are in need of " flexible, SDN driven, VPN”  then such problem is perfect for other WGs in IETF .  It  does not fit very well within the scope of the work related to Net Slices.

> If customers need NS (and they tell us they do) we should design it.

[Alex] if Operators are in need of NS [ i.e. I)  partitions of networking, computation, storage resources ( i.e. of the data plane) + II) partitions of Net Functions ( of the Control and Management planes) ]  then NS will happened and it is already happening.

This is the work which fits perfectly with the Network Slicing group.

> 
> If the first turns out to be a subset of the second,

[Alex] it is obvious  that the first area of work is related to the second however it is not necessarily a subset as partitioning the networking resources can be achieve through many means.

> then great, but if the 

[Alex] The above NS described as I) +II)  need to be integrally created/operated/deactivated. This means the I) is not performed before II) and II) is not performed before I).

I hope that the above would be of use to you

Best Regards
Alex
>> I am also concerned with the narrow view the "Flexible VPN is SDN then that can and should be done, regardless of whether NS is needed” which is IMHO not very practical and at best secondary for NS and the emerging new IETF work and potential new WG.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 15 Mar 2017 10:32:04 +0900

Dear Andrew, Adrian, and others,

My intermission was only to discuss my thoughts on using VPN as a mean
for slicing transport networks. Please, do not extrapolate the lack of
new requirements in very specific use cases, which are actually asking
for VPNs.

Retaking the question on "network slicing" (without being specifically
linked to transport network or VPNs), we have a set of requirements that
are not met today. From my point of view, they are:

- Enhanced infrastructure flexibility: Both underlying and overlying
  network elements can be added, removed, scaled up/down, re/connected,
  re/configured, etc. in terms of seconds/milliseconds instead of hours
  or minutes.

- Resource plasticity: Flexibility is also taken to the atomic level, so
  the view of resources as fixed elements (e.g. a link between A and B
  with properties P_x) gives pass to a "plastic element" that can change
  its shape dynamically and promptly in response to stimuli coming from
  different sources: consumer requirements specified through a standard
  and simple interface (current interfaces are not good for such task),
  changes in the working environment (events) or the workload, etc.

- Composability: Regardless of their provider, or even specific nature,
  network resources (and services) would be able to be easily composed
  to build "composite/composed resources/services" that somehow inherit
  the capabilities/qualities of the original resources, getting enhanced
  reliability by favoring reusability, among other benefits. This would
  be like a crosswise SFC.
  
A crazy example would be like:
- I want to account, log, and share (e.g. to my colleagues or peers of
  my favorite social network) the temperature that is around me at any
  moment.
- I request, probably to different infrastructure providers, a link
  between my mobile phone and my home manager, a caching service, an
  authorization service, a router, a temperature sensor for the room
  where I am now, and a WiFi AP.
- I somehow build a composite service by lengthwise (SFC) and crosswise
  integration of those elements, and publish it.
- I then move to other location, which is detected by my mobile phone
  and triggers an update of the service by changing some parameters of
  the elements that compose it (changing the location of the WiFi AP and
  sensor, the endpoints of the link, etc.).
- I decide to open the access to more levels of my social network, so
  the authorization service gets updated but the service also receives
  much more requests and thus increases its workload. The appropriate
  parameters are tuned to overcome this: link B/W, cache location and/or
  replication, etc.

This is just part of an scenario envisioned to exploit the main benefits
of network slicing (denoted by the required flexibility), also including
virtualization, network service migration, merging computing and network
services together, etc.

I hope this adds some valuable points to justify the actual need for a
reference architecture for network slicing...

Regards,
Pedro

---

From: GENG Liang <[email-masked]>
Date: Wed, 15 Mar 2017 03:30:36 +0000

Hi Hannu，

I think you have pointed at a very reasonable direction to look at the definition of network slicing. I have similiar understanding as yours:

Network slicing = a slice of dedicatedly allocated network connectivity, computing and storage, with life cycle provisioning from the slicing provider and application-specific provisioning from slice tenant.

The role of VPNs contributes to the connectivity part of network slicing.

________________________________
Liang GENG
China Mobile Research Institute

From: Flinck, Hannu (Nokia - FI/Espoo)<mailto:[email-masked]>
Date: 2017-03-14 23:40
To: Anton Ivanov<mailto:[email-masked]>; Pedro Martinez-Julia<mailto:[email-masked]>
CC: xuling \(F\)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Satish K<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Kiran.Makhijani<mailto:[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions
Hello

Best regards
Hannu

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: Tuesday, March 14, 2017 9:36 AM
To: Pedro Martinez-Julia <[email-masked]>
Cc: xuling (F) <[email-masked]>; [email-masked]; Satish K <[email-masked]>; [email-masked]; Kiran.Makhijani <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Otherwise:

A.

A,

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 15 Mar 2017 07:16:15 +0000

>   re/configured, etc. in terms of seconds/milliseconds instead of hours

That is orchestration, does not need a protocol - not IETF subject.

>   changes in the working environment (events) or the workload, etc.

That just broke the buzzword metering component in my brain. I am sorry
it is not very plastic and it needs a good signal-to-noise ratio to work
with.

In any case - if you want to change any of the resources attached
dynamically, that is once again an orchestration problem. The most we
can do here is define some models and get the whole thing aligned
correctly with i2rs and netmod so that orchestration has the appropriate
material to  work with.

>   reliability by favoring reusability, among other benefits. This would

Orchestration.

>   parameters are tuned to overcome this: link B/W, cache location and/or

What you are describing is an interaction of a network slice with
on-premises network. We cannot realistically cover any and every crazy
idea in this area. There needs to be some narrowing down of the scope in
order for this to result in viable standards.

If suspect there may be a use case to look into a boundary interaction
between a homenet and a VPN from a slice perspective and that can join
the queue of issues to be looked at. Similarly, a boundary of 6LoPaN and
the VPN under slice control

We cannot realistically cover any OTHER use cases because they lack the
definition to work with.

Just to be clear, we cannot "appropriate" control of the leaf if it is
already subject to what  homenet, 6lopan, etc are working on. We can
only work up to and including the boundary.

Once again, a lot of this smells like model definitions and a weird case
of non-i2rs topology import (or maybe expand i2rs? dunno...).

A,

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 15 Mar 2017 08:03:42 +0000

Hi Adrian, Hannu, 

I also find that the discussion starting from the simplest statement useful, as once we agreed on the simplest definition, we can expand each word to have more detailed discussion.

My question is does the application/service resource also include the network resource which the VPN would be built upon? Or it just means the services and functions based on compute and storage? 

Best regards,
Jie

> Sent: Tuesday, March 14, 2017 11:52 PM
> To: 'Flinck, Hannu (Nokia - FI/Espoo)' <[email-masked]>; 'Anton
> Ivanov' <[email-masked]>; 'Pedro Martinez-Julia'
> <[email-masked]>
> Cc: xuling (F) <[email-masked]>; [email-masked]'
> <[email-masked]>; 'Satish K' <[email-masked]>;
> [email-masked]; Kiran.Makhijani <[email-masked]>
> If so, is there a difference between this being an actual physical resource and a
> virtual resource so long as the capability of the resource is guaranteed?
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 15 Mar 2017 08:18:32 +0000

Hi Anton, 

> Sent: Wednesday, March 15, 2017 1:57 AM
> To: [email-masked]
> >> I take it to mean that it is a network resource that has been
> >> assigned for the sole control/use by a specific application.
> >> If so, is there a difference between this being an actual physical
> >> resource and a virtual resource so long as the capability of the
> >> resource is guaranteed?
> >>
> Most of that is out of scope. As Andrew noted it is either orchestration, model or
> something else.

I assume here Stewart means the network resources which the VPN relies on to provide the required b/w and latency characteristics, then it would be related to the resources and characteristics in the underlay network. Not sure whether orchestration or models can play some role in this layer. 

> inter-relationship between the VPN component of a slice and a datacenter

What does the VPN component mean here? I guess you are talking about the interconnection/coordination between the VPN edge nodes and the service/functions in the datacenters (please correct me if I misunderstood).

> That also has "other civilian applications" besides the obvious use case for
> virtualized mobile core.

I guess you mean the third-party applications.

Best regards,
Jie

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 15 Mar 2017 08:29:34 +0000

> I assume here Stewart means the network resources which the VPN relies on to provide the required b/w and latency characteristics, then it would be related to the resources and characteristics in t…

I was going to answer on your thread to Adrian.

Two issues here:

1. Information about the network - clearly in-scope and with existing 
work we can leverage - netmod and i2rs. In addition to that we need to 
figure out how it applies to networks governed by nvo3, homenet and 
6lopan some or all (depending on our scope definition) can be our 
"resources". In fact - my view is simple - no leaf topology + resource 
modeled information == not in scope for inclusion. No exceptions.
If it can be modelled and described, including it and serving a unified 
view so orchestration can work is something useful and in IETF scope. If 
not, sorry - not. Out of scope.

2. Control - not in scope. There is orchestration for this and any ideas 
of an all encompassing protocol to manage all of this are in the realm 
of "not realistic".

> What does the VPN component mean here? I guess you are talking about the interconnection/coordination between the VPN edge nodes and the service/functions in the datacenters (please correct me if I…

You understood correctly.

Add to that interconnect/coordination to homenet and/or 6lopan too.

> I guess you mean the third-party applications.

No, I mean "other". I was joking about "civilian" :)

A.

---

From: <[email-masked]>
Date: Wed, 15 Mar 2017 08:52:27 +0000

Alex:

“if Operators are in need of NS [ i.e. I)  partitions of networking, computation, storage resources ( i.e. of the data plane) + II) partitions of Net Functions ( of the Control and Management planes) ]  then NS will happened and it is already happening.

This is the work which fits perfectly with the Network Slicing group.”

I’m not sure I fully agree with the last statement based on your item I).

My concern is that we’re heading towards IETF producing standards for compute/storage.   I understand providing (although I’ve yet to fully understand the definition of) a NETWORK slice, i.e. something with the bounds of the IETF and hence can possibly see how interfaces could be defined towards something which was requesting that “slice” (we’re back to orchestration), but I don’t see how a NETWORK slice standard would/could have anything to do with COMPUTE slice provision.

For example, I can see how a (richer and more functional than is currently being defined) ETSI MANO system could orchestrate across compute/storage and network fabric in order to provide a defined-outcome for a particular application.

David

From: Netslices [mailto:[email-masked]] On Behalf Of Alex Galis
Sent: 14 March 2017 22:31
To: Stewart Bryant <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]; xuling (F) <[email-masked]>; [email-masked]; Pedro Martinez-Julia <[email-masked]>; Kiran.Makhijani <[email-masked]>; Satish K <[email-masked]>; Anton Ivanov <[email-masked]>; Alex Galis <[email-masked]>
Subject: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

Hi Stewart

Comments on line.

On 14 Mar 2017, at 16:43, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

then great, but if the

Best Regards
Alex

- Stewart

Alex

On 14 Mar 2017, at 13:52, Stewart Bryant <[email-masked]<mailto:[email-masked]>> wrote:

Pedro

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 15 Mar 2017 10:01:30 +0000

So my philosophy is that unless there is some distinguishing factor for 
NS, we
should adopt the same approach as the IETF NFV and SFC groups adopt in 
terms
of compute and storage management.

If they manage it, we should use the same protocol.

If for them this happens outside their system, we should make the same 
assumption.

- Stewart

On 15/03/2017 08:52, [email-masked] wrote:
>
> Alex:
>
> “if Operators are in need of NS [ i.e. I)  partitions of networking, 
> computation, storage resources ( i.e. of the data plane) + II) 
> partitions of Net Functions ( of the Control and Management planes) ] 
>  then NS will happened and it is already happening.
>
> My concern is that we’re heading towards IETF producing standards for 
> compute/storage.   I understand providing (although I’ve yet to fully 
> understand the definition of) a NETWORK slice, i.e. something with the 
> bounds of the IETF and hence can possibly see how interfaces could be 
> defined towards something which was requesting that “slice” (we’re 
> back to orchestration), but I don’t see how a NETWORK slice standard 
> would/could have anything to do with COMPUTE slice provision.
>
> For example, I can see how a (richer and more functional than is 
> currently being defined) ETSI MANO system could orchestrate across 
> compute/storage and network fabric in order to provide a 
> defined-outcome for a particular application.
>
> David
>
> *Alex Galis
> *Sent:* 14 March 2017 22:31
> *To:* Stewart Bryant <[email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; [email-masked]; 
> xuling (F) <[email-masked]>; [email-masked]; Pedro 
> Martinez-Julia <[email-masked]>; Kiran.Makhijani 
> <[email-masked]>; Satish K <[email-masked]>; Anton 
> Ivanov <[email-masked]>; Alex Galis <[email-masked]>
> It looks that you are using a narrow view of what NS is (i.e. only a 
> partition of network resources) which was the initial view 10 years ago.
>
> Comments on line.
>
>     On 14 Mar 2017, at 16:43, Stewart Bryant <[email-masked]
> [Alex] Delivering Flexible VPN ( I.e. partitions of networking 
> resources) via SDN or any other means is an old problem area. I am not 
> sure what ‘new problems’  you are planning to solve.
>
>
>
>
> [Alex] If Operators are in need of " flexible, SDN driven, VPN”  then 
> such problem is perfect for other WGs in IETF .  It  does not fit very 
> well within the scope of the work related to Net Slices.
>
>
>
>
> [Alex] if Operators are in need of NS [ i.e. I)  partitions of 
> networking, computation, storage resources ( i.e. of the data plane) + 
> II) partitions of Net Functions ( of the Control and Management 
> planes) ]  then NS will happened and it is already happening.
>
> [Alex] it is obvious  that the first area of work is related to the 
> second however it is not necessarily a subset as partitioning the 
> networking resources can be achieve through many means.
>
>
>
>     then great, but if the
> [Alex] The above NS described as I) +II)  need to be integrally 
> created/operated/deactivated. This means the I) is not performed 
> before II) and II) is not performed before I).
>
>         I am also concerned with the narrow view the "Flexible VPN is
>         SDN then that can and should be done, regardless of whether NS
>         is needed” which is IMHO not very practical and at best
>         secondary for NS and the emerging new IETF work and potential
>         new WG.
>

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 16 Mar 2017 04:56:06 +0000

Hi Anton,

I am afraid it is inappropriate to regard all of things like flexibility support as an orchestration exercise which could be done in a higher layer platform. 

Considering a situation that different domains (i.e., RAN, Transport network, CN) belong to different providers, a common higher layer platform (maybe we can call it vertical approach) is no longer valid. On the contrary, the horizontal approach that let domain managers negotiate and cooperate with each other will be better. Our IETF should consider/design the East-West interfaces among domain managers for horizontal approach. For vertical approach, we still need to design the North-South interfaces for the description of tenants' requirements and feedback from network.

Best regards,
Cristina. Qiang

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Anton Ivanov
发送时间: 2017年3月15日 15:16
收件人: Pedro Martinez-Julia; Andrew McLachlan
抄送: [email-masked]; xuling (F); [email-masked]; Kiran.Makhijani; Stewart Bryant; Adrian Farrel; Satish K
主题: Re: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions

On 15/03/17 01:32, Pedro Martinez-Julia wrote:
> linked to transport network or VPNs), we have a set of requirements 
> that are not met today. From my point of view, they are:
>

>   changes in the working environment (events) or the workload, etc.

That just broke the buzzword metering component in my brain. I am sorry it is not very plastic and it needs a good signal-to-noise ratio to work with.

In any case - if you want to change any of the resources attached dynamically, that is once again an orchestration problem. The most we can do here is define some models and get the whole thing aligned correctly with i2rs and netmod so that orchestration has the appropriate material to  work with.

Orchestration.

>   parameters are tuned to overcome this: link B/W, cache location and/or

What you are describing is an interaction of a network slice with on-premises network. We cannot realistically cover any and every crazy idea in this area. There needs to be some narrowing down of the scope in order for this to result in viable standards.

If suspect there may be a use case to look into a boundary interaction between a homenet and a VPN from a slice perspective and that can join the queue of issues to be looked at. Similarly, a boundary of 6LoPaN and the VPN under slice control

We cannot realistically cover any OTHER use cases because they lack the definition to work with.

Just to be clear, we cannot "appropriate" control of the leaf if it is already subject to what  homenet, 6lopan, etc are working on. We can only work up to and including the boundary.

Once again, a lot of this smells like model definitions and a weird case of non-i2rs topology import (or maybe expand i2rs? dunno...).

A,

>
> This is just part of an scenario envisioned to exploit the main 
> benefits of network slicing (denoted by the required flexibility), 
> also including virtualization, network service migration, merging 
> computing and network services together, etc.
>

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 06:45:04 +0000

On 16/03/17 04:56, qiangli (D) wrote:
> Considering a situation that different domains (i.e., RAN, Transport network, CN) belong to different providers, a common higher layer platform (maybe we can call it vertical approach) is no longer valid. 

The idea of a common horizontal platform is even less valid.

If two providers cannot agree to provide flexibility at the layer that
does the billing they are not going to provide it any other layer any
time soon.

A.

> On the contrary, the horizontal approach that let domain managers negotiate and cooperate with each other will be better. Our IETF should consider/design the East-West interfaces among domain managers for horizontal approach. For vertical approach, we still need to design the North-South interfaces for the description of tenants' requirements and feedback from network.
>
>
> Best regards,
> Cristina. Qiang
>
> -----邮件原件-----

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 16 Mar 2017 15:49:49 +0900

On Thu, Mar 16, 2017 at 06:41:36AM +0000, Anton Ivanov wrote:
> > I am afraid it is inappropriate to regard all of things like
> > flexibility support as an orchestration exercise which could be done
> > in a higher layer platform. 
> >
> > Considering a situation that different domains (i.e., RAN, Transport
> > network, CN) belong to different providers, a common higher layer
> > platform (maybe we can call it vertical approach) is no longer
> > valid. 
> 

But, in other areas (e.g. computing), providers are actually providing
the required flexibility and billing for it. There won't be a "common
horizontal platform" but "platforms that are compliant with a reference
architecture so they can interoperate easily".

Regards,
Pedro

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 06:58:25 +0000

> architecture so they can interoperate easily".

First of all, a SP network just does not work this way.  If it cannot be
orchestrated and billed it does not exist.

Second, flexibility, variable bandwidth, etc - are all billable items.
The idea that you can create the means to establish billable items
across a provider network without billing, capacity planning and
orchestration involved is in the realm of entertaining. Very
entertaining indeed. However, entertainment is not a subject for a WGs
and RFCs  (except the 1st of april ones).

A.

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 16 Mar 2017 15:58:33 +0900

Regards,
Pedro

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Thu, 16 Mar 2017 16:08:48 +0900

On Thu, Mar 16, 2017 at 06:58:25AM +0000, Anton Ivanov wrote:
> >>> flexibility support as an orchestration exercise which could be
> >>> done in a higher layer platform. 
> >>>
> >>> Considering a situation that different domains (i.e., RAN,
> >>> Transport network, CN) belong to different providers, a common
> >>> higher layer platform (maybe we can call it vertical approach) is
> >>> no longer valid. 
> >> If two providers cannot agree to provide flexibility at the layer
> >> that does the billing they are not going to provide it any other
> >> layer any time soon.
> > But, in other areas (e.g. computing), providers are actually
> > providing the required flexibility and billing for it. There won't
> > be a "common horizontal platform" but "platforms that are compliant
> > with a reference architecture so they can interoperate easily".
> 
> First of all, a SP network just does not work this way.  If it cannot
> be orchestrated and billed it does not exist.

Who is saying the opposite?

> and RFCs  (except the 1st of april ones).

Again, who said the opposite?

Any feature we can think about would be billable (although sometimes not
billed) or it just does not require any effort. We cannot consider other
situation. But it is totally different from the need for flexibility in
network services, and an slicing architecture would provide the needed
coherence to achieve such flexibility while enforcing some compatibility
among providers. What is wrong with it?

Regards,
Pedro

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 07:45:10 +0000

> among providers. What is wrong with it?

Cool - please provide a use case which is not covered by the current 
existing stuff.

The last set you provided was doable using 1990-es and sub-2000 RFC 
technology and redone 3 times since 1994 - twice using MPLS (PWE and 
L3VPN) and once using L2VPN - to a total of 4 times so far.

So something that actually needs to be done, is not done at present and 
is "flexible" as a use case, please. You are failing to provide a single 
example of "flexible" that has not been done and needs doing. Please do 
so so we can actually enqueue it for the use case draft.

I personally do not see anything like this on the network side. It has 
been done, dusted and does not need redoing for use cases which are 
sufficiently "common" to become a standard. The only open issues needed 
to work on are interworking to "resources" where resources are 
datacenter and leaves governed by other WGs or standard bodies - 
homenet, 6lopan, nvo3 or (outside IETF) 3GPP.

A.

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 16 Mar 2017 08:35:11 +0000

Hi Anton,

Datacenter is indeed a resource that needs flexible allocation and management. Except for datacenter, all of the network resources from RAN to CN (include radio unit, router, port, CPU, S-GW etc.) should be appropriately allocated. 

Even for a provider, it is impossible to manage all of these resources just through a single controller/platform, since different domains have quite different technical attributes. RAN, TN, CN must have their own domain controllers. In order to achieve the flexible E2E network slicing, we have to consider the interoperation among domain controllers. That is, we need to design the std. east-west interfaces.

Best regards,
Cristina.qiang

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Anton Ivanov
发送时间: 2017年3月16日 15:45
收件人: [email-masked]
主题: Re: [Netslices] Flexibility Requirement

>> entertaining indeed. However, entertainment is not a subject for a 
>> WGs and RFCs  (except the 1st of april ones).
> billed) or it just does not require any effort. We cannot consider 
> other situation. But it is totally different from the need for 
> flexibility in network services, and an slicing architecture would 
> provide the needed coherence to achieve such flexibility while 
> enforcing some compatibility among providers. What is wrong with it?

Cool - please provide a use case which is not covered by the current existing stuff.

The last set you provided was doable using 1990-es and sub-2000 RFC technology and redone 3 times since 1994 - twice using MPLS (PWE and
L3VPN) and once using L2VPN - to a total of 4 times so far.

So something that actually needs to be done, is not done at present and is "flexible" as a use case, please. You are failing to provide a single example of "flexible" that has not been done and needs doing. Please do so so we can actually enqueue it for the use case draft.

I personally do not see anything like this on the network side. It has been done, dusted and does not need redoing for use cases which are sufficiently "common" to become a standard. The only open issues needed to work on are interworking to "resources" where resources are datacenter and leaves governed by other WGs or standard bodies - homenet, 6lopan, nvo3 or (outside IETF) 3GPP.

A.

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 08:44:57 +0000

On 16/03/17 08:35, qiangli (D) wrote:
> Even for a provider, it is impossible to manage all of these resources just through a single controller/platform, since different domains have quite different technical attributes. RAN, TN, CN must have their own domain controllers. In order to achieve the flexible E2E network slicing, we have to consider the interoperation among domain controllers.

At orchestration level - you are doing controller interop.

A.
>  That is, we need to design the std. east-west interfaces.
>
>
> Best regards,
> Cristina.qiang
>
>
> -----邮件原件-----

---

From: "qiangli (D)" <[email-masked]>
Date: Thu, 16 Mar 2017 09:53:06 +0000

Please see my reply inline below.

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Anton Ivanov
发送时间: 2017年3月16日 16:45
收件人: qiangli (D); [email-masked]
主题: Re: [Netslices] 答复: Flexibility Requirement

[Cristina] As long as the controller interoperation needs new standards, people couldn't say it is out of our scope. 
        In addition to east-west interfaces, NS will also involve new standards in north-south interfaces. We should consider:
        1) how to describe tenants' requirements to controllers
        2) how to present a logical view of NSI to a tenant
        3) tenant should be able to configure their own NSI, then how to deliver the configuration commands to controllers
        4) how to deliver the configuration commands from controllers to underlying network, etc.

A.
>>> First of all, a SP network just does not work this way.  If it 
>>> cannot be orchestrated and billed it does not exist.

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 10:12:11 +0000

> [Cristina] As long as the controller interoperation needs new standards, people couldn't say it is out of our scope.

It does not at the lower levels. Controller to controller interfaces are 
effectively business level interfaces. IBM and friends have chewed up 
this topic for 4 decades now and trying to reinvent AMQP, ZMQ, SOAP 
(just a few examples) badly (because it is not our primary domain of 
expertise) is definitely outside IETF scope.

What may be in scope is not the interface, but what the data means on 
the interface.

>          4) how to deliver the configuration commands from controllers to underlying network, etc.

There MAY BE a role for the IETF in all of that  (I am repeating this 
for the n-th time here) - it is how to model data, how to represent 
topology for slice use and how to apply it to existing interoperability 
interfaces in controller-to-controller land. That is also the only place 
where transport and Layer 1 should be allowed to show up.

We are working on the subject by the way (and putting our money where 
our mouth is) - the draft on one possible interop protocol family was 
published a few weeks ago: 
https://trac.tools.ietf.org/html/draft-yang-json-rpc-00 , the actual 
implementation is in ODL.

AFAIK, the XML based protocols were being covered by netmod looking at 
WSDL interworking - you have to ask them where is that at present. ODL 
afaik generates WSDL, but is it usable for SOAP (and other non-netconf 
needs) I have no clue - you need to ask someone who works on that. I can 
find only references in some old slides, no idea where it is.

That does need aligning and tying together - the two controllers operate 
using the same model and same (or compatible) understanding of modelled 
data. The rest is already covered elsewhere and has been covered for 
many decades (no need to reinvent the wheel).

At that point you may or may not invent a new protocol if you wish (f.e. 
if you somehow thing you can exchange data between controllers faster 
than websockets or ZMQ). That is fine as it builds on top of something 
that is part of our subject matter. Inventing the protocol FIRST however 
is frankly a no go. At that level nobody cares about a new protocol if 
there is no data/model interop to start off with.

A.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Mar 2017 10:23:56 -0000

Picking at one point (and so losing context :-)

> topology for slice use

Once you are in the business of representing topology, isn't topology just topology?
That is, isn't a graph just a graph no matter to what application you intend to apply it?

I would like to understand how "slice use" of topology differs from "VPN use" or "TE use" or "capacity planning use" etc.
I think understanding that will help me understand what additional work is needed to make NetSlices a practical project.

Thanks,
Adrian

---

From: Giles Heron <[email-masked]>
Date: Thu, 16 Mar 2017 10:26:54 +0000

> That is, isn't a graph just a graph no matter to what application you intend to apply it?

yes.

> I think understanding that will help me understand what additional work is needed to make NetSlices a practical project.

right.   The I2RS topology YANG model (to use one example) is simply a list of nodes and a list of links.   You can augment that with whatever’s required for your specific protocol/application.   It *might* be that NetSlices needs to augment it.  But yes, that’s far from clear at this point - and we need to start with some real use-cases (i.e. not pipe-dreams) in order to figure that sort of thing out...

Giles

---

From: <[email-masked]>
Date: Thu, 16 Mar 2017 10:28:38 +0000

"how to describe tenants' requirements to controllers"

Isn't what you are describing essentially "Layer 8" requirements ?   In other words, my desire as a customer for outcome from the organisation(s) I buy service(s) from?  I agree that in the market there is a need for me to be able to describe the outcome I want and have that built across the many different components which need to be constructed to do that, but I suspect that if we organised the industry better (differently?) we would be able to do that given the protocols we have.

The issue is that it is not in the interests of an SP to work with, say, an OTT provider (and vice-versa) because they are both chasing the same, decreasing, revenue stream.   Unfortunately, some of the architectures we have (not the protocols - I think we have those) institutionalise these silos - 3GPP SAE is a case-in-point.

I'm actually starting to think that "Network Slicing" is a misnomer.   I think what we are actually trying to do is provide an even greater level of separation between application and network than we currently have (an expansion of the NetFlix et al model) but this time trying to ensure that there is some tie-in to the transport layer(s).

There is definitely a revenue sharing/settlement piece missing here but that, surely, is out-of-scope of an IETF WG?

David

-----邮件原件-----
发件人: Netslices [mailto:[email-masked]] 代表 Anton Ivanov
发送时间: 2017年3月16日 16:45
收件人: qiangli (D); [email-masked]
主题: Re: [Netslices] 答复: Flexibility Requirement

A.

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 10:29:42 +0000

> Once you are in the business of representing topology, isn't topology just topology?

Indeed.

> That is, isn't a graph just a graph no matter to what application you intend to apply it?

Indeed ^2.

> I would like to understand how "slice use" of topology differs from "VPN use" or "TE use" or "capacity planning use" etc.

I do not think it does, but it is difficult to see because of all the 
fog emanating from various pipe dreams.

+1

A.

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 10:32:21 +0000

> There is definitely a revenue sharing/settlement piece missing here but that, surely, is out-of-scope of an IETF WG?

Bingo.

Let's keep it to what may be in-scope: topology, interworking to 
networks covered to other WGs, data modelling, etc.

Layer 8 and 9 requirements are best left to marketing and legislation. 
They do not belong in an engineering forum.

A.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Mar 2017 11:52:42 +0000

On 16/03/2017 10:26, Giles Heron wrote:
> The I2RS topology YANG model (to use one example) is simply a list of nodes and a list of links.   You can augment that with whatever’s required for your specific protocol/application.   It*might*  be that NetSlices needs to augment it.

Giles,

I suppose it depends on what you mean by nodes and links, because you
these days you need classic network nodes and links, but you also need
service functions and compute power to run them.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 16 Mar 2017 11:55:40 +0000

> There is definitely a revenue sharing/settlement piece missing here but that, surely, is out-of-scope of an IETF WG?

Hi David

It may be outside IETF scope, but I think a better understanding of it 
might help us resolve the questions we are debating on this list.

- Stewart

---

From: Giles Heron <[email-masked]>
Date: Thu, 16 Mar 2017 11:59:05 +0000

On 16 Mar 2017, at 11:52, Stewart Bryant <[email-masked]> wrote:
>> The I2RS topology YANG model (to use one example) is simply a list of nodes and a list of links.   You can augment that with whatever’s required for your specific protocol/application.   It *might* be that NetSlices needs to augment it.
> 
> Giles,
> 

well - it’s up to the user of the model to define what nodes and links mean to them.  There’s no assumption that a “node” is a router or that a “link” is a piece of fibre.

Giles

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Mar 2017 08:21:36 -0400

Exactly. This is directly analogous to how Traffic Engineering has been deployed
over the years, and the most pragmatic solution has been just that: provider-to-provider 
agreements for things like PCEP use. Mobile scenarios are unlikely going to be a special 
case here. I could be wrong, and would welcome the input of some mobile operators if this is
not the case.

	—Tom

> On Mar 16, 2017:2:45 AM, at 2:45 AM, Anton Ivanov <[email-masked]> wrote:
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Mar 2017 08:25:58 -0400

> On Mar 16, 2017:5:53 AM, at 5:53 AM, qiangli (D) <[email-masked]> wrote:
> 

	I am not sure this is needed either. Look around at how SDN controllers interoperate today -
both for like-to-like and different controllers - and you will find that “standard methods” already exist 
for this such as message bus or north-bound ReSTful API interaction approaches.

	—Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 16 Mar 2017 08:27:15 -0400

> On Mar 16, 2017:6:23 AM, at 6:23 AM, Adrian Farrel <[email-masked]> wrote:
> 

	I think so.

> I think understanding that will help me understand what additional work is needed to make NetSlices a practical project.

	I honestly cannot see the difference either, or why anything special is needed here.

	—Tom

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Thu, 16 Mar 2017 16:49:33 +0000

David, 
I believe it is important to go back to why 5G mentions network slicing and not just refers to some form of known virtual networks, VPN technologies. Because newer kind of use cases are largely still at early stage. For example, Smart city or V2X are not as trivial as “achieving desired outcome from customer’s perspective”. These are “in-network” tightly stitched close to wire services and require entire realm of infrastructure to cooperate/coordinate/inter-operate just to be able to function and operate normally. Perhaps they may require different set of forwarding and control functions that could vary from slice to slice. It is not easy (if possible) to support this today. That’s what we should be talking about.

I look at slicing in 2 aspects – one is infrastructure impacting new services that 5G is readying for and second, ease of and flexibility of making existing OTT simpler and efficient. I guess you are mostly focusing on the second, which is not immediately attractive for SPs.

Regards
Kiran 

On 3/16/17, 3:28 AM, "Netslices on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    David

    
    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Anton Ivanov
    发送时间: 2017年3月16日 16:45
    收件人: qiangli (D); [email-masked]
    主题: Re: [Netslices] 答复: Flexibility Requirement

    

    A.

---

From: Anton Ivanov <[email-masked]>
Date: Thu, 16 Mar 2017 17:04:00 +0000

Kiran,

1. 5G is not the only game in town.

2. There is more to the idea of combining a resource and a virtual 
network than the extremely narrow and self-serving view of a mobile 
standards organization.

A classic example of a slice which pre-dates 3GPP by more than 5 years 
is a vCPE service - it is a combination of a customer network, a VPN/PWE 
and a cloud resource to run the vCPE and vServices. That, by all means 
is a a SLICE.

We just never bothered to describe it and standardize it properly so 
far. I can see the benefit in doing so, but definitely no benefit in 
duplicating any of the 3GPP work.

A.

---

From: <[email-masked]>
Date: Thu, 16 Mar 2017 17:28:19 +0000

Kiran

Not sure I totally agree, I'm afraid!

There IS a service where there is an application tightly tied to the network substrate which delivers against a guaranteed service and runs at an application level across multiple types of access technology - VoLTE.

The problem we have is that that service is silo-ed to a single operator domain - the EPC and IMS cores, the PCRF, the MMTel services.  It does work on an single SP's 4G and circuit-switched network.   An MMTel TAS is a SIP service - very much above the network layer because it includes many of the same aspects of authentication and application that you would find in the IoT services you mention.   VoLTE is tightly stitched in the way that you cite - the PCRF demands a specific transport scheme (modulation method) on the air interface. 

VoLTE suffers the exact problem you are talking about - as soon as I connect over a transport mechanism other than one entirely in the operator domain, all bets are off.  As a musician, nothing annoys me more than the constant dropped packets and digital artefacts I hear on services such as Skype which I just don't get on VoIP channels which run over dedicated LTE bearers!  I know that VoIP can be as-good as circuit-switched PCM but the quality of calls I am subjected to on a daily basis is quite awful.  This is purely down to the inability to signal my application desire (specific drop, latency, bandwidth requirements) over any interconnect.   The application (SIP server) KNOWS the requirement because it controls the session - it has no interface to the network and the networks have no interfaces between them to enable the application to request desired outcome.

If I consider "what things would I need to do to make VoLTE to the MNO TAS as reliable as when on LTE across any and all transport networks," many of the same issues you mention (service placement closer to the UE, the ability to signal desired outcome between transport providers, etc) come out.

I think we are in danger of thinking "new" and "different" and believing the Marchitecture too much rather than considering where the boundary problems exists which we can address today.  Yes, the applications are new, but the problems are very old...

David

-----Original Message-----
From: Kiran.Makhijani [mailto:[email-masked]]
Sent: 16 March 2017 16:50
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; qiangli (D) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Netslices] 答复: 答复: Flexibility Requirement

David, 

Regards
Kiran 

    

    
    
    David

    
    -----邮件原件-----
    发件人: Netslices [mailto:[email-masked]] 代表 Anton Ivanov
    发送时间: 2017年3月16日 16:45
    收件人: qiangli (D); [email-masked]
    主题: Re: [Netslices] 答复: Flexibility Requirement

    

    A.