Resending
Comments appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: Greg Mirsky <[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], [email protected], [email protected],
[email protected], [email protected], [email protected],
[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.
   - 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

Reply via email to