Subject: [TICTOC] FW: I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 7 Oct 2011 11:18:22 +0530

Hi Tictocers,

This version incorporates whatever comments we had recived till date. Would appreciate if the WG can review this updated version.

Cheers, Manav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 07, 2011 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

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-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: [email-masked]
Date: Tue, 11 Oct 2011 11:37:20 -0400

Hi Manav,

Thanks for incorporating most of my comments into the latest draft.

A couple points / questions.

1) In section 13 (UDP Checksum Correction), would recommend to clarify 
that the CF update only applies in the TC case.

2) In section 4, there is also a type "SO" -> "So" in the third sentence.

3) In section 4, there is text "Perhaps a pciture would be good here". 
Probably a placeholder for a future diagram.

4) In section 4, there is a comment that OC and BC would reside within 
LERs and TCs would reside with LSRs.  Unfortunately I'm not too familiar 
with MPLS routing concepts.  How does this fit with the comment in section 
7 "PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks 
(i.e.  Master, Slave,  Boundary, or Transparent) and MAY be transported 
over single hop PTP LSPs.".

Would it be correct to say that for PTP messages exchanged between 
peer-delay BC and peer-delay BC within LSRs, that a single hop PTP LSP 
would be used?  I think this is related to section 1 where peer-to-peer 
boundary clocks are not listed (some folks think this mode is supported in 
IEEE 1588-2008, although not explicitly defined).  I know ITU is 
considering peer-delay BCs for the distribution of time, in which case I 
would think the BC is within each LSR as one possible use case.

Thanks, 
ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]  | www.zarlink.com

"Bhatia, Manav (Manav)" <[email-masked]> 
Sent by: <[email-masked]>
07/10/2011 01:48 AM

To
"[email-masked]" <[email-masked]>
cc

Subject
[TICTOC] FW:  I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Hi Tictocers,

This version incorporates whatever comments we had recived till date. 
Would appreciate if the WG can review this updated version.

Cheers, Manav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Friday, October 07, 2011 10:53 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

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

---

From: Jack Kohn <[email-masked]>
Date: Tue, 11 Oct 2011 21:41:58 +0530

Peter,

> 4) In section 4, there is a comment that OC and BC would reside within LERs
> and TCs would reside with LSRs.  Unfortunately I'm not too familiar with
> MPLS routing concepts.  How does this fit with the comment in section 7
> "PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks (i.e.
>  Master, Slave,  Boundary, or Transparent) and MAY be transported over
> single hop PTP LSPs.".
>

> peer-delay BC and peer-delay BC within LSRs, that a single hop PTP LSP would
> be used?  I think this

Yes, i think this is correct.

> is related to section 1 where peer-to-peer boundary clocks are not listed
> (some folks think this mode is supported in IEEE 1588-2008, although not
> explicitly defined).  I know ITU is considering peer-delay BCs for the
> distribution of time, in which case I would think the BC is within each LSR
> as one possible use case.
>
>
Jack

---

From: [email-masked]
Date: Tue, 11 Oct 2011 17:17:22 -0400

Thanks Jack.

I think extending this to say that if we use a BC chain (a BC in each LSR) 
to propogate the timing information, then all the PTP messages (general & 
event) would be single-hop PTP LSPs between the BCs.  This is one specific 
use case.

Section 4 describes another use case, where we use a TC chain (a TC in 
each LSR) to propogate the timing information, where the OC/BC are only in 
the LER.

Perhaps both use cases could be described in section 4.

Regards,

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

Jack Kohn <[email-masked]> 
11/10/2011 12:13 PM

To
<[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-02.txt

Peter,

Would it be correct to say that for PTP messages exchanged between 
peer-delay BC and peer-delay BC within LSRs, that a single hop PTP LSP 
would be used?  I think this 

is related to section 1 where peer-to-peer boundary clocks are not listed 
(some folks think this mode is supported in IEEE 1588-2008, although not 
explicitly defined).  I know ITU is considering peer-delay BCs for the 
distribution of time, in which case I would think the BC is within each 
LSR as one possible use case. 

Jack

---

From: [email-masked]
Date: Tue, 25 Oct 2011 12:38:39 -0400

Hi Manav et al,

I'm also wondering if we need to fill out something similar to IEEE 
1588-2008 Annex D-F, or include such information in this document.

For example, the protocol address used for the portAddress.

The Annex D - F seem to have generally the same structure.

Annex E Transport of PTP over UDP over IPv4
D.1 General
D.2 UDP port numbers
D.3 IPv4 multicast addresses
D.4 transportSpecific field values
D.5 Optional values
D.6 IPv4 Options
D.7 Protocol addresses

Annex E Transport of PTP over UDP over IPv6
E.1 General
E.2 UDP port numbers
E.3 IPv6 multicast addresses
E.4 transportSpecific field values
E.5 Optional values
E.6 Protocol addresses

Annex F Transport of PTP over IEEE 802.3/Ethernet
F.1 General
F.2 Ethertype
F.3 Multicast MAC Addresses
F.4 transportSpecific field values
F.5 Optional values
F.6 Protocol addresses

Microsemi Corporation
Peter Meyer
Timing & Synchronization
Communication and Medical Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]  | www.zarlink.com

To

Subject

Hi Tictocers,

Cheers, Manav