Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 15 Jan 2011 16:25:59 +0530

Hi,

We have posted a revised version of draft-davari-tictoc-1588overmpls-01 and would appreciate a feedback from the WG.

The draft is available here:
http://www.ietf.org/id/draft-davari-tictoc-1588overmpls-01.txt

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 15 Jan 2011 12:30:24 +0100 (CET)

> http://www.ietf.org/id/draft-davari-tictoc-1588overmpls-01.txt

I am confused by:

"Note that the PTP LSPs MUST only carry PTP messages and MAY carry
    MPLS/MPLS-TP control and management messages such as BFD and LSP-
    Ping."

If it is only allowed to carry PTP messages, how can it be allowed to 
carry other traffic as well? Perhaps rephrasing is in order? "MUST NOT 
carry any traffic other than PTP messages or MPLS control and management 
messages..." ?

In section 10, I think it should be treated as control plane traffic with 
higher priority than what mostly is used for EF? Or is EF (which might 
carry a lot of voice traffic as well) enough?

In section 12-13 there is RSVP-TE and OSPF, what about ISIS?

In 14.3, is "Non-155-aware LSRs" a typo and should be "non-1588-aware" ?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 16 Jan 2011 04:56:15 +0530

Hi Mikael,

Thanks for the comments.
 
> carry any traffic other than PTP messages or MPLS control and 

We do explain this in section 9 that one MAY need to carry some OAM and management messages to manage these PTP LSPs and PTP PWs. 

> carry a lot of voice traffic as well) enough?

EF is better than the default. I don't think we can mandate AF since that would require operators to provide assurance of delivery as long as the traffic is not exceeding certain rate. Now, how does define that rate?

> In section 12-13 there is RSVP-TE and OSPF, what about ISIS?

Changes are similar to IS-IS and will get into the next version.

> In 14.3, is "Non-155-aware LSRs" a typo and should be 

Thanks for catching this. Again, will get into the next version.

Cheers, Manav

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 16 Jan 2011 07:05:22 +0100 (CET)

On Sun, 16 Jan 2011, Bhatia, Manav (Manav) wrote:

> We do explain this in section 9 that one MAY need to carry some OAM and 
> management messages to manage these PTP LSPs and PTP PWs.

Yes, I noticed. I still think that saying "X MUST be 4 (but it may also be 
3)" is a weird thing to say.

>> In section 10, I think it should be treated as control plane traffic 
>> with higher priority than what mostly is used for EF? Or is EF (which 
>> might carry a lot of voice traffic as well) enough?
>
> EF is better than the default. I don't think we can mandate AF since 
> that would require operators to provide assurance of delivery as long as 
> the traffic is not exceeding certain rate. Now, how does define that 
> rate?

I think you misunderstood.

In my world, control plane traffic (originated by the router itself) may 
have higher outgoing QoS priority than EF. AF is definitely further down 
the list of priorities, both when it comes to jitter and packet loss 
handling.

On Cisco for instance, people usually use the MQC "priority" command for 
EF, which means it's a low latency queue which is always emptied first, 
then there might be some round robin handling of other queues. Is this 
queue enough, or is it better to just handle it with low drop probability 
and just make sure the time information in the packet is accurate and the 
delay of the packet is of little importance?

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 16 Jan 2011 17:01:33 +0530

Hi Mikael,

> 3)" is a weird thing to say.

Would it work if we rephrase the text in section 4 as follows:

Old:

Note that the PTP LSPs MUST only carry PTP messages and MAY carry MPLS/MPLS-TP control and management messages such as BFD and LSP-Ping.

New:

We should be selective about the kind of traffic that flows over PTP LSPs. All PTP messages MUST only be sent on the PTP LSP. It MAY, in addition to this also carry MPLS/MPLS-TP control and management messages such as BFD and LSP-Ping.

> have higher outgoing QoS priority than EF. AF is definitely 

Yes, its probably NC.

> further down 

I am still not sure if I understood your point. Are you suggesting that all such packets be marked as NC? 

Cheers, Manav

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 16 Jan 2011 12:51:50 +0100 (CET)

On Sun, 16 Jan 2011, Bhatia, Manav (Manav) wrote:

> "We should be selective about the kind of traffic that flows over PTP 
> LSPs. All PTP messages MUST only be sent on the PTP LSP. It MAY, in 
> addition to this also carry MPLS/MPLS-TP control and management messages 
> such as BFD and LSP-Ping."

Suggestion:

"We should be selective about the kind of traffic that flows over PTP LSPs 
as these will be handled as a special case by the LSR. The only LSP user 
plane traffic MUST be PTP, but the LSP MAY also carry essential 
MPLS/MPLS-TP control plane traffic such as BFD and LSP-Ping."

Your suggestion above is fine as well, I don't have any major objections 
to it.

> all such packets be marked as NC?

I'm not talking marking at all.

When the LSR wants to send out the PTP message, should it go into the 
normal output queuing mechanism or should it just be sent out first thing, 
regardless of what the queuing configuration is (in that case, it'll beat 
EF when it comes to "importance" for output queuing).

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 16 Jan 2011 17:28:57 +0530

> Your suggestion above is fine as well, I don't have any major 

And neither do I with your text. 

Will update the next revision with the above.

> 
> > I am still not sure if I understood your point. Are you 
> suggesting that 
> > all such packets be marked as NC?
> 

Ok, I think I understand what youre alluding to. You will like implementations to send out the PTP message using the highest priority queue that's available at the egress. Is this correct?

If this is what you want, then I would disagree. While I understand the urgency to send out these packets, its way to less than all the other control traffic that needs to be sent (like BFD, LACP, EFM, etc) out. 

Cheers, Manav

---

From: "Tommy Cook" <[email-masked]>
Date: Mon, 17 Jan 2011 11:25:40 -0000

Hi Manav,

In the Terminology section, you list "BC: Border Clock, is a .....".  In
IEEE1588 what you describe is, I believe, referred to as a Boundary Clock.
Did you use a different term for a specific reason or is it simply the
terminology needs to be completely aligned?

Regards,
Tommy

==================================
Tommy Cook
CEO 
Calnex Solutions Ltd
Tel.:   +44 (0) 1506-671-416
Mob.: +44 (0) 770-4894-128
email:    [email-masked]
website: www.calnexsol.com
 
Calnex Solutions Limited is registered in Scotland: SC299625

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bhatia, Manav (Manav)
Sent: 15 January 2011 10:56
To: [email-masked]
Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi,

We have posted a revised version of draft-davari-tictoc-1588overmpls-01 and
would appreciate a feedback from the WG.

Cheers, Manav

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 17 Jan 2011 18:05:02 +0530

Hi Tommy,

This is a typo and will be fixed in the next revision.

Cheers, Manav 

> From: Tommy Cook [mailto:[email-masked]] 
> Sent: Monday, January 17, 2011 4.56 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: RE: [TICTOC] Transporting PTP messages (1588) over 
> MPLS Networks
> 
> Hi Manav,
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> Bhatia, Manav (Manav)

---

From: "Lars Ellegaard" <[email-masked]>
Date: Mon, 17 Jan 2011 16:44:50 +0100

Hi Manav et al.
A few comments/questions:

Section 2. Terminology:

* TC: Transparent Clocking --> Transparent Clock
* PTP PW: 
	Should the text read: A PW within a PTP LSP that is dedicated to carry PTP messages ?
	That at least is my understanding of the PTP PW.
  Put another way, can you have an Ethernet PW that is sometimes carrying PTP, sometimes "data"?
  More general, mustn't all labels in the stack (apart from reserved labels) be PTP labels?
* CW: duplicate

Section 5
* Figure 1+2: should top label read "PTP label", ref. section 4?

* For my understanding: the range of PTP reserved labels, is that defined by the operator?

Section 15
* last paragraph says:
"The use of Penultimate Hop Pop (PHP) is acceptable as long as either
   the PHP label is the bottom of stack label (applicable only to UDP/IP
   encapsulation) or the label below the PHP label is a PTP label."
This implies that the PHP-label is also a PTP label, right?

A more general comment: would you agree that there is a general class of tunnel technologies 
(PBB, MPLS, IPoverIP) that share the problem you have described here, and to which you found a solution for MPLS?

Thanks,
Lars

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: 17 January 2011 13:35
To: Tommy Cook
Cc: [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Tommy,

Cheers, Manav 

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Mon, 17 Jan 2011 21:46:13 +0530

Hi Lars,
 
>   Put another way, can you have an Ethernet PW that is 
> sometimes carrying PTP, sometimes "data"?

Will do.

> * Figure 1+2: should top label read "PTP label", ref. section 4?

The current text looks ok to me. Its called PTP Tunnel Label to explicitly indicate that it's the outermost label that LSRs would use to switch the packets on.

> that defined by the operator?

I am not sure I understand the reserved labels that you are referring to.
 
> (PBB, MPLS, IPoverIP) that share the problem you have 
> described here, and to which you found a solution for MPLS?

I think Yes.

Cheers, Manav

---

From: "Hing-Kam (Kam) Lam" <[email-masked]>
Date: Tue, 18 Jan 2011 05:40:01 +0530

There are a few minor nits which can be fixed in the next revision.
Otherwise, i appreciate this work and would like to see this
progressed further in the WG. Are we accepting this as a WG document
yet?

Kam

---

From: "Lars Ellegaard" <[email-masked]>
Date: Tue, 18 Jan 2011 08:44:17 +0100

Thanks, Manev.

Wrt.
> that defined by the operator?

I am not sure I understand the reserved labels that you are referring
to.

[LE] I was confused by a sentence towards the end in section 5.2: "In
such cases, the PW label SHOULD be chosen from the PTP Label range."
Looking at section 13+14 on I now understand that the binding of PTP LSP
and label is achieved via the RSVP-TE Object.

Rgds,
Lars

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: 17 January 2011 17:16
To: Lars Ellegaard
Cc: [email-masked]
Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS
Networks

Hi Lars,

Will do.

> * Figure 1+2: should top label read "PTP label", ref. section 4?

The current text looks ok to me. Its called PTP Tunnel Label to
explicitly indicate that it's the outermost label that LSRs would use to
switch the packets on.

> that defined by the operator?

I am not sure I understand the reserved labels that you are referring
to.

I think Yes.

Cheers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Tue, 18 Jan 2011 14:39:38 +0530

Yup, thats correct!

Cheers, Manav

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 18 Jan 2011 10:31:47 +0000

> If this is what you want, then I would disagree. While I understand the urgency to send out these packets, its way to less than all the other control traffic that needs to be sent (like BFD, LACP,…

I am not at all convinced that PTP traffic is in any way urgent.

What is important is that the timestamp is correct at egress and 
immediate on ingress.

The point of this draft is that PTP goes in it's own label group so that 
the h/w can identify and timestamp the PTP traffic.

Stewart

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 18 Jan 2011 17:42:01 +0530

> the h/w can identify and timestamp the PTP traffic.

Yes, that's correct. In addition to this, it also enables boxes that cant do 1588 processing to expedite processing of these packets.

Cheers, Manav

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 18 Jan 2011 16:04:21 +0200

Hi Manav,

A few comments below.

Section 3. Problem Statement says that "The defined method is applicable to both MPLS and MPLS-TP networks."
- however, Section 9. OAM, Control and Management does not mention MPLS-TP OAM. Furthermore, section 5.1. 1588 over LSP Encapsulation shows an encapsulation with a single label, and does not show that an optional GAL is possible.

6.  1588 Message Transport
"If Two Step Transparent clocks are present, then the FOLLOW_UP and DELAY_RESP messages must also be transported over the PTP LSPs." 
- for P2P TCs you also need the PDelay_Resp_Follow_Up.

10.  QoS Considerations
- I am not sure I understand why this is a MUST. This draft defines an encapsulation, while the QoS requirements are typically be derived from the application, which is defined elsewhere.

11.  FCS Recalculation
"FCS retention described in [RFC4720] MUST not be used" 
- that makes sense, but seems to contradict the first half of the sentence "Ethernet FCS MUST be recalculated at every LSR". In my understanding if retention is not used, only the LERs have to recompute the FCS. LSRs may alter the CF, but do not need to bother with the FCS.

Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Saturday, January 15, 2011 12:56 PM
To: [email-masked]
Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi,

Cheers, Manav

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 18 Jan 2011 15:45:13 +0000

Manav and co-authors, 

I just started reading the document, and have a few comments.

First, as we have stated a few times already, TICTOC is looking for a unified solution
for carrying timing flows over MPLS, not just 1588. Although this doesn't necessarily
mean that a single document explains both, if we have two separate documents,
or worse, only a 1588 document, we will not accomplish what we are intending.

Second, the following wording is not going to fly in the IETF.
   This document requires that MLPS nodes (LSRs) SHOULD be able to support TC, ...
   Such an LSR is referred to as a "1588-aware LSR" in this document.
As written this means that if this document becomes a proposed standard RFC, 
then every LSR manufactured will have to support identification of timing flows
(remember SHOULD means MUST unless there is a very good reason no to).
This, of course, means that almost every LSR will need to be "1588-aware" 
and there is no need to define the term.

I believe that what you mean to says is something like this.
   This document defines a "1588-aware LSR" that is able to identify 1588 timing flows
   carried over MPLS.

Third, and more controversially, I believe we should be more modest in our MUSTs here.
I would prefer that a "1588-aware" LSR MUST to be able to identify for prioritization,
and MAY be able to correct the correction field.

I have a few more minor comments (e.g., you speak of correcting FCS for the PW FCS retention mode 
of Ethernet PWS, but don't discuss correcting the UDP checksum (which in IPv6 is mandatory),
but prefer to clear up the major items first.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Saturday, January 15, 2011 12:56
To: [email-masked]
Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi,

Cheers, Manav

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 18 Jan 2011 18:05:38 +0200

Yaakov, 
You've said:
	
	I believe we should be more modest in our MUSTs here.
	I would prefer that a "1588-aware" LSR MUST to be able to identify [PTP traffic - Sasha] 
	for prioritization, and MAY be able to correct the correction field.

I concur with you regarding the level of requirements. 
Editorially, I think that "to correct the correction field" is an pleonasm that SHOULD be corrected.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Tuesday, January 18, 2011 5:45 PM
To: Bhatia, Manav (Manav); [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Manav and co-authors, 

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Saturday, January 15, 2011 12:56
To: [email-masked]
Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi,

Cheers, Manav

---

From: Ron Cohen <[email-masked]>
Date: Tue, 18 Jan 2011 18:06:53 +0200

A quick question: I assume that there will be LSRs which have some ports
with PTP support and some ports which are not. I think we should address
this as well. Best, Ron

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 26 Jan 2011 08:48:39 -0800

Hi Tal,

Please find my comments inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Tuesday, January 18, 2011 6:04 AM
To: Bhatia, Manav (Manav); [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Manav,

A few comments below.

SD> We could add the MPLS-TP OAM to the text. Regarding GAL, this is explicitly not allowed to be in the stack when the encapsulated data is PTP message. So GAL is not optional.

SD> AFAIK These messages don't require time stamping and therefore don't have to be transported over PTP LSP.

10.  QoS Considerations

SD> The application is PTP, which requires low delay. Are you suggesting we make it a should? 

11.  FCS Recalculation

SD> I think your understanding is not correct. 

Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Saturday, January 15, 2011 12:56 PM
To: [email-masked]
Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi,

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 26 Jan 2011 22:24:18 +0530

Hi Tal,

In addition to what Shahram has said:

> "If Two Step Transparent clocks are present, then the 
> FOLLOW_UP and DELAY_RESP messages must also be transported 
> over the PTP LSPs." 
> SD> AFAIK These messages don't require time stamping and 
> therefore don't have to be transported over PTP LSP.

The PDelay_Resp_Follow_Up message will never go through a TC and will never have its CF modified.  In the case of a non-TC PTP LSR, it is only the PDelay_Req and PDelay-Resp message that are time sensitive.  So the PDelay_Resp_Follow_Up can be sent outside of the PTP LSP.

> 
> 10.  QoS Considerations
> - I am not sure I understand why this is a MUST. This draft 
> defines an encapsulation, while the QoS requirements are 
> typically be derived from the application, which is defined elsewhere.
> 

The current text does not use a MUST. Does that look ok?

Cheers, Manav

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 26 Jan 2011 19:13:06 +0200

Hi Manav, Shahram,

>The current text does not use a MUST. Does that look ok?

The current wording is "The PTP messages are time critical and must be treated with the highest priority.", 
while the IEEE 1588 states in the informative Annex A that "PTP event messages should be sent with high priority compared with other data whenever possible."
Of course it makes sense that PTP is high priority, but the current wording seems a bit too stringent.

Thanks. 
Tal.

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 6:54 PM
To: Shahram Davari; Tal Mizrahi; [email-masked]
Subject: RE: Transporting PTP messages (1588) over MPLS Networks

Hi Tal,

Cheers, Manav

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 26 Jan 2011 09:15:51 -0800

Tal,

It is lower case "must" which is not a normative requirement. It is informative.

Thx
Shahram

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 9:13 AM
To: Bhatia, Manav (Manav); Shahram Davari; [email-masked]
Subject: RE: Transporting PTP messages (1588) over MPLS Networks

Hi Manav, Shahram,

Thanks. 
Tal.

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 6:54 PM
To: Shahram Davari; Tal Mizrahi; [email-masked]
Subject: RE: Transporting PTP messages (1588) over MPLS Networks

Hi Tal,

Cheers, Manav

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 26 Jan 2011 22:51:09 +0530

This can be easily fixed by replacing "highest" with "high" in the current text. Would that work?

Cheers, Manav 

> Sent: Wednesday, January 26, 2011 10.43 PM
> The current wording is "The PTP messages are time critical 
> and must be treated with the highest priority.", 
> while the IEEE 1588 states in the informative Annex A that 
> "PTP event messages should be sent with high priority 
> compared with other data whenever possible."
> Of course it makes sense that PTP is high priority, but the 
> current wording seems a bit too stringent.
> 
> Thanks. 
> Tal.
> 
> The PDelay_Resp_Follow_Up message will never go through a TC 
> and will never have its CF modified.  In the case of a non-TC 
> PTP LSR, it is only the PDelay_Req and PDelay-Resp message 
> that are time sensitive.  So the PDelay_Resp_Follow_Up can be 
> sent outside of the PTP LSP.
> 
> > 
> > 10.  QoS Considerations

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 27 Jan 2011 09:43:47 +0200

>This can be easily fixed by replacing "highest" with "high" in the current >text. Would that work?
Sounds okay.

Regards,
Tal.

-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 7:21 PM
To: Tal Mizrahi; Shahram Davari; [email-masked]
Subject: RE: Transporting PTP messages (1588) over MPLS Networks

Cheers, Manav

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 27 Jan 2011 09:59:57 +0200

Hi Shahram,

>- that makes sense, but seems to contradict the first half of the sentence >"Ethernet FCS MUST be recalculated at every LSR". In my understanding if >retention is not used, only the LERs have to recompute the FCS. LSRs may >alter the CF, but do not need to bother with the FCS.
>

I guess I am missing something - I will appreciate if you can elaborate why an intermediate LSR must recalculate the FCS in the absence of FCS retention.

In the absence of FCS retention, we would have according to RFC4448:
"The ingress Native Service Processing (NSP) function strips the preamble and frame check sequence (FCS) from the Ethernet frame and transports the frame in its entirety across the PW.  This is done regardless of the presence of the 802.1Q tag in the frame. The egress NSP function receives the Ethernet frame from the PW and regenerates the preamble or FCS"

Thanks.
Tal.

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 6:49 PM
To: Tal Mizrahi; Bhatia, Manav (Manav); [email-masked]
Subject: RE: Transporting PTP messages (1588) over MPLS Networks

Hi Tal,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Tuesday, January 18, 2011 6:04 AM
To: Bhatia, Manav (Manav); [email-masked]
Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi Manav,

A few comments below.

10.  QoS Considerations

11.  FCS Recalculation

Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: Saturday, January 15, 2011 12:56 PM
To: [email-masked]
Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks

Hi,

Cheers, Manav