Subject: [TICTOC] Enterprise Profile

From: Douglas Arnold <[email-masked]>
Date: Thu, 24 Oct 2013 17:35:10 -0700

Hello Everyone,

Attached is an updated version of the Enterprise profile.  Sorry I missed
the upload deadline for  the Vancouver meeting.  If you get a chance to
look at it before then I will be there and would love to discuss it.

Summary of changes:

I also changed the TLV format to fit the latest proposal in the 1588
revision.

I added a statement about not going into the master state unless one had a
current UTC offset.

I added to the TLV fields to indicate maximum phase correction over a sync
cycle.

-- 
Doug Arnold
Principal Technologist
*JTime!* Meinberg USA
+1-707-303-5559

---

From: John Fletcher <[email-masked]>
Date: Fri, 25 Oct 2013 10:01:11 +0000

Doug,

I would be interested to know the circumstances when you see the maximum phase adjustment information being used.

Some comments:

In section 6, you say, "In all three of the delay measurement modes...".  At that point in the text you have not yet mentioned multicast, hybrid and unicast modes so it's not clear which modes you are referring to.

In section 9, you say, "Slaves SHOULD NOT Synchronize to a Rogue Master."  It's not clear how a slave would know that a master is rogue; presumably it would need to examine the announce messages of all masters and do its own BMCA evaluation.  A more realistic "rogue" master would probably meet the BMCA criteria for selection.

In section 12, "Alternative Time Scales" should be "Alternate Timescales".

Regards,
John Fletcher

From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Arnold
Sent: 25 October 2013 01:35
To: [email-masked]
Subject: [TICTOC] Enterprise Profile

Hello Everyone,

Attached is an updated version of the Enterprise profile.  Sorry I missed the upload deadline for  the Vancouver meeting.  If you get a chance to look at it before then I will be there and would love to discuss it.

Summary of changes:

I also changed the TLV format to fit the latest proposal in the 1588 revision.

I added a statement about not going into the master state unless one had a current UTC offset.

I added to the TLV fields to indicate maximum phase correction over a sync cycle.

--
Doug Arnold
Principal Technologist
JTime! Meinberg USA
+1-707-303-5559

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: John Fletcher <[email-masked]>
Date: Mon, 28 Oct 2013 15:10:27 +0000

I'd also like to ask that you don't prohibit the Alternate Timescales option.  This is potentially useful to distribute "local time" (your time-zone and dst) and there doesn't seem to be any need to prohibit it.

John
________________________________
From: [email-masked] [[email-masked]] on behalf of John Fletcher [[email-masked]]
Sent: 25 October 2013 11:01
To: Douglas Arnold
Cc: [email-masked]
Subject: Re: [TICTOC] Enterprise Profile

Doug,

Some comments:

In section 6, you say, “In all three of the delay measurement modes…”.  At that point in the text you have not yet mentioned multicast, hybrid and unicast modes so it’s not clear which modes you are referring to.

In section 9, you say, “Slaves SHOULD NOT Synchronize to a Rogue Master.”  It’s not clear how a slave would know that a master is rogue; presumably it would need to examine the announce messages of all masters and do its own BMCA evaluation.  A more realistic “rogue” master would probably meet the BMCA criteria for selection.

In section 12, “Alternative Time Scales” should be “Alternate Timescales”.

Regards,
John Fletcher

Hello Everyone,

Summary of changes:

--
Doug Arnold
Principal Technologist
JTime! Meinberg USA
+1-707-303-5559

http://www.bbc.co.uk

---------------------

http://www.bbc.co.uk

---------------------

---

From: Douglas Arnold <[email-masked]>
Date: Mon, 28 Oct 2013 13:05:43 -0700

Hello John,

I agree that local time is useful.  I would not be averse to creating a TLV
to distribute local time offset, so that end node can convert to local time
and present it to users.

However, I do not support the idea of using a local time epoch in the PTP
timestamp fields. This is an allowed option in IEEE 1588-2008, but I
believe that this is likely to cause interoperability problems, when some
vendors support it and others do not.  Also some system architechs have
indicated that they deploy PTP across large networks, which span time
zones. This is the feature that should be forbidden.

In the NTP standard (RFC5905) the timestamps in the packet all use a
specific time epoch, and generate all other desired time epoch as
corrections performed at the end points.  Note also that in most computer
operating systems a single standard time epoch is used in and local time is
generated at the presentation layer for human readable interfaces.

Doug

On Mon, Oct 28, 2013 at 8:10 AM, John Fletcher <[email-masked]>wrote:

>  I'd also like to ask that you don't prohibit the Alternate Timescales
> option.  This is potentially useful to distribute "local time" (your
> time-zone and dst) and there doesn't seem to be any need to prohibit it.
>
>  John
>  ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> John Fletcher [[email-masked]]
> *Sent:* 25 October 2013 11:01
> *To:* Douglas Arnold
> *Cc:* [email-masked]
> *Subject:* Re: [TICTOC] Enterprise Profile
>
>    Doug,
>
>
>
> In section 6, you say, “In all three of the delay measurement modes…”.  At
> that point in the text you have not yet mentioned multicast, hybrid and
> unicast modes so it’s not clear which modes you are referring to.
>
>
>
> In section 9, you say, “Slaves SHOULD NOT Synchronize to a Rogue Master.”
> It’s not clear how a slave would know that a master is rogue; presumably it
> would need to examine the announce messages of all masters and do its own
> BMCA evaluation.  A more realistic “rogue” master would probably meet the
> BMCA criteria for selection.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Douglas Arnold
> *Sent:* 25 October 2013 01:35
> *To:* [email-masked]
> *Subject:* [TICTOC] Enterprise Profile
>
>
>
> Hello Everyone,
>
>
>
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.

-- 
Doug

---

From: Kevin Gross <[email-masked]>
Date: Mon, 28 Oct 2013 19:38:53 -0600

Enterprise networks definitely span timezones - if not now then eventually
through mergers and acquisition. I think having the wrong local time is
worse than having no local time. I support disabling the capability for
this profile.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>

On Mon, Oct 28, 2013 at 2:05 PM, Douglas Arnold <[email-masked]>wrote:

> Hello John,
>
> I agree that local time is useful.  I would not be averse to creating a
> TLV to distribute local time offset, so that end node can convert to local
> time and present it to users.
>
>> In section 6, you say, “In all three of the delay measurement modes…”.
>> At that point in the text you have not yet mentioned multicast, hybrid and
>> In section 9, you say, “Slaves SHOULD NOT Synchronize to a Rogue
>> Master.”  It’s not clear how a slave would know that a master is rogue;
>> presumably it would need to examine the announce messages of all masters
>> and do its own BMCA evaluation.  A more realistic “rogue” master would
>> probably meet the BMCA criteria for selection.
>>
>>
>>
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>
>

---

From: John Fletcher <[email-masked]>
Date: Tue, 29 Oct 2013 10:18:27 +0000

Just to be clear, I am not suggesting use of a different epoch in timestamp fields.  I am talking about the optional TLV described in section 16.3 which can give you the offset(s) between PTP time and one or more timescales of your choice.

Regarding spanning timezones, there is a difference between the extent of the enterprise network and the extent of the part of network served by a PTP master.  The latter is probably a subnet since multicast messages (e.g. Announce) are usually confined to a subnet.  A subnet spanning multiple timezones would be less common.  However you can have more than one Alternate Timescale if necessary.

This feature is just an option; I'm not suggesting it be required, just that it not be forbidden.

John

From: Douglas Arnold [mailto:[email-masked]]
Sent: 28 October 2013 20:06
To: John Fletcher
Cc: [email-masked]
Subject: Re: [TICTOC] Enterprise Profile

Hello John,

I agree that local time is useful.  I would not be averse to creating a TLV to distribute local time offset, so that end node can convert to local time and present it to users.

However, I do not support the idea of using a local time epoch in the PTP timestamp fields. This is an allowed option in IEEE 1588-2008, but I believe that this is likely to cause interoperability problems, when some vendors support it and others do not.  Also some system architechs have indicated that they deploy PTP across large networks, which span time zones. This is the feature that should be forbidden.

In the NTP standard (RFC5905) the timestamps in the packet all use a specific time epoch, and generate all other desired time epoch as corrections performed at the end points.  Note also that in most computer operating systems a single standard time epoch is used in and local time is generated at the presentation layer for human readable interfaces.

Doug

On Mon, Oct 28, 2013 at 8:10 AM, John Fletcher <[email-masked]<mailto:[email-masked]>> wrote:
I'd also like to ask that you don't prohibit the Alternate Timescales option.  This is potentially useful to distribute "local time" (your time-zone and dst) and there doesn't seem to be any need to prohibit it.

John
________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of John Fletcher [[email-masked]<mailto:[email-masked]>]
Sent: 25 October 2013 11:01
To: Douglas Arnold
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TICTOC] Enterprise Profile
Doug,

Some comments:

Regards,
John Fletcher

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Douglas Arnold
Sent: 25 October 2013 01:35
To: [email-masked]<mailto:[email-masked]>
Subject: [TICTOC] Enterprise Profile

Hello Everyone,

Summary of changes:

--
Doug Arnold
Principal Technologist
JTime! Meinberg USA
+1-707-303-5559<tel:%2B1-707-303-5559>

http://www.bbc.co.uk

---------------------

http://www.bbc.co.uk

---------------------

--
Doug

---

From: Kevin Gross <[email-masked]>
Date: Tue, 29 Oct 2013 09:45:09 -0600

Multicast IP routing allows multicast messaging beyond a subnet. Multicast
IP routing is not available over the internet but it is now fairly common
on enterprise networks.

John, can you describe a use case for alternate timescales and explain how
the endstation can know that the timescale is correct local time or which
alternate timescale to use if there are multiple?

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Tue, Oct 29, 2013 at 4:18 AM, John Fletcher <[email-masked]>wrote:

>  Just to be clear, I am not suggesting use of a different epoch in
> timestamp fields.  I am talking about the optional TLV described in section
> 16.3 which can give you the offset(s) between PTP time and one or more
> timescales of your choice.****
>
> ** **
>
> Regarding spanning timezones, there is a difference between the extent of
> the enterprise network and the extent of the part of network served by a
> PTP master.  The latter is probably a subnet since multicast messages (e.g.
> Announce) are usually confined to a subnet.  A subnet spanning multiple
> timezones would be less common.  However you can have more than one
> Alternate Timescale if necessary.****
>
> ** **
>
> This feature is just an option; I’m not suggesting it be required, just
> that it not be forbidden.****
>
> ** **
>
> John****
>
> ** **
>
> *From:* Douglas Arnold [mailto:[email-masked]]
> *Sent:* 28 October 2013 20:06
> *To:* John Fletcher
>
> *Cc:* [email-masked]
> *Subject:* Re: [TICTOC] Enterprise Profile****
>
> ** **
>
> Hello John,****
>
> ** **
>
> time and present it to users.****
>
> ** **
>
> zones. This is the feature that should be forbidden.  ****
>
> ** **
>
> generated at the presentation layer for human readable interfaces.****
>
> ** **
>
> Doug****
>
> ** **
>
> On Mon, Oct 28, 2013 at 8:10 AM, John Fletcher <[email-masked]>
> wrote:****
>
> time-zone and dst) and there doesn't seem to be any need to prohibit it. *
> ***
>
> ** **
>
> John****
> *Subject:* Re: [TICTOC] Enterprise Profile****
>
> Doug,****
>
>  ****
>
> I would be interested to know the circumstances when you see the maximum
> phase adjustment information being used.****
>
>  ****
>
> Some comments:****
>
>  ****
>
> unicast modes so it’s not clear which modes you are referring to.****
>
>  ****
>
> BMCA criteria for selection.****
>
>  ****
>
> ****
>  ****
>  ****
> Regards,****
> John Fletcher****
>  ****
> *Subject:* [TICTOC] Enterprise Profile****
>
>  ****
>
> Hello Everyone,****
>
>  ****
>
> look at it before then I will be there and would love to discuss it. ****
>
>  ****
>
> Summary of changes:****
>
>  ****
>
> revision.  ****
>  ****
> current UTC offset.  ****
>  ****
> cycle.****
>  ****
> -- ****
> Doug Arnold****
> Principal Technologist****
>
> *JTime!* Meinberg USA****
>
> +1-707-303-5559****
>
>  ****
>
>  ****
>
>  ****
>
> Further communication will signify your consent to this.****
>
> ---------------------****
>
>  ****
>
> Further communication will signify your consent to this.****
>
> ---------------------****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> Doug****
>

---

From: John Fletcher <[email-masked]>
Date: Thu, 31 Oct 2013 15:28:46 +0000

Hi Kevin,

Well, I think it already accepted that there are applications where it is useful to know the local time.  Generating SMPTE Timecode is one that you know about.

>From Doug's comment, I'm not clear if he wanted to prohibit something different, i.e. using an ARB timescale to represent local time.  I'm happy to prohibit that but I would like to see the Alternate Timescales TLV of section 16.3 allowed - not required, just allowed.

How can the endstation know which is the correct local time?  Most likely use case is that the PTP deployment is designed so that masters do not serve more than one timezone.  Failing that, it could be user selection based on the name of the alternate timescale.

Yes, you can route multicast messages beyond a subnet but many network administrators, e.g. in my own company's enterprise network, choose not to allow that, especially for "Any Source Multicast" as used by 1588.

John

From: Kevin Gross [mailto:[email-masked]]
Sent: 29 October 2013 15:45
To: John Fletcher
Cc: Douglas Arnold; [email-masked]
Subject: Re: [TICTOC] Enterprise Profile

Multicast IP routing allows multicast messaging beyond a subnet. Multicast IP routing is not available over the internet but it is now fairly common on enterprise networks.

John, can you describe a use case for alternate timescales and explain how the endstation can know that the timescale is correct local time or which alternate timescale to use if there are multiple?

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>

On Tue, Oct 29, 2013 at 4:18 AM, John Fletcher <[email-masked]<mailto:[email-masked]>> wrote:
Just to be clear, I am not suggesting use of a different epoch in timestamp fields.  I am talking about the optional TLV described in section 16.3 which can give you the offset(s) between PTP time and one or more timescales of your choice.

John

From: Douglas Arnold [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 28 October 2013 20:06
To: John Fletcher

Hello John,

Doug

John

Some comments:

Regards,
John Fletcher

Hello Everyone,

Summary of changes:

http://www.bbc.co.uk

---------------------

http://www.bbc.co.uk

---------------------

--
Doug

---

From: Kevin Gross <[email-masked]>
Date: Thu, 31 Oct 2013 14:56:54 -0600

So the use case would be timecode distribution in a broadcast facility
where multicast routing is administratively confined to the facility. Sound
reasonable.

I think that the reason alternate timescales are not included in the
enterprise profile is that the enterprise profile is trying to do things
the NTP way. NTP does not know about timezones; that is left up to the
individual workstations to sort out.

I expect your argument for allowing it that systems that wish to continue
to operate in this way can simply ignore the alternate timescale and even
if there is a disagreement about what the local time is, they're no worse
off than they currently are.

Kevin Gross
+1-303-447-0517
Media Network Consultant

On Thu, Oct 31, 2013 at 9:28 AM, John Fletcher <[email-masked]>wrote:

>  Hi Kevin,****
>
> ** **
>
> Well, I think it already accepted that there are applications where it is
> useful to know the local time.  Generating SMPTE Timecode is one that you
> know about.****
>
> ** **
>
> From Doug’s comment, I’m not clear if he wanted to prohibit something
> different, i.e. using an ARB timescale to represent local time.  I’m happy
> to prohibit that but I would like to see the Alternate Timescales TLV of
> section 16.3 allowed – not required, just allowed.****
>
> ** **
>
> How can the endstation know which is the correct local time?  Most likely
> use case is that the PTP deployment is designed so that masters do not
> serve more than one timezone.  Failing that, it could be user selection
> based on the name of the alternate timescale.****
>
> ** **
>
> Yes, you can route multicast messages beyond a subnet but many network
> administrators, e.g. in my own company’s enterprise network, choose not to
> allow that, especially for “Any Source Multicast” as used by 1588.****
>
> ** **
>
> John****
>
> ** **
>
> *From:* Kevin Gross [mailto:[email-masked]]
> *Sent:* 29 October 2013 15:45
> *To:* John Fletcher
> *Cc:* Douglas Arnold; [email-masked]
>
> on enterprise networks.****
>
> ** **
>
> alternate timescale to use if there are multiple?****
>
>
> ****
>
> Kevin Gross****
>
> +1-303-447-0517****
>
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>****
>
> ** **
>
> On Tue, Oct 29, 2013 at 4:18 AM, John Fletcher <[email-masked]>
> wrote:****
>
> *To:* John Fletcher****