Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

From: "Shahram Davari" <[email-masked]>
Date: Tue, 4 Jun 2013 23:39:48 +0000

Hi Peter,

Thanks for your god comments. Please see my responses inline. Please let me know whether you are satisfied with my responses since I am updating the draft in the next couple of days.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

Some comments on draft -04.

1) Section 3.  "A generic method is defined in this document that does
not require deep packet inspection at line rate, and can
deterministically identify Timing messages.  The generic method is
applicable to MPLS and MPLS-TP networks."

May want to add that this would apply only to one-step TC (I imagine
that is the point of the correction at line rate).  A two-step TC would
need to do deep packet inspection as it uses sourcePortIdentity &
sequenceId fields for Follow_up or Delay_Resp.

SD> For 2-step, all that is needed is for an interface to detect the Timing message (based on top MPLS Label)  and record the Time along with some information from the Timing packet and send them to CPU while forwarding the Timing message as usual. Then the CPU based on the information received generates Follow-up message and injects it in to the LSP.  Therefore it is the job of CPU to look at sourcePortIdentity & sequenceId fields not the Hardware.

2) Section 4.  "An MPLS domain can serve multiple customers.  This means
that the MPLS domain (maintained by a service provider) may provide
timing services to multiple customers, each having their own Timing
domain.  Therefore LER BCs need to interact with multiple grandmasters,
and consequently multiple time references."

This should be re-phrased.  It switches from an optional situation ("may
provide timing services") to mandatory situation ("LER BCs need to
interact").   Some words such as "in such a deployment scenario, ...."
and replace "can" with "may".   We have seen at ITU at least (with
participation from operators BT, FT, DT, CMCC, AT&T, Sprint, etc.) that
this multiple operator domain case was not useful enough to be included
in standardization process for Telecom networks.

SD> I rephrased it as following:

" An MPLS domain can serve multiple customers.  This means that the
   MPLS domain (maintained by a service provider) may provide timing
   services to multiple customers, each having their own Timing domain.
   Therefore in such deployment scenarios, LER BCs may interact with multiple grandmasters, 
and consequently multiple time references.  Also, LER/LSR TCs MUST be synchronized to the 
same master clock (which is the service provider Master clock), which implies that they need 
to choose one master to synchronize to."

3) Section 19.  "For transporting such peer delay measurement messages a
single-hop LSP SHOULD to be created between the two adjacent LSRs
engaged in peer delay measurement to carry peer delay measurement
messages. Other methods such as PTP transport over Ethernet MAY be used
for transporting peer delay measurement messages if the link between the
two routers is Ethernet."

This new statement to handle peer-delay (which in earlier drafts did not
have a communication path listed), also allows a BC to be embedded in an
LSR with a communication path between BC's as a single-hop LSP
(mentioned March 22, 2012 in my feedback to draft -03, subject "[TICTOC]
Updated 1588 over MPLS draf-03").

SD> When a single-hop LSP is created then I call the both ends of that LSP, LERs and not LSRs.
Note that a router can act as LSR for some LSPs and LER for other LSPs. The point is that we can't
Terminate a packet in the middle of an LSP (i.e., in an LSR). So BC functionality can't exist in the middle
Of a PTP LSP. So I think it is a matter of terminology otherwise I agree that you could have BC in the core
(not edge). 

Architecture diagrams Figure 1 and Figure should be updated to reflect
the possibility of either BC or TC implementation.   Section 18.2 and
section 18.3 and section 21 should also be updated to reflect the
possibility of either BC or TC.  I understand the RFC is intended to be
generic and not targeted only at TC.

4) Section 20.  "When the MPLS network (provider network) serves
multiple customers, it is important to maintain and process each
customers clock and Timing messages separately from other customers to
ensure there is no cross- customer effect.   For example if an LER BC is
synchronized to a specific grandmaster, belonging to customer A, then
the LER MUST use that BC clock only for customer A to ensure that
customer A cannot attack other customers by manipulating its time."

This seems much more applicable to the TC LSR and should be stated.
>From section 4 we see the TC uses the primary synchronization domain
(that of the service provide) to correct PTP messages.

SD> I don't see how in a TC LSR, one customer timing can affect other customer timings?
Since in a TC, we just update the Timestamp of a packet based on the Service provider Time.
May be I have not understood your point. Could you please clarify with an example.

5) Section 20.  "Timing messages (as opposed to regular customer data)
SHOULD not be encrypted or authenticated on an end-to-end basis."  I
think there is a security draft in parallel being developed that may be
relevant to that statement.

SD> I have updated the  text as following:

" Timing messages MAY be encrypted or authenticated, provided that the LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the timing messages."

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: February 23, 2013 2:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.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 Timing messages over MPLS
Networks
	Author(s)       : Shahram Davari
                          Amit Oren
                          Manav Bhatia
                          Peter Roberts
                          Laurent Montini
	Filename        : draft-ietf-tictoc-1588overmpls-04.txt
	Pages           : 36
	Date            : 2013-02-22

Abstract:
   This document defines the method for transporting Timing messages
   such as PTP and NTP 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 Timing messages inside dedicated MPLS
   LSPs.  These LSPs only carry timing messages and possibly Control and
   Management packets, but they do not carry customer traffic.

   Two methods for transporting Timing messages over MPLS are defined.
   The first method is to transport Timing messages directly over the
   dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for
   MPLS networks.  The second method is to transport Timing messages
   inside a PW via Ethernet encapsulation, which is suitable for both
   MPLS and MPLS-TP networks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588overmpls-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 00:57:56 +0000

Hi Yaakov,

Thanks for your great comments, please see my response inline.

Thx
Shahram

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Monday, March 11, 2013 8:26 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Shahram

A few more comments.

First, I don't like the terminology "both MPLS and MPLS-TP".
MPLS-TP is MPLS too. And in any case "environments" (in the plural).

SD> I have removed such text and replaced it with MPLS/MPLS-TP

"Extensions to signaling protocols (e.g., RSVP-TE) are required"
well, you COULD set them up manually, in which case no extensions are required.

SD> I have changed the text to" If singling is used then extension to signaling is required ...."

Section 5 GAL/ACH -> GAL/G-Ach (and throughout the document you have various mis-spellings of G-Ach)

SD> Done

In section 6.2 you require the Ethernet to be tagged, and in fact to be double tagged.
Since we now have an offset from BoS to the TC, why is this required ?
I realize that we want to limit the number of different encaps to be supported,
but I believe this is too harsh a limitation.
And why must the tagged mode of 4448 be used ?  
You can have tags and still use raw mode.

SD> I made both tags optional and also optional to use Raw or tagged mode

Section 6.3 - If NTP or some new method is used, 
with which part of the packet is the timestamp associated ?
Also "the control and signaling requirements in this document are defined ..."
needs to be removed (they are NOT defined here any more).

SD> I don't understand your comment that says " with which part of the packet is the timestamp associated ?" could you please clarify.

Section 7: technically a TC is not a timestamp, it is a time difference.
Also updating the TC is not time-stamping either.

SD> I have changed the text to state " time-stamping or correction field update"

I see that in Section 8 the recommendation regarding protection switching is SHOULD be used.
As you know I don't agree, but let's see if the WG agrees to this in LC.
Taking my view to the extreme, why outlaw ECMP in Section 9?
I agree with ruling it out, but if you allow protection switching, then why not ECMP?
Properly performed TC will remove the major portion of the delay differences.

SD> We could rephrase as:

" Therefore this specification recommends that protection
   switching SHOULD NOT be used, unless the operator knows that the
   protection switching does NOT have adverse effect on the slave clock."

SD> But both mean the same thing.

Section 11: entropy -> entropy label

Perhaps sections 14 and 15 can be combined. I am not sure which way is better.

SD> Done

If I remember the last meeting correctly, 
we asked for the signaling material to be mentioned in an Appendix.
Here it is in Sections 16 and 17.
I am not sure that this is terrible, but I don't think these belong in the body of a PS draft.

SD> Done, both moved to Appendix

Section 19 ware -> aware, it needs -> they need

SD> Done

I am not sure we need the applicability statement.

SD> Applicability statement removed

In the Acknowledgements: Luca Moniti -> Luca Martini

SD> Done

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: 12 March, 2013 02:59
To: Meyer, Peter; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Good feedback. I will update the draft after the Orlando to include your comments.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Meyer, Peter" <[email-masked]>
Date: Wed, 5 Jun 2013 14:00:37 -0400

Hi Shahram,

I hope in-line with my comments I have edited the text of draft -04.

I'm not sure how the formatting worked out (PC-based, line length, page
length).

I modified sections 3, 4, 18, 19 & 20.

I include here both original and modified version so you can diff (most
of the changes in 3 are due to line length / re-org, not actual text
changes).

File attachment:
"draft-ietf-tictoc-1588overmpls-04-org.txt" (52 KB)
"draft-ietf-tictoc-1588overmpls-04-pm.txt" (53 KB)

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks for your god comments. Please see my responses inline. Please let
me know whether you are satisfied with my responses since I am updating
the draft in the next couple of days.

Thanks
Shahram

-----Original Message-----
Of Meyer, Peter

Hi Shahram et al,

SD> For 2-step, all that is needed is for an interface to detect the
Timing message (based on top MPLS Label)  and record the Time along with
some information from the Timing packet and send them to CPU while
forwarding the Timing message as usual. Then the CPU based on the
information received generates Follow-up message and injects it in to
the LSP.  Therefore it is the job of CPU to look at sourcePortIdentity &
sequenceId fields not the Hardware.

" An MPLS domain can serve multiple customers.  This means that the
   MPLS domain (maintained by a service provider) may provide timing
   services to multiple customers, each having their own Timing domain.
   Therefore in such deployment scenarios, LER BCs may interact with
multiple grandmasters, 
and consequently multiple time references.  Also, LER/LSR TCs MUST be
synchronized to the 
same master clock (which is the service provider Master clock), which
implies that they need 
to choose one master to synchronize to."

SD> When a single-hop LSP is created then I call the both ends of that
LSP, LERs and not LSRs.
Note that a router can act as LSR for some LSPs and LER for other LSPs.
The point is that we can't
Terminate a packet in the middle of an LSP (i.e., in an LSR). So BC
functionality can't exist in the middle
Of a PTP LSP. So I think it is a matter of terminology otherwise I agree
that you could have BC in the core
(not edge). 

SD> I don't see how in a TC LSR, one customer timing can affect other
customer timings?
Since in a TC, we just update the Timestamp of a packet based on the
Service provider Time.
May be I have not understood your point. Could you please clarify with
an example.

" Timing messages MAY be encrypted or authenticated, provided that the
LERs/LSRs that are Timing capable/aware can authenticate/ decrypt the
timing messages."

Regards,
Peter

-----Original Message-----

Abstract:

---

From: Stefano Ruffini <[email-masked]>
Date: Wed, 5 Jun 2013 18:30:30 +0000

Hi Shahram, Peter

There is one point I would disagree with (I am referring to Peter's latest proposal, but the same comment would apply to the previous text):
"
An MPLS domain may serve multiple customers.  In these cases the
   MPLS domain (maintained by a service provider) may provide timing
   services to multiple customers, each having their own Timing domain.
   If so, then the LER BCs and TCs may interact with multiple grandmasters,
   and consequently multiple time references.  Also, LER/LSR TCs MUST be
   synchronized to the same master clock (which is the service provider
   Master clock), which implies that they need to choose one master to
   which it will synchronize.
"

My understanding of this statement is that a LER would need to implement multiple BC instances (with multiple clocks); this looks too complex.

The case of multiple operators, seems to me only practically applicable to figure 3 (LER TC).

I would then propose to remove the reference to LER BC in this statement .

Best regards
stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: mercoledì 5 giugno 2013 20:01
To: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

I'm not sure how the formatting worked out (PC-based, line length, page length).

I include here both original and modified version so you can diff (most of the changes in 3 are due to line length / re-org, not actual text changes).

File attachment:
"draft-ietf-tictoc-1588overmpls-04-org.txt" (52 KB) "draft-ietf-tictoc-1588overmpls-04-pm.txt" (53 KB)

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

1) Section 3.  "A generic method is defined in this document that does not require deep packet inspection at line rate, and can deterministically identify Timing messages.  The generic method is applicable to MPLS and MPLS-TP networks."

May want to add that this would apply only to one-step TC (I imagine that is the point of the correction at line rate).  A two-step TC would need to do deep packet inspection as it uses sourcePortIdentity & sequenceId fields for Follow_up or Delay_Resp.

SD> For 2-step, all that is needed is for an interface to detect the
Timing message (based on top MPLS Label)  and record the Time along with some information from the Timing packet and send them to CPU while forwarding the Timing message as usual. Then the CPU based on the information received generates Follow-up message and injects it in to the LSP.  Therefore it is the job of CPU to look at sourcePortIdentity & sequenceId fields not the Hardware.

2) Section 4.  "An MPLS domain can serve multiple customers.  This means that the MPLS domain (maintained by a service provider) may provide timing services to multiple customers, each having their own Timing domain.  Therefore LER BCs need to interact with multiple grandmasters, and consequently multiple time references."

This should be re-phrased.  It switches from an optional situation ("may provide timing services") to mandatory situation ("LER BCs need to
interact").   Some words such as "in such a deployment scenario, ...."
and replace "can" with "may".   We have seen at ITU at least (with
participation from operators BT, FT, DT, CMCC, AT&T, Sprint, etc.) that this multiple operator domain case was not useful enough to be included in standardization process for Telecom networks.

" An MPLS domain can serve multiple customers.  This means that the
   MPLS domain (maintained by a service provider) may provide timing
   services to multiple customers, each having their own Timing domain.
   Therefore in such deployment scenarios, LER BCs may interact with multiple grandmasters, and consequently multiple time references.  Also, LER/LSR TCs MUST be synchronized to the same master clock (which is the service provider Master clock), which implies that they need to choose one master to synchronize to."

3) Section 19.  "For transporting such peer delay measurement messages a single-hop LSP SHOULD to be created between the two adjacent LSRs engaged in peer delay measurement to carry peer delay measurement messages. Other methods such as PTP transport over Ethernet MAY be used for transporting peer delay measurement messages if the link between the two routers is Ethernet."

This new statement to handle peer-delay (which in earlier drafts did not have a communication path listed), also allows a BC to be embedded in an LSR with a communication path between BC's as a single-hop LSP (mentioned March 22, 2012 in my feedback to draft -03, subject "[TICTOC] Updated 1588 over MPLS draf-03").

SD> When a single-hop LSP is created then I call the both ends of that
LSP, LERs and not LSRs.
Note that a router can act as LSR for some LSPs and LER for other LSPs.
The point is that we can't
Terminate a packet in the middle of an LSP (i.e., in an LSR). So BC functionality can't exist in the middle Of a PTP LSP. So I think it is a matter of terminology otherwise I agree that you could have BC in the core (not edge). 

Architecture diagrams Figure 1 and Figure should be updated to reflect
the possibility of either BC or TC implementation.   Section 18.2 and
section 18.3 and section 21 should also be updated to reflect the possibility of either BC or TC.  I understand the RFC is intended to be generic and not targeted only at TC.

4) Section 20.  "When the MPLS network (provider network) serves multiple customers, it is important to maintain and process each customers clock and Timing messages separately from other customers to
ensure there is no cross- customer effect.   For example if an LER BC is
synchronized to a specific grandmaster, belonging to customer A, then the LER MUST use that BC clock only for customer A to ensure that customer A cannot attack other customers by manipulating its time."

>From section 4 we see the TC uses the primary synchronization domain (that of the service provide) to correct PTP messages.

5) Section 20.  "Timing messages (as opposed to regular customer data) SHOULD not be encrypted or authenticated on an end-to-end basis."  I think there is a security draft in parallel being developed that may be relevant to that statement.

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: February 23, 2013 2:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.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.

Abstract:

---

From: "Meyer, Peter" <[email-masked]>
Date: Wed, 5 Jun 2013 15:21:05 -0400

Hi Stefano,

I see Figure 3 and Figure 4 apply to the text above the figures, unrelated to multiple domains.

I see the multiple domain paragraph as a separate topic, perhaps could be its own sub-section.  We have seen systems that support multiple domains either as BC or TC.  I could support removal of the mention of multiple operator domains in total, if that is agreeable.  Otherwise I see BC and TC as both valid solutions available in the market today.

Regards,
Peter

-----Original Message-----
From: Stefano Ruffini [mailto:[email-masked]] 
Sent: June 5, 2013 2:31 PM
To: Meyer, Peter; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram, Peter

Best regards
stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: mercoledì 5 giugno 2013 20:01
To: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: February 23, 2013 2:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.txt

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 21:31:38 +0000

Thanks Peter. 

These edits where done before the publishing of draft-04. Correct?

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Meyer, Peter" <[email-masked]>
Date: Wed, 5 Jun 2013 17:48:27 -0400

Hi Shahram,

I took the -04 that was advertised on the exploder in February (dated
February 23, 2013).  I then edited that copy.

(I think the diff may show a ton of changes due to line length or word
wrapping).

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 22:15:37 +0000

Hi Peter,

I see that the majority of changes are related to LSR BC. I personally don't think this is possible, since we can't terminate packets in the middle of an LSP. Could you please provide an example for your suggestion of using LSR BC? How are the 1588 timing messages terminated?

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 22:18:20 +0000

Peter,

I think we have a difference in terminology. To me an LSR is a router that does Label Swap and not Label pop. May be what you have in mind is PE and P routers instead of LER and LSR. 

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Meyer, Peter" <[email-masked]>
Date: Wed, 5 Jun 2013 18:35:06 -0400

Hi Shahram,

I attempted to elaborate in section 19 Other Considerations, perhaps it
is not well written.  I tried to mirror the language that already
existed.

With the original -04 draft, section 19 covered the situation for an LSR
acting as a TC when using peer-delay messages.   An LSR would have to
generate & terminate peer-delay messages from its physical neighbour,
and the recommendation was to use a single-hop LSP.  With your
terminology, if I am using it correctly, the Sync messages are switched
through the LSR without termination.   However, this is not allowed for
peer-delay messages which must be terminated for the TC to function
properly.

"  For transporting such peer delay measurement messages a single-hop
   LSP SHOULD to be created between the two adjacent LSRs engaged in
   peer delay measurement to carry peer delay measurement messages.
   Other methods such as PTP transport over Ethernet MAY be used for
   transporting peer delay measurement messages if the link between the
   two routers is Ethernet.  "

I use this same approach for an LSR acting as a BC.   A BC inside an LSR
is the same as a peer-delay TC inside an LSR.  The LSR would have to
generate & terminate end-to-end messages from its physical neighbour. I
modified the section to recommend a single-hop LSP for this purpose.

"  Likewise for BCs embedded in an LSR, a single-hop LSP SHOULD be 
   created between the two adjacent LSRs that are acting as BCs.  Other
   methods such as PTP transport over Ethernet MAY be used if the link
   between the two routers is Ethernet.  "

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

I think we have a difference in terminology. To me an LSR is a router
that does Label Swap and not Label pop. May be what you have in mind is
PE and P routers instead of LER and LSR. 

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

I see that the majority of changes are related to LSR BC. I personally
don't think this is possible, since we can't terminate packets in the
middle of an LSP. Could you please provide an example for your
suggestion of using LSR BC? How are the 1588 timing messages terminated?

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 22:42:41 +0000

Hi Peter,

Thanks, now I get it.  I will update the draft as per your suggestion.

Thx
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 3:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 23:03:58 +0000

Peter,

Could you please also explain why the 2 step won't work with the method in this draft.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Wednesday, June 05, 2013 3:43 PM
To: Meyer, Peter; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thx
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 3:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Meyer, Peter" <[email-masked]>
Date: Wed, 5 Jun 2013 19:21:49 -0400

Hi Shahram,

I think you are referring to section 3 

"   A generic method is defined in this document that does not require
   deep packet inspection at line rate, and can deterministically
   identify Timing messages, for one-step mode of operation.  The 
   generic method is applicable to MPLS and MPLS-TP networks."

I was not intending to indicate two-step would not work.   I was
intending to highlight the important benefit of this document is
specifically to enable one-step capability more easily.  Without this
specification one-step is more difficult due to the need for deep packet
inspection.  Two-step would probably not benefit as much as a result of
this specification.

If I have not worded correctly, it can be removed/changed back to
original.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 7:04 PM
To: Shahram Davari; Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Could you please also explain why the 2 step won't work with the method
in this draft.

Thx
Shahram

-----Original Message-----
Of Shahram Davari

Hi Peter,

Thx
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 3:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 23:32:13 +0000

How about rephrasing it as following:

"   A generic method is defined in this document that does not require
   deep packet inspection at line rate, and can deterministically
   identify Timing messages. This method is specifically beneficial for 1-step 
 Transparent Clocking operation described in [IEEE-1588], while it also supports 
2-Step Transparent Clocking."

Thx
SD

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 4:22 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 7:04 PM
To: Shahram Davari; Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----

Hi Peter,

Thx
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 3:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Meyer, Peter" <[email-masked]>
Date: Wed, 5 Jun 2013 19:35:07 -0400

Slightly modified ......

"   A generic method is defined in this document that does not require
   deep packet inspection at line rate, and can deterministically
   identify Timing messages. This method is specifically beneficial for
1-step 
 Transparent Clock operation described in [IEEE-1588].   
2-Step Transparent Clock operation, Ordinary Clock operation and
Boundary Clock operation are also supported."

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 7:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

"   A generic method is defined in this document that does not require
   deep packet inspection at line rate, and can deterministically
   identify Timing messages. This method is specifically beneficial for
1-step 
 Transparent Clocking operation described in [IEEE-1588], while it also
supports 
2-Step Transparent Clocking."

Thx
SD

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 4:22 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 7:04 PM
To: Shahram Davari; Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----

Hi Peter,

Thx
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 3:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 5 Jun 2013 23:37:08 +0000

Great. Done.  

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 4:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Slightly modified ......

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 7:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thx
SD

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 4:22 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 7:04 PM
To: Shahram Davari; Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----

Hi Peter,

Thx
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 3:35 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Hope this makes sense.

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 6:18 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Peter,

Thx
Shahram

-----Original Message-----
From: Shahram Davari 
Sent: Wednesday, June 05, 2013 3:16 PM
To: 'Meyer, Peter'; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 2:48 PM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 5, 2013 5:32 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Thanks Peter. 

-Shahram

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: Wednesday, June 05, 2013 11:01 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----

Hi Shahram et al,

Regards,
Peter

-----Original Message-----

Abstract:

---

From: Stefano Ruffini <[email-masked]>
Date: Thu, 6 Jun 2013 06:39:23 +0000

Hi Peter,

The point is that while technically it might be possible, if compared with a TC, the use of BC in a multi operator context looks over complicated  (note: I am not referring to a BC connected to multiple PTP domains and that in the end must just select one of them; in this case the BC would have to actually maintain different time scales, independent datasets, run independent BMCA, etc.). This can be an issue in case where  the number of clients a provider network needs to serve is significantly high.  
At least a note with some warning could be beneficial (e.g. "Note: the applicability of a BC in the context of multiple customers may need further investigation. ")

Br
stefano

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: mercoledì 5 giugno 2013 21:21
To: Stefano Ruffini; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Stefano,

Regards,
Peter

-----Original Message-----
From: Stefano Ruffini [mailto:[email-masked]] 
Sent: June 5, 2013 2:31 PM
To: Meyer, Peter; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram, Peter

Best regards
stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: mercoledì 5 giugno 2013 20:01
To: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: February 23, 2013 2:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.txt

Abstract:

---

From: Stefano Ruffini <[email-masked]>
Date: Thu, 6 Jun 2013 06:46:31 +0000

Hi

I just saw the latest version of the draft.

I am fine with the  generic text proposed in this draft. 

Thanks
stefano

-----Original Message-----
From: Stefano Ruffini 
Sent: giovedì 6 giugno 2013 08:39
To: 'Meyer, Peter'; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Br
stefano

-----Original Message-----
From: Meyer, Peter [mailto:[email-masked]] 
Sent: mercoledì 5 giugno 2013 21:21
To: Stefano Ruffini; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Stefano,

Regards,
Peter

-----Original Message-----
From: Stefano Ruffini [mailto:[email-masked]] 
Sent: June 5, 2013 2:31 PM
To: Meyer, Peter; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram, Peter

Best regards
stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: mercoledì 5 giugno 2013 20:01
To: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: February 23, 2013 2:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.txt

Abstract:

---

From: Lars Ellegaard <[email-masked]>
Date: Thu, 6 Jun 2013 09:23:20 +0000

Hi Shahram, Peter,

I noticed a point which I disagree on. As with Stefano's comment this refers to both text proposals.
It regards the last sentence of the text block below:

"
Also, LER/LSR TCs MUST be
   synchronized to the same master clock (which is the service provider
   Master clock), which implies that they need to choose one master to
   which it will synchronize.
"

In general a TC need not be synchronized to a master. It may be so (syntonization) for increased accuracy but it is not a requirement per IEEE1588-2008. The TC may also be synchronized because the LER/LSR implementation includes OC-slave or BC functionality in addition to TC.

I suggest changing to

Also, LER/LSR TCs MAY be

Best regards,
Lars

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefano Ruffini
Sent: 05 June 2013 20:31
To: Meyer, Peter; Shahram Davari; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram, Peter

Best regards
stefano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: mercoledì 5 giugno 2013 20:01
To: Shahram Davari; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram,

File attachment:

Regards,
Peter

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: June 4, 2013 7:40 PM
To: Meyer, Peter; [email-masked]
Subject: RE: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Peter,

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meyer, Peter
Sent: Monday, March 11, 2013 5:49 PM
To: [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Shahram et al,

Regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: February 23, 2013 2:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588overmpls-04.txt

Abstract:

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 6 Jun 2013 10:25:14 +0000

Hi Lars,

I have actually removed this paragraph completely for new version.

Regards,
Shahram

---

From: Lars Ellegaard <[email-masked]>
Date: Thu, 6 Jun 2013 10:39:48 +0000

OK, thx

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: 06 June 2013 12:25
To: Lars Ellegaard
Cc: Stefano Ruffini; Meyer, Peter; [email-masked]
Subject: Re: [TICTOC] comments on draft-ietf-tictoc-1588overmpls-04.txt

Hi Lars,

Regards,
Shahram