All, On the requirement in Section 8 (Preferred Master Clocks SHOULD attempt to find a domain in which they are the best master):
I think that this describes an alternate BMCA for the profile, because the current 1588v2 BMCA operates on a single domain, and all domains are independent. 1588 allows for alternate BMCAs in profiles, but I think if we introduce the idea here we should spell it out in the profile as an alternate BMCA, and describe it more fully (in particular describing which BMCA states require monitoring of all domains.) I am also a bit concerned about the concept of "configured domains", and the idea that the Master clock can try any domain in its configured domain list. That requires all Master Clocks to be configured identically with the configured domain list, and if an operator wanted to add a new configured domain they would have to touch the configuration on all clocks (Master and Slave) in order to make sure each Master clock is monitoring the others properly. Perhaps we need to specify a range here? It also means that a Master clock that falls off the network and then gets back on may come back in a different domain, which may cause problems with the new Security procedures we are developing. My personal opinion is to go back to a concept that is closer to 1588v2 (and the Telecom Profile) on the Master side, where each master broadcasts on a single, pre-configured domain. We can add text saying that it is preferred to have each master broadcast on a separate domain to gain the benefits of using redundant timing sources. Masters can be added without having to worry about how other masters are configured. It seems simpler that way. -- I am in favor of the other changes, and in particular of the changes in Section 6 that call for multiple domain support in general. We have an easier time implementing multiple domains on the Slave side because, as Doug has noted, they can be implemented as independent ordinary clocks on a single port, with the combination of their timing information outside of 1588. (This is also one approach under consideration in the P1588 WB for the next revision of PTP.) I think the Enterprise profile is particularly suited to this, since Announce messages are broadcast in Multicast. A Slave device with multiple domain support can see all announce messages on all domains automatically, without having to ask for them. Each node can then decide which domains to listen to and what to do with the timing data in an implementation-specific way, with very little configuration required. Regards, -- Denis Reilly | Lead Engineer | [email protected] (585)321-5837 This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you received this e-mail in error please note that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. -----Original Message----- From: TICTOC [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, October 23, 2014 11:58 PM To: [email protected] Subject: TICTOC Digest, Vol 93, Issue 4 Send TICTOC mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/tictoc or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of TICTOC digest..." Today's Topics: 1. I-D Action: draft-ietf-tictoc-ptp-enterprise-profile-04.txt ([email protected]) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Oct 2014 20:57:28 -0700 From: [email protected] To: [email protected] Cc: [email protected] Subject: [TICTOC] I-D Action: draft-ietf-tictoc-ptp-enterprise-profile-04.txt Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock Working Group of the IETF. Title : Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast Messages Authors : Doug Arnold Heiko Gerstung Filename : draft-ietf-tictoc-ptp-enterprise-profile-04.txt Pages : 12 Date : 2014-10-23 Abstract: This document describes a profile for the use of the Precision Time Protocol in an IPV4 or IPv6 Enterprise information system environment. The profile uses the End to End Delay Measurement Mechanism, allows both multicast and unicast Delay Request and Delay Response Messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-ptp-enterprise-profile-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ------------------------------ Subject: Digest Footer _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc ------------------------------ End of TICTOC Digest, Vol 93, Issue 4 ************************************* _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
