Re: [TICTOC] Comments about draft-ietf-tictoc-1588overmpls-04

["Shahram Davari" <[e-mail]>]

Hi Tal,

I think I have addressed all your comments one way or another.  Please see my response inline.

Thanks
Shahram

From: Tal Mizrahi [mailto:[e-mail]]
Sent: Tuesday, February 26, 2013 6:53 AM
To: Shahram Davari; Bhatia, Manav (Manav) ([e-mail]); [e-mail]
Subject: Comments about draft-ietf-tictoc-1588overmpls-04

Hi Shahram, Manav,

Thanks for tolerating my exhausting comments. :)
I believe in draft 04 you addressed most of the major issues I raised.

I am quoting below some of my comments about draft 03 that I believe are still not addressed in draft 04.
I am sure most of them are just a slip, but if you disagree with some of them I will appreciate if you can respond.

Thanks,
Tal.


Quoting comments about draft 03 that were not fully addressed (quoting from http://www.ietf.org/mail-archive/web/tictoc/current/msg01326.html):


1.       The IEEE 1588 uses the term "port". Each PTP "port" has a state, which can be master, slave, or passive. The state is determined according to the BMC algorithm. The BMC algorithm determines whether a port is a slave or a master based on the announce messages received through this port.
In the current draft, I assume a "port" is in fact defined by a specific timing LSP (corresponding to a specific peer BC/OC), and the set of Announce messages received through it. This implies that Announce messages must either be sent through the timing LSP, or somehow be traceable to a specific timing LSP. This must be well defined in the document to allow consistent implementations.

SD> I have added the following text to end of page 11. I think this should be enough and I don't think we need to go to details of what is equivalent to a  PTP port in MPLS. Please let me know if you still need more text and if so please propose the required text.


"   PTP Announce messages that determine the Timing LSP terminating point
   behavior such as BC/OC/TC SHOULD be transported over the Timing LSP
   to simplify hardware and software."



2.       Section 19 currently suggests a few possible solutions. It is important that this document will define a single solution.
SD> I have made Single-hop LSP as SHOULD and other methods as MAY.



3.       Some terms in the document are used inconsistently, for example, the terms "time-stamping" and "timestamping" are used intermittently.

SD> I tried to fixed them . Seems we have still some inconsistencies. I will fix them for next version.


4.       There is some inconsistency about capitalization, for example, the word "Timing" is sometimes capitalized and sometimes not. Since you are using the term "Timing messages" quite often, I would suggest to add it to the terminology section, and to be consistent about its capitalization, whereas if the word "timing" is used on its own lowercase letters would be more appropriate.
SD> I tried to fixed them . Seems we have still some inconsistencies. I will fix them for next version.


5.        "...NTP messages for clock and time synchronization.  The PTP..." --> "...NTP messages for clock and time synchronization. The NTP..."

SD> Will correct in next version


6.       It appears that some of the sections are only applicable to PTP (e.g., Section 4, Section 18, Section 19). That is reasonable, but it should be pointed out explicitly that these sections apply only to PTP.
SD> I have added the following text to page 7. Please let me know if you agree that this is enough or you need other specific text.  But bear in mind that we want to leave the possibility of NTP adding TC in future open.

Tal.