On Wed, 27 Feb 2008, The IESG wrote: > The Timing over IP Connections and Transfer Of Clock (TICTOC) WG is > concerned with highly accurate time and frequency distribution over > native IP and MPLS-enabled IP Packet Switched Networks (PSNs). While > this need arises from a variety of sources (see > draft-bryant-tictoc-probstat-01.txt), the application areas of focus for > this WG are: How much is much? Please define your target or required value for "highly accurate time and frequency". Are you talking about pico, nano, micro, or milliseconds? > (1) Network infrastructures with the need for highly accurate time and > frequency distribution within well-engineered service provider or > enterprise campus networks. On-path support with specialized hardware > may be expected to be available at one or more hops on a given path. ... My reading of the proposed charter is that this protocol is expected to be usable in network which do not provide on-path support (specialized hardware). As a result, the technology should be good enough without link-specific aids. If it isn't, we shouldn't build the illusion that it is. There is a deliverable on link-layer mappings and many techniques are expected to be link-type specific. Instead of going down the path of media-specific technologies and adaptations -- which the IETF often tries to avoid -- I'd suggest (because the work item list is already very long) that at least in the first phase, the link-specific technologies are defined out of scope. > (2) Individual hosts and devices on the public Internet requiring > functionality or performance not currently available in NTP. On-path > support may be utilized if available, but is not expected. This > application brings additional requirements beyond improved accuracy, for > example, the traceable and authenticated distribution of UTC time, > including correct handling of leap seconds. I suggest taking link-type specific items out of scope in the initial phase here as well. > TICTOC will transfer time and frequency over both IP and IP enabled MPLS > PSNs. One of the major users of TICTOC technology is the service > provider community, where MPLS enabled IP networks are common. If > necessary, TICTOC may take advantage of the path control properties of > MPLS and the ability to signal modifications to per packet forwarding > behavior. If TICTOC is expected to be usable on pure IP PSNs, in the interest of avoiding premature optimizations and minimizing extra work in the first phase, I strongly advise dropping MPLS-specific considerations at this point and leaving it for later study. On the other hand, if TICTOC doesn't work sufficiently well in pure IP networks, who are we kidding by making it kind-of work in an MPLS network? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf