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
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
