Subject: [Netslices] Draft on Network Slicing Architecture

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

Hi all,

We have submitted a draft on the architechture of Network Slicing. You can find the draft from the following link.

https://datatracker.ietf.org/doc/draft-geng-netslices-architecture/

This draft briefly describes a systemetic top-level view of Network Slicing and defines some basic roles in the architechture. We also identifies some key technical issues that Network slicing should possibly address as the work progress.

We are planning to present this document in Chicago. Comments are extremely welcome.

Best wishes
Liang

________________________________
Liang GENG
China Mobile Research Institute

---

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

3.1.2.

1. Implies Orchestration
2. Mobile specific
3. Does not cover home network resources
4. Does not cover datacenter resources properly. "may require cloud 
resources" is not an acceptable definition going towards standard - it 
is marketing. The data center in IETF is mostly NVO3 and to a lesser 
extent L2VPN. What is the interworking level and function.
5. Has the dirty T word. We are not doing Transport and Layer 1 except 
as an information/topology model.

3.1.3 - Same as above. 3GPP-fest belongs in 3GPP. I do not see a point 
of repeating 3GPP work in IETF. We already had one multi-year soap opera 
with MPLS-TP and ITU work duplication, no thanks, we do not need 
another. If we are to work on something it should not be a duplicate.

3.1.5. That is literally a description of orchestration via an API 
gateway. Why is this anywhere near IETF?

3.1.6. Orchestration. Again. There is no IETF architecture here. There 
is no network architecture, there is no interconnect architecture, there 
is no interface architecture, there is no protocols, nothing.

4.1. Physical Layer. Again - same as 3.1.5. What is it doing here?
4.2. Same

This in first read does not belong.

A) It includes Layer 1.
B) It includes orchestration and has little or no networking to speak of
C) It does not specify any problem scope which the IETF works on and is 
good at and it also provides standard body work duplication environment.

Creating a duplicated standards environment is a fantastic way to 
maintain 5 years of subtly non-compliant implementations, because "the 
standard is not finalized". While I recall quite well how and who used 
this during the MPLS-TP IETF/ITU debacle, I do not see why we should be 
supporting an attempt to repeat this. In fact we should be explicitly 
against abusing IETF as a standards body for this particular purpose.

A.

On 15/03/17 03:55, GENG Liang wrote:
> Hi all,
>
> We have submitted a draft on the architechture of Network Slicing. You 
> can find the draft from the following link.
>
> This draft briefly describes a systemetic top-level view of Network 
> Slicing and defines some basic roles in the architechture. We also 
> identifies some key technical issues that Network slicing should 
> possibly address as the work progress.
>
> ------------------------------------------------------------------------
> Liang GENG
> _______________________________________________
> Netslices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netslices

---

From: GENG Liang <[email-masked]>
Date: Thu, 16 Mar 2017 11:16:24 +0000

Hi Anton,

Thank you for reading the draft.

The purpose of the architecture draft is to provide a very initial conceptual view of network slicing for the community to have rather focused discussions. I am happy to see this happening.

However, I don't think using terminologies from another standard organization does any harm at this stage to IETF work, particually if that may actually help people to understand the basic concepts. It is also not very helpful to refer to the MPLS-TP drama or using the term "abusing IETF" at this stage based on non-technical assumptions of possibilities of duplicated works. It is subjected to the community to judge what belongs to where, and the discussions at the moment are yet to approach that stage.

Technically, it would also be good to define what you mean by the term "orchestration" since people may have different understandings. Hence the statement of "any orchestration is outside the scope of IETF" is also subjected to futher clarification according to a mutual understanding of "orchestration". Network slicing itself of course includes the construction and arrangement of different network elements/resources. However, this level of "orchestration" is not enough for a dynamically configurable set of network resource, or a network slice instance, for a set of requirements for service guarantees.

For instance, a customer may want a slice with requirements of certain BW, latency, security, power consumption or provisioning abilities and guarantees. Given that a network slice instance is properly established by some sort of "Brilliant Orchestration", it is still subjected to the network equipments to mapping these network-slice-instance-specific requirements to chip-level or system-level capabilities. Remember there are inevitably co-existence issues with traffics flowing on non-sliced resources with no guarantees what so ever. Moreover, the intention of providing network slicing is also to improve the capability of network customization. It is true that existing technology like VPN can provide dedicated connections, but what is missing is the ability for the network to dynamically mapping those technologies to customized (and frequently changed) requirements, and then, back to the guarantee issue, mapping to equipement capabilities.

Best wishes
Liang

From: Anton Ivanov<mailto:[email-masked]>
Date: 2017-03-16 16:34
To: netslices<mailto:[email-masked]>
Subject: Re: [Netslices] Draft on Network Slicing Architecture
3.1.2.

1. Implies Orchestration
2. Mobile specific
3. Does not cover home network resources
4. Does not cover datacenter resources properly. "may require cloud resources" is not an acceptable definition going towards standard - it is marketing. The data center in IETF is mostly NVO3 and to a lesser extent L2VPN. What is the interworking level and function.
5. Has the dirty T word. We are not doing Transport and Layer 1 except as an information/topology model.

3.1.3 - Same as above. 3GPP-fest belongs in 3GPP. I do not see a point of repeating 3GPP work in IETF. We already had one multi-year soap opera with MPLS-TP and ITU work duplication, no thanks, we do not need another. If we are to work on something it should not be a duplicate.

3.1.5. That is literally a description of orchestration via an API gateway. Why is this anywhere near IETF?

3.1.6. Orchestration. Again. There is no IETF architecture here. There is no network architecture, there is no interconnect architecture, there is no interface architecture, there is no protocols, nothing.

A) It includes Layer 1.
B) It includes orchestration and has little or no networking to speak of
C) It does not specify any problem scope which the IETF works on and is good at and it also provides standard body work duplication environment.

Creating a duplicated standards environment is a fantastic way to maintain 5 years of subtly non-compliant implementations, because "the standard is not finalized". While I recall quite well how and who used this during the MPLS-TP IETF/ITU debacle, I do not see why we should be supporting an attempt to repeat this. In fact we should be explicitly against abusing IETF as a standards body for this particular purpose.

A.

Best wishes
Liang

_______________________________________________
Netslices mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netslices

---

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

On 16/03/17 11:16, GENG Liang wrote:
> The purpose of the architecture draft is to provide a very initial 
> conceptual view of network slicing for the community to have rather 
> focused discussions. I am happy to see this happening.
>

As in the draft at present, it is presently mostly at layer 8, the few 
things below that layer fall outside IETF scope.

> However, I don't think using terminologies from another standard 
> organization does any harm at this stage to IETF work, particually if 
> that may actually help people to understand the basic concepts. It is 
> also not very helpful to refer to the MPLS-TP drama or using the term 
> "abusing IETF" at this stage based on non-technical assumptions of 
> possibilities of duplicated works. It is subjected to the community to 
> judge what belongs to where, and the discussions at the moment are yet 
> to approach that stage.
>

It is a technical assumption. I read your document strictly through 
technical "goggles" and I see 70%+ 3GPP duplication with the remainder 
at layer 8 or above.

When I see something that is neither I will change my mind. Before that 
- sorry, I do not see this as anything different but a prelude to 
another MPLS-TP style saga. That is where this is going and no thanks, 
we have seen that movie from the front row.

> Technically, it would also be good to define what you mean by the term 
> "orchestration" since people may have different understandings. Hence 
> the statement of "any orchestration is outside the scope of IETF" is 
> also subjected to futher clarification according to a mutual 
> understanding of "orchestration". Network slicing itself of course 
> includes the construction and arrangement of different network 
> elements/resources. However, this level of "orchestration" is not 
> enough for a dynamically configurable set of network resource, or a 
> network slice instance, for a set of requirements for service guarantees.
>

Correct, it is not.

In order for the orchestration or as it is usually called today 
controller(s), to form that dynamically configurable set of network 
resources it needs to possess the correct information and it may use 
means of transmitting of that information which we formulate (or have 
formulated already).

That is in scope and some of it is already covered by other WGs. It is 
mostly missing from your draft.

> For instance, a customer may want a slice with requirements of certain 
> BW, latency, security, power consumption or provisioning abilities and 
> guarantees. Given that a network slice instance is properly 
> established by some sort of "Brilliant Orchestration", it is still 
> subjected to the network equipments to mapping these 
> network-slice-instance-specific requirements to chip-level or 
> system-level capabilities. Remember there are inevitably co-existence 
> issues with traffics flowing on non-sliced resources with no 
> guarantees what so ever.
>

We have been chewing on that particular aspect of networking for the 
best part of two decades. In order to state that there is a new problem 
here in the first place, and that problem falls into IETF scope, we need 
a corresponding use case which shows that there is a problem which 
cannot be solved using today's technology. I have asked several times 
for this and I am yet to see one.

> Moreover, the intention of providing network slicing is also to 
> improve the capability of network customization. It is true that 
> existing technology like VPN can provide dedicated connections, but 
> what is missing is the ability for the network to dynamically mapping 
> those technologies to customized (and frequently changed) 
> requirements, and then, back to the guarantee issue, mapping to 
> equipement capabilities.
>

That, when you translate it into engineering terms, equates to modelling 
the network, representing the guarantees, representing the change and 
representing the equipment capabilities as well as moving these around 
in an interop manner between controllers.  That, I have said a few times 
- it's clearly in-scope. It is core netmod and i2rs material.

A.

>     *From:* Anton Ivanov <mailto:[email-masked]>
>     *Date:* 2017-03-16 16:34
>     *To:* netslices <mailto:[email-masked]>
>     *Subject:* Re: [Netslices] Draft on Network Slicing Architecture
>     3.1.2.
>
>     1. Implies Orchestration
>     2. Mobile specific
>     4. Does not cover datacenter resources properly. "may require
>     cloud resources" is not an acceptable definition going towards
>     standard - it is marketing. The data center in IETF is mostly NVO3
>     and to a lesser extent L2VPN. What is the interworking level and
>     function.
>     3.1.3 - Same as above. 3GPP-fest belongs in 3GPP. I do not see a
>     point of repeating 3GPP work in IETF. We already had one
>     multi-year soap opera with MPLS-TP and ITU work duplication, no
>     thanks, we do not need another. If we are to work on something it
>     should not be a duplicate.
>
>     3.1.6. Orchestration. Again. There is no IETF architecture here.
>     There is no network architecture, there is no interconnect
>     architecture, there is no interface architecture, there is no
>     protocols, nothing.
>
>     C) It does not specify any problem scope which the IETF works on
>     and is good at and it also provides standard body work duplication
>     environment.
>
>     maintain 5 years of subtly non-compliant implementations, because
>     "the standard is not finalized". While I recall quite well how and
>     who used this during the MPLS-TP IETF/ITU debacle, I do not see
>     why we should be supporting an attempt to repeat this. In fact we
>     should be explicitly against abusing IETF as a standards body for
>     this particular purpose.
>
>     A.
>
>
>>     We have submitted a draft on the architechture of Network
>>     Slicing. You can find the draft from the following link.
>>
>>     This draft briefly describes a systemetic top-level view of
>>     Network Slicing and defines some basic roles in the
>>     architechture. We also identifies some key technical issues that
>>     Network slicing should possibly address as the work progress.
>>

---

From: GENG Liang <[email-masked]>
Date: Fri, 17 Mar 2017 06:40:56 +0000

Hi Anton and all,

Again, I think we are still at the stage of elaborating the mutual understanding of network slicing and identify if there are gaps within scope. People will need background information to work from. I do not see providing these information indicates any risk of duplicated work at the moment. We, as well as standard organizations as 3GPP are all yet to understand potential requirements and nail down the exact working areas.

As Anton mentioned (in another tread) a great example of what may be called a SLICE - the vCPE scenario. It obviously implies that there are gaps between people in the list on the understanding of network slicing. vCPE is a great example of combining connectivity and computing resources. However, how vCPE is set up by current technologies (If you refer to BBF version of VCPE, i.e. WT317 - various kind of tunneling + VNFs in cloud), is not what I have envisioned for future network slicing because it does not reflects the two basic requirements of Service-Guarantee and Customization.

In my philosophy,  under the network slicing regime. vCPE, or any other type/form/of services or the actually operator behind them (either Mr. OTT or Mr. SP) are network slice tenants. They should not worry about what technologies are being used to meet their requirements. SPs are due to make sure the Tunneling, BW, Latency, Computing etc. are arranged to meet the demand.

Now, very importantly, there need to be means to identify this slice instance from this specific tenant, for service-guarantee purpose (i. e. protections in different layers maybe applied according to reliability requirement for example). I do not see that centralized configuration method is quite enough for the future business/service model. Two reasons have come to my mind so far. One is the fact of zillions of IoT connections and potentially massive amount of dynamic configuration requests - unscalable. The other is the overwhelming critical latency requirement - bad performance. For both reasons, some sort of distributed local processes may be preferred.

For the other aspect of slice customization, it is also preferred to have the most automation or chained process instead of overly-spread point-to-point or hierarchical re-configuration. Hence, it is important for the components within a slice to know the existence of others and extra accessible resources. This may be overcome by means of orchestration but again, I don't believe the current technologies is fully capable for the purpose and that the centralized configuration is a total solution.

Best wishes

From: Anton Ivanov<mailto:[email-masked]>
Date: 2017-03-16 19:50
To: GENG Liang<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] Draft on Network Slicing Architecture
On 16/03/17 11:16, GENG Liang wrote:
Hi Anton,

As in the draft at present, it is presently mostly at layer 8, the few things below that layer fall outside IETF scope.

It is a technical assumption. I read your document strictly through technical "goggles" and I see 70%+ 3GPP duplication with the remainder at layer 8 or above.

When I see something that is neither I will change my mind. Before that - sorry, I do not see this as anything different but a prelude to another MPLS-TP style saga. That is where this is going and no thanks, we have seen that movie from the front row.

Correct, it is not.

In order for the orchestration or as it is usually called today controller(s), to form that dynamically configurable set of network resources it needs to possess the correct information and it may use means of transmitting of that information which we formulate (or have formulated already).

That is in scope and some of it is already covered by other WGs. It is mostly missing  from your draft.

For instance, a customer may want a slice with requirements of certain BW, latency, security, power consumption or provisioning abilities and guarantees. Given that a network slice instance is properly established by some sort of "Brilliant Orchestration", it is still subjected to the network equipments to mapping these network-slice-instance-specific requirements to chip-level or system-level capabilities. Remember there are inevitably co-existence issues with traffics flowing on non-sliced resources with no guarantees what so ever.

We have been chewing on that particular aspect of networking for the best part of two decades. In order to state that there is a new problem here in the first place, and that problem falls into IETF scope, we need a corresponding use case which shows that there is a problem which cannot be solved using today's technology. I have asked several times for this and I am yet to see one.

Moreover, the intention of providing network slicing is also to improve the capability of network customization. It is true that existing technology like VPN can provide dedicated connections, but what is missing is the ability for the network to dynamically mapping those technologies to customized (and frequently changed) requirements, and then, back to the guarantee issue, mapping to equipement capabilities.

That, when you translate it into engineering terms, equates to  modelling the network, representing the guarantees, representing the change and representing the equipment capabilities as well as moving these around in an interop manner between controllers.  That, I have said a few times - it's clearly in-scope. It is core netmod and i2rs material.

A.

Best wishes
Liang

1. Implies Orchestration
2. Mobile specific

A) It includes Layer 1.

A.

Best wishes
Liang