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 protected] [mailto:[email protected]] On Behalf Of
Bhatia, Manav (Manav)
Sent: venerdì 27 maggio 2011 0.48
To: [email protected]
Cc: [email protected]
Subject: Re: [TICTOC] draft-ietf-tictoc-1588overmpls-01.txt comments
Hi Peter,
Very valid comments. Will take care of them in the next version.
Cheers, Manav
________________________________
From: [email protected] [mailto:[email protected]]
Sent: Thursday, May 26, 2011 9.27 PM
To: Bhatia, Manav (Manav)
Cc: [email protected]
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.
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 protected]<mailto:[email protected]> |
www.zarlink.com<http://www.zarlink.com/>
<[email protected]>
Sent by: <[email protected]>
24/05/2011 06:41 PM
To
<[email protected]>
cc
<[email protected]>
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
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
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
----------
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.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
