Subject: [TICTOC] new TICTOC charter page

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 14 Nov 2007 20:39:49 +0200

Hi everyone, 
 
I just uploaded a new version of the TICTOC charter page.
Please take a look at www.dspcsp.com/tictoc.
 
Note in particular, that the scope has been curtailed and three specific
use cases have been identified.
However, the WG objectives and Goals and Milestones still need to be
adapted
to the revised description.
 
This new version is the result of lengthy conversations over the last
two days
between myself, Stewart, Karen, and Mark.
 
Comments would be appreciated. Sooner rather than later.
 
Y(J)S

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 15 Nov 2007 10:04:13 +0200

Hi,

I think you have improved the scope and charter considerably. 

My comments:

Use cases: I suggest to remove the general internet out of scope of
TICTOC. There is almost nothing in common in terms of application
requirements, infrastructure control etc. between this use case and the
other two. Let's solve the problem we really need to solve.

NTP:  The current text reads: " If the analysis indicates that NTPv4, or
specific extensions thereof, meet the second use case requirements,
TICTOC will adopt and extend NTPv4 as required." I believe NTP WG should
be responsible to extend NTP protocol. TICTOC should provide
requirements and feedback to the NTP WG. 

On-path support: I believe there are applications with very strict
requirements on phase and frequency synchronization for which on-path
support is mandatory. However I agree that TICTOC should also cover
solutions for less demanding applications that does not mandate on-path
support. 

I believe the draft I wrote on PTP over MPLS should be included as a
potential work item for the WG in the Internet Draft list:
http://www.ietf.org/internet-drafts/draft-ronc-ptp-mpls-00.txt

Best Regards,

Ron

From: Yaakov Stein [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 8:40 PM
To: [email-masked]
Subject: [TICTOC] new TICTOC charter page
Importance: High

Hi everyone, 

Y(J)S

-- 
This message was scanned by ESVA and is believed to be clean. 
Click here to report this message as spam.
<http://mailgw.resolutenetworks.com/cgi-bin/learn-msg.cgi?id=7F2E828155.
EE1CB>

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Nov 2007 11:50:33 +0200

Ron, 
 
As I said, this charter was the result of intensive discussions with
Mark as our AD.
 
We have already discussed on this list your opinion that only the
service provider case is of interest.
You are entitled to your opinion, but the IETF management does not share
this opinion.
>From our discussions, if we go this route we will find ourselves at a
dead-end.
Our scoping has separated the two problems as much as possible,
so that you are welcome to work ONLY on the problem you wish.
 
However, there is the feeling is that there is unsufficient manpower in
the IETF to run 
two timing related WGs for an extended period. (In fact, there is even a
concern
whether there are sufficient people to do EITHER.)
Thus, once NTPv4 is finished, the continuation of the NTP WG will need
to be evaluated. 
If TICTOC is chartered, then it is probable that any future NTP work
will be done in TICTOC.
 
Your draft will indeed be considered as a solution draft for the first
use case.
Others wish to contribute to the second case.
 
Y(J)S

________________________________

From: Ron Cohen [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 10:04 AM
To: Yaakov Stein; [email-masked]
Subject: RE: [TICTOC] new TICTOC charter page

Hi,

My comments:

Best Regards,

Ron

Hi everyone, 

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 15 Nov 2007 17:56:36 +0200

Sasha
 
Yes, when we talk about networks in the IETF, we are talking about IP
and MPLS,
rather than e.g. Ethernet. The Description says as much.
 
On-path support could be TCs or BCs. 
If we could deprecate TCs due to their layer violations, I would be in
favor of doing so.
However, they have their advantages.
Without any on-path support it may not be possible to meet some of the
requirements. 
 
There are a few differences between 1588 and NTP.
1588 has followup and can use on-path support.
NTP has advanced mitigations algorithms and security mechanisms.
1588 can be considered a packet with a timestamp, while NTP packets
carry performance info, etc.
NTP carries UTC while 1588 can carry TAI.
1588 is optimzed for HW timestamping, while (s discussed recently on the
NTP list) 
NTP doesn't even define which bit the timestamp refers to.
The default ranges of update rates and unicast/multicast are different.
The transport mechanisms are different.
The scalability issues are also quite different due to design decisions.

NTP is widely supported in the Internet, while 1588 has seen traction in
SP networks.
So, we are indeed focusing on using each in the right place.
 
I would be happy to move the MIBs up to phase 1.
Are you volunteering ?
 
Y(J)S

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 15 Nov 2007 18:18:12 +0200

Yaakov,
Thank you for a prompt response.
Please see inline (bold magenta).
 
Regards,
                 Sasha

From: Yaakov Stein [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 5:57 PM
To: Sasha Vainshtein
Cc: [email-masked]; Alon Shtern; Israel Sasson
Subject: RE: [TICTOC] new TICTOC charter page

Sasha

[Sasha] It only mentions "the pressing need to improve time and
frequency distribution over IP and over MPLS enabled Packet Switched
Networks (PSNs)". IMHO re-iterating that IP and MPLS-enabled networks
are in scope while other types of networks (e.g., Enterprise LANs)  are
out of scope when it comes to defining the use cases would be
beneficial.
 
On-path support could be TCs or BCs.  
[Sasha] To the best of my understanding Boundary Clocks (BCs) resolve
the scalability problems. Since the Slave treats its nearest BC as a
Master and is completely unaware of the next level Master clock, I'd say
that BCs should not be considered as part of the "on-path support"
concept.  But this is probably a terminology issue, not e real one.
If we could deprecate TCs due to their layer violations, I would be in
favor of doing so.
However, they have their advantages. 
 
Without any on-path support it may not be possible to meet some of the
requirements. 
[Sasha] I do not argue against TCs per se, I simply state that their
proper incorporation into the clock distribution scheme requires lots of
additional work. Hence I suggest to push them to Phase 2 and to focus on
the non-TC case in Phase 1. 
 
As for meeting or not meeting some of the requirements without TC, it
probably depends. AFAIK, some vendors claim they have excellent
solutions without the TCs.
 
There are a few differences between 1588 and NTP.
1588 has followup and can use on-path support.  [Sasha] Agree 
NTP has advanced mitigations algorithms and security mechanisms.
[Sasha] Agree  
1588 can be considered a packet with a timestamp, while NTP packets
carry performance info, etc.[Sasha] Agree 
NTP carries UTC while 1588 can carry TAI.  [Sasha] Agree, but this
hardly matters IMO. 
1588 is optimzed for HW timestamping, while (s discussed recently on the
NTP list) 
NTP doesn't even define which bit the timestamp refers to.  [Sasha] My
impression from these discussions is that 1588 facilitates timestamping
close to the actual pacte transmission (via the follow-up mechanism)
while NTP doesn't provide for anything like that. But this again is
probably a terminology issue.
The default ranges of update rates and unicast/multicast are different.
The transport mechanisms are different.[Sasha] Are they? AFAIK, both use
UDP/IP with well-known ports.
The scalability issues are also quite different due to design decisions.
[Sasha] Agree 
NTP is widely supported in the Internet, while 1588 has seen traction in
SP networks.[Sasha] "seen traction" sounds interesting. Any examples of
a production SP network distributing clock with 1588? Can I subscribe to
a 1588-based clock distribution service today?
So, we are indeed focusing on using each in the right place. [Sasha] Not
sure what is the right place for each. 
 
I would be happy to move the MIBs up to phase 1.
Are you volunteering ? [Sasha] Sorry, no. (And the TICROC WG should be
happy with this since I am pretty sure my MIBs would never pass the MIB
doctors' review:-)
 
Y(J)S

---

From: Mark Townsley <[email-masked]>
Date: Thu, 15 Nov 2007 17:25:47 +0100

> I would be happy to move the MIBs up to phase 1.
MIBs will have to be in the first phase.

- Mark

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 15 Nov 2007 12:59:05 +0200

Yaakov and all,
Here are my comments for the proposed charter.

1.	Well-engineered SP or Enterprise network mentioned in Use Case
1:

	*	I think that the charter must be explicitly restricted
to IP/MPLS networks (similar to that of the PWE3 WG) in both cases,
since IETF does not define protocols that run in other types of networks
	*	Restriction to IP/MPLS networks means that it is built
from devices (routers) that comply with, among other things, RFC 1812
(for IPv4) and RFC 3031 (for MPLS).

2.	On-path support mentioned in Use Case 1:

	*	I assume that what you have in mind is 1588v2
Transparent Clocks (TC), End-to-end and/or Peer-to-peer or some
modifications of those
	*	IMHO using of  the TCs in an IP/MPLS network implies:

		*	Drastic changes in the architecture of the
existing routers (availability of phase-synchronized clock on all the
line cards)
		*	A transport protocol enhancement that allows all
the routers to modify protocol packets that pass through them.  IPv4
Router Alert Option or MPLS Router Alert Label are two mechanisms to be
considered IMO. Without such an enhancement the routers in the SP
network would be prohibited from modifying the protocol packets. At the
same time these mechanisms should allow handling the protocol packets in
the "fast path", so maybe we need new IPv4 Options/new reserved labels
for MPLS
		*	A mechanism for checking that the on-path
support is provided by all the routers on the path.  Partial on-path
support where full support is assumed would be harmful IMO

	*	Hence I suggest:

		*	Explicitly restrict Phase 1 to solutions that do
not require on-path support
		*	To separate on-path support as an issue for
dedicated study

3.	NTPv4 and 1588v2: 

	*	AFAIK, if we take the 1588v2 TC mechanism aside (for the
reasons explained above), the main  difference between NTP and 1588 is
the follow-up message of the latter that allows to convey precision
timestamps from the Master to the Slave. Do I miss something?
	*	I'd say that if NTPv4 (or its suitable modification)
works for Use Case 2, there is no need to adapt a different protocol for
Use Case 1 (which is presumably simpler). So I suggest to re-phrase the
charter like following:

		*	If the WG finds out that NTPv4 (possibly with
appropriate modifications) can meet the requirements of both Use Case 1
and Use Case 2, then it will be adopted as a unified solution for both
cases
		*	If the WG finds out that NTPv4 cannot meet
requirements of Use Case 1 and 1588v2 (or its modifications) can meet
these requirements...
		*	Accordingly, the milestone must be an initial
profile of the selected protocol (not restricted to 1588).

4.	Last but not least, I am not sure that MIBs can be safely
relegated to Phase 2 (meaning that we are going to standardize some
protocol that cannot be managed).

My 2c,
                    Sasha

Hi everyone, 
 
I just uploaded a new version of the TICTOC charter page.
Please take a look at www.dpcsp.com/tictoc.

 
 
Y(J)S

---

From: "Ron Cohen" <[email-masked]>
Date: Fri, 16 Nov 2007 11:14:48 +0200

Sasha,

I have the opposite opinion.

TICTOC in my opinion must come up with a solution that provides
synchronization in the quality that will answer the most demanding
emerging application. In an non-accurate definition it must provide GPS
quality of time and frequency over PSN. In order to provide such timing
service such that service and telecom providers can rely upon it must be
proven that in any PDV the required performed is achieved. To do this
you must have on-path support. As I wrote in a previous email, the
on-path support does not have to be implemented everywhere across the
core, it needs to be implemented from the location time information is
available to the interface where it needs to be delivered. In essence I
believe that we should take a similar approach to 802.1as in spirit,
i.e. that the solution is fail proof and detailed (including the
algorithms). 

It is true that there are scenarios where the on-path support is not
available, or not available yet. In such environments synchronization
over packet can be delivered, with the understanding that the quality of
synchronization and the quality of assurance for this synchronization is
limited. I believe that for this purpose an IEEE1588v2 profile should be
built as well as NTPv4 solutions should be examined. I don't see how we
select one protocol over the other and therefore should probably, for
this scenario, promote both.

Best,

Ron

 

From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 12:59 PM
To: Yaakov Stein
Cc: Israel Sasson; Alon Shtern; [email-masked]
Subject: RE: [TICTOC] new TICTOC charter page

Yaakov and all,

	*	Hence I suggest:

3.	NTPv4 and 1588v2: 

My 2c,

                    Sasha

Hi everyone, 

Y(J)S

-- 
This message was scanned by ESVA and is believed to be clean. 
Click here to report this message as spam.
<http://mailgw.resolutenetworks.com/cgi-bin/learn-msg.cgi?id=75F8627F10.
5F652>