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

"Shahram Davari" <davari@broadcom.com> Thu, 15 July 2010 17:46 UTC

Return-Path: <davari@broadcom.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F22AE3A6A70; Thu, 15 Jul 2010 10:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level:
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uufgzw01TDxY; Thu, 15 Jul 2010 10:46:27 -0700 (PDT)
Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 5CBC83A6AB4; Thu, 15 Jul 2010 10:46:26 -0700 (PDT)
Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 15 Jul 2010 10:46:24 -0700
X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031
Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 15 Jul 2010 10:46:24 -0700
From: Shahram Davari <davari@broadcom.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Mach Chen <mach@huawei.com>
Date: Thu, 15 Jul 2010 10:46:22 -0700
Thread-Topic: [mpls] [PWE3] 1588 over MPLS draft
Thread-Index: AcsjzL+tuZ17f0tmSyC7yLZ0piwa1wAeDfPg
Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6940EC290F5@SJEXCHCCR02.corp.ad.broadcom.com>
References: <2C2F1EBA8050E74EA81502D5740B4BD6940EC28967@SJEXCHCCR02.corp.ad.broadcom.com> <04ae01cb2310$1a6b2730$9d4d460a@china.huawei.com> <89571.47481.qm@web88402.mail.re1.yahoo.com> <F8A42E669722437AB6CD24CFD4586300@m55527c> <2C2F1EBA8050E74EA81502D5740B4BD6940EC28FAD@SJEXCHCCR02.corp.ad.broadcom.com> <6862C24AB1F4468D8F3265AE705925C6@m55527c> <4C3E7E83.9080603@joelhalpern.com>
In-Reply-To: <4C3E7E83.9080603@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 602196FA10031891565-01-01
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Cc: "mpls@ietf.org" <mpls@ietf.org>, "ticctoc@ietf.org" <ticctoc@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [mpls] [PWE3] 1588 over MPLS draft
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2010 17:46:29 -0000

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:jmh@joelhalpern.com] 
Sent: Wednesday, July 14, 2010 8:21 PM
To: Mach Chen
Cc: Shahram Davari; S. Davari; Jia HE; mpls@ietf.org; pwe3@ietf.org; ticctoc@ietf.org; mpls-tp@ietf.org
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" <davari@broadcom.com>
> Sent: Thursday, July 15, 2010 1:58 AM
> To: "Mach Chen" <mach@huawei.com>; "S. Davari" <davarish@yahoo.com>; 
> "Jia HE" <hejia@huawei.com>
> Cc: <mpls@ietf.org>; <pwe3@ietf.org>; <ticctoc@ietf.org>; 
> <mpls-tp@ietf.org>
> 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:mach@huawei.com]
>> Sent: Wednesday, July 14, 2010 1:53 AM
>> To: S. Davari; Jia HE; Shahram Davari
>> Cc: mpls@ietf.org; pwe3@ietf.org; ticctoc@ietf.org; mpls-tp@ietf.org
>> 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" <davarish@yahoo.com>
>> Sent: Wednesday, July 14, 2010 2:31 PM
>> To: "Jia HE" <hejia@huawei.com>; "Shahram Davari" <davari@broadcom.com>
>> Cc: <mpls@ietf.org>; <pwe3@ietf.org>; <ticctoc@ietf.org>; 
>> <mpls-tp@ietf.org>
>> 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 <hejia@huawei.com>
>>> To: Shahram Davari <davari@broadcom.com>
>>> Cc: mpls@ietf.org; pwe3@ietf.org; ticctoc@ietf.org; mpls-tp@ietf.org
>>> 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: ticctoc@ietf.org ; mpls@ietf.org ; mpls-tp@ietf.org ; pwe3@ietf.org
>>>> 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
>>>> pwe3@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>>
>>>
>>
>>
>>
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>>
>>
>>
>>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls