Re: [mpls] [PWE3] 1588 over MPLS draft
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 15 July 2010 19:06 UTC
Return-Path: <jmh@joelhalpern.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 800A13A6AA5; Thu, 15 Jul 2010 12:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 pFCXiMT-7b2J; Thu, 15 Jul 2010 12:06:12 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 298C03A6971; Thu, 15 Jul 2010 12:06:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 9D74732365DE; Thu, 15 Jul 2010 12:06:19 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.10.10.102] (pool-71-161-50-61.clppva.btas.verizon.net [71.161.50.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id B5AC632365DA; Thu, 15 Jul 2010 12:06:17 -0700 (PDT)
Message-ID: <4C3F5C24.4070505@joelhalpern.com>
Date: Thu, 15 Jul 2010 15:06:12 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Shahram Davari <davari@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> <2C2F1EBA8050E74EA81502D5740B4BD6940EC290F5@SJEXCHCCR02.corp.ad.broadcom.com>
In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6940EC290F5@SJEXCHCCR02.corp.ad.broadcom.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "mpls@ietf.org" <mpls@ietf.org>, "ticctoc@ietf.org" <ticctoc@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>, "mpls-tp@ietf.org" <mpls-tp@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 19:06:13 -0000
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: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 >
- Re: [mpls] [PWE3] 1588 over MPLS draft Greg Mirsky
- Re: [mpls] [PWE3] 1588 over MPLS draft Jia HE
- Re: [mpls] [PWE3] 1588 over MPLS draft S. Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Mach Chen
- Re: [mpls] [PWE3] 1588 over MPLS draft Stewart Bryant
- Re: [mpls] [PWE3] 1588 over MPLS draft Curtis Villamizar
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Curtis Villamizar
- Re: [mpls] [PWE3] 1588 over MPLS draft Mach Chen
- Re: [mpls] [PWE3] 1588 over MPLS draft Joel M. Halpern
- Re: [mpls] [PWE3] 1588 over MPLS draft Mach Chen
- Re: [mpls] [PWE3] 1588 over MPLS draft Jia HE
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Joel M. Halpern
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Joel M. Halpern
- Re: [mpls] [PWE3] 1588 over MPLS draft John E Drake
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [mpls-tp] [PWE3] 1588 over MPLS draft Ben Niven-Jenkins
- Re: [mpls] [PWE3] 1588 over MPLS draft Mach Chen
- Re: [mpls] [PWE3] 1588 over MPLS draft lizhong.jin
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [PWE3] 1588 over MPLS draft Curtis Villamizar
- Re: [mpls] [mpls-tp] [PWE3] 1588 over MPLS draft Curtis Villamizar
- Re: [mpls] [mpls-tp] [PWE3] 1588 over MPLS draft Curtis Villamizar
- Re: [mpls] [PWE3] 1588 over MPLS draft Curtis Villamizar
- Re: [mpls] [PWE3] 1588 over MPLS draft Shahram Davari
- Re: [mpls] [mpls-tp] [PWE3] 1588 over MPLS draft S. Davari