Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

From: [email-masked]
Date: Wed, 9 Feb 2011 03:29:53 -0500

Hi Manav,

A high level point is that for the pure MPLS mapping (section 5.3) , I
wonder if what is really needed is a PTP profile for MPLS -- similar to
Annex D/E/F for IPv4/IPv6/Ethernet, respectively.  For example the IP &
Ethernet profiles include other information such as the port addressing for
the unicast master table and acceptable master table.  Without a full
profile, although the intermediate notes may operate in TC, the server,
client and boundary nodes may not operate successfully.

Its not clear if this draft is intended to cover all clock types (OC, BC &
TC) or only TC.  There are many sections that talk only about TC without
considering OC and BC behaviour or impact.  Is BC intended to be covered as
a Client-side OC + Server-side OC model, or is BC excluded from
consideration in this draft?  Perhaps this draft should be either
cleaned-up to consider all clock types or should be restricted to only TC
clock type with OC & BC out of scope.

Some specific comments

+ The abstract could be clarified to indicate there are three mappings, not
two (pure MPLS, UDP/IP over MPLS and Ethernet over MPLS).  I think the
third mapping may be under discussion, so perhaps this is premature.

+ A few places in the text the phrase "proper handling of these packets" or
"properly handle PTP messages" or "perform proper  processing"  is used to
mean transparent clock.  I would propose to remove such language as from
the ITU-T studies of timing performances of PTP one could argue the
"proper" way is to implement a boundary clock.  Where the intention is to
aid the designer of a TC that is fine to describe the implementation
recommendation, but not to suggest this is the way to acheive the best
performance or even the desired way to deploy PTP over MPLS.

+ I would like to see a statement added in the document that the
performance aspects (e.g. the phase or frequency alignment) are outside the
scope of the document.

+ Section 6, 7, 8, 10 and 13 seems to focus only on the TC case between
OC's and does not consider BC situation.

+ Section 12 text on checksums could be improved to indicate this only
applies to TC and not to OC & BC.

+ Section 16 seems to address only TC clocks and not OC or BC clocks.

+ Section 16.3 implies that the only possible way to handle PTP is TC,
excluding BC --- "don't have the capability to process 1588 packets (e.g.
TC processing)" and "   Non-1588-aware LSRs ignore the RSVP 1588_PTP_LSP
object and just switch the MPLS packets carrying 1588 messages as data
packets and don't perform any TC processing."

Regards,

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]  | www.zarlink.com

             "Bhatia, Manav                                                
             (Manav)"                                                      
             <manav.bhatia@alc                                          To 
             atel-lucent.com>          "[email-masked]" <[email-masked]> 
             Sent by:                                                   cc 
             <tictoc-bounces@i                                             
             etf.org>                                              Subject 
                                       [TICTOC]                            
                                       draft-ietf-tictoc-1588overmpls-00.t 
             26/01/2011 11:22          xt                                  
             AM                                                            

Hi,

We've tried incorporating most of the comments that we received on the
list. Please ping me if you think we have missed some.

Would be great if the WG can go through this and provide feedback on the
same.

The draft is available here:
http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588overmpls-00.txt

Cheers, Manav

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, January 26, 2011 9.30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [TICTOC] I-D Action:draft-ietf-tictoc-1588overmpls-00.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Timing over IP Connection
> and Transfer of Clock Working Group of the IETF.
>
>
>            Title           : Transporting PTP messages (1588) over
> MPLS Networks
>            Author(s)       : S. Davari, et al.
>            Filename        : draft-ietf-tictoc-1588overmpls-00.txt
>            Pages           : 35
>            Date            : 2011-01-26
>
> This document defines the method for transporting PTP messages (PDUs)
> over an MPLS network to enable a proper handling of these packets
> (e.g. implementation of Transparent Clocks (TC)) in LSRs.
>

Cheers, Manav

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

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 9 Feb 2011 18:50:27 +0530

Hi Peter,

Very valid comments. 

This draft covers all clock types - TC, BC and OC. The reason it seems we've been concentrating on TC is because that's the clock type that requires special MPLS processing. 

For BC's and OC's there is no special processing involved. One just needs an MPLS LSP that terminates on a BC and OC and things will just work. However, I get the drift of what youre saying and we can update the draft to explicitly state this.

I will let someone more knowledgeable respond to your question on whether a separate profile for MPLS is required or not. To my untrained eye it looks that we might.

Cheers, Manav 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, February 09, 2011 2.00 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC
> 
> 
> Hi Manav,
> 
> 
>              <manav.bhatia@alc                                
>           To 
>              Sent by:                                         
>           cc 
>              etf.org>                                         
>      Subject 
> ----------
> This email is confidential and may contain information that 
> is privileged and
> exempt from disclosure by law.  If you have received it in 
> error, please contact
> the sender immediately by return email and then delete it 
> from your system; you
> should not copy it or disclose its contents to anyone.  
> Emails are not secure
> and cannot be guaranteed to be error free as they can be 
> intercepted, amended,
> lost or destroyed, or contain viruses.  Anyone who 
> communicates with us by email
> is taken to accept these risks.
>

---

From: "Roberts, Peter (Peter)" <[email-masked]>
Date: Wed, 9 Feb 2011 07:52:10 -0600

Peter,
With respect to your comments on the profile, the Annexes are not profiles.  They are the portions of the standard that define the rules for running PTP over specific lower layer protocols.  These can then be included or excluded from specific profiles that are defined.  This draft is defining these rules for the MPLS environment.  
The draft covers all the clock types but as you point out this is not all that clear.  This can be added.
In addition, I don't believe the ITU-T has concluded anything about performance of BC vs TC.  They have just started studying the issue.  But this draft is not making any claims about performance and as stated earlier should be applicable for any of the clock types.  We can review it to remove any contentious wording in respect to performance.
Peter R.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments. 

Cheers, Manav

---

From: [email-masked]
Date: Wed, 9 Feb 2011 10:05:30 -0500

Thanks.

Yes, a poor choice of words on the Annexes being "profiles".  We would 
still need to fill out the Annex info though re: port addresses and the 
like to ensure inter-operability.

I am fine to be neutral on performance aspects -- I would recommend to 
indicate they are not within scope of the document. 
ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]  | www.zarlink.com

"Roberts, Peter (Peter)" <[email-masked]> 
Sent by: <[email-masked]>
09/02/2011 08:52 AM

To
"Bhatia, Manav (Manav)" <[email-masked]>, 
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Peter,
With respect to your comments on the profile, the Annexes are not 
profiles.  They are the portions of the standard that define the rules for 
running PTP over specific lower layer protocols.  These can then be 
included or excluded from specific profiles that are defined.  This draft 
is defining these rules for the MPLS environment. 
The draft covers all the clock types but as you point out this is not all 
that clear.  This can be added.
In addition, I don't believe the ITU-T has concluded anything about 
performance of BC vs TC.  They have just started studying the issue.  But 
this draft is not making any claims about performance and as stated 
earlier should be applicable for any of the clock types.  We can review it 
to remove any contentious wording in respect to performance.
Peter R.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments. 

This draft covers all clock types - TC, BC and OC. The reason it seems 
we've been concentrating on TC is because that's the clock type that 
requires special MPLS processing. 

For BC's and OC's there is no special processing involved. One just needs 
an MPLS LSP that terminates on a BC and OC and things will just work. 
However, I get the drift of what youre saying and we can update the draft 
to explicitly state this.

I will let someone more knowledgeable respond to your question on whether 
a separate profile for MPLS is required or not. To my untrained eye it 
looks that we might.

Cheers, Manav

---

From: Stefano Ruffini <[email-masked]>
Date: Thu, 10 Feb 2011 17:35:02 +0100

Peter M., Peter R.

I wonder if there is really a need (use case) for section 5.3 (pure MPLS mapping) ?

 Best Regards

Stefano

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: mercoledì 9 febbraio 2011 16.06
To: Roberts, Peter (Peter)
Cc: [email-masked]; [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Thanks.

Yes, a poor choice of words on the Annexes being "profiles".  We would still need to fill out the Annex info though re: port addresses and the like to ensure inter-operability.

I am fine to be neutral on performance aspects -- I would recommend to indicate they are not within scope of the document.

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked]<mailto:[email-masked]>  | www.zarlink.com<http://www.zarlink.com/>

09/02/2011 08:52 AM

To
"Bhatia, Manav (Manav)" <[email-masked]>, "[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Peter,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments.

Cheers, Manav

---

From: [email-masked]
Date: Thu, 10 Feb 2011 19:23:23 -0500

Hi Stefano,

I do not know if there is a need for pure MPLS mapping, it is not really an
area with which I am familiar.

My opinion is only that if an MPLS mapping is added for PTP, that we must
fully define the PTP operation (in-line with the other Annexes in IEEE
1588) to support all the PTP features and ensure inter-operability.

Regards,

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

             Stefano Ruffini                                               
             <stefano.ruffini@                                             
             ericsson.com>                                              To 
             Sent by:                  "[email-masked]"           
             <tictoc-bounces@i         <[email-masked]>,          
             etf.org>                  "Roberts, Peter       (Peter)"      
                                       <[email-masked]>  
                                                                        cc 
             10/02/2011 11:35          "[email-masked]"                   
             AM                        <[email-masked]>,                  
                                       "[email-masked]"           
                                       <[email-masked]>           
                                                                   Subject 
                                       Re: [TICTOC] 1588overmpls-00 / MPLS 
                                       profile & BC                        

                                                                           

Peter M., Peter R.

I wonder if there is really a need (use case) for section 5.3 (pure MPLS
mapping) ?

 Best Regards

Stefano

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]

Thanks.

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

 "Roberts, Peter (Peter)"                                                  
 <peter.roberts@alcatel-luc                                                
 ent.com>                                                                  
 Sent by:                                                               To 
 <[email-masked]>                      "Bhatia, Manav (Manav)"    
                                                <manav.bhatia@alcatel-luce 
                                                nt.com>,                   
 09/02/2011 08:52 AM                            "[email-masked]"  
                                                <[email-masked]>  
                                                                        cc 
                                                "[email-masked]"          
                                                <[email-masked]>          
                                                                   Subject 
                                                Re: [TICTOC]               
                                                1588overmpls-00 / MPLS     
                                                profile & BC               

                                                                           

Peter,
With respect to your comments on the profile, the Annexes are not profiles.
They are the portions of the standard that define the rules for running PTP
over specific lower layer protocols.  These can then be included or
excluded from specific profiles that are defined.  This draft is defining
these rules for the MPLS environment.
The draft covers all the clock types but as you point out this is not all
that clear.  This can be added.
In addition, I don't believe the ITU-T has concluded anything about
performance of BC vs TC.  They have just started studying the issue.  But
this draft is not making any claims about performance and as stated earlier
should be applicable for any of the clock types.  We can review it to
remove any contentious wording in respect to performance.
Peter R.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments.

I will let someone more knowledgeable respond to your question on whether a
separate profile for MPLS is required or not. To my untrained eye it looks
that we might.

Cheers, Manav

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 17:53:43 +0000

I would think the interface would be Ethernet. How many interfaces are there that are pure MPLS or another.

Maybe someone can expand on this.

Regards,

Mike

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefano Ruffini
Sent: 10 February 2011 16:35
To: [email-masked]; Roberts, Peter (Peter)
Cc: [email-masked]; [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Peter M., Peter R.

 Best Regards

Stefano

Thanks.

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

09/02/2011 08:52 AM

To

Peter,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments.

Cheers, Manav

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 11 Feb 2011 10:11:01 -0800

RAW mapping to MPLS has huge HW impact. No HW can support such a format today, and to be honest not justified when we already have Ethernet and IP encapsulations. We need to have a very good reason to add yet a 3rd option.

Thx
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 11, 2011 9:54 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Regards,

Mike

Peter M., Peter R.

 Best Regards

Stefano

Thanks.

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

09/02/2011 08:52 AM

To

cc

Subject

Peter,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments.

Cheers, Manav

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 23:31:35 +0100

Dear all,

Although I had not the opportunity to read the new versions of the draft that is discussed in this thread, I'll tend to share the same view as expressed by Stefano and Mike in case BCs only are considered.

If we make the assumption that an MPLS node has to support an Ethernet physical layer, then I don't understand the reason to discuss PTP over MPLS (at least, when using BCs only).

That is: why transporting the PTP messages over an MPLS stack, and not simply directly over Ethernet (e.g. using the standard Ethernet mapping specified in IEEE1588-2008)?

(for those of you who have access to ITU-T contributions, you can refer to WD30 discussed during the SG15/Q13 interim meeting in Shenzhen, which tried to explain more in details this point)

It seems to me that TCs are really the reason for this MPLS mapping. But in my opinion, the applicability of TCs in telecoms still needs to be discussed.

The justification of the pure MPLS mapping might be the case of tunneling.

BTW: did you discuss in this draft the issue of identifying the position of the PTP payload (to modify the correction field in the case of TC) in the packet once a packet has been identified as a PTP message?

Indeed, in the general case, nothing forces the PTP payload to be in a fixed location (potential tunneling issue again).

Thanks.

BR,

Sébastien

De : [email-masked] [mailto:[email-masked]] De la part de Shahram Davari
Envoyé : vendredi 11 février 2011 19:11
À : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Thx

Shahram

Regards, 

Mike 

Peter M., Peter R.

 Best Regards

Stefano 

Thanks. 

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization
Communication Products Group
Office: +1-613-270-7203  |  Fax: +1-613-592-1010
[email-masked] <mailto:[email-masked]>   | www.zarlink.com <http://www.zarlink.com/> 

09/02/2011 08:52 AM 

To

cc

Subject

		

Peter,

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments. 

Cheers, Manav 

> From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] 
> http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588over <http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588over> 
> mpls-00.txt
> 
> Cheers, Manav
> 
> > [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc <https://www.ietf.org/mailman/listinfo/tictoc> 
> 
> 
> 
> ----------
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc <https://www.ietf.org/mailman/listinfo/tictoc> 
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc <https://www.ietf.org/mailman/listinfo/tictoc>

---

From: Lars Ellegaard <[email-masked]>
Date: Sat, 12 Feb 2011 10:06:28 +0000

This would be PTPoverACHoMPLSoETH (or other link layer technologies).

In my view MPLS(-TP) provides "transport" of an application, which is behind some form of addressing (typically IP, Ethernet).
Only exception are (MPLS) transport associated mechanisms like OAM. MPLS(-TP) does not have an addressing scheme.
It would therefore be a violation of this if the PTP application (which requires multicast/unicast addressing) is carried directly after the label (even after the ACH).
In other words even though it is possible, I suggest not to support PTPoACHoMPLS or PTPoMPLS.

BR Lars

Sent: 11 February 2011 18:54

Regards,

Mike

Peter M., Peter R.

 Best Regards

Stefano

Thanks.

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

09/02/2011 08:52 AM

To

cc

Subject

Peter,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments.

Cheers, Manav

---

From: Ron Cohen <[email-masked]>
Date: Sun, 13 Feb 2011 09:51:25 +0200

Hi,

Here is how I see it.

There are several advantages for TC over BC it terms of implementation: you
don't need to maintain a clock, and you can implement all (most) of
operations in hardware, and as a result its much easier to upgrade equipment
to be PTP capable (see my previous post on per-port vs. per node PTP-capable
attribute). TCs also allows transport of multiple timescales with ease,
while this complicates BC considerably (This may or may not be needed in our
case though).

Hence, I see an advantage in deploying a BC on the boundary of the MPLS
domain, and implementing TCs within the MPLS domain, connecting the edge
BCs.

MPLS allows you to set a label-switched-path (LSP) which is fully
controlled: you can select hop by hop how the messages are transported,
selecting paths that support PTP at each hop (and not necessarily the
shortest path), that are symmetric (or for which asymmetry is known), that
are shared with SyncE synchronization chain (although I don't think its
necessary), etc.

MPLS advantage is that regardless of the underlying layer1/2 technology,
whether it is Ethernet, SONET, RPR etc, MPLS will allow setting these path
using the same procedures. Over an MPLS domain, this is maybe the only setup
protocol suite available.

Hence MPLS will allow setting PTP MPLS LSPs through the MPLS domain TCs.

Not all features available in MPLS are relevant for PTP transport. The PTP
profile should define all this. For example, many of the MPLS protection
features should be carefully selected, in order not to introduce phase
transients in downstream slaves.

Assuming the above makes sense, there is a need to define an MPLS PTP
profile, for which the current draft is a first step. The profile may
include MPLS to PTP event propagation (i.e. failures in MPLS signaled within
PTP messages),  etc. Raw PTP over MPLS encapsulation makes sense in this
scenario too, especially as the latest draft defines signaling offset of PTP
header, to avoid deep packet inspection on top of MPLS, and hence supports
also new encaps  (Hence I don't understand Shahram point).

Best,
Ron

On Sat, Feb 12, 2011 at 12:06 PM, Lars Ellegaard <[email-masked]> wrote:

> In my view MPLS(-TP) provides “transport” of an application, which is
> behind some form of addressing (typically IP, Ethernet).
>
> Only exception are (MPLS) transport associated mechanisms like OAM.
> MPLS(-TP) does not have an addressing scheme.
>
> It would therefore be a violation of this if the PTP application (which
> requires multicast/unicast addressing) is carried directly after the label
> (even after the ACH).
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* 11 February 2011 18:54
> *To:* [email-masked]; [email-masked];
> [email-masked]
>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC
>
>
>
> *Mike*
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Stefano Ruffini
> *Sent:* 10 February 2011 16:35
> *To:* [email-masked]; Roberts, Peter (Peter)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC
>
> Peter M., Peter R.
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* mercoledì 9 febbraio 2011 16.06
> *To:* Roberts, Peter (Peter)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC
>
>
> Thanks.
>
> still need to fill out the Annex info though re: port addresses and the like
> to ensure inter-operability.
>
> *ZARLINK** *Semiconductor*
> Peter Meyer
> Timing & Synchronization
> Communication Products Group**
> Office: +1-613-270-7203**  |  **Fax: +1-613-592-1010**
> [email-masked] <[email-masked]> * | *www.zarlink.com
>
>
>
>    *"Roberts, Peter (Peter)" <[email-masked]>*
> over specific lower layer protocols.  These can then be included or excluded
> from specific profiles that are defined.  This draft is defining these rules
> for the MPLS environment.
> should be applicable for any of the clock types.  We can review it to remove
> any contentious wording in respect to performance.
> Peter R.
>
>
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf Of Bhatia, Manav (Manav)
> However, I get the drift of what youre saying and we can update the draft to
> explicitly state this.
>
> > From: [email-masked] [mailto:[email-masked]<[email-masked]>]
>
> > > [mailto:[email-masked] <[email-masked]>] On Behalf
> Of
> > [email-masked]

---

From: <[email-masked]>
Date: Sun, 13 Feb 2011 14:04:19 +0100

Hi Ron,

Interesting view. As far as I understand, it sounds however a bit misaligned with the on-going work at ITU-T.

Just a quick question for my clarification: how do you manage the case when another transport technology (e.g. Ethernet) is used between two MPLS nodes if only an "MPLS mapping" is considered? (I understand that it may happen within an MPLS domain). The two MPLS nodes may even not be aware that there is something in the middle.

Thanks.

BR,

Sébastien

De : [email-masked] [mailto:[email-masked]] De la part de Ron Cohen
Envoyé : dimanche 13 février 2011 08:51
À : Lars Ellegaard
Cc : [email-masked]; [email-masked]
Objet : Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi,

Here is how I see it.

There are several advantages for TC over BC it terms of implementation: you don't need to maintain a clock, and you can implement all (most) of operations in hardware, and as a result its much easier to upgrade equipment to be PTP capable (see my previous post on per-port vs. per node PTP-capable attribute). TCs also allows transport of multiple timescales with ease, while this complicates BC considerably (This may or may not be needed in our case though).
 
Hence, I see an advantage in deploying a BC on the boundary of the MPLS domain, and implementing TCs within the MPLS domain, connecting the edge BCs.

MPLS allows you to set a label-switched-path (LSP) which is fully controlled: you can select hop by hop how the messages are transported, selecting paths that support PTP at each hop (and not necessarily the shortest path), that are symmetric (or for which asymmetry is known), that are shared with SyncE synchronization chain (although I don't think its necessary), etc. 

MPLS advantage is that regardless of the underlying layer1/2 technology, whether it is Ethernet, SONET, RPR etc, MPLS will allow setting these path using the same procedures. Over an MPLS domain, this is maybe the only setup protocol suite available.

Not all features available in MPLS are relevant for PTP transport. The PTP profile should define all this. For example, many of the MPLS protection features should be carefully selected, in order not to introduce phase transients in downstream slaves. 

Assuming the above makes sense, there is a need to define an MPLS PTP profile, for which the current draft is a first step. The profile may include MPLS to PTP event propagation (i.e. failures in MPLS signaled within PTP messages),  etc. Raw PTP over MPLS encapsulation makes sense in this scenario too, especially as the latest draft defines signaling offset of PTP header, to avoid deep packet inspection on top of MPLS, and hence supports also new encaps  (Hence I don't understand Shahram point). 

Best,
Ron

BR Lars

Regards, 

Mike 

Peter M., Peter R.

 Best Regards

Stefano 

Thanks. 

ZARLINK Semiconductor
Peter Meyer
Timing & Synchronization

09/02/2011 08:52 AM 

To

cc

Subject

		

Peter,

-----Original Message-----
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Bhatia, Manav (Manav)
Sent: February 9, 2011 8:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC

Hi Peter,

Very valid comments. 

Cheers, Manav 

> [email-masked]  | www.zarlink.com <http://www.zarlink.com> 
> 
> 
> 
>                                                               
>              
>              "Bhatia, Manav                                   
>              
>              (Manav)"                                         
>              
>              <manav.bhatia@alc                                
>           To

---

From: Ron Cohen <[email-masked]>
Date: Sun, 13 Feb 2011 15:49:56 +0200

Hi Sebastien,

I'm not sure I understand the question, so my answer below may be off topic.

One of the requirements for PTP-LSP should be that it is PTP-capable at each
segment. Therefore the LSP will not be setup over segments which include
non-PTP capable nodes in the middle, even if these nodes support MPLS
switching. Although MPLS allows hierarchy through label stacking, the PTP
over MPLS profile may specify, in my opinion, that only single label stack
should be used, unless we are in a special scenario yet to be discussed.

Not all MPLS LSR are also 802.1 bridges. That is, even if an LSR has
Ethernet interfaces it may not be able to forward Ethernet messages
according to their destination address. If the LSR is also a BC it may or
may not be configured to process the PTP messages. If what is required is TC
functionality, and the LSR doesn't support bridging, these messages will not
be forwarded at all, hence some form of PTP over MPLS (whether raw, IP or
other) is needed.

Best,
Ron

On Sun, Feb 13, 2011 at 3:04 PM, <[email-masked]>wrote:

>  Hi Ron,
>
>
>
> Interesting view. As far as I understand, it sounds however a bit
> misaligned with the on-going work at ITU-T.
>
>
>
> Just a quick question for my clarification: how do you manage the case when
> another transport technology (e.g. Ethernet) is used between two MPLS nodes
> if only an “MPLS mapping” is considered? (I understand that it may happen
> within an MPLS domain). The two MPLS nodes may even not be aware that there
> is something in the middle.
>
>
>
> Thanks.
>
>
>
> BR,
>
>
>
> Sébastien
>
>
>
> *De :* [email-masked] [mailto:[email-masked]] *De la
> part de* Ron Cohen
> *Envoyé :* dimanche 13 février 2011 08:51
> *À :* Lars Ellegaard
> *Cc :* [email-masked]; [email-masked]
> *Objet :* Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC
>
>
>
> Hi,
>
> Here is how I see it.
>