FYI ________________________________ From: Shahram Davari [mailto:[email protected]] Sent: Thursday, November 17, 2011 11:14 PM To: Greg Mirsky; Bhatia, Manav (Manav); Amit Oren; [email protected]; Roberts, Peter (Peter) Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt
Hi Greg, Here are our suggested resolution to your comments. Please let us know whether they are satisfactory. Thx Shahram ---------- Forwarded message ---------- From: Greg Mirsky <[email protected]<mailto:[email protected]>> Date: Wed, Oct 12, 2011 at 2:16 PM Subject: RE: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt To: [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> 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. SD> suggest simply removing the last paragraph from the Abstract. * 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. SD> Suggest adding the following clarification: "MPLS or MPLS-TP LSP may be used. The LSPs are P2P (not P2MP) and that they could be unidirectional or co-routed bidirectional LSPs. The setup could use either manual configuration or RSVP-TE." * 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. SD> A dedicated FRR tunnel only carries PTP LSPs and therefore the issue you mention won't arise. We suggest clarification by adding this text: "FRR tunnel that use PTP label shall only carry PTP LSPs." * 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? SD> This is a typo and is a remainder from first version. We will remove the term Range. * 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 SD> Suggestion is to delete Para 3 of section 6.2 since it is redundant. * 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? SD> Type. We will delete the term Range. * Section 10, p.17. s/G-ACH/G-ACh/ Will note that VCCV Type 1 Control Channel is ACH, not G-ACH. SD> Typo. Will correct as per your suggestion. Regards, Greg ---------- Forwarded message ---------- From: <[email protected]<mailto:[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]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
