Subject: [Netslices] Timing service

From: Stewart Bryant <[email-masked]>
Date: Fri, 16 Jun 2017 12:17:20 +0100

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 16 Jun 2017 13:43:58 +0000

Hey Stewart, yes, or even tighter depending on what is happening with the air interface, I've heard 100ns in some cases.

Some carriers will distribute time over 10-20 hops from a grand master or pair of grand master clock sources over redundant trees. As a result the time distribution is likely orthogonal to the slice resources although I suppose nothing prevents it from being per slice except the added complexity. However per slice timing would only make sense if the different slices were not sharing the same radios. I assume that when slices are sharing the same radio that the radio would need timing as precise as the most stringent air interface it is generating. Of course we expect to have radios that will do URRLC, eMBB, MMTC, NBIOT and LTE so you really only need one (primary) source of time/frequency for all those air interfaces into that radio.

Yes latency asymmetry is a problem and over 20 hops each little bit of asymmetry in the fiber lengths can add up to a significant error. We have seen fiber tx/rx length differences of 100's of meters in some instances which will wreak havoc with 1588's one way delay estimation (based on RTD/2) when trying to get to the 100ns level of clock synchronization precision.

Peter

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, June 16, 2017 7:17 AM
To: Network Slices <[email-masked]>
Subject: [Netslices] Timing service

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).

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netslices

---

From: "sebastian" <[email-masked]>
Date: Fri, 16 Jun 2017 09:08:07 -0500

Hello, Peter,

Currently, the IMT-2020 round trip latency bound target for the URLLC class
of services is 1millisecound, which includes the radio interface.

With the current plans, associated with the new radio specifications, the
timing aspects are expected to be coordinated across the radio sub-layers
and the core network, with both content and context being shifted and
distributed at the edges of network access.

With this background the instantiation potential of a 'network slice', will
be relatively flexible for a service realization in the system as a whole.

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of
AshwoodsmithPeter
Sent: Friday, June 16, 2017 8:44 AM
To: Stewart Bryant <[email-masked]>; Network Slices
<[email-masked]>
Subject: Re: [Netslices] Timing service

Hey Stewart, yes, or even tighter depending on what is happening with the
air interface, I've heard 100ns in some cases.

Some carriers will distribute time over 10-20 hops from a grand master or
pair of grand master clock sources over redundant trees. As a result the
time distribution is likely orthogonal to the slice resources although I
suppose nothing prevents it from being per slice except the added
complexity. However per slice timing would only make sense if the different
slices were not sharing the same radios. I assume that when slices are
sharing the same radio that the radio would need timing as precise as the
most stringent air interface it is generating. Of course we expect to have
radios that will do URRLC, eMBB, MMTC, NBIOT and LTE so you really only need
one (primary) source of time/frequency for all those air interfaces into
that radio.

Yes latency asymmetry is a problem and over 20 hops each little bit of
asymmetry in the fiber lengths can add up to a significant error. We have
seen fiber tx/rx length differences of 100's of meters in some instances
which will wreak havoc with 1588's one way delay estimation (based on RTD/2)
when trying to get to the 100ns level of clock synchronization precision.

Peter

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Stewart
Bryant
Sent: Friday, June 16, 2017 7:17 AM
To: Network Slices <[email-masked]>
Subject: [Netslices] Timing service

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 16 Jun 2017 14:26:52 +0000

Hey Sebastian, 

I believe you are confusing latency for the data (as you say 1-2ms for URRLC) and latency variation for the measurement of one way delay. As you correctly point out there are methods under study to get those end to end data delays down including content and state distribution in the packet cores closer to the edge, smaller OFDM frames etc... however..

Stewart's question relates to the latency variation and its impacts on being able to set clocks at different locations that are synchronized to within a few hundred nanoseconds of each other. Essentially the hop by hop latency variation is a source of error when you set your clock relative to another clock based on computing that one way delay = 1/2 the round trip delay ... which is what 1588v2 does.

GPS is one option but of course we can't use GPS everywhere and it won't work indoors. Currently the world's biggest operators having timing chains approaching 20 hops. Each hop sets its clock relative to the previous hop by subtracting 1/2 RTD from the time it receives the message.. hence the cumulative error.

My point was that I don't think you want a 1588 instance per slice but likely you want one or two instances per physical infrastructure since that would be simpler and also that the radios for multiple slices are likely common in many cases and therefore had a requirement for a primary and backup clock source which is as precise as the most stringent air interface (slice) they have to deal with at any particular time. 

I believe we have some good public materials that I will dig up the links to and share. 

Cheers

Peter

-----Original Message-----
From: sebastian [mailto:[email-masked]] 
Sent: Friday, June 16, 2017 10:08 AM
To: AshwoodsmithPeter <[email-masked]>; 'Stewart Bryant' <[email-masked]>; 'Network Slices' <[email-masked]>
Subject: RE: [Netslices] Timing service

Hello, Peter,

Currently, the IMT-2020 round trip latency bound target for the URLLC class of services is 1millisecound, which includes the radio interface.

With the current plans, associated with the new radio specifications, the timing aspects are expected to be coordinated across the radio sub-layers and the core network, with both content and context being shifted and distributed at the edges of network access.

With this background the instantiation potential of a 'network slice', will be relatively flexible for a service realization in the system as a whole.

Many thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of AshwoodsmithPeter
Sent: Friday, June 16, 2017 8:44 AM
To: Stewart Bryant <[email-masked]>; Network Slices <[email-masked]>
Subject: Re: [Netslices] Timing service

Peter

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, June 16, 2017 7:17 AM
To: Network Slices <[email-masked]>
Subject: [Netslices] Timing service

- Stewart

---

From: "sebastian" <[email-masked]>
Date: Sat, 17 Jun 2017 10:13:32 -0500

Hello, Stewart,

Yes, there are two aspects:
1. Round-trip latency bound targets for the most latency sensitive service
that fall within the category of URLLC
2. Clock synchronization offset induced latency variations, which result
from different sources of clock reference, across different serving domains.

Solution strategies:
a) To satisfy item 1, above the an appropriate allocation of resources and
functions, would be required to instantiate a corresponding network slice.
b) To mitigate the impact of item 2, with respect to performance and any
related SLAs (Service Level Agreements), the participating domains in the
instantiation of a corresponding network slice, would be required to
synchronize the different reference clocks 'a priori' as part of the
management and orchestration procedures. (e.g. GPS tec., for indoors
beacons, and relay methods can be used to relay GPS signals.)

Since timing synchronization, across spatially distributed entities, can be
imagined as a physical phenomenon, it would not be a candidate for
virtualization.
Hence, timing synchronization would be physical process that underlies the
instantiation of any 'network slice' for supporting any extremely
low-latency service, in the 5G ecosystem.

Many  thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Stewart
Bryant
Sent: Friday, June 16, 2017 6:17 AM
To: Network Slices <[email-masked]>
Subject: [Netslices] Timing service

- Stewart

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 17 Jun 2017 12:32:21 -0500

Hi Sebastian,
for #2, I think, to improve clock synchronization may use on-path support
measuring residence time through traversed nodes. I can refer to RFC 8169
which defines transport of PTP messages combined with residence time
measurement in MPLS network.
I agree that high quality clock synchronization is rather physical than
virtual element. Though, for some applications that do not require high
quality clock synchronization, it may be part of NSi resource.

Regards,
Greg

---

From: "sebastian" <[email-masked]>
Date: Sat, 17 Jun 2017 13:26:37 -0500

Hello, Greg,

Yes, for on-path measurement,  techniques such as the one you mentioned would be appropriate.

Agree that for relatively relaxed latency bound applications, the cock reference could be a part of network slice instantiation, while for ultra-low-latency bound applications, the clock references could be synchronized through an underlying physical mediation scheme.

Many thanks.

    Sebastian

From: Greg Mirsky [mailto:[email-masked]] 
Sent: Saturday, June 17, 2017 12:32 PM
To: [email-masked]
Cc: Stewart Bryant <[email-masked]>; Network Slices <[email-masked]>
Subject: Re: [Netslices] Timing service

Hi Sebastian,

for #2, I think, to improve clock synchronization may use on-path support measuring residence time through traversed nodes. I can refer to RFC 8169 which defines transport of PTP messages combined with residence time measurement in MPLS network.

I agree that high quality clock synchronization is rather physical than virtual element. Though, for some applications that do not require high quality clock synchronization, it may be part of NSi resource.

Regards,

Greg

On Sat, Jun 17, 2017 at 10:13 AM, sebastian <[email-masked] <mailto:[email-masked]> > wrote:

Hello, Stewart,

Solution strategies:

Many  thanks.
-Sebastian

-----Original Message-----
From: Netslices [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Stewart
Bryant
Sent: Friday, June 16, 2017 6:17 AM
To: Network Slices <[email-masked] <mailto:[email-masked]> >
Subject: [Netslices] Timing service

- Stewart

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

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

---

From: GENG Liang <[email-masked]>
Date: Sun, 18 Jun 2017 16:08:57 +0000

Hi Stewart,

I think you have raised a very interesting topic.

Since the Time/clock synchronization acts as fundamentals to forwarding plane of a specific network element and it normally acts as end-to-end. I think the reality is that it is hard to separate this ability as we separate the others to offer a XaaS - that would mean a physical network element may need to maintain various system times to offer the differentiated timing service - weird and complex.

I think it would make sense to regard 1588v2 network as a separate NSI - but I think the reality is - it already is an isolated domain. This forms a fundamental end-to-end timing service capability and can be offered by indicating "worst jitter" according to the topology of the created NSI.

Best wishes
Liang

________________________________
Liang GENG
China Mobile Research Institute

From: Stewart Bryant<mailto:[email-masked]>
Date: 2017-06-16 19:17
To: Network Slices<mailto:[email-masked]>
Subject: [Netslices] Timing service

- Stewart

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 20 Jun 2017 10:44:28 +0100

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:
> requirements for 5G are even stricter than they are for existing 
> systems (which in itself is a challenge).
>
> 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
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 20 Jun 2017 10:22:19 +0000

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?

Just asking myself it this would make sense.

BR
Daniele  

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Anton Ivanov
Sent: martedì 20 giugno 2017 11:44
To: [email-masked]
Subject: Re: [Netslices] Timing service

Err...

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.

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 20 Jun 2017 11:57:34 +0100

> 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.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 08:34:41 -0400

I agree. It looks like we are again over-rotating on the 5G/wireless requirements. 

	—Tom

> On Jun 20, 2017:5:44 AM, at 5:44 AM, Anton Ivanov <[email-masked]> wrote:
> 
> Err...
>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 08:38:16 -0400

Wouldn’t sync be a service that should be made available to any given “slice” ?
As we have found in the past, virtualization of things that really should
be run on bare metal (i.e.: that need direct allocation of physical resources) to function
properly and at scale, is not a good idea.

	—Tom

> On Jun 20, 2017:6:22 AM, at 6:22 AM, Daniele Ceccarelli <[email-masked]> wrote:
> 
> Hi Anton,
>

---

From: Gert Grammel <[email-masked]>
Date: Tue, 20 Jun 2017 12:38:35 +0000

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-slicing-00 

On 2017-06-20, 12:57, "Netslices on behalf of Anton Ivanov" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    
    A.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 20 Jun 2017 12:41:59 +0000

>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.

I think this makes sense.

BR
Daniele  

-----Original Message-----
From: Anton Ivanov [mailto:[email-masked]] 
Sent: martedì 20 giugno 2017 12:58
To: Daniele Ceccarelli <[email-masked]>; [email-masked]
Subject: Re: [Netslices] Timing service

> 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.

>> 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).
>>
>> latency (although that is nice to have) they need latency 
>> consistently and latency symmetry.
>>

---

From: Anton Ivanov <[email-masked]>
Date: Tue, 20 Jun 2017 13:42:15 +0100

On 20/06/17 13:38, Gert Grammel wrote:
> 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.

It is also possible (and much easier from an engineering perspective) to 
consider timing a service and "add it" to a slice only on at the last 
hop(s) and only if requested.

A.

> 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.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 10:33:28 -0400

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 <[email-masked]> wrote:
> 
> Daniele, Anton,
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 Jun 2017 15:47:17 +0100

On 20/06/2017 15:33, Thomas Nadeau wrote:
> I assume that service must be accurate and reliable to some specification.
.. and in some cases certified for regulatory reasons.
> However, aside from that

That is something we need to hear from the operators.

Stewart

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jun 2017 09:51:28 -0500

Hi Tom,
while 5G and IIoT would require high accuracy of clock synchronization some
other applications of netslicing, I'd imagine, may have more relaxed
requirements. Relaxed to the level that may not require use of 1588 but be
sufficiently fulfilled by NTP. And NTP may, may be part of netslice.

Regards,
Greg

On Tue, Jun 20, 2017 at 9:33 AM, Thomas Nadeau <[email-masked]>
wrote:

> > 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-slicing-00
> >
> >
> > On 2017-06-20, 12:57, "Netslices on behalf of Anton Ivanov" <
> [email-masked] on behalf of [email-masked]>
> wrote:
> >
> >> 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?
> >
> special, different from everyone else time synchronization as a common use
> case.
> >>
> test particular SLAs and assumptions, but I do not see the network design
> rationale for per-slice sync to get anywhere near requirements.
> >>
> >> A.
> >>
> >>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 Jun 2017 15:55:49 +0100

> English equivalent is "You cannot have your cake and eat it too".

Interestingly  Google thinks it says: "You can not embrace the vast", 
and every one of the internet language translators says something 
different but very similar.

S

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jun 2017 10:01:10 -0500

Hi Stewart, et. al,
obtaining SW timestamp even with 1588-synchronized clocks may become
congestion point that would affect clock quality for a slice. Thus, clock
may be considered resource shared by hosted netslices.

Regards,
Greg

On Tue, Jun 20, 2017 at 9:47 AM, Stewart Bryant <[email-masked]>
wrote:

>>         I think its a bit simpler than that. The slicing use cases
>> require a timing service to be available to it.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 20 Jun 2017 15:04:26 +0000

I agree with Greg and with what Anton said before.

I expect synchronization to be provided by the underlying network. If so any slice can use it. If it is not so it MAY be possible to provide synchronization on top of the underlying network (in some way, and which will have obviously worse performances) on a per slice basis. Since it was not provided by the network I don’t expect many slices to need it nor to need super high performances, otherwise the network was not properly designed.

BR
Daniele

From: Greg Mirsky [mailto:[email-masked]]
Sent: martedì 20 giugno 2017 16:51
To: Thomas Nadeau <[email-masked]>
Cc: Gert Grammel <[email-masked]>; Anton Ivanov <[email-masked]>; [email-masked]; Daniele Ceccarelli <[email-masked]>
Subject: Re: [Netslices] Timing service

Hi Tom,
while 5G and IIoT would require high accuracy of clock synchronization some other applications of netslicing, I'd imagine, may have more relaxed requirements. Relaxed to the level that may not require use of 1588 but be sufficiently fulfilled by NTP. And NTP may, may be part of netslice.

Regards,
Greg

On Tue, Jun 20, 2017 at 9:33 AM, Thomas Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

        Gert:

        —Tom

> On Jun 20, 2017:8:38 AM, at 8:38 AM, Gert Grammel <[email-masked]<mailto:[email-masked]>> wrote:
>
> Daniele, Anton,
>
> On 2017-06-20, 12:57, "Netslices on behalf of Anton Ivanov" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>> From: Netslices [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Anton Ivanov
>> To: [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>    [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

---

From: thomas nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 11:04:55 -0400

> On Jun 20, 2017, at 10:47 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 

Correct. The point I was making is that until someone says something, it is not a requirement.

tom

---

From: thomas nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 11:05:56 -0400

Then why not just use the operator's likely already functional NTP service?

tom

> On Jun 20, 2017, at 10:51 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Tom,
>> On Tue, Jun 20, 2017 at 9:33 AM, Thomas Nadeau <[email-masked]> wrote:
>> 
>>         Gert:
>>

---

From: thomas nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 11:07:09 -0400

Slavic languages have a lot of colloquialisms and implied meanings that are not easily translated directly. ;)

tom 

> On Jun 20, 2017, at 10:55 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> Interestingly  Google thinks it says: "You can not embrace the vast", and every one of the internet language translators says something different but very similar.
> 
> S
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 20 Jun 2017 15:13:59 +0000

Few more thoughts.

In order to get the degree of precision we are talking about it implies that boundary clocks are required for retiming at each switch/router from the grand master to the radios. These intermediate hops (10s' of them) may/will be invisible to a slice and exposing them just for the sake of timing and creating a redundant parallel set of boundary clocks would seem overly complex. 

It seems more straight forward to have one or two bare metal clock distribution trees with boundary clocks at each node that is invisible to the slices but which provides the resultant time to the slice where needed and possibly jittered to reduce its precision to the level being paid for by that slice at that location.

The alternative is pretty scary frankly...

So far I've not heard operators ask about timing in a slice.

If lower precision is required (no boundary clocks) then PTP etc. could run within a slice I suppose since its end to end.

Peter

>> 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.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jun 2017 10:17:48 -0500

AFAIK, NTP still cannot achieve 1588 quality of clock synchronization.

Regards,
Greg

On Tue, Jun 20, 2017 at 10:05 AM, thomas nadeau <[email-masked]>
wrote:

> while 5G and IIoT would require high accuracy of clock synchronization
> some other applications of netslicing, I'd imagine, may have more relaxed
>> Anton Ivanov
>> >> 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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jun 2017 10:19:12 -0500

But this is not the case. Automated translation is pretty close to the
original.

Regards,
Greg

On Tue, Jun 20, 2017 at 10:07 AM, thomas nadeau <[email-masked]>
wrote:

> and every one of the internet language translators says something different
> but very similar.
> >
> > S
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 11:22:42 -0400

Then use their existing 1588 service.

	—Tom

> On Jun 20, 2017:11:17 AM, at 11:17 AM, Greg Mirsky <[email-masked]> wrote:
> 
> On Tue, Jun 20, 2017 at 10:05 AM, thomas nadeau <[email-masked] <mailto:[email-masked]>> wrote:
> On Jun 20, 2017, at 10:51 AM, Greg Mirsky <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi Tom,
>> On Tue, Jun 20, 2017 at 9:33 AM, Thomas Nadeau <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>         Gert:
>> 
>> > On Jun 20, 2017:8:38 AM, at 8:38 AM, Gert Grammel <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> > Daniele, Anton,
>> >
>> > P.S.: with slice I mean constructs like described in https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-00 <https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-00>
>> >
>> >
>> > On 2017-06-20, 12:57, "Netslices on behalf of Anton Ivanov" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >> From: Netslices [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Anton Ivanov
>> >> To: [email-masked] <mailto:[email-masked]>
>> >>> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> >>>
>> >> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> >>
>> >
>> >    https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> >
>> >
>> > https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> 
>> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>> 
>> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>
>

---

From: Gert Grammel <[email-masked]>
Date: Tue, 20 Jun 2017 16:20:01 +0000

Stuart,

I am a bit puzzeled:
You wrote: "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."
I wrote:  "In my view timing accuracy is an attribute of a physical layer that cannot be virtualized/sliced/layered"

Are we essentially saying the same?

Thanks

Gert

On 2017-06-20, 17:04, "thomas nadeau" <[email-masked]> wrote:

    
    
    tom

---

From: Gert Grammel <[email-masked]>
Date: Tue, 20 Jun 2017 16:40:38 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    	Gert:

    	—Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 13:02:01 -0400

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 <[email-masked]> wrote:
> 
> Hi Tom, Stewart,
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 20 Jun 2017 11:02:26 -0700

+1

There’s no reason (nor technical, neither business) to provide timing per slice.

It should be provided as part of infrastructure, similar to basic connectivity. 

Cheers,

Jeff

From: Netslices <[email-masked]> on behalf of Daniele Ceccarelli <[email-masked]>
Date: Tuesday, June 20, 2017 at 08:04
To: Greg Mirsky <[email-masked]>, Thomas Nadeau <[email-masked]>
Cc: Gert Grammel <[email-masked]>, Anton Ivanov <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netslices] Timing service

BR
Daniele  

Hi Tom,

Regards,

Greg 

        Gert:

        —Tom

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 20 Jun 2017 19:06:39 +0100

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 20 Jun 2017 18:52:03 +0000

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:[email-masked]] On Behalf Of Stewart Bryant
Sent: Tuesday, June 20, 2017 2:07 PM
To: Thomas Nadeau <[email-masked]>; Gert Grammel <[email-masked]>
Cc: Anton Ivanov <[email-masked]>; [email-masked]; Daniele Ceccarelli <[email-masked]>
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:
>>>>> 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 
>>>>> 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
>>>>>

---

From: Gert Grammel <[email-masked]>
Date: Tue, 20 Jun 2017 19:13:36 +0000

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" <[email-masked]> wrote:

    
    Peter

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

    
    - Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 20 Jun 2017 19:54:04 +0000

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:[email-masked]] 
Sent: Tuesday, June 20, 2017 3:14 PM
To: AshwoodsmithPeter <[email-masked]>; Stewart Bryant <[email-masked]>; Thomas Nadeau <[email-masked]>
Cc: Anton Ivanov <[email-masked]>; [email-masked]; Daniele Ceccarelli <[email-masked]>
Subject: Re: [Netslices] Timing service

Peter,

Gert

    
    
    Peter

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

    
    - Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Jun 2017 15:57:38 -0400

> On Jun 20, 2017:2:52 PM, at 2:52 PM, AshwoodsmithPeter <[email-masked]> 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’.

	True except for the reality of virtualization of such things.  The devil is in the details, and 
more often than not, it is simpler and cheaper when you consider the total cost of operation to simply do 
a bare metal deployment.  In this case, since NTP and 1588 have been functional for years in
a bare metal environment and will continue to do so, it just makes sense to me anyways, to focus
on other things than open this can of worms.

	—Tom

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jun 2017 15:03:19 -0500

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 <
[email-masked]> wrote:

> 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.
>
> 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
>
> To: AshwoodsmithPeter <[email-masked]>; Stewart Bryant <
> [email-masked]>; Thomas Nadeau <[email-masked]>
> Cc: Anton Ivanov <[email-masked]>; [email-masked];
> Daniele Ceccarelli <[email-masked]>
>     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
>
>
> Stewart Bryant
>     Cc: Anton Ivanov <[email-masked]>; [email-masked];
> Daniele Ceccarelli <[email-masked]>
>     >> 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" <
> [email-masked] on behalf of [email-masked]> wrote:
>     >>
>     >>
>     >>          Gert:
>     >>
>     >>> 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
>     >>> https://tools.ietf.org/html/draft-king-teas-applicability-
> actn-slici
>     >>> ng-00
>     >>>
>     >>>
>     >>>> 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.
>     >>>>
>     >>>>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 20 Jun 2017 20:08:11 +0000

>It may be that certain quality of clock synchronization is indeed physical property of the underlay.

I think that is unavoidably true since the errors in 1588 are physically induced (asymmetry, temperature, ASIC/data path et.) and the order of those errors are getting close to the precision that is being asked for when aggregated over 10-20 hops.

Peter

> Greg

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

Peter

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

Peter,

Gert

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

    Peter

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

    - Stewart

    On 20/06/2017 18:02, Thomas Nadeau wrote:
    >> On Jun 20, 2017:12:40 PM, at 12:40 PM, Gert Grammel <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >> Hi Tom, Stewart,
    >>
    >> On 2017-06-20, 16:33, "Netslices on behalf of Thomas Nadeau" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
    >>
    >>
    >>          Gert:
    >>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 20 Jun 2017 15:08:30 -0500

Hi Tom,
1588 with HW support in the data plane is more suitable for timing of the
data plane. Since NTP is control plane protocol, synchronizing data plane
off it usually introduces local queuing and thus worsens clock
synchronization in the data plane. AFAIK, NTP is not capable to achieve the
same level, precision of clock synchronization as 1588. Though I agree, and
I've noted that earlier, in some scenarios NTP may be good-enough.

Regards,
Greg

On Tue, Jun 20, 2017 at 2:57 PM, Thomas Nadeau <[email-masked]>
wrote:

> 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
> >
> >
> >>> The maximum a slice can do is to filter for resources that support a
> given timing requirement if that constraint was given.
> >>>
> >>> Gert
> >>>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 20 Jun 2017 20:19:13 +0000

Yup, they are functional but my understanding is they will need more work to get the precision up over the required number of hops. As a result total cost of operation at the new required tolerances could change those cost equations and therefore the desirability (or not) of further automation.

Peter

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

> 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.…

	True except for the reality of virtualization of such things.  The devil is in the details, and more often than not, it is simpler and cheaper when you consider the total cost of operation to simply do a bare metal deployment.  In this case, since NTP and 1588 have been functional for years in a bare metal environment and will continue to do so, it just makes sense to me anyways, to focus on other things than open this can of worms.

	—Tom

>>>> https://tools.ietf.org/html/draft-king-teas-applicability-actn-slic
>>>> i
>>>> ng-00
>>>> 
>>>> 
>>>>>> 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
>>>>>>

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 20 Jun 2017 20:44:24 +0000

Hi Peter,

In the light of what you said below, would you concider grand master and boundary clocks as SFs/NFs and use SF/NF aware TE topology model describing physical or abstract network to define adequately constrained trees connecting the clocks?

Thanks,
Igor
From:AshwoodsmithPeter
To:Gert Grammel,Stewart Bryant,Thomas Nadeau,
Cc:Anton Ivanov,[email-masked],Daniele Ceccarelli,
Date:2017-06-20 15:54:50
Subject:Re: [Netslices] Timing service

Hey Gert,

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

    On 20/06/2017 18:02, Thomas Nadeau wrote:
    >    ―Tom
    >>           ―Tom

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 20 Jun 2017 21:04:54 +0000

Hey Igor,

Yes, I suppose that is a functionally correct abstraction but I make no claims on the practicality. Probably worth discussing with real clock experts.

Peter

From: Igor Bryskin
Sent: Tuesday, June 20, 2017 4:44 PM
To: AshwoodsmithPeter <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Netslices] Timing service

Hi Peter,

Thanks,
Igor
From:AshwoodsmithPeter

Hey Gert,

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

    On 20/06/2017 18:02, Thomas Nadeau wrote:
    >> On 2017-06-20, 16:33, "Netslices on behalf of Thomas Nadeau" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:
    >>
    >>
    >>           Gert:
    >>
    >>> On 2017-06-20, 12:57, "Netslices on behalf of Anton Ivanov" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:
    >>>

---

From: Gert Grammel <[email-masked]>
Date: Tue, 20 Jun 2017 21:23:54 +0000

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 <[email-masked]>
Date: Tuesday, 20. June 2017 at 22:03
To: AshwoodsmithPeter <[email-masked]>
Cc: Gert Grammel <[email-masked]>, Stewart Bryant <[email-masked]>, Thomas Nadeau <[email-masked]>, Anton Ivanov <[email-masked]>, "[email-masked]" <[email-masked]>, Daniele Ceccarelli <[email-masked]>
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

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: Gert Grammel <[email-masked]>
Date: Tue, 20 Jun 2017 21:29:25 +0000

Peter,

Appreciate sharing this observation. Indeed my first question when it cam eto defining what a "slice" would be was to ask what do we *not* consider being a slice. Timing is indeed an interesting example. To me a timing slice does not exist since a slice has to be virtual and timing is bound to the HW. I recognize others have different ideas, but by using the same name for different contexts doesn’t help. I found https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-00 to be a good starting point for a definition. Not perfect but a start.

Gert

On 2017-06-20, 21:54, "AshwoodsmithPeter" <[email-masked]> wrote:

    Hey Gert,

    

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

    Gert

        
        
        Peter

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

        
        - Stewart

---

From: Leeyoung <[email-masked]>
Date: Tue, 20 Jun 2017 22:06:49 +0000

Gert,

I agree.

Young

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

Peter,

Gert

    Hey Gert,

    

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

    Gert

        
        
        Peter

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

        
        - Stewart

---

From: GENG Liang <[email-masked]>
Date: Wed, 21 Jun 2017 04:18:23 +0000

Gert

I am not sure what you mean by "virtualized" in the scope of slicing. Is it logical isolation or the virtualization in NFV scope?

Though there has not been a solid definition of slice, but IMHO the dedication a network slice provide may consist of both logical (virtualized of not) and physical isolations, standalone or hybrid.

Taking timing service as an example
- ToD+1PPS is a physical dedicating - Conceptually it is a "hard" dedicated physical "timing service slice"
-1588 can have certain dedication, i.e. in Ethernet MAC layer to avoid congestion with data traffic - Conceptually it is a "soft" dedicated logical (but not virtualized) "timing service slice"

Though I am trying to make use of the slicing concept, I am actually not so sure if there is necessity for timing service to wear the network slicing hat given the existing manner of dedication. However, i do agree that timing service is an underlay which should serve whatever slice is running over it and I don't see the value of providing differentiated timing services from operator's point of view at this moment - we will anyway provide the timing service to support 5G requirement which is considered most critical. Hence share it for all the data planes will be most economical choice .

Best wishes
Liang

From: Gert Grammel<mailto:[email-masked]>
Date: 2017-06-21 03:13
To: AshwoodsmithPeter<mailto:[email-masked]>; Stewart Bryant<mailto:[email-masked]>; Thomas Nadeau<mailto:[email-masked]>
CC: Anton Ivanov<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli<mailto:[email-masked]>
Subject: Re: [Netslices] Timing service
Peter,

Gert

    Peter

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

    - Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Jun 2017 09:30:25 +0100

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 <[email-masked]>
> *Date: *Tuesday, 20. June 2017 at 22:03
> *To: *AshwoodsmithPeter <[email-masked]>
> *Cc: *Gert Grammel <[email-masked]>, Stewart Bryant 
> <[email-masked]>, Thomas Nadeau <[email-masked]>, 
> Anton Ivanov <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Daniele Ceccarelli <[email-masked]>
> *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 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hey Gert,
>
>     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.
>
>     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
>
>
>     To: AshwoodsmithPeter <[email-masked]
>     <mailto:[email-masked]>>; Stewart Bryant
>     <[email-masked] <mailto:[email-masked]>>;
>     Thomas Nadeau <[email-masked]
>     <mailto:[email-masked]>>
>     Cc: Anton Ivanov <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; Daniele Ceccarelli
>     <[email-masked]
>     <mailto:[email-masked]>>
>     On 2017-06-20, 20:52, "AshwoodsmithPeter"
>     <[email-masked]
>     <mailto:[email-masked]>> 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
>
>
>         From: Netslices [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Stewart Bryant
>         To: Thomas Nadeau <[email-masked]
>     <mailto:[email-masked]>>; Gert Grammel
>     <[email-masked] <mailto:[email-masked]>>
>         Cc: Anton Ivanov <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; Daniele Ceccarelli
>     <[email-masked]
>     <mailto:[email-masked]>>
>         >> On Jun 20, 2017:12:40 PM, at 12:40 PM, Gert Grammel
>     <[email-masked] <mailto:[email-masked]>> 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" <[email-masked]
>     <mailto:[email-masked]> on behalf of
>     [email-masked] <mailto:[email-masked]>> 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
>         >>     slice.  In essence, virtualization of the 1588 service
>     is not a requirement - running a bare metal
>         >>> On Jun 20, 2017:8:38 AM, at 8:38 AM, Gert Grammel
>     <[email-masked] <mailto:[email-masked]>> wrote:
>         >>>
>         >>> Daniele, Anton,
>         >>>
>         >>> 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
>         >>>
>         >>> On 2017-06-20, 12:57, "Netslices on behalf of Anton
>     Ivanov" <[email-masked]
>     <mailto:[email-masked]> on behalf of
>     [email-masked]
>     <mailto:[email-masked]>> wrote:
>         >>>
>         >>>> 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?
>         >>>> From: Netslices [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of
>         >>>> Anton Ivanov
>         >>>> 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.
>         >>>>
>         >>>>
>     <https://www.ietf.org/mailman/listinfo/netslices>
>         >>>>>
>     <https://www.ietf.org/mailman/listinfo/netslices>
>         >>>>
>     <https://www.ietf.org/mailman/listinfo/netslices>
>         >>>
>         >>>
>     <https://www.ietf.org/mailman/listinfo/netslices>
>     <https://www.ietf.org/mailman/listinfo/netslices>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Jun 2017 09:38:16 +0100

On 21/06/2017 05:18, GENG Liang wrote:
> I don't see the value of providing differentiated timing services from 
> operator's point of view at this moment

I was wondering about certified time, where there were financial or 
regulatory implications. Would operators want to be encumbered with the 
implications (audits, forensics, court cases etc) or would they simply 
provide a pipe and leave that to the customer.

- Stewart

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 21 Jun 2017 10:18:15 +0100

> 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.

>> 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 
>>     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
>>     The fact the resources are physical as opposed to virtual does
>>     not make that much difference really and of course some normal
>>     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
>>
>>
>>         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
>>
>>
>>         I raised the subject because timing is so important to 5G,
>>     and people are beginning not to trust GPS.
>>
>>         - Stewart
>>
>>     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.
>>     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
>>     to dynamically instantiate timing on links but could instantiate
>>     a "slice" on a set of timing enabled links.
>>         >>>> 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.
>>         >>>>

---

From: <[email-masked]>
Date: Wed, 21 Jun 2017 09:23:08 +0000

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:[email-masked]] De la part de Stewart Bryant
Envoyé : mercredi 21 juin 2017 10:30
À : Gert Grammel; Greg Mirsky; AshwoodsmithPeter
Cc : Thomas Nadeau; Anton Ivanov; [email-masked]; Daniele Ceccarelli
Objet : Re: [Netslices] Timing service

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

Gert

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

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: Anton Ivanov <[email-masked]>
Date: Wed, 21 Jun 2017 10:43:50 +0100

On 21/06/17 10:23, [email-masked] 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.
>

That is the "modelling view" and limiting the WG scope to modelling it. 
If we decide to do so, I am in full agreement.

If, however, we decide to do anything beyond modelling, then some scope 
limitations should be put in place so it does not end up as a run-away 
task to "control the known world".

A.

> Cheers,
>
> Med
>
> *De :*Netslices [mailto:[email-masked]] *De la part de* 
> Stewart Bryant
> *Envoyé :* mercredi 21 juin 2017 10:30
> *À :* Gert Grammel; Greg Mirsky; AshwoodsmithPeter
> *Cc :* Thomas Nadeau; Anton Ivanov; [email-masked]; Daniele Ceccarelli
> *Objet :* Re: [Netslices] Timing service
>
>     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
>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     *Cc: *Gert Grammel <[email-masked]>
>     <mailto:[email-masked]>, Stewart Bryant
>     <[email-masked]> <mailto:[email-masked]>,
>     Thomas Nadeau <[email-masked]>
>     <mailto:[email-masked]>, Anton Ivanov
>     <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>, Daniele Ceccarelli
>     <[email-masked]>
>     <mailto:[email-masked]>
>     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
>
>         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.
>
>         (non-timing) slices would require physical resources possibly
>         end to end.
>
>         orchestrator where the resulting slice provides services to
>         all the other slices.
>
>         Peter
>
>
>             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'.
>
>             Yes, I suspect that timing is an underlying resource
>         provided by the fabric to a slice if needed.
>
>             >> 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
>             >> The maximum a slice can do is to filter for resources
>         that support a given timing requirement if that constraint was
>         given.
>             >>
>             >> 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
>             >>     slice.  In essence, virtualization of the 1588
>         service is not a requirement - running a bare metal
>             >>> 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
>             >>>
>             >>>> 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?
>         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.
>             >>>>
>             >>>>

---

From: GENG Liang <[email-masked]>
Date: Wed, 21 Jun 2017 10:21:57 +0000

Stewart,

Those are very interesting thoughts.

There might be valid case where operator can provide certified time in some scenario with regulatory implications, however,
1. Would the accuracy requirement even higher that 5G RAN (~150ns)? Even it is, I doubt if it is economical for any operator in the world to build such a timing network for this purpose.
2. Are operator ready to take the additional legal responsibility?

I don't have answers now for 2 but I guess not, I would leave that task to some third-party dedicated timing system.

From: Stewart Bryant<mailto:[email-masked]>
Date: 2017-06-21 16:38
To: GENG Liang<mailto:[email-masked]>; Gert Grammel<mailto:[email-masked]>; AshwoodsmithPeter<mailto:[email-masked]>; Thomas Nadeau<mailto:[email-masked]>
CC: Anton Ivanov<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli<mailto:[email-masked]>
Subject: Re: [Netslices] Timing service

- Stewart

---

From: GENG Liang <[email-masked]>
Date: Wed, 21 Jun 2017 10:24:27 +0000

Hi Med

+1 on layer of abstraction + customer transparency

From: [email-masked]<mailto:[email-masked]>
Date: 2017-06-21 17:23
To: Stewart Bryant<mailto:[email-masked]>; Gert Grammel<mailto:[email-masked]>; Greg Mirsky<mailto:[email-masked]>; AshwoodsmithPeter<mailto:[email-masked]>
CC: Thomas Nadeau<mailto:[email-masked]>; Anton Ivanov<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli<mailto:[email-masked]>
Subject: Re: [Netslices] Timing service
Hi Stewart, all,

I don’t think so.

Cheers,
Med

- Stewart

Gert

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 21 Jun 2017 10:35:50 +0000

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,[email-masked]
时间：2017-06-21 17:18:59
主题:Re: [Netslices] Timing service

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.

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

A.

- Stewart

Gert

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Jun 2017 11:51:03 +0100

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.

- Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 21 Jun 2017 07:11:25 -0400

> On Jun 21, 2017:6:51 AM, at 6:51 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 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.
> 

	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, [email-masked] <mailto:[email-masked]> wrote:
>> Hi Stewart, all,
>>  
>> I don’t think so.
>>  
>> De : Netslices [mailto:[email-masked] <mailto:[email-masked]>] De la part de Stewart Bryant
>> Cc : Thomas Nadeau; Anton Ivanov; [email-masked] <mailto:[email-masked]>; Daniele Ceccarelli
>> From: Greg Mirsky <[email-masked]> <mailto:[email-masked]>
>> To: AshwoodsmithPeter <[email-masked]> <mailto:[email-masked]>
>> Cc: Gert Grammel <[email-masked]> <mailto:[email-masked]>, Stewart Bryant <[email-masked]> <mailto:[email-masked]>, Thomas Nadeau <[email-masked]> <mailto:[email-masked]>, Anton Ivanov <[email-masked]> <mailto:[email-masked]>, "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>, Daniele Ceccarelli <[email-masked]> <mailto:[email-masked]>
>> On Tue, Jun 20, 2017 at 2:54 PM, AshwoodsmithPeter <[email-masked] <mailto:[email-masked]>> wrote:
>> Hey Gert,
>> 
>> From: Gert Grammel [mailto:[email-masked] <mailto:[email-masked]>]
>> To: AshwoodsmithPeter <[email-masked] <mailto:[email-masked]>>; Stewart Bryant <[email-masked] <mailto:[email-masked]>>; Thomas Nadeau <[email-masked] <mailto:[email-masked]>>
>> Cc: Anton Ivanov <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Daniele Ceccarelli <[email-masked] <mailto:[email-masked]>>
>> On 2017-06-20, 20:52, "AshwoodsmithPeter" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>     From: Netslices [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Stewart Bryant
>>     To: Thomas Nadeau <[email-masked] <mailto:[email-masked]>>; Gert Grammel <[email-masked] <mailto:[email-masked]>>
>>     Cc: Anton Ivanov <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Daniele Ceccarelli <[email-masked] <mailto:[email-masked]>>
>>     >> On Jun 20, 2017:12:40 PM, at 12:40 PM, Gert Grammel <[email-masked] <mailto:[email-masked]>> wrote:
>>     >>
>>     >> Hi Tom, Stewart,
>>     >>
>>     >> On 2017-06-20, 16:33, "Netslices on behalf of Thomas Nadeau" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>>     >>
>>     >>
>>     >>          Gert:
>>     >>
>>     >>> https://tools.ietf.org/html/draft-king-teas-applicability-actn-slici <https://tools.ietf.org/html/draft-king-teas-applicability-actn-slici>
>>     >>> ng-00
>>     >>>
>>     >>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Jun 2017 12:19:59 +0100

On 21/06/2017 12:11, Thomas Nadeau wrote:
>
>> On Jun 21, 2017:6:51 AM, at 6:51 AM, Stewart Bryant 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>> 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.
>>
> 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.
>

Tom

Which part?

It is in scope for the IETF to modify as necessary the operation of any 
components (for which it is responsible) in the packet layers that 
require change to deliver the required services.

- Stewart

>>> 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
>>>
>>> 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
>>>
>>>     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
>>>
>>>         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
>>>         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
>>>         <[email-masked]
>>>         <mailto:[email-masked]>>; Thomas Nadeau
>>>         <[email-masked] <mailto:[email-masked]>>
>>>         MST's). So the mechanisms that are used to control slices
>>>         can be used to control two bare metal timing 'slices'.
>>>
>>>             I raised the subject because timing is so important to
>>>         5G, and people are beginning not to trust GPS.
>>>
>>>             - Stewart
>>>
>>>         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
>>>         that support a given timing requirement if that constraint
>>>         was given.
>>>             >>
>>>             >> Gert
>>>             >>
>>>             >>     I assume that service must be accurate and
>>>         reliable to some specification.  However, aside from that
>>>         (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.
>>>         we need synchronization for a slice which is built on top of
>>>         a non synchronized network?
>>>             >>>> 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.
>>>             >>>>
>>>             >>>>

---

From: <[email-masked]>
Date: Wed, 21 Jun 2017 11:35:37 +0000

Hi Anton,

Please see inline.

Cheers,
Med

De : Anton Ivanov [mailto:[email-masked]]
Envoyé : mercredi 21 juin 2017 11:44
À : BOUCADAIR Mohamed IMT/OLN; Stewart Bryant; Gert Grammel; Greg Mirsky; AshwoodsmithPeter
Cc : Thomas Nadeau; [email-masked]; Daniele Ceccarelli
Objet : Re: [Netslices] Timing service

On 21/06/17 10:23, [email-masked]<mailto:[email-masked]> wrote:
Hi Stewart, all,

I don’t think so.

That is the "modelling view" and limiting the WG scope to modelling it. If we decide to do so, I am in full agreement.
[Med] As you can read in the gap-analysis draft, a key deliverable is the so called NSRS (netslice resource specification); that is a modeling effort.

If, however, we decide to do anything beyond modelling, then some scope limitations should be put in place so it does not end up as a run-away task to "control the known world".
[Med] I fully agree.

A.

Cheers,
Med

Cc : Thomas Nadeau; Anton Ivanov; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli

- Stewart

Gert

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: <[email-masked]>
Date: Wed, 21 Jun 2017 11:45:11 +0000

Re-,

Please see inline.

Cheers,
Med

De : Stewart Bryant [mailto:[email-masked]]
Envoyé : mercredi 21 juin 2017 12:51
À : BOUCADAIR Mohamed IMT/OLN; Gert Grammel; Greg Mirsky; AshwoodsmithPeter
Cc : Thomas Nadeau; Anton Ivanov; [email-masked]; Daniele Ceccarelli
Objet : Re: [Netslices] Timing service

So is slicing simply an abstraction?
[Med] It is more than that. But, IMHO, a key piece that can be worked within the IETF is the modelling part (and some OAM features).

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.
[Med] How a slice is converted/mapped into actual network actions is really deployment-specific. I don’t think we need to cover those aspects in the context of the netslices IETF effort.

- Stewart

On 21/06/2017 10:23, [email-masked]<mailto:[email-masked]> wrote:
Hi Stewart, all,

I don’t think so.

Cheers,
Med

- Stewart

Gert

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 21 Jun 2017 13:37:50 +0000

Stewart, I don’t think physical or virtual is much help.

Slices consist of resources picked from sets of resources some of which can be physical and some of which can be logical.
You may have a dedicated CPU core which is physical but share the connectivity which is logical. The inverse is true in that you may have shared CPU resources but dedicated connectivity. Both are perfectly valid parts of a slice as are the other two combinations. Anyway I never thought of physical or logical as an important part of the definition but they are important parts of the QOS v.s. cost of implementation of course.

Peter

From: Netslices [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, June 21, 2017 4:30 AM
To: Gert Grammel <[email-masked]>; Greg Mirsky <[email-masked]>; AshwoodsmithPeter <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>; Anton Ivanov <[email-masked]>; [email-masked]; Daniele Ceccarelli <[email-masked]>
Subject: Re: [Netslices] Timing service

- Stewart

Gert

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 21 Jun 2017 13:40:12 +0000

Disagree because I don’t see the entire slice as always being physical or logical. As I said the slice is made up of components some of which can be physical and some of which can be logical, so the concepts of an entirely physical or entirely logical slice are really just two ends of a spectrum of options.

Peter

From: Anton Ivanov [mailto:[email-masked]]
Sent: Wednesday, June 21, 2017 5:18 AM
To: Stewart Bryant <[email-masked]>; Gert Grammel <[email-masked]>; Greg Mirsky <[email-masked]>; AshwoodsmithPeter <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>; [email-masked]; Daniele Ceccarelli <[email-masked]>
Subject: Re: [Netslices] Timing service

A.

- Stewart

Gert

Hi Peter,

Regards,
Greg

Peter

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

Peter,

Gert

    Peter

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

    - Stewart