Re: [Netslices] Distinguishing "slice types" [Was: Timing service]

["Kiran.Makhijani" <[e-mail]>]

Hello Adrian,
Partial answer regarding types. we have tried to address this  in use cases document.  There are following types of slices (in 2 categories).
   1. Generalized/Customization
     a. NFV type: e.g. vCPE etc, which benefits from flexibility to customize networks.
     b. New logical Infra type: support for new solutions on common infrastructure e.g. ICN over slice.
   2. Strict resource based
     c.  High Bandwidth/Fixed latency Type: e.g. Enhanced Broadband (Res: high bandwidth, fixed latency)
     d.  mMTC type: Massive machine to machine communication (low power, low bandwidth)
     e.  Time sensitive type: Ultra-reliable low latency communication (remote industry operations)
f.  0 pkt loss: Critical Communications/Emergency services (probably a scenario suitable for hard slice)

identifying interactions (data + logic) will be a new addition to gap analysis and could be explained better once revised version is out. Additional work is still needed to qualify that those interactions can satisfy above types.

https://tools.ietf.org/html/draft-netslices-usecases-00 (WIP).

Regards
Kiran

From: Netslices [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Wednesday, June 21, 2017 4:07 AM
To: Dongjie (Jimmy) <[e-mail]>; [e-mail]; 'stewart.bryant' <[e-mail]>; [e-mail]; [e-mail]; AshwoodsmithPeter <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Netslices] Distinguishing "slice types" [Was: Timing service]

All, I think you are getting somewhere in the recognition of different types of slice and slicing.

Different types of slice would appear to have different applications, different requirements of the underlying networks, different characteristics, etc.

My view of this "problem space" from the outside is that the term "network slice" is very (very, very) broadly defined. While the high level concept of slicing is constant across all of these definitions, that is not actually very helpful from the perspective of a technology development organisation. High-level and wide-reaching architectural pictures have a value, but they are normally something that the IETF works on.

What we need (in order for the BoF to be a success) is to focus in on each individual "type" of network slice. That should help us to understand what protocol tools we will use, and what additional pieces need to be developed.

The feeling that Gonzalo and I are getting is that it will be helpful to have several talks on "What I mean by network slicing, what applications my slices would serve, and what requirements I have on existing and developing protocol components."

We can start to talk about this on the call, but this approach would be about dismantling the Grand Unification Theory of Network Slicing, and arriving at a number of views of different pieces of the elephant. Gonzalo and I will need help in identifying which pieces of elephant people care about, and who cares most about each piece.

(Note that an end result *might* be that everything falls into place and we see a whole elephant. Or we may set the different pieces free to do the right work in the relevant places.)

Cheers,
Adrian

From: Netslices [mailto:[e-mail]] On Behalf Of Dongjie (Jimmy)
Sent: 21 June 2017 11:36
To: [e-mail]<mailto:[e-mail]>; stewart.bryant; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; AshwoodsmithPeter
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [Netslices] 答复: Timing service

So you suggest to use the term hard slice and soft (or virtual) slice to differentiate the characteristic of different slices?

-Jie
发件人：Anton Ivanov
收件人：stewart.bryant,Gert Grammel,Greg Mirsky,Peter Ashwood-Smith
抄送：Thomas Nadeau,Daniele Ceccarelli,[e-mail]
时间：2017-06-21 17:18:59
主题:Re: [Netslices] Timing service

On 21/06/17 09:30, Stewart Bryant wrote:



So do we need the terms physical and virtual slice?

Phys slice is mostly out of IETF traditional scope. The only thing we should do about it is modelling.

So, from that perspective, having hard and virtual sounds reasonable provided we stick to the scope of what we can do and the model is compatible across both.



One method of delivering a hard slice is via FlexE and that is physical for the purposes of these discussions, although I am not sure what remapping to re-arrange capacity will do for the quality of the time transfer.

Whatever a hard slice may be, it is not IETF material (except their model). Ditto (even more so), for its delivery.

A.



- Stewart

On 20/06/2017 22:23, Gert Grammel wrote:
Greg,

Before we go too far, I think we have to agree on what we mean with slicing. If a slice *must* be virtualized, then there is not much we can do for ptp. If a slice is something more amorph, a "physical slice" may exist. However my concern in that case would be that the term "slice" is so broad that it can't be used anymore for anything useable.

Gert

From: Greg Mirsky <[e-mail]><mailto:[e-mail]>
Date: Tuesday, 20. June 2017 at 22:03
To: AshwoodsmithPeter <[e-mail]><mailto:[e-mail]>
Cc: Gert Grammel <[e-mail]><mailto:[e-mail]>, Stewart Bryant <[e-mail]><mailto:[e-mail]>, Thomas Nadeau <[e-mail]><mailto:[e-mail]>, Anton Ivanov <[e-mail]><mailto:[e-mail]>, "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, Daniele Ceccarelli <[e-mail]><mailto:[e-mail]>
Subject: Re: [Netslices] Timing service

Hi Peter,
another consideration for network slicing may be scope of the network slice domain. PTP domain, as I understand, is more difficult to scale up than NTP domain. It may be that certain quality of clock synchronization is indeed physical property of the underlay.

Regards,
Greg

On Tue, Jun 20, 2017 at 2:54 PM, AshwoodsmithPeter <[e-mail]<mailto:[e-mail]>> wrote:
Hey Gert,

It was an observation. I don't know the best solution. Just offering it up for discussion.

The point is that to configure the timing you need to know the physical topology , the location of grand master clock sources and syncs and you have to compute a pair of diverse trees, then you need to configure all the intermediate boundary clocks adjust any differential errors, master slave relationships and fallback behavior. You may also need to bring this into a DC/CRAN and configure it to servers, radios etc.

So it starts to look a lot like configuring a slice.

The fact the resources are physical as opposed to virtual does not make that much difference really and of course some normal (non-timing) slices would require physical resources possibly end to end.

Anyway I'm not advocating it, just pointing out that what you need looks a lot like some of the functions of a slice orchestrator where the resulting slice provides services to all the other slices.

Peter

-----Original Message-----
From: Gert Grammel [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Tuesday, June 20, 2017 3:14 PM
To: AshwoodsmithPeter <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Thomas Nadeau <[e-mail]<mailto:[e-mail]>>
Cc: Anton Ivanov <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netslices] Timing service

Peter,

Do you suggest a de-virtualized version of a network slice?
I think that is stretching the meaning of "slice" a bit too far.

Gert

On 2017-06-20, 20:52, "AshwoodsmithPeter" <[e-mail]<mailto:[e-mail]>> wrote:

    The only subtle point I would make is that nothing prevents the timing to be its own 'slice', its aware of all the physical links, sources of grand master,  and who needs what levels of precision. It can compute where the boundary clocks go and establish primary and backup trees (disjoint MST's). So the mechanisms that are used to control slices can be used to control two bare metal timing 'slices'.

    Either that or have a completely different mechanism to manage them but there is a certain elegance to reusing the slicing architecture to create a primary and backup timing 'slices'.

    Peter


    -----Original Message-----
    From: Netslices [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Stewart Bryant
    Sent: Tuesday, June 20, 2017 2:07 PM
    To: Thomas Nadeau <[e-mail]<mailto:[e-mail]>>; Gert Grammel <[e-mail]<mailto:[e-mail]>>
    Cc: Anton Ivanov <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Daniele Ceccarelli <[e-mail]<mailto:[e-mail]>>
    Subject: Re: [Netslices] Timing service


    Yes, I suspect that timing is an underlying resource provided by the fabric to a slice if needed.

    I raised the subject because timing is so important to 5G, and people are beginning not to trust GPS.

    - Stewart

    On 20/06/2017 18:02, Thomas Nadeau wrote:
    >   I think you, Anton, Stewart and I are in violent agreement then. 8)
    >
    >   —Tom
    >
    >> On Jun 20, 2017:12:40 PM, at 12:40 PM, Gert Grammel <[e-mail]<mailto:[e-mail]>> wrote:
    >>
    >> Hi Tom, Stewart,
    >>
    >> Perhaps my writing was too cryptic. Daniele was actually asking to build timing slices and I was arguing that timing should be left to the underlying physical layer: "… timing accuracy is an attribute of a physical layer that cannot be virtualized/sliced/layered…". If my reading is correct, we seem to share that view.
    >> The maximum a slice can do is to filter for resources that support a given timing requirement if that constraint was given.
    >>
    >> Gert
    >>
    >> On 2017-06-20, 16:33, "Netslices on behalf of Thomas Nadeau" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:
    >>
    >>
    >>          Gert:
    >>
    >>          I think its a bit simpler than that. The slicing use cases require a timing service to be available to it.
    >>     I assume that service must be accurate and reliable to some specification.  However, aside from that
    >>     there does not seem to be any requirement/need to have that service encased within the
    >>     slice.  In essence, virtualization of the 1588 service is not a requirement - running a bare metal
    >>     version that is shared amongst all the slices, etc… seems perfectly acceptable.
    >>
    >>          —Tom
    >>
    >>
    >>> On Jun 20, 2017:8:38 AM, at 8:38 AM, Gert Grammel <[e-mail]<mailto:[e-mail]>> wrote:
    >>>
    >>> Daniele, Anton,
    >>>
    >>> this discussion is basically asking two questions:
    >>> 1) Is timing a service?
    >>> 2) Is timing a characteristic of a slice?
    >>>
    >>> In my view timing accuracy is an attribute of a physical layer that cannot be virtualized/sliced/layered (another aspect is fate sharing). It is reasonable to imagine a "slice" where timing capabilities are enabled by default on all resources. As an example, mobile traffic MAY need to be transported on SyncE capable links only. In such scenario a client would not  require to dynamically instantiate timing on links but could instantiate a "slice" on a set of timing enabled links.
    >>> So it would work similar as with SRLG whereby two slices could be created avoiding fate sharing whereby it is the physical topology dictating the fate, not the number of virtualized connections carried.
    >>>
    >>> Thoughts?
    >>>
    >>> Gert
    >>>
    >>> P.S.: with slice I mean constructs like described in
    >>> https://tools.ietf.org/html/draft-king-teas-applicability-actn-slici
    >>> ng-00
    >>>
    >>>
    >>> On 2017-06-20, 12:57, "Netslices on behalf of Anton Ivanov" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:
    >>>
    >>>    On 20/06/17 11:22, Daniele Ceccarelli wrote:
    >>>> Hi Anton,
    >>>>
    >>>> wouldn't it be possible to have a scenario in which we need synchronization for a slice which is built on top of a non synchronized network?
    >>>    There is a very good Russian saying "нельзя объять необъятное". The
    >>>    English equivalent is "You cannot have your cake and eat it too".
    >>>
    >>>    It is easier to implement sync at the lower layer and share it out than
    >>>    to guarantee that some or all of the virtual overlays will have jitter
    >>>    within the limits required for 4G or onwards sync.
    >>>
    >>>    We cannot cater for every possible requirement. There are reasonable and
    >>>    unreasonable asks.
    >>>
    >>>    That does not mean that there is no time sync aspect to the whole thing.
    >>>    There is an open question of how to share (with all relevant SLA
    >>>    restrictions) a common underlying time sync service securely between
    >>>    multiple slices and what can be the precision for that. One subcase of
    >>>    this may be (note the very big "may") having ONE (just one) sync enabled
    >>>    slice which we can just about guarantee and how do we fan it out at the
    >>>    edge to all consumers as a shared service.
    >>>
    >>>    But definitely not: "Allocate as many time-sync enabled slices on a
    >>>    network as you see fit".
    >>>
    >>>    A.
    >>>
    >>>> Just asking myself it this would make sense.
    >>>>
    >>>> BR
    >>>> Daniele
    >>>>
    >>>> -----Original Message-----
    >>>> From: Netslices [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of
    >>>> Anton Ivanov
    >>>> Sent: martedì 20 giugno 2017 11:44
    >>>> To: [e-mail]<mailto:[e-mail]>
    >>>> Subject: Re: [Netslices] Timing service
    >>>>
    >>>> Err...
    >>>>
    >>>> What does it have to do with slicing?
    >>>>
    >>>> I do not see a scenario where a slice will need to peruse its own special, different from everyone else time synchronization as a common use case.
    >>>>
    >>>> Sure, we can play with sync as a one-off use case to prove, disprove or test particular SLAs and assumptions, but I do not see the network design rationale for per-slice sync to get anywhere near requirements.
    >>>>
    >>>> A.
    >>>>
    >>>>
    >>>> On 16/06/17 12:17, Stewart Bryant wrote:
    >>>>> I was at a 5G seminar yesterday where it was explained that the
    >>>>> timing requirements for 5G are even stricter than they are for
    >>>>> existing systems (which in itself is a challenge).
    >>>>>
    >>>>> They were talking of a 200ns requirement with 20ns expected from 2020.
    >>>>>
    >>>>> The latency requirements for timing services are different from
    >>>>> the latency requirements of other services. They do not need
    >>>>> minimum latency (although that is nice to have) they need latency
    >>>>> consistently and latency symmetry.
    >>>>>
    >>>>> So one question I have is how we transmit the timing service. Does
    >>>>> it go in the underlay and provides time as a service to the NSI,
    >>>>> or does it go in a single slice, or does it go in multiple slices?
    >>>>>
    >>>>> - Stewart
    >>>>>
    >>>>> _______________________________________________
    >>>>> Netslices mailing list
    >>>>> [e-mail]<mailto:[e-mail]>
    >>>>> https://www.ietf.org/mailman/listinfo/netslices
    >>>>>
    >>>> _______________________________________________
    >>>> Netslices mailing list
    >>>> [e-mail]<mailto:[e-mail]>
    >>>> https://www.ietf.org/mailman/listinfo/netslices
    >>>>
    >>>    _______________________________________________
    >>>    Netslices mailing list
    >>>    [e-mail]<mailto:[e-mail]>
    >>>    https://www.ietf.org/mailman/listinfo/netslices
    >>>
    >>>
    >>> _______________________________________________
    >>> Netslices mailing list
    >>> [e-mail]<mailto:[e-mail]>
    >>> https://www.ietf.org/mailman/listinfo/netslices
    >>     _______________________________________________
    >>     Netslices mailing list
    >>     [e-mail]<mailto:[e-mail]>
    >>     https://www.ietf.org/mailman/listinfo/netslices
    >>
    >>
    >> _______________________________________________
    >> Netslices mailing list
    >> [e-mail]<mailto:[e-mail]>
    >> https://www.ietf.org/mailman/listinfo/netslices
    > _______________________________________________
    > Netslices mailing list
    > [e-mail]<mailto:[e-mail]>
    > https://www.ietf.org/mailman/listinfo/netslices

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


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