Re: [mpls] [PWE3] 1588 over MPLS draft
Shahram Davari <davarish@yahoo.com> Fri, 16 July 2010 03:51 UTC
Return-Path: <davarish@yahoo.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 2FA6F3A6822 for <mpls@core3.amsl.com>; Thu, 15 Jul 2010 20:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 SvOPUgvMmdlF for <mpls@core3.amsl.com>; Thu, 15 Jul 2010 20:51:43 -0700 (PDT)
Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id 4F1493A67EA for <mpls@ietf.org>; Thu, 15 Jul 2010 20:51:43 -0700 (PDT)
Received: from [68.142.200.227] by n15.bullet.mail.mud.yahoo.com with NNFMP; 16 Jul 2010 03:51:52 -0000
Received: from [66.196.97.152] by t8.bullet.mud.yahoo.com with NNFMP; 16 Jul 2010 03:51:51 -0000
Received: from [127.0.0.1] by omp205.mail.re3.yahoo.com with NNFMP; 16 Jul 2010 03:51:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 860575.10397.bm@omp205.mail.re3.yahoo.com
Received: (qmail 52842 invoked by uid 60001); 16 Jul 2010 03:51:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1279252311; bh=vCaLWYHh1oZj7NwI917l9VVZMZmzXjJSJRMJcskjYUI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DArt+W+l95PBL+qxWzRQWV1nxeDw9aDV6WGU2BzSMxN4L+e6lcriCxrZxe//MhUwC2KT5J9MBriJEfQHLcd+9zutYVGAsBw1tyLXv3McwVF8iISxLoasjoj/K4cL6SoAcSzMgd4igvG706LRdfg6GdtwfiBplR26RgKpdGQPzBE=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vewhnNHr98d35NwuIp4QoBkJydbffa2VQWGNuDhIM1r2vJ2xU6WQZD8UkWESfi1BOjMbdieJQ92/PLdfB7rda4jBN0YkW3t/IlTlBExcdXYK34MElz5IUKMC8JDHWdc3W6TES9SIFBsgyhdhniLW2BjEdk3wwjrkQOiG5S5+54s=;
Message-ID: <629665.45604.qm@web88412.mail.re1.yahoo.com>
X-YMail-OSG: Za7wlhgVM1nC1F39Cmhh.pUo2lyTo8SKPTn5M.JuJuImxBm h_LBYLyr4kkaLG_E_oMl9Z.tly6hUkQYICuFRV1u.rIr8ljcI.0tIfiSBnsc 3wmXzZG2jQa4e5XL4YTlTNovBpK9Koe6sA0mGkUHFa7KwlE4jkj107yRx.hk fQybALf5E.nkYQqFBJe4hhkmd8LABdpCDQNIABrJ540fnY.CCxJHwWFDMXCo uhh.T_xcBqYeKycykMmo56waZaGdI0dSacmHp7ksWRNxmZQUVlhosKELHbFQ weyK.Ay4A9Q.VgCToQDN479_Pv8xyqAczvxF4jFFRZ8C0ZpClWa8eAIO9QAt Tfv6DlJbw1shvMTXn
Received: from [166.134.150.116] by web88412.mail.re1.yahoo.com via HTTP; Thu, 15 Jul 2010 20:51:51 PDT
X-Mailer: YahooMailWebService/0.8.104.276605
Date: Thu, 15 Jul 2010 20:51:51 -0700
From: Shahram Davari <davarish@yahoo.com>
To: Mach Chen <mach@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 16 Jul 2010 03:51:45 -0000
Mach Is this supported by RSVP-TE? Best Regards, Shahram On Jul 15, 2010, at 6:35 PM, Mach Chen <mach@huawei.com> 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" <davari@broadcom.com> Sent: Friday, July 16, 2010 4:37 AM To: "Joel M. Halpern" <jmh@joelhalpern.com> Cc: <mpls@ietf.org>; <pwe3@ietf.org>; <ticctoc@ietf.org>; <mpls-tp@ietf.org> 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:jmh@joelhalpern.com] Sent: Thursday, July 15, 2010 1:32 PM To: Shahram Davari Cc: mpls@ietf.org; pwe3@ietf.org; ticctoc@ietf.org; mpls-tp@ietf.org 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:jmh@joelhalpern.com] Sent: Thursday, July 15, 2010 12:06 PM To: Shahram Davari Cc: Mach Chen; 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 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 _______________________________________________ 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