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

[Mach Chen <[e-mail]>]

Hi Joel,

Please see inline...
--------------------------------------------------
From: "Joel M. Halpern" <[e-mail]>
Sent: Thursday, July 15, 2010 11:20 AM
To: "Mach Chen" <[e-mail]>
Cc: "Shahram Davari" <[e-mail]>; "S. Davari" 
<[e-mail]>; "Jia HE" <[e-mail]>; <[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.

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.
>>
>> 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