Re: [Detnet] [Nfvrg] [5gangip] Network Slicing - a suggestion that we meet to discuss in Seoul (INTERNAL)

If we could instantiate all of the below as well described data models (hopefully YANG) - this would provide loosely coupled framework across different technologies.

Data models for transport parts are there, mW work is ongoing in CCAMP. We should extend this work to services and radio

Regards,
Jeff

> On Nov 1, 2016, at 15:12, <Kashif.Mahmood@telenor.com> <Kashif.Mahmood@telenor.com> wrote:
> 
> IMO the discussion below is around resource slicing where resources are compute/connectivity/storage.
> What 3GPP talks is more about network slicing which  is more of a “logical network composed by interconnection of set of network functions”. Off course network slices cannot run in the air so they need resources slices and this is how I see the mapping.
> FYI:
> 3GPP SA2 defines the following (TR 23.799)
>  
> Network Slice Template (NST):  is a logical representation of the Network Function(s) and corresponding resource requirements necessary to provide the required telecommunication services and network capabilities.
> Network Slice Instance (NSI): is an instance created from a Network Slice Template (NST).
> Network Slice: is a concept describing a system behaviour which is implemented via Network Slice Instance(s).
>  
> BR,
> Kashif
>  
> -----Original Message-----
> From: Nfvrg [mailto:nfvrg-bounces@irtf.org] On Behalf Of Jeff Tantsura
> Sent: 1. november 2016 22:26
> To: Stewart Bryant
> Cc: Dongjie (Jimmy); Mach Chen; Joe Touch; draft-ietf-teas-actn-framework@ietf.org; draft-galis-anima-autonomic-slice-networking@ietf.org; nfvrg@irtf.org; 5gangip@ietf.org; detnet@ietf.org; draft-vonhugo-5gangip-ip-issues@ietf.org; draft-xuan-dmm-multicast-mobility-slicing@ietf.org
> Subject: Re: [Nfvrg] [Detnet] [5gangip] Network Slicing - a suggestion that we meet to discuss in Seoul
>  
> Network slicing has become de facto standard terminology in context of 5G.
>  
> It would be rather useful to:
> -agree on terminology
> -discuss data modeling, interrelated technologies - radio, packet core, transport, optical to mention some and how they could work together/form in a "slice"
> -bring together experts in these, rather disjointed domains.
> -many other things
>  
> Regards,
> Jeff
>  
> > On Nov 1, 2016, at 12:39, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> >
> >
> >
> >> On 01/11/2016 16:55, Joe Touch wrote:
> >> Hi, all,
> >>
> >>
> >>> On 11/1/2016 8:21 AM, Stewart Bryant wrote:
> >>> We were trying to pull together a problem statement for network
> >>> slicing in a 5G context to understand how well the current IETF
> >>> protocols address this problem, what their short comings might be,
> >>> and what IETF work is necessary to have a deployable protocol suite
> >>> to address this need.
> >> I've seen this term around for a while, and continue to consider it
> >> nonsensical.
> >>
> >> It originally referred to a way of cutting OS resources and tying
> >> them to a distributed system in PlanetLab, which had no support for
> >> network virtualization. It has since been used to refer to E2E
> >> virtual nets (distinct from VPNs, which often tether individual hosts
> >> to a private net over the public Internet), but all networks have
> >> always had that capability.
> >>
> >> IMO, this term isn't related to the Internet architecture at all. It
> >> needs to correctly tie the existing network overlays that the
> >> Internet has supported for a very long time to OS resources.
> >>
> >> I.e., most of the work in defining "network slicing" needs to happen
> >> inside the OS, which is out of scope for the IETF. A properly defined
> >> E2E virtual network terminates at (virtual) network interfaces, which
> >> is compatible with either a sliced OS or a non-sliced OS.
> >>
> >> Joe
> >>
> >
> > Joe, we possibly have different ideas as to what network slicing is.
> >
> > My assumption is that it is a way that we can create multiple
> > virtually networks over a common base network with a higher degree of
> > isolation between VPNs and much higher performance guarantees than we currently achieve.
> >
> > If we need a new name, we need a new name, but the concept does not
> > seem to align with the definition you hints at.
> >
> > - Stewart
> >
> >
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
>  
> _______________________________________________
> Nfvrg mailing list
> Nfvrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nfvrg