Subject: Re: [TICTOC] FW: 1588 over MPLS draft

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Aug 2010 16:55:41 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Tuesday, July 20, 2010 1:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
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 : [email-masked] [mailto:[email-masked]] De la part de Lizhong Jin
Envoyé : lundi 19 juillet 2010 17:45
À : [email-masked]
Cc : [email-masked]
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 <[email-masked]>
> Subject: Re: [TICTOC] FW: 1588 over MPLS draft
> To: Tal Mizrahi <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Message-ID:
>    <[email-masked]>
> 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:[email-masked]]
> Sent: Monday, July 19, 2010 5:55 PM
> To: Alexander Vainshtein
> Cc: [email-masked]
> 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.
> 
>

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Aug 2010 18:26:54 +0300

Hi all,
As a correction to an ine

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

Hi all,

 

Best regards, Antti

 

 

 

 
BR,
 
Sébastien

Hi Sasha,
 
BR
Lizhong

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 2 Aug 2010 18:32:09 +0300

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: [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi all,

Hi all,

 

Best regards, Antti

 

 

 

 
BR,
 
Sébastien

Hi Sasha,
 
BR
Lizhong

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 2 Aug 2010 22:17:44 +0300

Antti,

While I am very happy to see people who go to ITU-T meetings come to the IETF
(there are several hundred such), I am not sure that all Q13/SG15 people need to come to TICTOC,
just as not all IEEE-1588 people came to the NTP WG.

TICTOC came to a stall precisely because we did not want to duplicate work,
and we felt that there was no need to perform some of our tasks, as the ITU would eventually get to them.
(I personally had to attend 3 or more SDOs a few years ago in order to ensure that they would not
produce contradictory protocols.)

In the present case, MPLS is an IETF protocol. How to carry timing packets (either NTP or 1588)
over MPLS is of interest to many people in the IETF. The needed network expertise is here.
And the work is not being carried out elsewhere.

Similarly, management and MIBs is traditionally an IETF function
(even purely ITU protocols like E1s had their MIBs done here).
No-one else is doing a 1588 MIB. So this seems like a reasonable task for IETF.

The issue of security for timing is a harder one. Others have tried to address it in the past.
However, I have not seen anyone with the requisite timing and security credential take this issue on
in a serious way except in the IETF (have a look at RFC 5906).

So, we would be happy to have anyone interested in timing issues in general,
especially those concerned with transport of timing services over the public Internet
or over protocols defined in the IETF, to attend.
However, we do not intend to focus on issues well-treated elsewhere,
and in particular we have no intention on focusing on the subject of timing for cellular applications,
which is already handled in ITU, MEF, BBF, etc.
So I don't think that anyone need attend in order to avoid duplication.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)
Sent: Monday, August 02, 2010 18:32
To: Pietilainen, Antti (NSN - FI/Espoo); [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Damn,

Best regards, Antti

BR,

Sébastien

BR
Lizhong

> From: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
> To: Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Message-ID:
>    <[email-masked]<mailto:[email-masked]>>
> From: Tal Mizrahi [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> From: tictoc-bounces at ietf.org<http://ietf.org> [mailto:tictoc-bounces<mailto:tictoc-bounces> at ietf.org<http://ietf.org>]
> Cc: tictoc at ietf.org<http://ietf.org>
>
> From: Mikael Abrahamsson [mailto:swmike<mailto:swmike> at swm.pp.se<http://swm.pp.se>]
>
> Cc: stbryant at cisco.com<http://cisco.com>; tictoc at ietf.org<http://ietf.org>
>

---

From: [email-masked]
Date: Tue, 3 Aug 2010 10:18:42 +0800

Hi Antti and all,

Hopefully the correnction was in time before people had decided to change 
their booked flight, :O

It is clear that the architecture of time/phase transport using 
packet-based method such as 1588v2 would be defined in ITU-T, so the 
substantial work should be carried out when the network architecture and 
use cases are defined. So far, it has been generally agreed to initially 
discuss the case of time/phase sync with full network timing support(BC/TC 
implemented in every node). in this case, the benifit of using MPLS layer 
to carry 1588v2 may be questioned and need further investigation. IMHO, 
the MPLS could be better to used for tunnelling PTP flow in a end-to-end 
scenario, this could also be a profile in ITU-T?? 
Another concern is if the new tansport specifics using MPLS need to be 
defined, it's possibly definite to report to and discuss with IEEE. 

Regards,

Fei 

"Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]> 
发件人:  [email-masked]
2010-08-02 下午 11:32

收件人
"Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>, 
<[email-masked]>
抄送

主题
Re: [TICTOC] FW: 1588 over MPLS draft

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 

Hi all,

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of ext Pietilainen, Antti (NSN - FI/Espoo)
Sent: Monday, August 02, 2010 4:56 PM
To: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf 
Of ext [email-masked]
Sent: Tuesday, July 20, 2010 1:54 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

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.

BR,
 
Sébastien

De : [email-masked] [mailto:[email-masked]] De la part 
de Lizhong Jin
Envoyé : lundi 19 juillet 2010 17:45
À : [email-masked]
Cc : [email-masked]
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

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

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Aug 2010 10:43:36 +0300

Hi Yaakov,
 
When addressing PTP over MPLS with PTP protocol support from intermediate nodes, one is actually solving the problem how to carry time synchronization over OTN (optical transport network), SDH (synchronous optical network), and SONET (and even Ethernet). This is exactly what ITU-T SG15 is doing. I cannot see anything else but full overlap.  
 
The security is another issue where I see overlap. The threat analysis requires participation of telecom people who have now learnt IEEE 1588 well and understand best the threats to the timing system in telecom transport equipment. These people sit in Q13 and therefore the analysis should be started there. For example, I have realized that almost all the general "Internet threats" are in vain concerning the security of time synchronization. The security could be worked forward in ITU as a subtopic or starting cooperation with IETF if needed.
 
MIBs have probably never got much priority in ITU so probably an IEEE 1588 telecom profile MIB would not see daylight there. Therefore Q13 should give away the responsibility to IETF if IETF wishes to work on it. I propose to have some liaisoning between the organizations so that all important managed objects would be present in the MIB in the correct way without a large propostion of people working in two stds organizations simultaneously.
 
Best regards, Antti

From: ext Yaakov Stein [mailto:[email-masked]] 
Sent: Monday, August 02, 2010 10:18 PM
To: Pietilainen, Antti (NSN - FI/Espoo); [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Antti,

Y(J)S

 

Damn,

Best regards, Antti 

Hi all,

Hi all,

Best regards, Antti

 

BR,

Sébastien

Hi Sasha,

BR

Lizhong

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Aug 2010 09:57:58 +0200 (CEST)

On Tue, 3 Aug 2010, Pietilainen, Antti (NSN - FI/Espoo) wrote:

> When addressing PTP over MPLS with PTP protocol support from 
> intermediate nodes, one is actually solving the problem how to carry 
> time synchronization over OTN (optical transport network), SDH 
> (synchronous optical network), and SONET (and even Ethernet). This is 
> exactly what ITU-T SG15 is doing. I cannot see anything else but full 
> overlap.

Should I interpret the above that you're saying the problem and solution 
is identical in MPLS-TP and MPLS?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Aug 2010 11:24:19 +0300

No, I'm just considering the IETF/ITU overlap on optical transmission of
time.
Antti

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 3 Aug 2010 11:37:49 +0300

Antti

From: Pietilainen, Antti (NSN - FI/Espoo) [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 10:44
To: Yaakov Stein; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Yaakov,

Do you see the ITU defining LDP TLVs or RSVP-TE objects for LSRs to recognize timing packets ?
How about requesting a reserved label, or defining the use of TC (ex-EXP) bits in the label stack ?
I don't.

I believe that you are confusing two different things.
One is the architecture of timing distribution. This is an area of expertise in the ITU.
The other is the issue of  protocol design for the IP suite of protocols (of which MPLS is part).

Once we define the format for timing over MPLS, the ITU and everyone else can build solutions using this format.

The issues of OTN and SDH are completely irrelevant even if one decided to send timing over MPLS over them.
This would not be an OTN or SDH timing solution (which the ITU could easily define).
It would be using an MPLS solution for some other layer network.

I already agreed that this is an area of potential overlap.
However, unfortunately, there are no security experts in Q13.

We would definitely have to work with the IEEE and the ITU (for the limited subset of the "telecom profile") on this issue.

Best regards, Antti

Y(J)S

Y(J)S

Damn,

Best regards, Antti

BR,

Sébastien

BR
Lizhong

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Aug 2010 12:41:33 +0300

Hi Yaakov,
 
Tell me if Im wrong but I guess that the dominant client layer of, for example OTN, is MPLS. If one solves the MPLS case, then one solves the OTN case for a dominant proportion of OTN cases. On the other hand, if one solves timing over OTN without using the MPLS layer, then one does not need to solve how to carry time over MPLS whenever layer 1 is OTN.
 
I'm not fully in opposition of considering IEEE 1588 time transport over MPLS. However, it has not been yet decided whether there is a reason to put it there at all. For example, there is no reason (or one could invent silly reasons) for carrying SyncE over MPLS. PTP time transport is similar to SyncE but requires even stronger attachment to the physical medium than SyncE.
 
The companies participating in Q13 do have security experts. Why not send one or two over to Q13 and the expertise would be there. I believe, the IEEE 1588 telecom profile and general telecom security understanding is far better in Q13 than TICTOC, unless forcing the Q13 participants join also TICTOC meetings.
 
There would be lesser pain when concentrating as much as possible in one place and distribute to other fora when suitable. The MIB could be a good example.
 
Best regards, Antti 

From: ext Yaakov Stein [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2010 11:38 AM
To: Pietilainen, Antti (NSN - FI/Espoo); [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Antti

Hi Yaakov,

I don't.

 

Best regards, Antti

Y(J)S

Antti,

Y(J)S

 

Damn,

Best regards, Antti 

Hi all,

Hi all,

Best regards, Antti

 

BR,

Sébastien

Hi Sasha,

BR

Lizhong

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Aug 2010 12:31:23 +0200 (CEST)

> No, I'm just considering the IETF/ITU overlap on optical transmission of

Personally I'd be more comfortable with extensions/additions to MPLS being 
done within IETF, not in ITU.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Aug 2010 12:37:48 +0200 (CEST)

On Tue, 3 Aug 2010, Pietilainen, Antti (NSN - FI/Espoo) wrote:

> Tell me if Im wrong but I guess that the dominant client layer of, for 
> example OTN, is MPLS. If one solves the MPLS case, then one solves the 
> OTN case for a dominant proportion of OTN cases. On the other hand, if 
> one solves timing over OTN without using the MPLS layer, then one does 
> not need to solve how to carry time over MPLS whenever layer 1 is OTN.

More and more networks are built with DWDM optics being put directly into 
routers/switches, ie no OTN at all. Future framers might be switchable 
between G.709(with FEC), 10GE WAN/LAN phy, and other framing standards, 
but this is not the case today.

So any packet standard addressed by this WG should look at doing the 
standard over packet (and not just MPLS, it should be over IPv4/IPv6 
which might be carried by MPLS, but this should not be a requirement).

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Aug 2010 14:16:21 +0300

Hi Mikael,
Here we have perfect agreement. I proposed this in a recent posting and
proposed further to do the MPLS related work in the MPLS group within
IETF rather than TICTOC.
Antti 

-----Original Message-----
From: ext Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2010 1:31 PM
To: Pietilainen, Antti (NSN - FI/Espoo)
Cc: [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

> No, I'm just considering the IETF/ITU overlap on optical transmission
of

Personally I'd be more comfortable with extensions/additions to MPLS
being 
done within IETF, not in ITU.

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 3 Aug 2010 14:53:37 +0300

Hi Mikael,

> More and more networks are built with DWDM optics being put directly
> into routers/switches, ie no OTN at all.

By no OTN at all, do you mean, eg. 10GE interface? Ethernet interfaces
should not require any changes to IETF protocols when Q13 is developing
the time profile even though IP and UDP protocols might be utilized.

As said earlier, the major IP/MPLS vendors are very well presented in
Q13, and therefore the IETF and IEEE802 standards have been respected
very well there (which, unfortunately cannot be said about some other
groups in ITU).

Best regards, Antti

-----Original Message-----
From: ext Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2010 1:38 PM
To: Pietilainen, Antti (NSN - FI/Espoo)
Cc: ext Yaakov Stein; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

> not need to solve how to carry time over MPLS whenever layer 1 is OTN.

More and more networks are built with DWDM optics being put directly
into 
routers/switches, ie no OTN at all. Future framers might be switchable 
between G.709(with FEC), 10GE WAN/LAN phy, and other framing standards, 
but this is not the case today.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 3 Aug 2010 14:55:05 +0200 (CEST)

> the time profile even though IP and UDP protocols might be utilized.

Yes, for instance an 10GE LAN PHY ethernet interface.

---

From: <[email-masked]>
Date: Tue, 3 Aug 2010 16:47:39 +0100

just as a general comment i think it would be more useful to develop an architecture and then decide on the information to be carried to support the architecture. It seems to often we decide on the protocol and then workout how to develop an architecture around the protocol limitations.

Regards,

Mike

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: 03 August 2010 09:38
To: Pietilainen, Antti (NSN - FI/Espoo); [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Antti

Hi Yaakov,

Best regards, Antti

Y(J)S

Y(J)S

Damn,

Best regards, Antti

BR,

Sébastien

BR
Lizhong

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 3 Aug 2010 10:29:06 -0700

Hi Antti,

I don't understand how 1588 over OTN/SONET can solve the problem of transporting 1588 over an MPLS network. Are you saying all networks must use OTN or SONET? 

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)
Sent: Tuesday, August 03, 2010 4:54 AM
To: ext Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Mikael,

Best regards, Antti

---

From: Danny Mayer <[email-masked]>
Date: Tue, 03 Aug 2010 23:21:08 -0400

On 8/3/2010 4:37 AM, Yaakov Stein wrote:
> Antti
> 
> *From:* Pietilainen, Antti (NSN - FI/Espoo)
> [mailto:[email-masked]]
> *Sent:* Tuesday, August 03, 2010 10:44
> *To:* Yaakov Stein; [email-masked]
> *Subject:* RE: [TICTOC] FW: 1588 over MPLS draft
> 
> Hi Yaakov,
> 
> 
> The security is another issue where I see overlap. The threat analysis
> requires participation of telecom people who have now learnt IEEE 1588
> well and understand best the threats to the timing system in telecom
> transport equipment. These people sit in Q13 and therefore the analysis
> should be started there. For example, I have realized that almost all
> the general "Internet threats" are in vain concerning the security
> of time synchronization. The security could be worked forward in ITU as
> a subtopic or starting cooperation with IETF if needed.
> 
>  
> 

I don't think there are any in the TICTOC WG either. If there are any
would they please identify themselves?

Danny

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 4 Aug 2010 10:57:55 +0300

Hi Shahram,

So let's clarify a little. Unlike in the case of frequency
synchronization I don't expect multiple timing flows going across the
network in the case of time synchronization. Instead, I expect that the
network nodes create a synchronization hierarchy and synchronize the
whole network. Probably BCs will be used. Synchronization service will
be offered at the edges to customers. My view is based on analogy to
Synchronous Ethernet. Note, however, that the architecture has not yet
been discussed in depth in Q13 so other architectures are possible too.

If the architecture presented above is the way to go, the MPLS layer
does not need to do any switching to the timing packets since they are
terminated in every node. The timing protocol itself (not MPLS) decides
what to do with the next hop. So the transporting problem is reduced to
merely getting the packets across a single link. If one can accomplish
that without bothering the MPLS layer, then we are all set just with OTN
- PTP interaction. 

There are several choices of physical layer media and L1 protocols. For
each protocol and medium one needs to separately solve how the physical
layer information is associated with the timing protocol.

Best regards, Antti  

-----Original Message-----
From: ext Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2010 8:29 PM
To: Pietilainen, Antti (NSN - FI/Espoo); ext Mikael Abrahamsson
Cc: [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Antti,

I don't understand how 1588 over OTN/SONET can solve the problem of
transporting 1588 over an MPLS network. Are you saying all networks must
use OTN or SONET? 

Thanks,
Shahram

-----Original Message-----
Of Pietilainen, Antti (NSN - FI/Espoo)

Hi Mikael,

Best regards, Antti

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 4 Aug 2010 10:03:32 +0200 (CEST)

> If the architecture presented above is the way to go, the MPLS layer

This looks like a forklift upgrade of the entire network to accomplish 
what you say above?

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 4 Aug 2010 18:20:07 +0300

> would they please identify themselves?

We have volunteers, and the support of the IETF security directorate.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 4 Aug 2010 18:22:46 +0300

Antti

Which part of the work needs to be done in MPLS or PWE or TICTOC is easily worked out.
As is usual in such cases, documents will be discussed on several lists, cross-reviewed, 
and probably LC'ed in >1 WG.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)
Sent: Tuesday, August 03, 2010 14:16
To: ext Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Mikael,

---

From: <[email-masked]>
Date: Thu, 5 Aug 2010 14:29:49 +0200

Hi Antti,

Just to mention that I have a similar analysis as yours for the phase/time architecture.

And I also agree with Mike's comment: let's first discuss what the architecture will be, and it will automatically determine what to do with the protocols, as well as where there might be issues to be solved.

Thanks.

BR, 

Sébastien

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Pietilainen, Antti (NSN - FI/Espoo)
Envoyé : mercredi 4 août 2010 09:58
À : ext Shahram Davari; ext Mikael Abrahamsson
Cc : [email-masked]
Objet : Re: [TICTOC] FW: 1588 over MPLS draft

Hi Shahram,

So let's clarify a little. Unlike in the case of frequency synchronization I don't expect multiple timing flows going across the network in the case of time synchronization. Instead, I expect that the network nodes create a synchronization hierarchy and synchronize the whole network. Probably BCs will be used. Synchronization service will be offered at the edges to customers. My view is based on analogy to Synchronous Ethernet. Note, however, that the architecture has not yet been discussed in depth in Q13 so other architectures are possible too.

If the architecture presented above is the way to go, the MPLS layer does not need to do any switching to the timing packets since they are terminated in every node. The timing protocol itself (not MPLS) decides what to do with the next hop. So the transporting problem is reduced to merely getting the packets across a single link. If one can accomplish that without bothering the MPLS layer, then we are all set just with OTN
- PTP interaction. 

There are several choices of physical layer media and L1 protocols. For each protocol and medium one needs to separately solve how the physical layer information is associated with the timing protocol.

Best regards, Antti  

-----Original Message-----
From: ext Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 8:29 PM
To: Pietilainen, Antti (NSN - FI/Espoo); ext Mikael Abrahamsson
Cc: [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Antti,

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)
Sent: Tuesday, August 03, 2010 4:54 AM
To: ext Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Mikael,

> into routers/switches, ie no OTN at all.

By no OTN at all, do you mean, eg. 10GE interface? Ethernet interfaces should not require any changes to IETF protocols when Q13 is developing the time profile even though IP and UDP protocols might be utilized.

As said earlier, the major IP/MPLS vendors are very well presented in Q13, and therefore the IETF and IEEE802 standards have been respected very well there (which, unfortunately cannot be said about some other groups in ITU).

Best regards, Antti

-----Original Message-----
From: ext Mikael Abrahamsson [mailto:[email-masked]]
Sent: Tuesday, August 03, 2010 1:38 PM
To: Pietilainen, Antti (NSN - FI/Espoo)
Cc: ext Yaakov Stein; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

> not need to solve how to carry time over MPLS whenever layer 1 is OTN.

More and more networks are built with DWDM optics being put directly into routers/switches, ie no OTN at all. Future framers might be switchable between G.709(with FEC), 10GE WAN/LAN phy, and other framing standards, but this is not the case today.

So any packet standard addressed by this WG should look at doing the standard over packet (and not just MPLS, it should be over IPv4/IPv6 which might be carried by MPLS, but this should not be a requirement).