Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

From: [email-masked]
Date: Mon, 22 Oct 2012 01:28:04 -0700

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           : Transporting Timing messages over MPLS Networks
	Author(s)       : Shahram Davari
                          Amit Oren
                          Manav Bhatia
                          Peter Roberts
                          Laurent Montini
	Filename        : draft-ietf-tictoc-1588overmpls-03.txt
	Pages           : 36
	Date            : 2012-10-22

Abstract:
   This document defines the method for transporting Timing messages
   such as PTP and NTP over an MPLS network.  The method allows for the
   easy identification of these PDUs at the port level to allow for port
   level processing of these PDUs in both LERs and LSRs.

   The basic idea is to transport Timing messages inside dedicated MPLS
   LSPs.  These LSPs only carry timing messages and possibly Control and
   Management packets, but they do not carry customer traffic.

   Two methods for transporting Timing messages over MPLS are defined.
   The first method is to transport Timing messages directly over the
   dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
   MPLS networks.  The second method is to transport Timing messages
   inside a PW via Ethernet encapsulation, which is suitable for both
   MPLS and MPLS-TP networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588overmpls-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 22 Oct 2012 16:47:01 +0200

Hi Shahram et al.

What is the motivation for adding NTP to this draft?
Are we planning to define something similar to a correctionField in NTP?

Regards,
Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 10:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

Abstract:

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

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 22 Oct 2012 16:46:20 +0000

Hi Tal,

If you recall the Area director asked for generalizing this draft to NTP and other possible future Timing methods such as a Shim header that can carry Timing. I know NTP does not have TC, but IETF may add TC in future. Also on the egress LER the timing Label (defined in the draft) may be used as an indicator to sample ToD at the port level.

Thanks
Shahram

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Monday, October 22, 2012 7:47 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

Hi Shahram et al.

Regards,
Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 10:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

Abstract:

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 22 Oct 2012 22:35:28 +0200

Hi Shahram,

Thanks for the prompt response.
I would suggest to add some text to explain the scope of this draft in the context of NTP, i.e., your explanation below.

A question to the WG chairs: if NTP TCs are indeed on the agenda, wouldn't it be best to define these entities in parallel to the MPLS draft? It seems more natural, and more likely to produce a coherent mechanism.

Thanks,
Tal.

________________________________________
From: Shahram Davari [[email-masked]]
Sent: Monday, October 22, 2012 6:46 PM
To: Tal Mizrahi; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

Hi Tal,

Thanks
Shahram

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]]
Sent: Monday, October 22, 2012 7:47 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

Hi Shahram et al.

Regards,
Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 10:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

Abstract:

---

From: Karen O'Donoghue <[email-masked]>
Date: Tue, 23 Oct 2012 11:10:41 -0400

Tal,

It is true that developing an NTP option in parallel would potentially 
be more efficient and coherent; however, we have thus far had no 
volunteers to work on that document. The current approach is flexible 
enough to support PTP, NTP, and possibly other timing methods which is a 
generalization of the solution originally proposed.

We welcome proposals and volunteer document editors who wish to pursue 
the NTP option.

Regards,
Karen

On 10/22/12 4:35 PM, Tal Mizrahi wrote:
> ntpwg mailing list
> [email-masked]
> http://lists.ntp.org/listinfo/ntpwg

---

From: "Meyer, Peter" <[email-masked]>
Date: Tue, 30 Oct 2012 19:27:56 -0400

Hi Shahram et al,

A few comments on the latest draft.

1) Section 4.  I like the diagrams.  Missing is the option for the BC to
be inside an LSR.   I think we've discussed before on the reflector that
if an LSR can act as a TC (e.g. terminating peer-delay messages) then it
also has the ability to act as a BC.  I can contribute such a diagram,
if desired.

2) Section 7.  "dont" -> "don't"

3) Section 7.  There might be some mix-up between "Event" messages and
"timestamped" messages.  The new "Event" list includes Announce, which
is probably not correct.   Announce messages are allowed to have 0
timestamp value or to be timestamped with +/-1 second.

4) Section 7.  "If Two Step PTP clocks are present, then the FOLLOW_UP,
DELAY_RESP, and PDELAY_RESP_FOLLOW_UP ....", probably DELAY_RESP should
not be in this list as it relates to two-way messaging, not two-step
messaging.

5) Section 18.2 "Behaviour of Timing-capable/aware LSR".  I think BC
should also be supported here.

6) Section 17. "Applicability Statement".  Where a TC is
supported/supportable a BC is also supported/supportable.  I don't
understand the exclusive bundling of LSR with a TC.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: October 22, 2012 4:28 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-03.txt

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           : Transporting Timing messages over MPLS
Networks
	Author(s)       : Shahram Davari
                          Amit Oren
                          Manav Bhatia
                          Peter Roberts
                          Laurent Montini
	Filename        : draft-ietf-tictoc-1588overmpls-03.txt
	Pages           : 36
	Date            : 2012-10-22

Abstract: