Subject: Re: WG Review: Timing over IP Connection and Transfer of Clock (tictoc)

From: Pekka Savola <[email-masked]>
Date: Thu, 28 Feb 2008 15:26:49 +0200 (EET)

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