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

From: Eric Gray <[email-masked]>
Date: Fri, 1 Nov 2019 13:10:12 +0000

One of the draw-backs to the template we've been looking at is that it is for GSMA - which we (Ericsson) feel does not have a complete correspondence to 5G Network Slicing.

Moreover, the scope of network slicing is more generic than either GSMA or 5G.  It includes network slicing as some folks are already using it in connection with Data Center Networking.

In a different context, we might talk about whether or not that usage is a good idea or not.

I am inclined to agree with the less restrictive definition for network slicing that Reza and others have proposed, where - as an abstract - the idea is that it is technology independent and (to the extent possible) capable of incorporating a reasonably arbitrary set of services.

From: John E Drake <jdrake=[email-masked]>
Sent: Thursday, October 31, 2019 10:30 AM
To: Eric Gray <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Subject: RE: New document: IETF definition of transport slice
Importance: High

Eric,

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

Yours Irrespectively,

John

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

John,

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

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

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

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

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

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

--
Eric

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

Hi,

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

Yours Irrespectively,

John

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

All,

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

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

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

Cheers,

Reza

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Sat, 2 Nov 2019 11:46:00 +0000

Hi Eric, all,

Despite the work on slicing management and control is on-going in 3GPP and not all the pieces are clearly defined and closed, I think we cannot ignore the GST as the root of the slice definition for 5G, which will probably the first situation that the operators will have to address (commercially and/or in real pilots and trials).

GST is the root to later define Network slice templates per type of service. This will be the process (documented in Annex A of 3GPP TS 28.531)

Once the slice is requested by the customer, the 3GPP management system will generate specific network slice subnet instances per technological areas, including the transport network, as shown in the following figure:

All this process has as the starting point the NEST which is derived from the GST.

>From that perspective I think it is worthy to consider the different attributes in GST as potential parameters to be handled in the NBI of the entity in charge of producing a Transport Slice.

By the way I'm working in an individual draft related to the work in templates done till now with the objective of posting before cut-off date.

For sure, other use cases will be illustrated as it is a work in progress.

Best regards

Luis

De: Teas-ns-dt <[email-masked]> En nombre de Eric Gray
Enviado el: viernes, 1 de noviembre de 2019 14:10
Para: John E Drake <jdrake=[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]; Kiran Makhijani <[email-masked]>; Kiran Makhijani <[email-masked]>; Shunsuke Homma <[email-masked]>
Asunto: Re: [Teas-ns-dt] New document: IETF definition of transport slice

From: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>
Sent: Thursday, October 31, 2019 10:30 AM
To: Eric Gray <[email-masked]<mailto:[email-masked]>>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Shunsuke Homma <[email-masked]<mailto:[email-masked]>>
Subject: RE: New document: IETF definition of transport slice
Importance: High

Eric,

Yours Irrespectively,

John

John,

--
Eric

Hi,

Yours Irrespectively,

John

All,

Cheers,

Reza

________________________________

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

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

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