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

From: [email-masked]
Date: Fri, 16 Jul 2010 11:22:19 +0800

Hi Sharam,
The label should not be per-platform or per-interface, but more general 
concept, context specific label space, see RFC5331 for detail.

BR
Lizhong
 
> ------------------------------
> 
> Message: 3
> Date: Thu, 15 Jul 2010 10:46:22 -0700
> From: "Shahram Davari" <[email-masked]>
> Subject: Re: [PWE3] [mpls]  1588 over MPLS draft
> To: "Joel M. Halpern" <[email-masked]>,   "Mach Chen"
>    <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]"
>    <[email-masked]>,   "[email-masked]" <[email-masked]>,
>    "[email-masked]" <[email-masked]>,   "S. Davari" <[email-masked]>
> Message-ID:
>    <[email-masked].
> broadcom.com>
> 
> Content-Type: text/plain; charset=utf-8
> 
> 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:
> > 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
> >>
> >> -----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,
> >>
> >> 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,
> >>>
> >>> 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
> >>> ________________________________
> >>> _______________________________________________
> >>>> pwe3 mailing    list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/pwe3
> >>>>
> >>>
> >>>
> >>
> >>

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 15 Jul 2010 20:51:51 -0700 (PDT)

Mach

Is this supported by RSVP-TE?

Best Regards,
Shahram

On Jul 15, 2010, at 6:35 PM, Mach Chen <[email-masked]> wrote:

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

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:
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:
Hi Joel,

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

signaling), the downstream switch can pick what label to assign to that LSP.

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.

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

Hi Mach,

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,

IMHO, since the objective is to tell related MPLS nodes which LSPs are
more common. And it will avoid the strict requirement of "the network and

Best regards,
Mach

To: "Jia HE" <[email-masked]>; "Shahram Davari" <[email-masked]>

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,

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

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

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

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

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 20 Jul 2010 11:17:06 -0700

Correct there is no issue and each LSR is in control of its labels

THX
SD

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Shahram Davari
Cc: Joel M. Halpern <[email-masked]>; Mach Chen <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; S. Davari <[email-masked]>
Sent: Tue Jul 20 11:07:13 2010
Subject: Re: [PWE3] [mpls] 1588 over MPLS draft

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,

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

Yours,
Joel M. Halpern

Mach Chen wrote:
>>>> technical issues converting the Word format to Txt we    couldnâ€™t 
>>>> upload
>>>> the