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

[<[e-mail]>]

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:[e-mail]] 
Envoyé : vendredi 12 juillet 2013 01:06
À : JOBERT Sebastien OLNC/OLN
Cc : Gregory Mirsky; Yaakov Stein; [e-mail]; [e-mail]
Objet : RE: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Sebastien,

Please see my response inline.

Thank
Shahram

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

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:[e-mail]] 
Envoyé : jeudi 11 juillet 2013 16:51
À : JOBERT Sebastien OLNC/OLN
Cc : Gregory Mirsky; Yaakov Stein; [e-mail]; [e-mail]
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; 

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.

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...

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

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).

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

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.

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.

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.

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.

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

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.

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


On Jul 11, 2013, at 1:05 AM, "[e-mail]" <[e-mail]> wrote:

> 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 : [e-mail] [mailto:[e-mail]] De la part de Gregory Mirsky
> Envoyé : vendredi 5 juillet 2013 18:47
> À : Yaakov Stein; [e-mail]
> Cc : [e-mail]
> Objet : Re: [TICTOC] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Yaakov Stein
> Sent: Thursday, July 04, 2013 2:21 AM
> To: [e-mail]
> Cc: [e-mail]
> 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).
> 
> 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 
> 
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> TICTOC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tictoc
> 


_________________________________________________________________________________________________________________________

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.




_________________________________________________________________________________________________________________________

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.