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

[Mach Chen <[e-mail]>]

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" <[e-mail]>
Sent: Friday, July 16, 2010 4:37 AM
To: "Joel M. Halpern" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
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:[e-mail]]
> Sent: Thursday, July 15, 2010 1:32 PM
> To: Shahram Davari
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
>> Sent: Thursday, July 15, 2010 12:06 PM
>> To: Shahram Davari
>> Cc: Mach Chen; S. Davari; Jia HE; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]
>> 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,
>>>
>>> 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:[e-mail]]
>>> Sent: Wednesday, July 14, 2010 8:21 PM
>>> To: Mach Chen
>>> Cc: Shahram Davari; S. Davari; Jia HE; [e-mail]; [e-mail]; 
>>> [e-mail]; [e-mail]
>>> 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" <[e-mail]>
>>>> Sent: Thursday, July 15, 2010 1:58 AM
>>>> To: "Mach Chen" <[e-mail]>; "S. Davari" <[e-mail]>;
>>>> "Jia HE" <[e-mail]>
>>>> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
>>>> <[e-mail]>
>>>> 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:[e-mail]]
>>>>> Sent: Wednesday, July 14, 2010 1:53 AM
>>>>> To: S. Davari; Jia HE; Shahram Davari
>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>>>> 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" <[e-mail]>
>>>>> Sent: Wednesday, July 14, 2010 2:31 PM
>>>>> To: "Jia HE" <[e-mail]>; "Shahram Davari" 
>>>>> <[e-mail]>
>>>>> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
>>>>> <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>>> To: Shahram Davari <[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>>>>> 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: [e-mail] ; [e-mail] ; [e-mail] ; 
>>>>>>> [e-mail]
>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>>>>
>>>>>
>>>>>> _______________________________________________
>>>>>> mpls mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> mpls mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>