Re: [TICTOC] FW: 1588 over MPLS draft

["Pietilainen, Antti (NSN - FI/Espoo)" <[e-mail]>]

Damn,
As a correction to an inexcusable mistake. The ITU Q13/SG15 meeting I refer to is definitely in Shenzhen Oct 18-22 and not in Shanghai. My mind is still somewere between the swimming pool and the bar.
Best regards, Antti 

________________________________

From: Pietilainen, Antti (NSN - FI/Espoo) 
Sent: Monday, August 02, 2010 6:27 PM
To: [e-mail]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft


Hi all,
As a correction to an ine

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Pietilainen, Antti (NSN - FI/Espoo)
Sent: Monday, August 02, 2010 4:56 PM
To: [e-mail]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft


Hi all,
 
When TICTOC work started a couple of years ago many ITU synchronization experts had to travel to several TICTOC meetings to make sure that IETF is not starting overlapping work on telecom synchronization (i.e. waste of money for everybody). Actually the work was more or less 100-% overlapping starting from telecom (and admittedly other) requirements for synchronization and which protocol to use (improved NTP/PTP something else). Luckily people decided to concentrate in ITU and the overlapping work died out. 
 
Now TICTOC has started work regarding time synchronization in MPLS networks just at the same time ITU group is finally getting into speed with the time synchronization as the frequency profile took almost all of the time until June. I guess that vendors representing ~ 9/10 of the world's MPLS equipment market share are present in the Synchronization stds group in ITU. This group certainly has the ability to conclude whether the best choice is to carry PTP time synchronization over MPLS or not in the MPLS networks.
 
In the last synchronization meeting in ITU there were 40 participants. Is the new MPLS work sarted in TICTOC implying that these people need to to start participating in the IETF meetings and mailing list for making sure that duplicate work will not be done?
 
At this time I propose as follows: Shahram Davari's paper would be presented also in the ITU time synchronization meeting in Shanghai in October as a document supporting a PTP over MPLS proposal. This could be compared with the possible PTP over OTN or PTP over SDH/SONET work going forward in ITU. If the decision is to carry PTP over MPLS in the MPLS networks, then the issues concerning MPLS protocol could be worked out in IETF (maybe in the MPLS group rather than in TICTOC?).
 
Best regards, Antti
 
p.s. In the discussion to come please note the following. Experience has shown that frequency delivery without nework support (intermediate nodes are PTP agnostic) and time synchronization with network support (where PTP layer is proessed in each node) should be treated completely separately. This mail concerns the latter one only.  
 
 
________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of ext [e-mail]
Sent: Tuesday, July 20, 2010 1:54 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft


Thank you Lizhong for reminding this!
 
It is also my feeling: I see that we are discussing in details some solutions to solve a problem for which the use cases are still not clear...
It raises the risk to develop a standard that is not really useful.
 
A few points may need to be clarified first in this discussion IMHO:
- What are the applications and the associated requirements that are targeted here? (Mobile networks only? Frequency, phase/time, both? With which accuracy?)
- What is the network architecture assumed in this discussion? (network with full/partial/no hardware timing support for PTP? Which kind of timing support: BC/TC/both?)
 
It might be worth reminding that in the case of a network providing no hardware timing support for PTP (i.e. no BC or TC features), PTP can be transported over MPLS using the existing MPLS standard without the need for any new feature to detect the PTP packets. For instance,  the G.8265.1 standard developed by ITU-T for frequency delivery enables transporting PTP messages over an MPLS network.
 
A reply to a comment from Stewart regarding this point: I don't believe that ITU-T has decided to develop standards for transporting PTP only over IP networks: in G.8265.1 (focused on frequency delivery), IP has been chosen as a useful way for addressing PTP masters and slaves, but the PTP messages can be transported over any kind of networks. In G.8275.1 (focused on phase/time delivery), this issue of addressing is still open I believe.
 
My understanding is that this current discussion only applies to MPLS nodes implementing features like TC or BC, where the PTP packets need to be detected, and not to the other MPLS nodes.
This implies some sort of hardware timing support from the network, being full or partial.
 
If one would like to consider some hardware timing support from the network, not only TC would be applicable in the case of PTP: BC would also be a relevant option, which has the advantage of avoiding the layer violation implied by TC (I understood from the discussion here that modifying the PTP payload within an LSP might create some problems with the MPLS standard, am I correct?).
 
Let's assume for instance this situation: PTP Master - BC - BC - BC - PTP Slave
What are the benefits here in transporting the PTP packets into an LSP between each BC, that are in this case separated by a single link? Why not simply using a link local channel?
Moreover, as mentioned above, any network segment between the BCs that is not experiencing hardware timing support for PTP can transport the PTP packets today without new feature.
 
FInally, I have a last general comment: I would be interested in better understanding how this discussion could interwork with the on-going efforts in ITU-T for developing standards for transporting synchronization over packet networks.
 
Thanks in advance for your feedback.
 
BR,
 
Sébastien

________________________________

De : [e-mail] [mailto:[e-mail]] De la part de Lizhong Jin
Envoyé : lundi 19 juillet 2010 17:45
À : [e-mail]
Cc : [e-mail]
Objet : Re: [TICTOC] FW: 1588 over MPLS draft


Hi Sasha,
Personally I also think a new reverved label is a better solution.
But I don't think we have provide very convienced answer of the initial question in this list: what is the benefit when deploying TC into MPLS network compared with current Ethernet/UDP solution.
 
BR
Lizhong


> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 19 Jul 2010 18:06:24 +0300
> From: Alexander Vainshtein <[e-mail]>
> Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> To: Tal Mizrahi <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Message-ID:
>    <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Tal,
> I think that we are in full agreement regarding a single-label GAL-only stack:
> It allows the LSRs to modify PTP packets (as TC must do), but it 
> does not support forwarding (unicast and multicast). Hence it is useless.
> IMO GAL/G-ACH are a clear dead end in this discussion.
> 
> If you have been following this list, I've suggested allocating a 
> new reserved label  which, at the top of the stack, would indicate 
> PTP packets.
> IMHO this is the only method that would somehow accommodate TC 
> (which is a layer violation, of course) without completely breaking 
> MPLS data plane.
> However, this approach did not gain support on the list.
> 
> "PTP FEC" IMO is also a dead end. E.g., you would not be able such 
> popular  recovery techniques as Facility FRR for this FEC, etc.
> 
> At the same time, if TC support is not required, there is no need to
> invent any special encapsulation of PTP over MPLS. All the rest of 
> the  use cases can be easily accommodated with PTP/UDP/IP/MPLS 
> without inventing new wheels.
> 
> My 2c,
>      Sasha
> 
> From: Tal Mizrahi [mailto:[e-mail]]
> Sent: Monday, July 19, 2010 5:55 PM
> To: Alexander Vainshtein
> Cc: [e-mail]
> Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> 
> 
> Hi Sasha, all,
> 
> 
> 
> A couple of comments:
> 
> 1. Generally, regarding using GAL+ACH: according to RFC 5586: "LSRs 
> MUST NOT modify the G-ACh message, the ACH or the GAL towards the 
> targeted destination". However, a PTP capable LSR that functions as 
> a TC must modify the packet (including the correctionField and the 
> UDP checksum). This means that if an LSR functions as a TC, either 
> (a) the functionality in RFC 5586 must be enhanced to allow 
> modification, or (b) the LSR terminates all incoming PTP messages, 
> and then re-generates them, which may burden the control plane.
> 
> 2. Sasha, regarding your option 1 below: if each packet has a label 
> stack with 1 label (GAL), it raises the question how to distinguish 
> between single-target and multi-target PTP packets. PTP calls for 
> both multicast frames (e.g.), and unicast (e.g. Delay_Req).
> 
> 
> 
> That's not to say I am against using the GAL, but it needs some 
> further refinement.
> 
> 
> 
> Tal.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> 
> 
> 
> Yaakov and all,
> 
> Please note that GAL and, by implication, the ACH header are only looked at by
> 
> an LSTR if GAL happens to be the top label in the stack (either because it has
> 
> been the top label in originally received packet, or because all the labels
> 
> above it have been popped by this LSR).
> 
> 
> 
> This leaves two options IMO:
> 
> 1. You carry PTP directly across physical links using labeled packets that
> 
>    have a label stack of depth 1 containing GAL.
> 
>    In this case you can probably do want you want with the PTP packets'
> 
>    payload, (e.g., support TC), but you need some new mechanism for forwarding
> 
>    PTP packets along a multi-hop path.
> 
> 
> 
> 2. You can carry PTP across any LSP using GAL at the bottom of the 
> label stack.
> 
>    In this case only the tail end of the LSP will be PTP-aware, i.e., TC will
> 
>    not be supported with this option.
> 
> 
> 
> I suggest taking a look at http://datatracker.ietf.org/doc/draft-
> ietf-mpls-tp-data-plane for details
> 
> regarding MPLS (and MPLS-TP) data plane.
> 
> 
> 
> Regards,
> 
>      Sasha
> 
> 
> 
> -----Original Message-----
> 
> From: tictoc-bounces at ietf.org [mailto:tictoc-bounces at ietf.org]
> On Behalf Of Yaakov Stein
> 
> Sent: Monday, July 19, 2010 12:06 PM
> 
> To: Mikael Abrahamsson
> 
> Cc: tictoc at ietf.org
> 
> Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> 
> 
> 
> No. Not a new Ethertype - we are talking about MPLS NOT Ethernet.
> 
> 
> 
> There is a protocol type (it's actually called a "channel type")
> 
> in the Ach control word. See RFC 4385.
> 
> Right now only a few are defined (raw BFD, IPv4, IPv6).
> 
> 
> 
> 
> 
> Y(J)S
> 
> 
> 
> -----Original Message-----
> 
> From: Mikael Abrahamsson [mailto:swmike at swm.pp.se]
> 
> Sent: Monday, July 19, 2010 09:48
> 
> To: Yaakov Stein
> 
> Cc: stbryant at cisco.com; tictoc at ietf.org
> 
> Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> 
> 
> 
> On Sun, 18 Jul 2010, Yaakov Stein wrote:
> 
> 
> 
> > 1) define a new protocol type (plenty of openings in THAT registry!)
> 
> 
> 
> New protocol type on what level? Ethernet, so this would involve a new
> 
> ethertype?
> 
> 
> 
> If routers generally can look that far into the packet on the correct
> 
> forwarding level (I doubt it though) then that would be the least
> 
> intrusive, but having LSRs look for ethertype within MPLS labeled packets
> 
> sounds kind of advanced to do that early in the receive path?
> 
> 
> 
> Why not do it more like an MPLS L3 VPN terminated/routed by all
> 
> involved&&aware routers, then it would signal special labels to its
> 
> neighbours that would be local significance only? But now we're talking
> 
> handling it like a tree and that would involve routing protocols as
> 
> well... Basically this would be like multicast IP and could leverage all
> 
> the multicast MPLS standards out there.
> 
>