Subject: [TICTOC] FW: 1588 over MPLS draft

From: "Shahram Davari" <[email-masked]>
Date: Wed, 7 Jul 2010 12:35:59 -0700

From: Shahram Davari
Sent: Wednesday, July 07, 2010 12:12 PM
To: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: 1588 over MPLS draft

Hi All,

Please find attached our first draft of 1588 over MPLS. Since we have some technical issues converting the Word format to Txt we couldn't  upload the draft before the cut-off date. However we will present the draft in the next IETF meeting and will upload the draft after the meeting.

Note that the main WG is TicToc but may require consultation with MPLS and PWE3 WGs.

Thanks,
Shahram Davari

---

From: <[email-masked]>
Date: Thu, 8 Jul 2010 17:36:41 +0200

Hi,
 
After reading this interesting draft, I would have some questions for clarification (sorry, I will not attend to the Maastricht meeting).
 
My first general question is related to the objective of TICTOC regarding this topic: is it planned that TICTOC would develop a specific mechanism for transporting PTP over MPLS as the one proposed in this document? If so, is it oriented to telecoms applications, or to other types of applications?
 
My second question would be to better understand why there is a need for transporting PTP over MPLS. It is still unclear to me. FYI, similar discussions happened in June in ITU-T Q13/15 during the last Geneva meeting.
 
My understanding of the context of this draft is that the network between a PTP master and a PTP slave experiences full timing support for PTP, such as TC in every node (or possibly BC, that is also slightly evoked in the document?). In this context, it can be questioned if the PTP timing delivery is really done "end-to-end", since every node has to process the PTP messages. Therefore, is it really appropriate in this case to put the PTP messages into a tunneling transport, such as MPLS?
 
It looks more logical to me in this situation to transport the PTP timing flows outside MPLS (e.g. simply over UDP/IP) on a hop-by-hop basis (e.g. each node delivers its timing to the next one).
But maybe I misunderstood or missed something...
 
Any thoughts?
 
Thanks.
 
BR,
 
Sébastien

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Shahram Davari
Envoyé : mercredi 7 juillet 2010 21:36
À : [email-masked]
Objet : [TICTOC] FW: 1588 over MPLS draft

From: Shahram Davari 

Hi All,

Thanks,

Shahram Davari

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 8 Jul 2010 11:06:05 -0700

Hi Sebastian,

Thanks for reading the draft. I will try to give you're my own understanding of the issue.

We know that if we want better accuracy and control and less complex algorithms in the Slave, it is best that most hops between 1588 Master and Slave perform Transparent Clocking (TC). As you mentioned one method is to use direct IP routing. However there are cases that this doesn't work. For example MPLS-TP networks don't support IP routing. Also when 1588 Master and Slave are in two different Ethernet networks separated by an MPLS network, it is simpler to just tunnel 1588 packets via Ethernet PW.

I hope this helps.

Thanks
Shahram

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 08, 2010 8:37 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi,

Any thoughts?

Thanks.

BR,

Sébastien

From: Shahram Davari

Hi All,

Thanks,
Shahram Davari

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 8 Jul 2010 11:09:21 -0700

Just to clarify:  by simpler  I meant Boundary clock is not required.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Thursday, July 08, 2010 11:06 AM
To: [email-masked]; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Sebastian,

I hope this helps.

Thanks
Shahram

Hi,

Any thoughts?

Thanks.

BR,

Sébastien

From: Shahram Davari

Hi All,

Thanks,
Shahram Davari

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 9 Jul 2010 07:06:13 +0300

Sebastien

Yes, developing an MPLS encapsulation for 1588 is high on TICTOC's list of things to accomplish.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 08, 2010 18:37
To: [email-masked]; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi,

Any thoughts?

Thanks.

BR,

Sébastien

From: Shahram Davari

Hi All,

Please find attached our first draft of 1588 over MPLS. Since we have some technical issues converting the Word format to Txt we couldn’t  upload the draft before the cut-off date. However we will present the draft in the next IETF meeting and will upload the draft after the meeting.

Thanks,
Shahram Davari

---

From: <[email-masked]>
Date: Fri, 9 Jul 2010 10:23:17 +0200

Thank you Shahram (and Yaakov) for the reply.
 
Just for my clarification:
 
"one method is to use direct IP routing. However there are cases that this doesn't work. For example MPLS-TP networks don't support IP routing."
=> Does it mean that MPLS-TP nodes do not understand IP?
 
"Also when 1588 Master and Slave are in two different Ethernet networks separated by an MPLS network, it is simpler to just tunnel 1588 packets via Ethernet PW."
=> It is not clear to me why it is simpler to carry them into a tunnel if finally the PTP messages are extracted from the tunnel by each node to be processed. Could you explain?
 
Thanks.
 
BR,
 
Sébastien

De : Shahram Davari [mailto:[email-masked]] 
Envoyé : jeudi 8 juillet 2010 20:06
À : JOBERT Sebastien RD-CORE-LAN; [email-masked]
Objet : RE: [TICTOC] FW: 1588 over MPLS draft

Hi Sebastian,

I hope this helps.

Thanks

Shahram

Hi,

Any thoughts?

Thanks.

BR,

Sébastien

 

From: Shahram Davari 

Hi All,

Thanks,

Shahram Davari

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 09 Jul 2010 10:34:37 +0100

On 09/07/2010 09:23, [email-masked] wrote:
> "one method is to use direct IP routing. However there are cases that 
> this doesn't work. For example MPLS-TP networks don't support IP routing."
They may not. Indeed I have always though that it was strange that Q13 
are working on an IP based time distribution protocol, whilst the other 
Questions who are designing the transports over which timing have to 
flow are insisting that IP may not be present in the equipment, 
especially in the forwarding plane.
Stewart

---

From: <[email-masked]>
Date: Fri, 9 Jul 2010 11:46:22 +0200

Thanks Stewart.
 
I understand from the "may" that you used that MPLS-TP nodes may also possibly support IP forwarding plane, correct? (I mean, MPLS-TP does not rule out using IP forwarding in the same node).
If so, then I understand that the problem that TICTOC is trying to solve is mainly the case of MPLS-TP nodes not supporting IP forwarding. Is that correct?
 
Another question for my clarification (sorry for my poor knowledge on MPLS-TP...): does MPLS-TP only imply that IP forwarding only may not be supported, or also that IP may not be supported at all in the equipment (e.g. for other purposes than forwarding plane, such as management)?
 
Thanks.
 
BR, 

Sébastien

De : Stewart Bryant [mailto:[email-masked]] 
Envoyé : vendredi 9 juillet 2010 11:35
À : JOBERT Sebastien RD-CORE-LAN
Cc : [email-masked]; [email-masked]
Objet : Re: [TICTOC] FW: 1588 over MPLS draft

	 

They may not. Indeed I have always though that it was strange that Q13 are working on an IP based time distribution protocol, whilst the other Questions who are designing the transports over which timing have to flow are insisting that IP may not be present in the equipment, especially in the forwarding plane.

Stewart

---

From: <[email-masked]>
Date: Fri, 9 Jul 2010 20:38:15 +0100

Hi Yaakov,

when you say encapsulation what is the intention e.g. at the interface?

Mike
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yaakov Stein [[email-masked]]
Sent: 09 July 2010 05:06
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Sebastien

Y(J)S

Hi,

Any thoughts?

Thanks.

BR,

Sébastien

From: Shahram Davari

Hi All,

Thanks,
Shahram Davari

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2010 12:41:59 -0700

And, how can the encapsulation be anything other than EthernetPW?

Tony

On Jul 9, 2010, at 12:38 PM, <[email-masked]> wrote:

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

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 9 Jul 2010 14:12:01 -0700

Hi Sebastien,

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 09, 2010 1:23 AM
To: Shahram Davari; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

"one method is to use direct IP routing. However there are cases that this doesn't work. For example MPLS-TP networks don't support IP routing."
=> Does it mean that MPLS-TP nodes do not understand IP?
[SD>] Yes MPLS-TP nodes don't understand IP in data-plane and may even not understand IP in control/management plane.

"Also when 1588 Master and Slave are in two different Ethernet networks separated by an MPLS network, it is simpler to just tunnel 1588 packets via Ethernet PW."
=> It is not clear to me why it is simpler to carry them into a tunnel if finally the PTP messages are extracted from the tunnel by each node to be processed. Could you explain?
[SD>] assume Master send Sync message to Slave. A the boundary of Ethernet-MPLS we have 2 choices:

1)      Carry the Sync message in MPLS (via PW)

2)      Terminate the Sync message via a boundary lock and the generate new Sync message with UDP/IP header

Obviously carrying the Sync message in PW is much simpler than having a boundary clock.

Thanks.

BR,

Sébastien

I hope this helps.

Thanks
Shahram

Hi,

Any thoughts?

Thanks.

BR,

Sébastien

From: Shahram Davari

Hi All,

Thanks,
Shahram Davari

---

From: Ron Cohen <[email-masked]>
Date: Sat, 10 Jul 2010 08:27:38 +0300

Hi Tony,

PTP is designed to be extended over multiple transports. Some transports are
included in IEEE1588-2008 Annex-s, while the idea was that others (such as
MPLS) will be developed by the expert standardization bodies.

I wrote a proposal a while ago for direct PTP over MPLS mapping. It is still
available here http://tools.ietf.org/html/draft-ronc-ptp-mpls-00 . At least
part of it still makes sense.

Best,
Ron

On Fri, Jul 9, 2010 at 10:41 PM, Tony Li <[email-masked]> wrote:

> > After reading this interesting draft, I would have some questions for
> clarification (sorry, I will not attend to the Maastricht meeting).
> >
> > My first general question is related to the objective of TICTOC regarding
> this topic: is it planned that TICTOC would develop a specific mechanism for
> transporting PTP over MPLS as the one proposed in this document? If so, is
> it oriented to telecoms applications, or to other types of applications?
> >
> > My second question would be to better understand why there is a need for
> transporting PTP over MPLS. It is still unclear to me. FYI, similar
> discussions happened in June in ITU-T Q13/15 during the last Geneva meeting.
> >
> > My understanding of the context of this draft is that the network between
> a PTP master and a PTP slave experiences full timing support for PTP, such
> as TC in every node (or possibly BC, that is also slightly evoked in the
> document?). In this context, it can be questioned if the PTP timing delivery
> is really done "end-to-end", since every node has to process the PTP
> messages. Therefore, is it really appropriate in this case to put the PTP
> messages into a tunneling transport, such as MPLS?
> >
> > It looks more logical to me in this situation to transport the PTP timing
> flows outside MPLS (e.g. simply over UDP/IP) on a hop-by-hop basis (e.g.
> each node delivers its timing to the next one).
> > Please find attached our first draft of 1588 over MPLS. Since we have
> some technical issues converting the Word format to Txt we couldn’t  upload
> the draft before the cut-off date. However we will present the draft in the
> next IETF meeting and will upload the draft after the meeting.
> >

---

From: Tony Li <[email-masked]>
Date: Fri, 9 Jul 2010 22:53:02 -0700

Thanks Ron.

Please pardon my ignorance, but what's the benefit of this over doing an EthernetPW?  

Tony

On Jul 9, 2010, at 10:27 PM, Ron Cohen wrote:

> Hi Tony,
> 
> PTP is designed to be extended over multiple transports. Some transports are included in IEEE1588-2008 Annex-s, while the idea was that others (such as MPLS) will be developed by the expert standardization bodies.
> 
> I wrote a proposal a while ago for direct PTP over MPLS mapping. It is still available here http://tools.ietf.org/html/draft-ronc-ptp-mpls-00 . At least part of it still makes sense.
> 
> Best,
> Ron
>

---

From: Ron Cohen <[email-masked]>
Date: Sat, 10 Jul 2010 09:43:37 +0300

Tony,

The idea is that this encapsulation is used in scenarios where the MPLS
cloud is PTP-aware. MPLS LSRs act as boundary (or transparent) clocks and
ensure that time delivery is will not be affected by queuing and forwarding
delays.

I think the question in these scenarios should be the other way round: why
should PTP messages sent between two PTP aware LSRs be encapsulated in
Ethernet and/or IP? Beyond bandwidth efficiency, addition of superfluous
layers adds complications and implementation assumptions. I think it is
similar to the reason why OAM messages between two LSRs are not encapsulated
in Ethernet/IP.

Does this make sense?

Best,
Ron

On Sat, Jul 10, 2010 at 8:53 AM, Tony Li <[email-masked]> wrote:

> > PTP is designed to be extended over multiple transports. Some transports
> are included in IEEE1588-2008 Annex-s, while the idea was that others (such
> as MPLS) will be developed by the expert standardization bodies.
> >
> > I wrote a proposal a while ago for direct PTP over MPLS mapping. It is
> still available here http://tools.ietf.org/html/draft-ronc-ptp-mpls-00 .
> At least part of it still makes sense.
> >
> > Best,
> > Ron
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> > > My first general question is related to the objective of TICTOC
> regarding this topic: is it planned that TICTOC would develop a specific
> mechanism for transporting PTP over MPLS as the one proposed in this
> document? If so, is it oriented to telecoms applications, or to other types
> of applications?
> > >
> > > My second question would be to better understand why there is a need
> for transporting PTP over MPLS. It is still unclear to me. FYI, similar
> > > My understanding of the context of this draft is that the network
> between a PTP master and a PTP slave experiences full timing support for
> PTP, such as TC in every node (or possibly BC, that is also slightly evoked
> in the document?). In this context, it can be questioned if the PTP timing
> delivery is really done "end-to-end", since every node has to process the
> PTP messages. Therefore, is it really appropriate in this case to put the
> PTP messages into a tunneling transport, such as MPLS?
> > >
> > > It looks more logical to me in this situation to transport the PTP
> timing flows outside MPLS (e.g. simply over UDP/IP) on a hop-by-hop basis
> (e.g. each node delivers its timing to the next one).

---

From: Tony Li <[email-masked]>
Date: Sat, 10 Jul 2010 00:46:09 -0700

Ron,

All true, but the cost is implementing Yet Another Encapsulation.

The bandwidth delta isn't big enough to be worth discussing.  What's another 20 bytes?  

And the reason why OAM isn't in IP is wholly due to politics.  If folks really wanted to do good engineering, they would have done BFD for reachability and IP based traceroute.  Adding more complexity just so that we can each have our own little standards is NOT efficient engineering and a good use of any of our resources.

Tony

On Jul 9, 2010, at 11:43 PM, Ron Cohen wrote:

> Tony,
> 
> The idea is that this encapsulation is used in scenarios where the MPLS cloud is PTP-aware. MPLS LSRs act as boundary (or transparent) clocks and ensure that time delivery is will not be affected by queuing and forwarding delays. 
> 
> I think the question in these scenarios should be the other way round: why should PTP messages sent between two PTP aware LSRs be encapsulated in Ethernet and/or IP? Beyond bandwidth efficiency, addition of superfluous layers adds complications and implementation assumptions. I think it is similar to the reason why OAM messages between two LSRs are not encapsulated in Ethernet/IP.
> 
> Does this make sense?
> 
> Best, 
> Ron
> 
> 
> 
>

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 10 Jul 2010 09:34:36 +0100

If we ignore issues associated with existing chipsets that support 
1588/E and 1588/UDP/IP, my preferred approach would be 1588/MPLS. Indeed 
I might be tempted to significantly reduce the protocol options in this 
environment. i.e. create a new 1588 protocol mapping which runs over a 
PTP FEC.

We need to think whether we would need to translate into one of the more 
common client mapping via boundary clock, or whether we could do direct 
protocol mapping, but I am concerned at the number of layers that we 
need if we retain the Ethernet or the IP headers.

Stewart

-- 
For corporate legal information go to:

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 11 Jul 2010 13:35:15 +0300

Stewart, and all,
IMHO and FWIW, there are two valid reasons to deliver PTP (a.k.a. 1588) over MPLS:
1. Ability to TE the PTP paths, e.g., to use co-routed bi-directional LSPs for PTP transport.
   This would hopefully eliminate potential negative effects of asymmetric paths on clock
   recovered by PTP slaves
2. Ability to employ TC by (somehow) making the intermediate nodes aware of PTP packets so that
   they could update the PTP correction field. The method by which such awareness is achieved
   should meet several important restrictions:
   - It should be compatible with the MPLS data plane architecture (RFC 3031). In particular, it should not
     imply any special treatments in the ILM for "generic" labels
   - Nodes that do not have TC capabilities should be traversed without incurring significant additional delay
   - Backward compatibility with existing MPLS deployments should be possible
   - It should be possible to distinguish between the following situations along the desired LSP between a PTP
     Master and PTP slave:
     * All LSR on the path are TC-capable
     * Some LSR on the path may be not TC-capable, but all LSR on the path can forward PTP packets without incurring
       significant additional delay
     * There is at least one LSR on the desired path that does not support any TC-specific MPLS forwarding
       mechanisms.
        
Please note that both items above are fully compatible with running PTP over UDP/IP in labeled packets. 
And nothing in these requirements implies IP forwarding in the data plane. (From my point of view ability to
identify a labeled packet as an IP packet "for me" by the LSP tail-end node is different for IP forwarding;
e.g., in MPLS-TP this ability is required to facilitate IP-based management communication.)

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Saturday, July 10, 2010 11:35 AM
To: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Stewart

---

From: Michel Ouellette <[email-masked]>
Date: Mon, 12 Jul 2010 14:23:02 -0400

Hi Sharam,

II have some initial comments and questions.  Not sure yet if I will attend
the meeting.

I do tend to agree that there are cases where there is a need for LSRs to
identify PTP messages. The draft is similar in some aspects to some of the
proposals made by Ron Cohen back in 2007.  The two differences I see is that
your draft proposes to use the outer label to identify PTP messages and to
use the standard PTP mappings (Annex D & F of IEEE1588), whereas in Cohen's
draft, the outer label was not used (ie., the PW instead was proposed to
distinguish the PTP LSP types) in addition to a proposal to have a direct
mapping of PTP into MPLS, although that would require a new networkProtocol
enumeration as defined in IEEE1588.

The draft primarily discusses the use for Transparent Clock, but it is
equally application to Boundary Clocks. Actually it should be useable for
any types of clocks defined in IEEE1588.  There are scenarios where you
might have a time synchronization chain composed of only BC-LSRs or TC-LSRs
or combination/mix. There is a need to clarify reference models as I think
these might further add requirements to the "PTP LSP" definition.

In section1, you say "the accuracy of the recovered clock improves".  Are
you referring to the distribution of frequency or time in this specific
paragraph?

In section 1, you also say "it should be possible to instead control the
delay for these messages on both directions across the node".  In theory
this is possible, but practically very difficult because of the current QoS
architecture (i.e., it is hard to control the per-hop behaviour (PBH) that
determines the scheduling treatment of packets to produce such results)

In section 8, can you clarify what is meant by "any PTP LSP failure will
trigger the slave to switch to the Redundant Master, even if the LSP is
protected at the MPLS layer". Why is that?

Thanks.

Michel

From: Shahram Davari 

Hi All,

Please find attached our first draft of 1588 over MPLS. Since we have some
technical issues converting the Word format to Txt we couldn't  upload the
draft before the cut-off date. However we will present the draft in the next
IETF meeting and will upload the draft after the meeting.

Note that the main WG is TicToc but may require consultation with MPLS and
PWE3 WGs.

Thanks,

Shahram Davari

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 12 Jul 2010 14:14:23 -0700

Hi Michel,

From: Michel Ouellette [mailto:[email-masked]]
Sent: Monday, July 12, 2010 11:23 AM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Sharam,

II have some initial comments and questions.  Not sure yet if I will attend the meeting.

I do tend to agree that there are cases where there is a need for LSRs to identify PTP messages. The draft is similar in some aspects to some of the proposals made by Ron Cohen back in 2007.  The two differences I see is that your draft proposes to use the outer label to identify PTP messages and to use the standard PTP mappings (Annex D & F of IEEE1588), whereas in Cohen's draft, the outer label was not used (ie., the PW instead was proposed to distinguish the PTP LSP types) in addition to a proposal to have a direct mapping of PTP into MPLS, although that would require a new networkProtocol enumeration as defined in IEEE1588.

SD> I know Ron had a nice draft, but the issue with that draft is that it required Deep packet inspection at line rate for all packets. Also it requires use of CW.

The draft primarily discusses the use for Transparent Clock, but it is equally application to Boundary Clocks. Actually it should be useable for any types of clocks defined in IEEE1588.  There are scenarios where you might have a time synchronization chain composed of only BC-LSRs or TC-LSRs or combination/mix. There is a need to clarify reference models as I think these might further add requirements to the "PTP LSP" definition.

SD> Sure we can expand it more.

In section1, you say "the accuracy of the recovered clock improves".  Are you referring to the distribution of frequency or time in this specific paragraph?

SD> Both. When intermediate nodes perform Transparent Clock, they remove most of the delay variation and help improve accuracy.

In section 1, you also say "it should be possible to instead control the delay for these messages on both directions across the node".  In theory this is possible, but practically very difficult because of the current QoS architecture (i.e., it is hard to control the per-hop behaviour (PBH) that determines the scheduling treatment of packets to produce such results)

SD> Why? Can't you just assign these packets to EF-PHB?

In section 8, can you clarify what is meant by "any PTP LSP failure will trigger the slave to switch to the Redundant Master, even if the LSP is protected at the MPLS layer". Why is that?

SD> When a PTP LSP fails the Slave detects the failure very quickly and switches to the Redundant Master even before protection switching kicks in. So LSP protection kicks in way after the Slave has switched to redundant Master.

Thx
Shahram

Thanks.

Michel

From: Shahram Davari

Hi All,

Thanks,
Shahram Davari

---

From: Ron Cohen <[email-masked]>
Date: Tue, 13 Jul 2010 08:37:59 +0300

Shaharm,

> SD> I know Ron had a nice draft, but the issue with that draft is that it
> required Deep packet inspection at line rate for all packets. Also it
> requires use of CW.
>
Thanks for the compliment, but you probably read someone's else draft. Here
it is http://tools.ietf.org/html/draft-ronc-ptp-mpls-00

The draft defines a PTP PW FEC (see section 6), hence it doesn't require any
inspection. CW is not used (see figure 5).

It does specify a direct PTP over MPLS mapping, without the additional use
of Ethernet or IP encapsulation.

Best,
Ron

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 13 Jul 2010 10:03:02 -0700

Hi Ron,

Hope you are doing fine.  Sorry for my comment, I had read it a while back and couldn't remember it precisely. However, let's discuss it:

1)      How do the Intermediate LSRs detect that a packet contains PTP? Do you  require snooping at line rate?

2)      How is a normal Ethernet or ATM or FR PW packet that uses CW is differentiated from a packet carrying PTP?

Thanks,
Shahram
From: Ron Cohen [mailto:[email-masked]]
Sent: Monday, July 12, 2010 10:38 PM
To: Shahram Davari
Cc: Michel Ouellette; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Shaharm,
SD> I know Ron had a nice draft, but the issue with that draft is that it required Deep packet inspection at line rate for all packets. Also it requires use of CW.
Thanks for the compliment, but you probably read someone's else draft. Here it is http://tools.ietf.org/html/draft-ronc-ptp-mpls-00

The draft defines a PTP PW FEC (see section 6), hence it doesn't require any inspection. CW is not used (see figure 5).

It does specify a direct PTP over MPLS mapping, without the additional use of Ethernet or IP encapsulation.

Best,
Ron

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 13 Jul 2010 22:11:50 +0300

Hi all, 

I have been out of contact for a few days, and just found that quite a few of you have commented on this issue.

There seem to have been two issues raised.

1) Why do we need to define an MPLS (or MPLS-TP) encap ?
As many have said TC (or BC) is one reason. 
I am not sure we are going to see TC handling in LSRs any time soon, but it is a reason.  
Perhaps a better reason for now is QoS. I really want to easily recognize a timing flow to give it EF service.
Of course this can be done by giving it its own label and assigning the proper QoS to that label
(which is Shahram suggests), but it may be easier to make timing flows universally recognizable
(as router alerts are).

2) Why do we need a new encap. Why not just use the UDP/IP one and put it in MPLS, or the Ethernet one in a PW.
Of course it is fine to carry 1588 inside UDP/IP or Ethernet inside MPLS.
For that matter you can put the 1588 in Ethernet inside an Ethernet PW inside IP (using RFC 4023) inside MPLS,
and many other encaps.  The problem is the predictability of finding the fields inside.

When you say 1588 in Ethernet encap, is that untagged ? 1 VLAN tag ? 2 tags ? MAC-in-MAC ?
In UDP/IP is that without IP options ? 

The idea behind defining another transport layer (and, incidentally, there are already more defined in 1588)

We COULD standardize one of these (e.g., never tagged), 
but what would we do in a hybrid scenario when it comes in from Ethernet with a tag ?

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

Tony

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Jul 2010 22:33:24 +0300

Yaakov,
Please see inline below.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Yaakov Stein [[email-masked]]
Sent: Tuesday, July 13, 2010 10:11 PM
To: Tony Li; Ron Cohen; Shahram Davari; [email-masked]
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi all,

1) Why do we need to define an MPLS (or MPLS-TP) encap ?
As many have said TC (or BC) is one reason.
[[Sasha]] TC is the reason, BC, IMO, is not. 
I am not sure we are going to see TC handling in LSRs any time soon, but it is a reason.
Perhaps a better reason for now is QoS. I really want to easily recognize a timing flow to give it EF service.
[[Sasha]] QoS is IMO not an issue. It exists over IP as well as over MPLS. 
Of course this can be done by giving it its own label and assigning the proper QoS to that label
(which is Shahram suggests), but it may be easier to make timing flows universally recognizable
(as router alerts are).
[[Sasha]] Exactly!!! If you want every LSR on the way to be able to inspect and modify the packet, you need a RA label or, rather, its analog - let's call it the PTP Alert label, or PTPA for (not so) short.
This would be a new reserved label (and yes, some are still left) with the following rules:
- just as the RA label, it can be anywhere in the stack except at the bottom
- An LSR that observes this label (because it was at the top of the stack or because it has popped all the labels
  above it) will do the following:
  * Check the payload of the MPLS packet  for being a PTP packet in one of the existing encapsulations
     (my personal preference is PTP over UDP/IP, but it is not that relevant)
  * If the check succeeds and the LSR is a TC, update the correction field in this packet
  * Forward this packet as indicated by the label immediately below the PTPA. If this means sending    
     a labeled packet, add PTPA at the top of the resulting label stack (again, same treatment as for the RA).
     The forwarding rule is applied regardless of the results of check for carrying PTP.
The only differences with RA is that passing the PTPA-labeled packet to a software module is not required
(and probably should be avoided). 

It would be also pretty easy to check if there any malicious LSRs on your LSP that do not recognize PTPA: just use ICMP-Ping in this LSP with and without added PTPA on top... if it does not work with PTPA but works without it, there is an LSR that treats PTPA as an unknown label and discards the packet...

Does this make sense?

My 2c,
     Sasha  

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 13 Jul 2010 13:02:15 -0700

> but what would we do in a hybrid scenario when it comes in from Ethernet with a tag ?

My experience suggests that operators will do whatever minimizes their operational complexity.  This implies that if they are running a IP over MPLS network today, that they will use an IP encapsulation.  If they are running a primarily PW over MPLS network today, they will run PTP over PW.

In short, we will have to deal with _all_ of these encapsulations already.  Defining a new one only makes the problem larger, and it's of dubious value as most providers will not want to assign labels simply for PTP.

My $.03,
Tony

---

From: Ron Cohen <[email-masked]>
Date: Tue, 13 Jul 2010 23:49:05 +0300

Hi Shahram,

Its been a while since I read this draft as well....  After reading it again
and reading your draft the second time, indeed the issue identification of
PTP LSP by intermediate TCs is not addressed in the draft I wrote. This can
be solved by extending the PTP FEC signaling defined in the draft between
ordinary and boundary clocks to also address signaling between all PTP aware
LSRs (i.e. including TCs). The approach described in your draft is also a
valid starting point.

Best,
Ron

On Tue, Jul 13, 2010 at 8:03 PM, Shahram Davari <[email-masked]> wrote:

>  Hi Ron,
>
>
>
> Hope you are doing fine.  Sorry for my comment, I had read it a while back
> and couldn’t remember it precisely. However, let’s discuss it:
>
>
>
> 2)      How is a normal Ethernet or ATM or FR PW packet that uses CW is
> differentiated from a packet carrying PTP?
>
>
>
> Thanks,
>
> Shahram
>
> *From:* Ron Cohen [mailto:[email-masked]]
> *Sent:* Monday, July 12, 2010 10:38 PM
> *To:* Shahram Davari
> *Cc:* Michel Ouellette; [email-masked]
> *Subject:* Re: [TICTOC] FW: 1588 over MPLS draft
>
>
>
> Shaharm,
>
>  Thanks for the compliment, but you probably read someone's else draft.
> Here it is http://tools.ietf.org/html/draft-ronc-ptp-mpls-00
>
>
>
> The draft defines a PTP PW FEC (see section 6), hence it doesn't require
> any inspection. CW is not used (see figure 5).
>
>
>

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 14 Jul 2010 18:34:48 +0300

Sasha

<YJS> IMO it is. There are many reasons to shun TCs. They are a cute trick, 
but the layer violation can mean trouble in many cases. BCs avoid the problem, at the cost of
1) more complex implementation at mid points, and 2) phase error accumulation.

<snip>

Yes, QoS exists, but we need to know what QoS to give to what.
Shahram's suggestion is to use specific labels. That is OK, but may be troublesome to implement.

About a year ago I put together a list of 9 ways to send 1588 over MPLS, and the first one
was UDP/IP/MPLS. In the preliminary discussions most people thought that this was the route
to use if we can not standardize something better (it can be done NOW). Just set up a minimum delay
LSP for the timing flow, and the problem is solved. Or is it ?

The first problem is scaling. Remember the early days of PWE ? The original suggestion was
PW = LSP, but then Luca convinced us that this doesn't scale. You can't expect all the P routers
to know about all these labels. and for timing we may need thousands of unicast flows going through the core
(of course multicasting is another solution).

That is why my following methods relied on a universal marking.

[[Sasha]] Exactly!!! If you want every LSR on the way to be able to inspect and modify the packet, 
you need a RA label or, rather, its analog - let's call it the PTP Alert label, or PTPA for (not so) short.

<YJS>  YES !  This is my method number 3.  A new reserved label. Of course we need to convince the MPLS
WG to give us one (there aren't that many ...)

<YJS>  YES. We are thinking along the same lines.

Of course an alternative would be a well-known, or at least network-wide CoS bit combination (alternative 2).

Or a PW with certain marking in the control word (alternative 4).

Or using the GAL GAch.

[[Sasha]] Does this make sense?

<YJS>  yes, IMO. Shahram's approach makes sense if there are only a small number of timing flows.
Universal markings makes sense if there are many.

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 14 Jul 2010 18:41:02 +0300

Ron,

Nice to see you participating on this list.

When you proposed your MPLS transport format for 1588, I was very much against it (I freely admit).

The reason I was against was that I knew that if we allowed this, then the next step was to demand TC functionality,
and no LSR manufacturer I knew was interested in that happening.

However, over the last year I have changed my mind.
The reason is MPLS-TP.

I can see MPLS-TP switches (I am trying to call them a different name from LSR)
for special-purpose networks, such as cellular SPs, implementing all sorts of on-path support mechanisms.

So it took a long time, but I have finally come around.

I think one of the things TICTOC should do is to decide how to best handle this issue.

If we decide that the default method (AKA Shahram's method) is optimal, or even "good enough"
then we can either leave it at that, or come up with a BCP.

If we decide that we need something more scalable, then there are various options,
and we need to produce a standard's track document.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Cohen
Sent: Tuesday, July 13, 2010 23:49
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Hi Shahram,

Its been a while since I read this draft as well....  After reading it again and reading your draft the second time, indeed the issue identification of PTP LSP by intermediate TCs is not addressed in the draft I wrote. This can be solved by extending the PTP FEC signaling defined in the draft between ordinary and boundary clocks to also address signaling between all PTP aware LSRs (i.e. including TCs). The approach described in your draft is also a valid starting point.

Best,
Ron

On Tue, Jul 13, 2010 at 8:03 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ron,

Thanks,
Shahram
From: Ron Cohen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, July 12, 2010 10:38 PM
To: Shahram Davari
Cc: Michel Ouellette; [email-masked]<mailto:[email-masked]>
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Shaharm,

Best,
Ron

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 14 Jul 2010 09:46:22 -0700

Dear Yaakov and All,

<snip>

> WG to give us one (there aren't that many ...)
GIM>> What if instead of LSP/PW as PTP transport we use dedicated to
1588 ACH in an MPLS-TP DCN? TC-capable nodes might be interconnected
by DCN links and processing TC would not violate network layers.

Regards,
Greg

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 14 Jul 2010 20:43:37 +0300

Greg

Yes, a dedicated Ach is a possibility. I mentioned that as using the GAch format. I actually like this idea.

But why do you believe that this is any less of a layer violation ?
The timestamps come from layer 1 (they are physical mechanisms) 
while MPLS is somewhere around layer 2 or higher.
If the MPLS is carried over Ethernet or some other CRC protected layer 2, the CRC would need to be updated.
If there is some integrity protection at layer 1 or 2 then it will break when we update the TC field, 
and the packet would be discarded.
If there is layer 2 encryption, the mechanism won't be applicable unless we open and close the encryption
at a link-by-link basis.

Y(J)S

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 19:46
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Dear Yaakov and All,

<snip>

Regards,
Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 14 Jul 2010 11:04:13 -0700

Hi Greg,

The problem is that most routers send DCN packets to CPU directly, while at least for 1-step TC we want HW forwarding.

Thanks,
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, July 14, 2010 9:46 AM
To: Yaakov Stein
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Dear Yaakov and All,

<snip>

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 14 Jul 2010 11:05:56 -0700

Dear Yaakov,
perhaps my wording wasn't precise. I think of ACH option not as
PTP-over-MPLT-TP transport but as PTP interworking between 1588
MPLS-TP domain and 1588 non-MPLS-TP (IP/UDP) domain.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 14 Jul 2010 11:09:02 -0700

Dear Shahram,
Then routers/LSRs will have to change ;)
If CV/CC as well as LM/DM can be HW-based/assisted, I'd assume that
there will be HW support for 1588-ACH if need to be.

Regards,
Greg

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Jul 2010 21:01:53 +0200 (CEST)

> there will be HW support for 1588-ACH if need to be.

Please don't count on hw upgrade to do anything, if it's at all possible 
to do without HW upgrade and specific protocol support.

Assuring priority queueing (always first served) for important traffic 
(like sync) is ok, we already do that. As an ISP, demands that require 
forklift upgrades of tons of equipment to deploy is usually a no-go.

Please if at all possible, make sure that anything being developed can 
work over hw-forwarding assisted platforms (to keep down jitter) with QoS, 
even if they're 5-10 years old.

Also, our core network doesn't do MPLS-TP, it does MPLS. MPLS-TP might be 
used in smaller distribution parts, but it's not a core technology for us. 
We also want to build one core network, not multiple.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 15 Jul 2010 10:29:30 +0100

> (like sync) is ok, we already do that.

Depending on your algorithm, I am not sure how much that helps.

The best timing "edge" is generated by the few packets that do not 
experience any queuing at all, in which case the high priority queue 
does not help much, indeed you might be wasting the queue by using it 
for this.

Stewart

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 15 Jul 2010 11:26:14 -0700

Hi Sasha,

I like your PTP Alert label idea, except that 1588 unaware routers will probably not forward such packets.

Thanks,
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 12:33 PM
To: Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Yaakov,
Please see inline below.

Regards,
     Sasha

Hi all,

Does this make sense?

My 2c,
     Sasha  

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

Tony

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Jul 2010 21:50:58 +0300

Shahram hi,
Very glad to hear from you, hope to see you in Maastricht.

Regarding your comment about routers that are not PTP-aware:
- you can easily identify these routers if they are on your LSP (use LSP-Ping with PTP Alert label on top of the original stack)
- non-aware routers treat PTP alert almost as if it were Router Alert label. I believe this would be quite easy to achieve.

The main advantage (from my point of view) is that this approach would not break MPLS architecture as defined 
in RFC 3031. Specifically, you do not have to add new actions ("update correction field, swap labels and forward")
to the ILM. Breaking 3031 would open a real Pandora box IMO.
Instead, you would just consume one more reserved label and associate special actions with it.
This is a pretty common method of introducing exceptions in MPLS IMO. 
Of course all this is only makes sense if TC are really needed. I am not sure this is the case. 

Regards,
     Sasha

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 9:26 PM
To: Alexander Vainshtein; Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Sasha,

Thanks,
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 12:33 PM
To: Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Yaakov,
Please see inline below.

Regards,
     Sasha

Hi all,

Does this make sense?

My 2c,
     Sasha  

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

Tony

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 15 Jul 2010 11:56:13 -0700

Hi Sasha,

It is fine if non-1588 aware routers send packets with PTP Alert label to CPU, and then forward it via software, but the problem is that this extra latency is not fixed and introduces variable jitter. Right?

Thanks,
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 11:51 AM
To: Shahram Davari
Cc: [email-masked]; Tony Li; Ron Cohen; [email-masked]; Yaakov Stein
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Shahram hi,

Regards,
     Sasha

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 9:26 PM
To: Alexander Vainshtein; Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Sasha,

Thanks,
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 12:33 PM
To: Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Yaakov,
Please see inline below.

Regards,
     Sasha

Hi all,

Does this make sense?

My 2c,
     Sasha  

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

Tony

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 15 Jul 2010 22:04:16 +0300

Shahram,
This is why the routers that understand the PTPA label but do not support PTP in general and TC in particular should treat this label *almost* as the Router Alert one, i.e., forward base on the next label and, in the case the packet is forwarded as labeled, add this label on top of the stack - without sending it to software.
As I said I think that adding this functionality to existing LSRs would be easy.
For the reference, introducing GAL (this Swiss Army knife of MPLS-TP) did not raise any objections. And complexity of supporting PTPA label in the LSR data plane is comparable IMHO.

Regards,
     Sasha

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 9:56 PM
To: Alexander Vainshtein
Cc: [email-masked]; Tony Li; Ron Cohen; [email-masked]; Yaakov Stein
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Sasha,

Thanks,
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 11:51 AM
To: Shahram Davari
Cc: [email-masked]; Tony Li; Ron Cohen; [email-masked]; Yaakov Stein
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Shahram hi,

Regards,
     Sasha

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 9:26 PM
To: Alexander Vainshtein; Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Sasha,

Thanks,
Shahram

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Tuesday, July 13, 2010 12:33 PM
To: Yaakov Stein
Cc: [email-masked]; Tony Li; Ron Cohen; Shahram Davari; [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Yaakov,
Please see inline below.

Regards,
     Sasha

Hi all,

Does this make sense?

My 2c,
     Sasha  

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

Tony

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 15 Jul 2010 22:04:04 +0100

Reserved labels are very much a utility of last resort. There are only 
16 of them to last us the whole life of MPLS, so that should only be 
used when there is no other method.

It is not a good idea to probe the network to discover a capability, it 
is far better to know it through a property of  the routing protocol. 
That way you can match the path to the set of capable LSRs.

Stewart

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 18 Jul 2010 14:19:19 +0300

Stewart and all, 

Indeed, the limited number of reserved labels was the main drawback of the "reserved label" approach when I first raised it.

The other possibility of this sort was a special CoS bit combination,
but there are no universally defined CoS (yet).

So, are we back to the GAL ?  

If so, there are still at least 4 options :
1) define a new protocol type (plenty of openings in THAT registry!)
2) put 1588 packet into an ACH TLV
3) use IPv4 protocol type with 1588 over UDP/IP but mark it in some other way (e.g., reserved field)
4) define a new first nibble (0010 ?)  <ugh!>

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Friday, July 16, 2010 00:04
To: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Stewart

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 19 Jul 2010 08:48:08 +0200 (CEST)

> 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: Yaakov Stein <[email-masked]>
Date: Mon, 19 Jul 2010 12:05:57 +0300

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 19 Jul 2010 12:59:25 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: Monday, July 19, 2010 12:06 PM
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Y(J)S

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 19 Jul 2010 11:16:14 +0100

I have always been assuming that we would do this over a timing FEC - 
not reserved labels - not special types - ordinary MPLS with a timing 
semantics attached to the label(s).

What I would also like to see is an encapsulation that works for both 
NTP and 1588 - i.e. put the corrections in a well known place at the 
front of the packet (we have to pick a single TS format), followed by 
the timing payload (NTP, 1588 or foo), then fix it all up at the edge of 
the network, either via a slave timeserver, of via correcting the packets.

Stewart

---

From: Danny Mayer <[email-masked]>
Date: Mon, 19 Jul 2010 09:22:03 -0400

On 7/18/2010 7:19 AM, Yaakov Stein wrote:
> Stewart and all, 
> 
> Indeed, the limited number of reserved labels was the main drawback
> of the "reserved label" approach when I first raised it.
> 

You *MUST* allow both IPv4 *and* IPv6 for an IETF document if you are
using IP at all. If you need to know which is being used then there is a
major problem here.

Danny

---

From: Michel Ouellette <[email-masked]>
Date: Mon, 19 Jul 2010 22:09:38 -0400

Hi Sharam,

two comments below on your remarks. Bye.

  _____  

From: Shahram Davari [mailto:[email-masked]] 
Sent: July 12, 2010 05:14 PM
To: Michel Ouellette
Cc: [email-masked]
Subject: RE: [TICTOC] FW: 1588 over MPLS draft

Hi Michel,

Hi Sharam,

SD> Both. When intermediate nodes perform Transparent Clock, they remove
most of the delay variation and help improve accuracy.

MO: Sure you can assign them to EF, but there are absolutely no guarantees
with the current QoS architecture and traffic management mechanism to
maintain a differential delay within the network element that is well within
the requirements for your application (eg, the microsecond level).  The
forward direction in a network element is independent from the reverse
direction. and in addition, EF PHB does not control any of the additional
latency within a network element that could be incurred after any strict
priority scheduling. 

SD> When a PTP LSP fails the Slave detects the failure very quickly and
switches to the Redundant Master even before protection switching kicks in.
So LSP protection kicks in way after the Slave has switched to redundant
Master.

MO: The state machine as defined in IEEE1588 does not permit that, but maybe
you want to clarify what you mean by "trigger the slave" (ie., trigger based
on signal fail coming from the physical layer or from the PTP protocol state
machine).

Thx

Shahram

Thanks.

Michel

From: Shahram Davari 

Hi All,

Thanks,

Shahram Davari

---

From: Michel Ouellette <[email-masked]>
Date: Mon, 19 Jul 2010 22:26:13 -0400

Hi Sasha,

One comment below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexander Vainshtein
Sent: July 13, 2010 03:33 PM
To: Yaakov Stein
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Yaakov,
Please see inline below.

Regards,
     Sasha

From: [email-masked] [[email-masked]] On Behalf Of Yaakov
Stein [[email-masked]]

Hi all,

I have been out of contact for a few days, and just found that quite a few
of you have commented on this issue.

MO: Actually, for a BC you also need a way to identify and terminate the PTP
packets.  It is actually no different than if one uses the pdelay mechanism
of a peer-to-peer TC (ie., need to identify and terminate the PTP packets),
as opposed to an end-to-end TC (ie., need only to identify the PTP packets).

I am not sure we are going to see TC handling in LSRs any time soon, but it
is a reason.
Perhaps a better reason for now is QoS. I really want to easily recognize a
timing flow to give it EF service.
[[Sasha]] QoS is IMO not an issue. It exists over IP as well as over MPLS. 
Of course this can be done by giving it its own label and assigning the
proper QoS to that label
(which is Shahram suggests), but it may be easier to make timing flows
universally recognizable
(as router alerts are).
[[Sasha]] Exactly!!! If you want every LSR on the way to be able to inspect
and modify the packet, you need a RA label or, rather, its analog - let's
call it the PTP Alert label, or PTPA for (not so) short.
This would be a new reserved label (and yes, some are still left) with the
following rules:
- just as the RA label, it can be anywhere in the stack except at the bottom
- An LSR that observes this label (because it was at the top of the stack or
because it has popped all the labels
  above it) will do the following:
  * Check the payload of the MPLS packet  for being a PTP packet in one of
the existing encapsulations
     (my personal preference is PTP over UDP/IP, but it is not that
relevant)
  * If the check succeeds and the LSR is a TC, update the correction field
in this packet
  * Forward this packet as indicated by the label immediately below the
PTPA. If this means sending    
     a labeled packet, add PTPA at the top of the resulting label stack
(again, same treatment as for the RA).
     The forwarding rule is applied regardless of the results of check for
carrying PTP.
The only differences with RA is that passing the PTPA-labeled packet to a
software module is not required
(and probably should be avoided). 

It would be also pretty easy to check if there any malicious LSRs on your
LSP that do not recognize PTPA: just use ICMP-Ping in this LSP with and
without added PTPA on top... if it does not work with PTPA but works without
it, there is an LSR that treats PTPA as an unknown label and discards the
packet...

Does this make sense?

My 2c,
     Sasha  

2) Why do we need a new encap. Why not just use the UDP/IP one and put it in
MPLS, or the Ethernet one in a PW.
Of course it is fine to carry 1588 inside UDP/IP or Ethernet inside MPLS.
For that matter you can put the 1588 in Ethernet inside an Ethernet PW
inside IP (using RFC 4023) inside MPLS,
and many other encaps.  The problem is the predictability of finding the
fields inside.

When you say 1588 in Ethernet encap, is that untagged ? 1 VLAN tag ? 2 tags
? MAC-in-MAC ?
In UDP/IP is that without IP options ?

The idea behind defining another transport layer (and, incidentally, there
are already more defined in 1588)

We COULD standardize one of these (e.g., never tagged),
but what would we do in a hybrid scenario when it comes in from Ethernet
with a tag ?

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tony Li
Sent: Saturday, July 10, 2010 10:46
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] FW: 1588 over MPLS draft

Ron,

The bandwidth delta isn't big enough to be worth discussing.  What's another
20 bytes?

And the reason why OAM isn't in IP is wholly due to politics.  If folks
really wanted to do good engineering, they would have done BFD for
reachability and IP based traceroute.  Adding more complexity just so that
we can each have our own little standards is NOT efficient engineering and a
good use of any of our resources.

Tony

> > I wrote a proposal a while ago for direct PTP over MPLS mapping. It is
still available here http://tools.ietf.org/html/draft-ronc-ptp-mpls-00 . At
least part of it still makes sense.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 19 Jul 2010 23:04:03 -0400

> the network, either via a slave timeserver, of via correcting the packets.

I'm not clear here whether you are suggesting diddling with the contents
of the packet or this is some sort of add-on. If you modify the packet
then all attempts to add any authentication is off the table. If you are
changing some other part, any changes cannot be authenticated so you
render the protocol subject to interference. Of course I could be
totally misunderstanding this as I'm not really knowledgable about MPLS
except for the basics.

Danny