Subject: Re: [mpls-tp] [PWE3] 1588 over MPLS draft

From: Greg Mirsky <[email-masked]>
Date: Tue, 13 Jul 2010 12:31:18 -0700

Dear Shahram, Authors and All,
below please find my notes:
- Abstract, first paragraph - extra "to enable"
- I believe that goal to transport PTP over MPLS PSN stated in
Abstract contradicts with declared in Introduction requirement to
perform TC function on LSR(s). Transport, in my view, assumes
transparency for payload, PTP in case.
- Providing or using TC capability by transient MPLS nodes might be
supported by ability to advertise such capability (or afinity). Then
LSP can be set suing this capability as a constrain.
- As mentioned by others, nodes that don't support TC should not be
affected and perform as LSR. (Not sure if non-TC capable node will be
considered for LER).

Regards,
Greg

On Wed, Jul 7, 2010 at 12:12 PM, Shahram Davari <[email-masked]> wrote:
> 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
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: Jia HE <[email-masked]>
Date: Wed, 14 Jul 2010 12:50:37 +0800

Hi Shahram,

One question about "PTP Label Range":

To my knowledge, label in MPLS network is a local matter. For example, we may have per-interface or per-platform label space. Will this specificed "PTP Label Range" conflict with the current in-use labels for common LSPs? 

B.R.
Jia

  ----- Original Message ----- 
  From: Shahram Davari 
  To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Thursday, July 08, 2010 3:12 AM
  Subject: [PWE3] 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: Mach Chen <[email-masked]>
Date: Wed, 14 Jul 2010 16:53:11 +0800

Hi Shahram,

>From the view of implementation, there is no more difference between SHOULD 
and MUST :-)
For me, the Label Range is more like a mechanim to notify related nodes that 
some LSPs are dedicated for PTP messages other than the chips memory 
limitation, because the memory restriction is always there whatever you use 
Label Range or not.
IMHO, since the objective is to tell related MPLS nodes which LSPs are PTP 
LSPs, an indication in the signaling(RSVP-TE/GMPLS/LDP) is enough and seems 
more common. And it will avoid the strict requirement of "the network and 
all nodes required to support the Label range".
In addition, there should be some mechanims(e.g., ISIS/OSPF extensions) for 
nodes to advertise their PTP capability hence to help PTP LSPs computation.

Best regards,
Mach

--------------------------------------------------
From: "S. Davari" <[email-masked]>
Sent: Wednesday, July 14, 2010 2:31 PM
To: "Jia HE" <[email-masked]>; "Shahram Davari" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

> Hi Jia,
>
> Label range is a SHOULD requirements and not MUST. The reason for Label 
> Range is
> mainly for PHY chips that don't have large memory and can't store a lot of
> Labels. Otherwise the PTP LSP is setup via signaling that specifies the 
> LSP as
> carrying 1588.
>
> So the answer is that if a Label range is used it must be a Global range 
> within
> a network and should not be used by any router for other applications.
>
> Thanks,
> Shahram
>
>
>
> ________________________________
> From: Jia HE <[email-masked]>
> To: Shahram Davari <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Sent: Tue, July 13, 2010 9:50:37 PM
> Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
>
>
> Hi Shahram,
>
> To my knowledge, label in MPLS network is a local  matter. For example, we 
> may
> have per-interface or per-platform label space. Will  this specificed "PTP 
> Label
> Range" conflict with the current in-use labels  for common LSPs?
>
>
> B.R.
> Jia
>
> ________________________________

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

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Jul 2010 12:23:51 +0100

On 14/07/2010 09:53, Mach Chen wrote:
> Hi Shahram,
>
> For me, the Label Range is more like a mechanim to notify related 
> nodes that some LSPs are dedicated for PTP messages
Yes
> IMHO, since the objective is to tell related MPLS nodes which LSPs are 
> PTP LSPs, an indication in the signaling(RSVP-TE/GMPLS/LDP) is enough 
> and seems more common. And it will avoid the strict requirement of 
> "the network and all nodes required to support the Label range".
> In addition, there should be some mechanims(e.g., ISIS/OSPF 
> extensions) for nodes to advertise their PTP capability hence to help 
> PTP LSPs computation.
>
Yes.

I would anticipate that the path would be set up using RSVP-TE since 
this is a better match to the needs of a timing path. However you could 
do it with a separate instance of the IGP and then use LDP, so we should 
not exclude that case.

Stewart

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 13:04:29 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
>  
> 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 nex=
> t 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

IMO Attaching a word doc and asking for a slot at the meeting is
unacceptable.  At least convert the document to text or don't bother
and submit the draft after the meeting.  In any case, the cutoffs are
there for a reason and this should be given low priority at the
meeting (presented if there is time left over).

Curtis

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 14 Jul 2010 10:58:52 -0700

Hi Mach,

When a service provider wants to create these PTP LSPs, what is wrong with allocating a range of labels for this purpose? This is purely a software exercise. There are 2 million labels available to each node, why can't some of them be allocated by software to PTP?

In theory what you say is correct and should work, but in practice there is a function called 1-step Transparent clocking that requires time stamping at the PHY (immediately when the packet is received or transmitted). PHY chips don't have CAM or lots of memory to store a few thousand random labels. The label range will solve that problem and is consistent with MPLS architecture.

Thanks,
Shahram

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 1:53 AM
To: S. Davari; Jia HE; Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

Hi Shahram,

Best regards,
Mach

---

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

Hi Cutris,

Are you saying you can't read the word doc? Could you do me a favor and tell me how to convert it to txt. I have been working on it without success. I am trying now to write it in XML (which I am learning now).

Also note that the main thing is the idea and not what format the document is. 

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 10:04 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] 1588 over MPLS draft

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 18:10:24 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
> Hi Cutris,
>  
> Are you saying you can't read the word doc?  Could you do me a favor
> and tell me how to convert it to txt. I have been working on it
> without success. I am trying now to write it in XML (which I am
> learning now).

Converting to XML is the best approach.

Reading word is somewhat inconventient but doable since I have to move
the file to another machine that runs openoffice.  I wouldn't run an
insecure app like that (or worse yet an insecure OS with an even less
secure app) on any machine I actually cared about.  :-)

The XML is quite easy once you've done it the first time.

I'll wait for you to convert to XML and I'll deal with what you sent.

> Also note that the main thing is the idea and not what format the

Yes, but some document formats are simply unacceptable and word is one
of them.  Not too fond of powerpoint either.

Thanks,

Curtis

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 Jul 2010 10:19:09 +0800

Hi Shahram,

I agree that the label range idea is an efficient way that could reduce the 
storage requirement of PHY chips.

It's easy to require one or limited nodes to reserve a label range, but 
IMHO, it very difficut to require all nodes of a large network to do this 
and even worse when some labels are already used by other LSPs, unless there 
are some mechanisms to negotiate/advertise(e.g., flooding the label range by 
IGP within the network) the proper label range hence to aviod label 
collision.

Best regards,
Mach

--------------------------------------------------
From: "Shahram Davari" <[email-masked]>
Sent: Thursday, July 15, 2010 1:58 AM
To: "Mach Chen" <[email-masked]>; "S. Davari" <[email-masked]>; "Jia 
HE" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: RE: [mpls] [PWE3] 1588 over MPLS draft

> Hi Mach,
>
> When a service provider wants to create these PTP LSPs, what is wrong with 
> allocating a range of labels for this purpose? This is purely a software 
> exercise. There are 2 million labels available to each node, why can't 
> some of them be allocated by software to PTP?
>
> In theory what you say is correct and should work, but in practice there 
> is a function called 1-step Transparent clocking that requires time 
> stamping at the PHY (immediately when the packet is received or 
> transmitted). PHY chips don't have CAM or lots of memory to store a few 
> thousand random labels. The label range will solve that problem and is 
> consistent with MPLS architecture.
>
> Thanks,
> Shahram
>
>>>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

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 Jul 2010 11:56:16 +0800

Hi Joel,

Please see inline...
--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Thursday, July 15, 2010 11:20 AM
To: "Mach Chen" <[email-masked]>
Cc: "Shahram Davari" <[email-masked]>; "S. Davari" 
<[email-masked]>; "Jia HE" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

> Remember that if what is required is that the message arriving at the 1588 
> supporting device have a certain label range, that is a purely local 
> matter.  As long as the singaling carries the indication that the LSP is 
> to be dedicated to 1588 traffic (a reasonable extension to the signaling), 
> the downstream switch can pick what label to assign to that LSP.

Agree, that is my original suggestion.

Best regards,
Mach

>
> If the goal is to have the outgoing label be from a specific range, that 
> is essentially impossible in the proposed architecture.  The proposed 
> architecture is one in which 1588 switches are peers with existing LSRs 
> using MPLS.  As such, in order to have a label range for outgoing labels, 
> the existing MPLS LSR would somehow have to know about this reserved label 
> range, not use those labels for other purposes, and assign those labels to 
> 1588 LSPs.  All of which is non-backwards-compatible.  If the 1588 LSPs 
> were actually pseudowires, tunneled over LSPs, then any number of things 
> are possible.
>
> Yours,
> Joel M. Halpern
>
> Mach Chen wrote:
>> Hi Shahram,
>>
>> I agree that the label range idea is an efficient way that could reduce 
>> the storage requirement of PHY chips.
>>
>> and even worse when some labels are already used by other LSPs, unless 
>> there are some mechanisms to negotiate/advertise(e.g., flooding the label 
>> range by IGP within the network) the proper label range hence to aviod 
>> label collision.
>>
>> Best regards,
>> Mach
>>
>>> When a service provider wants to create these PTP LSPs, what is wrong 
>>> with allocating a range of labels for this purpose? This is purely a 
>>> software exercise. There are 2 million labels available to each node, 
>>> why can't some of them be allocated by software to PTP?
>>>
>>> PTP
>>>>> Please find attached our first draft of 1588 over MPLS.    Since we 
>>>>> have
>>>>> some
>>>>> Note that the main WG is TicToc but may require    consultation with 
>>>>> MPLS
>>>>> and
>>>>> PWE3 WGs.
>>>>>
>>>>> Thanks,
>>>>> Shahram Davari

---

From: Jia HE <[email-masked]>
Date: Thu, 15 Jul 2010 16:15:17 +0800

Hi Shahram,

Thanks for your response. But still more for clarification:

So the specified PTP Label Range is for the PHY to easily recognize and get to process PTP information that is carried on LSPs or PWs. This is efficient when we define and make known such a Label range globally at the beginning of setting up a network. What if we want to set up such PTP LSPs using a global label range when there are already LSPs in use in the network? It might be difficult to get a global label range in this case considering the possible label collision. Or in this case we depend on signaling but may cause burden for PHY chips. If I'm right, it seems a compromise between the two. Is that true?

Thanks!

B.R.
Jia

  ----- Original Message ----- 
  From: S. Davari 
  To: Jia HE ; Shahram Davari 
  Cc: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Wednesday, July 14, 2010 2:31 PM
  Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

  Hi Jia,

  Label range is a SHOULD requirements and not MUST. The reason for Label Range is mainly for PHY chips that don't have large memory and can't store a lot of Labels. Otherwise the PTP LSP is setup via signaling that specifies the LSP as carrying 1588.

  So the answer is that if a Label range is used it must be a Global range within a network and should not be used by any router for other applications.

  Thanks,
  Shahram

  Hi Shahram,

  B.R.
  Jia

    ----- Original Message ----- 
    From: Shahram Davari 
    To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
    Sent: Thursday, July 08, 2010 3:12 AM
    Subject: [PWE3] 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.

    Thanks,

    Shahram Davari

----------------------------------------------------------------------------

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 15 Jul 2010 10:41:25 -0700

Hi Mach,

Your suggestion is valid. This could also be done without any global label range. A local label range between two nodes will also work.

Thx
Shahram

-----Original Message-----
From: Mach Chen [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 7:19 PM
To: Shahram Davari; S. Davari; Jia HE
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

Hi Shahram,

Best regards,
Mach

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 15 Jul 2010 10:46:22 -0700

Hi Joel,

I agree with your logic, but the idea is a bit different:

All we need is a label range, it does not need to be globally unique in the network and it does not even need to be the same on the Tx and Rx direction of the same link. Although we need time stamping both on Rx and on Tx, but on Rx a node is in control of its own label and on Tx the downstream node should advertise some label range. What we don't want is that the downstream node to advertise random labels for each LSP carrying PTP.

I will update the draft to mention that the label range does not require to be global but it can be per-platform or even per-interface.

Thanks,
Shahram

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 8:21 PM
To: Mach Chen
Cc: Shahram Davari; S. Davari; Jia HE; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

Remember that if what is required is that the message arriving at the 
1588 supporting device have a certain label range, that is a purely 
local matter.  As long as the singaling carries the indication that the 
LSP is to be dedicated to 1588 traffic (a reasonable extension to the 
signaling), the downstream switch can pick what label to assign to that LSP.

If the goal is to have the outgoing label be from a specific range, that 
is essentially impossible in the proposed architecture.  The proposed 
architecture is one in which 1588 switches are peers with existing LSRs 
using MPLS.  As such, in order to have a label range for outgoing 
labels, the existing MPLS LSR would somehow have to know about this 
reserved label range, not use those labels for other purposes, and 
assign those labels to 1588 LSPs.  All of which is 
non-backwards-compatible.  If the 1588 LSPs were actually pseudowires, 
tunneled over LSPs, then any number of things are possible.

Yours,
Joel M. Halpern

Mach Chen wrote:
> IMHO, it very difficut to require all nodes of a large network to do 
> this and even worse when some labels are already used by other LSPs, 
> unless there are some mechanisms to negotiate/advertise(e.g., flooding 
> the label range by IGP within the network) the proper label range hence 
> to aviod label collision.
> 
> Best regards,
> Mach
> 
> To: "Mach Chen" <[email-masked]>; "S. Davari" <[email-masked]>; 
> "Jia HE" <[email-masked]>
>> In theory what you say is correct and should work, but in practice 
>> there is a function called 1-step Transparent clocking that requires 
>> time stamping at the PHY (immediately when the packet is received or 
>> transmitted). PHY chips don't have CAM or lots of memory to store a 
>> few thousand random labels. The label range will solve that problem 
>> and is consistent with MPLS architecture.
>>
>> Thanks,
>> Shahram
>>
>> nodes that
>> extensions) for
>>>> draft before the cut-off date. However we will    present the draft 
>>>> in the
>>>> next

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 15 Jul 2010 12:52:19 -0700

Hi Joel,

There are 2 aspects to this puzzle:

1) Hardware support for 1588 in a device. 
2) Software support for 1588 in the form of allocating labels to PTP LSPs

A router that wants to perform 1588 time stamping must have both (1) and (2) functionality. While a router in the path of a PTP LSP that does not support (1) should support (2) and advertise labels from some arbitrary range for PTP LSP. 

It is quite easy to upgrade a router software so that when it receives RSVP-TE label request to assign label from an arbitrary local range. 

So I don't see any issue here.

Thanks,
Shahram

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 12:06 PM
To: Shahram Davari
Cc: Mach Chen; S. Davari; Jia HE; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

Architecturally, as I understand the draft, the downstream neighbor of a 
1588 supporting device (on the PTP carrying LSP) may not itself be a 
1588 supporting device.  Is that correct?  If that is not correct, if 
instead the structure is that PTP supporting LSPs are established 
between adjacent enhanced devices, then I can see how some sort of a 
label range might make sense.

If however, the downstream node you refer to may be an existing LSR, 
then I do not see how you can ask an existing LSR to allocate a label 
range for a function it does not understand.

Yours,
Joel

Shahram Davari wrote:
> All we need is a label range, it does not need to be globally unique in the network and it does
 >not even need to be the same on the Tx and Rx direction of the same 
link. Although we need time
 >stamping both on Rx and on Tx, but on Rx a node is in control of its 
own label and on Tx the
 >downstream node should advertise some label range. What we don't want 
is that the downstream
 >node to advertise random labels for each LSP carrying PTP.
>

---

From: John E Drake <[email-masked]>
Date: Thu, 15 Jul 2010 13:26:52 -0700

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shahram Davari
> Sent: Thursday, July 15, 2010 12:52 PM
> To: Joel M. Halpern
> Cc: [email-masked]; [email-masked]; S. Davari; [email-masked]; mpls-
> [email-masked]
> Subject: Re: [mpls-tp] [mpls] [PWE3] 1588 over MPLS draft
> 
> Hi Joel,
> 
> A router that wants to perform 1588 time stamping must have both (1)
> and (2) functionality. While a router in the path of a PTP LSP that
> does not support (1) should support (2) and advertise labels from some
> arbitrary range for PTP LSP.
> 
> It is quite easy to upgrade a router software so that when it receives
> RSVP-TE label request to assign label from an arbitrary local range.

JD:  What happens in the case where a router's software has not been upgraded?

> > I will update the draft to mention that the label range does not
> require to be global but it can
>  >be per-platform or even per-interface.
> >
> > Thanks,
> > Shahram
> >
> >>> From the view of implementation, there is no more difference
> between
> >>> SHOULD
> >>> and MUST :-)
> >>> LSPs, an indication in the signaling(RSVP-TE/GMPLS/LDP) is enough
> and
> >>> seems
> >>>> mainly for PHY chips that don't have large memory and can't store
> a
> >>>> lot of
> >>>> have per-interface or per-platform label space. Will  this
> specificed
> >>>> "PTP
> >>>> Label
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

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

Hi Joel,

OK, do you have a better proposal?

Thx
Shahram

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 1:32 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

I am sorry, but requiring every LSR in the infrastructure to get a 
software upgrade in order to allow for the presence of 1588-supporting 
devices is a MAJOR issue.  It is NOT backwards compatible.  Operators 
(wether service provider or enterprise IT) do NOT like being told they 
ahve to upgrade the software on all devices in their network in order to 
add a capability that those devices are not engaging in.

While one can argue about the "ease" of the specific software change, 
there is from an operational perspective no such thing as an easy 
upgrade of any device, and there is definitely no such thing as an easy 
upgrade of all the devices in the network.

Yours,
Joel

Shahram Davari wrote:
> A router that wants to perform 1588 time stamping must have both (1) and (2) functionality. While a router in 
 >the path of a PTP LSP that does not support (1) should support (2) and 
advertise labels from some arbitrary
 >range for PTP LSP.

---

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

By the way there is no need to upgrade the software for all routers in the network, just the routers directly adjacent to a PTP-aware router.

Thx
Shahram

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, July 15, 2010 1:32 PM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

Yours,
Joel

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 15 Jul 2010 22:14:31 +0100

Sharam,

I am not sure there is a requirement for all devices to be upgraded. My thinking is as follows:

We have 3 types of 1588 MPLS devices:
1) Those that do not support 1588
2) Those that can terminate 1588 but do not support boundary clock
3) Those that can terminate 1588 and do support boundary clock.

For the purpose of this discussion (2) & (3) can probably be lumped together.

The requirement (to avoid more complex hardware processing) is that 1588 packets arrive at device types (2) & (3) with a label out of a "1588 label range". A label from the 1588 label range has no special meaning with respect to forwarding behaviour it simply carries an extra semantic that indicates that the packet is a 1588 packet, such a semantic is only required if the LSP is terminating on device types (2) & (3) or transiting device type (3).

Therefore the 1588 LSP does not need to use a label from a 1588 specific label range at every hop in the path, it only needs such a label as the incoming label to device types (2) & (3).

If labels are downstream assigned then the downstream device provides the label mapping for the incoming label for itself and so device types (2) & (3) can assign labels out of their 1588 label range, there is no requirement for the upstream device to realise such a label has an additional semantic and therefore there is no need to upgrade devices except those directly participating in the 1588 session (either as terminating devices or as boundary devices).

If labels are upstream assigned then the upstream device will need to assign a label from the 1588 label range and so the upstream device, even if it is of type (1), needs to realise it has to assign a label with 1588 semantics. The upstream (as well as downstream) device will require upgrading although context labels may provide some level of support already (I would have to think more about the applicability of context labels to this problem space).

The key thing to remember is that the semantic that the LSP is a 1588 LSP needs to be carried End to End when signalling the LSP but does not need to exist within the forwarding machinery for each device in the path unless that device is participating in the 1588 session in some way (including upstream allocation of 1588 labels).

Ben

---

From: Mach Chen <[email-masked]>
Date: Fri, 16 Jul 2010 09:35:43 +0800

Hi Shahram,

If the 1588-capability router does downstream (for Rx direction) and 
upstream (for Tx direction) label distribution respectively, it may not 
require its adjacent routers to upgrade.

Best regards,
Mach

--------------------------------------------------
From: "Shahram Davari" <[email-masked]>
Sent: Friday, July 16, 2010 4:37 AM
To: "Joel M. Halpern" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

>>> I will update the draft to mention that the label range does not require 
>>> to be global but it can

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 16 Jul 2010 16:48:51 -0700

Hi,

Please find the txt format of 1588 over mpls draft. There has been some discussion over the mailing list. I will update it based on the consensus.

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 10:04 AM
To: Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] 1588 over MPLS draft

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 10:43:30 -0400

In message <[email-masked]>
"Shahram Davari" writes:
>  
>  
> Hi,
>  
> Please find the txt format of 1588 over mpls draft. There has been some dis=
> cussion over the mailing list. I will update it based on the consensus.
>  
> Thanks,
> Shahram

Shahram,

Thanks for converting to XML and producing a text version.  BTW - you
should call this one 00-preview since it has yet to be accepted by RFC
editor programs and may change slightly due to nits - unless of
course, you got it past the nits.

Some general comments.

Why IEEE-1588 and not NTP as the basis of the clock sync.  They are
very similar, except that NTP does a better job of compensating for
any jitter.  A modification to NTP as payload would yield better
accuracy.  NTP format may have to be modified to make it more hardware
parsible and easier for the low order bits of the time stamp to be
added by the forwarding hardware.

In most cases the precision of even the CF is going to depend on how
much effort has been put into compensating for the outgoing packet.

Ideally the exact time when the start of the currently transmitted
packet could be saved and with that and the byte count of all of the
packets currently in the queue ahead of the IEEE-1588 or NTP packet
would yield precision to roughly a bit time.  In practice though I
doubt that most IEEE-1588 capable hardware can attain this accuracy
and may be accurate only to within one packet time (no way to
determine which byte of the packet is currently being sent and no
saved timestamp on the first byte send time).

A lot of hardware can only provide a count of what is in the queue and
the timestamp.  If the CF is applied by SW without locking the queue
(somehow), then packets can sneak in between the time of reading the
queue occupancy, applying the time stamp, and queueing the PTP PDU.
That would yield worse than one packet time uncertainty on the time
stamping process.

On the receive side, accuracy can be acheived if the hardware saves a
timestamp with the first (or last) bit arrival or at some
deterministic time after first bit arrival (for example, in some NP
handoff to a ME may occur within a narrow window of time relative to
first bit arrival).  If a timestamp is saved by hardware it throws it
out in most cases.  If this is not done by the receive side hardware,
furthern inaccuracy is introduced.

Given that precision is likely to be within one packet time or worse,
the compensation in NTP will yield a better result than the lack of
compensation in IEEE-1588.  Of course that was the "complicated thing"
in NTP that IEEE-1588 was trying to avoid, but it does work well.

Could you remind me how it is signaled on the LSP whether a PW is
underneath, and if so, whether CW is used.  Or are we assuming that if
PW is being used only the PW PE or MS-PW *-PE modify CF?  Of course
with adjacent LSR, there are no mid hops.  Is the offset that is
signaled intended to avoid encapsulation checks?

btw- This seems like requirements only since no signaling is
specified, just the need for signaling in section 12.

Second, it would be best to provide a subsection which enumerates all
of the places that forwarding has to look when processing such an
LSP.  For example:

    1.  Check the LSP range.  If not just forward.

    2.  Check for no BOS and GAL (13) or OAM (14) beneath the label.
	If so just forward.

    3.  If PW and CW is being used:

	  a.  Check for no BOS, then BOS (PW) and CW indicating OAM
	      beneath the label.  If so just forward.

	  b.  Check for no BOS, then BOS (PW) and if so modify CF and
	      forward.

	  c.  Else if BOS (no PW, or GAL) then error.  (?)

	Else

	  a.  Check for BOS.  If so then modify CF and forward.

	  b.  Else (more labels, unexpected) error.  (?)

  Note: modify CF means find IPv4 or IPv6, then UDP then PTP.  Then
  modify any checksums and FCS.

If this is wrong, then I missed something.  Note that this is quite a
bit more than the usual look at label, then forward.

Also, not having looked at IEEE-1588 in quite a while, doesn't just
the sending and recieving node modify CF at around the point of
forwarding?  Please correct me if I'm wrong on that and I'll relook.

Note that neither NTP or IEEE-1588 is highly accurate if there are any
forwarding nodes between the two nodes that are synchronizing clocks.
In that case NTP is considerably less inaccurate.  If the two are
adjacent and the time stamping hardware is in place, in theory,
stamping precision could be to within a bit time, and with
compensation of NTP clock precision could be to within well under a
bit time.

Maybe this sort of comment about expected accuracy would be helpful.

Nits: you have a reference to 1EEE1588 and a reference to [1].  These
seem to be leftovers from the ms-word version.

For completeness it probably wouldn't hurt to specify what the CF
modification is (which bits and what to put in them) without repeating
all of IEEE-1588.  This would be a standalone full specification of
what the hardware needs to do if software then takes over and does the
clock adjustment.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 12:51:19 -0400

A section on backwards compatibility with non-compliant LSR would be
helpful.  It might be as simple as a bit of RSVP-TE signaling that
indicates capability and actions to take when a non-compliant LSR is
found in a path.  Normally IEEE-1588 (or very high precision NTP)
would be with adjacent LSR so non-compliance would mean no peering
would be attempted.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 13:29:19 -0400

LSR today can already run NTP using TC bits set at the priority of
control plane traffic (for CS service that is CS6 - CS7 could be used
for slightly better accuracy), Some may soon have hardware support in
addition to the prioritization (for more than just IEEE-1588).
Providers already run NTP, often among adjacent LSR to get good clock
precision, if for no other reason to be able to correlate logs (or
traps, etc) among devices.

NTP is only inaccurate if you try to peer with some random NTP server
that is far far away.  Among adjacent peers it can be quite accurate
even without hardware support and should be highly accurate with
hardware support.

So it doesn't make much sense to even consider devices that don't
support IEEE-1588 boundary clock.  The goal of this work should be to
*improve* the available accuracy of the clock in LSR.  We should not
use IEEE-1588 over MPLS solely for the sake of the Ethernet religious
even if it makes the clock accuracy worse.

We are talking about more than software change here.  This requires
hardware change.  If we are going to require hardware change we should
specify something which provides the best outcome possible.  That may
be NTP and not IEEE-1588.  For Ethernet devices outside of the LSR
domain that do not support NTP (and may not even support IP or MPLS),
IEEE-1588 can be used.

Curtis

In message <[email-masked]>

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 20 Jul 2010 14:07:13 -0400

Is there really an issue at all?  If an LSR is tictoc capable, it
provides the upstream with a label in that range.  That is the way
RSVP-TE works.  At forwarding time that is the label that will be used
at that hop.  If an LSR is not tictoc capable, then it provides any
label it choses and it sees that label but it wouldn't have done
anything different no matter what label it picked.

It is still highly questionable whether there is any utility in
running over a LSP with a midpoint LSR in the path.  For high clock
accuracy, either NTP or IEEE-1588 have to be run among adjacent LSR
only.

BTW- If one hop IP is available for the control plane, the use of NTP
over IP is a good practical choice and I would be very surprised if it
were not the most common choice today among LSR.

It might be easier for the tictoc group to simply specify that the NTP
timestamping should be supported in hardware.

Curtis

In message <[email-masked]>
"Shahram Davari" writes:

Hi Joel,

Thanks,
Shahram

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2010 8:21 PM
To: Mach Chen
Cc: Shahram Davari; S. Davari; Jia HE; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft

Yours,
Joel M. Halpern