Subject: [Netslices] FW: New Version Notification for draft-flinck-slicing-management-00.txt

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 4 Jul 2017 15:56:01 +0000

A new version of I-D, draft-flinck-slicing-management-00.txt
has been successfully submitted by Hannu Flinck and posted to the
IETF repository.

Name:		draft-flinck-slicing-management
Revision:	00
Title:		Network Slicing Management and Orchestration
Document date:	2017-07-03
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-flinck-slicing-management-00.txt
Status:         https://datatracker.ietf.org/doc/draft-flinck-slicing-management/
Htmlized:       https://tools.ietf.org/html/draft-flinck-slicing-management-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-flinck-slicing-management-00

Abstract:
   Network Slicing is worked in multiple SDOs from different view
   points.  As network slicing is an end-to-end topic, this draft
   proposes that network slices architecture [NS-Framework] aligns with
   the work done in NGMN, 3GPP and ETSI with relation to management and
   orchestration.  The key aspect that this draft makes is the rational
   for role and need for Network Slice Management Function (NSMF) entity
   that operates above Network Virtualization Function Orchestrator and
   PNFs Management Functions.  NSMF needs to support different
   abstractions of resources and to offer access to different management
   entities.

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

The IETF Secretariat

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Wed, 5 Jul 2017 03:35:17 +0000

Hi Hannu, all,

I have gone through the draft and some comments / doubts come to my mind.

.- The draft considers three different categories or kind of slices, depending on the level of control exposed to the tenant. These are basically:
1) the tenant just merely can use the slice provided
2) the tenant can change some configuration on the functions part of the slice
3) the tenant has full control of the slice
Looking at this from an operator mindset, considering similarities with wholesale product offerings probably an analogy could be set in the sense of considering that:
1) what the tenant consumes is what is known as a managed service. The provider can use slicing mechanisms for that, but not only (or even a mix of slicing plus conventional service offerings). From the infrastructure point of view this is not so much different from sharing part of the network, or even partitioning in a more extreme case. But the provider retains the management and control e2e.
2) what the tenant is allowed is to managed its service to some extent. Then, from the service offering point of view, this would be equivalent to an unmanaged service (from the provider perspective). The tenant can make some operations / configurations, and the provider just provides the infrastructure necessary for that (understanding infrastructure in a broad sense, so including as well the network functions that the customer can configure). Once again, the provider can use slicing mechanisms for that, but not only (or even a mix of slicing plus conventional service offerings).
3) This is a pure slicing service from the provider perspective, where the tenant receives an e2e logical network, on top of a shared infrastructure with
independent control and management. This necessary has to be implemented through slicing mechanisms, conventional ones are not more valid (this does not prevent that e.g. some overlay mechanisms could be used for the transport part).

My comment here is that probably the focus should be on (3) as the more complete and comprehensive scenario to analyze.

.- when talking about sharing or common usage of functions/elements, it is mentioned that such capability is performed by EMS/NMS. This is not clear to me. Such sharing capabilities are intrinsic to the element (e.g., VRFs in PE routers) or to the function (distinct APNs in GGSNs). This can be certainly instantiated or configured via EMS, but it is not a capability of them. Maybe you can clarify what you mean with that.

.- when talking about the different lifecycles for PNFs and VNFs it is mentioned that the NSMF should support service level abstractions. Since "service" is a very overloaded term I'm not sure about what kind or level of services you refer. I guess it should refer to network function level abstractions and connectivity abstractions, right? Because looking at TR 28.801 that the CSMF (the communications service  management function) passes to NSMF the requirements of the network slice in terms of network type, network capacity, QoS requirements, etc. In other words, the NSMF does not need to support customer service level abstractions, right?

.- It is not clear the purpose of Figure 1. It is not referenced in the text, then not clear to me if it is taken from some other place, if it is you final view of the problem, etc. Also it is not clear the origin of some entities like the Service M&O. Is it NGMN terminology? Is it 3GPP terminology? I don't think so, but maybe I'm wrong. For clarity it should be nice to have a better description and a better motivation for such figure.

.- Also it is mentioned that these constructs can be considered as part of the OSS/BSS according to TR28.801, but I think this is not correct. In section 7, TR 28.801 mentions: How network slice management functions are mapping to OSS/BSS is FFS

.- In general, I do not feel comfortable with your positioning of NSMF as part of OSS/BSS. I think that the purposes of OSS/BSS and NSMF are different and some positioning of NSMF with respect OSS/BSS like the one in ETSI NFV architecture is what I could expect. Linking NSMF to OSS/BSS creates important architectural dependencies for the evolution of the networks and for sure will difficult vendor interoperability/inter-manageability, as well as probably migration. This is what we are seeing today with more simplistic capabilities like SDN, for instance.

Probably I have misunderstood concepts, so any clarification is more than welcome.

Best regards

Luis

-----Mensaje original-----
De: Netslices [mailto:[email-masked]] En nombre de Flinck, Hannu (Nokia - FI/Espoo)
Enviado el: martes, 4 de julio de 2017 17:56
Para: [email-masked]
Asunto: [Netslices] FW: New Version Notification for draft-flinck-slicing-management-00.txt

A new version of I-D, draft-flinck-slicing-management-00.txt
has been successfully submitted by Hannu Flinck and posted to the IETF repository.

Name:draft-flinck-slicing-management
Revision:00
Title:Network Slicing Management and Orchestration
Document date:2017-07-03
Group:Individual Submission
Pages:10
URL:            https://www.ietf.org/internet-drafts/draft-flinck-slicing-management-00.txt
Status:         https://datatracker.ietf.org/doc/draft-flinck-slicing-management/
Htmlized:       https://tools.ietf.org/html/draft-flinck-slicing-management-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-flinck-slicing-management-00

Abstract:

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

The IETF Secretariat

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

________________________________

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

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

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

---

From: Pedro Martinez-Julia <[email-masked]>
Date: Wed, 5 Jul 2017 13:28:12 +0900

Dear Luis,

The "operator" perspective you are providing is really appreciated and
we will/should concentrate on point 3 for the "tenant perspective" and
the other points for the "operator perspective".

For the time being, I take this opportunity to ask you what an operator
is for you. In my mind I have the following roles (you can use different
names, but semantically are the same):

- Infrastructure Provider (InP): Owns the physical infrastructure and
  slices each physical element to get several virtual elements. For
  instance this /can/ be played by Telefonica, Orange, Vodafone, etc.

- Virtual Network Operator (VNO): Builds one or more slices of resources
  contacted to the InPs and then constructs a virtual network system on
  their top. For instance this /can/ be Yoigo, Simyo, etc.

- Application Service Provider (ASP): Contracts the virtual network
  system offered by a VNO, builds an application on top of it and offers
  it to users/customers. This can be played by Simyo (but not Yoigo).

Regarding the example organizations, all of them are clearly hybrid but
if we consider just a separate product/service we can classify them. For
instance, we can contract a set of physical links to Telefonica, a set
of access rights to Vodafone 4G service, and build a whole IP network
that a third party (ASP) can contract and then deploy an IMS solution to
offer call services to its customers.

In this sense, we have two clear points of standardization: The provider
needs a standard way to slice its physical resources so it is not tied
to any specific vendor or customer interface. The customer also needs a
standard way of managing (CRUD) their resource slices. The question in
relation to your comment would be whether it is better to address both
viewpoints together or separately.

Please give us your opinion and, please, try to associate it to some of
the roles I mention. Thank you very much.

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: <[email-masked]>
Date: Wed, 5 Jul 2017 13:52:06 +0000

Dear Flinck, 

Thank you for sharing this draft. 

I had the impression that you assume a "slices for sale" approach (or a "lease" network approach if you will) and that there is one single tenant for each instantiated network slice. 

It is fine to cover this case (even if I have some concerns with it), but I do personally see slicing as an internal tool for a network provider to honor the needs of services/customer having common requirements. That is a network slice can be shared among multiple tenants/services. Doing so allows to rationalize the usage of resources within a network without requiring instantiated slices to linearly increase as a function of the tenants. 

I don't see this second perspective reflected in your document.

Cheers,
Med

> -----Message d'origine-----
> De : Netslices [mailto:[email-masked]] De la part de Flinck,
> Hannu (Nokia - FI/Espoo)
> Envoyé : mardi 4 juillet 2017 17:56
> À : [email-masked]
> Objet : [Netslices] FW: New Version Notification for draft-flinck-slicing-
> management-00.txt
> 
> 
>

---

From: Gino Carrozzo <[email-masked]>
Date: Wed, 5 Jul 2017 18:58:20 +0200

Hi Mohamed

If I correctly captured your point, the grouping of resources in a single
slice for multiple tenants will be driven by the capability to fulfill
similar service KPIs, e.g. for URLLC, eMBB, MTC, etc..

As such, doesn't the network slice "degenerate" into a set of NS-es
originated by the network [slice] operator?
Would the only control modes applicable to this case be 1) Monitoring only
and 2) limited configuration of VNFs? I.e. there would be no need for a
MANO stack for the slice consumer.

Thanks for your clarification
br
Gino

On 5 July 2017 at 15:52, <[email-masked]> wrote:

> I had the impression that you assume a "slices for sale" approach (or a
> "lease" network approach if you will) and that there is one single tenant
> for each instantiated network slice.
>
> It is fine to cover this case (even if I have some concerns with it), but
> I do personally see slicing as an internal tool for a network provider to
> honor the needs of services/customer having common requirements. That is a
> network slice can be shared among multiple tenants/services. Doing so
> allows to rationalize the usage of resources within a network without
> requiring instantiated slices to linearly increase as a function of the
> tenants.
>
> > URL:            https://www.ietf.org/internet-
> drafts/draft-flinck-slicing-
> > management-00.txt

-- 
==============================================================
  Dr. Gino Carrozzo
  Deputy Head of R&D

  mobile    : +39 348 7610 081
  landline  : +39 050 3871 679
  fax         : +39 050 3871 601
  e-mail    : [email-masked]
  web       : www.nextworks.it
  address   : Nextworks s.r.l.
                  via Livornese, 1027
                  56122 S.Piero a Grado, Pisa, ITALY
==============================================================

---

From: "Kiran.Makhijani" <[email-masked]>
Date: Thu, 6 Jul 2017 00:02:13 +0000

Hi Med,
In addition to Gino’s comment, my opinion is that w.r.t. 4 requirements in gap-analysis, multi-tenancy per instance should not qualify as a slice (at least in my head). That’s a service. We have been talking about operational isolation and independent OAM of a slice where a tenant can operate on a ‘slice’. Having multiple tenants in an instance will need another abstraction to “group resources per tenant per instance”. To me that’s additional complexity.
Regards
Kiran

From: Netslices <[email-masked]> on behalf of Gino Carrozzo <[email-masked]>
Date: Wednesday, July 5, 2017 at 9:58 AM
To: "[email-masked]" <[email-masked]>
Cc: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Hi Mohamed

If I correctly captured your point, the grouping of resources in a single slice for multiple tenants will be driven by the capability to fulfill similar service KPIs, e.g. for URLLC, eMBB, MTC, etc..

As such, doesn't the network slice "degenerate" into a set of NS-es originated by the network [slice] operator?
Would the only control modes applicable to this case be 1) Monitoring only and 2) limited configuration of VNFs? I.e. there would be no need for a MANO stack for the slice consumer.

On 5 July 2017 at 15:52, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Flinck,

Cheers,
Med

> De : Netslices [mailto:[email-masked]<mailto:[email-masked]>] De la part de Flinck,
> Hannu (Nokia - FI/Espoo)
> À : [email-masked]<mailto:[email-masked]>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
> [email-masked]<mailto:[email-masked]>

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

  mobile    : +39 348 7610 081
  landline  : +39 050 3871 679
  fax         : +39 050 3871 601
  e-mail    : [email-masked]<mailto:[email-masked]>
  web       : www.nextworks.it<http://www.nextworks.it>
  address   : Nextworks s.r.l.
                  via Livornese, 1027
                  56122 S.Piero a Grado, Pisa, ITALY
==============================================================

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Thu, 6 Jul 2017 06:43:13 +0000

Hi Pedro,

"Operator" implies the fact of manage and operate an infrastructure for providing a service to customers. Traditional responsibilities for an operator with respect to a network (as technological substrate needed for providing the service offered to customers) were basically three: Design, Build and Run.

All these three traditional responsibilities are (or can be) transformed with the advent of virtualization (even as known before in the form of MVNO). Now an operator not necessary needs to Design and plan totally its network (it can be leased in part); neither the operator needs to Build and deploy the network (again, it can be partially leased). Probably the key part is the Run in the scope of operating their assets. Without operation, the organization is reduced merely to the commercial part, then basically being an intermediate between the customers and the real operator. An example of this could be the MVNOs created by some brands e.g. supermarkets (like Carrefour).

So with respect your classification, at least InP and VNOs could be considered as operators in my mind. No so clear with the ASP, I presume it depends so much of the scope of the application and how it relates with the network (as technological substrate for providing the service).

For sure, it is not easy make general statements as the ones above, tale it as a generalization.

With respect to your question about what could be required to be standardized. I would say that both points of views are required, for sure. And probably we cannot separate them, as the customer need conditions the provider offerings.

Best regards

Luis

-----Mensaje original-----
De: Pedro Martinez-Julia [mailto:[email-masked]]
Enviado el: miércoles, 5 de julio de 2017 6:28
Para: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
CC: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Asunto: Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Dear Luis,

The "operator" perspective you are providing is really appreciated and we will/should concentrate on point 3 for the "tenant perspective" and the other points for the "operator perspective".

For the time being, I take this opportunity to ask you what an operator is for you. In my mind I have the following roles (you can use different names, but semantically are the same):

Regarding the example organizations, all of them are clearly hybrid but if we consider just a separate product/service we can classify them. For instance, we can contract a set of physical links to Telefonica, a set of access rights to Vodafone 4G service, and build a whole IP network that a third party (ASP) can contract and then deploy an IMS solution to offer call services to its customers.

In this sense, we have two clear points of standardization: The provider needs a standard way to slice its physical resources so it is not tied to any specific vendor or customer interface. The customer also needs a standard way of managing (CRUD) their resource slices. The question in relation to your comment would be whether it is better to address both viewpoints together or separately.

Please give us your opinion and, please, try to associate it to some of the roles I mention. Thank you very much.

Regards,
Pedro

On Wed, Jul 05, 2017 at 03:35:17AM +0000, LUIS MIGUEL CONTRERAS MURILLO wrote:
> 3) the tenant has full control of the slice Looking at this from an
> operator mindset, considering similarities with wholesale product offerings probably an analogy could be set in the sense of considering that:
> 3) This is a pure slicing service from the provider perspective, where
> the tenant receives an e2e logical network, on top of a shared infrastructure with independent control and management. This necessary has to be implemented through slicing mechanisms, conventional ones are not more valid (this does not prevent that e.g. some overlay mechanisms could be used for the transport part).
>
> .- Also it is mentioned that these constructs can be considered as
> part of the OSS/BSS according to TR28.801, but I think this is not
> correct. In section 7, TR 28.801 mentions: How network slice
> management functions are mapping to OSS/BSS is FFS
>
> De: Netslices [mailto:[email-masked]] En nombre de Flinck,
> Hannu (Nokia - FI/Espoo) Enviado el: martes, 4 de julio de 2017 17:56
> Para: [email-masked]
> Title:Network Slicing Management and Orchestration Document
> date:2017-07-03 Group:Individual Submission
> Pages:10
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
> destinatário, pode conter informação privilegiada ou confidencial e é
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
> senhoria o destinatário indicado, fica notificado de que a leitura,
> utilização, divulgação e/ou cópia sem autorização pode estar proibida
> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
> proceda a sua destruição

--
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: <[email-masked]>
Date: Thu, 6 Jul 2017 09:12:26 +0000

Hi Gino,

Please see inline.

Cheers,
Med

De : Gino Carrozzo [mailto:[email-masked]]
Envoyé : mercredi 5 juillet 2017 18:58
À : BOUCADAIR Mohamed IMT/OLN
Cc : Flinck, Hannu (Nokia - FI/Espoo); [email-masked]
Objet : Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Hi Mohamed

If I correctly captured your point, the grouping of resources in a single slice for multiple tenants will be driven by the capability to fulfill similar service KPIs, e.g. for URLLC, eMBB, MTC, etc..
[Med] Yes. A slice is engineered to transfer flows belonging to services/customers having common requirements.

As such, doesn't the network slice "degenerate" into a set of NS-es originated by the network [slice] operator?
[Med] It may or may not. It is up to each operator to decide how to engineer its network.

Would the only control modes applicable to this case be 1) Monitoring only and 2) limited configuration of VNFs?
[Med] Probably. I would also add the control of the order of invoking those VNFs. Multiple service chains should be supported over the same slice.

For sure, I would not give out the control of all routers that are involved in forwarding flows of a given service. For example, a network provider may decide to exclude satellite links for transporting and delivering delay-sensitive flows, but a tenant has not to be aware of the actual (logical) topology that excluded those links.

I.e. there would be no need for a MANO stack for the slice consumer.

Cheers,
Med

---

From: GENG Liang <[email-masked]>
Date: Thu, 6 Jul 2017 10:25:59 +0000

Hi Hannu,

I like the idea of adding ETSI MANO to the picture and distinguish PNF and VNF since the Orchestration of these different types of resources in a network slice instance may be very different. We can discuss further to see how the Framwork document address your concerns

However, the SA5 terms NSMF (which is E2E orchestration in NS-Framework) and NSSMF (which is domain orchestration in NS-Framework) may need further discussion. I am slightly worried about directly using terms defined in other SDOs because you never know what they possibly mean tomorrow.

Best wishes
Liang

________________________________
Liang GENG
China Mobile Research Institute

From: Flinck, Hannu (Nokia - FI/Espoo)<mailto:[email-masked]>
Date: 2017-07-04 23:56
To: [email-masked]<mailto:[email-masked]>
Subject: [Netslices] FW: New Version Notification for draft-flinck-slicing-management-00.txt

Abstract:

The IETF Secretariat

---

From: GENG Liang <[email-masked]>
Date: Thu, 6 Jul 2017 10:42:32 +0000

Dear Med

I think "one single tenant per slice" and "multiple tenants per slice" are both valid slice arrangements. It is rather a implementation/business model choice of Network Slice Provider (Operator/infrastructure owner)  leasing infrastructures/resource/capabilities in different granularities.

The operator may use "multiple tenants per slice" approach to advertise the "eMBB","URLLC" slices. However for more customized requirements (i.e. a specific acceleration/CDN/sercurity ) from a AR gaming application vendor, operator may use  "one single tenant per slice" approach. The level of provisioning abilities exposed to the tenants would be different in these two cases and would be a interesting topic to be addressed in the future.

Best wishes
Liang

From: [email-masked]<mailto:[email-masked]>
Date: 2017-07-05 21:52
To: Flinck, Hannu (Nokia - FI/Espoo)<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt
Dear Flinck,

Cheers,
Med

---

From: <[email-masked]>
Date: Thu, 6 Jul 2017 11:10:51 +0000

Hi Kiran,

Hmm.. I would see the complexity in having as many slices instantiated in a network as tenants. IMO, we need to avoid stretching the concept to extremes where, for instance, a service chain is characterized as a slice!

My initial comment was, at this stage of the discussion, we need to cover both the viewpoint in draft-flinck and the one I exposed. See attached.

Cheers,
Med

De : Kiran.Makhijani [mailto:[email-masked]]
Envoyé : jeudi 6 juillet 2017 02:02
À : Gino Carrozzo; BOUCADAIR Mohamed IMT/OLN
Cc : Flinck, Hannu (Nokia - FI/Espoo); [email-masked]
Objet : Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Hi Med,

From: Netslices <[email-masked]<mailto:[email-masked]>> on behalf of Gino Carrozzo <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 5, 2017 at 9:58 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Hi Mohamed

Cheers,
Med

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 17 Jul 2017 07:52:50 +0000

Hello Liang

Sorry about late response. I have been out of office few past weeks.

Even if I am  not too particular about the terminology we still need to have a common understanding how the various concepts relate especially at  the boarders of the domains across different SDOs. This is important to identify caps and ensure interoperability.

Best regards
Hannu

From: GENG Liang [mailto:[email-masked]]
Sent: Thursday, July 06, 2017 1:26 PM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: [Netslices] FW: New Version Notification for draft-flinck-slicing-management-00.txt

Hi Hannu,

Best wishes
Liang

Abstract:

The IETF Secretariat

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 17 Jul 2017 08:00:25 +0000

Hello Med and Liang

It was not our intention to tie the approach with the one use case you suggest below, namely single tenant per slice. However, even with a shared slice between multiple tenants a single tenant is likely to require customized view on the FCAPS of the slice per tenant’s SLA. Of course if a slice is a tool for  operator internal service optimization there is no need to expose slice KPIs to the end users.

Best regards
Hannu

From: GENG Liang [mailto:[email-masked]]
Sent: Thursday, July 06, 2017 1:43 PM
To: [email-masked]; Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: Re: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Dear Med

Best wishes
Liang

Cheers,
Med

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 17 Jul 2017 08:05:42 +0000

Hello Med

Yes. I agree.

Best regards
Hannu

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 06, 2017 2:11 PM
To: Kiran.Makhijani <[email-masked]>; Gino Carrozzo <[email-masked]>
Cc: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: RE: [Netslices] New Version Notification for draft-flinck-slicing-management-00.txt

Hi Kiran,

Cheers,
Med

Cc : Flinck, Hannu (Nokia - FI/Espoo); [email-masked]<mailto:[email-masked]>

Hi Med,

Hi Mohamed

Cheers,
Med