Subject: [TICTOC] Updated 1588 over MPLS draf-03

From: "Shahram Davari" <[email-masked]>
Date: Mon, 12 Mar 2012 17:16:39 -0700

Hi,

Please find attached the latest 1588 over MPLS draft (03). Since cut-off date was yesterday, we will upload this after the Paris meeting.
Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some aspects from each of these groups are used in this draft.

We will present this draft in the relevant WGs in Paris.

Regards,
Shahram Davari

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 14 Mar 2012 19:07:44 -0700

Dear Shahram,
perhaps because of "This document provides extensions to OSPF, ISIS ..."
review by OSPF and ISIS WGs should be solicited as well.

Regards,
Greg

On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari <[email-masked]> wrote:

> Hi,****
>
> ** **
>
> Please find attached the latest 1588 over MPLS draft (03). Since cut-off
> date was yesterday, we will upload this after the Paris meeting.****
>
> Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some
> aspects from each of these groups are used in this draft. ****
>
> ** **
>
> We will present this draft in the relevant WGs in Paris.****
>
> ** **
>
> Regards,****
>
> Shahram Davari****
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 15 Mar 2012 11:44:52 -0700

Yes, agree.

Thx
Shahram

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 14, 2012 7:08 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; CCAMP
Subject: Re: [PWE3] Updated 1588 over MPLS draf-03

Dear Shahram,
perhaps because of "This document provides extensions to OSPF, ISIS ..." review by OSPF and ISIS WGs should be solicited as well.

Regards,
Greg
On Mon, Mar 12, 2012 at 5:16 PM, Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,
Shahram Davari

_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: [email-masked]
Date: Wed, 21 Mar 2012 13:09:46 -0400

Hi Shahram et al,

These are my comments on the draft.

1) In section 3, I would suggest this paragraph be removed.  It is unclear 
where this problem arises as it seems the GMs are all traceable back to 
UTC.   Many large operators have confirmed the use and distribution of 
only a single clock domain from core through access, in on-going 
discussions within ITU_T.  Maybe you have some examples of asynchronous 
PTP clock domain deployments, and where this requirement arises?  It would 
be interesting to know what other traceable time base may be used to 
distributed throughout the network, and how multiple GMs are themselves 
synchronized to a timebase other than UTC..  I think it would be easier to 
remove this paragraph than to start-up such a use case discussion.

"There is also a requirement to transport PTP messages belonging to many 
different 1588 domains across an MPLS network,such as the case for whole 
sale (carrier?s carrier case)."

2) In section 4, one example is provided using TCs in the LSRs.   I would 
propse the addition of another example / use case using BCs in the LSRs. 
This traces back to some earlier comments (not fully vetted by MPLS 
routing experts) on the reflector that it seems single-hop PTP LSPs could 
be used between BCs when using a pure BC chain.  This is one of the cases 
listed in section 19 "applicability statements"

3) In section 16.2, it covers on the transparent clock case.  I would 
propose the following changes.

a) "(e.g. transparent clock or boundary clock processing)"
b) "After 1588 processing the packet is forwarded as a normal MPLS packet 
to downstream node (in the case of transparent clock processing), whereas 
a boundary clock terminates the 1588 packets at each node and re-generates 
a new packet downstream".

4) In section 16.3, it covers only the transparent clock case.

"(e.g. perform transparent clock or boundary clock processing)"

5) In section 19, there is a missing line-return between sub-bullet #2 and 
#3

6) In section 19, its unclear why the OC and BC case would not apply to 
non-MPLS interfaces aswell.

Regards,

Regards,
Microsemi Corporation
Peter Meyer
Timing & Synchronization - CMPG
Office:+1-613-270-7203 |  Mobile: +1-613-240-9163 
[email-masked] |  www.zarlink.com

Shahram Davari <[email-masked]> 
Sent by: <[email-masked]>
12/03/2012 08:17 PM

To
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]'" <[email-masked]>, CCAMP <[email-masked]>
cc

Subject
[TICTOC] Updated 1588 over MPLS draf-03

Hi,
 
Please find attached the latest 1588 over MPLS draft (03). Since cut-off 
date was yesterday, we will upload this after the Paris meeting.
Review is required from TICTOC, MPLS, PWE3 and CCAMP WGs, since some 
aspects from each of these groups are used in this draft. 

Regards,
Shahram Davari[attachment "draft-ietf-tictoc-1588overmpls-03.txt" deleted 
by Peter Meyer/Zarlink] _______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 21 Mar 2012 11:29:30 -0700

Hi Peter,

Thanks for your great comments. Please see my responses inline.

Thanks
Shahram

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 21, 2012 10:10 AM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [TICTOC] Updated 1588 over MPLS draf-03

Hi Shahram et al,

1) In section 3, I would suggest this paragraph be removed.  It is unclear where this problem arises as it seems the GMs are all traceable back to UTC.   Many large operators have confirmed the use and distribution of only a single clock domain from core through access, in on-going discussions within ITU_T.  Maybe you have some examples of asynchronous PTP clock domain deployments, and where this requirement arises?  It would be interesting to know what other traceable time base may be used to distributed throughout the network, and how multiple GMs are themselves synchronized to a timebase other than UTC..  I think it would be easier to remove this paragraph than to start-up such a use case discussion.

"There is also a requirement to transport PTP messages belonging to many different 1588 domains across an MPLS network,such as the case for whole sale (carrier?s carrier case)."

SD> This issue was raised by others as well. Although this draft can support the mentioned functionality, but I think it is out of scope of this draft and I am going to remove this sentence.

2) In section 4, one example is provided using TCs in the LSRs.   I would propse the addition of another example / use case using BCs in the LSRs.  This traces back to some earlier comments (not fully vetted by MPLS routing experts) on the reflector that it seems single-hop PTP LSPs could be used between BCs when using a pure BC chain.  This is one of the cases listed in section 19 "applicability statements"

SD> In The BC at every hop case that you mention, the LSR is really acting as LER since it terminates hop-by-hop LSP. This is different from a real LSR doing BC, meaning that without terminating the LSP do the BC operation. So I am going to leave it as is. Please let me know whether you agree with my assessment.

3) In section 16.2, it covers on the transparent clock case.  I would propose the following changes.

SD> Based on my answer to (2), I don't think we need to do this change since LSR is not really doing BC.

b) "After 1588 processing the packet is forwarded as a normal MPLS packet to downstream node (in the case of transparent clock processing), whereas a boundary clock terminates the 1588 packets at each node and re-generates a new packet downstream".

SD> Same as above. No change.

SD> Same as above. No change

5) In section 19, there is a missing line-return between sub-bullet #2 and #3

SD> Corrected. Thanks.

6) In section 19, its unclear why the OC and BC case would not apply to non-MPLS interfaces aswell.

SD> The OC and BC obviously apply to non-MPLS interface, but that is out of the scope of this document which
Tries to document the 1588 over MPLS functionality.

Regards,

Regards,
Microsemi Corporation
Peter Meyer
Timing & Synchronization - CMPG
Office:+1-613-270-7203 |  Mobile: +1-613-240-9163
[email-masked]<mailto:[email-masked]> |  www.zarlink.com<http://www.zarlink.com/>

12/03/2012 08:17 PM

To

"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]'" <[email-masked]>, CCAMP <[email-masked]>

cc

Subject

Hi,

Regards,
Shahram Davari[attachment "draft-ietf-tictoc-1588overmpls-03.txt" deleted by Peter Meyer/Zarlink] _______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

----------

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: Greg Mirsky <[email-masked]>
Date: Wed, 21 Mar 2012 16:03:23 -0700

Hi Shahram,
noticed that both TICTOC and MPLS agendas refer to -02 version of the
document. Would you be presenting -02 or -03?

Regards,
Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 21 Mar 2012 16:52:13 -0700

Hi,

I will present ver-02, since ver-03 was not completed in time. But we like to hear all feddbacks.

Thanks
Shahram

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 21, 2012 4:03 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; CCAMP
Subject: Re: [PWE3] Updated 1588 over MPLS draf-03

Hi Shahram,
noticed that both TICTOC and MPLS agendas refer to -02 version of the document. Would you be presenting -02 or -03?

Regards,
Greg

Regards,
Shahram Davari

---

From: [email-masked]
Date: Thu, 22 Mar 2012 12:16:49 -0400

Hi Shahram,

There are a few points causing some confusion for me.

1) In section 19 it lists the use case that I proposed to add as an 
architecture diagram in section 4.

"  - An LSR receives MPLS encapsulated PTP messages and terminates them, 
while performing the OC or BC functionality"

From your e-mail you seem to indicate this is not a use case.  Or perhaps 
I have not understood your statement about "a real LSR doing BC, meaning 
that without terminating the LSP do the BC operation".  I am only familiar 
with a BC that terminates PTP packets.

2) In section 7 there was previously in -02 the below statement that 
peer-delay messages must be transported over single hop PTP LSPs. 

"SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock and 
MUST be transported over PTP LSPs.  PDELAY_REQ and PDELAY_RESP are 
exchanged between adjacent PTP clocks (i.e.  Master, Slave, Boundary, or 
Transparent) and MAY be transported over single hop PTP    LSPs.  If Two 
Step PTP clocks are present, then the FOLLOW_UP, DELAY_RESP, and 
PDELAY_RESP_FOLLOW_UP messages must also be transported over the PTP 
LSPs."

Now this statement is removed in -03, as well as references to two-step 
PTP clocks and associated FOLLOW_UP & PDELAY_RESP_FOLLOW_UP.

"SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock and 
MUST be transported over PTP LSPs.  PDELAY_REQ and PDELAY_RESP are 
exchanged between adjacent PTP clocks (i.e.  ordinary in Master or  Slave 
state, boundary, or transparent clock) and MAY be transported    over 
single hop PTP LSPs."

For p2p deployments, the exchange & termination of packets between two LSR 
is still required.  For the use case of p2p TC or p2p BC, each LSR must 
generate & terminate some of the PTP messages and process them locally. 
These would be the PDELAY_REQ, PDELAY_RESP and PDELAY_RESP_FOLLOW_UP.  Not 
all PTP messages are sent through the LSR transparently in the case of p2p 
TC.

In such a case it would seem the LSR must be able to terminate a single 
hop PTP LSP, and this could be used for TC or BC implementation in the 
LSR.

Regards,

Microsemi Corporation
Peter Meyer

21/03/2012 02:29 PM

To
"[email-masked]" <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
RE: [TICTOC] Updated 1588 over MPLS draf-03

Hi Peter,

Thanks
Shahram

Hi Shahram et al, 

SD> This issue was raised by others as well. Although this draft can 
support the mentioned functionality, but I think it is out of scope of 
this draft and I am going to remove this sentence.

SD> In The BC at every hop case that you mention, the LSR is really acting 
as LER since it terminates hop-by-hop LSP. This is different from a real 
LSR doing BC, meaning that without terminating the LSP do the BC 
operation. So I am going to leave it as is. Please let me know whether you 
agree with my assessment.

 
SD> Based on my answer to (2), I don’t think we need to do this change 
since LSR is not really doing BC.

 

SD> Corrected. Thanks.

SD> The OC and BC obviously apply to non-MPLS interface, but that is out 
of the scope of this document which 
Tries to document the 1588 over MPLS functionality.

Regards, 

Regards,
Microsemi Corporation
Peter Meyer

To

Subject

Hi, 

  
Regards, 

----------
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: "Shahram Davari" <[email-masked]>
Date: Thu, 22 Mar 2012 13:14:15 -0700

Hi Peter,

Thanks you for your comments. Please see my response inline.

-Shahram

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 22, 2012 9:17 AM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [TICTOC] Updated 1588 over MPLS draf-03

Hi Shahram,

1) In section 19 it lists the use case that I proposed to add as an architecture diagram in section 4.

"  - An LSR receives MPLS encapsulated PTP messages and terminates them,   while performing the OC or BC functionality"

From your e-mail you seem to indicate this is not a use case.  Or perhaps I have not understood your statement about "a real LSR doing BC, meaning that without terminating the LSP do the BC operation".  I am only familiar with a BC that terminates PTP packets.

SD> That is correct, and LSR (with respect to a PTP LSP) can’t perform OC or BC operation, since to perform OC or TC PTP LSP must be terminated and that means this is an LER and not LSR.  You are correct about section 19. I have deleted that bullet that you mentioned.

2) In section 7 there was previously in -02 the below statement that peer-delay messages must be transported over single hop PTP LSPs.

"SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock and MUST be transported over PTP LSPs.  PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks (i.e.  Master, Slave, Boundary, or Transparent) and MAY be transported over single hop PTP    LSPs.  If Two Step PTP clocks are present, then the FOLLOW_UP, DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages must also be transported over the PTP LSPs."

Now this statement is removed in -03, as well as references to two-step PTP clocks and associated FOLLOW_UP & PDELAY_RESP_FOLLOW_UP.

"SYNC and DELAY_REQ are exchanged between Master Clock and Slave Clock and MUST be transported over PTP LSPs.  PDELAY_REQ and PDELAY_RESP are exchanged between adjacent PTP clocks (i.e.  ordinary in Master or  Slave state, boundary, or transparent clock) and MAY be transported    over single hop PTP LSPs."

SD> The reason the 2-Step statement was removed was that FOLLOW_UP, DELAY_RESP, and PDELAY_RESP_FOLLOW_UP don’t need to be transported over PTP LSP since they are exchanged over one hop. However the draft does not prevent one from sending them over PTP LSP. May be I can add the following Text:

“If Two Step PTP clocks are present, then the FOLLOW_UP, DELAY_RESP, and PDELAY_RESP_FOLLOW_UP messages MAY  be transported over the PTP LSPs”

For p2p deployments, the exchange & termination of packets between two LSR is still required.  For the use case of p2p TC or p2p BC, each LSR must generate & terminate some of the PTP messages and process them locally.  These would be the PDELAY_REQ, PDELAY_RESP and PDELAY_RESP_FOLLOW_UP.  Not all PTP messages are sent through the LSR transparently in the case of p2p TC.

SD> No. The idea is to follow the standard MPLS data-plane. This means we can’t terminate packets in the middle of an LSP. So in the case that you mentioned, two different PTP LSPs are needed. One for carrying end-to-end messages (between Master and Slave) and one for carrying Peer-to-peer messages.

In such a case it would seem the LSR must be able to terminate a single hop PTP LSP, and this could be used for TC or BC implementation in the LSR.

SD> As mentioned above BC can only be done in LER, means you have to terminate the PTP LSP and then process the 1588 message.

Regards,

Microsemi Corporation
Peter Meyer

21/03/2012 02:29 PM

To

cc

Subject

Hi Peter,

Thanks
Shahram

Hi Shahram et al,

SD> Based on my answer to (2), I don’t think we need to do this change since LSR is not really doing BC.

SD> Corrected. Thanks.

Regards,

Regards,
Microsemi Corporation
Peter Meyer

12/03/2012 08:17 PM

To

cc

Subject

Hi,

Regards,

----------

---

From: [email-masked]
Date: Thu, 22 Mar 2012 17:27:56 -0400

Thanks Shahram.  I think I am closer to understanding, but I have some 
more questions, to help address my concerns. 

I have added some comments below, preceeded by PM.

Thanks,
Peter

22/03/2012 04:15 PM

To

Hi Peter,

-Shahram

Hi Shahram, 

 
SD> That is correct, and LSR (with respect to a PTP LSP) can’t perform OC 
or BC operation, since to perform OC or TC PTP LSP must be terminated and 
that means this is an LER and not LSR.  You are correct about section 19. 
I have deleted that bullet that you mentioned.

 
SD> The reason the 2-Step statement was removed was that FOLLOW_UP, 
DELAY_RESP, and PDELAY_RESP_FOLLOW_UP don’t need to be transported over 
PTP LSP since they are exchanged over one hop. However the draft does not 
prevent one from sending them over PTP LSP. May be I can add the following 
Text:
 
“If Two Step PTP clocks are present, then the FOLLOW_UP, DELAY_RESP, and 
PDELAY_RESP_FOLLOW_UP messages MAY  be transported over the PTP LSPs”
 
PM> There are two types of packets that are necessary to implement a p2p 
TC functionality, as you mention.   Both of these types of packets could 
be event packets, and both of these types of packets are critical to 
enable the TC functionality.  Some of these packets flow through the TC 
network element, for which the draft establishes a special PTP LSP.   Some 
of these packets are generated & terminated at every TC network element 
(e.g. peer-delay) for which there is no recommendation in the draft, but 
there are a couple options.

Option 1:  These packets are not carried over MPLS, but over another 
mapping (such as proposed in draft-jobert-tictoc-ptp-link-local-00).  It 
is not intended in this draft to specify this mechanism, even though these 
packets are required for the TC to operate, and are time sensitive event 
packets that need to be indentified easily by the ingress & egress port 
aswell.  Since these packets are generated & terminated in the TC, but are 
not carried over an LSP, this portion of the TC functionality does not 
require the node to be considered an LER.

Option 2:  These packets are carried over a second PTP LSP (single hop). 
Would this second PTP LSP be the same type of special PTP LSP that 
requires the additional control aspects being proposed in this draft, in 
order to have a label setup to identify the event/timestamping needs of 
the packet?  As the TC would terminate this second PTP LSP, would it not 
be considered to be acting as an LER?  (I am not clear if generating & 
terminating a single hop PTP LSP qualifies the equipment as an LER, since 
this is not my area of expertise).

SD> No. The idea is to follow the standard MPLS data-plane. This means we 
can’t terminate packets in the middle of an LSP. So in the case that you 
mentioned, two different PTP LSPs are needed. One for carrying end-to-end 
messages (between Master and Slave) and one for carrying Peer-to-peer 
messages.

SD> As mentioned above BC can only be done in LER, means you have to 
terminate the PTP LSP and then process the 1588 message.

PM> Refering back to the previous two options I have introduced, depending 
on which was intended to be propsed in the draft for non-flow through 
packets, it would seem there may be ways to address my concerns about the 
exclusion of BC functionality.

Option 1:  Using another mapping to carry PTP messages between network 
elements could apply to all BC messages (see 
draft-jobert-tictoc-ptp-link-local-00).    This BC is embedded within a 
network element that is acting as an LSR, but the PTP itself is never 
carried over MPLS.  This could be mentioned in the section 4 architecture, 
allowing the reader to more clearly understand that both BC capability and 
TC capability could exist within a network element acting as an LSR.  At 
present it seems that a network element acting as an LSR could only 
support TC functionality, which is not the case.

Option 2:  The second PTP LSP (single hop) could also be used to carry all 
necessary BC messages.  This would be, I thought, what was proposed in 
section 19. This could also be shown in section 4 architecture.

Regards,
Peter

To

Hi Peter, 

Thanks 
Shahram 

Hi Shahram et al, 

  

  

  

SD> Corrected. Thanks. 

Regards, 
Peter

To

Subject

Hi, 

 
Regards, 

----------