Re: FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Stefano,

Thanks for our comments and Sorry for delay. I will go through your comments this week and if needed will
update the draft accordingly. Will keep you posted.

Thanks
Shahram

-----Original Message-----
From: Stefano Ruffini [mailto:stefano.ruffini <at> ericsson.com] 
Sent: Monday, February 13, 2012 7:53 AM
To: Shahram Davari; manav.bhatia <at> alcatel-lucent.com; tictoc <at> ietf.org
Subject: RE: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Dear Manav, Sharham, 1588 over mpls draft Authors 

 I have collected some notes on version 02 of the 1588 over MPLS draft that may be considered for future
versions of the document. 

1) In general the draft needs some clean-up. In particular as also highlighted in previous discussions
(e.g. in Taipei) some of the aspects to be addressed are outside the scope of TICTOC, and a review with the
MPLS WG will certainly be required. For instance the description of the protocol - particularly with
respect to how layering is modeled in the behavior of an LSR. 
Section 16 (e.g. the description of LER behavior in section 16.1) should be among the main parts to be
checked by the MPLS WG. 
The CCAMP WG should also be involved in the review . 

2) There is a serious mismatch between what is currently in the introduction and what the rest of the draft
includes. Most notably, the introduction seems to imply that only 1588 PTP messages are transported
while it is clear from the abstract and in subsequent sections (10 and 16, particularly) that other
message types may also be transported on the same LSP. 
In addition more information should be added with respect to the required routing and signaling
extensions. In particular the introduction should list at least well-known and commonly used routing
and signaling protocols, including those for which the draft currently defines extensions and why
others are considered out of scope. 

3) Section 3 and 4 could be expanded to better explain the various 1588 network scenarios and applicability
of the draft to these scenarios .
In fact , although as explained in section 4, the main scenario of interest for this draft is with LSRs
implementing (E2E?) TC, and BC implemented in the LERs, it seems that other scenarios could be of interest
or at least the applicability of the draft could be better clarified (e.g. indicating the benefits, if
any, in using the features described in the draft).
 For instance some of the scenarios that should be considered are: 
- BC in the LERs, and 1588 unaware LSRs
- BC in the LERs, and LSRs with P2P TC 
- Boundary clocks in every node, which is currently the main scenario being studied in ITU-T. 

Finally, assuming the TC layer violation is addressed by terminating the PTP at every hop (i.e. also in the
LSR-TC), how would this case be addressed by the draft ?

4) The Introduction reads: 
"This document provides two methods for transporting PTP messages over MPLS. One is principally focused
on an IP/MPLS environment and the second is focused on the MPLS-TP environment."
Section 6.1. explains that the mapping described in this section is suitable for IP/MPLS networks.
A similar consideration should be added in 6.2 as relevant for MPLS-TP. For instance the MPLS-TP related
assumptions should be made clear in this section. Perhaps title of these sections might be revised. 

5) Section 5 
The discussion on using P2P or P2MP LSP ("The PTP LSP between Master Clocks and Slave Clocks MAY be P2MP or P2P
LSP while the PTP LSP between
   each Slave Clock and Master Clock SHOULD be P2P LSP.") could be described more in detail (e.g. adding the
rationales) or perhaps removed. It may also be related to the specific profile used.  

6) Section 14.1 and 14.2: 
only 1 bit is currently defined (C) for the 1588aware link capability information
If relevant (see also comment 3), the authors could consider to distinguish already at this stage several
cases (E2E TC, P2P TC, BC, etc.), allocating more bits, rather than leaving everything for future use.

7) Section 16.3
The definition of "non-1588-aware LSR" may need to be revised: the current definition seems to mix the
capability of handling PTP packets with the capability of handling the RSVP-TE extensions. I think it
would be better to use different terms for these cases.

Best Regards
Stefano