Dear Authors, et al., below are my notes to the latest version of the document. thank you for your kind consideration.
- Abstract. In last paragraph UDP/IP encapsulation presented as more preferable for IP/MPLS PSN while Ethernet PW as more preferable for MPLS-TP PSN. I think that applicability statements will benefit from more extensive and argumented discussion. - Section 5, third para. Since MPLS-TP is a subset of MPLS statement "The PTP LSP MAY be MPLS LSP or MPLS-TP LSP" might be not the most accurate form of expression. At the same time the fourth paragraph suggests that PTP LSP might be configured by NMS (static configuration) or signaled by RSVP-TE/GMPLS. Have to note that RSVP-TE/GMPLS signaling is applicable only to MPLS-TP PSN. IP/MPLS LSPs are LDP signaled, MPLS-TE LSPs are signaled via RSVP-TE/MPLS. - Section 6.1 Statement "In order for an LSR to process PTP messages, the PTP Label must be the top label of the label stack" implies that Facility Backup MPLS FRR should not be used for PTP LSP. Further in Section 8 suggested that FRR Backup tunnel label must be as well associated with the PTP application. I'll note that then all LSPs that to be protected by this PTP Backup will be viewed as PTP LSPs and that might be undesirable. I think that Facility Backup FRR is not practical local protection for PTP LSP. - Section 6.2, p.11, third para. A "PTP label range" is first time referred here. How this range is defined? Where it is defined - across all MPLS PSN or only along particular PTP LSP? - Section 6.2, p.11, third para "... the PW label may be the top label in the stack, such as cases where there is only one-hop between PEs or in case of PHP ..." illustrates the same as text at the top of p.12 - section 6.2, p.12 refers not to "PTP label range" but to some mechanism to associate a label, PW label, with PTP application. Are there two mechanisms to make a label into a PTP application label - static and dynamic? Where PTP Association extensions will be defined? - Section 10, p.17. s/G-ACH/G-ACh/ Will note that VCCV Type 1 Control Channel is ACH, not G-ACH. Regards, Greg ---------- Forwarded message ---------- From: <[email protected]> Date: Thu, Oct 6, 2011 at 10:23 PM Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt To: [email protected] Cc: [email protected] 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-02.txt Pages : 34 Date : 2011-10-06 This document defines the method for transporting PTP messages (PDUs) over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and 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-02.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-02.txt _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
