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

From: [email-masked]
Date: Tue, 24 May 2011 15:39:58 -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 PTP messages (1588) over MPLS Networks
	Author(s)       : Shahram Davari
                          Amit Oren
                          Manav Bhatia
                          Peter Roberts
                          Laurent Montini
	Filename        : draft-ietf-tictoc-1588overmpls-01.txt
	Pages           : 35
	Date            : 2011-05-24

   This document defines the method for transporting PTP messages (PDUs)
   over an MPLS network to enable a proper handling of these packets
   (e.g. implementation of Transparent Clocks (TC)) in LSRs.

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

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-01.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-01.txt

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 25 May 2011 04:14:21 +0530

Hi,

You can use the following link to get the diffs from the previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588overmpls-01.txt

Cheers, Manav

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, May 25, 2011 4.10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-01.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.
> 
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>

---

From: [email-masked]
Date: Thu, 26 May 2011 11:57:11 -0400

Hi Manev,

My comments are more or less the same as submitted for the -00 draft. The 
document does not differentiate well the topic of MPLS transport mapping 
with the individual clock types along the reference chain (specifically 
TC).  It leads the reader to conclude that the transport of 1588 over MPLS 
requires TCs.

Perhaps a generic architecture diagram may be useful.

1) A few places in the text the phrase "proper handling of these packets" 
or "properly handle PTP messages" or "perform proper  processing"  is used 
to mean transparent clock.  I would propose to remove such language as 
from the ITU-T studies of timing performances of PTP one could argue the 
"proper" way is to implement a boundary clock.  Where the intention is to 
aid the designer of a TC that is fine to describe the implementation 
recommendation, but not to suggest this is the way to acheive the best 
performance or even the desired way to deploy PTP over MPLS.

Refer to first paragraph of Abstract, and first paragraph of Problem 
Statement (section 3)

2) I would like to see a statement added in the document that the 
performance aspects (e.g. the phase or frequency alignment) are outside 
the scope of the document.

Refer to fifth paragraph of Introduction(section 1) where performance of 
TC is mentioned and TCs are mentioned as the way ensure synchronization 
objectives are met.

3) The 1588 message transport section 6 it lists sync, delay_req, 
pdelay_req and pdelay_resp as requiring TC processing.  I believe also 
Follow_Ups are handled for two-step or the conversion from one-step to 
two-step.  I think also pdelay_resp_follow_ups aswell.  In addition, 
syntonized TCs may handle the general messages aswell to figure out which 
flow to use as a syntonization source.

4) Section 6, 7, 8, 10 and 13 seems to focus only on the TC case between 
OC's and does not consider BC situation.

5) Section 12 text on checksums could be improved to indicate this only 
applies to TC and not to OC & BC.

6) Section 16 seems to address only TC clocks and not OC or BC clocks.

7) Section 16.3 implies that the only possible way to handle PTP is TC, 
excluding BC --- "don't have the capability to process 1588 packets (e.g. 
TC processing)" and "   Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP 
object and just switch the MPLS packets carrying 1588 messages as data 
packets and don't perform any TC processing."

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]  | www.zarlink.com

<[email-masked]> 
Sent by: <[email-masked]>
24/05/2011 06:41 PM

To
<[email-masked]>
cc
<[email-masked]>
Subject
[TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-01.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 PTP messages (1588) over 
MPLS Networks
                 Author(s)       : Shahram Davari
                          Amit Oren
                          Manav Bhatia
                          Peter Roberts
                          Laurent Montini
                 Filename        : draft-ietf-tictoc-1588overmpls-01.txt
                 Pages           : 35
                 Date            : 2011-05-24

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 27 May 2011 04:18:27 +0530

Hi Peter,

Very valid comments. Will take care of them in the next version.

Cheers, Manav

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, May 26, 2011 9.27 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: [TICTOC] draft-ietf-tictoc-1588overmpls-01.txt comments

Hi Manev,

My comments are more or less the same as submitted for the -00 draft.   The document does not differentiate well the topic of MPLS transport mapping with the individual clock types along the reference chain (specifically TC).  It leads the reader to conclude that the transport of 1588 over MPLS requires TCs.

1) A few places in the text the phrase "proper handling of these packets" or "properly handle PTP messages" or "perform proper  processing"  is used to mean transparent clock.  I would propose to remove such language as from the ITU-T studies of timing performances of PTP one could argue the "proper" way is to implement a boundary clock.  Where the intention is to aid the designer of a TC that is fine to describe the implementation recommendation, but not to suggest this is the way to acheive the best performance or even the desired way to deploy PTP over MPLS.

Refer to first paragraph of Abstract, and first paragraph of Problem Statement (section 3)

2) I would like to see a statement added in the document that the performance aspects (e.g. the phase or frequency alignment) are outside the scope of the document.

Refer to fifth paragraph of Introduction(section 1) where performance of TC is mentioned and TCs are mentioned as the way ensure synchronization objectives are met.

3) The 1588 message transport section 6 it lists sync, delay_req, pdelay_req and pdelay_resp as requiring TC processing.  I believe also Follow_Ups are handled for two-step or the conversion from one-step to two-step.  I think also pdelay_resp_follow_ups aswell.  In addition, syntonized TCs may handle the general messages aswell to figure out which flow to use as a syntonization source.

4) Section 6, 7, 8, 10 and 13 seems to focus only on the TC case between OC's and does not consider BC situation.

5) Section 12 text on checksums could be improved to indicate this only applies to TC and not to OC & BC.

7) Section 16.3 implies that the only possible way to handle PTP is TC, excluding BC --- "don't have the capability to process 1588 packets (e.g.  TC processing)" and "   Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP object and just switch the MPLS packets carrying 1588 messages as data packets and don't perform any TC processing."

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]<mailto:[email-masked]>  | www.zarlink.com<http://www.zarlink.com/>

24/05/2011 06:41 PM

To
<[email-masked]>
cc
<[email-masked]>
Subject

----------
This email is confidential and may contain information that is privileged and
exempt from disclosure by law.  If you have received it in error, please contact
the sender immediately by return email and then delete it from your system; you
should not copy it or disclose its contents to anyone.  Emails are not secure
and cannot be guaranteed to be error free as they can be intercepted, amended,
lost or destroyed, or contain viruses.  Anyone who communicates with us by email
is taken to accept these risks.

---

From: Stefano Ruffini <[email-masked]>
Date: Fri, 27 May 2011 12:00:56 +0200

Peter,

a general thought based on some of your comments (e.g. comment 4 ).

I undertsand that main use case for this draft is either implementation of some kind of TC or perhaps optimization of the forwarding of the timing packets .
When a  BC is implemented  in every hop , this draft might be useful (e.g. it could help in the implementation of the  "HW timestamping") but perhaps not really so important .

About your comment 1), the language ("proper") could be revised, but I think it is useful to use some equivalent wording as to cover possible "processing" of the packets not necessarily according to 1588 transparent clock or boundary clock (the simplest would be somethign related to QoS).

Best REgards
Stefano

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: venerdì 27 maggio 2011 0.48
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] draft-ietf-tictoc-1588overmpls-01.txt comments

Hi Peter,

Cheers, Manav

Hi Manev,

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

24/05/2011 06:41 PM

To
<[email-masked]>
cc
<[email-masked]>
Subject

----------