Subject: [TICTOC] NTP in draft-ietf-tictoc-1588overmpls-04

From: Gregory Mirsky <[email-masked]>
Date: Thu, 6 Jun 2013 18:23:12 +0000

Dear Authors, et al.,
The draft-ietf-tictoc-1588overmpls-04 is currently titled as "Transporting Timing messages over MPLS Networks" and states that both timing synchronization protocols, PTP and NTP, require use of PTP LSP to transport timing messages over an MPLS network. After reading RFC 5905 I am not sure that PTP LSP, with its constraints and additional complexity, is required to transport NTPv4 messages over an MPLS network. And first paragraph in Section 3 Problem Statement of draft-ietf-tictoc-1588overmpls-04 explains motivation for the PTP as
"There is a need to transport Timing messages over MPLS networks while supporting the Transparent Clock (TC), Boundary Clock (BC) and Ordinary Clock (OC) functionality in the LER and LSRs in the MPLS network."
 but says nothing of a kind about NTP.

        Regards,
                Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 6 Jun 2013 18:44:41 +0000

Hi Greg,

Even for NTP, there is a need to detect MPLS encapsulated NTP packets and timestamp them at server nodes.  This draft allows such function. We know that TC is not defined for NTP, but this draft leaves it open for NTP to define TC if needed in the future.

Regards,
Shahram

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, June 06, 2013 11:23 AM
To: Shahram Davari; Amit Oren; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]; [email-masked]
Subject: NTP in draft-ietf-tictoc-1588overmpls-04

Dear Authors, et al.,

        Regards,
                Greg

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 7 Jun 2013 14:54:45 +0000

Greg

This version makes the mechanism more general so that in future other time-sensitive protocols
(NTP, delay measurement OAM, generic header for MPLS) could avail themselves of its timestamping/correction features.

It is true that the only real case so far is 1588.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: 06 June, 2013 21:23
To: Shahram Davari; [email-masked]; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]; [email-masked]
Subject: [TICTOC] NTP in draft-ietf-tictoc-1588overmpls-04

Dear Authors, et al.,

        Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 7 Jun 2013 15:28:25 +0000

Yaakov,
I'm rather sceptical of using "If you build it, he will come" as protocol development guiding principle. Personally I prefer KISS.

    Regards,
        Greg

________________________________
From: Yaakov Stein [mailto:[email-masked]]
Sent: Friday, June 07, 2013 7:55 AM
To: Gregory Mirsky; Shahram Davari; [email-masked]; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]; [email-masked]
Subject: RE: NTP in draft-ietf-tictoc-1588overmpls-04

Greg

Y(J)S

Dear Authors, et al.,

        Regards,
                Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 7 Jun 2013 16:00:33 +0000

Greg,

This draft was originally only for PTP, however our Area Director asked the draft to be made more generic so that it can apply to any timing protocol.

Regards,
Shahram

On Jun 7, 2013, at 8:28 AM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

Yaakov,

    Regards,
        Greg

To: Gregory Mirsky; Shahram Davari; [email-masked]<mailto:[email-masked]>; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Greg

Y(J)S

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: 06 June, 2013 21:23
To: Shahram Davari; [email-masked]<mailto:[email-masked]>; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [TICTOC] NTP in draft-ietf-tictoc-1588overmpls-04

Dear Authors, et al.,

        Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 7 Jun 2013 16:07:26 +0000

Hi Shahram,
and hence are my questions:

  *
Is proposed mechanism required to transport other timing protocols over MPLS network
  *
Is use of PTP LSP to transport NTP messages justified or not

    Regards,
        Greg

________________________________
From: Shahram Davari [mailto:[email-masked]]
Sent: Friday, June 07, 2013 9:01 AM
To: Gregory Mirsky
Cc: Yaakov Stein; Amit Oren; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]; [email-masked]
Subject: Re: NTP in draft-ietf-tictoc-1588overmpls-04

Greg,

Regards,
Shahram

Yaakov,

    Regards,
        Greg

Greg

---

From: John E Drake <[email-masked]>
Date: Fri, 7 Jun 2013 16:10:45 +0000

& Do we know to a certainty that the proposed generalizations will support all (or any) other current and future timing protocols?

Yours Irrespectively,

John

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Friday, June 07, 2013 9:07 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [TICTOC] NTP in draft-ietf-tictoc-1588overmpls-04

Hi Shahram,

  *   Is proposed mechanism required to transport other timing protocols over MPLS network
  *   Is use of PTP LSP to transport NTP messages justified or not
    Regards,
        Greg

Cc: Yaakov Stein; Amit Oren; Bhatia, Manav (Manav); Roberts, Peter (Peter); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Regards,
Shahram

    Regards,
        Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 7 Jun 2013 16:24:32 +0000

For NTP, It is not required to use this draft for transporting it over MPLS. Since NTP has not yet defined Transparent Clock, and  NTP accuracy as of now is low and does not require time stamping  in Hardware.

Regards,
Shahram

On Jun 7, 2013, at 9:08 AM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Shahram,

  *

    Regards,
        Greg

Greg,

Regards,
Shahram

Yaakov,

    Regards,
        Greg

Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 7 Jun 2013 20:27:33 +0000

We can never be sure, but we have made it general enough to be used for other timing protocols if needed.

 This draft really doesn't introduce any new protocol, it just says transport Timing over dedicated LSPs. The generalization is in companion drafts that include OSPF and RSVPTE extensions.

Regards,
Shahram

On Jun 7, 2013, at 9:32 AM, "John E Drake" <[email-masked]<mailto:[email-masked]>> wrote:

Yours Irrespectively,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Friday, June 07, 2013 9:07 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TICTOC] NTP in draft-ietf-tictoc-1588overmpls-04

Hi Shahram,

Regards,
Shahram

    Regards,
        Greg

---

From: Brian Haberman <[email-masked]>
Date: Sat, 15 Jun 2013 12:34:26 -0400

Hi Shahram,

> This draft was originally only for PTP, however our Area Director asked the draft to be made more generic so that it can apply to any timing protocol.

That is not exactly what *I* said.  I was asked the question of whether 
it was reasonable to go in this direction and my response was "it is 
worth looking into".  It is up to the WG to decide if it is worth doing.

Regards,
Brian

> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 15 Jun 2013 23:44:37 +0000

Hi Brian,

Originally this draft covered just 1588. I believe Stewart Bryant suggested that we change the draft and make it generic to apply to any timing protocol. Its then that we removed the 1588 specific routing and signaling changes from this draft and put them in a separate draft that describes those extensions (still work in progress btw).

Cheers, Manav

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Saturday, June 15, 2013 10:04 PM
> To: [email-masked]
> > This draft was originally only for PTP, however our Area 
> Director asked the draft to be made more generic so that it 
> can apply to any timing protocol.
> >
> 
> That is not exactly what *I* said.  I was asked the question 
> of whether it was reasonable to go in this direction and my 
> response was "it is worth looking into".  It is up to the WG 
> to decide if it is worth doing.
> 
> Regards,
> Brian
> 
> > Regards,
> > Shahram
> >
> >
> > On Jun 7, 2013, at 8:28 AM, "Gregory Mirsky" 
> <[email-masked]<mailto:[email-masked]
> m>> wrote:
> >
> > Yaakov,
> > I'm rather sceptical of using "If you build it, he will 
> come" as protocol development guiding principle. Personally I 
> prefer KISS.
> >
> >      Regards,
> >          Greg
> >
> > To: Gregory Mirsky; Shahram Davari; 
> > [email-masked]<mailto:[email-masked]>; Bhatia, 
> Manav (Manav); 
> > Roberts, Peter (Peter); 
> [email-masked]<mailto:[email-masked]>; 
> > [email-masked]<mailto:[email-masked]>
> > This version makes the mechanism more general so that in 
> future other 
> > time-sensitive protocols (NTP, delay measurement OAM, 
> generic header for MPLS) could avail themselves of its 
> timestamping/correction features.
> >
> > From: [email-masked]<mailto:[email-masked]> 
> > [mailto:[email-masked]] On Behalf Of Gregory Mirsky
> > To: Shahram Davari; [email-masked]<mailto:[email-masked]>; 
> > Bhatia, Manav (Manav); Roberts, Peter (Peter); 
> > [email-masked]<mailto:[email-masked]>; 
> > [email-masked]<mailto:[email-masked]>
> > The draft-ietf-tictoc-1588overmpls-04 is currently titled as 
> > "Transporting Timing messages over MPLS Networks" and 
> states that both timing synchronization protocols, PTP and 
> NTP, require use of PTP LSP to transport timing messages over 
> an MPLS network. After reading RFC 5905 I am not sure that 
> PTP LSP, with its constraints and additional complexity, is 
> required to transport NTPv4 messages over an MPLS network. 
> And first paragraph in Section 3 Problem Statement of 
> draft-ietf-tictoc-1588overmpls-04 explains motivation for the 
> PTP as "There is a need to transport Timing messages over 
> MPLS networks while supporting the Transparent Clock (TC), 
> Boundary Clock (BC) and Ordinary Clock (OC) functionality in 
> the LER and LSRs in the MPLS network."