Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

From: Yaakov Stein <[email-masked]>
Date: Thu, 4 Jul 2013 09:21:13 +0000

We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1588overmpls
(see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05).

Please send indications of support, as well as any remaining technical comments, to the list.

Due to the MPLS aspects of this draft this email is also being sent to the MPLS WG,
but please conduct all discussion on the TICTOC working group mailing list.

This working group last call will end on July 19, 2013.

Y(J)S

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 4 Jul 2013 13:18:12 +0300

Support.

Tal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Thursday, July 04, 2013 12:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

We hereby announce a TICTOC working group last call for draft-ietf-tictoc-1588overmpls (see http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05).

Due to the MPLS aspects of this draft this email is also being sent to the MPLS WG, but please conduct all discussion on the TICTOC working group mailing list.

Y(J)S 

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

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 5 Jul 2013 16:46:36 +0000

Do not support
- As document describing Transporting Timing messages over MPLS Networks it comes short in justification of complexity of PTP LSP for non-1588 protocols;
- I do believe that even for IEEE 1588 distribution through MPLS-TP domain PTP LSPs are not required. DCN constructed of dedicated G-ACh interconnecting ports that support IEEE 1588 (new capability advertised in IGP-TE) is architectually clean and sufficient.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Thursday, July 04, 2013 2:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 10 Jul 2013 14:53:35 +0000

<chair-hat value=off>
 I support this draft.

 I disagree with Greg (which doesn't often happen) in that I don't see this as adding that much complexity;
 all that is needed is to associate the desired characteristics with a specific label.
 I agree that sending 1588 over the GACh DCN would be an alternative mechanism that was not discussed in TICTOC;
 I am far from sure that this would be a better solution that the proposed one.
 In particular, by the time an intermediate LSR discovers that this is a 1588 packet,
 it would probably be too late to timestamp it for TC.
</chair-hat>

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: 04 July, 2013 12:21
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Y(J)S

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 10 Jul 2013 16:10:32 +0000

Hi

I support this draft to go ahead as RFC. We have worked almost 2 years on this draft and have addressed all comments by participants and area director.

I disagree with Greg's comment. We have made the draft generic based on Stewart's request so that if in future IETF decided to carry other Timing protocols such as NTP they can use the same mechanism.

Also I disagree with using GAL-ACH channel, since if the proposal is To use Section Channel then it can't support TC and can only support BC. And if the proposal is to use LSP Channel, then intermediate routers need to do deep packet inspection of all packets and detect 1588 packets encapsulated in the ACH. Also most routers upon detection of any terminated ACH send those packets directly to CPU. This method had been considered by authors and rejected due to its issues.

The current method is simple and supports TC and BC.

Regards,
Shahram

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

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 10 Jul 2013 18:25:38 +0000

Dear Shahram,
as Yaacov noted "... sending 1588 over the GACh DCN would be an alternative mechanism that was not discussed in TICTOC." And that is  unfortunate and perhaps I should have written a document earlier. Timing Distribution DCN can interconnect 1588-capable ports with combination of section and LSP spans. I am interested to understand why you believe that TC function can not be supported by a node terminating G-ACh and only BC functionality can be supported.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Wednesday, July 10, 2013 9:11 AM
To: Yaakov Stein
Cc: [email-masked]; [email-masked]
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi

Regards,
Shahram

---

From: <[email-masked]>
Date: Thu, 11 Jul 2013 08:05:33 +0000

Hi,

In general, I do not support this document, mainly because I don't think that the problem statement it tries to address really exists.
That being said, I did not check more in details its content, so I cannot judge whether or not what it proposes is correct.
I just think that there is no use case for this mechanism.
 
"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." => this statement is not supported by any argumentation, and each time that the point has been raised on the mailing list, no clear answer or use case was provided in my opinion. As mentioned several times, I do not think that there is a real need to involve the MPLS layer to transport PTP messages; using the existing mappings defined in IEEE 1588-2008 is sufficient for all the use cases that I can imagine. And I have not heard any other use case from other industries than telecoms.

Operators are requesting Ethernet encapsulation for PTP (full timing support from the network scenario) or IP mapping (partial timing support from the network scenario and no timing support scenario), but not MPLS encapsulation...

A quick feedback from an operator monitoring this topic from the beginning.

Thanks for considering (or not) this input.

BR,

Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Gregory Mirsky
Envoyé : vendredi 5 juillet 2013 18:47
À : Yaakov Stein; [email-masked]
Cc : [email-masked]
Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Do not support

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Thursday, July 04, 2013 2:21 AM
To: [email-masked]
Cc: [email-masked]
Subject: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Y(J)S 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 11 Jul 2013 14:51:23 +0000

Hi Sebastian,

Thanks for your comments. This draft is an IETF working draft and was accepted as such based on IETF consensus.

Are you saying there is no need to carry 1588 in the networks that use MPLS or are you saying there are other methods which are simpler? 

If you mean the former, then I disagree and I can give you examples from China mobile, China Telecom, NTT, KDDI, etc  where their mobile Backhaul access and aggregation network are MPLS and they wang to use 1588 at the cell site.

If you mean the later one then I disagree as well. If you are proposing to use Ethernet encapsulation for 1588 without MPLS, then the problem is that not all links are Ethernet. Even when all links are Ethernet, Ethernet is just used for P2P link and is not switched in routers. This means you can only do BC in such cases. If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then this is exactly what we do in this draft.

If you are proposing to use IP encapsulation for 1588, then you are either proposing to use IP without MPLS encapsulation, which doesn't work since obviously many networks such as MPLS-TP can't perform IP routing. Or you are proposing to use IP with MPLS encapsulation, which is exactly what we are doing in this draft.

The other issue is assume a service provider who is using say Ethernet encapsulation to carry 1588, leases some connections from another network operator. The network operator needs to carry these 1588 messages without terminating them but also needs to do TC on them. Using flat Ethernet switching is not possible since the operator network is carrying traffic from many other customers and his network is virtualized.

I suggest you reading the draft first.

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 11 Jul 2013 14:55:48 +0000

I forgot to mention that in my below example the operator network is MPLS.

Regards,
Shahram

---

From: <[email-masked]>
Date: Thu, 11 Jul 2013 22:10:13 +0000

Hi Shahram,

Thanks for your reply and explanations. See some comments below in your text.
It is interesting discussion.

Thanks.

BR,

Sébastien

-----Message d'origine-----
De : Shahram Davari [mailto:[email-masked]] 
Envoyé : jeudi 11 juillet 2013 16:51
À : JOBERT Sebastien OLNC/OLN
Cc : Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Sebastian,

Thanks for your comments. This draft is an IETF working draft and was accepted as such based on IETF consensus.
[JOBERT Sebastien RD-CORE-LAN] Absolutely, and this is not something that I dispute. However, since it has been asked to the mailing list to indicate support and provide comments, I do not feel that giving an opinion was outside the IETF process. The group may or may not consider this input at the end.

Are you saying there is no need to carry 1588 in the networks that use MPLS or are you saying there are other methods which are simpler? 
[JOBERT Sebastien RD-CORE-LAN] Of course, there is a need to carry PTP messages over networks that operate the MPLS layer; what I am saying is simply that, over such networks, I do not think that carrying these PTP messages inside an MPLS layer is required. Other existing encapsulations are fine and probably simpler, indeed.

If you mean the former, then I disagree and I can give you examples from China mobile, China Telecom, NTT, KDDI, etc  where their mobile Backhaul access and aggregation network are MPLS and they wang to use 1588 at the cell site.
[JOBERT Sebastien RD-CORE-LAN] Of course, we agree on this point: MPLS networks are widely deployed. It is on the method to carry PTP messages that we have different views, I think.

If you mean the later one then I disagree as well.
[JOBERT Sebastien RD-CORE-LAN] OK, let's discuss then to see where the different views are.

If you are proposing to use Ethernet encapsulation for 1588 without MPLS, then the problem is that not all links are Ethernet. 
[JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only one possibility, as IP mapping is also possible, see below), the links that use an Ethernet mapping for the PTP messages must obviously support Ethernet. That being said: 1- not all the links must use this mapping, it is possible to mix different mappings (e.g. Ethernet and IP) and allow some kind of interworking mechanisms; 2- it is not because the PTP messages are carried over Ethernet that the entire traffic must also be carried over Ethernet, it is fully possible to envisage that only the "synchronization plane" be over Ethernet, and the data and control planes be over MPLS if desirable. Do we agree on this?

Even when all links are Ethernet, Ethernet is just used for P2P link and is not switched in routers. 
[JOBERT Sebastien RD-CORE-LAN] Some routers may also implement a L2...

This means you can only do BC in such cases. 
[JOBERT Sebastien RD-CORE-LAN] No, there are ways to build a TC system with Ethernet encapsulation (we actually presented a draft in Paris providing one possible solution).

If you are proposing to use Ethernet encapsulation with MPLS (aka PW), then this is exactly what we do in this draft.
[JOBERT Sebastien RD-CORE-LAN] Indeed, but this is not what I am proposing ;-)

If you are proposing to use IP encapsulation for 1588, then you are either proposing to use IP without MPLS encapsulation, which doesn't work since obviously many networks such as MPLS-TP can't perform IP routing. 
[JOBERT Sebastien RD-CORE-LAN] This is probably the main point where we do not agree. I can hardly imagine personally a network operating an MPLS layer where everything is carried over MPLS. As mentioned before, there is no problem in having the data and control planes over MPLS if desirable (although I doubt that the control plane be always over MPLS, but it is a different debate), and the "synchronization plane" over IP. Synchronization is generally uncorrelated from the other planes: consider for instance Synchronous Ethernet, it is a layer 1 mechanism, which is totally uncorrelated from the way the data plane is transported. Correlating these layers is not necessary.

Or you are proposing to use IP with MPLS encapsulation, which is exactly what we are doing in this draft.
[JOBERT Sebastien RD-CORE-LAN] No, as I mentioned, I do not think that such encapsulation is required.

The other issue is assume a service provider who is using say Ethernet encapsulation to carry 1588, leases some connections from another network operator. The network operator needs to carry these 1588 messages without terminating them but also needs to do TC on them. 
[JOBERT Sebastien RD-CORE-LAN] Another point where we also probably disagree, I believe. TC is one possible solution, but there are many other ways to enable "timing transparency" (for instance, without going into the details: differential methods, "network TC" concept, etc.). However, the real question seems to be: is timing transparency a real requirement? My opinion is that this is not a strong requirement, because at the end, for mobile applications, one has to deliver some sort of UTC traceable signal. Hence, where the synchronization reference is coming from is not really important, as long as the synchronization requirements are met, because the ultimate source is at the end the same for everyone: UTC. Future applications do not really have plesiochronous requirements anymore. I really believe that a scenario where the carrier operator is providing the reference to the mobile operator, in case of leased lines, is what will occur. Otherwise, this will be a scenario where the carrier operator does not provide any support at all for PTP and where the mobile operator is on its own to get rid of the PDV and asymmetry generated by the network. I cannot imagine why the carrier operator would like to spend money on hardware support such as TC in every single NEs simply to provide to other operators some kind of timing transparency not really required; the carrier operator would better spend his money building a robust network enabling to deliver very accurate synchronization, and provide his own timing reference, with possible guarantees, as part of the leased line offer.

Using flat Ethernet switching is not possible since the operator network is carrying traffic from many other customers and his network is virtualized.

I suggest you reading the draft first.
[JOBERT Sebastien RD-CORE-LAN] Good suggestion indeed ;-) I'll do this for my own education; however, still, I believe that the use cases that this draft tries to address are subject to discussion.

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 11 Jul 2013 23:06:00 +0000

Hi Sebastien,

Please see my response inline.

Thank
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:10 PM
To: Shahram Davari
Cc: Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Shahram,

Thanks.

BR,

Sébastien

-----Message d'origine-----

Hi Sebastian,

If you are proposing to use Ethernet encapsulation for 1588 without MPLS, then the problem is that not all links are Ethernet. 
[JOBERT Sebastien RD-CORE-LAN] To be precise: in this case (which is only one possibility, as IP mapping is also possible, see below), the links that use an Ethernet mapping for the PTP messages must obviously support Ethernet. That being said: 1- not all the links must use this mapping, it is possible to mix different mappings (e.g. Ethernet and IP) and allow some kind of interworking mechanisms; 

SD> So you agree that you need some interworking function which can convert Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA,  etc. I am sure you don't want to do this interworking in the CPU, do you? So you need new HW. Basically what you are saying is that carry 1588 over the server layer such as Ethernet or OTN, etc. The problem as you figured out yourself is that the span of the server layer is not the same span as the LSP. Therefore you either need to terminate the 1588 and regenerate it (BC), or as you said you need service interworking.

2- it is not because the PTP messages are carried over Ethernet that the entire traffic must also be carried over Ethernet, it is fully possible to envisage that only the "synchronization plane" be over Ethernet, and the data and control planes be over MPLS if desirable. Do we agree on this?

SD> Yes. But as I said the issue is that the span of server layer may not be the same as the LSP.

SD> yes some do L2 switching, but some don't.

SD> I haven't seen that. Could you please email that to me.

SD> There are networks that don't do IP routing. PTN networks that are based on MPLS-TP don't do IP routing at all. You can refer to come of the China and Japan carriers.  I agree that Synch can be uncorrelated to data, but you the issue is that the logically out-of-band network you are referring to in most cases has short span (such as one link) and therefore can't support 1588 end-to-end TC.

SD> While the model that you describe where a Transit provider also provides reference clock is possible, but it require 1588 protocol exchange between Operator and the service provider that leases from operator.  And I think it is not embraced in the industry (as of yet). But 1588 transparency is simple and does not require 1588 protocol exchange between operator and service provider.

SD> I agree with you that if the entire network is built out of Switch-Routers and all links are Ethernet then you probably don't need this draft and can do 1588 over Ethernet end-to-end.

Regards,
Shahram

---

From: <[email-masked]>
Date: Fri, 12 Jul 2013 15:59:38 +0000

Hi Shahram,

Thanks for the reply.

I copied your text below in order to give some more feedback, to make it more readable:

"SD> So you agree that you need some interworking function which can convert Ethernet to IP and vice-versa and to translate MAC-DA, VLAN to IP-DA,  etc. I am sure you don't want to do this interworking in the CPU, do you?"

Sébastien: If such IWF occurs, it would involve several different physical ports. Then, I assume that some specific PTP HW would have to be supported by the various ports involved for HW timestamping purposes, which may rely on different mappings if needed. But then, I assume that the relevant PTP information is recovered from the PTP packets, and transmitted to the central clock in the equipment, without information about the mapping initially used, which is at the end a transport facility only. I am then not sure why such IWF is really needed in HW: the PTP packets may simply use different mappings at the ingress and at the egress, as far as the relevant information has been processed inside the device; the IWF is at the end realized by the entire device, not at a single place. This may look however more like a BC-model only, but my assumption is that it should be possible to design a TC with a similar model in which the PTP messages are terminated and processed (again, refer to the draft that we presented in Paris). I don't see any particular IWF problem then from the HW perspective (that being said, I recognized that I am not expert in this field, so your feedback is really welcomed).

"So you need new HW. Basically what you are saying is that carry 1588 over the server layer such as Ethernet or OTN, etc. The problem as you figured out yourself is that the span of the server layer is not the same span as the LSP. Therefore you either need to terminate the 1588 and regenerate it (BC), or as you said you need service interworking."

Sébastien: OK, I see where we diverge then. First, my assumption is that we can build a TC-model in which the PTP messages are terminated and processed (it is even better IMHO, as it avoids the layer violation problem, please refer again to our draft from Paris). Second, my understanding is that your mechanism is really only for a TC-model used over an MPLS layer that "does not terminate the PTP messages" (which I think is not a good model for telecoms), and not really for a BC system. The layer violation problem of TCs should not be under-estimated IMHO; IEEE has delivered to ITU-T a very clear message that such architectural problems should be avoided.

"SD> I haven't seen that. Could you please email that to me."

Sébastien: draft from Paris => http://tools.ietf.org/html/draft-jobert-tictoc-ptp-link-local-00 

"SD> There are networks that don't do IP routing. PTN networks that are based on MPLS-TP don't do IP routing at all. You can refer to come of the China and Japan carriers.  I agree that Synch can be uncorrelated to data, but you the issue is that the logically out-of-band network you are referring to in most cases has short span (such as one link)"

Sébastien: such networks do not have to do IP *routing* (or Ethernet switching) in the model that I propose, because in all the cases, the PTP messages are terminated and processed. The IP or Ethernet layers are only used as "encapsulations", not for routing (otherwise, the layer violation is there). 

"SD> While the model that you describe where a Transit provider also provides reference clock is possible, but it require 1588 protocol exchange between Operator and the service provider that leases from operator.  And I think it is not embraced in the industry (as of yet). But 1588 transparency is simple and does not require 1588 protocol exchange between operator and service provider."

Sébastien: I really disagree: the model where the carrier operator delivers his timing reference as part of the service exists today in many cases (I have several examples in mind for frequency synchronization). However, the "timing transparency" model in which the network operator puts very specific HW in his equipment to ensure transparency to the mobile operator is really a scenario that I have never seen, and that I really doubt will happen one day (perhaps the only exception is SyncE timing transparency over OTN, which implies specific mappings, but I consider this as different, because there is no other way to carry timing over OTN than transparency to the client signals, so the carrier operator has anyway to implement such new mapping for his own purpose - it is not a feature dedicated to the mobile operator).

In conclusion, from my perspective:

- I think we have now identified the points that we do not agree:
	- PTP clock that terminates the PTP messages vs PTP clock that does not (and layer violation implications)
	- Real need for "timing transparency" as far as PTP is concerned

- These points are not related to issues with regards to the solution that you propose, but to the need for this solution. Depending on the perspective, the MPLS layer may not need to be used to carry PTP messages over networks that operate the MPLS layer.

- So, my understanding is that the solution presented in your draft would be applicable only to an operator who would built a network with TC everywhere based on the MPLS layer, in order to provide timing transparency capability to other operators. Given that this timing transparency is subject to debate, I wonder if there are operators having such requirements?

- I wonder if your solution really makes sense for a BC-model?

Thanks for the interesting discussion.

BR,

Sébastien

-----Message d'origine-----
De : Shahram Davari [mailto:[email-masked]] 
Envoyé : vendredi 12 juillet 2013 01:06
À : JOBERT Sebastien OLNC/OLN
Cc : Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Objet : RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Sebastien,

Thank
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:10 PM
To: Shahram Davari
Cc: Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Shahram,

Thanks.

BR,

Sébastien

-----Message d'origine-----

Hi Sebastian,

Regards,
Shahram

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 12 Jul 2013 18:10:11 +0000

Hi Sebastien,

Pls see inline.

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 12, 2013 9:00 AM
To: Shahram Davari
Cc: Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Shahram,

Thanks for the reply.

SD> If all links are Ethernet, and if your switch can do Ethernet bridging then there is no issue. But if all links are not Ethernet then as you said you need to convert from Ethernet to say IP. This can off course be done in CPU, but then it will add significant PDV that makes it useless. So you would need new HW.
Also if all links are Ethernet, based on your own draft, you still want to use special forwarding for PTP packets, which means new HW.

SD> This is exactly where we disagree. For end-to-end TC you must not terminate and regenerate PTP messages, otherwise you are going to incur huge PDV. 

SD> Thanks. It seems in order to avoid layer violation you have gone to great length. But what you are doing is the same just calling it terminate and regenerate. 

SD> Again, The termination and regeneration must be done somewhere. If it is done in CPU then it won't work for TC since the PDV is high. If it is done in HW then logically you are doing IP routing in HW, although you are not calling it that way. But this would need new HW that doesn't exist.

SD> I disagree, the model that the provider provides ToD service to the other operator requires interworking of PTP protocol stack between operators, while Transparent PTP transport is simple and doesn't require protocol interworking.

SD> Yes it does when the two BC nodes are many MPLS hops away from each other. 

BR,

Sébastien

-----Message d'origine-----

Hi Sebastien,

Thank
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:10 PM
To: Shahram Davari
Cc: Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Shahram,

Thanks.

BR,

Sébastien

-----Message d'origine-----

Hi Sebastian,

Regards,
Shahram

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 18 Jul 2013 05:47:41 +0000

Hi,

Support this draft.

Cheers, Manav 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yaakov Stein
> Sent: Thursday, July 04, 2013 2:51 PM
> To: [email-masked]
> Cc: [email-masked]
> We hereby announce a TICTOC working group last call for 
> draft-ietf-tictoc-1588overmpls (see 
> http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-05).
> 
> Due to the MPLS aspects of this draft this email is also 
> being sent to the MPLS WG, but please conduct all discussion 
> on the TICTOC working group mailing list.
>

---

From: <[email-masked]>
Date: Thu, 18 Jul 2013 08:04:42 +0000

Hi Shahram,

(sorry for the late reply, just going back from Geneva ITU-T meeting...)

It seems that we identified where we disagree. I wonder if some points are mainly a matter of terminology? (e.g. terminate/regenerate).

As an example, you said: "For end-to-end TC you must not terminate and regenerate PTP messages, otherwise you are going to incur huge PDV"
The forwarding function (i.e. finding the relevant output port) is for me uncorrelated to the PTP treatment (i.e. updating properly the correction field for a TC, or updating the local time reference for a BC). Therefore, I do not understand why in your opinion, TC with termination/regeneration necessarily leads to PDV; in my opinion, if the TC is properly implemented (i.e. proper update of the correction field based on HW timestamping), then there should be almost no PDV, whatever the way to perform the forwarding function (SW-based or HW-based).

Anyway, I agree with you that, in order to avoid PDV and so on, new HW is absolutely required, independently of the type of encapsulation.
The two topics seem not directly related.

It was useful discussion. But still, I remain skeptical about the usefulness of the MPLS encapsulation... 
	- for full timing support scenario: I believe that there are other simpler ways to perform the same thing (it is what we discussed, although we disagree on some points).
	- for partial timing support scenario: if there is no PTP treatment in some MPLS nodes, then there is no need for identifying them among the rest of the traffic... "Soft prioritization" to minimize the PDV can still be possible in this case using DSCP marking.

Thanks!

BR,

Sébastien

-----Message d'origine-----
Envoyé : vendredi 12 juillet 2013 20:10

Hi Sebastien,

Pls see inline.

Thx
SD

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, July 12, 2013 9:00 AM
To: Shahram Davari
Cc: Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Shahram,

Thanks for the reply.

BR,

Sébastien

-----Message d'origine-----

Hi Sebastien,

Thank
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 11, 2013 3:10 PM
To: Shahram Davari
Cc: Gregory Mirsky; Yaakov Stein; [email-masked]; [email-masked]
Subject: RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Shahram,

Thanks.

BR,

Sébastien

-----Message d'origine-----

Hi Sebastian,

Regards,
Shahram

---

From: weiqiang cheng <[email-masked]>
Date: Thu, 18 Jul 2013 14:37:11 +0800

Hi,

Support.

It is useful for 1588 time synchronization in mobile backhaul application
scenarios.
Cheng Weiqiang
Research Institute of China Mobile

2013/7/18 Bhatia, Manav (Manav) <[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 18 Jul 2013 10:15:03 +0000

Hi all,
I do not support this draft in its present form.
IMHO and FWIW the idea of setting up dedicated "timing LSPs" for carrying just the PTP messages does not match the MPLS data plane architecture as described in RFC 3031.

To the best of my understanding, the proper way to request any kind of special processing (including the processing required for accurate synchronization) in MPLS is by defining a suitable "alert label". Such a label could be pushed on top of the label stack by the LSR that is the originator of the packet that requires special processing. The LER that receives a packet with such an alert label would:
- treat this label as a request for special processing
- use the remainder of the label stack to define the forwarding disposition of the packet
- if the packet were to be forwarded as a labeled packet, the same "alert label" would be pushed on top of the  label stack at egress.

(This behavior has been defined for the "router alert" label in RFC 3032).

I am not sure if the WG has ever considered such an alternative. I believe (but I may be wrong)  that it has been mentioned in some private discussions, but rejected due to the fact that reserved labels were considered a scarce resource so that the chances to obtain one from the IANA were slim.

The situation is hopefully going to change with the advance of an extended space of "special purpose" labels as defined in http://tools.ietf.org/html/draft-ietf-mpls-special-purpose-labels-03. With at least 240 special purpose labels available for the Standards Action, it would be easy to obtain a "Synchronization Alert" label that would indicate the need for the corresponding special processing without creation and maintenance of dedicated "timing LSPs", providing dedicated protection schemes for such LSPs etc. It would only greatly simplify the HW design because the packets requiring special processing would be easily identifiable without any special configuration (the "Synchronization Alert" label would follow the "Extension Label" indicator and have a fixed IANA-allocated value).

My 2c,
     Sasha

> This working group last call will end on July 19, 2013.

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "S. Davari" <[email-masked]>
Date: Thu, 18 Jul 2013 09:11:25 -0700

Hi Sasha,

We had considered using a reserved label and it was rejected. Perhaps we should have documented it in the draft. 

The issues are:

1) reserved label is not backward compatible with existing routers. One of the requirements is that routers that are not PTP aware can just switch the packet normally.  Using a reserved label can't achieve this requirement, since routers that don't understand it will drop it or sent it to CPU.

2) there are multiple encapsulations for PTP such as Ethernet with optional VLAN or UDP/IP. An intermediate LSR doesn't know the whether the payload is IP or Ethernet or VLAN. This means for each PTP encapsulation type you probably need a different reserved label.

3) the area director has asked us to create a more generalized way of carrying timing over MPLS to be usable with new timing protocols that need TC. Using reserved label would require different reserved label for each new timing protocol.

4) the extended reserved label draft is fairly new and didn't exist when this draft was progressing.

Regards,
Shahram

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 19 Jul 2013 08:01:48 +0000

Shahram hi!

Lots of thanks for a prompt and informative response.

Please see some comments inline below.

Regards,
     Sasha

________________________________________
From: S. Davari [[email-masked]]
Sent: Thursday, July 18, 2013 6:11 PM
To: Alexander Vainshtein
Cc: Yaakov Stein; [email-masked]; [email-masked]
Subject: Re: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Sasha,

[[Sasha]] Yes, indeed.

The issues are:

1) reserved label is not backward compatible with existing routers. One of the requirements is that routers that are not PTP aware can just switch the packet normally.  Using a reserved label can't achieve this requirement, since routers that don't understand it will drop it or sent it to CPU.
[[Sasha]]  Is not this concern  applicable to any new reserved label? And routers that use network processors as forwarding engines could easily overcome this issue by upgrading their microcode.
But I agree that this is a valid concern.

2) there are multiple encapsulations for PTP such as Ethernet with optional VLAN or UDP/IP. An intermediate LSR doesn't know the whether the payload is IP or Ethernet or VLAN. This means for each PTP encapsulation type you probably need a different reserved label.
[[Sasha]] IMHO and FWIW support of PTP over UDP/IP would suffice in the absolute majority of cases. 

3) the area director has asked us to create a more generalized way of carrying timing over MPLS to be usable with new timing protocols that need TC. Using reserved label would require different reserved label for each new timing protocol.
[[Sasha]] I do not think so. "New timing protocols" would be hopefully still run on top of UDP/IP and hence could be easily identifiable by looking at the appropriate UDP port. 

4) the extended reserved label draft is fairly new and didn't exist when this draft was progressing.
[[Sasha]] This is definitelt true. But it does not justify (for me) setting up dedicated LSPs for timing distribution.

Regards,
Shahram

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 19 Jul 2013 08:11:35 +0000

Hi Sasha,

> 1) reserved label is not backward compatible with existing routers. One
> of the requirements is that routers that are not PTP aware can just
> switch the packet normally.  Using a reserved label can't achieve this
> requirement, since routers that don't understand it will drop it or
> sent it to CPU.
> [[Sasha]]  Is not this concern  applicable to any new reserved label?
> And routers that use network processors as forwarding engines could
> easily overcome this issue by upgrading their microcode.

This is a huge concern because not all routers use network processors that can be reprogrammed.

The current solution works with any router that can set up an MPLS path.

> 
> 2) there are multiple encapsulations for PTP such as Ethernet with
> optional VLAN or UDP/IP. An intermediate LSR doesn't know the whether
> the payload is IP or Ethernet or VLAN. This means for each PTP
> encapsulation type you probably need a different reserved label.
> 3) the area director has asked us to create a more generalized way of
> carrying timing over MPLS to be usable with new timing protocols that
> need TC. Using reserved label would require different reserved label
> for each new timing protocol.
> [[Sasha]] I do not think so. "New timing protocols" would be hopefully
> still run on top of UDP/IP and hence could be easily identifiable by
> looking at the appropriate UDP port.

That's bordering on speculation. The current solution is oblivious to a new timing protocol. Today it can be used for both PTP and NTP. With reserved labels, we will need a new label (and a firmware upgrade) each time a new protocol needs to be supported. 

> [[Sasha]] This is definitelt true. But it does not justify (for me)
> setting up dedicated LSPs for timing distribution.

No offence, am trying to understand - whats the problem that you see with setting up a dedicated LSP for timing distribution?

Cheers, Manav

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Jul 2013 11:32:31 +0100

> The current solution works with any router that can set up an MPLS path.
Really?

Surely the LSR needs to know that on seeing a label in the FEC it needs
to timestamp the packet.

Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 19 Jul 2013 13:19:32 +0000

Hi Stewart,

Not necessarily. It is ok if some of the routers in the path are not timing aware. That is the whole idea. We have tested cases in which 5-7 hops are not   1588 aware and still we can recover the time correctly.

Regards,
Shahram

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 19 Jul 2013 17:07:43 +0100

Shahram

That then poses two interesting question:

1) Do you ever need to go more than 7 hops? In the work we did on
IPFRR the core was normally 8 hops across so most of the traffic
in a single routing domain went less that 8 hops.

2) What happens when there is an underlying packet transport
network which will introduce hidden hops?

Stewart

On 19/07/2013 14:19, Shahram Davari wrote:
> .

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 19 Jul 2013 17:12:48 +0000

Hi Stewart,

Good question. It depends on the Servo algorithms used. The more hops the more complex algorithms with longer convergence time. Any queuing point is potentially one hop that can introduce PDV. The 5-7 hops I mentioned is the best proprietory servo algorithm I have seen, but the convergence time is very long (many minutes).

Thanks
Shahram

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Friday, July 19, 2013 9:08 AM
To: Shahram Davari
Cc: Bhatia, Manav (Manav); [email-masked]; [email-masked]; S. Davari
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Shahram

Stewart

---

From: Kevin Gross <[email-masked]>
Date: Fri, 19 Jul 2013 11:32:54 -0600

You need to specify what you mean by "recover the time correctly."
Everytime you pass through a piece of equipment that is not timing aware,
you introduce noise into the timing signal. More hops, more noise. Noise
reduces synchronization accuracy.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Fri, Jul 19, 2013 at 7:19 AM, Shahram Davari <[email-masked]> wrote:

> Hi Stewart,
>
> Not necessarily. It is ok if some of the routers in the path are not
> timing aware. That is the whole idea. We have tested cases in which 5-7
> hops are not   1588 aware and still we can recover the time correctly.
>
> Regards,
> Shahram
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 20 Jul 2013 14:53:31 +0000

Kevin, Shahram and all,

I do not actively follow the developments in the ITU-T SG 15, but I believe that investigation of partial on-path support for PTP (which would be the case if some LERs on the path were not PTP-aware) has just began there, and it is not clear what (if anything) could be achieved and under what conditions.

Did I miss something important here?

My 2c,

     Sasha

________________________________
From: [email-masked] [[email-masked]] on behalf of Kevin Gross [[email-masked]]
Sent: Friday, July 19, 2013 7:32 PM
To: Shahram Davari
Cc: [email-masked]; S. Davari; [email-masked]
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

You need to specify what you mean by "recover the time correctly." Everytime you pass through a piece of equipment that is not timing aware, you introduce noise into the timing signal. More hops, more noise. Noise reduces synchronization accuracy.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Fri, Jul 19, 2013 at 7:19 AM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stewart,

Regards,
Shahram

On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 21 Jul 2013 08:45:25 +0000

Manay,
Please see some answers inline below.

Regards,
     Sasha

> From: Bhatia, Manav (Manav) [mailto:[email-masked]]
> Sent: Friday, July 19, 2013 11:12 AM
> To: Alexander Vainshtein; S. Davari
> Subject: RE: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
> 
> Hi Sasha,
> 
[[[Sasha]]]  I have already stated that backward compatibility of the solution is a valid concern.
However, I do not believe this concern is really huge.
I suspect that presence of routers that are not capable for providing on-path support for PTP represents a problem by and of itself when it comes to accurate recovery of ToD. I defer to ITU-T SG15 that is now working on "partial on-path support for PTP" to decide what - and under what restrictions - one could expect in this scenario. 
Meanwhile, as you say, the routers that do not support extended special purpose labels would most probably send the packets with such labels on top of the label stack for SW processing; and SW usually is upgradeable. So the outcome would be additional unaccounted for delay generated by non-compliant routers - but it would be there in any case, right?

> That's bordering on speculation. The current solution is oblivious to a new
> timing protocol. Today it can be used for both PTP and NTP. With reserved
> labels, we will need a new label (and a firmware upgrade) each time a new
> protocol needs to be supported.
> 
[[[Sasha]]] I do not understand this statement. On-path support has to be aware of the specific clock distribution protocol for which it provides support to be of any use in "transit" nodes (e.g., it should now where the "correction field" or its analog sits within the packet).
If you want this support to be multi-protocol, then your HW has to be multi-protocol as well, and some form of protocol identification is required.
> No offence, am trying to understand - whats the problem that you see with
> setting up a dedicated LSP for timing distribution?
> 
[[[Sasha]]] One use case (which i see as a real one) is clock distribution across a BGP/MPLS VPN instance that combines delivery of traffic to/from eNodeB (mobile backhaul) with delivery of ToD to these nodes.

---

From: Stefano Ruffini <[email-masked]>
Date: Mon, 22 Jul 2013 13:06:23 +0000

Hi
Please note that the performance is heavily dependent on the actual traffic load as it can create asymmetries.
Under certain conditions 7 hops might lead to quite bad performance

Study is still ongoing to understand the partial timing support scenarios

Best regards
Stefano
________________________________________
Da: [email-masked] [[email-masked]] per conto di Shahram Davari [[email-masked]]
Inviato: venerdì 19 luglio 2013 19.12
A: [email-masked]
Cc: [email-masked]; [email-masked]; S. Davari
Oggetto: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Stewart,

Thanks
Shahram

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Friday, July 19, 2013 9:08 AM
To: Shahram Davari
Cc: Bhatia, Manav (Manav); [email-masked]; [email-masked]; S. Davari
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Shahram

Stewart