From pce-bounces@lists.ietf.org Wed Jan 03 13:15:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ae9-0000mj-Mk; Wed, 03 Jan 2007 13:15:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ae4-0000hK-MP for pce@ietf.org; Wed, 03 Jan 2007 13:15:24 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2Abo-00036L-KT for pce@ietf.org; Wed, 03 Jan 2007 13:13:06 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Jan 2007 13:13:02 -0500 X-IronPort-AV: i="4.12,233,1165208400"; d="scan'208"; a="110799986:sNHT43608268" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l03ID2mi004018; Wed, 3 Jan 2007 13:13:02 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03ID17f004701; Wed, 3 Jan 2007 13:13:01 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:13:01 -0500 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:13:01 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 3 Jan 2007 13:12:59 -0500 To: pce@ietf.org X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jan 2007 18:13:01.0099 (UTC) FILETIME=[CDE50FB0:01C72F62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=956; t=1167847982; x=1168711982; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20WG=20Feed-back=20required=20on=20draft-farrel-pce-manageabili ty-requirements-02.txt |Sender:=20 |To:=20pce@ietf.org; bh=HuRHDw+daRQFKoTjc2oqOjCYdR7YqIwmym9Ru2qfAiY=; b=QOyjVCHwQE3xapXoEIOX5INdeoqVhGz2emZZ22+tWqyMEGuJJPHxbSql8yWzihbBLZqesk8O 2RvfF1W2skUMx6B/zB5Du39yt0CIlNHnuS2lnTXkM6xHVFjSlfJhHwk5; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Dan \(\(Dan\)\) Romascanu" Subject: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear WG, The idea of adding a Manageability section to IDs was first introduced by Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see the WG minutes) since then two revisions of draft- farrel-pce-manageability-requirements have been published based on the comments received from members of the PCE WG and OPS ADs. My recollection of the discussions about this ID is a general good support from members of the PCE WG and OPS AD (thanks to Dan for his help). The were some concerns from Lou that have been addressed in the latest revision of the draft. Furthermore, there are several IDs in the works for which the authors agreed to add a manageability section and "experiment" the process that may have to be tuned as we'll move forward. Because, this ID does have some implication on (current and future) PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG document. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 03 13:15:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ae5-0000j3-QJ; Wed, 03 Jan 2007 13:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Ae4-0000hI-CG; Wed, 03 Jan 2007 13:15:24 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2AcN-00038N-Oh; Wed, 03 Jan 2007 13:13:40 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Jan 2007 10:13:40 -0800 X-IronPort-AV: i="4.12,233,1165219200"; d="scan'208"; a="49921566:sNHT43233700" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l03IDd55004282; Wed, 3 Jan 2007 13:13:39 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l03IDa7f004850; Wed, 3 Jan 2007 13:13:36 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:13:36 -0500 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 13:13:36 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Wed, 3 Jan 2007 13:13:34 -0500 To: Ross Callon , Bill Fenner X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jan 2007 18:13:36.0145 (UTC) FILETIME=[E2C8A810:01C72F62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=229; t=1167848019; x=1168712019; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Publication=20Request=3A=20draft-ietf-pce-pcecp-interarea-req s-05.txt |Sender:=20 |To:=20Ross=20Callon=20, =20Bill=20Fenner=20; bh=RLucknJVOB8jvKJgCyRAhQ7apPEg9xdDggTsR6JbHBk=; b=MJGHe5macZ9j/6nhyw3sH0iQ1AbqyFCp8HtWJx9lgssHgI/SPqPJqAn/EZ1ZHvIxKf5shMTp p07TgP3MxbyGofEPOYKV5Zu4v4YN+G+/hgLPqsElBKnj3JzWHxhOo9jr; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: iesg-secretary@ietf.org, pce@ietf.org Subject: [Pce] Publication Request: draft-ietf-pce-pcecp-interarea-reqs-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, draft-ietf-pce-pcecp-interarea-reqs-05.txt has completed Working Group Last Call and is now ready according to the WG chairs' judgement. Please consider it for publication as an Informational RFC. Thanks, JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 03 14:28:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bmr-0008K0-Dn; Wed, 03 Jan 2007 14:28:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2Bmq-0008FU-4Q for pce@ietf.org; Wed, 03 Jan 2007 14:28:32 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2Bmn-0007e6-QV for pce@ietf.org; Wed, 03 Jan 2007 14:28:32 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1167852508!13058304!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9189 invoked from network); 3 Jan 2007 19:28:29 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-12.tower-121.messagelabs.com with SMTP; 3 Jan 2007 19:28:29 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l03JSSaF020534; Wed, 3 Jan 2007 14:28:28 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l03JSOe6020501; Wed, 3 Jan 2007 14:28:24 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Date: Wed, 3 Jan 2007 13:28:23 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC808E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: AccvY3OsuDFEC+g8QGWraR18iSpDXQABy9ZQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org > Because, this ID does have some implication on (current and future) =20 > PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG=20 > document. Question on the ultimate intent of this draft http://ietf.org/internet-drafts/draft-farrel-pce-manageability-requireme nts-02.txt: Is the goal to only apply the requirements to the PCE WG drafts or to the IETF as a whole? It appears the intent is to restrict to the PCE WG and hope that other WGs apply in the future. If we adopt this process just for the PCE WG, what becomes of the revised process after the PCE WG completes its work and is disbanded? Process experiments are run according to RFC 3933 http://www.ietf.org/rfc/rfc3933.txt?number=3D3933, and AFAIK are = intended to be applied to IETF-wide processes. =20 Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 03 15:39:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CtV-00061y-Ne; Wed, 03 Jan 2007 15:39:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2CtU-00061j-P4 for pce@ietf.org; Wed, 03 Jan 2007 15:39:28 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2CtS-0003Lj-B5 for pce@ietf.org; Wed, 03 Jan 2007 15:39:28 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1H2CtL-0007On-00 for pce@ietf.org; Wed, 03 Jan 2007 20:39:19 +0000 Received: from your029b8cecfe ([217.158.132.71] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 20:39:21 +0000 Message-ID: <031501c72f77$3b884af0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "Ash, Gerald R \(Jerry\), ALABS" , "JP Vasseur" , References: <9473683187ADC049A855ED2DA739ABCA0DDC808E@KCCLUST06EVS1.ugd.att.com> Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt Date: Wed, 3 Jan 2007 20:39:06 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 03 Jan 2007 20:39:22.0036 (UTC) FILETIME=[3FBDB740:01C72F77] X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org All good questions, Jerry. Avri, Loa, and I originally had an ambitious plan to "force" these requirements on the whole of the Routing Area. This seemed to us to be the right scale for such an experiment, but I think folks were (probably reasonably) a bit shy of making such a change on such a large scale. My next proposal was to bring this forward as 3933 process experiment limited to the PCE working group. However, various process experts and some of the IESG warned us off saying that such a process experiment was really targeted at a larger proving ground and that 3933 was too heavy for what we had in mind. They suggested that if we were limiting ourselves to just the PCE working group and if the working group supported the idea, we should just get on with it. So that is what this revision of the draft is trying to do. My hope is that valuable lessons will be learned resulting either in this idea being refined or abandoned. This should give other working group chairs (and hopefully the IESG) some helpful input. At the same time, I hope that the output of the PCE working group will be suitably improved by following these guidelines. I know that the Ops ADs are considering a separate effort at the next IETF that will look at offering guidance to the authors of *all* I-Ds on how they can give suitable considerations to Manageability, and I am sure that we will be trying to keep in synch. Cheers, Adrian ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Wednesday, January 03, 2007 7:28 PM Subject: RE: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt > Because, this ID does have some implication on (current and future) > PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG > document. Question on the ultimate intent of this draft http://ietf.org/internet-drafts/draft-farrel-pce-manageability-requireme nts-02.txt: Is the goal to only apply the requirements to the PCE WG drafts or to the IETF as a whole? It appears the intent is to restrict to the PCE WG and hope that other WGs apply in the future. If we adopt this process just for the PCE WG, what becomes of the revised process after the PCE WG completes its work and is disbanded? Process experiments are run according to RFC 3933 http://www.ietf.org/rfc/rfc3933.txt?number=3933, and AFAIK are intended to be applied to IETF-wide processes. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 04 16:08:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZoW-0006eq-Tt; Thu, 04 Jan 2007 16:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZoW-0006ef-6c for pce@ietf.org; Thu, 04 Jan 2007 16:07:52 -0500 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2ZoT-0001S1-RZ for pce@ietf.org; Thu, 04 Jan 2007 16:07:52 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1167944866!1900019!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 14590 invoked from network); 4 Jan 2007 21:07:47 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-3.tower-146.messagelabs.com with SMTP; 4 Jan 2007 21:07:47 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l04L7kVa006539; Thu, 4 Jan 2007 16:07:46 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l04L7gZZ006518; Thu, 4 Jan 2007 16:07:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt Date: Thu, 4 Jan 2007 15:07:42 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC8095@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <031501c72f77$3b884af0$0a23fea9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: Accvd025bL95LlnSRuKlMqN3ipbRnwAzJ2AQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Thanks Adrian, very helpful. Yes, I support adopting this ID as a WG document and the need for a manageability section in WG drafts. Regards, Jerry -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Wednesday, January 03, 2007 3:39 PM To: Ash, Gerald R (Jerry), ALABS; JP Vasseur; pce@ietf.org Cc: Dan ((Dan)) Romascanu Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt All good questions, Jerry. Avri, Loa, and I originally had an ambitious plan to "force" these=20 requirements on the whole of the Routing Area. This seemed to us to be the=20 right scale for such an experiment, but I think folks were (probably=20 reasonably) a bit shy of making such a change on such a large scale. My next proposal was to bring this forward as 3933 process experiment=20 limited to the PCE working group. However, various process experts and some=20 of the IESG warned us off saying that such a process experiment was really=20 targeted at a larger proving ground and that 3933 was too heavy for what we=20 had in mind. They suggested that if we were limiting ourselves to just the=20 PCE working group and if the working group supported the idea, we should just get on with it. So that is what this revision of the draft is trying to do. My hope is that valuable lessons will be learned resulting either in this=20 idea being refined or abandoned. This should give other working group chairs=20 (and hopefully the IESG) some helpful input. At the same time, I hope that=20 the output of the PCE working group will be suitably improved by following=20 these guidelines. I know that the Ops ADs are considering a separate effort at the next IETF=20 that will look at offering guidance to the authors of *all* I-Ds on how they=20 can give suitable considerations to Manageability, and I am sure that we will be trying to keep in synch. Cheers, Adrian ----- Original Message -----=20 From: "Ash, Gerald R (Jerry), ALABS" To: "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Wednesday, January 03, 2007 7:28 PM Subject: RE: [Pce] WG Feed-back=20 requiredondraft-farrel-pce-manageability-requirements-02.txt > Because, this ID does have some implication on (current and future) > PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG > document. Question on the ultimate intent of this draft http://ietf.org/internet-drafts/draft-farrel-pce-manageability-requireme nts-02.txt: Is the goal to only apply the requirements to the PCE WG drafts or to the IETF as a whole? It appears the intent is to restrict to the PCE WG and hope that other WGs apply in the future. If we adopt this process just for the PCE WG, what becomes of the revised process after the PCE WG completes its work and is disbanded? Process experiments are run according to RFC 3933 http://www.ietf.org/rfc/rfc3933.txt?number=3D3933, and AFAIK are = intended to be applied to IETF-wide processes. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 09 18:24:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QK3-0003we-8h; Tue, 09 Jan 2007 18:24:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4QJv-0003q2-S9 for pce@ietf.org; Tue, 09 Jan 2007 18:23:55 -0500 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Q8B-0007eO-5v for pce@ietf.org; Tue, 09 Jan 2007 18:11:48 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1H4Q83-00078g-00 for pce@ietf.org; Tue, 09 Jan 2007 23:11:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Pce] WG Feed-backrequiredondraft-farrel-pce-manageability-requirements-02.txt Date: Tue, 9 Jan 2007 23:11:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <3D1918258E6DE14DAAABBD34D53D29340CCAD7@cortex.aria-networks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-backrequiredondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: Accvd025bL95LlnSRuKlMqN3ipbRnwAzJ2AQAP+s3HA= References: <9473683187ADC049A855ED2DA739ABCA0DDC8095@KCCLUST06EVS1.ugd.att.com> From: "Daniel King" To: "Ash, Gerald R \(Jerry\), ALABS" , "Adrian Farrel" , "JP Vasseur" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello all, I'd like to add my support to making this a WG document. It's a good start and should fuel proactive discussions re: Manageability for new drafts. =20 Thanks, Dan -----Original Message----- From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 Sent: 04 January 2007 21:08 To: Adrian Farrel; JP Vasseur; pce@ietf.org Cc: Dan ((Dan)) Romascanu Subject: RE: [Pce] WG Feed-backrequiredondraft-farrel-pce-manageability-requirements-02.txt Thanks Adrian, very helpful. Yes, I support adopting this ID as a WG document and the need for a manageability section in WG drafts. Regards, Jerry -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Wednesday, January 03, 2007 3:39 PM To: Ash, Gerald R (Jerry), ALABS; JP Vasseur; pce@ietf.org Cc: Dan ((Dan)) Romascanu Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt All good questions, Jerry. Avri, Loa, and I originally had an ambitious plan to "force" these requirements on the whole of the Routing Area. This seemed to us to be the right scale for such an experiment, but I think folks were (probably reasonably) a bit shy of making such a change on such a large scale. My next proposal was to bring this forward as 3933 process experiment limited to the PCE working group. However, various process experts and some of the IESG warned us off saying that such a process experiment was really targeted at a larger proving ground and that 3933 was too heavy for what we had in mind. They suggested that if we were limiting ourselves to just the PCE working group and if the working group supported the idea, we should just get on with it. So that is what this revision of the draft is trying to do. My hope is that valuable lessons will be learned resulting either in this idea being refined or abandoned. This should give other working group chairs (and hopefully the IESG) some helpful input. At the same time, I hope that the output of the PCE working group will be suitably improved by following these guidelines. I know that the Ops ADs are considering a separate effort at the next IETF that will look at offering guidance to the authors of *all* I-Ds on how they can give suitable considerations to Manageability, and I am sure that we will be trying to keep in synch. Cheers, Adrian ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Wednesday, January 03, 2007 7:28 PM Subject: RE: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt > Because, this ID does have some implication on (current and future)=20 > PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG=20 > document. Question on the ultimate intent of this draft http://ietf.org/internet-drafts/draft-farrel-pce-manageability-requireme nts-02.txt: Is the goal to only apply the requirements to the PCE WG drafts or to the IETF as a whole? It appears the intent is to restrict to the PCE WG and hope that other WGs apply in the future. If we adopt this process just for the PCE WG, what becomes of the revised process after the PCE WG completes its work and is disbanded? Process experiments are run according to RFC 3933 http://www.ietf.org/rfc/rfc3933.txt?number=3D3933, and AFAIK are = intended to be applied to IETF-wide processes. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 10 10:50:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fiO-0001Lt-83; Wed, 10 Jan 2007 10:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4fiN-0001Ln-7F for pce@ietf.org; Wed, 10 Jan 2007 10:50:11 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4fiA-0001uO-BG for pce@ietf.org; Wed, 10 Jan 2007 10:50:11 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Jan 2007 16:49:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Date: Wed, 10 Jan 2007 16:49:49 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: AccvY08wfOQ4+hp+QrarWOMVMCe3YgFasyxg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , X-OriginalArrivalTime: 10 Jan 2007 15:49:51.0381 (UTC) FILETIME=[F6EA5C50:01C734CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Jean-Philippe, Adrian, all The manageability section will be really useful. I support this draft as = WG document. Regards JL > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com]=20 > Envoy=E9 : mercredi 3 janvier 2007 19:13 > =C0 : pce@ietf.org > Cc : Dan ((Dan)) Romascanu > Objet : [Pce] WG Feed-back required=20 > ondraft-farrel-pce-manageability-requirements-02.txt >=20 > Dear WG, >=20 > The idea of adding a Manageability section to IDs was first=20 > introduced by Adrian and discussed at IETF-65 Dallas March=20 > 2006 (for reference, see the WG minutes) since then two=20 > revisions of draft- farrel-pce-manageability-requirements=20 > have been published based on the comments received from=20 > members of the PCE WG and OPS ADs. >=20 > My recollection of the discussions about this ID is a general=20 > good support from members of the PCE WG and OPS AD (thanks to=20 > Dan for his help). The were some concerns from Lou that have=20 > been addressed in the latest revision of the draft. >=20 > Furthermore, there are several IDs in the works for which the=20 > authors agreed to add a manageability section and=20 > "experiment" the process that may have to be tuned as we'll=20 > move forward. >=20 > Because, this ID does have some implication on (current and=20 > future) PCE WG IDs, I'd welcome feed-back on adopting this ID=20 > as a WG document. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 11 13:32:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54iR-00015G-0o; Thu, 11 Jan 2007 13:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54iP-000150-5g for pce@ietf.org; Thu, 11 Jan 2007 13:31:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54iG-0003kw-Sj for pce@ietf.org; Thu, 11 Jan 2007 13:31:53 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jan 2007 10:31:45 -0800 X-IronPort-AV: i="4.13,174,1167638400"; d="scan'208,217"; a="50608855:sNHT88538760" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0BIVitZ031428 for ; Thu, 11 Jan 2007 13:31:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0BIViVT003256 for ; Thu, 11 Jan 2007 13:31:44 -0500 (EST) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 13:31:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Pce] update of the PCE Path Key Draft Date: Thu, 11 Jan 2007 13:31:42 -0500 Message-ID: <3C292CE901FC634693F24FB2DDC4D33202725CCD@xmb-rtp-20d.amer.cisco.com> In-Reply-To: <15D54E13-EC8B-49B8-A96C-E85ECF50A1E7@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] update of the PCE Path Key Draft Thread-Index: Acc1j68ouep9mGO0Q36SwQYf3PQHLwAGPEsw From: "Rich Bradford \(rbradfor\)" To: X-OriginalArrivalTime: 11 Jan 2007 18:31:44.0471 (UTC) FILETIME=[BEC80670:01C735AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5198; t=1168540304; x=1169404304; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rbradfor@cisco.com; z=From:=20=22Rich=20Bradford=20\(rbradfor\)=22=20 |Subject:=20=20[Pce]=20update=20of=20the=20PCE=20Path=20Key=20Draft=20 |Sender:=20 |To:=20; bh=+RoxnGcZIQWQPu2BAooPA3UYbqWrlApMHae7pQJifGU=; b=jaCcWmPz5wfnurKKMFZJdeomAPv+x0Y1tc/VUJG39Zn+FrawZwjGngFhnLHzBT60+ZTV9Hdh K3NMUV9r20CMpyEI/4RMs4WDABDIPpP83bFPILmAeFD928ILYzvrdHza; Authentication-Results: rtp-dkim-2; header.From=rbradfor@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0668304121==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0668304121== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C735AE.BE9EBDA2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C735AE.BE9EBDA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG, Just a quick update on the changes in the recently posted update to the path key draft, draft-bradford-pce-path-key-02.txt. This rev clarifies the language in most sections and calls out the PCEP extensions for the PKS ID. We hope it addresses most of the issues that have been raised. I want to thank the everyone for their suggestions. We've had quite a few discussions in the WG at meetings and on the list with pretty good support for the draft. The draft is now in pretty good shape, there are still minor aspects that should benefit from WG feed-back. Best Regards, Rich =20 ------_=_NextPart_001_01C735AE.BE9EBDA2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG,

Just a quick update on the changes in the recently posted update = to the path key draft, draft-bradford-pce-path-key-02.txt. This rev clarifies = the language in most sections and calls out the PCEP extensions for the PKS = ID. We hope it addresses most of the issues that have been raised. I want to = thank the everyone for their suggestions. We’ve had quite a few discussions = in the WG at meetings and on the list with pretty good support for the draft. = The draft is now in pretty good shape, there are still minor aspects that = should benefit from WG feed-back.

  Best Regards,

    Rich

 

------_=_NextPart_001_01C735AE.BE9EBDA2-- --===============0668304121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0668304121==-- From pce-bounces@lists.ietf.org Thu Jan 11 16:30:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57Uy-0001xx-2g; Thu, 11 Jan 2007 16:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57Uw-0001w6-Oe for pce@ietf.org; Thu, 11 Jan 2007 16:30:10 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57Uu-0000EG-Fg for pce@ietf.org; Thu, 11 Jan 2007 16:30:10 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Jan 2007 16:30:08 -0500 X-IronPort-AV: i="4.13,175,1167627600"; d="scan'208"; a="111502899:sNHT54690256" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0BLU8bF007360; Thu, 11 Jan 2007 16:30:08 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0BLU8OA002414; Thu, 11 Jan 2007 16:30:08 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 16:30:08 -0500 Received: from kkoushikwxp ([64.101.185.176]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 16:30:07 -0500 Message-ID: <011901c735c7$aa4b15c0$b0b96540@apac.cisco.com> From: "A S Kiran Koushik" To: "STEPHAN Emile RD-CORE-LAN" References: Date: Thu, 11 Jan 2007 15:30:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 11 Jan 2007 21:30:07.0622 (UTC) FILETIME=[AA5B4260:01C735C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1436; t=1168551008; x=1169415008; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkoushik@cisco.com; z=From:=20=22A=20S=20Kiran=20Koushik=22=20 |Subject:=20Re=3A=20PCEP=20MIB |Sender:=20 |To:=20=22STEPHAN=20Emile=20RD-CORE-LAN=22=20; bh=YJJW2DXNLqKIuHynZDSin5D9c18xNGL4e5KPJsLHzlA=; b=xvkZKpKui5TI45U3soFdsvb+jXuxKIyutrPXGZONJGM1Q8+eLdV/guKqC0Vh9kU9QK4N1pcm 92F7r8nWC1JAM4FeL0l+mUkFh7FwS5Vp8nHFkFx5hH05yUGuwmlGr/TF; Authentication-Results: rtp-dkim-2; header.From=kkoushik@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: pce@ietf.org Subject: [Pce] Re: PCEP MIB X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Emile, Thanks! I will schedule a telecon by end of this month and we will start working on the code for the drafts Regards, Kiran. ----- Original Message ----- From: "STEPHAN Emile RD-CORE-LAN" To: "A S Kiran Koushik" Cc: Sent: Friday, January 05, 2007 11:47 AM Subject: PCEP MIB Hi Kiran, My best wishes for this new year. I agree completely with your proposal. Tagging MIB names with DRAFT helps implementers to distinguish draft mib from final mib. So the new name of the decomposition looks like: MIB module WG draft name ================================================ PCE-DISC-DRAFT-MIB draft-ietf-pce-disc-mib -- PCE discovery MIB. PCE-PCEP-DRAFT-MIB draft-ietf-pce-pcep-mib -- PCE communication protocol MIB PCE-PCC-DRAFT-MIB draft-ietf-pce-pcc-mib -- Path Computation Client MIB PCE-TC-DRAFT-MIB draft-ietf-pce-tc-mib -- PCE Textual conventions MIB. I will update TC MIB and DISC MIB in that way. To keep naming consistent I just added pce before pcep in draft-ietf-pcep-mib and PCE before PCEP-DRAFT-MIB. Let me known how to start my contribution to this draft. I propose we start with a teleconf to define the general structure of the PCEP MIB before going in the details of each groups of objects. Regards Emile _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 12 11:06:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OvV-0000xj-1x; Fri, 12 Jan 2007 11:06:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OvT-0000xP-K9 for pce@ietf.org; Fri, 12 Jan 2007 11:06:43 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5OvR-00052E-8c for pce@ietf.org; Fri, 12 Jan 2007 11:06:43 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1H5Ovd-0007SG-00 for pce@ietf.org; Fri, 12 Jan 2007 16:06:53 +0000 Received: from your029b8cecfe ([217.158.132.43] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 16:06:35 +0000 Message-ID: <116101c73663$9f1d2ca0$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: Date: Fri, 12 Jan 2007 16:05:40 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 12 Jan 2007 16:06:36.0524 (UTC) FILETIME=[A2DA82C0:01C73663] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Pce] Temporary PCEP codepoints registry X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, Seeing that we now have a couple of people working on PCEP extensions, I thought it might be helpful to keep a centralised registry of codepoints until such time as IANA takes over. You can see this at http://www.olddog.co.uk/pce.htm Note that allocation in this temporary registry does not imply that IANA will make the same allocation, but they are generally quite good at following recommendations, so if we can keep ourselves untangled on the web page, we should be good. Please email me with any additions or changes. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 12 14:29:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S5v-0003Lz-DF; Fri, 12 Jan 2007 14:29:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5S5u-0003Lu-QP for pce@ietf.org; Fri, 12 Jan 2007 14:29:42 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5S5t-0004Ny-8m for pce@ietf.org; Fri, 12 Jan 2007 14:29:42 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Jan 2007 14:29:41 -0500 X-IronPort-AV: i="4.13,179,1167627600"; d="scan'208,217"; a="111574122:sNHT83851464" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0CJTffa026419 for ; Fri, 12 Jan 2007 14:29:41 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0CJTbOC028078 for ; Fri, 12 Jan 2007 14:29:40 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 14:29:40 -0500 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 14:29:39 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> References: From: JP Vasseur Subject: Fwd: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt Date: Fri, 12 Jan 2007 14:28:58 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Jan 2007 19:29:39.0570 (UTC) FILETIME=[0083CD20:01C73680] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7875; t=1168630181; x=1169494181; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20WG=20Feed-back=20required=20on=20draft-farre l-pce-manageability-requirements-02.txt |Sender:=20 |To:=20pce@ietf.org; bh=xDViobuucmMxJPj/DLT7Pf30X1oq3qQwOXZYdepvWns=; b=oedRvoClNDRb9l3DdU7qjb3I6vLi/AEgpqa3BMZv5+58p0BAyvqXH/gIBqBJQmCTh7StgyZx yNtPcYUFOrETyfEfSPnOKuOY7OZgWc5wxRKrm2zqlHm6BbHqIm04pMVE; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1046203967==" Errors-To: pce-bounces@lists.ietf.org --===============1046203967== Content-Type: multipart/alternative; boundary=Apple-Mail-81--803106316 --Apple-Mail-81--803106316 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, We had so far a few (and positive) feed-backs, it would be nice to get more feed-back on this (in particular several of the usual contributors haven't expressed their opinion). Thanks. Happy New Year to all of you. JP. Begin forwarded message: > From: JP Vasseur > Date: January 3, 2007 1:12:59 PM EST > To: pce@ietf.org > Cc: "Dan \(\(Dan\)\) Romascanu" > Subject: [Pce] WG Feed-back required on draft-farrel-pce- > manageability-requirements-02.txt > > Dear WG, > > The idea of adding a Manageability section to IDs was first > introduced by Adrian and discussed at IETF-65 Dallas March 2006 > (for reference, see the WG minutes) since then two revisions of > draft-farrel-pce-manageability-requirements have been published > based on the comments received from members of the PCE WG and OPS ADs. > > My recollection of the discussions about this ID is a general good > support from members of the PCE WG and OPS AD (thanks to Dan for > his help). The were some concerns from Lou that have been addressed > in the latest revision of the draft. > > Furthermore, there are several IDs in the works for which the > authors agreed to add a manageability section and "experiment" the > process that may have to be tuned as we'll move forward. > > Because, this ID does have some implication on (current and future) > PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG > document. > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-81--803106316 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Dear WG,

We had so far a few (and = positive) feed-backs, it would be nice to get more feed-back on this (in = particular several of the usual contributors haven't expressed their = opinion).

Thanks.

Happy New Year to all of = you.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = January 3, 2007 1:12:59 PM EST
Cc: "Dan = \(\(Dan\)\) Romascanu" <dromasca@avaya.com>
=
Subject: = [Pce] WG Feed-back required on = draft-farrel-pce-manageability-requirements-02.txt

Dear = WG,

The idea of adding a Manageability section to IDs = was first introduced by Adrian and discussed at IETF-65 Dallas March = 2006 (for reference, see the WG minutes) since then two revisions of = draft-farrel-pce-manageability-requirements have been published based on = the comments received from members of the PCE WG and OPS ADs.

My = recollection of the discussions about this ID is a general good support = from members of the PCE WG and OPS AD (thanks to Dan for his help). The = were some concerns from Lou that have been addressed in the latest = revision of the draft.
Furthermore, there are several = IDs in the works for which the authors agreed to add a manageability = section and "experiment" the process that may have to be tuned as we'll = move forward.

Because, this ID does have some implication on = (current and future) PCE WG IDs, I'd welcome feed-back on adopting this = ID as a WG document.
Thanks.


Pce mailing list
=

= --Apple-Mail-81--803106316-- --===============1046203967== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1046203967==-- From pce-bounces@lists.ietf.org Fri Jan 12 14:50:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SQC-0001KE-FA; Fri, 12 Jan 2007 14:50:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SQB-0001HQ-I6 for pce@ietf.org; Fri, 12 Jan 2007 14:50:39 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5SQ9-0000Q9-R4 for pce@ietf.org; Fri, 12 Jan 2007 14:50:39 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2007 11:50:35 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l0CJoZY0028222 for ; Fri, 12 Jan 2007 11:50:35 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0CJoKiG011808 for ; Fri, 12 Jan 2007 11:50:35 -0800 (PST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 14:50:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Date: Fri, 12 Jan 2007 14:50:32 -0500 Message-ID: In-Reply-To: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: Acc2gBYqeJNT5/mjTYevpurIiCqy9gAAlHYA From: "Zafar Ali \(zali\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 12 Jan 2007 19:50:34.0342 (UTC) FILETIME=[EC6AD060:01C73682] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9423; t=1168631435; x=1169495435; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20[Pce]=20WG=20Feed-back=20required=20ondraft-farrel-pc e-manageability-requirements-02.txt |Sender:=20; bh=FD+WpvnZcbKu/WhvBHl4Vw+fQK7LeROgrtj4tx/m3FA=; b=H9NMWYlmejAuGFODnGg5d0603xl8HUKOAQXa0bBCRJqB8jsM3KQYCEiYXxABaHKNRrFWlZJS Ks0lunyOJwjbRDnmWZXJstspVe8FWsuViUNhmIvR37PIL2EmWubk5DDu; Authentication-Results: sj-dkim-5; header.From=zali@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0767430429==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0767430429== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73682.EC419B49" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73682.EC419B49 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi JP, et al-=20 =20 Having Manageability section to ALL IETF ID-es is a good idea. I wish this can be push even beyond this doc. I recall Adrian was pushing it across the spectrum, but don't know what happens.=20 =20 In favor, as you can guess.=20 =20 Thanks =20 Regards... Zafar=20 ________________________________ From: Jean Philippe Vasseur (jvasseur)=20 Sent: Friday, January 12, 2007 2:29 PM To: pce@ietf.org Subject: Fwd: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt =09 =09 Dear WG,=20 We had so far a few (and positive) feed-backs, it would be nice to get more feed-back on this (in particular several of the usual contributors haven't expressed their opinion). Thanks. Happy New Year to all of you. JP. =09 Begin forwarded message: From: JP Vasseur Date: January 3, 2007 1:12:59 PM EST To: pce@ietf.org Cc: "Dan \(\(Dan\)\) Romascanu" Subject: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt Dear WG, The idea of adding a Manageability section to IDs was first introduced by Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see the WG minutes) since then two revisions of draft-farrel-pce-manageability-requirements have been published based on the comments received from members of the PCE WG and OPS ADs. My recollection of the discussions about this ID is a general good support from members of the PCE WG and OPS AD (thanks to Dan for his help). The were some concerns from Lou that have been addressed in the latest revision of the draft. Furthermore, there are several IDs in the works for which the authors agreed to add a manageability section and "experiment" the process that may have to be tuned as we'll move forward. Because, this ID does have some implication on (current and future) PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG document. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C73682.EC419B49 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi JP, et al-
 
Having Manageability section to ALL IETF ID-es = is a good=20 idea. I wish this can be push even beyond this doc. I recall Adrian was = pushing=20 it across the spectrum, but don't know what happens. =
 
In favor, as you can guess. =
 
Thanks
 
Regards... Zafar=20

From: Jean Philippe Vasseur = (jvasseur)=20
Sent: Friday, January 12, 2007 2:29 PM
To:=20 pce@ietf.org
Subject: Fwd: [Pce] WG Feed-back required=20 = ondraft-farrel-pce-manageability-requirements-02.txt

=
Dear WG,

We had so far a few (and positive) feed-backs, it would be nice = to get=20 more feed-back on this (in particular several of the usual = contributors=20 haven't expressed their opinion).

Thanks.

Happy New Year to all of you.

JP.

Begin forwarded message:

From: JP Vasseur <jvasseur@cisco.com>
Date: January 3, = 2007 1:12:59=20 PM EST
To: pce@ietf.org
Cc: "Dan = \(\(Dan\)\)=20 Romascanu" <dromasca@avaya.com>
Subject: = [Pce] WG = Feed-back=20 required on=20 draft-farrel-pce-manageability-requirements-02.txt

Dear WG,

The idea of adding a Manageability = section to IDs=20 was first introduced by Adrian and discussed at IETF-65 Dallas March = 2006=20 (for reference, see the WG minutes) since then two revisions of=20 draft-farrel-pce-manageability-requirements have been published = based on the=20 comments received from members of the PCE WG and OPS ADs.

My recollection of the discussions about = this ID is=20 a general good support from members of the PCE WG and OPS AD (thanks = to Dan=20 for his help). The were some concerns from Lou that have been = addressed in=20 the latest revision of the draft.

Furthermore, there are several IDs in the = works for=20 which the authors agreed to add a manageability section and = "experiment" the=20 process that may have to be tuned as we'll move forward.

Because, this ID does have some = implication on=20 (current and future) PCE WG IDs, I'd welcome feed-back on adopting = this ID=20 as a WG document.

Thanks.

JP.

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

= ------_=_NextPart_001_01C73682.EC419B49-- --===============0767430429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0767430429==-- From pce-bounces@lists.ietf.org Fri Jan 12 15:34:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5T6G-000292-Au; Fri, 12 Jan 2007 15:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5T6E-00028a-N3 for pce@ietf.org; Fri, 12 Jan 2007 15:34:06 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5T6C-00027X-2D for pce@ietf.org; Fri, 12 Jan 2007 15:34:06 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2007 12:34:03 -0800 X-IronPort-AV: i="4.13,179,1167638400"; d="scan'208"; a="356011187:sNHT182738182" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l0CKY2Fh015986; Fri, 12 Jan 2007 12:34:02 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0CKXtVI025481; Fri, 12 Jan 2007 12:34:00 -0800 (PST) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 12:33:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Date: Fri, 12 Jan 2007 12:31:04 -0800 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E02DEF202@xmb-sjc-234.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: AccvY1RAU3UtQSWaT1e+LdeZMlo/1AHHbB3g From: "Dean Cheng \(dcheng\)" To: "Jean Philippe Vasseur \(jvasseur\)" , X-OriginalArrivalTime: 12 Jan 2007 20:33:54.0209 (UTC) FILETIME=[FA0F0910:01C73688] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1513; t=1168634042; x=1169498042; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=20=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:=20RE=3A=20[Pce]=20WG=20Feed-back=20required=20ondraft-farrel-pc e-manageability-requirements-02.txt |Sender:=20; bh=wQynAf8/QLMMKM9XhfVJlIkGtr5IdITD9M3XhjYCco0=; b=kmireYtNKlkEhaQz7AIKici8hkeEmdaDYXb02793KHOM8Fsz0Hh9DJbbbzuELnHLol1PAIYS rGgcHQaXGDwvreMu5mxJg/YyTlJu0xTuBarMqMjsS5XRTTl/3gCCqz9O; Authentication-Results: sj-dkim-4; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org I supported this as a WG I-D.=20 Dean > -----Original Message----- > From: Jean Philippe Vasseur (jvasseur)=20 > Sent: Wednesday, January 03, 2007 10:13 AM > To: pce@ietf.org > Cc: Dan ((Dan)) Romascanu > Subject: [Pce] WG Feed-back required=20 > ondraft-farrel-pce-manageability-requirements-02.txt >=20 > Dear WG, >=20 > The idea of adding a Manageability section to IDs was first=20 > introduced by Adrian and discussed at IETF-65 Dallas March=20 > 2006 (for reference, see the WG minutes) since then two=20 > revisions of draft- farrel-pce-manageability-requirements=20 > have been published based on the comments received from=20 > members of the PCE WG and OPS ADs. >=20 > My recollection of the discussions about this ID is a general=20 > good support from members of the PCE WG and OPS AD (thanks to=20 > Dan for his help). The were some concerns from Lou that have=20 > been addressed in the latest revision of the draft. >=20 > Furthermore, there are several IDs in the works for which the=20 > authors agreed to add a manageability section and=20 > "experiment" the process that may have to be tuned as we'll=20 > move forward. >=20 > Because, this ID does have some implication on (current and=20 > future) PCE WG IDs, I'd welcome feed-back on adopting this ID=20 > as a WG document. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 12 17:20:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5UlR-0005xW-Oc; Fri, 12 Jan 2007 17:20:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5UlQ-0005xR-Qa for pce@ietf.org; Fri, 12 Jan 2007 17:20:44 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5UlO-0004S2-Ps for pce@ietf.org; Fri, 12 Jan 2007 17:20:44 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0CMKRo9016687; Fri, 12 Jan 2007 23:20:44 +0100 In-Reply-To: To: JP Vasseur Subject: Re: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Fri, 12 Jan 2007 23:20:37 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/12/2007 23:20:37, Serialize complete at 01/12/2007 23:20:37 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dromasca@avaya.com, pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p the doc is ok as long as it refers to the manageability of the protocol that is detailed in the corr. i-d - we can express several concerns whether such details are useful or not ... practicing will tell us a couple of comments though -- concerns on section 3.3 - it will for each document open the pandora box of the protocol dependencies - these should remain at most illustrative otherwise o) becoming restrictive with respect to the protocol applicability - o) potentially impacting and/or assuming other protocol(s) behaviour -- generally speaking, the document should state that manageability description shall ideally remain device/implementation independent (of course there will be always exceptions) -- the document says "3.1 Control of Function and Policy This sub-section describes the configurable items that exist for the control of function or policy" the control of functions - via the protocol elements described in the document is important - but the term policy is to vague at which level of the policy specification does that section applies -- the document on network operations is important as it forces the writer to document the dimensions impacting the protocol deployment nevertheless assuming this is the case (taking the example of the doc. the implementer is aware of the scaling threat) which mechanism are in place to prevent protocol deployment ? i guess this boils down somehow to the RFC 1264 discussion and ultimately to the usefulness of the doc. not in terms of description but actual practice hope it will help - d. JP Vasseur 03/01/2007 19:12 To: pce@ietf.org cc: "Dan \(\(Dan\)\) Romascanu" Subject: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt Dear WG, The idea of adding a Manageability section to IDs was first introduced by Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see the WG minutes) since then two revisions of draft- farrel-pce-manageability-requirements have been published based on the comments received from members of the PCE WG and OPS ADs. My recollection of the discussions about this ID is a general good support from members of the PCE WG and OPS AD (thanks to Dan for his help). The were some concerns from Lou that have been addressed in the latest revision of the draft. Furthermore, there are several IDs in the works for which the authors agreed to add a manageability section and "experiment" the process that may have to be tuned as we'll move forward. Because, this ID does have some implication on (current and future) PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG document. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 12 18:50:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5WA6-00021c-BI; Fri, 12 Jan 2007 18:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5W9q-0001zO-Ja; Fri, 12 Jan 2007 18:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5W9p-0003lZ-UV; Fri, 12 Jan 2007 18:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id DB331329A0; Fri, 12 Jan 2007 23:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H5W9p-0001Mm-P5; Fri, 12 Jan 2007 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 12 Jan 2007 18:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 Author(s) : J. Le Roux, J. Vasseur Filename : draft-ietf-pce-pcep-05.txt Pages : 66 Date : 2007-1-12 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-pcep-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-12152022.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-pcep-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-pcep-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-12152022.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Fri Jan 12 18:57:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5WHK-0001df-8D; Fri, 12 Jan 2007 18:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5WHI-0001Yp-SI for pce@ietf.org; Fri, 12 Jan 2007 18:57:44 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5WH3-0006Pa-Vf for pce@ietf.org; Fri, 12 Jan 2007 18:57:44 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Jan 2007 18:57:29 -0500 X-IronPort-AV: i="4.13,180,1167627600"; d="scan'208,217"; a="111593374:sNHT110387454" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0CNvTiv022623 for ; Fri, 12 Jan 2007 18:57:29 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0CNvTVT004575 for ; Fri, 12 Jan 2007 18:57:29 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 18:57:29 -0500 Received: from [10.86.104.185] ([10.86.104.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 18:57:28 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <3329AB0B-19C1-4481-9EE4-4A9226FE01FA@cisco.com> References: From: JP Vasseur Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt Date: Fri, 12 Jan 2007 18:57:26 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Jan 2007 23:57:28.0335 (UTC) FILETIME=[6A3EC1F0:01C736A5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21496; t=1168646249; x=1169510249; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20I-D=20ACTION=3Adraft-ietf-pce-pcep-05.txt=20 |Sender:=20 |To:=20pce@ietf.org; bh=blaA5iLAdoQPfuQ2w5RnfEFP8WMbOXFbdXme2Jmck4A=; b=ZgtdczEP3OmLik4l7kEJ4+/rPHJ20e8KqawqvoAFd9E01MhptDrbu64VryLjjknd7FKP1DTF rmv/gHkBeE/9jsOcD//QEkWY2o0i8cYgsWDjrFc14a0s95Q8cX5jynK3; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0171542701==" Errors-To: pce-bounces@lists.ietf.org --===============0171542701== Content-Type: multipart/alternative; boundary=Apple-Mail-84--786998471 --Apple-Mail-84--786998471 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here are the minor changes: 1) Change in the OPEN object format to align the field on byte boundaries, 2) Addition of a new Reason for closing in the CLOSE object. In rev-04 we had: Reasons Value Meaning 1 No explanation provided 2 DeadTimer expired 3 PCEP session characteristics negotiation failure New: 4 Reception of a malformed packet 3) Typo Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: January 12, 2007 6:50:01 PM EST > To: i-d-announce@ietf.org > Cc: pce@ietf.org > Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element Working > Group of the IETF. > > Title : Path Computation Element (PCE) communication Protocol > (PCEP) - Version 1 > Author(s) : J. Le Roux, J. Vasseur > Filename : draft-ietf-pce-pcep-05.txt > Pages : 66 > Date : 2007-1-12 > > This document specifies the Path Computation Element communication > Protocol (PCEP) for communications between a Path Computation > Client > (PCC) and a Path Computation Element (PCE), or between two PCEs. > Such interactions include path computation requests and path > computation replies as well as notifications of specific states > related to the use of a PCE in the context of MPLS and GMPLS > Traffic > Engineering. The PCEP protocol is designed to be flexible and > extensible so as to easily allow for the addition of further > messages > and objects, should further requirements be expressed in the > future. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-05.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-pce-pcep-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pce-pcep-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-1-12152022.I-D@ietf.org> > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-84--786998471 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Here are the minor = changes:

1) Change = in the OPEN object format=A0to align the field on byte = boundaries,

2) Addition of a new Reason for closing in = the CLOSE object.=A0

In rev-04 we had:=A0

=A0 =A0 Value=A0 =A0 =A0 =A0 = Meaning
=A0 =A0 =A0 1=A0 =A0 =A0 =A0 =A0 = No explanation provided
=A0 =A0 =A0 = 2=A0 =A0 =A0 =A0 =A0 DeadTimer expired
=A0 =A0 = =A0 3=A0 =A0 =A0 =A0 =A0 PCEP session characteristics negotiation = failure

=A0 =A0=A0 =A04 =A0 =A0=A0 =A0=A0= =A0Reception of a malformed packet

3) = Typo


Date: January 12, 2007 6:50:01 PM = EST
To: i-d-announce@ietf.org
Subject: = [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0
This draft is a work item of the = Path Computation Element Working Group of the IETF.

= Title = = : Path Computation Element (PCE) communication Protocol (PCEP) - = Version 1
Author(s) : J. Le = Roux, J. Vasseur
Filename : = draft-ietf-pce-pcep-05.txt
= Pages = = : 66
Date : 2007-1-12


This document = specifies the Path Computation Element communication
=A0=A0 = Protocol (PCEP) for communications between a Path Computation = Client
=A0=A0 (PCC) and a Path = Computation Element (PCE), or between two PCEs.
=A0=A0 = Such interactions include path computation requests and = path
=A0=A0 computation replies as = well as notifications of specific states
=A0=A0 related to the use of a = PCE in the context of MPLS and GMPLS Traffic
=A0=A0 = Engineering.=A0 The = PCEP protocol is designed to be flexible and
=A0=A0 = extensible so as to easily allow for the addition of further = messages
=A0=A0 and objects, should = further requirements be expressed in the future.

A URL = for this Internet-Draft is:

To = remove yourself from the I-D Announcement list, send a message to=A0
i-d-announce-request@ietf.or= g with the word unsubscribe in the body of=A0
the = message.=A0
to = change your subscription settings.

Internet-Drafts are also = available by anonymous FTP. Login with the=A0
username = "anonymous" and a password of your e-mail address. After=A0
logging = in, type "cd internet-drafts" and then=A0
"get = draft-ietf-pce-pcep-05.txt".

A list of Internet-Drafts = directories can be found in
Internet-Drafts can also be = obtained by e-mail.
Send a message to:
In the body type:
"FILE = /internet-drafts/draft-ietf-pce-pcep-05.txt".


NOTE: The mail = server at ietf.org can return the document in
MIME-encoded form by using the = "mpack" utility.=A0 To use = this
feature, insert the command = "ENCODING mime" before the "FILE"
= command.=A0 To = decode the response(s), you will need "munpack" or
a MIME-compliant mail = reader.=A0 Different = MIME-compliant mail readers
exhibit = different behavior, especially when dealing with
"multipart" MIME messages (i.e. = documents which have been split
up into = multiple messages), so check your local documentation on
how to manipulate these = messages.

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically = retrieve the ASCII version of the
Content-Type: = text/plain

=

= --Apple-Mail-84--786998471-- --===============0171542701== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0171542701==-- From pce-bounces@lists.ietf.org Tue Jan 16 05:15:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6lLV-0000ZQ-1x; Tue, 16 Jan 2007 05:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6lLT-0000ZK-57 for pce@ietf.org; Tue, 16 Jan 2007 05:15:11 -0500 Received: from smtp1.mail.atosorigin.com ([160.92.103.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6lLS-0004wf-3L for pce@ietf.org; Tue, 16 Jan 2007 05:15:11 -0500 Received: from filter.worldlinemail.net (localhost [127.0.0.1]) by mwumf0101.mail.fr.ww.atosorigin.com (Postfix) with SMTP id 6491F1C000B3; Tue, 16 Jan 2007 11:15:08 +0100 (CET) Received: from AOFR11476 (localhost [127.0.0.1]) by mwumf0101.mail.fr.ww.atosorigin.com (Postfix) with ESMTP id 1F4F51C000B2; Tue, 16 Jan 2007 11:15:08 +0100 (CET) Message-ID: <002501c73957$1718aea0$16600337@AOFR11476> From: "fabien.verhaeghe" To: , "JP Vasseur" References: <3329AB0B-19C1-4481-9EE4-4A9226FE01FA@cisco.com> Subject: Re: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt Date: Tue, 16 Jan 2007 11:14:20 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: b656e85d4d33f5403d96bac6146425d9 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1419054131==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1419054131== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C7395F.78231570" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C7395F.78231570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello JP, All, I have a question about the PCntf message format: ::=3D ::=3D [] ::=3D [] :=3D=3D :=3D It seems to mean that we have the following kind of relation between RP = and NOTFICATION object: RP --(0..n)--------(1..n)--NOTIFICATION While reading the description of the NOTIFICATION object it seems to me = that it should be RP --(0..n)--------(1..1)--NOTIFICATION Shouldn't we have the following description?=20 ::=3D ::=3D [] ::=3D [] :=3D=3D Or is it to offer some flexibility? Note that the same question/remark applies to Error message. By the way I just noticed a typo in 7.13 NOTIFICATION "If a new PCEP session is established while the PCE is in congested state, the PCE MUST immediately send a PCErr with Notification-type=3D2, Notification-value=3D1 along with the optional CONGESTION-DURATION TLV." Seems PCErr should be replaced by PCntf. Thanks=20 Fabien ----- Original Message -----=20 From: JP Vasseur=20 To: pce@ietf.org=20 Sent: Saturday, January 13, 2007 12:57 AM Subject: Fwd: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt=20 Here are the minor changes: 1) Change in the OPEN object format to align the field on byte = boundaries, 2) Addition of a new Reason for closing in the CLOSE object.=20 In rev-04 we had:=20 Reasons Value Meaning 1 No explanation provided 2 DeadTimer expired 3 PCEP session characteristics negotiation failure New: 4 Reception of a malformed packet 3) Typo Thanks. JP. Begin forwarded message: From: Internet-Drafts@ietf.org Date: January 12, 2007 6:50:01 PM EST To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-05.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Path Computation Element Working = Group of the IETF. Title : Path Computation Element (PCE) communication Protocol (PCEP) = - Version 1 Author(s) : J. Le Roux, J. Vasseur Filename : draft-ietf-pce-pcep-05.txt Pages : 66 Date : 2007-1-12 This document specifies the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation = Client (PCC) and a Path Computation Element (PCE), or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of MPLS and GMPLS = Traffic Engineering. The PCEP protocol is designed to be flexible and extensible so as to easily allow for the addition of further = messages and objects, should further requirements be expressed in the = future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-05.txt To remove yourself from the I-D Announcement list, send a message to = i-d-announce-request@ietf.org with the word unsubscribe in the body = of=20 the message.=20 You can also visit = https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-pce-pcep-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-pcep-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2007-1-12152022.I-D@ietf.org> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce -------------------------------------------------------------------------= ----- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------=_NextPart_000_0022_01C7395F.78231570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello JP, All,
 
I have a question about the PCntf = message=20 format:
 
   <PCNtf = Message>::=3D<Common=20 Header>
          = ;          =20 <notify-list>
   = <notify-list>::=3D<notify>=20 [<notify-list>]
   <notify>::=3D=20 [<request-id-list>]
       &n= bsp;       =20 <notification-list>
  =20 <request-id-list>:=3D=3D<RP><request-id-list>
  =20 <notification-list>:=3D<NOTIFICATION><notification-list>= ;
 
It seems to mean that we have the = following=20 kind of relation between RP and NOTFICATION object:
  RP=20 --(0..n)--------(1..n)--NOTIFICATION
 
While reading the description of the = NOTIFICATION=20 object it seems to me that it should be
  RP=20 --(0..n)--------(1..1)--NOTIFICATION
 
Shouldn't we have the = following description?=20
 
   <PCNtf = Message>::=3D<Common=20 Header>
          = ;          =20 <notify-list>
   = <notify-list>::=3D<notify>=20 [<notify-list>]
   <notify>::=3D=20 [<request-id-list>]
       &n= bsp;       =20 <NOTIFICATION>
  =20 <request-id-list>:=3D=3D<RP><request-id-list>
 
Or is it to offer some flexibility?
Note that the same question/remark applies to Error message.
 
By the way I just noticed a typo in 7.13 NOTIFICATION
 
"If a new PCEP session is established while the PCE is=20 in
         congested state, = the PCE=20 MUST immediately send a PCErr=20 with
         = Notification-type=3D2,=20 Notification-value=3D1 along with=20 the
         optional=20 CONGESTION-DURATION TLV."
Seems PCErr should be replaced by PCntf.
 
Thanks
Fabien
 
----- Original Message -----
From:=20 JP = Vasseur=20
Sent: Saturday, January 13, = 2007 12:57=20 AM
Subject: Fwd: [Pce] I-D=20 ACTION:draft-ietf-pce-pcep-05.txt

Here are the minor = changes:

1) Change in the OPEN object format to align the field on = byte=20 boundaries,

2) Addition of a new Reason for closing in the CLOSE = object. 

In rev-04 we had: 

Reasons
    Value      =  =20 Meaning
      1      =  =20   No explanation provided
      2      =  =20   DeadTimer expired
      3      =  =20   PCEP session characteristics negotiation failure

New:
      4   =   =20     Reception of a malformed packet

3) Typo

Thanks.

JP.

Begin forwarded message:

From: Internet-Drafts@ietf.org
Date: January 12, = 2007 6:50:01=20 PM EST
To: i-d-announce@ietf.org
Cc: pce@ietf.org
Subject: = [Pce] = I-D=20 ACTION:draft-ietf-pce-pcep-05.txt 

A New Internet-Draft is available from = the on-line=20 Internet-Drafts 
directories.
This draft is a work item of the Path = Computation=20 Element Working Group of the IETF.

Title : Path Computation Element (PCE)=20 communication Protocol (PCEP) - Version 1
Author(s) : J. Le Roux, J. Vasseur
Filename : = draft-ietf-pce-pcep-05.txt
Pages : 66
Date : 2007-1-12


This document specifies the Path = Computation=20 Element communication
  =20 Protocol (PCEP) for communications between a Path Computation = Client
  =20 (PCC) and a Path Computation Element (PCE), or between two=20 PCEs.
  =20 Such interactions include path computation requests and = path
  =20 computation replies as well as notifications of specific = states
  =20 related to the use of a PCE in the context of MPLS and GMPLS=20 Traffic
  =20 Engineering.  = The PCEP=20 protocol is designed to be flexible and
  =20 extensible so as to easily allow for the addition of further=20 messages
  =20 and objects, should further requirements be expressed in the=20 future.

A URL for this Internet-Draft is:
h= ttp://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-05.txt

To remove yourself from the I-D = Announcement list,=20 send a message to 
i-d-announce-request@ietf.o= rg=20 with the word unsubscribe in the body of 
the message. 
You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce 
to change your subscription = settings.

Internet-Drafts are also available by = anonymous=20 FTP. Login with the 
username "anonymous" and a password of = your e-mail=20 address. After 
logging in, type "cd internet-drafts" and = then 
"get draft-ietf-pce-pcep-05.txt".

A list of Internet-Drafts directories can = be found=20 in
http://www.ietf.org/shadow.html<= /A> 
or ftp://ftp.ietf.org/iet= f/1shadow-sites.txt

Internet-Drafts can also be obtained by=20 e-mail.

Send a message to:
mailserv@ietf.org.
In the body type:
"FILE=20 /internet-drafts/draft-ietf-pce-pcep-05.txt".


NOTE: The mail server at ietf.org can = return the=20 document in
MIME-encoded form by using the = "mpack"=20 utility.  To use = this
feature, insert the command = "ENCODING mime"=20 before the "FILE"
command.  To decode the = response(s), you=20 will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant = mail=20 readers
exhibit different behavior, = especially when=20 dealing with
"multipart" MIME messages (i.e. = documents=20 which have been split
up into multiple messages), so = check your=20 local documentation on
how to manipulate these = messages.

Below is the data which will enable a = MIME=20 compliant mail reader
implementation to automatically retrieve = the ASCII=20 version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2007-1-12152022.I-D@ietf.org= >

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

_______________________________________________
Pce mailing=20 = list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce<= BR> ------=_NextPart_000_0022_01C7395F.78231570-- --===============1419054131== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1419054131==-- From pce-bounces@lists.ietf.org Tue Jan 16 08:55:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6omr-0003u7-Rn; Tue, 16 Jan 2007 08:55:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6omq-0003tl-7B for pce@ietf.org; Tue, 16 Jan 2007 08:55:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6omn-0003l0-2Z for pce@ietf.org; Tue, 16 Jan 2007 08:55:40 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 16 Jan 2007 05:55:36 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0GDtaqF027095 for ; Tue, 16 Jan 2007 05:55:36 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0GDtCiS013006 for ; Tue, 16 Jan 2007 05:55:36 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 08:55:26 -0500 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 08:55:25 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <4F097617-16CD-417F-A5CF-8B60C67B942A@cisco.com> References: From: JP Vasseur Date: Tue, 16 Jan 2007 08:55:24 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 16 Jan 2007 13:55:25.0867 (UTC) FILETIME=[F93A8FB0:01C73975] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=32472; t=1168955736; x=1169819736; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Internet-Draft=20Boilerplate=20Reminder=20 |Sender:=20; bh=ASOFlv3esF5+lrZOJ6sOk5ysS4LbP1NgqIQRkdH5tSk=; b=R769F7471e6bjYaq/TYFPorBIGa4x0LkXEBSVoBpZunRuJfVWQYEmllqNslq+dOj0IS6eEVn spzLrV4JtMwmz4OsuuQxzah5cdl0nyaGvuNDQgqcOl/IjkfRSt8wwPkn; Authentication-Results: sj-dkim-7; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 08868c2bcdb53bddcb7cc7e7cf96b038 Cc: Subject: [Pce] Fwd: Internet-Draft Boilerplate Reminder X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2061522484==" Errors-To: pce-bounces@lists.ietf.org --===============2061522484== Content-Type: multipart/alternative; boundary=Apple-Mail-6--477520043 --Apple-Mail-6--477520043 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: IETF Secretariat > Date: January 15, 2007 11:51:16 AM EST > To: IETF Announcement list > Cc: iesg@ietf.org > Subject: Internet-Draft Boilerplate Reminder > > This message is to remind you that as of February 1, 2007 the IETF > Secretariat will no longer accept Internet-Drafts with the old > (i.e. pre RFC 4748) boilerplate. For your convenience, below is > the text of the message that was sent to the IETF Announcement > List by the IETF Chair on October 26, 2006 with Subject: Update to > Internet Draft and RFC Boilerplate. > > The IETF Secretariat. > -------------------------------------------------------------- > A small update to BCP 78 was recently approved by the IESG as RFC > 4748, > to update the boilerplate (i.e., standard legal text) in RFCs and > Internet-Drafts to recognize the IETF Trust as a rights holder, > instead of ISOC. > > The actual boilerplate changes are given below this message. > > Starting as soon as reasonably possible, all authors of Internet- > Drafts > are requested to use the new boilerplate. The RFC Editor will in any > case be inserting it in all RFCs issued from 2006-11-01. (The rights > held by ISOC in older RFCs will be administratively transferred to > the IETF Trust.) > > The public ID Nits checker already accepts I-Ds with old or new > boilerplate. The Secretariat has started accepting I-Ds with old or > new boilerplate. > > XML2RFC version 1.32 will generate the new boilerplate. > Users of I-D templates are requested to update them appropriately. > > http://www.ietf.org/ID-Checklist.html and > http://www.ietf.org/ietf/1id-guidelines.html are being updated. > > Starting December, the public ID Nits checker will issue warnings > for old > boilerplate. > > Starting February 2007, the Secretariat will refuse the old > boilerplate > in Internet-Drafts. > > We are sorry for the inconvenience, but this change cannot be avoided. > > IETF Chair > IETF Secretariat > TOOLS Team > > -------- > > Copyright Notice (required for all IETF Documents) > > (Normally placed at the end of the IETF Document.) > > NOTE: by convention, the first line of the copyright statement is > usually > placed near the beginning of each document. This must also be updated. > > OLD > "Copyright (C) The Internet Society (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > NEW > "Copyright (C) The IETF Trust (year). > > This document is subject to the rights, licenses and > restrictions > contained in BCP 78, and except as set forth therein, the > authors > retain all their rights. > > > Disclaimer (required in all IETF Documents) > > (Normally placed at the end of the IETF Document after the > copyright > notice.) > > > OLD > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY > THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY > RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE." > > > NEW > "This document and the information contained herein are provided > on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, > THE > IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL > WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY > WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT > INFRINGE > ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR > FITNESS > FOR A PARTICULAR PURPOSE." > > Exceptions > > In MIB modules, PIB modules and similar material commonly > extracted from IETF Documents, except for material that is being > placed under IANA maintenance, the following abbreviated notice > shall be included in the body of the material that will be > extracted in lieu of the notices otherwise required by > Section 5: > > OLD > "Copyright (C) The Internet Society . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > NEW > "Copyright (C) The IETF Trust . This version of > this MIB module is part of RFC XXXX; see the RFC itself for > full legal notices." > > When the MIB or PIB module is the initial version of a module > that > is to be maintained by the IANA, the following abbreviated > notice > shall be included: > > OLD > "Copyright (C) The Internet Society . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > NEW > "Copyright (C) The IETF Trust . The initial > version of this MIB module was published in RFC XXXX; for > full > legal notices see the RFC itself. Supplementary information > may be available at: > http://www.ietf.org/copyrights/ianamib.html." > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-6--477520043 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = IETF Secretariat <ietf-secretariat@ietf.org>= ;
Date: January 15, 2007 11:51:16 AM = EST
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: = Internet-Draft Boilerplate Reminder=A0

This = message is to remind you that as of February 1, 2007 the IETF
Secretariat will no longer accept Internet-Drafts = with the old=A0
(i.e. pre RFC 4748) boilerplate.=A0 For your convenience, below = is=A0
the text of the message that was sent to the IETF = Announcement=A0
List by the IETF Chair on October 26, 2006 with = Subject: Update to
Internet Draft and RFC = Boilerplate.

The IETF Secretariat.
A small update to BCP 78 was recently approved by = the IESG as RFC 4748,=A0
to = update the boilerplate (i.e., standard legal text) in RFCs and=A0
=A0
instead = of ISOC.

The actual boilerplate changes are given below this = message.

Starting as soon as reasonably possible, all authors = of Internet-Drafts=A0
are requested to use the new boilerplate. The RFC = Editor will in any=A0
case be inserting it in all RFCs issued from = 2006-11-01. (The rights=A0
held by = ISOC in older RFCs will be administratively transferred to=A0
the IETF = Trust.)

The public ID Nits checker already accepts I-Ds with = old or new
boilerplate. The Secretariat has = started accepting I-Ds with old or=A0
new = boilerplate.

XML2RFC version 1.32 will generate the new = boilerplate.
Users of I-D templates are = requested to update them appropriately.


Starting = December, the public ID Nits checker will issue warnings for = old
boilerplate.

Starting = February 2007, the Secretariat will refuse the old boilerplate
in Internet-Drafts.

We are sorry = for the inconvenience, but this change cannot be avoided.

=A0 =A0 IETF Chair
=A0 =A0 = IETF Secretariat
=A0 =A0 TOOLS Team


Copyright Notice (required for all IETF = Documents)

=A0=A0 = (Normally placed at the end of the IETF Document.)

NOTE: by = convention, the first line of the copyright statement is = usually
placed near the beginning of = each document. This must also be updated.

OLD
=A0 =A0 =A0 = "Copyright (C) The Internet Society (year).

=A0 =A0 =A0 This document is = subject to the rights, licenses and restrictions
=A0 =A0 =A0 = contained in BCP 78, and except as set forth therein, the = authors
=A0 =A0 =A0 retain all their = rights.

NEW
=A0 =A0 =A0 "Copyright (C) The = IETF Trust (year).
=A0 =A0 =A0 This document is = subject to the rights, licenses and restrictions
=A0 =A0 =A0 = contained in BCP 78, and except as set forth therein, the = authors
=A0 =A0 =A0 retain all their = rights.



=A0=A0 (Normally placed at the = end of the IETF Document after the copyright
=A0=A0 = notice.)


=A0 =A0 =A0 "This document and = the information contained herein are provided
=A0 =A0 =A0 = on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION = HE/SHE
=A0 =A0 =A0 REPRESENTS OR IS = SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
=A0 =A0 =A0 = THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL = WARRANTIES,
=A0 =A0 =A0 EXPRESS OR IMPLIED, = INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
=A0 =A0 =A0 = THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS = OR
=A0 =A0 =A0= ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR = A
=A0 =A0 =A0= PARTICULAR PURPOSE."


NEW
=A0 =A0 =A0 "This document and = the information contained herein are provided
=A0 =A0 =A0 = on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION = HE/SHE
=A0 =A0 =A0 REPRESENTS OR IS = SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE=A0
=A0 =A0 =A0 IETF TRUST AND THE = INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
=A0 =A0 =A0 = WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO = ANY
=A0 =A0 =A0 WARRANTY THAT THE USE = OF THE INFORMATION HEREIN WILL NOT INFRINGE
=A0 =A0 =A0 ANY RIGHTS OR ANY = IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
=A0 =A0 =A0 = FOR A PARTICULAR PURPOSE."

Exceptions

=A0 =A0 =A0 In MIB modules, PIB = modules and similar material commonly
=A0 =A0 =A0 extracted from IETF = Documents, except for material that is being
=A0 =A0 =A0 = placed under IANA maintenance, the following abbreviated = notice
=A0 =A0 =A0 shall be included in = the body of the material that will be
=A0 =A0 =A0 extracted in lieu of = the notices otherwise required by Section 5:

=A0=A0 =A0 =A0 =A0 "Copyright (C) = The Internet Society <year>.=A0= This version of
=A0=A0 =A0 =A0 =A0 this MIB = module is part of RFC XXXX; see the RFC itself for
=A0=A0 =A0 =A0 = =A0 full legal notices."

NEW
=A0=A0 =A0 =A0 =A0 "Copyright (C) = The IETF Trust <year>.=A0 = This version of
=A0=A0 =A0 =A0 =A0 this MIB = module is part of RFC XXXX; see the RFC itself for
=A0=A0 =A0 =A0 = =A0 full legal notices."

=A0 =A0 =A0 When the MIB or PIB = module is the initial version of a module that
=A0 =A0 =A0 = is to be maintained by the IANA, the following abbreviated = notice
=A0 =A0 =A0 shall be = included:

OLD
=A0=A0 =A0 =A0 =A0 "Copyright (C) = The Internet Society <year>.=A0= The initial
=A0=A0 =A0 =A0 =A0 version of = this MIB module was published in RFC XXXX; for full
=A0=A0 =A0 =A0 = =A0 legal notices see the RFC itself.=A0 Supplementary = information
=A0=A0 =A0 =A0 =A0 may be = available at:

NEW
=A0=A0 =A0 =A0 =A0 "Copyright (C) = The IETF Trust <year>.=A0 = The initial
=A0=A0 =A0 =A0 =A0 version of = this MIB module was published in RFC XXXX; for full
=A0=A0 =A0 =A0 = =A0 legal notices see the RFC itself.=A0 Supplementary = information
=A0=A0 =A0 =A0 =A0 may be = available at:

IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce =
= --Apple-Mail-6--477520043-- --===============2061522484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2061522484==-- From pce-bounces@lists.ietf.org Tue Jan 16 16:36:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vyC-0002a3-Qq; Tue, 16 Jan 2007 16:35:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vyB-0002Z5-GJ for pce@ietf.org; Tue, 16 Jan 2007 16:35:51 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vy9-0001wt-1y for pce@ietf.org; Tue, 16 Jan 2007 16:35:51 -0500 Received: from pc6 (1Cust63.tnt30.lnd3.gbr.da.uu.net [62.188.122.63]) by ranger.systems.pipex.net (Postfix) with SMTP id D84B4E00024B; Tue, 16 Jan 2007 21:35:43 +0000 (GMT) Message-ID: <05e201c739ad$c43854e0$0601a8c0@pc6> From: "tom.petch" To: "JP Vasseur" , References: Subject: Re: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Date: Tue, 16 Jan 2007 21:26:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org I think that this draft should start from a broader perspective of what management is before getting into what I see as the details, especially if the intent is to roll it out across other WG. I think that that is particularly important in PCE because of the specialised usage of the term management that may crop up (as in the individual ccamp I-D that was entitled 'GMPLS Signaling Extensions for the Transfer of Ownership of Label Switched Paths Between the Management and Control Planes' which is not a use of the word management that I expect many in the IETF - but not other SDOs - outside these working groups would recognise). I might use a model of management as made up of:- Security, Accounting, Configuration, Fault, Performance; of which, Security is already accounted for, Accounting is out of scope and the remaining detail items are structured under one of the other three. I am concerned that, without a paragraph or two of overview along these lines, the wood will be lost amongst the trees. Tom Petch ----- Original Message ----- From: "JP Vasseur" To: Cc: "Dan ((Dan)) Romascanu" Sent: Wednesday, January 03, 2007 7:12 PM Subject: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt > Dear WG, > > The idea of adding a Manageability section to IDs was first > introduced by Adrian and discussed at IETF-65 Dallas March 2006 (for > reference, see the WG minutes) since then two revisions of draft- > farrel-pce-manageability-requirements have been published based on > the comments received from members of the PCE WG and OPS ADs. > > My recollection of the discussions about this ID is a general good > support from members of the PCE WG and OPS AD (thanks to Dan for his > help). The were some concerns from Lou that have been addressed in > the latest revision of the draft. > > Furthermore, there are several IDs in the works for which the authors > agreed to add a manageability section and "experiment" the process > that may have to be tuned as we'll move forward. > > Because, this ID does have some implication on (current and future) > PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG document. > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 17 11:54:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7E3E-0006e5-UO; Wed, 17 Jan 2007 11:54:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7E3D-0006bs-JR for pce@ietf.org; Wed, 17 Jan 2007 11:54:15 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7E3B-0006Yq-Lk for pce@ietf.org; Wed, 17 Jan 2007 11:54:15 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 17:54:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Date: Wed, 17 Jan 2007 17:54:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt Thread-Index: Acc2gBKpX0Q7UQFkTZCeSvIK51ZnQQDzVBUw From: "STEPHAN Emile RD-CORE-LAN" To: , "Romascanu, Dan \(Dan\)" X-OriginalArrivalTime: 17 Jan 2007 16:54:06.0071 (UTC) FILETIME=[1961A070:01C73A58] X-Spam-Score: 0.2 (/) X-Scan-Signature: 489500194134bea022a3070ad86cad76 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0127835345==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0127835345== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73A58.18D9B316" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73A58.18D9B316 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I support adopting this ID as a WG document. =20 As the editor of the PCE TC MIB and of the PCE DISC MIB I have de facto = experimented it and consider that a manageability section should be = added to any I-D: It permits the editor to start the editing earlier than previously; It gives straight forward directions to the editors and weighs clearly = the management options; The scope of theses sections is wider than MIB editing and covers any = kind of management interfaces; As MIB editing is a real mystery for protocols geeks, this draft = provides them with guidance to extract and to structure the = manageability requirements of the protocol they are specifying. =20 Regards Emile =20 =20 =20 =20 ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : vendredi 12 janvier 2007 20:29 =C0 : pce@ietf.org Objet : Fwd: [Pce] WG Feed-back required = ondraft-farrel-pce-manageability-requirements-02.txt =20 Dear WG, =20 We had so far a few (and positive) feed-backs, it would be nice to get = more feed-back on this (in particular several of the usual contributors = haven't expressed their opinion). =20 Thanks. =20 Happy New Year to all of you. =20 JP. =20 Begin forwarded message: From: JP Vasseur Date: January 3, 2007 1:12:59 PM EST To: pce@ietf.org Cc: "Dan \(\(Dan\)\) Romascanu" Subject: [Pce] WG Feed-back required on = draft-farrel-pce-manageability-requirements-02.txt =20 Dear WG, =20 The idea of adding a Manageability section to IDs was first introduced = by Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see = the WG minutes) since then two revisions of = draft-farrel-pce-manageability-requirements have been published based on = the comments received from members of the PCE WG and OPS ADs. =20 My recollection of the discussions about this ID is a general good = support from members of the PCE WG and OPS AD (thanks to Dan for his = help). The were some concerns from Lou that have been addressed in the = latest revision of the draft. =20 Furthermore, there are several IDs in the works for which the authors = agreed to add a manageability section and "experiment" the process that = may have to be tuned as we'll move forward. =20 Because, this ID does have some implication on (current and future) PCE = WG IDs, I'd welcome feed-back on adopting this ID as a WG document. =20 Thanks. =20 JP. =20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01C73A58.18D9B316 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I support adopting this ID as a WG document.

 

As the editor of the PCE TC MIB and of the PCE DISC MIB I have de facto = experimented it and consider that a manageability = section should be added to any I-D:

It permits the editor to start the = editing earlier than previously;

It gives straight forward directions = to the editors and weighs clearly the management = options;

The scope of theses sections is = wider than MIB editing and covers any kind of management = interfaces;

As MIB editing is a real mystery for protocols geeks, this draft provides them with guidance to extract and = to structure the manageability requirements of the protocol they are = specifying.

 

Regards

Emile

 

 

 

 

De : JP = Vasseur [mailto:jvasseur@cisco.com]
Envoy=E9 : vendredi = 12 janvier 2007 20:29
=C0 : = pce@ietf.org
Objet : Fwd: [Pce] = WG Feed-back required = ondraft-farrel-pce-manageability-requirements-02.txt

 

Dear WG,

 

We had so far a few (and positive) feed-backs, it would be nice = to get more feed-back on this (in particular several of the usual contributors = haven't expressed their opinion).

 

Thanks.

 

Happy New Year to all of you.

 

JP.

 

Begin forwarded message:



From: JP Vasseur <jvasseur@cisco.com>

Date: January 3, 2007 1:12:59 PM = EST

Cc: "Dan \(\(Dan\)\) Romascanu" <dromasca@avaya.com>

Subject: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt=

 

Dear WG,

 

The idea of adding a Manageability section to IDs was first = introduced by Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see = the WG minutes) since then two revisions of draft-farrel-pce-manageability-requirements have been published based on = the comments received from members of the PCE WG and OPS = ADs.

 

My recollection of the discussions about this ID is a general = good support from members of the PCE WG and OPS AD (thanks to Dan for his = help). The were some concerns from Lou that have been addressed in the latest = revision of the draft.

 

Furthermore, there are several IDs in the works for which the = authors agreed to add a manageability section and "experiment" the = process that may have to be tuned as we'll move = forward.

 

Because, this ID does have some implication on (current and = future) PCE WG IDs, I'd welcome feed-back on adopting this ID as a WG = document.

 

Thanks.

 

JP.

 

_______________________________________________=

Pce mailing list

 

------_=_NextPart_001_01C73A58.18D9B316-- --===============0127835345== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0127835345==-- From pce-bounces@lists.ietf.org Wed Jan 17 15:50:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HjS-0004tg-JK; Wed, 17 Jan 2007 15:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HjO-0004sZ-Ag; Wed, 17 Jan 2007 15:50:02 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HjO-0002og-1n; Wed, 17 Jan 2007 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 03D65329FF; Wed, 17 Jan 2007 20:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7HjN-0004GV-SG; Wed, 17 Jan 2007 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Jan 2007 15:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-brpc-03.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter- domain Traffic Engineering Label Switched Paths Author(s) : J. Vasseur, et al. Filename : draft-ietf-pce-brpc-03.txt Pages : 16 Date : 2007-1-17 The ability to compute constrained shortest Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems) has been identified as a key requirement . This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) in order to compute such inter-domain shortest constraint paths along a determined sequence of domains, using a backward recursive path computation technique while preserving confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-brpc-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-brpc-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-17134533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-brpc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-brpc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-17134533.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Jan 17 16:51:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7IgF-000785-Go; Wed, 17 Jan 2007 16:50:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7IgE-000780-Pm for pce@ietf.org; Wed, 17 Jan 2007 16:50:50 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7IgD-0003JQ-9S for pce@ietf.org; Wed, 17 Jan 2007 16:50:50 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0HLopoc016555; Wed, 17 Jan 2007 22:50:51 +0100 In-Reply-To: To: "STEPHAN Emile RD-CORE-LAN" Subject: RE: [Pce] WG Feed-back required ondraft-farrel-pce-manageability-requirements-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Wed, 17 Jan 2007 22:50:55 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/17/2007 22:50:44, Serialize complete at 01/17/2007 22:50:44 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "Romascanu, Dan \(Dan\)" , pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org stephan > As MIB editing is a real mystery for protocols geeks how did you come to that observation ? - d. "STEPHAN Emile RD-CORE-LAN" 17/01/2007 17:54 =20 To: , "Romascanu, Dan \(Dan\)"=20 cc:=20 Subject: RE: [Pce] WG Feed-back required=20 ondraft-farrel-pce-manageability-requirements-02.txt Hi, =20 I support adopting this ID as a WG document. =20 As the editor of the PCE TC MIB and of the PCE DISC MIB I have de facto=20 experimented it and consider that a manageability section should be added=20 to any I-D: It permits the editor to start the editing earlier than previously; It gives straight forward directions to the editors and weighs clearly the = management options; The scope of theses sections is wider than MIB editing and covers any kind = of management interfaces; As MIB editing is a real mystery for protocols geeks, this draft provides=20 them with guidance to extract and to structure the manageability=20 requirements of the protocol they are specifying. =20 Regards Emile =20 =20 =20 =20 De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : vendredi 12 janvier 2007 20:29 =C0 : pce@ietf.org Objet : Fwd: [Pce] WG Feed-back required=20 ondraft-farrel-pce-manageability-requirements-02.txt =20 Dear WG, =20 We had so far a few (and positive) feed-backs, it would be nice to get=20 more feed-back on this (in particular several of the usual contributors=20 haven't expressed their opinion). =20 Thanks. =20 Happy New Year to all of you. =20 JP. =20 Begin forwarded message: From: JP Vasseur Date: January 3, 2007 1:12:59 PM EST To: pce@ietf.org Cc: "Dan \(\(Dan\)\) Romascanu" Subject: [Pce] WG Feed-back required on=20 draft-farrel-pce-manageability-requirements-02.txt =20 Dear WG, =20 The idea of adding a Manageability section to IDs was first introduced by=20 Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see the=20 WG minutes) since then two revisions of=20 draft-farrel-pce-manageability-requirements have been published based on=20 the comments received from members of the PCE WG and OPS ADs. =20 My recollection of the discussions about this ID is a general good support = from members of the PCE WG and OPS AD (thanks to Dan for his help). The=20 were some concerns from Lou that have been addressed in the latest=20 revision of the draft. =20 Furthermore, there are several IDs in the works for which the authors=20 agreed to add a manageability section and "experiment" the process that=20 may have to be tuned as we'll move forward. =20 Because, this ID does have some implication on (current and future) PCE WG = IDs, I'd welcome feed-back on adopting this ID as a WG document. =20 Thanks. =20 JP. =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 18 09:36:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YN4-0006l2-PY; Thu, 18 Jan 2007 09:36:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7YN3-0006kv-PS for pce@ietf.org; Thu, 18 Jan 2007 09:36:05 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7YMm-0008Ia-JU for pce@ietf.org; Thu, 18 Jan 2007 09:36:05 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1H7YMy-0004Yf-00 for pce@ietf.org; Thu, 18 Jan 2007 14:36:00 +0000 Received: from your029b8cecfe ([217.158.132.177] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 14:35:41 +0000 Message-ID: <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> From: "Adrian Farrel" To: "tom.petch" , "JP Vasseur" , References: <05e201c739ad$c43854e0$0601a8c0@pc6> Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt Date: Thu, 18 Jan 2007 14:35:21 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 18 Jan 2007 14:35:42.0603 (UTC) FILETIME=[EE8AB5B0:01C73B0D] X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Tom, >I think that this draft should start from a broader perspective of what > management is before getting into what I see as the details, especially if > the > intent is to roll it out across other WG. I think that that is > particularly > important in PCE because of the specialised usage of the term management > that > may crop up (as in the individual ccamp I-D that was entitled > 'GMPLS Signaling Extensions for the Transfer of Ownership of Label > Switched > Paths Between the Management and Control Planes' > which is not a use of the word management that I expect many in the IETF - > but > not other SDOs - outside these working groups would recognise). Hmmm. I'm a bit disappointed if folks don't recognise the term Management Plane, but I believe you. Yes, I see no reason why a future revision of this I-D within the working group should not include a summary of FCAPS to set the context and explain why there are requirements. > I might use a model of management as made up of:- > Security, Accounting, Configuration, Fault, Performance; > of which, Security is already accounted for, Accounting is out of scope > and the > remaining detail items are structured under one of the other three. > > I am concerned that, without a paragraph or two of overview along these > lines, > the wood will be lost amongst the trees. I guess you should see this as iterating towards the right thing. We started with a baren plane with no trees. Now we have a lot of trees. You would like to be able to perform some taxonomy and dendritic analysis - fair enough. We will get there. But it sounds like you welcome the general principle, and that we can use this I-D as a basis for WG progress. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Jan 18 19:55:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7i1O-000577-V3; Thu, 18 Jan 2007 19:54:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7i1N-000572-Is for pce@ietf.org; Thu, 18 Jan 2007 19:54:21 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7i1L-0003rf-61 for pce@ietf.org; Thu, 18 Jan 2007 19:54:21 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jan 2007 16:54:19 -0800 X-IronPort-AV: i="4.13,206,1167638400"; d="scan'208,217"; a="51124534:sNHT97042456" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0J0sIXH030663 for ; Thu, 18 Jan 2007 19:54:18 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0J0sIVT028071 for ; Thu, 18 Jan 2007 19:54:18 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 19:54:18 -0500 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 19:54:18 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: From: JP Vasseur Date: Thu, 18 Jan 2007 19:54:14 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Jan 2007 00:54:18.0108 (UTC) FILETIME=[591B53C0:01C73B64] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8689; t=1169168058; x=1170032058; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Draft=20Agenda=20IETF-68 |Sender:=20 |To:=20pce@ietf.org; bh=/x34MZI9X+VIaiJWIaTU1t0bo2iFZ+b5fc30H/GU8LQ=; b=e9G+9vn7DXSw0oqRtYP99UjfaPrx6wNjGv9Ycr8VXE6nSdJZcDMwgx6jsL0+mdTEcuYqZeCS 2ZgVQnYl+USBhyx4f+Gqyjof4kAQ54jkjXUVpAKJEexzwIm/whgdqYvu; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Subject: [Pce] Draft Agenda IETF-68 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1293623593==" Errors-To: pce-bounces@lists.ietf.org --===============1293623593== Content-Type: multipart/alternative; boundary=Apple-Mail-58--265189177 --Apple-Mail-58--265189177 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed WEDNESDAY, March 21, 2007 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I Madrid/Vienna INT trill Transparent Interconnection of Lots of Links WG Congress I OPS mboned MBONE Deployment WG 1130-1300 Break 1300-1500 Afternoon Session I Congress I RAI ecrit Emergency Context Resolution with Internet Technologies WG Congress III RTG pce Path Computation Element WG Grand Ballroom TSV rmt Reliable Multicast Transport WG 1610-1700 Afternoon Beverage and Snack Break I - 1510-1610 Afternoon Session II Madrid/Vienna INT mip4 Mobility for IPv4 WG --Apple-Mail-58--265189177 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
WEDNESDAY, March 21, = 2007
0800-1700 IETF Registration = -
0800-0900 Continental Breakfast -
0900-1130 Morning = Session I
Madrid/Vienna INT trill Transparent Interconnection of Lots of Links = WG
Congress I OPS mboned MBONE Deployment WG
1130-1300 Break
1300-1500 Afternoon Session = I
Congress I RAI ecrit Emergency Context Resolution with Internet Technologies = WG
Congress III RTG pce Path Computation Element WG
Grand = Ballroom TSV rmt Reliable Multicast Transport WG

1610-1700 Afternoon Beverage and Snack Break = I -
1510-1610 Afternoon Session II
Madrid/Vienna INT mip4 Mobility for IPv4 WG

= --Apple-Mail-58--265189177-- --===============1293623593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1293623593==-- From pce-bounces@lists.ietf.org Fri Jan 19 04:50:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qOD-0004we-W6; Fri, 19 Jan 2007 04:50:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7qOC-0004wW-Ge for pce@ietf.org; Fri, 19 Jan 2007 04:50:28 -0500 Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7qOA-0007yN-3r for pce@ietf.org; Fri, 19 Jan 2007 04:50:28 -0500 Received: from pc6 (1Cust125.tnt1.lnd4.gbr.da.uu.net [62.188.130.125]) by blaster.systems.pipex.net (Postfix) with SMTP id BBCA7E0001DF; Fri, 19 Jan 2007 09:50:16 +0000 (GMT) Message-ID: <004101c73ba6$b40b5540$0601a8c0@pc6> From: "tom.petch" To: "Adrian Farrel" , "JP Vasseur" , References: <05e201c739ad$c43854e0$0601a8c0@pc6> <090f01c73b0d$ea029580$0a23fea9@your029b8cecfe> Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt Date: Thu, 18 Jan 2007 19:15:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "Dan \(\(Dan\)\) Romascanu" X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Yes I support this being adopted as a WG I-D. Tom Petch ----- Original Message ----- From: "Adrian Farrel" To: "tom.petch" ; "JP Vasseur" ; Cc: "Dan ((Dan)) Romascanu" Sent: Thursday, January 18, 2007 3:35 PM Subject: Re: [Pce] WG Feed-back requiredondraft-farrel-pce-manageability-requirements-02.txt > Hi Tom, > > >I think that this draft should start from a broader perspective of what > > management is before getting into what I see as the details, especially if > > the > > intent is to roll it out across other WG. I think that that is > > particularly > > important in PCE because of the specialised usage of the term management > > that > > may crop up (as in the individual ccamp I-D that was entitled > > 'GMPLS Signaling Extensions for the Transfer of Ownership of Label > > Switched > > Paths Between the Management and Control Planes' > > which is not a use of the word management that I expect many in the IETF - > > but > > not other SDOs - outside these working groups would recognise). > > Hmmm. > I'm a bit disappointed if folks don't recognise the term Management Plane, > but I believe you. > > Yes, I see no reason why a future revision of this I-D within the working > group should not include a summary of FCAPS to set the context and explain > why there are requirements. > > > I might use a model of management as made up of:- > > Security, Accounting, Configuration, Fault, Performance; > > of which, Security is already accounted for, Accounting is out of scope > > and the > > remaining detail items are structured under one of the other three. > > > > I am concerned that, without a paragraph or two of overview along these > > lines, > > the wood will be lost amongst the trees. > > I guess you should see this as iterating towards the right thing. We started > with a baren plane with no trees. Now we have a lot of trees. You would like > to be able to perform some taxonomy and dendritic analysis - fair enough. We > will get there. > > But it sounds like you welcome the general principle, and that we can use > this I-D as a basis for WG progress. > > Thanks, > Adrian > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 19 07:25:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7soJ-00014B-PQ; Fri, 19 Jan 2007 07:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7soJ-000146-1o for pce@ietf.org; Fri, 19 Jan 2007 07:25:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7soH-0005Lg-PC for pce@ietf.org; Fri, 19 Jan 2007 07:25:35 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2007 04:25:30 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0JCPTCN017297; Fri, 19 Jan 2007 04:25:29 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0JCPTnF006160; Fri, 19 Jan 2007 04:25:29 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 07:25:29 -0500 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 07:25:28 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <66EB8C4A-FA94-40A7-AEC1-1D86C89C6A74@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Adrian Farrel , pce@ietf.org From: JP Vasseur Date: Fri, 19 Jan 2007 07:25:26 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Jan 2007 12:25:28.0680 (UTC) FILETIME=[E77E6E80:01C73BC4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=203; t=1169209530; x=1170073530; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20WG=20ID=3A=20draft-ietf-pce-manageability-requirements- 00.txt |Sender:=20; bh=g81NZlhBtLSkZbHREvXo32khH/ESeJQLblFesCTXH+s=; b=a4uZE/0BOQhlPnsxTC+oOB6AJ4Z7+suO7QLjuYef1NiVhZYRR4kPfzaXjBqzX9V5qIQDjq5b trHQZZ9pc2UCkz5L8sM+dOeKg0nbYKgPT0VW4UvcbDt2SuPliMtKUduO; Authentication-Results: sj-dkim-6; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Pce] New WG ID: draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We had a good support to adopt draft-farrel-pce-manageability- requirements-02.txt as a WG item. Adrian, please post as draft-ietf-pce-manageability- requirements-02.txt ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 19 07:28:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sqg-0001fZ-8I; Fri, 19 Jan 2007 07:28:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7sqe-0001eq-MD for pce@ietf.org; Fri, 19 Jan 2007 07:28:00 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7sqd-0005qD-9r for pce@ietf.org; Fri, 19 Jan 2007 07:28:00 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2007 04:27:59 -0800 X-IronPort-AV: i="4.13,210,1167638400"; d="scan'208,217"; a="51145781:sNHT84577948" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0JCRx8l028906; Fri, 19 Jan 2007 07:27:59 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0JCRwOA025357; Fri, 19 Jan 2007 07:27:58 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 07:27:58 -0500 Received: from [10.86.104.186] ([10.86.104.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 07:27:58 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: Adrian Farrel , pce@ietf.org Message-Id: <7621A927-E663-4E2C-AF9C-3ADFE5F58838@cisco.com> References: <66EB8C4A-FA94-40A7-AEC1-1D86C89C6A74@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] New WG ID: draft-ietf-pce-manageability-requirements-00.txt Date: Fri, 19 Jan 2007 07:27:56 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 19 Jan 2007 12:27:58.0115 (UTC) FILETIME=[40906730:01C73BC5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5042; t=1169209679; x=1170073679; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20New=20WG=20ID=3A=20draft-ietf-pce-manageabil ity-requirements-00.txt |Sender:=20 |To:=20Adrian=20Farrel=20,=20pce@ietf.org; bh=zbQKKZYpcM7q6FraOdXUS/q34y1mXj3UVKMFrYZ3eHk=; b=a2TvlOOGFovEan2HDK4WFuyIXpi/oi1BfSqNl2W5R/IloMGfxOEjn7cvuLrRTAPE/BWxg1iY S2PJzAnpBM482YvslvA3RTkHzTwnU+0ph2fxHngYpUofreOy7HCs1622; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1896725795==" Errors-To: pce-bounces@lists.ietf.org --===============1896725795== Content-Type: multipart/alternative; boundary=Apple-Mail-59--223568046 --Apple-Mail-59--223568046 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I meant post as Adrian, please post as draft-ietf-pce-manageability- requirements-00.txt of course. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: January 19, 2007 7:25:26 AM EST > To: Adrian Farrel , pce@ietf.org > Subject: [Pce] New WG ID: draft-ietf-pce-manageability- > requirements-00.txt > > Hi, > > We had a good support to adopt draft-farrel-pce-manageability- > requirements-02.txt as a WG item. > Adrian, please post as draft-ietf-pce-manageability- > requirements-02.txt ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-59--223568046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 I meant post as=A0Adrian, please = post as draft-ietf-pce-manageability-requirements-00.txt of = course.

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = January 19, 2007 7:25:26 AM EST
To: Adrian = Farrel <adrian@olddog.co.uk>, pce@ietf.org
Subject: = [Pce] New WG ID: = draft-ietf-pce-manageability-requirements-00.txt


We had a good support to adopt = draft-farrel-pce-manageability-requirements-02.txt as a WG = item.
Adrian, please post as = draft-ietf-pce-manageability-requirements-02.txt ?


JP.

Pce mailing list
=

= --Apple-Mail-59--223568046-- --===============1896725795== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1896725795==-- From pce-bounces@lists.ietf.org Fri Jan 19 08:01:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tNT-0003jC-UM; Fri, 19 Jan 2007 08:01:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7tNS-0003io-Dg for Pce@lists.ietf.org; Fri, 19 Jan 2007 08:01:54 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7tNR-0003RC-26 for Pce@lists.ietf.org; Fri, 19 Jan 2007 08:01:54 -0500 Received: by ug-out-1314.google.com with SMTP id k3so418984ugf for ; Fri, 19 Jan 2007 05:01:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R4MYW7+rdUMgeIvrV85itkSjUk9M34vz6GjExasqwoZW4nbK36Wq4g12MN5BRqz+x/ZY1WRP0XHxctwYFzxaBNG/yMpJt6hfAjPC81VwTVzIAnwIdnD/Ib6CUum8WU0cT3abv0X12TDgp/GZ08DkEfTmICWLoxsfqhySs8VvRYo= Received: by 10.82.135.13 with SMTP id i13mr504527bud.1169211711641; Fri, 19 Jan 2007 05:01:51 -0800 (PST) Received: by 10.82.186.18 with HTTP; Fri, 19 Jan 2007 05:01:51 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 08:01:51 -0500 From: "Matthew R. Meyer" To: "JP Vasseur" , Pce@lists.ietf.org Subject: Re: [Pce] WG Feed-back required on draft-farrel-pce-manageability-requirements-02.txt In-Reply-To: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <54E8FBBA-2663-4745-AF18-539D10613C0B@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: matthew.r.meyer@gmail.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org JP, Adrian, WG I strongly support this document as PCE WG item and for general WG draft use. I wonder if in the 3.x section it might be useful to optionally break out a legacy protocol interworking & native backward compatibility implications subsection to briefly call attention to their management problem spaces. I see the topic could fall under '3.5 Requirements on Other Protocols' however I perceive from the text of that section that the focus is really upon protocols that are impacted or required by the proposed protocol, not necessarily older cousins that perform a similar function and might pose a manageability problem worth reflecting upon. Matthew Meyer On 1/12/07, JP Vasseur wrote: > Dear WG, > > We had so far a few (and positive) feed-backs, it would be nice to get more > feed-back on this (in particular several of the usual contributors haven't > expressed their opinion). > > Thanks. > > Happy New Year to all of you. > > JP. > > Begin forwarded message: > > From: JP Vasseur > Date: January 3, 2007 1:12:59 PM EST > To: pce@ietf.org > Cc: "Dan \(\(Dan\)\) Romascanu" > Subject: [Pce] WG Feed-back required on > draft-farrel-pce-manageability-requirements-02.txt > > > Dear WG, > > The idea of adding a Manageability section to IDs was first introduced by > Adrian and discussed at IETF-65 Dallas March 2006 (for reference, see the WG > minutes) since then two revisions of > draft-farrel-pce-manageability-requirements have been > published based on the comments received from members of the PCE WG and OPS > ADs. > > My recollection of the discussions about this ID is a general good support > from members of the PCE WG and OPS AD (thanks to Dan for his help). The were > some concerns from Lou that have been addressed in the latest revision of > the draft. > > Furthermore, there are several IDs in the works for which the authors agreed > to add a manageability section and "experiment" the process that may have to > be tuned as we'll move forward. > > Because, this ID does have some implication on (current and future) PCE WG > IDs, I'd welcome feed-back on adopting this ID as a WG document. > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 23 16:23:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9ScD-000880-U3; Tue, 23 Jan 2007 15:51:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9SbD-0006Tt-7q; Tue, 23 Jan 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9SbB-0003a0-KR; Tue, 23 Jan 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B28B72ACDA; Tue, 23 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9Sag-00044l-Ep; Tue, 23 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 23 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-manageability-requirements-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Requirements for Manageability Sections in PCE Working Group Drafts Author(s) : A. Farrel Filename : draft-ietf-pce-manageability-requirements-00.txt Pages : 8 Date : 2007-1-23 It has often been the case that manageability considerations have been retrofitted to protocols. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the requirement for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-manageability-requirements-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-manageability-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-manageability-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-23133256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-manageability-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-manageability-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-23133256.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --NextPart-- From pce-bounces@lists.ietf.org Wed Jan 24 11:38:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9l8S-0001AL-O2; Wed, 24 Jan 2007 11:38:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9l8R-000172-6n for pce@ietf.org; Wed, 24 Jan 2007 11:38:07 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9l8P-0007WD-Ie for pce@ietf.org; Wed, 24 Jan 2007 11:38:07 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Jan 2007 11:38:06 -0500 X-IronPort-AV: i="4.13,233,1167627600"; d="scan'208,217"; a="112388903:sNHT77180184" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0OGc5n3030092 for ; Wed, 24 Jan 2007 11:38:05 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0OGc5VT013744 for ; Wed, 24 Jan 2007 11:38:05 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 11:38:05 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 11:38:04 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <356DCC07-5CDE-4879-95B3-D433572364E6@cisco.com> From: JP Vasseur Date: Wed, 24 Jan 2007 11:38:04 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 24 Jan 2007 16:38:04.0539 (UTC) FILETIME=[0527BCB0:01C73FD6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5761; t=1169656685; x=1170520685; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Compliance=20with=20the=20PCECP=20Requirement=20Document |Sender:=20 |To:=20pce@ietf.org; bh=5+jCNU7ZSFbT0GKvPtHU9Qlo1mg50zLmJW+pUBbJ3Gg=; b=nvz0NIRINQLt4W2B0X9prGPDBGXz9QdKn5q3EifPlbN/UMMGXL27Q/P8RZfghNAuq0iPYPdk ECse+6Brc1DDloVXzdOSz79eaaOoIP0ahK+yrEUr9KYEPeEDLHHD6fSQ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Subject: [Pce] Compliance with the PCECP Requirement Document X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1625492728==" Errors-To: pce-bounces@lists.ietf.org --===============1625492728== Content-Type: multipart/alternative; boundary=Apple-Mail-26-223440353 --Apple-Mail-26-223440353 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, As discussed in San Diego, there are still a few requirements stated in RFC 4657 that PCEP does not satisfy (see Appendix A of the PCEP ID) for which we'd like your feed-back: Appendix A The aim of this section is to list the set of requirements set forth in [RFC4657] that are not satisfied by the current revision of this document. This only concerns the requirements listed as MUST according to [RFC2119]. Here is the list of currently unsatisfied requirements: o Allow to select/prefer from advertised list of standard objective functions/options o Allow to customize objective function/options o Support "unsynchronized" & "synchronized" objective functions Comment> The Proposal is to work on this item in the context of a separate ID that will cover the set of requirements, IGP PCED extensions and PCEP extensions since these functions are not required for the base protocol specification. o Protocol recovery support resynchronization of information & requests between sender & receiver. Comment> We can see two potential avenues here: 1) Upon loosing the PCEP session, pending requests are considered as lost, and the PCC has the initiative to resend the set of pending requests. The main benefit of such approach is to be extremely simple and IMO well suited to most of the cases since path computation requests are not likely to be pending for a long period of time. 2) Specify a set of re-synchronization procedures. We came up with similar solutions for many other protocols (in very different contexts and set of requirements) and our experience clearly tells us that this will likely to be a fairly complex issue. We could see some benefit in statefull contexts though; thus if such functions is required for particular context, we would propose not to include in the base protocol specification and leave it for further should the WG think that such function will be required. Thanks for your feed-back. JP, Jean-Louis et al. --Apple-Mail-26-223440353 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Dear WG,

As discussed in San Diego, = there are still a few requirements stated in RFC 4657 that PCEP does not = satisfy (see Appendix A of the PCEP ID) for which we'd like your = feed-back:


Appendix A

=A0 =A0The aim of this section is to list = the set of requirements set forth
=A0=A0 in = [RFC4657] that are not satisfied by the current revision of = this
=A0=A0 document.=A0 This only concerns the = requirements listed as MUST
=A0=A0 according to = [RFC2119].

=A0=A0 Here is the = list of currently unsatisfied requirements:

=A0=A0 o=A0 Allow to = select/prefer from advertised list of standard = objective
=A0 =A0 =A0 = functions/options

=A0=A0 o=A0 Allow to = customize objective function/options

=A0=A0 o=A0 Support = "unsynchronized" & "synchronized" objective = functions

Comment> The = Proposal is to work on this item in the context of a separate ID that = will cover the set of requirements, IGP PCED extensions and PCEP = extensions since these functions are not required for the base protocol = specification.

=A0=A0 o=A0 Protocol = recovery support resynchronization of information = &
=A0 =A0 =A0 requests between sender & = receiver.

Comment> We can = see two potential avenues here:
1) Upon loosing the = PCEP session, pending requests are considered as lost, and the PCC has = the initiative to resend the set of pending requests. The main benefit = of such approach is to be extremely simple and IMO well suited to most = of the cases since path computation requests are not likely to be = pending for a long period of time.
2) Specify a set of = re-synchronization procedures. We came up with similar solutions for = many other protocols (in very different contexts and set of = requirements) and our experience clearly tells us that this will likely = to be a fairly complex issue. We could see some benefit in statefull = contexts though; thus if such functions is required for particular = context, we would propose not to include in the base protocol = specification and leave it for further should the WG think that such = function will be required.

Thanks for your = feed-back.

JP, Jean-Louis et = al.
= --Apple-Mail-26-223440353-- --===============1625492728== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1625492728==-- From pce-bounces@lists.ietf.org Thu Jan 25 06:26:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2kA-0002Of-Fv; Thu, 25 Jan 2007 06:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA2k9-0002NP-2j for pce@ietf.org; Thu, 25 Jan 2007 06:26:13 -0500 Received: from gws04.hcl.in ([203.105.186.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA2k6-0001mn-2h for pce@ietf.org; Thu, 25 Jan 2007 06:26:13 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id D5168360105 for ; Thu, 25 Jan 2007 16:56:07 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id CAF58360094for ; Thu, 25 Jan 2007 16:56:07 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.14]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 16:56:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C74073.8F7A04CF" Date: Thu, 25 Jan 2007 16:51:26 +0530 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Thread-Index: Acc+aF2q8Fd5Y60rRgWGHQu/3HHy3ACCbGFQ From: "Vijayanand C - TLS, Chennai." To: X-OriginalArrivalTime: 25 Jan 2007 11:26:07.0450 (UTC) FILETIME=[9B505BA0:01C74073] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-18.9419 TC:1F TRN:62 TV:3.6.1039(14956.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: Subject: [Pce] FW: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C74073.8F7A04CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello allm We have posted a new I-D, given below. Please give your comments/suggestions on it. Regards Vijay -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =09 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-vijay-somen-pce-bgp-interas-te-path-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vijay-somen-pce-bgp-interas-te-path-01.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C74073.8F7A04CF Content-Type: application/octet-stream; name="draft-vijay-somen-pce-bgp-interas-te-path-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-vijay-somen-pce-bgp-interas-te-path-01.URL Content-Disposition: attachment; filename="draft-vijay-somen-pce-bgp-interas-te-path-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC12aWpheS1zb21lbi1wY2UtYmdwLWludGVyYXMtdGUtcGF0aC0wMS50eHQNCg== ------_=_NextPart_001_01C74073.8F7A04CF Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C74073.8F7A04CF-- From pce-bounces@lists.ietf.org Thu Jan 25 09:38:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5kB-0008Ki-Rk; Thu, 25 Jan 2007 09:38:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA5kA-0008KV-Hs for pce@ietf.org; Thu, 25 Jan 2007 09:38:26 -0500 Received: from gws04.mail.hcl.in ([203.105.186.20] helo=gws04.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA5k7-0003QN-N7 for pce@ietf.org; Thu, 25 Jan 2007 09:38:26 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id A53C436005E for ; Thu, 25 Jan 2007 20:08:21 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTP id 9A2E8360051for ; Thu, 25 Jan 2007 20:08:21 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jan 2007 20:08:20 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jan 2007 20:02:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt thread-index: Acc+aF2q8Fd5Y60rRgWGHQu/3HHy3ACJR5sQ From: "Vijayanand C - TLS, Chennai." To: X-OriginalArrivalTime: 25 Jan 2007 14:38:20.0923 (UTC) FILETIME=[75CCACB0:01C7408E] X-imss-version: 2.045 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-8.0080 TC:1F TRN:28 TV:3.6.1039(14956.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hello all, We have submitted the following I-D, please send in your comments/suggestions Regards Vijay -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, January 23, 2007 2:20 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : A BGP based method to compute inter-AS Traffic engineering Label Switched Paths with PCE Author(s) : C. Vijayanand, S. Bhattacharya Filename : draft-vijay-somen-pce-bgp-interas-te-path-01.txt Pages : 26 Date : 2007-1-22 =09 The ability to compute an optimal path for setting up Traffic=20 engineering Label Switched Paths spanning multiple autonomous=20 systems managed by different operators has been a key requirement in=20 MPLS and GMPLS networks. This document specifies a method of=20 computing inter-AS paths consisting of a list of ASes to be=20 traversed and a list of TE-Tunnels to be traversed in each AS. The=20 method described here uses BGP speakers in the PCEs of each AS to=20 distribute the inter-AS connectivity information and the TE-Tunnels=20 in each AS to its neighbors to facilitate the construction of an=20 inter-AS topology graph which can be used for computing inter-AS paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp-interas-te -path-01.txt DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its= affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have=20 received this email in error please delete it and notify the sender= immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 26 11:02:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATWw-0004EY-PY; Fri, 26 Jan 2007 11:02:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATWv-0004DG-NG for pce@ietf.org; Fri, 26 Jan 2007 11:02:21 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATWu-0003CC-73 for pce@ietf.org; Fri, 26 Jan 2007 11:02:21 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2007 11:02:20 -0500 X-IronPort-AV: i="4.13,243,1167627600"; d="scan'208,217"; a="112551831:sNHT88362752" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0QG2JCG028533 for ; Fri, 26 Jan 2007 11:02:19 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0QG2JOC010567 for ; Fri, 26 Jan 2007 11:02:19 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:02:19 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:02:19 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: <989A79F6-C80C-48ED-B536-EB3A3805D276@cisco.com> References: From: JP Vasseur Date: Fri, 26 Jan 2007 11:02:18 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Jan 2007 16:02:19.0236 (UTC) FILETIME=[5B47FA40:01C74163] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11113; t=1169827339; x=1170691339; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Internet-Drafts=20Submission=20Cutoff=20Dates=20for= 20the=2068th=20IETF=20=20Meeting=20in=20Prague,=20Czech=20Republic=20 |Sender:=20 |To:=20pce@ietf.org; bh=FL4529NpC9rTTG0sEkP7P6Ni/72B0sy5gDvyuD8mUsM=; b=ZQAFdEHoqN/oZ2aihXiOy/iRHjd8MhIRD9saHN2sbeOgzam9PympFZztfJZ192wyETw6Ba14 pC2a2vR864VsrCCOnrAwEoz8PoCXcpo4B9mFHGI2Pzm5PraEca7skvc9; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.7 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100831301==" Errors-To: pce-bounces@lists.ietf.org --===============2100831301== Content-Type: multipart/alternative; boundary=Apple-Mail-73-394093747 --Apple-Mail-73-394093747 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: January 26, 2007 12:00:02 AM EST > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF > Meeting in Prague, Czech Republic > > > There are two (2) Internet-Draft cutoff dates for the 68th > IETF Meeting in Prague, Czech Republic: > > February 26th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 26th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > February 19th at 9:00 AM ET. > > March 5th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, March 5th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 19th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 68th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_68.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-73-394093747 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

Date: January 26, 2007 12:00:02 AM = EST
To: ietf-announce@ietf.org
Subject: Internet-Drafts Submission Cutoff = Dates for the 68th IETF=A0 = Meeting in Prague, Czech Republic=A0


There are two = (2) Internet-Draft cutoff dates for the 68th=A0
IETF = Meeting in Prague, Czech Republic:

February 26th: Cutoff Date for = Initial (i.e., version -00)=A0
=A0

All initial = Internet-Drafts (version -00) must be submitted by Monday,=A0
February = 26th at 9:00 AM ET. As always, all initial submissions with a=A0
filename = beginning with "draft-ietf" must be approved by the=A0
=A0 The=A0
=A0
February 19th at 9:00 AM ET.

March = 5th: Cutoff Date for Revised (i.e., version -01 and higher)=A0
=A0

All revised = Internet-Drafts (version -01 and higher) must be submitted=A0
by = Monday, March 5th at 9:00 AM ET.

Initial and revised = Internet-Drafts received after their respective=A0
cutoff = dates will not be made available in the Internet-Drafts=A0
=A0
AM ET, when Internet-Draft posting resumes.=A0 Please do not wait until=A0
the last = minute to submit.

Thank you for your understanding and cooperation. If = you have any=A0
questions or concerns, then please send a message = to=A0
internet-drafts@ietf.org.

The IETF = Secretariat

FYI: The Internet-Draft cutoff dates as well as = other significant dates
for the 68th = IETF Meeting can be found at http://www.ietf= .org/meetings/cutoff_dates_68.html.

IETF-Announce mailing list
https://www1= .ietf.org/mailman/listinfo/ietf-announce
=

= --Apple-Mail-73-394093747-- --===============2100831301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============2100831301==-- From pce-bounces@lists.ietf.org Fri Jan 26 11:10:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATeG-00016N-AA; Fri, 26 Jan 2007 11:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATeE-0000zK-OJ for pce@ietf.org; Fri, 26 Jan 2007 11:09:54 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATeD-0004ZM-3z for pce@ietf.org; Fri, 26 Jan 2007 11:09:54 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 26 Jan 2007 08:09:53 -0800 X-IronPort-AV: i="4.13,243,1167638400"; d="scan'208,217"; a="459966590:sNHT84611420" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0QG9qq6010329 for ; Fri, 26 Jan 2007 08:09:52 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0QG9mi0010251 for ; Fri, 26 Jan 2007 08:09:52 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:09:46 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jan 2007 11:09:45 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) To: pce@ietf.org Message-Id: References: <356DCC07-5CDE-4879-95B3-D433572364E6@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] Compliance with the PCECP Requirement Document Date: Fri, 26 Jan 2007 11:09:44 -0500 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 26 Jan 2007 16:09:45.0376 (UTC) FILETIME=[65338A00:01C74164] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9073; t=1169827792; x=1170691792; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[Pce]=20Compliance=20with=20the=20PCECP=20Requiremen t=20Document |Sender:=20; bh=EBB2WkHycG6yRQmpB8v5X76vA0EzI6OkCixy8D4osQU=; b=S6jtP8nPz7MRZHFsoyl0DD/pHRH0+xenJPs7Dj1tv53mjKzmrwvR0BZQiqQ63roIJIrqS7NY jWS+e25Ubdv4P4HQCsmTks6EeOjPsfjZZnRRT8a027swdhrx7EuHR48T; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0889340150==" Errors-To: pce-bounces@lists.ietf.org --===============0889340150== Content-Type: multipart/alternative; boundary=Apple-Mail-74-394539796 --Apple-Mail-74-394539796 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Dear WG, In absence of negative reply we'll go ahead with the proposed plan below. Let us know within 1-2 weeks max if you have comments. Thanks, JP. Begin forwarded message: > From: JP Vasseur > Date: January 24, 2007 11:38:04 AM EST > To: pce@ietf.org > Subject: [Pce] Compliance with the PCECP Requirement Document > > Dear WG, > > As discussed in San Diego, there are still a few requirements > stated in RFC 4657 that PCEP does not satisfy (see Appendix A of > the PCEP ID) for which we'd like your feed-back: > > > Appendix A > > The aim of this section is to list the set of requirements set > forth > in [RFC4657] that are not satisfied by the current revision of this > document. This only concerns the requirements listed as MUST > according to [RFC2119]. > > Here is the list of currently unsatisfied requirements: > > o Allow to select/prefer from advertised list of standard > objective > functions/options > > o Allow to customize objective function/options > > o Support "unsynchronized" & "synchronized" objective functions > > Comment> The Proposal is to work on this item in the context of a > separate ID that will cover the set of requirements, IGP PCED > extensions and PCEP extensions since these functions are not > required for the base protocol specification. > > o Protocol recovery support resynchronization of information & > requests between sender & receiver. > > Comment> We can see two potential avenues here: > 1) Upon loosing the PCEP session, pending requests are considered > as lost, and the PCC has the initiative to resend the set of > pending requests. The main benefit of such approach is to be > extremely simple and IMO well suited to most of the cases since > path computation requests are not likely to be pending for a long > period of time. > 2) Specify a set of re-synchronization procedures. We came up with > similar solutions for many other protocols (in very different > contexts and set of requirements) and our experience clearly tells > us that this will likely to be a fairly complex issue. We could see > some benefit in statefull contexts though; thus if such functions > is required for particular context, we would propose not to include > in the base protocol specification and leave it for further should > the WG think that such function will be required. > > Thanks for your feed-back. > > JP, Jean-Louis et al. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-74-394539796 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Dear WG,

In absence of negative = reply we'll go ahead with the proposed plan below. Let us know within = 1-2 weeks max if you have comments.

Thanks,

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = January 24, 2007 11:38:04 AM EST
Subject: = [Pce] Compliance with the PCECP Requirement = Document
As discussed in San Diego, = there are still a few requirements stated in RFC 4657 that PCEP does not = satisfy (see Appendix A of the PCEP ID) for which we'd like your = feed-back:


Appendix A

=A0 =A0The aim of this section is to list = the set of requirements set forth
=A0=A0 in = [RFC4657] that are not satisfied by the current revision of = this
=A0=A0 document.=A0 This only concerns the = requirements listed as MUST
=A0=A0 according to = [RFC2119].

=A0=A0 Here is the = list of currently unsatisfied requirements:

=A0=A0 o=A0 Allow to = select/prefer from advertised list of standard = objective
=A0 =A0 =A0 = functions/options

=A0=A0 o=A0 Allow to = customize objective function/options

=A0=A0 o=A0 Support = "unsynchronized" & "synchronized" objective = functions

Comment> The = Proposal is to work on this item in the context of a separate ID that = will cover the set of requirements, IGP PCED extensions and PCEP = extensions since these functions are not required for the base protocol = specification.

=A0=A0 o=A0 Protocol = recovery support resynchronization of information = &
=A0 =A0 =A0 requests between sender & = receiver.

Comment> We can = see two potential avenues here:
1) Upon loosing the = PCEP session, pending requests are considered as lost, and the PCC has = the initiative to resend the set of pending requests. The main benefit = of such approach is to be extremely simple and IMO well suited to most = of the cases since path computation requests are not likely to be = pending for a long period of time.
2) Specify a set of = re-synchronization procedures. We came up with similar solutions for = many other protocols (in very different contexts and set of = requirements) and our experience clearly tells us that this will likely = to be a fairly complex issue. We could see some benefit in statefull = contexts though; thus if such functions is required for particular = context, we would propose not to include in the base protocol = specification and leave it for further should the WG think that such = function will be required.

Thanks for your = feed-back.

JP, Jean-Louis et = al.
Pce mailing list
=

= --Apple-Mail-74-394539796-- --===============0889340150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============0889340150==-- From pce-bounces@lists.ietf.org Fri Jan 26 18:13:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAaFa-0005Bf-BQ; Fri, 26 Jan 2007 18:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAaFY-0005BN-Tj for pce@ietf.org; Fri, 26 Jan 2007 18:12:52 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAaFX-00016D-D6 for pce@ietf.org; Fri, 26 Jan 2007 18:12:52 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0QNCq2j021047; Sat, 27 Jan 2007 00:12:52 +0100 In-Reply-To: To: JP Vasseur Subject: Re: Fwd: [Pce] Compliance with the PCECP Requirement Document MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Sat, 27 Jan 2007 00:12:45 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/27/2007 00:12:45, Serialize complete at 01/27/2007 00:12:45 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi j-p one point on the last issue, assuming wg goes as planned: there is a need to distinguish re-sync and de-sync (or out-of-sync), you may certainly want to prevent complex re-sync, but de-sync must lead to the possibility to drop replies from previous requests, assume that a PCC initiates a req. to a PCE, the TCP connection breaks, PCC re-initiates the same request, and receives an answer does it come from the former or the latter req. (this may lead to false positive or true negative) ? thanks, - d. JP Vasseur 26/01/2007 17:09 To: pce@ietf.org cc: Subject: Fwd: [Pce] Compliance with the PCECP Requirement Document Dear WG, In absence of negative reply we'll go ahead with the proposed plan below. Let us know within 1-2 weeks max if you have comments. Thanks, JP. Begin forwarded message: From: JP Vasseur Date: January 24, 2007 11:38:04 AM EST To: pce@ietf.org Subject: [Pce] Compliance with the PCECP Requirement Document Dear WG, As discussed in San Diego, there are still a few requirements stated in RFC 4657 that PCEP does not satisfy (see Appendix A of the PCEP ID) for which we'd like your feed-back: Appendix A The aim of this section is to list the set of requirements set forth in [RFC4657] that are not satisfied by the current revision of this document. This only concerns the requirements listed as MUST according to [RFC2119]. Here is the list of currently unsatisfied requirements: o Allow to select/prefer from advertised list of standard objective functions/options o Allow to customize objective function/options o Support "unsynchronized" & "synchronized" objective functions Comment> The Proposal is to work on this item in the context of a separate ID that will cover the set of requirements, IGP PCED extensions and PCEP extensions since these functions are not required for the base protocol specification. o Protocol recovery support resynchronization of information & requests between sender & receiver. Comment> We can see two potential avenues here: 1) Upon loosing the PCEP session, pending requests are considered as lost, and the PCC has the initiative to resend the set of pending requests. The main benefit of such approach is to be extremely simple and IMO well suited to most of the cases since path computation requests are not likely to be pending for a long period of time. 2) Specify a set of re-synchronization procedures. We came up with similar solutions for many other protocols (in very different contexts and set of requirements) and our experience clearly tells us that this will likely to be a fairly complex issue. We could see some benefit in statefull contexts though; thus if such functions is required for particular context, we would propose not to include in the base protocol specification and leave it for further should the WG think that such function will be required. Thanks for your feed-back. JP, Jean-Louis et al. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Jan 26 18:45:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAal6-00087U-LF; Fri, 26 Jan 2007 18:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAal5-00087N-If for pce@ietf.org; Fri, 26 Jan 2007 18:45:27 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAal4-0006zp-36 for pce@ietf.org; Fri, 26 Jan 2007 18:45:27 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jan 2007 00:45:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: [Pce] Compliance with the PCECP Requirement Document Date: Sat, 27 Jan 2007 00:45:17 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: [Pce] Compliance with the PCECP Requirement Document Thread-Index: AcdBn7dJbA7dtRskTLWadxAaKj9qOgAAtxog From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , "JP Vasseur" X-OriginalArrivalTime: 26 Jan 2007 23:45:21.0294 (UTC) FILETIME=[0AAD9AE0:01C741A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Dimitri, As stated in the spec, if the TCP connection fails the PCE releases all = ressources for the session, including pending requests. Hence a PCC will = never receive a reply for a request sent during a previous session. Regards, JL > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : samedi 27 janvier 2007 00:13 > =C0 : JP Vasseur > Cc : pce@ietf.org > Objet : Re: Fwd: [Pce] Compliance with the PCECP Requirement Document >=20 > Attention, votre correspondant continue de vous =E9crire =E0=20 > votre ancienne adresse en @orange-ft.com, qui va =EAtre=20 > d=E9sactiv=E9e d=E9but avril. Veuillez lui demander de mettre =E0=20 > jour son carnet d'adresses avec votre nouvelle adresse en=20 > @orange-ftgroup.com. >=20 > Caution : your correspondent is still writing to your=20 > orange-ft.com address, which will be disabled beginning of=20 > April. Please ask him/her to update his/her address book to=20 > orange-ftgroup.com .................................................. >=20 > hi j-p >=20 > one point on the last issue, assuming wg goes as planned: >=20 > there is a need to distinguish re-sync and de-sync (or=20 > out-of-sync), you >=20 > may certainly want to prevent complex re-sync, but de-sync=20 > must lead to >=20 > the possibility to drop replies from previous requests,=20 > assume that a PCC >=20 > initiates a req. to a PCE, the TCP connection breaks, PCC=20 > re-initiates the >=20 > same request, and receives an answer does it come from the=20 > former or the >=20 > latter req. (this may lead to false positive or true negative) ? >=20 > thanks, > - d. >=20 >=20 >=20 >=20 > JP Vasseur > 26/01/2007 17:09 >=20 >=20 > To: pce@ietf.org > cc: >=20 > Subject: Fwd: [Pce] Compliance with the PCECP=20 > Requirement >=20 > Document >=20 >=20 > Dear WG, >=20 > In absence of negative reply we'll go ahead with the proposed=20 > plan below. >=20 > Let us know within 1-2 weeks max if you have comments. >=20 > Thanks, >=20 > JP. >=20 > Begin forwarded message: >=20 > From: JP Vasseur > Date: January 24, 2007 11:38:04 AM EST > To: pce@ietf.org > Subject: [Pce] Compliance with the PCECP Requirement Document >=20 > Dear WG, >=20 > As discussed in San Diego, there are still a few requirements=20 > stated in >=20 > RFC 4657 that PCEP does not satisfy (see Appendix A of the=20 > PCEP ID) for >=20 > which we'd like your feed-back: >=20 >=20 > Appendix A >=20 > The aim of this section is to list the set of requirements=20 > set forth > in [RFC4657] that are not satisfied by the current revision of this > document. This only concerns the requirements listed as MUST > according to [RFC2119]. >=20 > Here is the list of currently unsatisfied requirements: >=20 > o Allow to select/prefer from advertised list of standard=20 > objective > functions/options >=20 > o Allow to customize objective function/options >=20 > o Support "unsynchronized" & "synchronized" objective functions >=20 > Comment> The Proposal is to work on this item in the context of a=20 > Comment> separate >=20 > ID that will cover the set of requirements, IGP PCED=20 > extensions and PCEP >=20 > extensions since these functions are not required for the=20 > base protocol >=20 > specification. >=20 > o Protocol recovery support resynchronization of information & > requests between sender & receiver. >=20 > Comment> We can see two potential avenues here: > 1) Upon loosing the PCEP session, pending requests are=20 > considered as lost, >=20 > and the PCC has the initiative to resend the set of pending=20 > requests. The >=20 > main benefit of such approach is to be extremely simple and IMO well >=20 > suited to most of the cases since path computation requests=20 > are not likely >=20 > to be pending for a long period of time. > 2) Specify a set of re-synchronization procedures. We came up=20 > with similar >=20 > solutions for many other protocols (in very different=20 > contexts and set of >=20 > requirements) and our experience clearly tells us that this=20 > will likely to >=20 > be a fairly complex issue. We could see some benefit in=20 > statefull contexts >=20 > though; thus if such functions is required for particular context, we >=20 > would propose not to include in the base protocol=20 > specification and leave >=20 > it for further should the WG think that such function will be=20 > required. >=20 > Thanks for your feed-back. >=20 > JP, Jean-Louis et al. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Jan 27 02:25:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhvX-0004O3-TT; Sat, 27 Jan 2007 02:24:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhvW-0004Nu-SW for pce@ietf.org; Sat, 27 Jan 2007 02:24:42 -0500 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAhvS-00080f-90 for pce@ietf.org; Sat, 27 Jan 2007 02:24:42 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l0R7OVIY019486; Sat, 27 Jan 2007 08:24:31 +0100 In-Reply-To: To: "LE ROUX Jean-Louis RD-CORE-LAN" Subject: RE: Fwd: [Pce] Compliance with the PCECP Requirement Document MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel-lucent.be Date: Sat, 27 Jan 2007 08:24:23 +0100 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 01/27/2007 08:24:25, Serialize complete at 01/27/2007 08:24:25 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org hi jean-louis is my reading correct: " In case of TCP connection failure, the PCEP session SHOULD be maintained for a period of time equal to the DeadTimer." DeadTimer =3D recommended 4 x KeepAlive (min 1s and recommended 30 s)=20 during that interval (recommended =3D 120s) which is not negligible how pending requests are processed ? or did i miss something ? thanks, - d. "LE ROUX Jean-Louis RD-CORE-LAN" 27/01/2007 00:45 =20 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "JP Vasseur"=20 cc: Subject: RE: Fwd: [Pce] Compliance with the PCECP=20 Requirement Document Hi Dimitri, As stated in the spec, if the TCP connection fails the PCE releases all=20 ressources for the session, including pending requests. Hence a PCC will=20 never receive a reply for a request sent during a previous session. Regards, JL > -----Message d'origine----- > De : Dimitri.Papadimitriou@alcatel-lucent.be=20 > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20 > Envoy=E9 : samedi 27 janvier 2007 00:13 > =C0 : JP Vasseur > Cc : pce@ietf.org > Objet : Re: Fwd: [Pce] Compliance with the PCECP Requirement Document >=20 > Attention, votre correspondant continue de vous =E9crire =E0=20 > votre ancienne adresse en @orange-ft.com, qui va =EAtre=20 > d=E9sactiv=E9e d=E9but avril. Veuillez lui demander de mettre =E0=20 > jour son carnet d'adresses avec votre nouvelle adresse en=20 > @orange-ftgroup.com. >=20 > Caution : your correspondent is still writing to your=20 > orange-ft.com address, which will be disabled beginning of=20 > April. Please ask him/her to update his/her address book to=20 > orange-ftgroup.com .................................................. >=20 > hi j-p >=20 > one point on the last issue, assuming wg goes as planned: >=20 > there is a need to distinguish re-sync and de-sync (or=20 > out-of-sync), you >=20 > may certainly want to prevent complex re-sync, but de-sync=20 > must lead to >=20 > the possibility to drop replies from previous requests,=20 > assume that a PCC >=20 > initiates a req. to a PCE, the TCP connection breaks, PCC=20 > re-initiates the >=20 > same request, and receives an answer does it come from the=20 > former or the >=20 > latter req. (this may lead to false positive or true negative) ? >=20 > thanks, > - d. >=20 >=20 >=20 >=20 > JP Vasseur > 26/01/2007 17:09 >=20 >=20 > To: pce@ietf.org > cc: >=20 > Subject: Fwd: [Pce] Compliance with the PCECP=20 > Requirement >=20 > Document >=20 >=20 > Dear WG, >=20 > In absence of negative reply we'll go ahead with the proposed=20 > plan below. >=20 > Let us know within 1-2 weeks max if you have comments. >=20 > Thanks, >=20 > JP. >=20 > Begin forwarded message: >=20 > From: JP Vasseur > Date: January 24, 2007 11:38:04 AM EST > To: pce@ietf.org > Subject: [Pce] Compliance with the PCECP Requirement Document >=20 > Dear WG, >=20 > As discussed in San Diego, there are still a few requirements=20 > stated in >=20 > RFC 4657 that PCEP does not satisfy (see Appendix A of the=20 > PCEP ID) for >=20 > which we'd like your feed-back: >=20 >=20 > Appendix A >=20 > The aim of this section is to list the set of requirements=20 > set forth > in [RFC4657] that are not satisfied by the current revision of this > document. This only concerns the requirements listed as MUST > according to [RFC2119]. >=20 > Here is the list of currently unsatisfied requirements: >=20 > o Allow to select/prefer from advertised list of standard=20 > objective > functions/options >=20 > o Allow to customize objective function/options >=20 > o Support "unsynchronized" & "synchronized" objective functions >=20 > Comment> The Proposal is to work on this item in the context of a=20 > Comment> separate >=20 > ID that will cover the set of requirements, IGP PCED=20 > extensions and PCEP >=20 > extensions since these functions are not required for the=20 > base protocol >=20 > specification. >=20 > o Protocol recovery support resynchronization of information & > requests between sender & receiver. >=20 > Comment> We can see two potential avenues here: > 1) Upon loosing the PCEP session, pending requests are=20 > considered as lost, >=20 > and the PCC has the initiative to resend the set of pending=20 > requests. The >=20 > main benefit of such approach is to be extremely simple and IMO well >=20 > suited to most of the cases since path computation requests=20 > are not likely >=20 > to be pending for a long period of time. > 2) Specify a set of re-synchronization procedures. We came up=20 > with similar >=20 > solutions for many other protocols (in very different=20 > contexts and set of >=20 > requirements) and our experience clearly tells us that this=20 > will likely to >=20 > be a fairly complex issue. We could see some benefit in=20 > statefull contexts >=20 > though; thus if such functions is required for particular context, we >=20 > would propose not to include in the base protocol=20 > specification and leave >=20 > it for further should the WG think that such function will be=20 > required. >=20 > Thanks for your feed-back. >=20 > JP, Jean-Louis et al. > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Jan 28 17:12:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBIFb-00008B-AY; Sun, 28 Jan 2007 17:11:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBIFZ-000085-K2 for pce@ietf.org; Sun, 28 Jan 2007 17:11:49 -0500 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBIFY-0002QT-89 for pce@ietf.org; Sun, 28 Jan 2007 17:11:49 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1170022306!13292085!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 10629 invoked from network); 28 Jan 2007 22:11:47 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-11.tower-120.messagelabs.com with SMTP; 28 Jan 2007 22:11:47 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0SMBknf014914; Sun, 28 Jan 2007 17:11:46 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh3i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0SMBd1W014890; Sun, 28 Jan 2007 17:11:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Compliance with the PCECP Requirement Document Date: Sun, 28 Jan 2007 16:11:39 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC813C@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC813B@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Compliance with the PCECP Requirement Document Thread-Index: Acc/1il6ZkzimkILQVGsUC78t8F+wwDT0PTwAAAGMOA= From: "ASH, GERALD R \(JERRY\), SBCLABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi JP, > From: JP Vasseur [mailto:jvasseur@cisco.com]=20 > Sent: Wednesday, January 24, 2007 11:38 AM > To: pce@ietf.org > Subject: [Pce] Compliance with the PCECP Requirement Document >=20 > Dear WG, >=20 > As discussed in San Diego, there are still a few requirements=20 > stated in RFC 4657 that PCEP does not satisfy (see Appendix A=20 > of the PCEP ID) for which we'd like your feed-back: >=20 >=20 > Appendix A >=20 > The aim of this section is to list the set of requirements=20 > set forth > in [RFC4657] that are not satisfied by the current revision of this > document. This only concerns the requirements listed as MUST > according to [RFC2119]. >=20 >=20 > Here is the list of currently unsatisfied requirements: >=20 > o Allow to select/prefer from advertised list of standard=20 > objective functions/options >=20 > o Allow to customize objective function/options >=20 > o Support "unsynchronized" & "synchronized" objective functions >=20 >=20 > Comment> The Proposal is to work on this item in the context=20 > of a separate ID that will cover the set of requirements, IGP=20 > PCED extensions and PCEP extensions since these functions are=20 > not required for the base protocol specification. >=20 > o Protocol recovery support resynchronization of information & > requests between sender & receiver. >=20 >=20 > Comment> We can see two potential avenues here: > 1) Upon loosing the PCEP session, pending requests are=20 > considered as lost, and the PCC has the initiative to resend=20 > the set of pending requests. The main benefit of such=20 > approach is to be extremely simple and IMO well suited to=20 > most of the cases since path computation requests are not=20 > likely to be pending for a long period of time. > 2) Specify a set of re-synchronization procedures. We came up=20 > with similar solutions for many other protocols (in very=20 > different contexts and set of requirements) and our=20 > experience clearly tells us that this will likely to be a=20 > fairly complex issue. We could see some benefit in statefull=20 > contexts though; thus if such functions is required for=20 > particular context, we would propose not to include in the=20 > base protocol specification and leave it for further should=20 > the WG think that such function will be required. Approach #1 seems very crude and puts much of the burden on PCC to 'recover'. I can appreciate that #2 is more complex but would seemingly allow recovery to occur more quickly and smoothly. Assuming that PCE is a critical network function, smoothing over a failed session in as short a time as possible (or perhaps with no hiccup whatever) would be very important IMO. Thanks, Jerry =20 >=20 > Thanks for your feed-back. >=20 >=20 > JP, Jean-Louis et al. >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jan 29 14:21:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBc4E-0003w5-5G; Mon, 29 Jan 2007 14:21:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBc4B-0003vz-V7 for pce@ietf.org; Mon, 29 Jan 2007 14:21:23 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBc4A-0000NK-EB for pce@ietf.org; Mon, 29 Jan 2007 14:21:23 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 29 Jan 2007 11:21:22 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0TJLLeG023608; Mon, 29 Jan 2007 11:21:21 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0TJL2nj023456; Mon, 29 Jan 2007 11:21:21 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 14:21:07 -0500 Received: from [161.44.113.154] ([161.44.113.154]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 14:21:07 -0500 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC813C@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA0DDC813C@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98EC6C0F-333D-4511-B541-2412BA2A898D@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Compliance with the PCECP Requirement Document Date: Mon, 29 Jan 2007 14:21:06 -0500 To: "ASH, GERALD R \(JERRY\), SBCLABS" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Jan 2007 19:21:07.0101 (UTC) FILETIME=[A014FCD0:01C743DA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4293; t=1170098481; x=1170962481; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20Compliance=20with=20the=20PCECP=20Requirement =20Document |Sender:=20; bh=rqCAp9RtbYGcxWxoKT3JUY1Xx0DYkJNywhFnMzd4ygA=; b=vQrLo1XrbZuL/ToYL+Kt7riZPy7x82K9+LTHc5PM97MBDWhI9l6WOLeWpOW9jaD4NAZy3pp5 7vSSD/1aTUmn/56/5aeJIXLZ8q7n7lw/j4NpPvuv2TnjAlXWpJdW7UVr; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Jerry, On Jan 28, 2007, at 5:11 PM, ASH, GERALD R ((JERRY)), SBCLABS wrote: > Hi JP, > >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Wednesday, January 24, 2007 11:38 AM >> To: pce@ietf.org >> Subject: [Pce] Compliance with the PCECP Requirement Document >> >> Dear WG, >> >> As discussed in San Diego, there are still a few requirements >> stated in RFC 4657 that PCEP does not satisfy (see Appendix A >> of the PCEP ID) for which we'd like your feed-back: >> >> >> Appendix A >> >> The aim of this section is to list the set of requirements >> set forth >> in [RFC4657] that are not satisfied by the current revision of this >> document. This only concerns the requirements listed as MUST >> according to [RFC2119]. >> >> >> Here is the list of currently unsatisfied requirements: >> >> o Allow to select/prefer from advertised list of standard >> objective functions/options >> >> o Allow to customize objective function/options >> >> o Support "unsynchronized" & "synchronized" objective functions >> >> >> Comment> The Proposal is to work on this item in the context >> of a separate ID that will cover the set of requirements, IGP >> PCED extensions and PCEP extensions since these functions are >> not required for the base protocol specification. >> >> o Protocol recovery support resynchronization of information & >> requests between sender & receiver. >> >> >> Comment> We can see two potential avenues here: >> 1) Upon loosing the PCEP session, pending requests are >> considered as lost, and the PCC has the initiative to resend >> the set of pending requests. The main benefit of such >> approach is to be extremely simple and IMO well suited to >> most of the cases since path computation requests are not >> likely to be pending for a long period of time. >> 2) Specify a set of re-synchronization procedures. We came up >> with similar solutions for many other protocols (in very >> different contexts and set of requirements) and our >> experience clearly tells us that this will likely to be a >> fairly complex issue. We could see some benefit in statefull >> contexts though; thus if such functions is required for >> particular context, we would propose not to include in the >> base protocol specification and leave it for further should >> the WG think that such function will be required. > > Approach #1 seems very crude and puts much of the burden on PCC to > 'recover'. Two comments there: 1) Note that the probability for such a failure to happen while requests are pending is not likely to be very high in most cases. Still we've got to handle and discuss it but it is worth being considered when looking at the solution. 2) In term of PCC implementation, there is a trade-off between having to resend all lost pending requests and have to re-sync with the PCE after loosing a PCEP session. Not sure resending is more burden compared to adding more complexity to the FSM. > I can appreciate that #2 is more complex but would seemingly > allow recovery to occur more quickly and smoothly. Also not very easy to evaluate until we've got a better idea on what #2 might look like. Indeed, the PCC may decide to implement fairly quick retransmission once the PCEP session is restored thus leading to potentially comparable recovery time compared to #2. For the PCE side, we would increase the overall complexity also, allocated resources. > Assuming that PCE is > a critical network function, smoothing over a failed session in as > short > a time as possible (or perhaps with no hiccup whatever) would be very > important IMO. > Thanks for the feed-back. We've got 3 options here: 1) We add #2 to the base protocol specification 2) We decide to work on #2 but we leave it out of the base protocol specification 3) We decide not to work on #2 for the time being. WG ? My personal opinion is not to go with 1) since there are many situations where such feature would not be required thus it is probably a good idea not to overload the base protocol spec. Let's see what others think ? Thanks. JP. > Thanks, > Jerry > >> >> Thanks for your feed-back. >> >> >> JP, Jean-Louis et al. >> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Jan 29 18:01:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfUX-0007yd-Te; Mon, 29 Jan 2007 18:00:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfUX-0007yX-80 for pce@lists.ietf.org; Mon, 29 Jan 2007 18:00:49 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBfUQ-0002Af-7q for pce@lists.ietf.org; Mon, 29 Jan 2007 18:00:48 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN00I3RJX0CS@usaga01-in.huawei.com> for pce@lists.ietf.org; Mon, 29 Jan 2007 15:00:37 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN00DCNJWZU0@usaga01-in.huawei.com> for pce@lists.ietf.org; Mon, 29 Jan 2007 15:00:36 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00AJPKF98Q@usaml03-in.huawei.com> for pce@lists.ietf.org; Mon, 29 Jan 2007 15:11:37 -0800 (PST) Date: Mon, 29 Jan 2007 17:00:31 -0600 From: Young Lee In-reply-to: To: pce@lists.ietf.org Message-id: <001c01c743f9$470b0250$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdBa3E1vqxJwxpxTauY0jV2bs79hgCiVPzg X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Subject: [Pce] RE: Pce Digest, Vol 29, Issue 13 X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi J-P, Regarding your proposal on the objective function/options not to be defined in the PCEP-Version 1, I suggest to define the objective function object in the PCEP-Version 1. Unless there's base object definition, it would be a little harder to be consistent across different applications and/or PCEP extensions. For instance, in the PCE Global concurrent optimization I-D, the global objective functions need to be defined. The authors have decided to define the Global Objective Function (GOF) Object. I can see each application or extension would define its own Objective Function Object, which could result in inconsistency moving forward. Regards, Young > o Allow to customize objective function/options > > o Support "unsynchronized" & "synchronized" objective functions > > Comment> The Proposal is to work on this item in the context of a > separate ID that will cover the set of requirements, IGP PCED > extensions and PCEP extensions since these functions are not > required for the base protocol specification. I -----Original Message----- From: pce-request@lists.ietf.org [mailto:pce-request@lists.ietf.org] Sent: Friday, January 26, 2007 11:00 AM To: pce@lists.ietf.org Subject: Pce Digest, Vol 29, Issue 13 Send Pce mailing list submissions to pce@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/pce or, via email, send a message with subject or body 'help' to pce-request@lists.ietf.org You can reach the person managing the list at pce-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Pce digest..." Today's Topics: 1. Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic (JP Vasseur) 2. Fwd: [Pce] Compliance with the PCECP Requirement Document (JP Vasseur) ---------------------------------------------------------------------- Message: 1 Date: Fri, 26 Jan 2007 11:02:18 -0500 From: JP Vasseur Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic To: pce@ietf.org Message-ID: <989A79F6-C80C-48ED-B536-EB3A3805D276@cisco.com> Content-Type: text/plain; charset="us-ascii" Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: January 26, 2007 12:00:02 AM EST > To: ietf-announce@ietf.org > Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF > Meeting in Prague, Czech Republic > > > There are two (2) Internet-Draft cutoff dates for the 68th > IETF Meeting in Prague, Czech Republic: > > February 26th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > February 26th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > February 19th at 9:00 AM ET. > > March 5th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, March 5th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, March 19th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 68th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_68.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/pce/attachments/20070126/c11a8762/attachment- 0001.html ------------------------------ Message: 2 Date: Fri, 26 Jan 2007 11:09:44 -0500 From: JP Vasseur Subject: Fwd: [Pce] Compliance with the PCECP Requirement Document To: pce@ietf.org Message-ID: Content-Type: text/plain; charset="us-ascii" Dear WG, In absence of negative reply we'll go ahead with the proposed plan below. Let us know within 1-2 weeks max if you have comments. Thanks, JP. Begin forwarded message: > From: JP Vasseur > Date: January 24, 2007 11:38:04 AM EST > To: pce@ietf.org > Subject: [Pce] Compliance with the PCECP Requirement Document > > Dear WG, > > As discussed in San Diego, there are still a few requirements > stated in RFC 4657 that PCEP does not satisfy (see Appendix A of > the PCEP ID) for which we'd like your feed-back: > > > Appendix A > > The aim of this section is to list the set of requirements set > forth > in [RFC4657] that are not satisfied by the current revision of this > document. This only concerns the requirements listed as MUST > according to [RFC2119]. > > Here is the list of currently unsatisfied requirements: > > o Allow to select/prefer from advertised list of standard > objective > functions/options > > o Allow to customize objective function/options > > o Support "unsynchronized" & "synchronized" objective functions > > Comment> The Proposal is to work on this item in the context of a > separate ID that will cover the set of requirements, IGP PCED > extensions and PCEP extensions since these functions are not > required for the base protocol specification. > > o Protocol recovery support resynchronization of information & > requests between sender & receiver. > > Comment> We can see two potential avenues here: > 1) Upon loosing the PCEP session, pending requests are considered > as lost, and the PCC has the initiative to resend the set of > pending requests. The main benefit of such approach is to be > extremely simple and IMO well suited to most of the cases since > path computation requests are not likely to be pending for a long > period of time. > 2) Specify a set of re-synchronization procedures. We came up with > similar solutions for many other protocols (in very different > contexts and set of requirements) and our experience clearly tells > us that this will likely to be a fairly complex issue. We could see > some benefit in statefull contexts though; thus if such functions > is required for particular context, we would propose not to include > in the base protocol specification and leave it for further should > the WG think that such function will be required. > > Thanks for your feed-back. > > JP, Jean-Louis et al. > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/pce/attachments/20070126/2dc60500/attachment- 0001.html ------------------------------ _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 29, Issue 13 *********************************** _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 30 08:07:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBshJ-0005jT-33; Tue, 30 Jan 2007 08:06:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBshH-0005iE-Ng for pce@lists.ietf.org; Tue, 30 Jan 2007 08:06:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBshF-0006Hv-1i for pce@lists.ietf.org; Tue, 30 Jan 2007 08:06:51 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2007 05:06:48 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0UD6mIx011074; Tue, 30 Jan 2007 05:06:48 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0UD6khu023808; Tue, 30 Jan 2007 05:06:47 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 08:06:16 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 08:06:15 -0500 In-Reply-To: <001c01c743f9$470b0250$560c7c0a@china.huawei.com> References: <001c01c743f9$470b0250$560c7c0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] RE: Pce Digest, Vol 29, Issue 13 Date: Tue, 30 Jan 2007 08:06:13 -0500 To: Young Lee X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 30 Jan 2007 13:06:15.0913 (UTC) FILETIME=[6CB3CD90:01C7446F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8923; t=1170162408; x=1171026408; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20RE=3A=20Pce=20Digest, =20Vol=2029, =20Issue=201 3 |Sender:=20; bh=g5NxmirJAdqrQzNy4OXxawdYafELKpU3LmTnChWDkt4=; b=a70r5KV5Ady+0QX5Gg13jQmyldZMSHRMjAicEVQTUge5VopeEO7nYEhjd9Vf+fImPjoIT+CU vg8q6ccP0qHti6yH5/VmEOYV8QD/tqZXXtzQI0iSeDIkp+ROg4/5uvBA; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: pce@lists.ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi Young, On Jan 29, 2007, at 6:00 PM, Young Lee wrote: > Hi J-P, > > Regarding your proposal on the objective function/options not to be > defined > in the PCEP-Version 1, I suggest to define the objective function > object in > the PCEP-Version 1. Unless there's base object definition, it > would be a > little harder to be consistent across different applications and/or > PCEP > extensions. > There is definitely a need for a base spec for an ID related to the objective function, which does not mean that it should belong to the base protocol specification. The PCEP authors (ad discussed with you) decided to have it in a separate ID (in the works) since this is not a "core" function of PCEP (in other words, not required for the protocol to operate in many circumstances). > For instance, in the PCE Global concurrent optimization I-D, the > global > objective functions need to be defined. The authors have decided to > define > the Global Objective Function (GOF) Object. I can see each > application or > extension would define its own Objective Function Object, which > could result > in inconsistency moving forward. Your draft could then refer to the newly ID discussed below. Thanks. JP. > > > Regards, > > Young > > > > > >> o Allow to customize objective function/options >> >> o Support "unsynchronized" & "synchronized" objective functions >> >> Comment> The Proposal is to work on this item in the context of a >> separate ID that will cover the set of requirements, IGP PCED >> extensions and PCEP extensions since these functions are not >> required for the base protocol specification. > > I > -----Original Message----- > From: pce-request@lists.ietf.org [mailto:pce-request@lists.ietf.org] > Sent: Friday, January 26, 2007 11:00 AM > To: pce@lists.ietf.org > Subject: Pce Digest, Vol 29, Issue 13 > > Send Pce mailing list submissions to > pce@lists.ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/pce > or, via email, send a message with subject or body 'help' to > pce-request@lists.ietf.org > > You can reach the person managing the list at > pce-owner@lists.ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pce digest..." > > > Today's Topics: > > 1. Fwd: Internet-Drafts Submission Cutoff Dates for the 68th > IETF Meeting in Prague, Czech Republic (JP Vasseur) > 2. Fwd: [Pce] Compliance with the PCECP Requirement Document > (JP Vasseur) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 26 Jan 2007 11:02:18 -0500 > From: JP Vasseur > Subject: [Pce] Fwd: Internet-Drafts Submission Cutoff Dates for the > 68th IETF Meeting in Prague, Czech Republic > To: pce@ietf.org > Message-ID: <989A79F6-C80C-48ED-B536-EB3A3805D276@cisco.com> > Content-Type: text/plain; charset="us-ascii" > > > > Begin forwarded message: > >> From: ietf-secretariat@ietf.org >> Date: January 26, 2007 12:00:02 AM EST >> To: ietf-announce@ietf.org >> Subject: Internet-Drafts Submission Cutoff Dates for the 68th IETF >> Meeting in Prague, Czech Republic >> >> >> There are two (2) Internet-Draft cutoff dates for the 68th >> IETF Meeting in Prague, Czech Republic: >> >> February 26th: Cutoff Date for Initial (i.e., version -00) >> Internet-Draft Submissions >> >> All initial Internet-Drafts (version -00) must be submitted by >> Monday, >> February 26th at 9:00 AM ET. As always, all initial submissions >> with a >> filename beginning with "draft-ietf" must be approved by the >> appropriate WG Chair before they can be processed or announced. The >> Secretariat would appreciate receiving WG Chair approval by Monday, >> February 19th at 9:00 AM ET. >> >> March 5th: Cutoff Date for Revised (i.e., version -01 and higher) >> Internet-Draft Submissions >> >> All revised Internet-Drafts (version -01 and higher) must be >> submitted >> by Monday, March 5th at 9:00 AM ET. >> >> Initial and revised Internet-Drafts received after their respective >> cutoff dates will not be made available in the Internet-Drafts >> directory or announced until on or after Monday, March 19th at 9:00 >> AM ET, when Internet-Draft posting resumes. Please do not wait until >> the last minute to submit. >> >> Thank you for your understanding and cooperation. If you have any >> questions or concerns, then please send a message to >> internet-drafts@ietf.org. >> >> The IETF Secretariat >> >> FYI: The Internet-Draft cutoff dates as well as other significant >> dates >> for the 68th IETF Meeting can be found at http://www.ietf.org/ >> meetings/cutoff_dates_68.html. >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf-announce > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/pce/attachments/20070126/c11a8762/ > attachment- > 0001.html > > ------------------------------ > > Message: 2 > Date: Fri, 26 Jan 2007 11:09:44 -0500 > From: JP Vasseur > Subject: Fwd: [Pce] Compliance with the PCECP Requirement Document > To: pce@ietf.org > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Dear WG, > > In absence of negative reply we'll go ahead with the proposed plan > below. Let us know within 1-2 weeks max if you have comments. > > Thanks, > > JP. > > Begin forwarded message: > >> From: JP Vasseur >> Date: January 24, 2007 11:38:04 AM EST >> To: pce@ietf.org >> Subject: [Pce] Compliance with the PCECP Requirement Document >> >> Dear WG, >> >> As discussed in San Diego, there are still a few requirements >> stated in RFC 4657 that PCEP does not satisfy (see Appendix A of >> the PCEP ID) for which we'd like your feed-back: >> >> >> Appendix A >> >> The aim of this section is to list the set of requirements set >> forth >> in [RFC4657] that are not satisfied by the current revision of >> this >> document. This only concerns the requirements listed as MUST >> according to [RFC2119]. >> >> Here is the list of currently unsatisfied requirements: >> >> o Allow to select/prefer from advertised list of standard >> objective >> functions/options >> >> o Allow to customize objective function/options >> >> o Support "unsynchronized" & "synchronized" objective functions >> >> Comment> The Proposal is to work on this item in the context of a >> separate ID that will cover the set of requirements, IGP PCED >> extensions and PCEP extensions since these functions are not >> required for the base protocol specification. >> >> o Protocol recovery support resynchronization of information & >> requests between sender & receiver. >> >> Comment> We can see two potential avenues here: >> 1) Upon loosing the PCEP session, pending requests are considered >> as lost, and the PCC has the initiative to resend the set of >> pending requests. The main benefit of such approach is to be >> extremely simple and IMO well suited to most of the cases since >> path computation requests are not likely to be pending for a long >> period of time. >> 2) Specify a set of re-synchronization procedures. We came up with >> similar solutions for many other protocols (in very different >> contexts and set of requirements) and our experience clearly tells >> us that this will likely to be a fairly complex issue. We could see >> some benefit in statefull contexts though; thus if such functions >> is required for particular context, we would propose not to include >> in the base protocol specification and leave it for further should >> the WG think that such function will be required. >> >> Thanks for your feed-back. >> >> JP, Jean-Louis et al. >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www1.ietf.org/pipermail/pce/attachments/20070126/2dc60500/ > attachment- > 0001.html > > ------------------------------ > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > > End of Pce Digest, Vol 29, Issue 13 > *********************************** > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 30 14:35:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByko-0000u3-6h; Tue, 30 Jan 2007 14:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBykn-0000tx-Bo for pce@lists.ietf.org; Tue, 30 Jan 2007 14:34:53 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBykj-0003Ub-1h for pce@lists.ietf.org; Tue, 30 Jan 2007 14:34:52 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00CSL51WJV@usaga01-in.huawei.com> for pce@lists.ietf.org; Tue, 30 Jan 2007 11:34:44 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00MO251UIF@usaga01-in.huawei.com> for pce@lists.ietf.org; Tue, 30 Jan 2007 11:34:44 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCP00BHU5K4KD@usaml03-in.huawei.com> for pce@lists.ietf.org; Tue, 30 Jan 2007 11:45:44 -0800 (PST) Date: Tue, 30 Jan 2007 13:34:37 -0600 From: Young Lee To: pce@lists.ietf.org Message-id: <000601c744a5$ae0feb80$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdEpa1DxY704l2+SsajlAvoUAcc0g== X-Spam-Score: 0.0 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Subject: [Pce] PCE global concurrent optimization X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1828301196==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1828301196== Content-type: multipart/alternative; boundary="Boundary_(ID_nqeWrawkgePKRinGxFW1sQ)" This is a multi-part message in MIME format. --Boundary_(ID_nqeWrawkgePKRinGxFW1sQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, We have submitted the following I-D. As we have made a significant progress on this I-D from the previous version, we'd appreciate your comments and suggestions. Regards, Young, Jean-Louis, Dan and Eiji ------Original Message-------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-lee-pce-global-concurrent-optimization-01.txt Pages : 31 Date : 2007-1-29 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-pce-global-concurrent-optimization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_nqeWrawkgePKRinGxFW1sQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

We have submitted the following I-D.  As we have made a significant progress on this I-D from the previous version, we’d appreciate your comments and suggestions.  

 

Regards,

 

Young, Jean-Louis, Dan and Eiji

 

------Original Message--------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
               Title : Path Computation Element Communication 
                          Protocol (PCECP) Requirements and Protocol 
                          Extensions In Support of Global Concurrent Optimization
               Author(s) : Y. Lee, et al.
               Filename : draft-lee-pce-global-concurrent-optimization-01.txt
               Pages                     : 31
               Date                       : 2007-1-29
               
The Path Computation Element (PCE) is a network component,
   application, or node that is capable of performing path computations
   at the request of Path Computation Clients (PCCs).  The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.  The Path Computation Element Communication Protocol (PCEP)
   is specified for communications between PCCs and PCEs, and between
   cooperating PCEs.
 
   When computing or re-optimizing the routes of a set of LSPs through a
   network it may be advantageous to perform bulk path computations in
   order to avoid blocking problems and to achieve more optimal network-
   wide solutions.  Such bulk optimization is termed Global Concurrent
   Optimization.
 
   This document provides application-specific requirements and the PCEP
   extensions in support of a global concurrent path computation
   application.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt
 
To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
 
Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-lee-pce-global-concurrent-optimization-01.txt".
 
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 
Internet-Drafts can also be obtained by e-mail.
 
Send a message to:
               mailserv at ietf.org.
In the body type:
               "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt".
               
NOTE:     The mail server at ietf.org can return the document in
               MIME-encoded form by using the "mpack" utility.  To use this
               feature, insert the command "ENCODING mime" before the "FILE"
               command.  To decode the response(s), you will need "munpack" or
               a MIME-compliant mail reader.  Different MIME-compliant mail readers
               exhibit different behavior, especially when dealing with
               "multipart" MIME messages (i.e. documents which have been split
               up into multiple messages), so check your local documentation on
               how to manipulate these messages.
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt> 

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

 

 

--Boundary_(ID_nqeWrawkgePKRinGxFW1sQ)-- --===============1828301196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1828301196==-- From pce-bounces@lists.ietf.org Tue Jan 30 14:45:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByvE-0006A4-Gp; Tue, 30 Jan 2007 14:45:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByvD-00067Z-7a for pce@ietf.org; Tue, 30 Jan 2007 14:45:39 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByv5-0005cX-4q for pce@ietf.org; Tue, 30 Jan 2007 14:45:39 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00ASO5JU6N@usaga01-in.huawei.com> for pce@ietf.org; Tue, 30 Jan 2007 11:45:31 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00J545JSGF@usaga01-in.huawei.com> for pce@ietf.org; Tue, 30 Jan 2007 11:45:30 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCP00BA3622KD@usaml03-in.huawei.com> for pce@ietf.org; Tue, 30 Jan 2007 11:56:30 -0800 (PST) Date: Tue, 30 Jan 2007 13:45:23 -0600 From: Young Lee To: pce@ietf.org Message-id: <000b01c744a7$2f4fbad0$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdEpy6WKVRRleAzSYid4LzRJ/+daA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: Subject: [Pce] PCE Global Concurrent Optimization - new version is now available X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1025110712==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1025110712== Content-type: multipart/alternative; boundary="Boundary_(ID_H9wtLoVbEUiib/9uukcA5w)" This is a multi-part message in MIME format. --Boundary_(ID_H9wtLoVbEUiib/9uukcA5w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, We have submitted the following I-D. As we have made a significant progress on this I-D from the previous version, we'd appreciate your comments and suggestions. Regards, Young, Jean-Louis, Dan and Eiji ------Original Message-------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-lee-pce-global-concurrent-optimization-01.txt Pages : 31 Date : 2007-1-29 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-pce-global-concurrent-optimization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_H9wtLoVbEUiib/9uukcA5w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

We have submitted the following I-D.  As we have made a significant progress on this I-D from the previous version, we’d appreciate your comments and suggestions.  

 

Regards,

 

Young, Jean-Louis, Dan and Eiji

 

------Original Message--------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
               Title : Path Computation Element Communication 
                          Protocol (PCECP) Requirements and Protocol 
                          Extensions In Support of Global Concurrent Optimization
               Author(s) : Y. Lee, et al.
               Filename : draft-lee-pce-global-concurrent-optimization-01.txt
               Pages                     : 31
               Date                       : 2007-1-29
               
The Path Computation Element (PCE) is a network component,
   application, or node that is capable of performing path computations
   at the request of Path Computation Clients (PCCs).  The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.  The Path Computation Element Communication Protocol (PCEP)
   is specified for communications between PCCs and PCEs, and between
   cooperating PCEs.
 
   When computing or re-optimizing the routes of a set of LSPs through a
   network it may be advantageous to perform bulk path computations in
   order to avoid blocking problems and to achieve more optimal network-
   wide solutions.  Such bulk optimization is termed Global Concurrent
   Optimization.
 
   This document provides application-specific requirements and the PCEP
   extensions in support of a global concurrent path computation
   application.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt
 
To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
 
Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-lee-pce-global-concurrent-optimization-01.txt".
 
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 
Internet-Drafts can also be obtained by e-mail.
 
Send a message to:
               mailserv at ietf.org.
In the body type:
               "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt".
               
NOTE:     The mail server at ietf.org can return the document in
               MIME-encoded form by using the "mpack" utility.  To use this
               feature, insert the command "ENCODING mime" before the "FILE"
               command.  To decode the response(s), you will need "munpack" or
               a MIME-compliant mail reader.  Different MIME-compliant mail readers
               exhibit different behavior, especially when dealing with
               "multipart" MIME messages (i.e. documents which have been split
               up into multiple messages), so check your local documentation on
               how to manipulate these messages.
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt> 

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

 

 

 

--Boundary_(ID_H9wtLoVbEUiib/9uukcA5w)-- --===============1025110712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1025110712==-- From pce-bounces@lists.ietf.org Tue Jan 30 19:56:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3lA-0001Uw-TN; Tue, 30 Jan 2007 19:55:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3l9-0001Um-2B for pce@ietf.org; Tue, 30 Jan 2007 19:55:35 -0500 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3l7-0004Nj-NJ for pce@ietf.org; Tue, 30 Jan 2007 19:55:35 -0500 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1HC3lW-0000yH-00 for pce@ietf.org; Wed, 31 Jan 2007 00:55:58 +0000 Received: from your029b8cecfe ([217.158.132.201] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 00:55:32 +0000 Message-ID: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> From: "Adrian Farrel" To: Date: Wed, 31 Jan 2007 00:54:48 -0000 Organization: Old Dog Consulting MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 31 Jan 2007 00:55:32.0557 (UTC) FILETIME=[827057D0:01C744D2] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Pce] Path Key draft to WG status? X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, draft-bradford-pce-path-key-01.txt was presented in San Diego and there was some interest and a general agreement that the work was needed for confidentiality of path segments computed by cooperating PCEs, for example in the BRPC mode of operation. Since then we have produced a new version to address some comments made in San Diego and privately to the authors. Rich sent a note about the changes on 11th January. Since JP and I are both co-authors of this work we need to move forward with some caution, but we believe that this is a necessary part of the puzzle and that the current draft is in good shape to become a Working Group draft. We can then build on it (hopefully with input from the working group) until it is fully stable and complete. So opinions please: is draft-bradford-pce-path-key-02.txt ready to be a WG draft? Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 30 22:06:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC5n5-0007hg-Ti; Tue, 30 Jan 2007 22:05:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC5n4-0007hY-W8 for pce@ietf.org; Tue, 30 Jan 2007 22:05:43 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC5my-0000Bw-W0 for pce@ietf.org; Tue, 30 Jan 2007 22:05:42 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Jan 2007 22:05:37 -0500 X-IronPort-AV: i="4.13,259,1167627600"; d="scan'208"; a="112801553:sNHT46252496" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0V35aEX026250; Tue, 30 Jan 2007 22:05:36 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0V35aVT000614; Tue, 30 Jan 2007 22:05:36 -0500 (EST) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 22:05:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Path Key draft to WG status? Date: Tue, 30 Jan 2007 22:05:34 -0500 Message-ID: In-Reply-To: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Path Key draft to WG status? Thread-Index: AcdE0u3BUp9j+BM1RBe/Wf3+2bnBawAEbQQw References: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 31 Jan 2007 03:05:36.0663 (UTC) FILETIME=[AE0C6A70:01C744E4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1387; t=1170212736; x=1171076736; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20\(zali\)=22=20 |Subject:=20RE=3A=20[Pce]=20Path=20Key=20draft=20to=20WG=20status? |Sender:=20 |To:=20=22Adrian=20Farrel=22=20,=20; bh=DbhVxcYv5ejQCf1KNYJwGEtkkXnO5npXoYKisXl7eB4=; b=f5oGuXvHhMIZAuuU/LZxaCLvMfrTT2ACbn94VHFVys6xChaFf20bl30koeGG3ZVW13txxHiO 6f1+NqaTota/Ij5BG1bV3Hb2FZsULi7A+I3gF9DLnB6O2rtQRCddXYkY; Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org In Favor.=20 Thanks Regards... Zafar =20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, January 30, 2007 7:55 PM > To: pce@ietf.org > Subject: [Pce] Path Key draft to WG status? >=20 > Hi, >=20 > draft-bradford-pce-path-key-01.txt was presented in San Diego=20 > and there was some interest and a general agreement that the=20 > work was needed for confidentiality of path segments computed=20 > by cooperating PCEs, for example in the BRPC mode of operation. >=20 > Since then we have produced a new version to address some=20 > comments made in San Diego and privately to the authors. Rich=20 > sent a note about the changes on 11th January. >=20 > Since JP and I are both co-authors of this work we need to=20 > move forward with some caution, but we believe that this is a=20 > necessary part of the puzzle and that the current draft is in=20 > good shape to become a Working Group draft. We can then build=20 > on it (hopefully with input from the working group) until it=20 > is fully stable and complete. >=20 > So opinions please: is draft-bradford-pce-path-key-02.txt=20 > ready to be a WG draft? >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Jan 30 22:39:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6Jc-0007hO-HW; Tue, 30 Jan 2007 22:39:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC6Jb-0007hG-GX for pce@ietf.org; Tue, 30 Jan 2007 22:39:19 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC6JZ-0006Ze-Md for pce@ietf.org; Tue, 30 Jan 2007 22:39:19 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP004G6RG5AT@szxga01-in.huawei.com> for pce@ietf.org; Wed, 31 Jan 2007 11:38:29 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00A3VRG4AY@szxga01-in.huawei.com> for pce@ietf.org; Wed, 31 Jan 2007 11:38:29 +0800 (CST) Received: from Z18605a ([10.111.12.121]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCP005OARG32V@szxml04-in.huawei.com> for pce@ietf.org; Wed, 31 Jan 2007 11:38:28 +0800 (CST) Date: Wed, 31 Jan 2007 11:38:27 +0800 From: Zhang Renhai To: ccamp@ops.ietf.org, pce@ietf.org Message-id: <016301c744e9$453a5cf0$790c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Pce] A New Internet-Draft on Advertising of inter-AS TE links X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, allWe have just submitted the following draft in which we describe some problemsin inter-AS TE scenarios and the corresponding OSPF extension is introduced.PCE environment is also considerd in this I-d so I'd also like pce working groupto pay attention to it.we'd highly appreciate your comments.Thanks a lot,Zhang Renhai & Mach A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Extensions in Support of Inter-AS (G)MPLS TE Author(s) : M. Chen, R. Zhang Filename : draft-chen-ccamp-ospf-interas-te-extension-00.txt Pages : 9 Date : 2007-1-30 This document describes extensions to the OSPF to support inter-AS Traffic engineering (TE). It defines OSPF extensions for the flooding of inter-AS links information which can be used to perform inter-AS path computation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chen-ccamp-ospf-interas-te-extension-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-chen-ccamp-ospf-interas-te-extension-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 31 02:44:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCA8f-0005FE-Nv; Wed, 31 Jan 2007 02:44:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCA8e-0005F7-3f for pce@ietf.org; Wed, 31 Jan 2007 02:44:16 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCA8c-0007hR-NH for pce@ietf.org; Wed, 31 Jan 2007 02:44:16 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 08:44:12 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [Pce] Path Key draft to WG status? Date: Wed, 31 Jan 2007 08:39:01 +0100 Message-ID: In-Reply-To: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Path Key draft to WG status? Thread-Index: AcdE0uZ/U/WiwpxeSgG1G84+KQfT7wAN+JBw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 31 Jan 2007 07:44:12.0538 (UTC) FILETIME=[997C85A0:01C7450B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi This is an important piece. I'm in favor. Regards, JL=20 > -----Message d'origine----- > De : Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Envoy=E9 : mercredi 31 janvier 2007 01:55 > =C0 : pce@ietf.org > Objet : [Pce] Path Key draft to WG status? >=20 > Hi, >=20 > draft-bradford-pce-path-key-01.txt was presented in San Diego=20 > and there was some interest and a general agreement that the=20 > work was needed for confidentiality of path segments computed=20 > by cooperating PCEs, for example in the BRPC mode of operation. >=20 > Since then we have produced a new version to address some=20 > comments made in San Diego and privately to the authors. Rich=20 > sent a note about the changes on 11th January. >=20 > Since JP and I are both co-authors of this work we need to=20 > move forward with some caution, but we believe that this is a=20 > necessary part of the puzzle and that the current draft is in=20 > good shape to become a Working Group draft. We can then build=20 > on it (hopefully with input from the working group) until it=20 > is fully stable and complete. >=20 > So opinions please: is draft-bradford-pce-path-key-02.txt=20 > ready to be a WG draft? >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 31 08:49:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFpH-0002CT-Qf; Wed, 31 Jan 2007 08:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBucG-0001fz-OZ for pce@lists.ietf.org; Tue, 30 Jan 2007 10:09:48 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBuc9-0004YC-J6 for pce@lists.ietf.org; Tue, 30 Jan 2007 10:09:48 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCO00G3DSS021@usaga01-in.huawei.com> for pce@lists.ietf.org; Tue, 30 Jan 2007 07:09:37 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCO00CE7SRIVO@usaga01-in.huawei.com> for pce@lists.ietf.org; Tue, 30 Jan 2007 07:09:36 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCO00ARFT9RDD@usaml03-in.huawei.com> for pce@lists.ietf.org; Tue, 30 Jan 2007 07:20:21 -0800 (PST) Date: Tue, 30 Jan 2007 09:09:11 -0600 From: Young Lee To: pce@lists.ietf.org Message-id: <00ed01c74480$99b1fdb0$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_owV1AthqLy67eqCWzQkE0g)" Thread-index: AcdEgJixisOlAjFDQOSHbwTqe3WZmg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 56e89b758a38944229c8153fc72e2933 X-Mailman-Approved-At: Wed, 31 Jan 2007 08:48:38 -0500 Subject: [Pce] PCE Global Concurrent Optimization X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_owV1AthqLy67eqCWzQkE0g) Content-type: multipart/alternative; boundary="Boundary_(ID_hotCUioXsNhe0Z9xTEQ9UQ)" --Boundary_(ID_hotCUioXsNhe0Z9xTEQ9UQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, We have submitted the following I-D. As we have made a significant progress on this I-D from the previous version, we'd appreciate your comments and suggestions. Regards, Young, Jean-Louis, Dan and Eiji ------Original Message-------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-lee-pce-global-concurrent-optimization-01.txt Pages : 31 Date : 2007-1-29 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-pce-global-concurrent-optimization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_hotCUioXsNhe0Z9xTEQ9UQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

We have submitted the following I-D.  As we have made a significant progress on this I-D from the previous version, we’d appreciate your comments and suggestions.  

 

Regards,

 

Young, Jean-Louis, Dan and Eiji

 

------Original Message--------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
               Title : Path Computation Element Communication 
                          Protocol (PCECP) Requirements and Protocol 
                          Extensions In Support of Global Concurrent Optimization
               Author(s) : Y. Lee, et al.
               Filename : draft-lee-pce-global-concurrent-optimization-01.txt
               Pages                     : 31
               Date                       : 2007-1-29
               
The Path Computation Element (PCE) is a network component,
   application, or node that is capable of performing path computations
   at the request of Path Computation Clients (PCCs).  The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.  The Path Computation Element Communication Protocol (PCEP)
   is specified for communications between PCCs and PCEs, and between
   cooperating PCEs.
 
   When computing or re-optimizing the routes of a set of LSPs through a
   network it may be advantageous to perform bulk path computations in
   order to avoid blocking problems and to achieve more optimal network-
   wide solutions.  Such bulk optimization is termed Global Concurrent
   Optimization.
 
   This document provides application-specific requirements and the PCEP
   extensions in support of a global concurrent path computation
   application.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt
 
To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
 
Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-lee-pce-global-concurrent-optimization-01.txt".
 
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 
Internet-Drafts can also be obtained by e-mail.
 
Send a message to:
               mailserv at ietf.org.
In the body type:
               "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt".
               
NOTE:     The mail server at ietf.org can return the document in
               MIME-encoded form by using the "mpack" utility.  To use this
               feature, insert the command "ENCODING mime" before the "FILE"
               command.  To decode the response(s), you will need "munpack" or
               a MIME-compliant mail reader.  Different MIME-compliant mail readers
               exhibit different behavior, especially when dealing with
               "multipart" MIME messages (i.e. documents which have been split
               up into multiple messages), so check your local documentation on
               how to manipulate these messages.
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt> 

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

 

 

--Boundary_(ID_hotCUioXsNhe0Z9xTEQ9UQ)-- --Boundary_(ID_owV1AthqLy67eqCWzQkE0g) Content-type: text/plain; name=draft-lee-pce-global-concurrent-optimization-01.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-lee-pce-global-concurrent-optimization-01.txt Network Working Group Y. Lee Internet-Draft Huawei Intended status: Standards Track JL. Le Roux Expires: August 2, 2007 France Telecom D. King Aria Networks E. Oki NTT January 29, 2007 Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization draft-lee-pce-global-concurrent-optimization-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lee, et al. Expires August 2, 2007 [Page 1] Internet-Draft PCE Global Concurrent Optimization January 2007 Abstract The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. Lee, et al. Expires August 2, 2007 [Page 2] Internet-Draft PCE Global Concurrent Optimization January 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability of Global Concurrent Path Computation . . . . . 7 3.1. Greenfield Optimization . . . . . . . . . . . . . . . . . 7 3.1.1. Single-layer Traffic Engineering . . . . . . . . . . . 7 3.1.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 3.3. Application of the PCE Architecture . . . . . . . . . . . 9 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol extensions for support of global concurrent optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Global Concurrent Optimization Indication . . . . . . . . 16 5.2. Global Objective Function (GOF) Specification . . . . . . 16 5.3. Indication of Global Concurrent Requests . . . . . . . . . 17 5.4. Request for the order of LSP . . . . . . . . . . . . . . . 17 5.5. The Order Response . . . . . . . . . . . . . . . . . . . . 18 5.6. Global Constraints (GC) Object . . . . . . . . . . . . . . 20 5.7. Multi-Session Processing . . . . . . . . . . . . . . . . . 21 5.8. Error Indicator . . . . . . . . . . . . . . . . . . . . . 23 5.9. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 23 6. Manageability Considerations . . . . . . . . . . . . . . . . . 25 6.1. Control of Function and Policy . . . . . . . . . . . . . . 25 6.2. Information and Data Models, e.g. MIB module . . . . . . . 25 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25 6.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 25 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 25 6.7. Other Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Lee, et al. Expires August 2, 2007 [Page 3] Internet-Draft PCE Global Concurrent Optimization January 2007 1. Terminology The terminology explained herein complies with [RFC4655]. PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. PCECP: The PCE Communication Protocol: PCECP is the generic abstract idea of a protocol that is used to communicate path computation requests from PCCs to a PCE, and to return computed paths from the PCE to the PCCs. The PCECP can also be used between cooperating PCEs. PCEP: The PCE communication Protocol: PCEP is the actual protocol that implements the PCECP idea. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These terms are also used in the parts of this document that specify requirements for clarity of specification of those requirements. Lee, et al. Expires August 2, 2007 [Page 4] Internet-Draft PCE Global Concurrent Optimization January 2007 2. Introduction [RFC4655] defines the PCE based Architecture and explains how a PCE may compute the paths of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) at the request of PCCs. A PCC is shown to be any network component that makes such a request and may be a Label Switching Router (LSR) or a Network Management System (NMS). The PCE, itself, is shown to be located anywhere within the network, and may be within an LSR, an NMS or Operational Support System (OSS), or may be an independent network server. The PCECP is the communication protocol used between PCC and PCE, and may also be used between cooperating PCEs. [RFC4657] sets out the common protocol requirements for the PCECP. Additional application- specific requirements for PCECP are deferred to separate documents. This document provides a set of PCECP extension requirements and solutions in support of concurrent path computation applications that may arise during network operations. A concurrent path computation is a path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. The computation method involved with a concurrent path computation is referred to as global concurrent optimization in this document. Appropriate computation algorithms to perform this type of optimization are out of the scope of this document. As new LSPs are added sequentially or removed from the network over time, the global network resources become fragmented and the network no longer provides the optimal use of the available capacity. A global concurrent path computation is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to re-optimize the entire network to satisfy all constraints for all LSPs. Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology. The need for a gloabl concurrent path computation may also arise when network operators need to set up a large number of TE LSPs in their network planning process. A global concurrent path computation is typically an off-line computation. This document does not exclude the possibility that network operators might require on-line computation for a global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted in real-time. The off-line computation requirements to support a set of TE LSPs are quite different from on-line path computation requirements. While Lee, et al. Expires August 2, 2007 [Page 5] Internet-Draft PCE Global Concurrent Optimization January 2007 on-line path computation is focused on finding a single best path in a timely manner given the prevailing network conditions, an off-line path computation application involves finding paths for a set of TE LSPs concurrently to meet a global objective. While off-line computation may not require such stringent time constraints as on- line path computation, the key objective associated with off-line computation is to efficiently allocate network resources from a global network perspective. While on-line path computation is tactical, off-line path computation is strategic. As the PCE is envisioned to provide solutions in all path computation matters, it is anticipated that the PCE would provide solutions for global concurrent path computation needs. The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation application and to define protocol extensions to meet those needs. The PCC-PCE requirements addressed herein are specific to the context where the PCE is a specialized PCE that is capable of solving global concurrent path computation applications. Discovery of such capabilities might be desirable and could be achieved through extensions to the PCE discovery mechanisms [RFC4674], but that is out of the scope of this document. Lee, et al. Expires August 2, 2007 [Page 6] Internet-Draft PCE Global Concurrent Optimization January 2007 3. Applicability of Global Concurrent Path Computation This section discusses scenarios for which global concurrent path computation may be applied. It also discusses how these scenarios apply to the PCE architecture. 3.1. Greenfield Optimization When a new TE network needs to be provisioned from a green-field perspective, a set of TE LSPs need to be created based on traffic demand, network topology, service constraints, and network resources. Under this scenario, concurrent computation ability is highly desirable, or required, to utilize network resources in an optimal manner and avoid blocking risks. Sequential path computation could potentially result in sub-optimal use of network resources or even blocking issues. 3.1.1. Single-layer Traffic Engineering Greenfield optimization can be applied when layer-specific TE LSPs need to be created from a green-field perspective. For example, MPLS-TE network can be established based on layer 3 specific traffic demand, network topology, and network resources. Greenfield optimization for single-layer traffic engineering can be applied to lower layer networks such as SDH/Sonet, Ethernet Transport, WDM, etc. 3.1.1.1. Pre-establishment of the Hierarchical-LSP (H-LSP)in the Transport Network When an optical transport layer provides lower-layer traffic engineered LSPs for upper-layer client LSPs via the Hierarchical LSP (H-LSP) mechanism, the operator may desire to pre-establish optical LSPs in the optical transport network [MLN-REQ]. This whole multi- layer network can be managed using PCE [PCE-MLN]. In this scenario, it is anticipated that a set of H-LSPs would be created concurrently in such a way as to efficiently utilize network resources in the lower-layer network. Again, concurrent path computation capability would result in more efficient network resource utilization than sequential path computation. 3.1.1.2. VNT Configuration A set of one or more of lower-layer LSPs providing information for efficient path handling in upper-layer(s) can be described as a virtual network topology (VNT)[MLN-REQ]. When the VNT [MLN-REQ] is configured for the first time, greenfield concurrent optimization may well be applied to find a set of LSPs Lee, et al. Expires August 2, 2007 [Page 7] Internet-Draft PCE Global Concurrent Optimization January 2007 more efficiently than sequential path computation. 3.1.2. Multi-layer Traffic Engineering Greenfield optimization is not limited to single-layer traffic engineering. It can also be applied in multi-layer traffic engineering. Both the client and the server layers network resources and topology can be considered simultaneously in setting up a set of TE LSPs that traverse the layer boundary. 3.2. Re-optimization of Existing Networks The need for global concurrent path computation may also arise in existing networks. When an existing TE LSP network experiences sub- optimal use of its resources, the need for re-optimization or reconfiguration may arise. The scope of re-optimization and reconfiguration may vary depending on particular situations. The scope of re-optimization may be limited to bandwidth modification to an existing TE LSP. However, it could well be that a large number of TE LSPs may need to be re-optimized concurrently. In an extreme case, the TE LSPs may need to be globally re-optimized. Note that sequential re-optimization of such TE LSPs is unlikely to produce substantial improvements in overall network optimization except in very sparsely utilized networks. 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) Reconfiguration of the VNT [MLN-REQ] is another application scenario where global concurrent path computation may be applicable. Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes, may require a large set of existing LSPs to be re-computed. Again, concurrent path computation capability would result in more efficient network resource utilization than sequential path computation. 3.2.2. Traffic Migration When migrating from one set of TE LSPs to a reoptimized set of TE LSPs it is important that the traffic be moved without causing disruption. Various techniques exist in MPLS and GMPLS, such as make-before-break [RFC3209], to establish the new LSPs before tearing down the old LSPs. When multiple LSP routes are changed according to the computed results, some of the LSPs may be disrupted due to the resource constraints. In other words, it may prove to be impossible to perform a direct migration from the old LSPs to the new optimal LSPs without disrupting traffic because there are insufficient network resources to support both sets of LSPs when make-before-break is used. However, the PCE may be able determine an order of LSP Lee, et al. Expires August 2, 2007 [Page 8] Internet-Draft PCE Global Concurrent Optimization January 2007 rerouting actions so that make-before-break can be performed within the limited resources. However, it may be the case that the reoptimization is radical. This could mean that it is not possible to apply make-before-break in any order to migrate from the old LSPs to the new LSPs. In this case a migration strategy is required that may necessitate LSPs being rerouted using make-before-break onto temporary paths in order to make space for the full reoptimization. A PCE might indicate the order in which reoptimized LSPs must be established and take over from the old LSPs, and may indicate a series of different temporary paths that must be used. Alternatively, the PCE might perform the global reoptimization as a series of sub-reoptimizations by reoptimizing subsets of the total set of LSPs. Note also that during reoptimization, traffic disruption may be allowed for some LSPs carrying low priority services (e.g., Internet traffic) and not allowed for some LSPs carrying mission critical services (e.g., voice traffic). 3.3. Application of the PCE Architecture Figure 1 shows how the aforementioned functionality applies within the PCE architecture. It must be observed that the PCC is not necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as remote from the NMS, it might be collocated with the NMS. Upon receipt of an application request (e.g., a traffic demand matrix is provided to the NMS by the operator's network planning procedure), the NMS requests a global concurrent path computation from the PCE. The PCE then computes the requested paths concurrently applying some algorithms. When the requested path computation completes, the PCE sends the resulting paths back to the NMS. The NMS then supplies the head-end LSRs with a fully computed explicit path for each TE LSP that needs to be established. Lee, et al. Expires August 2, 2007 [Page 9] Internet-Draft PCE Global Concurrent Optimization January 2007 ----------- Application | ----- | Request | | TED | | | | ----- | v | | | ------------- Request/ | v | | | Response| ----- | | NMS |<--------+> | PCE | | | | | ----- | ------------- ----------- Service | Request | v ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<---------->| Node | ---------- ---------- Figure 1: PCE-Based Architecture for Global Concurrent Optimization Lee, et al. Expires August 2, 2007 [Page 10] Internet-Draft PCE Global Concurrent Optimization January 2007 4. PCECP Requirements This section provides the PCECP requirements to support large-scale concurrent path computation applications. The requirements specified here should be regarded as application-specific requirements and are justifiable based on the extensibility clause found in section 6.1.14 of [RFC4657]: The PCECP MUST support the requirements specified in the application-specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future. It is also to be noted that some of the requirements discussed in this section have already been discussed in the PCECP requirement document [RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list of generic constraints while Section 5.1.17 in [RFC4657] provides a list of generic objective functions that MUST be supported by the PCECP. While using such generic requirements as the baseline, this section provides application-specific requirements in the context of global concurrent path computation and in a more detail level than the generic requirements. The PCEP SHOULD support the following capabilities either via creation of new objects and/or modification of existing objects where applicable. o An indicator to convey that the request is for a global concurrent path computation. This indicator is necessary to ensure consistency in applying global objectives and global constraints in all path computations. Note: This requirement is covered by "synchronized path computation" in [RFC4655] and [RFC4657]. However, an explicit indicator to request a global concurrent optimization is a new requirement. o A Global Objective Function (GOF) field in which to specify the global objective function. The global objective function is the overarching objective function to which all individual path computation requests are subjected in order to find a globally optimal solution. Note that this requirement is covered by "synchronized objective functions" in section 5.1.7 [RFC4657]. A list of available global objective functions SHOULD include the following objective functions at the minimum and SHOULD be expandable for future addition: * Minimize the sum of all TE LSP costs (min cost) Lee, et al. Expires August 2, 2007 [Page 11] Internet-Draft PCE Global Concurrent Optimization January 2007 * Maximize the residual bandwidth on the most loaded link * Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. o A Global Constraints (GC) field in which to specify the list of global constraints to which all the requested path computations should be subjected. This list SHOULD include the following constraints at the minimum and SHOULD be expandable for future addition: * Maximum link utilization value -- This value indicates the highest possible link utilization percentage set for each link. (Note: to avoid floating point numbers, the values should be integer values.) * Minimum link utilization value -- This value indicates the lowest possible link utilization percentage set for each link. (Note: same as above) * Overbooking Factor -- The overbooking factor allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. * Maximum number of hops for all the LSPs -- This is the largest number of hops that any LSP can have. Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * Exclusion of links/nodes in all LSP path computation (i.e., all LSPs should not include the specified links/nodes in their paths). Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * An indication should be available in a path computation response that further reoptimization may only become available once existing traffic has been moved to the new LSPs. o A Global Concurrent Vector (GCV) field in which to specify all the individual path computation requests that are subject to concurrent path computation and subject to the global objective function and all of the global constraints. Note that this requirement is partially fulfilled by the SVEC object in the PCEP specification [PCEP]. Since the SVEC object as defined in [PCEP] Lee, et al. Expires August 2, 2007 [Page 12] Internet-Draft PCE Global Concurrent Optimization January 2007 allows identifying a set of concurrent path requests, the SVEC can be reused to specify all the individual concurrent path requests for a global concurrent optimization. This can be achieved by defining a new flag in the SVEC object to indicate that this is a global concurrent optimization. o An indicator field in which to indicate the outcome of the request. When the PCE could not find a feasible solution with the initial request, the reason for failure SHOULD be indicated. This requirement is partially covered by [RFC4657], but not in this level of detail. The following indicators SHOULD be supported at the minimum: * no feasible solution found. Note that this is already covered in [PCEP]. * memory overflow * PCE too busy. Note that this is already covered in [PCEP]. * PCE not capable of concurrent reoptimization * no migration path available * administrative privileges do not allow global reoptimization o A Multi-Session Indicator field in the case where the original request is sub-divided into multiple sessions. This case may arise when the reason for failure of the original request is due to mathematical infeasibility, or memory overflow. The PCC may follow up with subsequent actions under a local policy. The motivation for multi-session application is to find a partial feasible solution in the absence of the optimal solution. When the PCC decides to scale down the original request into several sessions, the PCC sends the first session path computation request to the PCE. The next session path computation request is held until the results from the first session would be available. Once the results from the first session are available, the PCC then sends the second session path computation request to the PCE. The same procedure is repeated until the last session of the multiple session has been completed. To support this requirement, it is required that the PCE keep in memory the previously computed paths until all paths of the multi-session have been computed. * Multi-Session Indicator * Multi-Session Sequence Number Lee, et al. Expires August 2, 2007 [Page 13] Internet-Draft PCE Global Concurrent Optimization January 2007 * The Indication of the Final Session o In order to minimize disruption associated with bulk path provisioning, the following requirements MUST be supported: * The request message MUST allow requesting the PCE to provide the order in which LSPs should be reoptimized (i.e., the migration path) in order to minimize traffic disruption during the migration. That is the request message MUST allow indicating the PCE that the set of paths that will be provided in the response message (PCRep) has to be ordered. * In response to the "ordering" request from the PCC, the PCE MUST be able to indicate in the response message (PCRep) the order in which LSPs should be reoptimized so as to minimize traffic disruption. It should indicate for each request the order in which the old LSP should be removed and the order in which the new LSP should be setup. If the removal order is lower than the setup order this means that make-before-break cannot be done for this request. * As stated in RFC 4657, the request for a reoptimization MUST support the inclusion of the set of previously computed paths along with their bandwidth. This is to avoid double bandwidth accounting and also this allows running an algorithm that minimizes perturbation and that can compute a migration path (LSP setup/removal orders). This is particularly required for stateless PCEs. * During a migration it may not be possible to do a make-before- break for all existing LSPs. The request message must allow indicating for each request whether make-before-break is required (e.g. Voice traffic) or break-before-make is acceptable (e.g. Internet traffic). The response message must allow indicating LSPs for which make-before-break reoptimization is not possible (this will be deduced from the LSP setup and deletion orders). * During a reoptimization it may be required to move a LSP several times so as to avoid traffic disruption. The response message must allow indicating the path sequence for each request. Lee, et al. Expires August 2, 2007 [Page 14] Internet-Draft PCE Global Concurrent Optimization January 2007 5. Protocol extensions for support of global concurrent optimization This section provides protocol extensions for support of global concurrent optimization. Protocol extensions discussed in this section are built on [PCEP]. The format of a PCReq message is currently as follows per [PCEP]: ::= [] where: ::= [] ::= [] ::= [] [] [] [] [] [] [] The format of a PCReq message after incorporating new requirements for support of global concurrent optimization is as follows: ::= [] The is changed as follows: :: = [] [] [] [] Note that in the SVEC-list two new optional objects have been defined: the GOF (Global Objective Function) Object and the GC (Global Constraints) Object. Note also that the XRO is also added as an optional Object in the list. Details of this change will be discussed in the following sections. Lee, et al. Expires August 2, 2007 [Page 15] Internet-Draft PCE Global Concurrent Optimization January 2007 5.1. Global Concurrent Optimization Indication A global concurrent path computation request from other types of computation request can be implicitly indicated by the presence of the GOF object in the new SVEC-list as defined in the previous section. That is when the SVEC-list includes the GOF object, it indicates a request for global concurrent optimization. It can also be explicitly indicated by the C flag in the SVEC object. 5.2. Global Objective Function (GOF) Specification The global objective function can be specified in the GOF object. The format of the GOF object body that includes the global objective function is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Objective Function ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: GOF body object format The Objective Function ID (16 bit) identifies the objective function for global concurrent request. Currently three global objective functions are identified. Other objective functions may be defined later. 1: Minimize the sum of all TE LSP costs (min cost) 2: Maximize the residual bandwidth on the most loaded link 3: Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)- A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. GOF Object-Class is to be assigned by IANA. GOF Object-Type is to be assigned by IANA. Lee, et al. Expires August 2, 2007 [Page 16] Internet-Draft PCE Global Concurrent Optimization January 2007 5.3. Indication of Global Concurrent Requests All the path requests in this application should be indicated so that the global objective function and all of the global constraints are applied to each of the requested path computation. In order to support this requirement, the SVEC object should be modified as follows. C flag (1 bit): This is a new flag in the SVEC object. When C flag is set, this indicates that all of the path request listed in the body of the SVEC object should be computed applying the global constraints and the global objective function. When the C Flag is set in the SVEC Object, the GOF and the GC objects should directly follow the SVEC Object. Therefore, the format of the PCReq is modified as follows: ::= [] The is changed as follows: ::= [] [] [] [] 5.4. Request for the order of LSP In order to minimize disruption associated with bulk path provisioning, the PCC MAY indicate to the PCE that the response MUST be ordered. That is, it MUST include the order in which LSPs MUST be moved so as to minimize traffic disruption. Such indication can be included in the RP object which is revised as follows: Lee, et al. Expires August 2, 2007 [Page 17] Internet-Draft PCE Global Concurrent Optimization January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|M|F|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: RP object body format in the PCReq Message D bit (orDer - 1 bit): when set, in a PCReq message, the requesting PCC requires the PCE to specify in the PCRep message the order in which this particular path request is to be provisioned relative to other requests. M bit (Make-before-break - 1 bit): when set, this indicates that a make-before-break reoptimization is required for this request. When M bit is not set, this implies that this request is allowed to a break-before-make reoptimization. Note that M bit can be set only if the R and D flags are set. All other fields are unchanged from [PCEP]. 5.5. The Order Response The PCE MUST specify the order number in response to the Order Request made by the PCC in the PCReq message if so requested by the setting of the D bit in the RP object in the PCReq message. The format of the RP object body to be included in the PCRep message is modified as follows: Lee, et al. Expires August 2, 2007 [Page 18] Internet-Draft PCE Global Concurrent Optimization January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|M|F|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Order TLV (Optional TLV) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: RP object body format in the PCRep Message The Order TLV is an optional TLV in the RP object, that indicates the order in which the old LSP must be removed and the new LSP must be setup during a reoptimization. It is carried in the PCRep message in response to a reoptimization request. The Order TLV SHOULD be included in the RP object in the PCRep message if the D bit is set in the RP object in the PCReq message. The format of the Order TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delete Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be defined by IANA (suggested value = ) Length Variable Value Orders in which the old path should be removed and the new path should be setup Figure 8: The Order TLV in the RP object in the PCRep Message Delete Order: 32 bit integer that indicates the order in which the old LSP should be removed Lee, et al. Expires August 2, 2007 [Page 19] Internet-Draft PCE Global Concurrent Optimization January 2007 Setup Order: 32 bit integer that indicates the order in which the new LSP should be setup The delete order should not be equal to the setup order. If the delete order is higher than the setup order, this means that the reoptimization can be done in a make-before-break manner, else it cannot be done in a make-before-break manner. To illustrate, consider a network with two established requests: R1 with path P1 and R2 with path P2. During a reoptimization the PCE may provide the following ordered reply: R1, path P1', remove order 1, setup order 4 R2, path P2', remove order 3, setup order 2 This indicates that the NMS should do the following sequence of tasks: 1: Remove path P1 2: Setup path P2' 3: Remove path P2 4: Setup path P1' That is, R1 is reoptimized in a break-before-make manner and R2 in a make-before-break manner. 5.6. Global Constraints (GC) Object The Global Constraints (GC) Object is used in a PCReq message to specify the necessary global constraints that should be applied to all individual path computations for a global concurrent path optimization request. The format of the GC object body that includes the global constraints is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MU | mU | OB | MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires August 2, 2007 [Page 20] Internet-Draft PCE Global Concurrent Optimization January 2007 Figure 11: GC body object format MU (Max Utilization) (8 bits) : 8 bit integer that indicates the upper bound utilization percentage by which all link should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the lower bound utilization percentage by which all link should be bound. OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the overbooking percentage that allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. The value, for example, 10% means that 110 Mbps can be reserved on a 100Mbps link. MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop count for all the LSPs. GC Object-Class is to be assigned by IANA. GC Object-Type is to be assigned by IANA. The exclusion of the list of nodes/links from a global path computation can be done by including the XRO object following the GC object in the new SVEC definition. 5.7. Multi-Session Processing When the initial global concurrent path computation request fails due to scaling issues or memory overflow as indicated in the PCEP-ERROR object in the PCRep message, multi-session processing may be proceeded in an attempt to find a feasible solution in the absence of an optimal solution. This should be driven by local policy decision. How to divide up the original global concurrent optimization problem into a number of smaller-scale optimization problems is out of the scope of this document. In order to meet these multi-session requirements, a new object, the Multi-Session (MS) object is required. This object should be defined on a per message basis. The message is modified as follows: ::= [] [] Lee, et al. Expires August 2, 2007 [Page 21] Internet-Draft PCE Global Concurrent Optimization January 2007 The format of the MSO object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Multi-Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MSO object body format Multi-Session ID (16 bits): 16 bit integer that identifies the multi- session computation. The Multi-Session ID will allow to map all request messages for the same global computation. Sequence Number (16 bits): 16 bit integer that indicates the sequence number of the current multi-session request. This should be incremented for each new request message during a multi-session request until the final request is performed. F (Final session - 1 bit): When set, the requesting PCC indicates that the PCReq message is the final session of a multi-session request. When it is not set, the PCE SHOULD keep in memory all the computed paths until the final session of a multi-session is completed. This is necessary to correctly account for already computed LSPs. MS Object-Class is to be assigned by IANA. MS Object-Type is to be assigned by IANA. For PCE not able to temporarily maintain previously computed paths, the multi-session capability can be provided by simply adding the ERO object and the Bandwidth object following the RP object in the PCReq message. The ERO and the Bandwidth objects together provide all of the previously computed paths by the PCE. In order to distinguish a previously computed request from a new request, a new flag in the RP object is required. A (Already computed request - 1 bit): When set, this indicates that the request has already been computed in a previous session, and its result (as indicated by the ERO and the Bandwidth Object following Lee, et al. Expires August 2, 2007 [Page 22] Internet-Draft PCE Global Concurrent Optimization January 2007 the RP object) must be taken account in the current session. 5.8. Error Indicator To indicate errors associated with the global concurrent path optimization request, a new Error-Type (11) and subsequent error- values are defined as follows for inclusion in the PCEP-ERROR object: A new Error-Type (11) and subsequent error-values are defined as follows: Error-Type=14 and Error-Value=1: if a PCE receives a global concurrent path optimization request and the PCE is not capable of the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP ERROR object (Error-Type=14) and an Error-Value (Error-Value=1). The corresponding global concurrent path optimization request MUST be cancelled. Error-Type=14; Error-Value=2: if a PCE receives a global concurrent path optimization request and the PCE is not capable of global concurrent optimization, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). The corresponding global concurrent path optimization MUST be cancelled. Error-Type=14; Error-Value=3: if a PCE receives a global concurrent path optimization request which is not compliant with administrative privileges (i.e., the PCE policy does not support global concurrent optimization), the PCE send a PCErr message with a PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=3). The corresponding global concurrent path computation MUST be cancelled. 5.9. NO-PATH Indicator To communicate the reason(s) for not being able to find global concurrent path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|G|M| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires August 2, 2007 [Page 23] Internet-Draft PCE Global Concurrent Optimization January 2007 Figure 14: NO-PATH object format Flags (16 bits). The C flag is defined in [PCEP]. Two additional flags are defined to support other reasons why the path computation fails: G flag (1 bit) and M flag (1 bit). M flag (1 bit): when set, the PCE indicates that no migration path was found. G flag (1 bit): when set, the PCE indicates no feasible solution was found that meets all the constraints associated with global concurrent path optimization in the PCRep message. When either M or G flag is set in the PCRep Message, a subsequent multi-session feature may be triggered if the PCC's local policy allows it. The multi-session feature allows the original global concurrent optimization to be split into a number of multiple sessions so that the PCE would compute a number of smaller-scale optimizations in a sequential manner. The trade-off is that a partial feasible solution may be obtained using this approach which is better than not having any solution at all, although such solution might not be a global optimal solution. How to divide up the original large-scale global concurrent optimization into a multiple number of smaller-scale optimizations is out of the scope of this document. See Section 5.7 for multi-session processing details. Lee, et al. Expires August 2, 2007 [Page 24] Internet-Draft PCE Global Concurrent Optimization January 2007 6. Manageability Considerations Manageability of Global Concurrent Path Computation with PCE must address the following considerations: 6.1. Control of Function and Policy This sub-section will describe the configurable items that exist for the control of global concurrent optimization functions or policies. 6.2. Information and Data Models, e.g. MIB module This sub-section will describe the information and data models necessary for the protocol or the protocol extensions. This includes, but is not necessarily limited to, the MIB modules developed specifically for the protocol functions specified in the document. 6.3. Liveness Detection and Monitoring This sub-section will describe liveness detection and monitoring requirements for both the control plane and the data plane. 6.4. Verifying Correct Operation This sub-section will describe Operations and Management (OAM) features and functions for verifying the correct operation. 6.5. Requirements on Other Protocols and Functional Components This sub-section will describe requirements or refer to the sections that discuss the impact of global concurrent optimization on existing protocols. 6.6. Impact on Network Operation This sub-section will discuss the impact on the operation of existing networks. 6.7. Other Considerations This sub-section will cover those manageability requirements not specifically in previous sub-sections. Lee, et al. Expires August 2, 2007 [Page 25] Internet-Draft PCE Global Concurrent Optimization January 2007 7. Security Considerations When global re-optimization is applied to an active network, it could be extremely disruptive. Although the real security and policy issues apply at the NMS, if the wrong results are returned to the NMS, the wrong actions may be taken in the network. Therefore, it is very important that the operator issuing the commands has sufficient authority and is authenticated, and that the computation request is subject to appropriate policy. The mechanisms defined in [PCEP] to secure a PCEP session (MD-5 authentication, etc.) apply here as well. Lee, et al. Expires August 2, 2007 [Page 26] Internet-Draft PCE Global Concurrent Optimization January 2007 8. Acknowledgements We would like to thank Jerry Ash, Adrian Farrel, Ning So and Lucy Yong for their useful comments and suggestions. Lee, et al. Expires August 2, 2007 [Page 27] Internet-Draft PCE Global Concurrent Optimization January 2007 9. IANA Considerations A future revision of this document will present requests to IANA for codepoint allocation. Lee, et al. Expires August 2, 2007 [Page 28] Internet-Draft PCE Global Concurrent Optimization January 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. 10.2. Informative References [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- region and multi-layer networks (MRN/MLN), draft-ietf-ccamp-gmpls-mln-reqs, work in progress". [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- based inter-layer MPLS and GMPL traffic engineering, draft-ietf-pce-inter-layer-frwk, work in progress.". [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1, draft-ietf-pce-pcep-04.txt, work in progress". [RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery, draft-ietf-pce-discovery-reqs, work in progress.". Lee, et al. Expires August 2, 2007 [Page 29] Internet-Draft PCE Global Concurrent Optimization January 2007 Authors' Addresses Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: ylee@huawei.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Daniel King Aria Networks 44/45 Market Place Chippenham SN15 3HU United Kingdom Phone: +44 7790 775187 Fax: +44 1249 446530 Email: daniel.king@aria-networks.com Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585 JAPAN Email: oki.eiji@lab.ntt.co.jp Lee, et al. Expires August 2, 2007 [Page 30] Internet-Draft PCE Global Concurrent Optimization January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires August 2, 2007 [Page 31] --Boundary_(ID_owV1AthqLy67eqCWzQkE0g) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Boundary_(ID_owV1AthqLy67eqCWzQkE0g)-- From pce-bounces@lists.ietf.org Wed Jan 31 08:49:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFpH-0002CF-Dj; Wed, 31 Jan 2007 08:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBerC-0003JR-I9 for pce@ietf.org; Mon, 29 Jan 2007 17:20:10 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBer9-0007E6-DU for pce@ietf.org; Mon, 29 Jan 2007 17:20:10 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN00I0MI1FCS@usaga01-in.huawei.com> for pce@ietf.org; Mon, 29 Jan 2007 14:20:04 -0800 (PST) Received: from huawei.com ([172.18.4.47]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN009T5I17LK@usaga01-in.huawei.com> for pce@ietf.org; Mon, 29 Jan 2007 14:20:03 -0800 (PST) Received: from Lee736821 ([10.124.12.86]) by usaml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00AX8IJG8Q@usaml03-in.huawei.com> for pce@ietf.org; Mon, 29 Jan 2007 14:30:57 -0800 (PST) Date: Mon, 29 Jan 2007 16:19:50 -0600 From: Young Lee To: pce@ietf.org Message-id: <001401c743f3$98583520$560c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_NHxcN+rJUCwz4Ojzu5JTXA)" Thread-index: AcdD85dum6IPvGbvTNaBdduDcsjDkg== X-Spam-Score: 0.0 (/) X-Scan-Signature: f2a42a2af3bbcd3f35e4f1de597f9a9f X-Mailman-Approved-At: Wed, 31 Jan 2007 08:48:38 -0500 Cc: Subject: [Pce] PCE Global Concurrent Optimization X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --Boundary_(ID_NHxcN+rJUCwz4Ojzu5JTXA) Content-type: multipart/alternative; boundary="Boundary_(ID_NaSFNGibIW/I940V+ERVWA)" --Boundary_(ID_NaSFNGibIW/I940V+ERVWA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello all, We have submitted the following I-D. As we have made significant progress on this I-D from the previous version, we'd appreciate your comments and suggestions. Regards, Young, Jean-Louis, Dan and Eiji ------Original Message-------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization Author(s) : Y. Lee, et al. Filename : draft-lee-pce-global-concurrent-optimization-01.txt Pages : 31 Date : 2007-1-29 The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimiza tion-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-lee-pce-global-concurrent-optimization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_NaSFNGibIW/I940V+ERVWA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello all,

 

We have submitted the following I-D.  As we have made significant progress on this I-D from the previous version, we’d appreciate your comments and suggestions.  

 

Regards,

 

Young, Jean-Louis, Dan and Eiji

 

------Original Message--------

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
 
 
               Title                        : Path Computation Element Communication 
                          Protocol (PCECP) Requirements and Protocol 
                          Extensions In Support of Global Concurrent Optimization
               Author(s) : Y. Lee, et al.
               Filename : draft-lee-pce-global-concurrent-optimization-01.txt
               Pages                     : 31
               Date                       : 2007-1-29
               
The Path Computation Element (PCE) is a network component,
   application, or node that is capable of performing path computations
   at the request of Path Computation Clients (PCCs).  The PCE is
   applied in Multiprotocol Label Switching Traffic Engineering
   (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to
   determine the routes of Label Switched Paths (LSPs) through the
   network.  The Path Computation Element Communication Protocol (PCEP)
   is specified for communications between PCCs and PCEs, and between
   cooperating PCEs.
 
   When computing or re-optimizing the routes of a set of LSPs through a
   network it may be advantageous to perform bulk path computations in
   order to avoid blocking problems and to achieve more optimal network-
   wide solutions.  Such bulk optimization is termed Global Concurrent
   Optimization.
 
   This document provides application-specific requirements and the PCEP
   extensions in support of a global concurrent path computation
   application.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt
 
To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request at ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
 
Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-lee-pce-global-concurrent-optimization-01.txt".
 
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 
Internet-Drafts can also be obtained by e-mail.
 
Send a message to:
               mailserv at ietf.org.
In the body type:
               "FILE /internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt".
               
NOTE:     The mail server at ietf.org can return the document in
               MIME-encoded form by using the "mpack" utility.  To use this
               feature, insert the command "ENCODING mime" before the "FILE"
               command.  To decode the response(s), you will need "munpack" or
               a MIME-compliant mail reader.  Different MIME-compliant mail readers
               exhibit different behavior, especially when dealing with
               "multipart" MIME messages (i.e. documents which have been split
               up into multiple messages), so check your local documentation on
               how to manipulate these messages.
 
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-lee-pce-global-concurrent-optimization-01.txt> 

_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

 

--Boundary_(ID_NaSFNGibIW/I940V+ERVWA)-- --Boundary_(ID_NHxcN+rJUCwz4Ojzu5JTXA) Content-type: text/plain; name=draft-lee-pce-global-concurrent-optimization-01.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-lee-pce-global-concurrent-optimization-01.txt Network Working Group Y. Lee Internet-Draft Huawei Intended status: Standards Track JL. Le Roux Expires: August 2, 2007 France Telecom D. King Aria Networks E. Oki NTT January 29, 2007 Path Computation Element Communication Protocol (PCECP) Requirements and Protocol Extensions In Support of Global Concurrent Optimization draft-lee-pce-global-concurrent-optimization-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Lee, et al. Expires August 2, 2007 [Page 1] Internet-Draft PCE Global Concurrent Optimization January 2007 Abstract The Path Computation Element (PCE) is a network component, application, or node that is capable of performing path computations at the request of Path Computation Clients (PCCs). The PCE is applied in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to determine the routes of Label Switched Paths (LSPs) through the network. The Path Computation Element Communication Protocol (PCEP) is specified for communications between PCCs and PCEs, and between cooperating PCEs. When computing or re-optimizing the routes of a set of LSPs through a network it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network- wide solutions. Such bulk optimization is termed Global Concurrent Optimization. This document provides application-specific requirements and the PCEP extensions in support of a global concurrent path computation application. Lee, et al. Expires August 2, 2007 [Page 2] Internet-Draft PCE Global Concurrent Optimization January 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability of Global Concurrent Path Computation . . . . . 7 3.1. Greenfield Optimization . . . . . . . . . . . . . . . . . 7 3.1.1. Single-layer Traffic Engineering . . . . . . . . . . . 7 3.1.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 3.3. Application of the PCE Architecture . . . . . . . . . . . 9 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol extensions for support of global concurrent optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Global Concurrent Optimization Indication . . . . . . . . 16 5.2. Global Objective Function (GOF) Specification . . . . . . 16 5.3. Indication of Global Concurrent Requests . . . . . . . . . 17 5.4. Request for the order of LSP . . . . . . . . . . . . . . . 17 5.5. The Order Response . . . . . . . . . . . . . . . . . . . . 18 5.6. Global Constraints (GC) Object . . . . . . . . . . . . . . 20 5.7. Multi-Session Processing . . . . . . . . . . . . . . . . . 21 5.8. Error Indicator . . . . . . . . . . . . . . . . . . . . . 23 5.9. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 23 6. Manageability Considerations . . . . . . . . . . . . . . . . . 25 6.1. Control of Function and Policy . . . . . . . . . . . . . . 25 6.2. Information and Data Models, e.g. MIB module . . . . . . . 25 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25 6.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 25 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 25 6.7. Other Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Lee, et al. Expires August 2, 2007 [Page 3] Internet-Draft PCE Global Concurrent Optimization January 2007 1. Terminology The terminology explained herein complies with [RFC4655]. PCC: Path Computation Client: Any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TED: Traffic Engineering Database which contains the topology and resource information of the domain. The TED may be fed by IGP extensions or potentially by other means. PCECP: The PCE Communication Protocol: PCECP is the generic abstract idea of a protocol that is used to communicate path computation requests from PCCs to a PCE, and to return computed paths from the PCE to the PCCs. The PCECP can also be used between cooperating PCEs. PCEP: The PCE communication Protocol: PCEP is the actual protocol that implements the PCECP idea. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. These terms are also used in the parts of this document that specify requirements for clarity of specification of those requirements. Lee, et al. Expires August 2, 2007 [Page 4] Internet-Draft PCE Global Concurrent Optimization January 2007 2. Introduction [RFC4655] defines the PCE based Architecture and explains how a PCE may compute the paths of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) at the request of PCCs. A PCC is shown to be any network component that makes such a request and may be a Label Switching Router (LSR) or a Network Management System (NMS). The PCE, itself, is shown to be located anywhere within the network, and may be within an LSR, an NMS or Operational Support System (OSS), or may be an independent network server. The PCECP is the communication protocol used between PCC and PCE, and may also be used between cooperating PCEs. [RFC4657] sets out the common protocol requirements for the PCECP. Additional application- specific requirements for PCECP are deferred to separate documents. This document provides a set of PCECP extension requirements and solutions in support of concurrent path computation applications that may arise during network operations. A concurrent path computation is a path computation application where a set of TE paths are computed concurrently in order to efficiently utilize network resources. The computation method involved with a concurrent path computation is referred to as global concurrent optimization in this document. Appropriate computation algorithms to perform this type of optimization are out of the scope of this document. As new LSPs are added sequentially or removed from the network over time, the global network resources become fragmented and the network no longer provides the optimal use of the available capacity. A global concurrent path computation is able to simultaneously consider the entire topology of the network and the complete set of existing LSPs, and their respective constraints, and look to re-optimize the entire network to satisfy all constraints for all LSPs. Alternatively, the application may consider a subset of the LSPs and/or a subset of the network topology. The need for a gloabl concurrent path computation may also arise when network operators need to set up a large number of TE LSPs in their network planning process. A global concurrent path computation is typically an off-line computation. This document does not exclude the possibility that network operators might require on-line computation for a global concurrent path computation in the event of catastrophic network failures, where a set of TE LSPs need to be optimally rerouted in real-time. The off-line computation requirements to support a set of TE LSPs are quite different from on-line path computation requirements. While Lee, et al. Expires August 2, 2007 [Page 5] Internet-Draft PCE Global Concurrent Optimization January 2007 on-line path computation is focused on finding a single best path in a timely manner given the prevailing network conditions, an off-line path computation application involves finding paths for a set of TE LSPs concurrently to meet a global objective. While off-line computation may not require such stringent time constraints as on- line path computation, the key objective associated with off-line computation is to efficiently allocate network resources from a global network perspective. While on-line path computation is tactical, off-line path computation is strategic. As the PCE is envisioned to provide solutions in all path computation matters, it is anticipated that the PCE would provide solutions for global concurrent path computation needs. The main focus of this document is to highlight the PCC-PCE communication needs in support of a concurrent path computation application and to define protocol extensions to meet those needs. The PCC-PCE requirements addressed herein are specific to the context where the PCE is a specialized PCE that is capable of solving global concurrent path computation applications. Discovery of such capabilities might be desirable and could be achieved through extensions to the PCE discovery mechanisms [RFC4674], but that is out of the scope of this document. Lee, et al. Expires August 2, 2007 [Page 6] Internet-Draft PCE Global Concurrent Optimization January 2007 3. Applicability of Global Concurrent Path Computation This section discusses scenarios for which global concurrent path computation may be applied. It also discusses how these scenarios apply to the PCE architecture. 3.1. Greenfield Optimization When a new TE network needs to be provisioned from a green-field perspective, a set of TE LSPs need to be created based on traffic demand, network topology, service constraints, and network resources. Under this scenario, concurrent computation ability is highly desirable, or required, to utilize network resources in an optimal manner and avoid blocking risks. Sequential path computation could potentially result in sub-optimal use of network resources or even blocking issues. 3.1.1. Single-layer Traffic Engineering Greenfield optimization can be applied when layer-specific TE LSPs need to be created from a green-field perspective. For example, MPLS-TE network can be established based on layer 3 specific traffic demand, network topology, and network resources. Greenfield optimization for single-layer traffic engineering can be applied to lower layer networks such as SDH/Sonet, Ethernet Transport, WDM, etc. 3.1.1.1. Pre-establishment of the Hierarchical-LSP (H-LSP)in the Transport Network When an optical transport layer provides lower-layer traffic engineered LSPs for upper-layer client LSPs via the Hierarchical LSP (H-LSP) mechanism, the operator may desire to pre-establish optical LSPs in the optical transport network [MLN-REQ]. This whole multi- layer network can be managed using PCE [PCE-MLN]. In this scenario, it is anticipated that a set of H-LSPs would be created concurrently in such a way as to efficiently utilize network resources in the lower-layer network. Again, concurrent path computation capability would result in more efficient network resource utilization than sequential path computation. 3.1.1.2. VNT Configuration A set of one or more of lower-layer LSPs providing information for efficient path handling in upper-layer(s) can be described as a virtual network topology (VNT)[MLN-REQ]. When the VNT [MLN-REQ] is configured for the first time, greenfield concurrent optimization may well be applied to find a set of LSPs Lee, et al. Expires August 2, 2007 [Page 7] Internet-Draft PCE Global Concurrent Optimization January 2007 more efficiently than sequential path computation. 3.1.2. Multi-layer Traffic Engineering Greenfield optimization is not limited to single-layer traffic engineering. It can also be applied in multi-layer traffic engineering. Both the client and the server layers network resources and topology can be considered simultaneously in setting up a set of TE LSPs that traverse the layer boundary. 3.2. Re-optimization of Existing Networks The need for global concurrent path computation may also arise in existing networks. When an existing TE LSP network experiences sub- optimal use of its resources, the need for re-optimization or reconfiguration may arise. The scope of re-optimization and reconfiguration may vary depending on particular situations. The scope of re-optimization may be limited to bandwidth modification to an existing TE LSP. However, it could well be that a large number of TE LSPs may need to be re-optimized concurrently. In an extreme case, the TE LSPs may need to be globally re-optimized. Note that sequential re-optimization of such TE LSPs is unlikely to produce substantial improvements in overall network optimization except in very sparsely utilized networks. 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) Reconfiguration of the VNT [MLN-REQ] is another application scenario where global concurrent path computation may be applicable. Triggers for VNT reconfiguration, such as traffic demand changes, network failures, and topological configuration changes, may require a large set of existing LSPs to be re-computed. Again, concurrent path computation capability would result in more efficient network resource utilization than sequential path computation. 3.2.2. Traffic Migration When migrating from one set of TE LSPs to a reoptimized set of TE LSPs it is important that the traffic be moved without causing disruption. Various techniques exist in MPLS and GMPLS, such as make-before-break [RFC3209], to establish the new LSPs before tearing down the old LSPs. When multiple LSP routes are changed according to the computed results, some of the LSPs may be disrupted due to the resource constraints. In other words, it may prove to be impossible to perform a direct migration from the old LSPs to the new optimal LSPs without disrupting traffic because there are insufficient network resources to support both sets of LSPs when make-before-break is used. However, the PCE may be able determine an order of LSP Lee, et al. Expires August 2, 2007 [Page 8] Internet-Draft PCE Global Concurrent Optimization January 2007 rerouting actions so that make-before-break can be performed within the limited resources. However, it may be the case that the reoptimization is radical. This could mean that it is not possible to apply make-before-break in any order to migrate from the old LSPs to the new LSPs. In this case a migration strategy is required that may necessitate LSPs being rerouted using make-before-break onto temporary paths in order to make space for the full reoptimization. A PCE might indicate the order in which reoptimized LSPs must be established and take over from the old LSPs, and may indicate a series of different temporary paths that must be used. Alternatively, the PCE might perform the global reoptimization as a series of sub-reoptimizations by reoptimizing subsets of the total set of LSPs. Note also that during reoptimization, traffic disruption may be allowed for some LSPs carrying low priority services (e.g., Internet traffic) and not allowed for some LSPs carrying mission critical services (e.g., voice traffic). 3.3. Application of the PCE Architecture Figure 1 shows how the aforementioned functionality applies within the PCE architecture. It must be observed that the PCC is not necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as remote from the NMS, it might be collocated with the NMS. Upon receipt of an application request (e.g., a traffic demand matrix is provided to the NMS by the operator's network planning procedure), the NMS requests a global concurrent path computation from the PCE. The PCE then computes the requested paths concurrently applying some algorithms. When the requested path computation completes, the PCE sends the resulting paths back to the NMS. The NMS then supplies the head-end LSRs with a fully computed explicit path for each TE LSP that needs to be established. Lee, et al. Expires August 2, 2007 [Page 9] Internet-Draft PCE Global Concurrent Optimization January 2007 ----------- Application | ----- | Request | | TED | | | | ----- | v | | | ------------- Request/ | v | | | Response| ----- | | NMS |<--------+> | PCE | | | | | ----- | ------------- ----------- Service | Request | v ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<---------->| Node | ---------- ---------- Figure 1: PCE-Based Architecture for Global Concurrent Optimization Lee, et al. Expires August 2, 2007 [Page 10] Internet-Draft PCE Global Concurrent Optimization January 2007 4. PCECP Requirements This section provides the PCECP requirements to support large-scale concurrent path computation applications. The requirements specified here should be regarded as application-specific requirements and are justifiable based on the extensibility clause found in section 6.1.14 of [RFC4657]: The PCECP MUST support the requirements specified in the application-specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future. It is also to be noted that some of the requirements discussed in this section have already been discussed in the PCECP requirement document [RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list of generic constraints while Section 5.1.17 in [RFC4657] provides a list of generic objective functions that MUST be supported by the PCECP. While using such generic requirements as the baseline, this section provides application-specific requirements in the context of global concurrent path computation and in a more detail level than the generic requirements. The PCEP SHOULD support the following capabilities either via creation of new objects and/or modification of existing objects where applicable. o An indicator to convey that the request is for a global concurrent path computation. This indicator is necessary to ensure consistency in applying global objectives and global constraints in all path computations. Note: This requirement is covered by "synchronized path computation" in [RFC4655] and [RFC4657]. However, an explicit indicator to request a global concurrent optimization is a new requirement. o A Global Objective Function (GOF) field in which to specify the global objective function. The global objective function is the overarching objective function to which all individual path computation requests are subjected in order to find a globally optimal solution. Note that this requirement is covered by "synchronized objective functions" in section 5.1.7 [RFC4657]. A list of available global objective functions SHOULD include the following objective functions at the minimum and SHOULD be expandable for future addition: * Minimize the sum of all TE LSP costs (min cost) Lee, et al. Expires August 2, 2007 [Page 11] Internet-Draft PCE Global Concurrent Optimization January 2007 * Maximize the residual bandwidth on the most loaded link * Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. o A Global Constraints (GC) field in which to specify the list of global constraints to which all the requested path computations should be subjected. This list SHOULD include the following constraints at the minimum and SHOULD be expandable for future addition: * Maximum link utilization value -- This value indicates the highest possible link utilization percentage set for each link. (Note: to avoid floating point numbers, the values should be integer values.) * Minimum link utilization value -- This value indicates the lowest possible link utilization percentage set for each link. (Note: same as above) * Overbooking Factor -- The overbooking factor allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. * Maximum number of hops for all the LSPs -- This is the largest number of hops that any LSP can have. Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * Exclusion of links/nodes in all LSP path computation (i.e., all LSPs should not include the specified links/nodes in their paths). Note that this constraint can also be provided on a per LSP basis (as requested in [RFC4657] and defined in [PCEP]). * An indication should be available in a path computation response that further reoptimization may only become available once existing traffic has been moved to the new LSPs. o A Global Concurrent Vector (GCV) field in which to specify all the individual path computation requests that are subject to concurrent path computation and subject to the global objective function and all of the global constraints. Note that this requirement is partially fulfilled by the SVEC object in the PCEP specification [PCEP]. Since the SVEC object as defined in [PCEP] Lee, et al. Expires August 2, 2007 [Page 12] Internet-Draft PCE Global Concurrent Optimization January 2007 allows identifying a set of concurrent path requests, the SVEC can be reused to specify all the individual concurrent path requests for a global concurrent optimization. This can be achieved by defining a new flag in the SVEC object to indicate that this is a global concurrent optimization. o An indicator field in which to indicate the outcome of the request. When the PCE could not find a feasible solution with the initial request, the reason for failure SHOULD be indicated. This requirement is partially covered by [RFC4657], but not in this level of detail. The following indicators SHOULD be supported at the minimum: * no feasible solution found. Note that this is already covered in [PCEP]. * memory overflow * PCE too busy. Note that this is already covered in [PCEP]. * PCE not capable of concurrent reoptimization * no migration path available * administrative privileges do not allow global reoptimization o A Multi-Session Indicator field in the case where the original request is sub-divided into multiple sessions. This case may arise when the reason for failure of the original request is due to mathematical infeasibility, or memory overflow. The PCC may follow up with subsequent actions under a local policy. The motivation for multi-session application is to find a partial feasible solution in the absence of the optimal solution. When the PCC decides to scale down the original request into several sessions, the PCC sends the first session path computation request to the PCE. The next session path computation request is held until the results from the first session would be available. Once the results from the first session are available, the PCC then sends the second session path computation request to the PCE. The same procedure is repeated until the last session of the multiple session has been completed. To support this requirement, it is required that the PCE keep in memory the previously computed paths until all paths of the multi-session have been computed. * Multi-Session Indicator * Multi-Session Sequence Number Lee, et al. Expires August 2, 2007 [Page 13] Internet-Draft PCE Global Concurrent Optimization January 2007 * The Indication of the Final Session o In order to minimize disruption associated with bulk path provisioning, the following requirements MUST be supported: * The request message MUST allow requesting the PCE to provide the order in which LSPs should be reoptimized (i.e., the migration path) in order to minimize traffic disruption during the migration. That is the request message MUST allow indicating the PCE that the set of paths that will be provided in the response message (PCRep) has to be ordered. * In response to the "ordering" request from the PCC, the PCE MUST be able to indicate in the response message (PCRep) the order in which LSPs should be reoptimized so as to minimize traffic disruption. It should indicate for each request the order in which the old LSP should be removed and the order in which the new LSP should be setup. If the removal order is lower than the setup order this means that make-before-break cannot be done for this request. * As stated in RFC 4657, the request for a reoptimization MUST support the inclusion of the set of previously computed paths along with their bandwidth. This is to avoid double bandwidth accounting and also this allows running an algorithm that minimizes perturbation and that can compute a migration path (LSP setup/removal orders). This is particularly required for stateless PCEs. * During a migration it may not be possible to do a make-before- break for all existing LSPs. The request message must allow indicating for each request whether make-before-break is required (e.g. Voice traffic) or break-before-make is acceptable (e.g. Internet traffic). The response message must allow indicating LSPs for which make-before-break reoptimization is not possible (this will be deduced from the LSP setup and deletion orders). * During a reoptimization it may be required to move a LSP several times so as to avoid traffic disruption. The response message must allow indicating the path sequence for each request. Lee, et al. Expires August 2, 2007 [Page 14] Internet-Draft PCE Global Concurrent Optimization January 2007 5. Protocol extensions for support of global concurrent optimization This section provides protocol extensions for support of global concurrent optimization. Protocol extensions discussed in this section are built on [PCEP]. The format of a PCReq message is currently as follows per [PCEP]: ::= [] where: ::= [] ::= [] ::= [] [] [] [] [] [] [] The format of a PCReq message after incorporating new requirements for support of global concurrent optimization is as follows: ::= [] The is changed as follows: :: = [] [] [] [] Note that in the SVEC-list two new optional objects have been defined: the GOF (Global Objective Function) Object and the GC (Global Constraints) Object. Note also that the XRO is also added as an optional Object in the list. Details of this change will be discussed in the following sections. Lee, et al. Expires August 2, 2007 [Page 15] Internet-Draft PCE Global Concurrent Optimization January 2007 5.1. Global Concurrent Optimization Indication A global concurrent path computation request from other types of computation request can be implicitly indicated by the presence of the GOF object in the new SVEC-list as defined in the previous section. That is when the SVEC-list includes the GOF object, it indicates a request for global concurrent optimization. It can also be explicitly indicated by the C flag in the SVEC object. 5.2. Global Objective Function (GOF) Specification The global objective function can be specified in the GOF object. The format of the GOF object body that includes the global objective function is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Objective Function ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: GOF body object format The Objective Function ID (16 bit) identifies the objective function for global concurrent request. Currently three global objective functions are identified. Other objective functions may be defined later. 1: Minimize the sum of all TE LSP costs (min cost) 2: Maximize the residual bandwidth on the most loaded link 3: Evenly allocate the network load to achieve the most uniform link utilization across all links (this can be achieved by the following objective function: minimize max over all links {(C(i)- A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is the total bandwidth allocated on link i. GOF Object-Class is to be assigned by IANA. GOF Object-Type is to be assigned by IANA. Lee, et al. Expires August 2, 2007 [Page 16] Internet-Draft PCE Global Concurrent Optimization January 2007 5.3. Indication of Global Concurrent Requests All the path requests in this application should be indicated so that the global objective function and all of the global constraints are applied to each of the requested path computation. In order to support this requirement, the SVEC object should be modified as follows. C flag (1 bit): This is a new flag in the SVEC object. When C flag is set, this indicates that all of the path request listed in the body of the SVEC object should be computed applying the global constraints and the global objective function. When the C Flag is set in the SVEC Object, the GOF and the GC objects should directly follow the SVEC Object. Therefore, the format of the PCReq is modified as follows: ::= [] The is changed as follows: ::= [] [] [] [] 5.4. Request for the order of LSP In order to minimize disruption associated with bulk path provisioning, the PCC MAY indicate to the PCE that the response MUST be ordered. That is, it MUST include the order in which LSPs MUST be moved so as to minimize traffic disruption. Such indication can be included in the RP object which is revised as follows: Lee, et al. Expires August 2, 2007 [Page 17] Internet-Draft PCE Global Concurrent Optimization January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|M|F|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: RP object body format in the PCReq Message D bit (orDer - 1 bit): when set, in a PCReq message, the requesting PCC requires the PCE to specify in the PCRep message the order in which this particular path request is to be provisioned relative to other requests. M bit (Make-before-break - 1 bit): when set, this indicates that a make-before-break reoptimization is required for this request. When M bit is not set, this implies that this request is allowed to a break-before-make reoptimization. Note that M bit can be set only if the R and D flags are set. All other fields are unchanged from [PCEP]. 5.5. The Order Response The PCE MUST specify the order number in response to the Order Request made by the PCC in the PCReq message if so requested by the setting of the D bit in the RP object in the PCReq message. The format of the RP object body to be included in the PCRep message is modified as follows: Lee, et al. Expires August 2, 2007 [Page 18] Internet-Draft PCE Global Concurrent Optimization January 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|M|F|O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Order TLV (Optional TLV) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: RP object body format in the PCRep Message The Order TLV is an optional TLV in the RP object, that indicates the order in which the old LSP must be removed and the new LSP must be setup during a reoptimization. It is carried in the PCRep message in response to a reoptimization request. The Order TLV SHOULD be included in the RP object in the PCRep message if the D bit is set in the RP object in the PCReq message. The format of the Order TLV is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delete Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Setup Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To be defined by IANA (suggested value = ) Length Variable Value Orders in which the old path should be removed and the new path should be setup Figure 8: The Order TLV in the RP object in the PCRep Message Delete Order: 32 bit integer that indicates the order in which the old LSP should be removed Lee, et al. Expires August 2, 2007 [Page 19] Internet-Draft PCE Global Concurrent Optimization January 2007 Setup Order: 32 bit integer that indicates the order in which the new LSP should be setup The delete order should not be equal to the setup order. If the delete order is higher than the setup order, this means that the reoptimization can be done in a make-before-break manner, else it cannot be done in a make-before-break manner. To illustrate, consider a network with two established requests: R1 with path P1 and R2 with path P2. During a reoptimization the PCE may provide the following ordered reply: R1, path P1', remove order 1, setup order 4 R2, path P2', remove order 3, setup order 2 This indicates that the NMS should do the following sequence of tasks: 1: Remove path P1 2: Setup path P2' 3: Remove path P2 4: Setup path P1' That is, R1 is reoptimized in a break-before-make manner and R2 in a make-before-break manner. 5.6. Global Constraints (GC) Object The Global Constraints (GC) Object is used in a PCReq message to specify the necessary global constraints that should be applied to all individual path computations for a global concurrent path optimization request. The format of the GC object body that includes the global constraints is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MU | mU | OB | MH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires August 2, 2007 [Page 20] Internet-Draft PCE Global Concurrent Optimization January 2007 Figure 11: GC body object format MU (Max Utilization) (8 bits) : 8 bit integer that indicates the upper bound utilization percentage by which all link should be bound. Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link Capacity mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the lower bound utilization percentage by which all link should be bound. OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the overbooking percentage that allows the reserved bandwidth to be overbooked on each link beyond its physical capacity limit. The value, for example, 10% means that 110 Mbps can be reserved on a 100Mbps link. MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop count for all the LSPs. GC Object-Class is to be assigned by IANA. GC Object-Type is to be assigned by IANA. The exclusion of the list of nodes/links from a global path computation can be done by including the XRO object following the GC object in the new SVEC definition. 5.7. Multi-Session Processing When the initial global concurrent path computation request fails due to scaling issues or memory overflow as indicated in the PCEP-ERROR object in the PCRep message, multi-session processing may be proceeded in an attempt to find a feasible solution in the absence of an optimal solution. This should be driven by local policy decision. How to divide up the original global concurrent optimization problem into a number of smaller-scale optimization problems is out of the scope of this document. In order to meet these multi-session requirements, a new object, the Multi-Session (MS) object is required. This object should be defined on a per message basis. The message is modified as follows: ::= [] [] Lee, et al. Expires August 2, 2007 [Page 21] Internet-Draft PCE Global Concurrent Optimization January 2007 The format of the MSO object is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Multi-Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: MSO object body format Multi-Session ID (16 bits): 16 bit integer that identifies the multi- session computation. The Multi-Session ID will allow to map all request messages for the same global computation. Sequence Number (16 bits): 16 bit integer that indicates the sequence number of the current multi-session request. This should be incremented for each new request message during a multi-session request until the final request is performed. F (Final session - 1 bit): When set, the requesting PCC indicates that the PCReq message is the final session of a multi-session request. When it is not set, the PCE SHOULD keep in memory all the computed paths until the final session of a multi-session is completed. This is necessary to correctly account for already computed LSPs. MS Object-Class is to be assigned by IANA. MS Object-Type is to be assigned by IANA. For PCE not able to temporarily maintain previously computed paths, the multi-session capability can be provided by simply adding the ERO object and the Bandwidth object following the RP object in the PCReq message. The ERO and the Bandwidth objects together provide all of the previously computed paths by the PCE. In order to distinguish a previously computed request from a new request, a new flag in the RP object is required. A (Already computed request - 1 bit): When set, this indicates that the request has already been computed in a previous session, and its result (as indicated by the ERO and the Bandwidth Object following Lee, et al. Expires August 2, 2007 [Page 22] Internet-Draft PCE Global Concurrent Optimization January 2007 the RP object) must be taken account in the current session. 5.8. Error Indicator To indicate errors associated with the global concurrent path optimization request, a new Error-Type (11) and subsequent error- values are defined as follows for inclusion in the PCEP-ERROR object: A new Error-Type (11) and subsequent error-values are defined as follows: Error-Type=14 and Error-Value=1: if a PCE receives a global concurrent path optimization request and the PCE is not capable of the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP ERROR object (Error-Type=14) and an Error-Value (Error-Value=1). The corresponding global concurrent path optimization request MUST be cancelled. Error-Type=14; Error-Value=2: if a PCE receives a global concurrent path optimization request and the PCE is not capable of global concurrent optimization, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). The corresponding global concurrent path optimization MUST be cancelled. Error-Type=14; Error-Value=3: if a PCE receives a global concurrent path optimization request which is not compliant with administrative privileges (i.e., the PCE policy does not support global concurrent optimization), the PCE send a PCErr message with a PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=3). The corresponding global concurrent path computation MUST be cancelled. 5.9. NO-PATH Indicator To communicate the reason(s) for not being able to find global concurrent path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|G|M| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee, et al. Expires August 2, 2007 [Page 23] Internet-Draft PCE Global Concurrent Optimization January 2007 Figure 14: NO-PATH object format Flags (16 bits). The C flag is defined in [PCEP]. Two additional flags are defined to support other reasons why the path computation fails: G flag (1 bit) and M flag (1 bit). M flag (1 bit): when set, the PCE indicates that no migration path was found. G flag (1 bit): when set, the PCE indicates no feasible solution was found that meets all the constraints associated with global concurrent path optimization in the PCRep message. When either M or G flag is set in the PCRep Message, a subsequent multi-session feature may be triggered if the PCC's local policy allows it. The multi-session feature allows the original global concurrent optimization to be split into a number of multiple sessions so that the PCE would compute a number of smaller-scale optimizations in a sequential manner. The trade-off is that a partial feasible solution may be obtained using this approach which is better than not having any solution at all, although such solution might not be a global optimal solution. How to divide up the original large-scale global concurrent optimization into a multiple number of smaller-scale optimizations is out of the scope of this document. See Section 5.7 for multi-session processing details. Lee, et al. Expires August 2, 2007 [Page 24] Internet-Draft PCE Global Concurrent Optimization January 2007 6. Manageability Considerations Manageability of Global Concurrent Path Computation with PCE must address the following considerations: 6.1. Control of Function and Policy This sub-section will describe the configurable items that exist for the control of global concurrent optimization functions or policies. 6.2. Information and Data Models, e.g. MIB module This sub-section will describe the information and data models necessary for the protocol or the protocol extensions. This includes, but is not necessarily limited to, the MIB modules developed specifically for the protocol functions specified in the document. 6.3. Liveness Detection and Monitoring This sub-section will describe liveness detection and monitoring requirements for both the control plane and the data plane. 6.4. Verifying Correct Operation This sub-section will describe Operations and Management (OAM) features and functions for verifying the correct operation. 6.5. Requirements on Other Protocols and Functional Components This sub-section will describe requirements or refer to the sections that discuss the impact of global concurrent optimization on existing protocols. 6.6. Impact on Network Operation This sub-section will discuss the impact on the operation of existing networks. 6.7. Other Considerations This sub-section will cover those manageability requirements not specifically in previous sub-sections. Lee, et al. Expires August 2, 2007 [Page 25] Internet-Draft PCE Global Concurrent Optimization January 2007 7. Security Considerations When global re-optimization is applied to an active network, it could be extremely disruptive. Although the real security and policy issues apply at the NMS, if the wrong results are returned to the NMS, the wrong actions may be taken in the network. Therefore, it is very important that the operator issuing the commands has sufficient authority and is authenticated, and that the computation request is subject to appropriate policy. The mechanisms defined in [PCEP] to secure a PCEP session (MD-5 authentication, etc.) apply here as well. Lee, et al. Expires August 2, 2007 [Page 26] Internet-Draft PCE Global Concurrent Optimization January 2007 8. Acknowledgements We would like to thank Jerry Ash, Adrian Farrel, Ning So and Lucy Yong for their useful comments and suggestions. Lee, et al. Expires August 2, 2007 [Page 27] Internet-Draft PCE Global Concurrent Optimization January 2007 9. IANA Considerations A future revision of this document will present requests to IANA for codepoint allocation. Lee, et al. Expires August 2, 2007 [Page 28] Internet-Draft PCE Global Concurrent Optimization January 2007 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. 10.2. Informative References [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- region and multi-layer networks (MRN/MLN), draft-ietf-ccamp-gmpls-mln-reqs, work in progress". [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- based inter-layer MPLS and GMPL traffic engineering, draft-ietf-pce-inter-layer-frwk, work in progress.". [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1, draft-ietf-pce-pcep-04.txt, work in progress". [RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery, draft-ietf-pce-discovery-reqs, work in progress.". Lee, et al. Expires August 2, 2007 [Page 29] Internet-Draft PCE Global Concurrent Optimization January 2007 Authors' Addresses Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 US Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: ylee@huawei.com JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE Email: jeanlouis.leroux@orange-ftgroup.com Daniel King Aria Networks 44/45 Market Place Chippenham SN15 3HU United Kingdom Phone: +44 7790 775187 Fax: +44 1249 446530 Email: daniel.king@aria-networks.com Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585 JAPAN Email: oki.eiji@lab.ntt.co.jp Lee, et al. Expires August 2, 2007 [Page 30] Internet-Draft PCE Global Concurrent Optimization January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lee, et al. Expires August 2, 2007 [Page 31] --Boundary_(ID_NHxcN+rJUCwz4Ojzu5JTXA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --Boundary_(ID_NHxcN+rJUCwz4Ojzu5JTXA)-- From pce-bounces@lists.ietf.org Wed Jan 31 14:49:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLRp-0004oi-S2; Wed, 31 Jan 2007 14:48:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLRo-0004o9-Ft for pce@ietf.org; Wed, 31 Jan 2007 14:48:48 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLRl-0008EX-5z for pce@ietf.org; Wed, 31 Jan 2007 14:48:48 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Jan 2007 11:48:45 -0800 X-IronPort-AV: i="4.13,263,1167638400"; d="scan'208,217"; a="51981674:sNHT117328880" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0VJmifg008538; Wed, 31 Jan 2007 14:48:44 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0VJmgVV014522; Wed, 31 Jan 2007 14:48:44 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:48:40 -0500 Received: from [10.86.104.188] ([10.86.104.188]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 14:48:39 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <21078E40-48EF-4B1B-87BD-CB36B3A4269E@cisco.com> From: JP Vasseur Subject: Re: [Pce] RE: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt Date: Wed, 31 Jan 2007 14:48:38 -0500 To: "Vijayanand C - TLS, Chennai." X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Jan 2007 19:48:39.0405 (UTC) FILETIME=[CDC211D0:01C74570] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=24928; t=1170272924; x=1171136924; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Pce]=20RE=3A=20I-D=20ACTION=3Adraft-vijay-somen-pce- bgp-interas-te-path-01.txt=20 |Sender:=20 |To:=20=22Vijayanand=20C=20-=20TLS,=20Chennai.=22=20; bh=6ejeEjOZL5nrjiksFzPPUonHFescxu1ecreS8bHKxwQ=; b=p7LgsrCQvLeM4lnixCvwNv3UYLWim8HroGNaf1UviO29nm1b3IJw0K9PqDbbsCe8vTkHI8tL FQ1Yia+N5Ot4ZUmg2jWmitKRzSciLXHPGYPGkhEFlDfD0GyrgG7p7h0o; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: ea36de7a5e28e9b4461c8d685f4e97f1 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269114868==" Errors-To: pce-bounces@lists.ietf.org --===============1269114868== Content-Type: multipart/alternative; boundary=Apple-Mail-149-839674151 --Apple-Mail-149-839674151 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, On Jan 25, 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote: > > Hello all, > We have submitted the following I-D, please send in your > comments/suggestions * speaking as a technical contributor * In [BRPC], a method to optimally compute a inter-domain TE path for MPLS and GMPS LSPs using the PCE architecture detailed in [PCE_ARCH] is described. However the method described requires the list of Autonomous systems or domains to be determined apriori. Determining the list of ASes/domains to be traversed to reach a destination, satisfying the TE constraints is non-trivial. It requires knowledge of the inter-AS connectivity and the TE characteristics of the inter-AS links along with the knowledge of the available paths within each of the ASes/domains. BGP contains information on the list of ASes to be traversed to reach a destination, however BGP route selection and decision process truncates most of the feasible paths, and it also does not carry the TE characteristics of the inter-AS links and path availability within a domain. What does prevent you from relying on BGP to provide you all possible paths toward a specific destination skipping the regular path selection process for specific routes (see proposals made in the past) and then use BRPC as currently specified? The Inter-AS TE link could easily be obtained via the IGP with minor additions. This is in my opinion a fundamental question that must first be addressed before moving forward. Thanks. JP. > > Regards > Vijay > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, January 23, 2007 2:20 AM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A BGP based method to compute inter-AS Traffic > engineering Label Switched Paths with PCE > Author(s) : C. Vijayanand, S. Bhattacharya > Filename : > draft-vijay-somen-pce-bgp-interas-te-path-01.txt > Pages : 26 > Date : 2007-1-22 > > The ability to compute an optimal path for setting up Traffic > engineering Label Switched Paths spanning multiple autonomous > systems managed by different operators has been a key > requirement in > MPLS and GMPLS networks. This document specifies a method of > computing inter-AS paths consisting of a list of ASes to be > traversed and a list of TE-Tunnels to be traversed in each AS. The > method described here uses BGP speakers in the PCEs of each AS to > distribute the inter-AS connectivity information and the TE-Tunnels > in each AS to its neighbors to facilitate the construction of an > inter-AS topology graph which can be used for computing inter-AS > paths. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vijay-somen-pce-bgp- > interas-te > -path-01.txt > > > > DISCLAIMER: > ---------------------------------------------------------------------- > ------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of > this message without the prior written consent of the author of > this e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > ---------------------------------------------------------------------- > ------------------------------------------------- > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-149-839674151 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

On Jan 25, = 2007, at 9:32 AM, Vijayanand C - TLS, Chennai. wrote:


Hello = all,
We have submitted the following = I-D, please send in your
* speaking as a technical = contributor *

=A0 =A0In [BRPC], = a method to optimally compute a inter-domain TE=A0
=A0=A0 = path for MPLS and = GMPS LSPs using the PCE architecture detailed in=A0
=A0=A0 = [PCE_ARCH] is = described. However the method described requires the=A0
=A0=A0 = list of Autonomous = systems or domains to be determined apriori.=A0
=A0=A0 = Determining the = list of ASes/domains to be traversed to reach a=A0
=A0=A0 = destination, = satisfying the TE constraints is non-trivial. It=A0
=A0=A0 = requires knowledge = of the inter-AS connectivity and the TE=A0
=A0=A0 = characteristics of = the inter-AS links along with the knowledge of=A0
=A0=A0 = the available = paths within each of the ASes/domains. BGP contains=A0
=A0=A0 = information on the = list of ASes to be traversed to reach a=A0
=A0=A0 = destination, = however BGP route selection and decision process=A0
=A0=A0 = truncates most of = the feasible paths, and it also does not carry=A0
=A0=A0 = the TE = characteristics of the inter-AS links and path = availability=A0
=A0=A0 within a domain. =A0

What does prevent you from = relying on BGP to provide you all possible paths toward=A0
a = specific destination skipping the regular path selection process for = specific routes (see
proposals made in the past) and then use = BRPC as currently specified? The Inter-AS TE
link could easily = be obtained via the IGP with minor additions.

This is in my opinion a = fundamental question that must first be addressed = before=A0
moving forward.

Thanks.

JP.


Regards

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=A0
Subject: I-D = ACTION:draft-vijay-somen-pce-bgp-interas-te-path-01.txt=A0

A New = Internet-Draft is available from the on-line Internet-Drafts=A0


= Title = = : A BGP based method to compute inter-AS Traffic
engineering Label Switched Paths with PCE
Author(s) : C. = Vijayanand, S. Bhattacharya
= Filename = :
Pages : 26
Date : = 2007-1-22

=

The = ability to compute an optimal path for setting up Traffic=A0
=A0=A0 engineering Label Switched = Paths spanning multiple autonomous=A0
=A0=A0 systems managed by = different operators has been a key requirement in=A0
=A0=A0 MPLS and GMPLS networks. = This document specifies a method of=A0
=A0=A0 computing inter-AS paths = consisting of a list of ASes to be=A0
=A0=A0 traversed and a list of = TE-Tunnels to be traversed in each AS. The=A0
=A0=A0 method described here uses = BGP speakers in the PCEs of each AS to=A0
=A0=A0 distribute the inter-AS = connectivity information and the TE-Tunnels=A0
=A0=A0 in each AS to its = neighbors to facilitate the construction of an=A0
=A0=A0 inter-AS topology graph = which can be used for computing inter-AS
=A0 =A0 paths.

A URL = for this Internet-Draft is:
-path-01.txt



DISCLAIMER:

The = contents of this e-mail and any attachment(s) are confidential and = intended for the named recipient(s) only.
It shall = not attach any liability on the originator or HCL or its affiliates. Any = views or opinions presented in=A0
this = email are solely those of the author and may not necessarily reflect the = opinions of HCL or its affiliates.
Any form of = reproduction, dissemination, copying, disclosure, modification, = distribution and / or publication of=A0
this = message without the prior written consent of the author of this e-mail = is strictly prohibited. If you have=A0
received = this email in error please delete it and notify the sender immediately. = Before opening any mail and=A0


Pce mailing list
=

= --Apple-Mail-149-839674151-- --===============1269114868== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --===============1269114868==-- From pce-bounces@lists.ietf.org Wed Jan 31 14:53:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLWE-0006fd-Nr; Wed, 31 Jan 2007 14:53:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCLWD-0006fV-03 for pce@ietf.org; Wed, 31 Jan 2007 14:53:21 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCLWB-0000Ml-L0 for pce@ietf.org; Wed, 31 Jan 2007 14:53:20 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2007 11:53:19 -0800 X-IronPort-AV: i="4.13,263,1167638400"; d="scan'208"; a="107518729:sNHT124477560" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l0VJrIX9028282; Wed, 31 Jan 2007 11:53:18 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l0VJr8Do019131; Wed, 31 Jan 2007 11:53:17 -0800 (PST) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 11:53:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Path Key draft to WG status? Date: Wed, 31 Jan 2007 11:53:11 -0800 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E02FBDDB5@xmb-sjc-234.amer.cisco.com> In-Reply-To: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Path Key draft to WG status? Thread-Index: AcdE0u0Uth4f5vYfTbOQB6/AHEme6AAm5kow From: "Dean Cheng \(dcheng\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 31 Jan 2007 19:53:12.0147 (UTC) FILETIME=[70533230:01C74571] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1366; t=1170273199; x=1171137199; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dcheng@cisco.com; z=From:=20=22Dean=20Cheng=20\(dcheng\)=22=20 |Subject:=20RE=3A=20[Pce]=20Path=20Key=20draft=20to=20WG=20status? |Sender:=20 |To:=20=22Adrian=20Farrel=22=20, =20 |Content-Type:=20text/plain=3B=0A=09charset=3D=22us-ascii=22 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=H3GL0RiA/XRX1V4OD81xaKWolub3yyY8tP7kC7nPPwE=; b=hU2yBNIaXI34yV5KpUhf/9LmrUIA15zwR9fscGkYYV/Q5IOuXqfXVrsahr6n4tG4WvoV76D6 ZIqr+9ZRy+KnNYp5lA1qYj1F+3oTfoSqgYHq4jQ6inXsVK11vYqw3D58pzvVdXEwTHy39RkPbh CNbGq4phNsOMlv9nhE9/2pC50=; Authentication-Results: sj-dkim-1; header.From=dcheng@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Yes it is ready. Dean=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, January 30, 2007 4:55 PM > To: pce@ietf.org > Subject: [Pce] Path Key draft to WG status? >=20 > Hi, >=20 > draft-bradford-pce-path-key-01.txt was presented in San Diego=20 > and there was some interest and a general agreement that the=20 > work was needed for confidentiality of path segments computed=20 > by cooperating PCEs, for example in the BRPC mode of operation. >=20 > Since then we have produced a new version to address some=20 > comments made in San Diego and privately to the authors. Rich=20 > sent a note about the changes on 11th January. >=20 > Since JP and I are both co-authors of this work we need to=20 > move forward with some caution, but we believe that this is a=20 > necessary part of the puzzle and that the current draft is in=20 > good shape to become a Working Group draft. We can then build=20 > on it (hopefully with input from the working group) until it=20 > is fully stable and complete. >=20 > So opinions please: is draft-bradford-pce-path-key-02.txt=20 > ready to be a WG draft? >=20 > Thanks, > Adrian=20 >=20 >=20 >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 31 16:06:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMfC-00025i-9n; Wed, 31 Jan 2007 16:06:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMfB-00025Q-CQ for pce@ietf.org; Wed, 31 Jan 2007 16:06:41 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCMf8-0007GV-3P for pce@ietf.org; Wed, 31 Jan 2007 16:06:41 -0500 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1170277596!13430296!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 23706 invoked from network); 31 Jan 2007 21:06:36 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 31 Jan 2007 21:06:36 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0VL6ZKM009660; Wed, 31 Jan 2007 16:06:36 -0500 (EST) Received: from kcclust06evs1.ugd.att.com (kcst12.ugd.att.com [135.38.164.89]) by attrh0i.attrh.att.com (8.13.7/8.13.7) with ESMTP id l0VL6GL8009424; Wed, 31 Jan 2007 16:06:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] Path Key draft to WG status? Date: Wed, 31 Jan 2007 15:06:26 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC816B@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <04d301c744d2$7c9eeec0$76849ed9@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Path Key draft to WG status? Thread-Index: AcdE0udMIPulqCNjTNGKLwV7A8ArBAAqFPlg From: "ASH, GERALD R \(JERRY\), SBCLABS" To: "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org > So opinions please: is draft-bradford-pce-path-key-02.txt ready to be a WG=20 > draft? Yes, important work (although the Manageability Considerations section is a bit brief :-) Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Jan 31 22:39:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSmM-0006Nr-9D; Wed, 31 Jan 2007 22:38:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSmL-0006NR-Kk for pce@ietf.org; Wed, 31 Jan 2007 22:38:29 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCSmJ-00013k-KE for pce@ietf.org; Wed, 31 Jan 2007 22:38:29 -0500 Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l111RORb009203 for ; Thu, 1 Feb 2007 10:27:24 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E9B8820AE29 for ; Thu, 1 Feb 2007 10:27:23 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 91EB720AE2F for ; Thu, 1 Feb 2007 10:27:23 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l111RNU0002870 for ; Thu, 1 Feb 2007 10:27:23 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l111RM7W007192 for ; Thu, 1 Feb 2007 10:27:22 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l111RM19007189 for ; Thu, 1 Feb 2007 10:27:22 +0900 (JST) Received: from [129.60.80.74] ([129.60.80.74]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l111RMde004489 for ; Thu, 1 Feb 2007 10:27:22 +0900 (JST) Date: Thu, 01 Feb 2007 10:27:23 +0900 From: Eiji Oki To: pce@ietf.org Message-Id: <20070201100557.554B.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_45C13CF555CE09044228_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Subject: [Pce] Fw: I-D ACTION:draft-oki-pce-pcep-xro-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --------_45C13CF555CE09044228_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, A new draft on extensions to PCEP for route exclusions has been published: http://www.ietf.org/internet-drafts/draft-oki-pce-pcep-xro-00.txt Any comments and suggestions are highly appreciated. Thank you. Eiji Forwarded by Eiji Oki ----------------------- Original Message ----------------------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Date: Wed, 31 Jan 2007 15:50:02 -0500 Subject: I-D ACTION:draft-oki-pce-pcep-xro-00.txt ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Author(s) : E. Oki, A. Farrel Filename : draft-oki-pce-pcep-xro-00.txt Pages : 12 Date : 2007-1-31 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify as constraints to the path computation abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from routes. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-pce-pcep-xro-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-oki-pce-pcep-xro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-oki-pce-pcep-xro-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------------- Original Message Ends -------------------- -- Eiji Oki, Ph. D. Senior Research Engineer NTT Network Service Systems Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-3441, Fax: +81-422-59-3787 E-mail: oki.eiji@lab.ntt.co.jp --------_45C13CF555CE09044228_MULTIPART_MIXED_ Content-Type: message/rfc822 Content-Description: I-D ACTION:draft-oki-pce-pcep-xro-00.txt Return-Path: Received: from eclscan1.m.ecl.ntt.co.jp (eclscan1.m.ecl.ntt.co.jp [129.60.5.67]) by imb.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l0VL1Cc3012026 for ; Thu, 1 Feb 2007 06:01:12 +0900 (JST) Received: from eclscan1.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l0VL1BI6024725 for ; Thu, 1 Feb 2007 06:01:12 +0900 (JST) Received: from idma.m.ecl.ntt.co.jp. (idma.m.ecl.ntt.co.jp [129.60.5.2]) by eclscan1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l0VL1A3w024714; Thu, 1 Feb 2007 06:01:10 +0900 (JST) Received: from nttmail2.ecl.ntt.co.jp (nttmail2.ecl.ntt.co.jp [129.60.57.213]) by idma.m.ecl.ntt.co.jp. (8.13.8/8.13.8) with ESMTP id l0VL1ANk024124; Thu, 1 Feb 2007 06:01:10 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (mfs34.rdh.ecl.ntt.co.jp [129.60.39.114]) by nttmail2.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l0VL19Ux025167; Thu, 1 Feb 2007 06:01:09 +0900 (JST) Received: from mfs34.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E09EE20AE28; Thu, 1 Feb 2007 06:01:08 +0900 (JST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by mfs34.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6D06A20AE2D; Thu, 1 Feb 2007 06:01:08 +0900 (JST) Received: from megatron.ietf.org (stiedprmman1.ietf.ORG [156.154.16.145]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id l0VL16tq002249; Thu, 1 Feb 2007 06:01:06 +0900 (JST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMPe-0003eu-Mc; Wed, 31 Jan 2007 15:50:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCMPZ-0003cE-B6 for i-d-announce@ietf.org; Wed, 31 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCMPZ-0004vh-02 for i-d-announce@ietf.org; Wed, 31 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AF59D175D0 for ; Wed, 31 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCMP4-0004xg-9Y for i-d-announce@ietf.org; Wed, 31 Jan 2007 15:50:02 -0500 Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 31 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: I-D ACTION:draft-oki-pce-pcep-xro-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org Status: Content-Type: Multipart/Mixed; Boundary="NextPart" Content-Transfer-Encoding: 7bit --NextPart Content-Type: text/plain Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Author(s) : E. Oki, A. Farrel Filename : draft-oki-pce-pcep-xro-00.txt Pages : 12 Date : 2007-1-31 The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify as constraints to the path computation abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from routes. Such constraints are termed route exclusions. The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-pce-pcep-xro-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-oki-pce-pcep-xro-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-oki-pce-pcep-xro-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" Content-Transfer-Encoding: 7bit --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2007-1-31120143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-oki-pce-pcep-xro-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-oki-pce-pcep-xro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Disposition: attachment; filename="draft-oki-pce-pcep-xro-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2007-1-31120143.I-D@ietf.org> --OtherAccess-- --NextPart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------_45C13CF555CE09044228_MULTIPART_MIXED_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --------_45C13CF555CE09044228_MULTIPART_MIXED_--