Re: [Netslices] Timing service

[Thomas Nadeau <[e-mail]>]

> On Jun 21, 2017:6:51 AM, at 6:51 AM, Stewart Bryant <[e-mail]> wrote:
> 
> 
> So is slicing simply an abstraction?
> 
> If so, then I sense that there are two focii here: the generation of the abstract description of a slice, and the conversion of the abstract view into a practical system that moves, reads and modifies bits.
> 
> A key question is the extent to which the two focii need to be co-located.

	This is generally an exercise for the operator and really has nothing to do with what the IETF would ever specify, so we should just skip it.
The assumption must simply be that components of the service will be virtualized, physical or a mix and will depend on lots of variables that we just 
cannot (or should not) worry about. The bottom line is that we should not assume any one of those things other than what the operator will invoke will 
be done in order to make it work to their specification, which may or may not include performance requirements or regulatory requirements. 

	As Anton said, this is a service description and largely a modeling exercise. 

	—Tom


> 
> - Stewart
> 
> 
> On 21/06/2017 10:23, [e-mail] <mailto:[e-mail]> wrote:
>> Hi Stewart, all,
>>  
>> I don’t think so.
>>  
>> Slicing is no more than an abstract view. How that view is built/engineered is actually up to the taste of each operator; further it is an internal business of the operator. From where I sit, I see the slice can be packaged using physical, virtual or a combination thereof. How the slice is structured internally is not visible to third parties. As such, I don’t think we need to overload the terminology with new terms.
>>  
>> Cheers,
>> Med
>>  
>> De : Netslices [mailto:[e-mail] <mailto:[e-mail]>] De la part de Stewart Bryant
>> Envoyé : mercredi 21 juin 2017 10:30
>> À : Gert Grammel; Greg Mirsky; AshwoodsmithPeter
>> Cc : Thomas Nadeau; Anton Ivanov; [e-mail] <mailto:[e-mail]>; Daniele Ceccarelli
>> Objet : Re: [Netslices] Timing service
>>  
>>  
>> 
>> So do we need the terms physical and virtual slice?
>> 
>> 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.
>> 
>> - 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 <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 <https://www.ietf.org/mailman/listinfo/netslices>
>>     >>>>>
>>     >>>> _______________________________________________
>>     >>>> Netslices mailing list
>>     >>>> [e-mail] <mailto:[e-mail]>
>>     >>>> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>>     >>>>
>>     >>>    _______________________________________________
>>     >>>    Netslices mailing list
>>     >>>    [e-mail] <mailto:[e-mail]>
>>     >>>    https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>>     >>>
>>     >>>
>>     >>> _______________________________________________
>>     >>> Netslices mailing list
>>     >>> [e-mail] <mailto:[e-mail]>
>>     >>> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>>     >>     _______________________________________________
>>     >>     Netslices mailing list
>>     >>     [e-mail] <mailto:[e-mail]>
>>     >>     https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> Netslices mailing list
>>     >> [e-mail] <mailto:[e-mail]>
>>     >> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>>     > _______________________________________________
>>     > Netslices mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> 
>>     _______________________________________________
>>     Netslices mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> 
>> 
>> _______________________________________________
>> Netslices mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>>  
>>  
>