From pce-bounces@lists.ietf.org Thu Sep 01 03:21:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjNb-0001Qi-W6; Thu, 01 Sep 2005 03:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAjNV-0001Or-E2 for pce@megatron.ietf.org; Thu, 01 Sep 2005 03:20:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01115 for ; Thu, 1 Sep 2005 03:20:52 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAjGA-0002aZ-AJ for pce@ietf.org; Thu, 01 Sep 2005 03:13:18 -0400 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAjEA-000HlV-KM; Thu, 01 Sep 2005 07:11:14 +0000 Message-ID: <4316A99D.8000806@psg.com> Date: Thu, 01 Sep 2005 09:11:25 +0200 From: dimitri papadimitriou User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt References: <43AB7A03-623D-48E9-9B2A-EDFF01DAE7C0@cisco.com> In-Reply-To: <43AB7A03-623D-48E9-9B2A-EDFF01DAE7C0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA01115 Cc: pce@ietf.org, Richard Rabbat , Ting_Wo Chung , "raymond.zhang" , Paul Mabey X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org hi jp, all the following chart discussed by JL during the last meeting pretty well=20 summarize the issues based on the discussion one has had during the meeting (and even if it=20 not appropriate to consider specific implementation) one could draw some=20 line that for "discovering" the exact state (load, congestion) and=20 detailed capabilities a protocol preserving several requirements such as=20 adapted to exchange of such detailed information, minimize overhead=20 (conservative), confidentiality, etc. thanks, - dimitri. JP Vasseur wrote: > Hi Jean-Louis, >=20 > On Aug 31, 2005, at 3:13 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: >=20 >> Hi Jean-Philippe, >> >> we plan to post a new revision by mid-september. >> Is that OK? >> >=20 > Perfect, thanks. Provided that the remaining issues are sorted out, we= =20 > could go for WG LC on this ID. >=20 > JP. >=20 >> Regards, >> >> JL >> >> >>> -----Message d'origine----- >>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey; Eiji Oki; >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang >>> Cc : pce@ietf.org >>> Objet : Progress on draft-ietf-pce-discovery-reqs-01.txt >>> >>> Hi, >>> >>> First of all, thanks for the very significant progress which >>> has been made on this ID over the past 6 months. As discussed >>> during the last meeting in Paris, there are still a few >>> issues to be sorted out. >>> Could we try to close on these remaining issues so as to >>> quickly start the protocol work (we're a bit late on this Milestone)= ? >>> >>> Thanks. >>> >>> 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 Sep 01 23:56:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB2ey-0001fS-Gv; Thu, 01 Sep 2005 23:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB2eu-0001dF-Jl for pce@megatron.ietf.org; Thu, 01 Sep 2005 23:56:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27533 for ; Thu, 1 Sep 2005 23:56:06 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB2gu-0008Fv-Ti for pce@ietf.org; Thu, 01 Sep 2005 23:58:18 -0400 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 <0IM600E6I8FQEF@szxga01-in.huawei.com> for pce@ietf.org; Fri, 02 Sep 2005 11:59:50 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IM6005XZ8FNL1@szxga01-in.huawei.com> for pce@ietf.org; Fri, 02 Sep 2005 11:59:50 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IM600KBA8I2H8@szxml02-in.huawei.com>; Fri, 02 Sep 2005 12:01:15 +0800 (CST) Date: Wed, 02 Nov 2005 11:29:19 +0800 From: Zhang Renhai Subject: Re: [Pce] About the presentationofdraft-zhang-pce-comm-app-model-01.txt To: LE ROUX Jean-Louis RD-CORE-LAN Message-id: <002b01c5df5d$9c76a160$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Priority: 3 X-MSMail-priority: Normal References: X-Spam-Score: 4.6 (++++) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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="===============1066614229==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============1066614229== Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 SGksIEplYW4gTG91aXMNCg0KICAgIFRoYW5rcyB5b3VyIHJlcGx5LCBzZWUgaW5saW5lIGJlbG93 Lg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkxFIFJPVVggSmVhbi1M b3VpcyBSRC1DT1JFLUxBTiIgPGplYW5sb3Vpcy5sZXJvdXhAZnJhbmNldGVsZWNvbS5jb20+DQpU bzogIlpoYW5nIFJlbmhhaSIgPHpoYW5ncmVuaGFpQGh1YXdlaS5jb20+DQpDYzogPHBjZUBpZXRm Lm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDA1IDY6MjcgUE0NClN1YmplY3Q6 IFJFOiBbUGNlXSBBYm91dCB0aGUgcHJlc2VudGF0aW9ub2ZkcmFmdC16aGFuZy1wY2UtY29tbS1h cHAtbW9kZWwtMDEudHh0DQoNCg0KSGkgWmhhbmcsDQoNClBsZWFzZSBzZWUgaW5saW5lLCANCg0K PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGUgOiBaaGFuZyBSZW5oYWkgW21haWx0 bzp6aGFuZ3JlbmhhaUBodWF3ZWkuY29tXSANCj4gRW52b3npIDogbHVuZGkgMjkgYW/7dCAyMDA1 IDA1OjM5DQo+IMAgOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4NCj4gQ2MgOiBwY2VA aWV0Zi5vcmcNCj4gT2JqZXQgOiBSZTogW1BjZV0gQWJvdXQgdGhlIA0KPiBwcmVzZW50YXRpb25v ZmRyYWZ0LXpoYW5nLXBjZS1jb21tLWFwcC1tb2RlbC0wMS50eHQNCj4gDQo+IEhpLCBKZWFuIExv dWlzDQo+IA0KPiAgRnJvbSB3aGF0IHlvdSBzYWlkIGJlbG93LCBjb3VsZCBJIGNvbmNsdWRlIHRo YXQgdGhlcmUgaXMgYSANCj4gdHJhZGVvZmYgb24gd2hhdCB3ZSBkaXNjdXNzZWQ6DQo+IFRoZSB0 d28gc2lkZXMgb2YgdGhlIHRyYWRlb2ZmIGFyZSByZXNvdXJjZSBjb250ZW50aW9ucyBhbmQgDQo+ IHJlY2VpdmluZyBhbGwgcmVxdWVzdHMgZm9yIGEgUENFLg0KPiBBbmQgaW4gbXkgb3Bpbmlvbiwg cmVjZWl2aW5nIGFuZCBwYXJzaW5nIHBhY2tldHMgY29uc3VtZSBtdWNoIA0KPiBsZXNzIENQVSBj YXBhYmlsaXR5IHRoYW4gcGF0aCBjb21wdXRhdGlvbiB3aGljaCBhcmUgYmVjb21pbmcgDQo+IG1v cmUgYW5kIG1vcmUgY29tcGxleCwgU28gSSB0aGluayB0aGUgcGF0aCBjb21wdXRhdGlvbiB3aWxs IA0KPiBiZSB0aGUgcmVhbCBib3R0bGVuZWNrLlRvIG1ha2UgbWFpbnRhaW5pbmcgb2YgYWxsIHJl cXVlc3RzIA0KPiBmb3IgYSBQQ0UgZWFzaWVyLCBhIHByaW9yaXR5IGZvciBhcHBseWluZyByZXNv dXJjZXMgaW4gdGhlIA0KPiByZXF1ZXN0IG1lc3NhZ2UgbWF5IGJlIGVub3VnaC4NCg0KSSB0aGlu ayB0aGF0IHRoZSBudW1iZXIgb2YgcmVxdWVzdHMgdG8gYmUgaGFuZGxlZCBieSBhIFBDRQ0KaXMg YW4gaW1wb3J0YW50IHBhcmFtZXRlciB3aGVuIGV2YWx1YXRpbmcgdGhlIHNjYWxhYmlsaXR5IG9m IGEgUENFIGFyY2hpdGVjdHVyZS4gDQpXaGF0IHdvcnJpZXMgbWUgaW4geW91ciBwcm9wb3NhbCBp cyB0aGF0IHlvdSBkaXN0cmlidXRlIHRoZSBjb21wdXRhdGlvbiBsb2FkLCB3aGljaCBpcyBhIGdv b2QgcG9pbnQsIGJ1dCBpbiByZXR1cm4geW91IGludHJvZHVjZSBzaWduaWZpY2FudCBjb21wbGV4 aXR5IG9uIFBDRXMgdGhhdCB3aWxsIGhhdmUgdG8gbWFpbnRhaW4gYSByZXF1ZXN0IHRhYmxlIGFu ZCBleGNoYW5nZSBzb21lIHNpZ25pZmljYW50IGFtb3VudCBvZiBzdGF0ZSAodGhpbmsgYWJvdXQg ZW1lcmdlbmN5IGNvbmRpdGlvbnMpLg0KW1pSSF0tLT5QZXJoYXBzIHRoZXJlIGlzIGEgZGlmZmVy ZW5jZSBmcm9tIG15IHByb3Bvc2FsIGhlcmUsICB0byBjbGFyaWZ5LCBpbiBmYWN0IHRoZXJlIGlz IG5vIGV4Y2hhbmdlIG9mIHN0YXRlLCB0aGUgc3RhdGUgaXMgb25seSBtYWludGFpbmVkIGluIGVh Y2ggUENFIGJhc2VkIG9uIHRoZSByZWNlaXZlZCByZXF1ZXN0cy4gSW4gbXkgb3BpbmlvbiwgZm9y IGEgUENFLCB0aGVyZSBzaG91bGQgIG5vdCBiZSAgbXVjaCBjb25zdW1wdGlvbiBvbiB0aGUgbWFp bnRhaW5pbmcgd29yaywgbW9zdCBvZiB3aGljaCB3aWxsIGNvbXByaXNlICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHJlY2VpdmluZywgcmVjb3JkaW5nIG9mIHJlcXVlc3RzLCBjaGFuZ2lu ZyBzdGF0ZSBvZiBkdXJpbmcgdGhlIHNlcnZpZS4NCi4NCkFsc28gdGhpbmsgYWJvdXQgdGhlIGxv YWQgeW91IGludHJvZHVjZSBvbiBQQ0NzLi4uIA0KW1pSSF0tLT5vbmx5IHNlbmRpbmcgYSByZXF1 ZXN0IHRvIG11bHRpIFBDRXMNCg0KSW4gc29tZSBpbnRlci1hcmVhIG5ldHdvcmtzIHdoZXJlIEFC UnMgYXJlIGFjdGluZyBhcyBQQ0VzIHlvdSBtYXkgc2V2ZXJhbCAxMHMgb2YgUENFIGluIHRoZSBi YWNrYm9uZSBhcmVhLCBhIFBDQyB3b3VsZCBoYXZlIHRvIHNlbmQgYSByZXF1ZXN0IHRvIGFsbCB0 aGVzZSBQQ0VzIGZvciBlYWNoIFRFLUxTUCB0byBiZSBjb21wdXRlZC4uLg0KW1pSSF0tLT5ZZXMs IHNvIHRoZSBwcm9wb3NhbCBpcyBub3QgY29uZm9ybWFibGUgZm9yIHRoaXMgZW52aXJvbm1lbnQs IHRoaXMgaXMgYW4gYXBwbGljYXRpb24tb3JpZW50ZWQsIG5vdCBhIHByb3RvY29sLCBzbyBpdCBj YW4gYmUgZGVjaWRlZCBpZiB0aGUgbWV0aGVkIGNhbiBiZSBlbXBsb3llZCBmb3IgYSBzcGVjaWZp YyBlbnZpcm9ubWVudC4NCg0KSSdtIG15IHZpZXcgYSBiZXR0ZXIgd2F5IHRvIHNvbHZlIHRoZXNl IHJhY2UgY29uZGl0aW9ucyBjb3VsZCBiZSB0byByZWx5IG9uIGEgcHJveHkgUENFLCB0aGF0IHdv dWxkIGFjdHVhbGx5IHJlY2VpdmUgcmVxdWVzdHMgZnJvbSBhbGwgUENDcywgYW5kIHdvdWxkIGFj dCBhcyBhIHBhdGggY29tcHV0YXRpb24gc2NoZWR1bGVyIGJ5IGFwcHJvcHJpYXRlbHkgc2VxdWVu Y2luZyByZXF1ZXN0cyBhbmQgZGlzdHJpYnV0aW5nIHJlcXVlc3RzIHRvIGEgc2V0IG9mIFBDRXMu IFRoaXMgd291bGQgYXZvaWQgc2VuZGluZyByZXF1ZXN0cyB0byBhbGwgUENFcywgDQpbWlJIXS0t PkFub3RoZXIgZ29vZCBpZGVhLCBob3dldmVyLCB0aGUgc2FtZSByZXN1bHQgb2NjdXIgb24gdGhl IHByb3h5LCB0aGF0IGlzIHRvIHJlY2VpdmUgYWxsIHRoZSByZXF1ZXN0cywgd2h5IG5vdCB0aGUg UENFIGhhdmUgdGhlIHNhbWUgY2FwYWJpbGl0eSBvbiByZWNlaXZpbmcgYW5kIGhhbmRsaW5nIHRo ZSBwYWNoZXRzLCBhbmQgSSB0aGluayBpdCBzaG91bGQuDQoNCmFuZCB3b3VsZCBhdm9pZCBtYWlu dGFpbmluZyBhbmQgc3luY2hyb25pemluZyByZXF1ZXN0IHRhYmxlcyBiZXR3ZWVuIGFsbCBQQ0Vz Lg0KW1pSSF0tLT5idXQgaG93IHRvIGF2b2lkIHRoZSByYWNlIGNvbmRpdGlvbnM/IGRvbmUgb24g dGhlIHByb3h5PyBpZiBzbywgaXQncyBmaW5lLg0KDQo+IA0KPiAgQW5vdGhlciBwdXJwb3NlIG9m IHRoZSBwcm9wb3NhbCBpcyB0byBkZWNyZWFzZSB0aGUgUENFIA0KPiBkaXNjb3ZlcnkncyBjb21w bGV4aXR5LiANCj4gQmVmb3JlIGEgUENDIGRlY2lkZXMgdG8gc2VuZCBhIA0KPiByZXF1ZXN0IHRv IGEgcHJvcGVyIFBDRSwgaXQgbXVzdCBsZWFybiBhIGxvdCBvZiBtZXNzYWdlcyBmcm9tIA0KPiB0 aGUgZGlmZmVyZW50IFBDRXMgdGhyb3VnaCBQQ0UgZGlzY292ZXJ5IHByb3RvY29sLCBhbmFseXNl IA0KPiBhbGwga2lua3Mgb2YgY2FwYWJpbGl0aWVzL3BvbGljaWVzIGNvbnRhaW5lZCBpbiB0aGUg bWVzc2FnZXMsIA0KPiBkbyBzb21lIG1haW50YWluaW5nIHdvcmssIHRoZXNlIHBlcmhhcHMgd2ls bCBtYWtlIHRoZSBQQ0MgDQo+IGZhbGwgaW50byBhIHBhaW5mdWwgc2l0dWF0aW9uIHdoaWNoIGdv ZXMgYmFjayBvbiB0aGUgDQo+IGludGVudGlvbiBvZiBQQ0UgYXJjaC4gDQoNClRoZSBQQ0UgZGlz Y292ZXJ5IGlzIGRvbmUgb25jZSwgYW5kIG5vdCBiZWZvcmUgZWFjaCByZXF1ZXN0LiBZb3UgYXJl IHJpdGhnIGRldGFpbGVkIFBDRSBkaXNjb3ZlcnkgcmVxdWlyZXMgbWVzc2FnZSBleGhhbmdlLCBi dXQgdGhpcyBpcyBkb25lIG9uY2UsIGFuZCBub3QgcGVyIHJlcXVlc3QuIEluIHlvdXIgcHJvcG9z YWwgYSBQQ0MgaGFzIHRvIHNlbmQgYSBtZXNzYWdlIHRvIGFsbCBQQ0VzIGFuZCBtYWludGFpbiBh IHRyYW5zaWVudCBzdGF0ZSBwZXIgbWVzc2FnZSBmb3IgZWFjaCByZXF1ZXN0LA0KW1pSSF0tLT5U byBjbGFyaXR5LCB0aGVyZSBpcyBubyBtYWludGFpbmluZyB3b3JrIG9uIHRoZSBQQ0MsIGV2ZW4g dGhlcmUgaXMgbm8gbW9yZSB3b3JrIGFkZGVkIHRvIFBDQyBpbiB0aGUgcHJvcG9zYWwgZXhjZXB0 IHRoZSBzZW5kaW5nLiBJIHRoaW5rIHRoZSBQQ0Ugc2hvdWxkIGhhdmUgYSBhZGVxdWF0ZSAgY2Fw YWJpbGl0eSBmb3IgdGhlc2UgYWRkZWQgbWFpbnRhaW5pbmcgd29yaywgc2hvdWxkbid0IGl0Pw0K DQogd2hpY2ggaXMgSU1ITyBtdWNoIG1vcmUgaGVhdnkgdGhhbiBhIGNhcGFiaWxpdHkgZGlzY292 ZXJ5IGF0IFBDQy1QQ0Ugc2Vzc2lvbiBzZXR1cC4gDQpbWlJIXS0tPkluIGZhY3QsIHRoZSBQQ0Mn cyB3b3JrIGlzIGxpZ2h0ZW5lZCwgYmVmb3JlIGEgcmVxdWVzdCBpcyBzZW50IGZyb20gYSBQQ0Ms IHRoZSBkaWNpc2lvbiB3aGljaCBQQ0UgdG8gc2VuZCBpcyBtYWRlIHJvdWdobHksIHRoZSBhY2N1 cmF0ZSBkaWNpc2lvbiBjYW4gYmUgIGRvbmUgYnkgYW55IFBDRS4gVGhpcyB3aWxsIHJlbGF4IGlt bWVuc2UgUENDcywgZXZlbiBpZiB0aGUgZGlzdm92ZXJ5IGlzIGRvbmUgb25jZSBvbiBlYWNoIFBD QywgYnV0IGl0IHdpbGwgYmUgbWFpbnRhaW5lZCBhbGwgdGhlIHdoaWxlLCBzZWUgeW91ciBleGFt cGxlICBhYm92ZSwgaW4gYSBiYWNrYm9uZSBhcmVhLCBhIFBDQyBwZXJoYXBzIG11c3QgbWFpbnRh aW4gdm9sdW1lcyBvZiBjYXBhYmlsaXRpZXMgbWVzc2FnZXMgZm9yIHNldmVyYWwgMTBzLCBldmVu IGlmIGl0IGhhdmUgdmVyeSBmZXcgcmVxdWVzdC4NCg0KVG8gcmVsYXggdGhlIFBDQydzIHdvcmss IHdpdGggdGhpcyANCj4gcHJvcG9zYWwsIGp1c3QgZ2V0IHRoZSBkaWNpc2lvbiBvZiB0aGUgZXhh Y3QgUENFIGZvciBhIA0KPiByZXF1ZXN0IGRvbmUgaW4gUENFLg0KPiBmb3IgdGhlIFBDQywgb25s eSBnZW5lcmljIGNhcGFiaWxpdGllcyBvZiBQQ0VzIGFyZSBsZWFybmVkLCANCg0KWWVzLCB0aGlz IGlzIGluIHN5bmMgd2l0aCB0aGUgUENFIGRpc2NvdmVyeSAgcmVxIElELCANCk5vdGUgdGhhdCB3 ZSBkaXN0aW5ndWlzaCB0d28gdHlwZXMgb2YgaW5mb3JtYXRpb24gdG8gYmUgZGlzY292ZXJlZDog Z2VuZXJhbCBpbmZvcm1hdGlvbiAobG9jYXRpb24sIHNjb3Blcy4uLikgYW5kIGRldGFpbGVkIGlu Zm9ybWF0aW9uIChjb25zdHJhaW50cywgb2JqZWN0aXZlIGZ1bmN0aW9ucy4uLikuIA0KVGhlIFBD RSBkaXNjb3ZlcnkgcHJvdG9jb2wgY291bGQgYmUgbGltaXRlZCB0byBnZW5lcmFsIGluZm9ybWF0 aW9uLiBUaGlzIHdvdWxkIG5vdCByZXF1aXJlIG1haW50YWluaW5nIGEgbG90IG9mIGluZm9ybWF0 aW9uIChhIHNldCBvZiBiaXQgZmxhZ3MgcGVyIFBDRSkuIA0KRGV0YWlsZWQgY2FwYWJpbGl0aWVz IGNvdWxkIGJlIGRpc2NvdmVyZWQgdGhhbmtzIHRvIHRoZSBQQ0MtUENFIGNvbW11bmNhdGlvbiBw cm90b2NvbCwgYXQgUENDLVBDRSBzZXNzaW9uIHNldHVwLg0KVGhpcyBpbmZvcm1hdGlvbiBpcyBx dWl0ZSBzdGF0aWMsIGFuZCBkaXNjb3Zlcnkgd291bGQgYmUgZG9uZSBvbmNlIGF0IHNlc3Npb24g c2V0dXAuDQpbWlJIXS0tPkl0J3MgZmluZSwgYSBnb29kIHNvbHV0aW9uLiBXaGF0IGFib3V0IHRo ZSBkZXRhaWxlZCBjYXBhYmlsaXRpZXMgYWZ0ZXIgYSByZXF1ZXN0IGlzIGRvbmU/IHRvIG1haW50 YWluIG9yIHRvIGRpc2NhcmQ/IEkgdGhpbmsgaXQgc2hvdWxkIGJlIG1haW50YWluZWQscmlnaHQ/ DQoNCj4gYmFzZWQgb24gd2hpY2ggUENDcyB3aWxsIGhvcGZ1bGx5IGNob29zZSB0aGUgcmlnaHQg UENFLCBpbiANCj4gY2FzZSBvZiBmYWlsdXJlIG9mIHRoZSBjaG9pY2UsIFBDRSBjYW4gZ2V0IGl0 IGRvbmUuIA0KDQpPZiBjb3Vyc2Ugc2VuZGluZyB0aGUgcmVxdWVzdCB0byBhbGwgUENFcyBhdm9p ZCBkZXRhaWxlZCBQQ0UgZGlzY292ZXJ5LiBidXQgRnJhbmtseSBzcGVha2luZyBJTUhPIHRoaXMg aW50cm9kdWNlcyBtdWNoIG1vcmUgY29tcGxleGl0eSB0aGFuIGl0IHRyaWVzIHRvIHJlZHVjZS4u Lg0KW1pSSF0tLT5JbmRlZWQsIHRoZXJlIGFyZSBzb21lIGNvbXBsZXhpdHksIGJ1dCBhbHNvIGdl dCByaWQgb2Ygc29tZSBjb21wbGV4aXR5LCBJIHRoaW5rIGl0IG1heSBiZSBhIHRyYWRlb2ZmIGlu IHNvbWUgZW52aXJvbm1lbnRzLg0KDQpUaGluayBhYm91dCB0aGUgbnVtYmVyIG9mIG1lc3NhZ2Vz IGFuZCB0cmFuc2llbnQgc3RhdGVzIChvbmUgcGVyIG1lc3NhZ2UpIGEgUENDIHdvdWxkIGhhdmUg dG8gbWFpbnRhaW4sIA0KW1pSSF0tLT5TZWUgbXkgY2xhcmlmaWNhdGlvbiBhYm92ZS4NCg0KQmVz dCB3aXNoZXMsDQpaaGFuZw0KDQpwYXJ0aWN1bGFybHkgdW5kZXIgbmV0d29yayBmYWlsdXJlIGNv bmRpdGlvbiwgY29tcGFyZWQgdG8gYSBzaW1wbGUgZGlzY292ZXJ5IGFzIHBhcnQgb2YgdGhlIFBD Qy1QQ0Ugc2Vzc2lvbiBzZXR1cC4uLg0KDQoNCkJlc3QgUmVnYXJkcywNCg0KSkwNCg0KPiANCj4g Q2hlZXJzLA0KPiBaaGFuZw0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBG cm9tOiAiTEUgUk9VWCBKZWFuLUxvdWlzIFJELUNPUkUtTEFOIiANCj4gPGplYW5sb3Vpcy5sZXJv dXhAZnJhbmNldGVsZWNvbS5jb20+DQo+IFRvOiAiWmhhbmcgUmVuaGFpIiA8emhhbmdyZW5oYWlA aHVhd2VpLmNvbT47IDxwY2VAaWV0Zi5vcmc+DQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDI2LCAy MDA1IDU6MTYgUE0NCj4gU3ViamVjdDogUkU6IFtQY2VdIEFib3V0IHRoZSANCj4gcHJlc2VudGF0 aW9ub2ZkcmFmdC16aGFuZy1wY2UtY29tbS1hcHAtbW9kZWwtMDEudHh0DQo+IA0KPiANCj4gSGkg WmhhbmcNCj4gDQo+IFNvcnJ5IGZvciByZXBseWluZyBzbyBsYXRlLi4uDQo+IA0KPiBQbGVhc2Ug c2VlIGlubGluZSwgDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERl IDogWmhhbmcgUmVuaGFpIFttYWlsdG86emhhbmdyZW5oYWlAaHVhd2VpLmNvbV0gDQo+ID4gRW52 b3npIDogbHVuZGkgOCBhb/t0IDIwMDUgMTA6MTANCj4gPiDAIDogTEUgUk9VWCBKZWFuLUxvdWlz IFJELUNPUkUtTEFOOyBwY2VAaWV0Zi5vcmcNCj4gPiBPYmpldCA6IFJlOiBbUGNlXSBBYm91dCB0 aGUgDQo+ID4gcHJlc2VudGF0aW9ub2ZkcmFmdC16aGFuZy1wY2UtY29tbS1hcHAtbW9kZWwtMDEu dHh0DQo+ID4gDQo+ID4gSGksIEplYW4gTG91aXMNCj4gPiANCj4gPiAgIE5pY2UgdG8gc2VlIHlv dXIgcXVlc3Rpb24gYWdhaW4gaW4gbWFpbGluZyBsaXN0LiBQbGVhc2UgDQo+IHNlZSBpbmxpbmUu DQo+ID4gDQo+ID4gDQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+IEZyb206 ICJMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4iIA0KPiA+IDxqZWFubG91aXMubGVyb3V4 QGZyYW5jZXRlbGVjb20uY29tPg0KPiA+IFRvOiAiWmhhbmcgUmVuaGFpIiA8emhhbmdyZW5oYWlA aHVhd2VpLmNvbT47IDxwY2VAaWV0Zi5vcmc+DQo+ID4gU2VudDogRnJpZGF5LCBBdWd1c3QgMDUs IDIwMDUgNjoxNCBQTQ0KPiA+IFN1YmplY3Q6IFJFOiBbUGNlXSBBYm91dCB0aGUgcHJlc2VudGF0 aW9uIA0KPiA+IG9mZHJhZnQtemhhbmctcGNlLWNvbW0tYXBwLW1vZGVsLTAxLnR4dA0KPiA+IA0K PiA+IA0KPiA+IEhpIFpoYW5nDQo+ID4gDQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUgDQo+ID4gDQo+ ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlIDogcGNlLWJvdW5jZXNA bGlzdHMuaWV0Zi5vcmcgDQo+ID4gPiBbbWFpbHRvOnBjZS1ib3VuY2VzQGxpc3RzLmlldGYub3Jn XSBEZSBsYSBwYXJ0IGRlIFpoYW5nIFJlbmhhaQ0KPiA+ID4gRW52b3npIDogbWVyY3JlZGkgMyBh b/t0IDIwMDUgMTU6MjgNCj4gPiA+IMAgOiBwY2VAaWV0Zi5vcmcNCj4gPiA+IE9iamV0IDogW1Bj ZV0gQWJvdXQgdGhlIHByZXNlbnRhdGlvbiANCj4gPiA+IG9mZHJhZnQtemhhbmctcGNlLWNvbW0t YXBwLW1vZGVsLTAxLnR4dA0KPiA+ID4gDQo+ID4gPiBIaSwgYWxsDQo+ID4gPiAgDQo+ID4gPiAg U29ycnkgZm9yIG5vdCBhbGwgY2xlYXIgYWJvdXQgc29tZSBxdWVzdGlvbnMgYXNrZWQgdG8gbWUg YXQgDQo+ID4gPiB0aGUgbWVldGluZy4NCj4gPiA+IEkgcmVhbGx5IGFwcHJlY2lhdGUgdGhhdCBz b21lb25lIGNhbiByZXBlYXQgdGhlIHF1ZXN0aW9uIGFuZCANCj4gPiA+IHdlIGNhbiBkaXNjdXNz IG1vcmUgaGVyZS4NCj4gPiANCj4gPiBTdXJlLCBoZXJlIGl0IGlzOg0KPiA+IA0KPiA+IEpMLT5U aGUgcHJvYmxlbSB5b3UgcmFpc2UgaXMgdmFsdWFibGUsIHJhY2UgY29uZGl0aW9uIGlzc3VlcyAN Cj4gPiB3aWxsIGluY3JlYXNlIGluIGNhc2Ugb2YgZGlzdHJpYnV0ZWQtUENFIGNvbXB1dGF0aW9u IHdpdGggDQo+ID4gZXh0ZXJuYWwgUENFcywgYXMgdGhlIGRlbGF5IGJldHdlZW4gcGF0aCBjb21w dXRhdGlvbiBhbmQgcGF0aCANCj4gPiBzZXR1cCB3aWxsIGluY3JlYXNlLiBCdXQgSSBoYXZlIHNv bWUgc2NhbGFiaWxpdHkgY29uY2VybnMgDQo+ID4gd2l0aCB5b3VyIHByb3Bvc2VkIHNvbHV0aW9u OiBCYXNpY2FsbHkgb25lIG9iamVjdGl2ZSBvZiBQQ0UgDQo+ID4gZGlzdHJpYnV0aW9uIHdvdWxk IGJlIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIHJlcXVlc3RzIHRvIGJlIA0KPiA+IGhhbmRsZWQg YnkgUENFcywgYXMgdGhpcyBjb3VsZCBiZSB0aGUgYm90dGxlbmVjaywgYW5kIGhlcmUgDQo+ID4g YWN0dWFsbHkgeW91ciBwcm9wb3NhbCByZXF1aXJlcyBzZW5kaW5nIHJlcXVlc3RzIHRvIGFsbCBQ Q0VzLiANCj4gPiBIZW5jZSBhbGwgUENFcyB3aWxsIHN1cHBvcnQgdGhlIHdob2xlIFBDQ3MnIHJl cXVlc3RzIGxvYWQuDQo+ID4gDQo+ID4gWlJILS0tLT5TZW5kaW5nIHJlcXVlc3RzIHRvIGFsbCBQ Q0VzIGlzIGEgbWV0aG9kIHRvIG1ha2UgaXQgDQo+ID4gcG9zc2libGUgdGhhdCBlYWNoIFBDRSBj YW4ga25vdyB0aGUgY3VycmVudCByZXNvdXJjZXMgDQo+ID4gYXBwbGljYXRpb24gc3RhdHVzLCAN Cj4gDQo+IFllcyBJIHVuZGVyc3RhbmQgdGhpcyBwb2ludCwgYnV0IHRoZSBpc3N1ZSBpcyB0aGF0 IHRoZSANCj4gcmVxdWVzdCBtZXNzYWdlcyBsb2FkIGlzIG5vIGxvbmdlciBkaXN0cmlidXRlZCwg YSBQQ0Ugd2lsbCANCj4gcmV2ZWl2ZSBhbGwgcmVxdWVzdHMsIGFuZCBJTUhPIHRoaXMgbWF5IHNp Z25pZmljYW50bHkgDQo+IGRpbWluaXNoIHRoZSBiZW5lZml0cyBvZiBQQ0UgZGlzdHJpYnV0aW9u Lg0KPiBUaGlzIG1heSBiZSBPSyBpbiBzdGVhZHkgc3RhdGUgYnV0IGxldCdzIHRha2UgYW4gZW1l cmdlbmN5IA0KPiBjb25kaXRpb246IEZvciBpbnN0YW5jZSBsZXQncyB0YWtlIGEgTGluay9ub2Rl IGZhaWx1cmUgaW4gdGhlIA0KPiBjb3JlLCB3aGljaCBpbXBhY3RzIGEgbGFyZ2UgbnVtYmVyIG9m IFRFLUxTUHMuIE1hbnkgUENDcyBhcmUgDQo+IGdvaW5nIHRvIHNpbXVsdGFuZW91c2x5IHNlbmQg YSByZXF1ZXN0IHRvIGFsbCBQQ0VzLiANCj4gVGhpcyByYWlzZXMgYSBzY2FsYWJpbGl0eSBpc3N1 ZSByZWdhcmRpbmcgdGhlIG51bWJlciBvZiANCj4gbWVzc2FnZXMgdG8gYmUgaGFuZGxlZCBieSBl YWNoIFBDRSBhbmQgYWxzbyByZWdhcmRpbmcgdGhlIA0KPiBzaXplIG9mIHRoZSByZXF1ZXN0IHRh YmxlIHRvIGJlIG1haW50YWluZWQgb24gZWFjaCBQQ0UgKCMgDQo+IGZhaWxlZCBMU1BzKS4NCj4g DQo+IA0KPiBhbmQgYWNjb3JkaW5nbHkNCj4gPiBjYW4gc29ydCBvcmRlciBmb3IgdGhlIHJlcXVl c3RzIHdoaWNoIG1heSBiZSBjb21wdXRlZCBpbiANCj4gPiBkaWZmZXJlbnQgUENFcywgZm9yIGV4 YW1wbGUsIHJlcTEgYW5kIHJlcTIgYXJlIHNlbmQgDQo+ID4gcmVwZWN0aXZlbHkgdG8gUENFMSwg UENFMiwgYW5kIHJlcTEgaGFzDQo+ID4gYSBsb3dlciBwcmlvcml0eSB0aGFuIHJlcTIsIGJ1dCBp ZiBQQ0UxIGRvZXNuJ3Qga25vdyB0aGF0IA0KPiA+IHRoZXJlIGlzIGFub3RoZXIgcmVxIHdpdGgg YSBoaWdoZXIgcHJpb3JpdHkocmVxMiBpcyBzZW50IHRvIA0KPiA+IFBDRTIpLCAgaXQgbWF5IHRh a2UgdGhlIHJlc291cmNlIHRoYXQgcmVxMg0KPiA+IG1heSBhbHNvIG5lZWQgYW5kIG9ubHkgc3Vm ZmljZSBvbmUgcmVxdWVzdC4gDQo+IA0KPiBZZXMgSSBjbGVhcmx5IGFncmVlIHRoYXQgeW91ciBw cm9wb3NhbCB3b3VsZCBoZWxwIHNvbHZpbmcgdGhlIA0KPiByYWNlIGNvbmRpdGlvbiBpc3N1ZSwg YnV0IHRvIG15IG1pbmQgdGhlIGNvbXBsZXhpdHkgDQo+IGludHJvZHVjZWQgc2lnbmlmaWNhbnRs eSAgcmVkdWNlcyB0aGUgYmVuZWZpdHMgb2YgdGhpcyBhcHJvYWNoLg0KPiANCj4gDQo+IFRoZW4g d2hlbiBQQ0UyIGlzIA0KPiA+IGNvbXB1dGluZyB0aGUgcGF0aCBmb3IgcmVxMiBsYXRlciwgd2hh dCBhYm91dCB0aGUgcmVzdWx0PyANCj4gPiB0ZWFyZG93biB0aGUgZmlyc3QgcGF0aCBjb21wdXRl ZCANCj4gPiBmb3IgcmVxMT8gb3IgcmVwbHkgdGhlIGZhaWx1cmUgb2YgdGhlIGNvbXB1dGF0aW9u IGZvciByZXEyPw0KPiA+IFNvIGlmIGJvdGggdGhlIFBDRTEgYW5kIFBDRTIga25vdyB0aGUgYWxs IHRoZSBjdXJyZW50IA0KPiA+IHJlcXVlc3RzLCBiYXNlZCBvbiBzb21lIHBvbGljaWVzIGNvbmZp Z3VyZWQgYnkgb3BlcmF0b3IsIFBDRTEgDQo+ID4gY2FuIGRlbGF5IHRoZSBjb21wdXRhdGlvbiBm b3IgcmVxMSwNCj4gDQo+ID4gdG8gZ2V0IHRoZSBjb21wdXRhdGlvbiBvcmRlcmx5IGFuZCBtYWtl IHN1cmUgdGhlIHJlc291cmNlcyANCj4gPiBkaXN0cmlidXRlZCByZWFzb25hYmx5Lg0KPiA+IA0K PiA+IA0KPiA+IEpMLT5JTUhPIHRoaXMgbWF5IHNpZ25pZmljYW50bHkgZGlzbWluaXNoIHRoZSBi ZW5lZml0cyBvZiBQQ0UgDQo+ID4gZGlzdHJpYnV0aW9uLg0KPiA+IA0KPiA+IFpSSC0tLT5FYWNo IFBDRSBrbm93aW5nIGFsbCB0aGUgcmVxdWVzdHMgZG9lc24ndCBtZWFucyB0byBhZGQgDQo+ID4g dGhlIGxvYWQgb2YgY29tcHV0YXRpb24gdG8gZWFjaCBQQ0UsIGl0J3MganVzdCBnaXZlIGVhY2gg UENFIA0KPiA+IGVub3VnaCBpbmZvcm1hdGlvbiB0byBtYWtlIHRoZSBQQ0VzIHdvcmtpbmcgY29v cGVyYXRpdmVseS4gDQo+IA0KPiBUaGUgaXNzdWUgaXMgdGhhdCB0aGUgYm9vdGxlbmVjayBkb2Vz IG5vdCBvbmx5IHJlbHkgb24gdGhlIA0KPiBsb2FkIG9mIGNvbXB1dGF0aW9uLCBidXQgYWxzbywg YW5kIGFib3ZlIGFsbCwgb24gdGhlIGxvYWQgb2YgDQo+IG1lc3NhZ2VzIHRvIGJlIGhhbmRsZWQg YW5kIG9uIHRoZSBhbW91bnQgb2YgaW5mb3JtYXRpb24gdG8gYmUgDQo+IG1haW50YWluZWQuLi4N Cj4gDQo+ID4gU2VlIHRoZSBleGFtcGxlIGFnYWluLCBQQ0UxIGtub3dzIHRoZXJlIGFyZSBiZWlu ZyB0d28gDQo+ID4gcmVxdWVzdHMgYnV0IG9ubHkgY29tcHV0ZXMgcmVxMSwgUENFMiBrbm93cyB0 aGVyZSBhcmUgYmVpbmcgdHdvIGJ1dCANCj4gPiBvbmx5IGNvbXB1dGVzIHJlcTIuDQo+IA0KPiBZ ZXMgSSBjbGVhcmx5IHVuZGVyc3RhbmQgdGhhdCwgYnV0IGl0IGhhcyBhdCBsZWFzdCB0byBwYXJz ZSANCj4gcmVxMSBtZXNzYWdlIGFuZCBzdG9yZSByZWxhdGVkIGluZm9ybWF0aW9uLiBJbiBzb21l IGVtZXJnZW5jeSANCj4gY29uZGl0aW9ucyB0aGlzIG1heSBsZWFkIHRvIGEgbGFyZ2UgbnVtYmVy IG9mIHJlcXVlc3QgdG8gYmUgDQo+IGhhbmRsZWQgYW5kIGEgaHVnZSBhbW91bnQgb2YgaW5mb3Jt YXRpb24gdG8gYmUgbWFpbnRhaW5lZC4uLg0KPiANCj4gQW55d2F5IHRoZSByYWNlIGNvbmRpdGlv biBwcm9ibGVtIHlvdSByYWlzZWQgaXMgaGlnaGx5IA0KPiB2YWx1YWJsZSwgYnV0IElNSE8gd2Ug bmVlZCBtb3JlIGRpc2N1c3Npb25zIG9uIHRoZSB3YXkgdG8gDQo+IGFkZHJlc3MgaXQuLi4NCj4g DQo+IFRoYW5rcywNCj4gDQo+IEpMDQo+IA0KPiA+IA0KPiA+IFRoYW5rcyBhbmQgUmVnYXJkcywN Cj4gPiBaaGFuZw0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEpMLT5Bbnl3YXkgdGhhbmtzIGZvciBo aWdsaWdodGluZyB0aGlzIHByb2JsZW0sIGFuZCBmb3IgDQo+ID4gaW5pdGlhdGluZyBkaXNjdXNz aW9uLiANCj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IA0KPiA+IEpMDQo+ID4gDQo+ID4gDQo+ID4g PiANCj4gPiA+ICBBY3R1YWxseSwgd2hhdCBJIHByb3Bvc2VkIHN1cmVseSBpcyBqdXN0IGFwcGxp ZWQgdG8gc29tZSANCj4gPiA+IGtpbmQgb2YgY2lyY3Vtc3RhbmNlcy4gRm9yIGV4YW1wbGUsIGlm IHRocmVlIFBDRXMgYXJlIHNlcnZpbmcgDQo+ID4gPiBhbGwgcmVxdWVzdHMgaW4gYSBkb21haW4s IGFuZCB0aGVzZSBQQ0VzIGFyZSBjb3VwbGVkIGNsb3NlbHksIA0KPiA+ID4gZm9yIGluc3RhbmNl LCB0aGV5IG1heSBiZSBsb2NhdGVkIGluIGRpZmZlcmVudCBib3ggYnV0IGluIHRoZSANCj4gPiA+ IHNhbWUgdGFuayBvciByb29tLCBvciBsb2NhdGVkIGluIGRpZmZlcmVudCBwbGFjZSByZW1vdGUg dG8gDQo+ID4gPiBlYWNoIG90aGVyIGFuZCBjb25uZWN0ZWQgYnkgYSBoaWdoIHNwZWVkIGxpbmUs IHNvIGJhc2VkIG9uIG15IA0KPiA+ID4gcHJvcG9zYWwsIGV2ZW4gb25seSBvbmUgcmVxdWVzdCBp cyBzZW50IHRvIG9uZSBvZiB0aGVzZSBQQ0UsIA0KPiA+ID4gYW5kIHRoZSBQQ0UgY2FuIGZvcndh cmQgdGhlIHJlcXVlc3QgdG8gb3RoZXIgdHdvIFBDRXMgcXVpY2tseSANCj4gPiA+IHRvIG1ha2Ug dGhlIHR3byBQQ0VzIG1haW50YWluIHRoZSByZXF1ZXN0IHRhYmxlLGFuZCB0aGlzIA0KPiA+ID4g ZGVsYXRpb24gb2YgdHJhbnNtaXR0aW9uIG1heSBiZSBpZ25vZWQgIGJ5IHNvbWUgdHJhZGVvZmYu DQo+ID4gPiBUaGUgZXNzZW50aWFsIGdvYWwgb2YgdGhlIGRyYWZ0IGlzIGp1c3QgdG8gdXNlIHRo ZSB0YWJsZSB0byANCj4gPiA+IHNvbHZlIHNvbWUga25vd24gcXVlc3Rpb24uDQo+ID4gPiAgSSBk b24ndCBrbm93IGhvdyB0aGUgY29tbXVuaWNhdGlvbiBmb3IgdGhlIGRldGFpbGVkIA0KPiA+ID4g ZGlzY292ZXJ5IHdpbGwgYmUgYmVjYXVzZSB0aGUgZGV0YWlsZWQgY2FwYWJpbGl0eSBpcyBzdGls bCANCj4gPiA+IG5vdCBzcGVjaWZpZWQgbm93LCBob3cgY29tcGxpY2F0ZWQgYSBkZXRhaWxlZCBj YXBhYmlsaXR5IA0KPiA+ID4gY291bGQgYmUgZm9yIGEgc3BlY2lhbCByZXF1ZXN0PyBDYW4gYSB0 cmFkZW9mZiBiZSBtYWRlIA0KPiA+ID4gYmV0d2VlbiBiZWxvdyB0d28gY2hvaWNlIGZvciBzb21l IHNwZWNpYWwgYXBwbGljYXRpb246DQo+ID4gPiAgDQo+ID4gPiAgIC1zYXZpbmcgdGhlIGRldGFp bGVkIGRpc2NvdmVyeSBjb21tdW5pY2F0aW9uLCANCj4gPiA+IGNvcnJlc3BvbmRpbmdseSBzZW5k aW5nIA0KPiA+ID4gICAgdGhlIHNhbWUgcmVxdWVzdCB0byBhbGwgUENFcyhvciBqdXN0IG9uZSBv ZiB0aGVzZSBQQ0VzIA0KPiA+ID4gbGlrZSB3aGF0IEkgbWVudGlvbmVkIGFib3ZlKQ0KPiA+ID4g ICAtcGVyZm9ybWluZyB0aGUgZGV0YWlsZWQgZGlzY292ZXJ5IGNvbW11bmljYXRpb24gZm9yIGVh Y2ggUENDPw0KPiA+ID4gDQo+ID4gPiAgIENlcnRhaW5seSx0aGlzIHByb3Bvc2FsIGlzIG5vdCBp bnRlbnQgdG8gYmVjYW1lIHBhcnQgb2YgdGhlIA0KPiA+ID4gUENFIGNvbW11bmljYXRpb24gcHJv dG9jb2wuDQo+ID4gPiANCj4gPiA+ICBBbm90aGVyIGNvbmNlcm4gb2YgdGhpcyBkcmFmdCBpcyB0 byBtYWtlIHRoZSByZXF1ZXN0cyANCj4gPiA+IGRpc3RyaWJ1dGVkIHRvIGRpZmZlcmVudCBQQ0Ug bW9yZSAqcmVhc29uYWJsZSosIGZvciBleGFtcGxlLCANCj4gPiA+IHRocmVlIFBDRXMgaW4gYSBk b21haW4sIFBDRTEsIFBDRTIsIFBDRTMsIGFuZCBub3cgUENFMyBpcyANCj4gPiA+IGNvbmdlc3Rl ZCB3aXRoIHRvbyBtdWNoIHJlcXVlc3RzIG9yIG90aGVyIHJlYXNvbiwgZm9yIHRoZSBQQ0MgDQo+ ID4gPiBvcmlnaW5hdGluZyB0aGUgcmVxdWVzdCwgd2hpY2ggUENFIGVsc2Ugc2hvdWxkIGl0IGNo b29zZT8gDQo+ID4gPiBQQ0UxIG9yIFBDRTI/IHdoYXQgaW5mb3JtYXRpb24gc2hvdWxkIGJlIHVz ZWQgdG8gaGVscCB0byANCj4gPiA+IHNlbGVjdCBhZ2FpbiBtb3JlIHJlYXNvbmFibGU/IEJhc2Vk IG9uIHRoZSBHbG9iYWwgQ29tcHV0aW5nIA0KPiA+ID4gVGFibGUsIHRoZSBjb25nZXN0aW5nIFBD RShQQ0UzKSB3aWxsIGtub3cgdGhlIG51bWJlciBvZiANCj4gPiA+IHJlcXVlc3RzIHRoYXQgb3Ro ZXIgUENFIGlzIG5vdyBkZWFsaW5nIHdpdGgsIGFsdGhvdWdoIFBDRTEgYW5kDQo+ID4gPiBQQ0Uy IGJvdGggYXJlIG5vdCBjb25nZXN0ZWQgbm93LCBiYXNlZCBvbiB0aGUgbWVudGlvbmVkIA0KPiA+ ID4gaW5mb3JtYXRpb24sIFBDRTMgY2FuIHNlbGVjdCBvdGhlciBQQ0Ugd2l0aCBsZWFzdCBudW1i ZXIgb2YgDQo+ID4gPiByZXF1ZXN0cyBhbmQgYXBwcm9wcmlhdGUgY2FwYWJpbGl0eSB0byBtYWtl IHN1cmUgdGhlIFBDQyBjYW4gDQo+ID4gPiBnZXQgdGhlIGNvbXB1dGF0aW9uIHJlc3VsdCBhc2Fw LCBhbmQgSSB0aGluayB0aGUgdGltZSBmcm9tIA0KPiA+ID4gc2VuZGluZyByZXF1ZXN0IHRvIHJl Y2VpdmluZyB0aGUgY29tcHV0aW5nIHJlc3VsdCBtYXkgYmUgYSANCj4gPiA+IGltcG9ydGFudCBj b25zaWRlcmF0aW9uIGZvciBzb21lIGFwcGxpY2F0aW9uLg0KPiA+ID4gDQo+ID4gPiBDaGVlcnMs DQo+ID4gPiBaaGFuZw0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IFBjZSBtYWlsaW5nIGxp c3QNCj4gPiA+IFBjZUBsaXN0cy5pZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGNlDQo+ID4gPg0KPiA+DQo+DQoNCg0K --===============1066614229== 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 --===============1066614229==-- From pce-bounces@lists.ietf.org Sun Sep 04 17:27:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC21P-0005hM-7F; Sun, 04 Sep 2005 17:27:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC21N-0005hA-Qp for pce@megatron.ietf.org; Sun, 04 Sep 2005 17:27:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25541 for ; Sun, 4 Sep 2005 17:27:23 -0400 (EDT) Received: from web30504.mail.mud.yahoo.com ([68.142.200.117]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EC23v-0000jk-6L for pce@ietf.org; Sun, 04 Sep 2005 17:30:09 -0400 Received: (qmail 86959 invoked by uid 60001); 4 Sep 2005 21:27:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=roGQs7RIlmlX8F2TRoILeyP2eSOPxA0XseIOo+PlRkBeu9ZwW7tHUYm2We6nxWaIJKV+0YN9Z2TWczdvp1F4S435psxmxctpCMBuSbLIKoih1mJ62KsYaxJsdJDW4NcLsl1cxS20hB8HtS04XxxywtTPmgPU7X82+zW/Sux5OOg= ; Message-ID: <20050904212708.86957.qmail@web30504.mail.mud.yahoo.com> Received: from [213.94.134.32] by web30504.mail.mud.yahoo.com via HTTP; Sun, 04 Sep 2005 22:27:07 BST Date: Sun, 4 Sep 2005 22:27:07 +0100 (BST) From: Stephen Morris Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, JP Vasseur In-Reply-To: <4316A99D.8000806@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.5 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA25541 Cc: Ting_Wo Chung , pce@ietf.org, Richard Rabbat , "raymond.zhang" , Paul Mabey 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP, All In section 6.3. "PCE Information Synchronization", does this requirement allow for a PCE to notify an interested entity (e.g., a network management system) of a capability (or some other) change? Best wishes Stephen --- dimitri papadimitriou wrote: > hi jp, all >=20 > the following chart discussed by JL during the last > meeting pretty well=20 > summarize the issues >=20 > >=20 > based on the discussion one has had during the > meeting (and even if it=20 > not appropriate to consider specific implementation) > one could draw some=20 > line that for "discovering" the exact state (load, > congestion) and=20 > detailed capabilities a protocol preserving several > requirements such as=20 > adapted to exchange of such detailed information, > minimize overhead=20 > (conservative), confidentiality, etc. >=20 > thanks, > - dimitri. >=20 >=20 >=20 > JP Vasseur wrote: >=20 > > Hi Jean-Louis, > >=20 > > On Aug 31, 2005, at 3:13 AM, LE ROUX Jean-Louis > RD-CORE-LAN wrote: > >=20 > >> Hi Jean-Philippe, > >> > >> we plan to post a new revision by mid-september. > >> Is that OK? > >> > >=20 > > Perfect, thanks. Provided that the remaining > issues are sorted out, we=20 > > could go for WG LC on this ID. > >=20 > > JP. > >=20 > >> Regards, > >> > >> JL > >> > >> > >>> -----Message d'origine----- > >>> De : JP Vasseur [mailto:jvasseur@cisco.com] > >>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey; > Eiji Oki; > >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang > >>> Cc : pce@ietf.org > >>> Objet : Progress on > draft-ietf-pce-discovery-reqs-01.txt > >>> > >>> Hi, > >>> > >>> First of all, thanks for the very significant > progress which > >>> has been made on this ID over the past 6 months. > As discussed > >>> during the last meeting in Paris, there are > still a few > >>> issues to be sorted out. > >>> Could we try to close on these remaining issues > so as to > >>> quickly start the protocol work (we're a bit > late on this Milestone) ? > >>> > >>> Thanks. > >>> > >>> JP. > >>> > >> > >=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 >=20 =09 ___________________________________________________________=20 To help you stay safe and secure online, we've developed the all new Yaho= o! Security Centre. http://uk.security.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sun Sep 04 17:30:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC24l-0006CN-7o; Sun, 04 Sep 2005 17:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC24j-0006CH-0S for pce@megatron.ietf.org; Sun, 04 Sep 2005 17:30:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25685 for ; Sun, 4 Sep 2005 17:30:50 -0400 (EDT) Received: from web30509.mail.mud.yahoo.com ([68.142.200.122]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EC27K-0000pF-Mi for pce@ietf.org; Sun, 04 Sep 2005 17:33:37 -0400 Received: (qmail 20134 invoked by uid 60001); 4 Sep 2005 21:30:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=54l4SCAZxWpt8auqBk8wwfpwPO9ksm+sEvTkvEQzGwisLhiVD+ICs2d59TaUK4OeI1wO1uwpUbhBH4Kqo/V1rQAFq3DjUU9uWfDX+bwHj2V9QDmDipqLJi3L4gkJavnXFNzaMnUi8GLw0eWmlr2FzZpF00s6S4KTkyPA/l6L4DA= ; Message-ID: <20050904213041.20132.qmail@web30509.mail.mud.yahoo.com> Received: from [213.94.134.32] by web30509.mail.mud.yahoo.com via HTTP; Sun, 04 Sep 2005 22:30:41 BST Date: Sun, 4 Sep 2005 22:30:41 +0100 (BST) From: Stephen Morris To: pce@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit Cc: Subject: [Pce] Re: Management Issues 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi All Any comments on my message below :-)? Best wishes Stephen --- Stephen Morris wrote: > Hi All > I have a few comments/suggestions about the > architecture document sections 8.1, 8.3, & 10: > > (1) Section 8.1 > I suggest we allow path computations to be initiated > using SNMP (e.g., set a variable). This potentially > opens up PCE technology to existing NMS/OSS > products. > Just a new (PCE) MIB module and some backend code is > needed to integrate PCE technology in this case. > > Path computation completion might be indicated by an > informational notification or an SNMP response. > Another approach might be the use of polling to > allow > a PCC to query PCE completion of a path request. > > (2) Section 8.3 > Correctness - maybe provide ping access through > SNMP? > > (3) Section 10 > IANA might be needed for the MIB module? > > (4) A further manageability item is deployment or > software distribution. Let's say I have LSR X from > vendor Y and I want to upgrade LSR X to include PCE > capability. Or let's say I want to upgrade a number > of > LSRs to support PCE. While this is mostly an NMS/OSS > issue (ftp, tftp etc.), the PCE element can help by > supporting software version data (i.e., deployment > data). > > Best wishes > Stephen Morris > > > > ___________________________________________________________ > > To help you stay safe and secure online, we've > developed the all new Yahoo! Security Centre. > http://uk.security.yahoo.com > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Sep 05 01:50:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC9sS-0004Lu-P8; Mon, 05 Sep 2005 01:50:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EC9sQ-0004LG-Ik for pce@megatron.ietf.org; Mon, 05 Sep 2005 01:50:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13868 for ; Mon, 5 Sep 2005 01:50:09 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EC9uc-000395-Tx for pce@ietf.org; Mon, 05 Sep 2005 01:52:59 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Sep 2005 07:49:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Date: Mon, 5 Sep 2005 07:49:43 +0200 Message-ID: Thread-Topic: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Thread-Index: AcWxl6UrrDO77yq+S7yCIq6zUCoRmgARcLpQ From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Stephen Morris" , , , "JP Vasseur" X-OriginalArrivalTime: 05 Sep 2005 05:49:44.0673 (UTC) FILETIME=[9E01BD10:01C5B1DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: Ting_Wo Chung , pce@ietf.org, Richard Rabbat , "raymond.zhang" , Paul Mabey 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Stephen, If the "interested entity" is a PCC then the answer is YES. Regards JL=20 > -----Message d'origine----- > De : pce-bounces@lists.ietf.org=20 > [mailto:pce-bounces@lists.ietf.org] De la part de Stephen Morris > Envoy=E9 : dimanche 4 septembre 2005 23:27 > =C0 : dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be;=20 > JP Vasseur > Cc : Ting_Wo Chung; pce@ietf.org; Richard Rabbat;=20 > raymond.zhang; Paul Mabey > Objet : Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt >=20 > Hi JP, All > In section 6.3. "PCE Information Synchronization", does this=20 > requirement allow for a PCE to notify an interested entity=20 > (e.g., a network management system) of a capability (or some=20 > other) change? > Best wishes > Stephen >=20 > --- dimitri papadimitriou > wrote: >=20 > > hi jp, all > >=20 > > the following chart discussed by JL during the last meeting pretty=20 > > well summarize the issues > >=20 > > > > >=20 > > based on the discussion one has had during the > > meeting (and even if it=20 > > not appropriate to consider specific implementation) > > one could draw some=20 > > line that for "discovering" the exact state (load, > > congestion) and=20 > > detailed capabilities a protocol preserving several > > requirements such as=20 > > adapted to exchange of such detailed information, > > minimize overhead=20 > > (conservative), confidentiality, etc. > >=20 > > thanks, > > - dimitri. > >=20 > >=20 > >=20 > > JP Vasseur wrote: > >=20 > > > Hi Jean-Louis, > > >=20 > > > On Aug 31, 2005, at 3:13 AM, LE ROUX Jean-Louis > > RD-CORE-LAN wrote: > > >=20 > > >> Hi Jean-Philippe, > > >> > > >> we plan to post a new revision by mid-september. > > >> Is that OK? > > >> > > >=20 > > > Perfect, thanks. Provided that the remaining > > issues are sorted out, we=20 > > > could go for WG LC on this ID. > > >=20 > > > JP. > > >=20 > > >> Regards, > > >> > > >> JL > > >> > > >> > > >>> -----Message d'origine----- > > >>> De : JP Vasseur [mailto:jvasseur@cisco.com] > > >>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey; > > Eiji Oki; > > >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang > > >>> Cc : pce@ietf.org > > >>> Objet : Progress on > > draft-ietf-pce-discovery-reqs-01.txt > > >>> > > >>> Hi, > > >>> > > >>> First of all, thanks for the very significant > > progress which > > >>> has been made on this ID over the past 6 months. > > As discussed > > >>> during the last meeting in Paris, there are > > still a few > > >>> issues to be sorted out. > > >>> Could we try to close on these remaining issues > > so as to > > >>> quickly start the protocol work (we're a bit > > late on this Milestone) ? > > >>> > > >>> Thanks. > > >>> > > >>> JP. > > >>> > > >> > > >=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 > >=20 >=20 >=20 >=20 > =09 > ___________________________________________________________=20 > To help you stay safe and secure online, we've developed the=20 > all new Yahoo! Security Centre. http://uk.security.yahoo.com >=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 Mon Sep 05 08:43:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGJZ-0007wY-OH; Mon, 05 Sep 2005 08:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGJR-0007w4-Ft for pce@megatron.ietf.org; Mon, 05 Sep 2005 08:43:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14589 for ; Mon, 5 Sep 2005 08:42:59 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECGMA-0005mQ-L9 for pce@ietf.org; Mon, 05 Sep 2005 08:45:53 -0400 Received: from du-069-0031.access.clara.net ([217.158.132.31] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1ECGJ8-000Mjh-75; Mon, 05 Sep 2005 13:42:44 +0100 Message-ID: <013d01c5b217$b0b103f0$93849ed9@Puppy> From: "Adrian Farrel" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Stephen Morris" References: Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Date: Mon, 5 Sep 2005 11:35:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA14589 Cc: pce@ietf.org 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Jean-Louis is right; the requirement is focused on allowing PCEs to conve= y information to PCCs. Another entity would be able to "listen in" and gather information for it= s own use, but such a requirement is out of scope for this document. I guess it depends on the purpose of the function you are suggesting. For example, if you want the NMS to be able to track the status of the PCE, this would probably be a perfectly adequate technique. However, it does rely on the NMS being able to listen in. That is: suppose the solution to PCE discovery is an opaque LSA in OSPF; you would need the NMS to be able to participate (at least passively) in the OSPF exchanges. Since the NMS may be remote through a distinct management plane network, this might not be possible. The alternative solution to gathering status information at the NMS would appear to be unchanged from the way network devices report status information today. From an IETF standardisation point of view, this requires MIB modules to allow the NMS to read information and to let the PCE report asynchronous Notifications. Obviously, piles of other proprietary or standard mechanisms exist outside the IETF. Cheers, Adrian ----- Original Message -----=20 From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Stephen Morris" ; ; ; "JP Vasseur" Cc: "Ting_Wo Chung" ; ; "Richard Rabbat" ; "raymond.zhang" ; "Paul Mabey" Sent: Monday, September 05, 2005 6:49 AM Subject: RE: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Hi Stephen, If the "interested entity" is a PCC then the answer is YES. Regards JL > -----Message d'origine----- > De : pce-bounces@lists.ietf.org > [mailto:pce-bounces@lists.ietf.org] De la part de Stephen Morris > Envoy=E9 : dimanche 4 septembre 2005 23:27 > =C0 : dpapadimitriou@psg.com; dimitri.papadimitriou@alcatel.be; > JP Vasseur > Cc : Ting_Wo Chung; pce@ietf.org; Richard Rabbat; > raymond.zhang; Paul Mabey > Objet : Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt > > Hi JP, All > In section 6.3. "PCE Information Synchronization", does this > requirement allow for a PCE to notify an interested entity > (e.g., a network management system) of a capability (or some > other) change? > Best wishes > Stephen > > --- dimitri papadimitriou > wrote: > > > hi jp, all > > > > the following chart discussed by JL during the last meeting pretty > > well summarize the issues > > > > > > > > > based on the discussion one has had during the > > meeting (and even if it > > not appropriate to consider specific implementation) > > one could draw some > > line that for "discovering" the exact state (load, > > congestion) and > > detailed capabilities a protocol preserving several > > requirements such as > > adapted to exchange of such detailed information, > > minimize overhead > > (conservative), confidentiality, etc. > > > > thanks, > > - dimitri. > > > > > > > > JP Vasseur wrote: > > > > > Hi Jean-Louis, > > > > > > On Aug 31, 2005, at 3:13 AM, LE ROUX Jean-Louis > > RD-CORE-LAN wrote: > > > > > >> Hi Jean-Philippe, > > >> > > >> we plan to post a new revision by mid-september. > > >> Is that OK? > > >> > > > > > > Perfect, thanks. Provided that the remaining > > issues are sorted out, we > > > could go for WG LC on this ID. > > > > > > JP. > > > > > >> Regards, > > >> > > >> JL > > >> > > >> > > >>> -----Message d'origine----- > > >>> De : JP Vasseur [mailto:jvasseur@cisco.com] > > >>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul Mabey; > > Eiji Oki; > > >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang > > >>> Cc : pce@ietf.org > > >>> Objet : Progress on > > draft-ietf-pce-discovery-reqs-01.txt > > >>> > > >>> Hi, > > >>> > > >>> First of all, thanks for the very significant > > progress which > > >>> has been made on this ID over the past 6 months. > > As discussed > > >>> during the last meeting in Paris, there are > > still a few > > >>> issues to be sorted out. > > >>> Could we try to close on these remaining issues > > so as to > > >>> quickly start the protocol work (we're a bit > > late on this Milestone) ? > > >>> > > >>> 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 > > > > > > > ___________________________________________________________ > To help you stay safe and secure online, we've developed the > all new Yahoo! Security Centre. http://uk.security.yahoo.com > > _______________________________________________ > 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 Mon Sep 05 08:43:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGJc-0007xf-GA; Mon, 05 Sep 2005 08:43:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECGJU-0007wp-Kw for pce@megatron.ietf.org; Mon, 05 Sep 2005 08:43:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14592 for ; Mon, 5 Sep 2005 08:43:03 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECGMF-0005n5-MV for pce@ietf.org; Mon, 05 Sep 2005 08:45:56 -0400 Received: from du-069-0031.access.clara.net ([217.158.132.31] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1ECGJG-000Mjh-8J; Mon, 05 Sep 2005 13:43:02 +0100 Message-ID: <013e01c5b217$b5991e70$93849ed9@Puppy> From: "Adrian Farrel" To: "Stephen Morris" References: <20050904213041.20132.qmail@web30509.mail.mud.yahoo.com> Subject: Re: [Pce] Re: Management Issues Date: Mon, 5 Sep 2005 13:42:58 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.6 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Cc: pce@ietf.org 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: , Content-Type: multipart/mixed; boundary="===============1267873220==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1267873220== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C5B21F.BA0EA760" This is a multi-part message in MIME format. ------=_NextPart_000_0132_01C5B21F.BA0EA760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, We're just revising the Architecture I-D, so this is a timely = discussion. > > I have a few comments/suggestions about the > > architecture document sections 8.1, 8.3, & 10: > >=20 > > (1) Section 8.1 > > I suggest we allow path computations to be initiated > > using SNMP (e.g., set a variable). This potentially > > opens up PCE technology to existing NMS/OSS > > products. > > Just a new (PCE) MIB module and some backend code is > > needed to integrate PCE technology in this case. This is potentially feasible. I guess you are suggesting that it is = easier for an existing NMS to utilize the SNMP code that it already = includes than it is for it to support a new protocol. I'm slightly concerned that the PCC-PCE request would normally be = considered as transaction-based with no residue on the PCE. That is, the = PCC sends a request which creates temporary state on the PCE. When the = PCE sends its response, the state is deleted from the PCE. I'm not clear = how this would work with SNMP because the NMS would need to create the = state (all of the constraints related to the computation request) = through a series of SETs. Once the state has been created, the = computation can be easily triggered as you say, and there are a variety = of ways to extract the solution as you suggest below (although I think = Polling probably does not scale, and Notifications are not reliable). = But how would we remove the state from the PCE? I'd also point out that the amount of MIB objects we would be looking at = for the set of constraints already under discussion is non-trivial, but = this might not be such a problem since many of them have been = demonstrated to be encodable in the MPLS TE MIB. Are there any MIB modules you can point us at that do a similar thing in = another context? > > Path computation completion might be indicated by an > > informational notification or an SNMP response. > > Another approach might be the use of polling to > > allow a PCC to query PCE completion of a path request. > > (2) Section 8.3 > > Correctness - maybe provide ping access through > > SNMP? I presume you are refering to the 'correctness' of PCC-PCE connectivity, = not to the correctness of the computed path. I'm not sure why you think = providing access to 'ping' through SNMP would help for this issue. Since = the PCC has connected to something that it believes is the correct PCE = using an IP-based protocol we may assume that it has correctly attached = to the IP address that it thinks it should have attached to. Using ping = will confirm this, but will not confirm that we are attached to the = correct PCE. That requires application level authentication. > > (3) Section 10 > > IANA might be needed for the MIB module? You're absolutely correct. Any MIB module that is written will = definitely require IANA to assign a place in the MIB tree. Similarly, = any protocols written for discovery or for PCC-PCE communicaitons will = need IANA to manage thier codespaces. This section, however, describes specific IANA actions requested by this = document, and there are none. > > (4) A further manageability item is deployment or > > software distribution. Let's say I have LSR X from > > vendor Y and I want to upgrade LSR X to include PCE > > capability. Or let's say I want to upgrade a number > > of LSRs to support PCE. While this is mostly an=20 > > NMS/OSS issue (ftp, tftp etc.), the PCE element can > > help by supporting software version data (i.e.,=20 > > deployment data). We need to distinguish standards and implementation issues. The version = of a protocol supported is a standards issue. The version of a software = package supported is an implementation issue. The former is the subject = of information that should be carried in the protocol and might be made = available in a standard MIB module. The latter is proprietary and cannot = be standardised, but might be included in a proprietary MIB module or = extension. But you have raised an interesting point here. PCE should support = graceful shut-down so that it can be upgraded. Such shut-down might = involve: - advertising a new status of 'unusable' - closing the input queues to new requests - flushing queued requests by=20 - rejecting them - passing them on to another PCE (which would have to respond to the PCC direct) - servicing them and responding I will add something about this to the Architecture document. Cheers, Adrian ------=_NextPart_000_0132_01C5B21F.BA0EA760 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Stephen,
 
We're just revising the Architecture = I-D, so this=20 is a timely discussion.
 
> > I have a few = comments/suggestions about=20 the
> > architecture document sections 8.1, 8.3, & = 10:
> >=20
> > (1) Section 8.1
> > I suggest we allow path = computations=20 to be initiated
> > using SNMP (e.g., set a variable). This=20 potentially
> > opens up PCE technology to existing = NMS/OSS
>=20 > products.
> > Just a new (PCE) MIB module and some backend = code=20 is
> > needed to integrate PCE technology in this = case.
 
This is potentially feasible. I guess = you are=20 suggesting that it is easier for an existing NMS to utilize the SNMP = code that=20 it already includes than it is for it to support a new = protocol.
 
I'm slightly concerned that the = PCC-PCE request=20 would normally be considered as transaction-based with no residue on the = PCE.=20 That is, the PCC sends a request which creates temporary state on the = PCE. When=20 the PCE sends its response, the state is deleted from the PCE. I'm not = clear how=20 this would work with SNMP because the NMS would need to create the state = (all of=20 the constraints related to the computation request) through a series of = SETs.=20 Once the state has been created, the computation can be easily triggered = as you=20 say, and there are a variety of ways to extract the solution as you = suggest=20 below (although I think Polling probably does not scale, and = Notifications are=20 not reliable). But how would we remove the state from the = PCE?
 
I'd also point out that the amount of = MIB objects=20 we would be looking at for the set of constraints already under = discussion is=20 non-trivial, but this might not be such a problem since many of them = have been=20 demonstrated to be encodable in the MPLS TE MIB.
 
Are there any MIB modules you can = point us at=20 that do a similar thing in another context?
 
> > Path computation completion might be indicated by = an
> >=20 informational notification or an SNMP response.
> > Another = approach=20 might be the use of polling to
> > allow a PCC to query PCE = completion=20 of a path request.
 
 
> > (2) Section 8.3
> = >=20 Correctness - maybe provide ping access through
> > = SNMP?
 
I presume you are refering to the = 'correctness'=20 of PCC-PCE connectivity, not to the correctness of the computed path. = I'm not=20 sure why you think providing access to 'ping' through SNMP would help = for this=20 issue. Since the PCC has connected to something that it believes is the = correct=20 PCE using an IP-based protocol we may assume that it has correctly = attached to=20 the IP address that it thinks it should have attached to. Using ping = will=20 confirm this, but will not confirm that we are attached to the correct = PCE. That=20 requires application level authentication.
 
> > (3) Section 10
> > = IANA might=20 be needed for the MIB module?
 
You're absolutely correct. Any MIB = module that is=20 written will definitely require IANA to assign a place in the MIB tree.=20 Similarly, any protocols written for discovery or for PCC-PCE = communicaitons=20 will need IANA to manage thier codespaces.
 
This section, however, describes = specific IANA=20 actions requested by this document, and there are none.
 
> > (4) A further manageability = item is=20 deployment or
> > software distribution. Let's say I have LSR X = from
> > vendor Y and I want to upgrade LSR X to include = PCE
>=20 > capability. Or let's say I want to upgrade a number
> > of = LSRs to=20 support PCE. While this is mostly an
> > NMS/OSS issue (ftp, tftp = etc.), the PCE=20 element can
> > help by supporting = software=20 version data (i.e.,
> > deployment = data).
We need to distinguish standards and=20 implementation issues. The version of a protocol supported is a = standards issue.=20 The version of a software package supported is an implementation issue. = The=20 former is the subject of information that should be carried in the = protocol and=20 might be made available in a standard MIB module. The latter is = proprietary and=20 cannot be standardised, but might be included in a proprietary MIB = module or=20 extension.
 
But you have raised an interesting = point here.=20 PCE should support graceful shut-down so that it can be upgraded. Such = shut-down=20 might involve:
- advertising a new status of=20 'unusable'
- closing the input queues to new=20 requests
- flushing queued requests by =
  - rejecting them
  - passing them on to another = PCE=20 (which
    would have to = respond to the=20 PCC direct)
  - servicing them and=20 responding
 
I will add something about this to = the=20 Architecture document.
 
Cheers,
Adrian
 
------=_NextPart_000_0132_01C5B21F.BA0EA760-- --===============1267873220== 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 --===============1267873220==-- From pce-bounces@lists.ietf.org Tue Sep 06 17:48:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClJ7-0005va-7U; Tue, 06 Sep 2005 17:48:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClJ6-0005uL-2o for pce@megatron.ietf.org; Tue, 06 Sep 2005 17:48:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02476 for ; Tue, 6 Sep 2005 17:48:41 -0400 (EDT) Received: from web30504.mail.mud.yahoo.com ([68.142.200.117]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EClLw-0004Yh-60 for pce@ietf.org; Tue, 06 Sep 2005 17:51:53 -0400 Received: (qmail 55702 invoked by uid 60001); 6 Sep 2005 21:48:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CPIA5nvRi2cDBhIlTbLSmc569tofPbG/E27C/fYDUSXqLyhlWXxQa88lEvaV6s/UpNdlhcOLULmD5qEqrvQjODnz81J4FgtIVtqYjTTmHMxw2SEk1fsI9NWtwhiWiZja7UsIEzBMEmiDN309ZW5gtTn/jrLxaMw5dLtz/D3ws9E= ; Message-ID: <20050906214818.55700.qmail@web30504.mail.mud.yahoo.com> Received: from [213.94.132.54] by web30504.mail.mud.yahoo.com via HTTP; Tue, 06 Sep 2005 22:48:18 BST Date: Tue, 6 Sep 2005 22:48:18 +0100 (BST) From: Stephen Morris Subject: Re: [Pce] Re: Management Issues To: Adrian Farrel In-Reply-To: <013e01c5b217$b5991e70$93849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 8bit 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian & All Comments inline. Best wishes Stephen --- Adrian Farrel wrote: > Hi Stephen, > > We're just revising the Architecture I-D, so this is > a timely discussion. > > > > I have a few comments/suggestions about the > > > architecture document sections 8.1, 8.3, & 10: > > > > > > (1) Section 8.1 > > > I suggest we allow path computations to be > initiated > > > using SNMP (e.g., set a variable). This > potentially > > > opens up PCE technology to existing NMS/OSS > > > products. > > > Just a new (PCE) MIB module and some backend > code is > > > needed to integrate PCE technology in this case. > > This is potentially feasible. I guess you are > suggesting that it is easier for an existing NMS to > utilize the SNMP code that it already includes than > it is for it to support a new protocol. > > I'm slightly concerned that the PCC-PCE request > would normally be considered as transaction-based > with no residue on the PCE. That is, the PCC sends a > request which creates temporary state on the PCE. > When the PCE sends its response, the state is > deleted from the PCE. I'm not clear how this would > work with SNMP because the NMS would need to create > the state (all of the constraints related to the > computation request) through a series of SETs. Once > the state has been created, the computation can be > easily triggered as you say, and there are a variety > of ways to extract the solution as you suggest below > (although I think Polling probably does not scale, > and Notifications are not reliable). But how would > we remove the state from the PCE? My point was just in relation to gaining access to PCE functions, i.e., initiating a path compute from an NMS (or PCC). By allowing SNMP access, we open up the PCE work to a huge number of existing NMS/OSS applications - with minimal operational impact. So, an NMS selects a PCE, specifies the required constraints and these can then be communicated to the PCE either via SNMP or via the PCC-PCE protocol. The path computation occurs and is communicated back to the client either via SNMP or via the PCC-PCE protocol. You're right in your point about polling/notifications, but if a response was lost, then the computation can always be re-executed and modern networks are pretty reliable :-). > > I'd also point out that the amount of MIB objects we > would be looking at for the set of constraints > already under discussion is non-trivial, but this > might not be such a problem since many of them have > been demonstrated to be encodable in the MPLS TE > MIB. > > Are there any MIB modules you can point us at that > do a similar thing in another context? None I can think of! Similar functionality has tended to not be implemented in SNMP, resulting in skewed NMS applications :-). > > > > Path computation completion might be indicated > by an > > > informational notification or an SNMP response. > > > Another approach might be the use of polling to > > > allow a PCC to query PCE completion of a path > request. > > > > > (2) Section 8.3 > > > Correctness - maybe provide ping access through > > > SNMP? > > I presume you are refering to the 'correctness' of > PCC-PCE connectivity, not to the correctness of the > computed path. I'm not sure why you think providing > access to 'ping' through SNMP would help for this > issue. Since the PCC has connected to something that > it believes is the correct PCE using an IP-based > protocol we may assume that it has correctly > attached to the IP address that it thinks it should > have attached to. Using ping will confirm this, but > will not confirm that we are attached to the correct > PCE. That requires application level authentication. > Good points, though I was referring to the correctness of the PCE path computation itself. Is this worth thinking about? I'm kind of harking back to RFC2547, which had no correctness or verification features, i.e., you'd set up a VPN but there was no standard way to check the configuration. > > > (3) Section 10 > > > IANA might be needed for the MIB module? > > You're absolutely correct. Any MIB module that is > written will definitely require IANA to assign a > place in the MIB tree. Similarly, any protocols > written for discovery or for PCC-PCE communicaitons > will need IANA to manage thier codespaces. > > This section, however, describes specific IANA > actions requested by this document, and there are > none. > > > > (4) A further manageability item is deployment > or > > > software distribution. Let's say I have LSR X > from > > > vendor Y and I want to upgrade LSR X to include > PCE > > > capability. Or let's say I want to upgrade a > number > > > of LSRs to support PCE. While this is mostly an > > > NMS/OSS issue (ftp, tftp etc.), the PCE element > can > > > help by supporting software version data (i.e., > > > deployment data). > > We need to distinguish standards and implementation > issues. The version of a protocol supported is a > standards issue. The version of a software package > supported is an implementation issue. The former is > the subject of information that should be carried in > the protocol and might be made available in a > standard MIB module. The latter is proprietary and > cannot be standardised, but might be included in a > proprietary MIB module or extension. > > But you have raised an interesting point here. PCE > should support graceful shut-down so that it can be > upgraded. Such shut-down might involve: > - advertising a new status of 'unusable' > - closing the input queues to new requests > - flushing queued requests by > - rejecting them > - passing them on to another PCE (which > would have to respond to the PCC direct) > - servicing them and responding > > I will add something about this to the Architecture > document. > > Cheers, > Adrian > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 06 17:57:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClRp-0007SR-6D; Tue, 06 Sep 2005 17:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EClRo-0007SM-7d for pce@megatron.ietf.org; Tue, 06 Sep 2005 17:57:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02835 for ; Tue, 6 Sep 2005 17:57:41 -0400 (EDT) Received: from web30508.mail.mud.yahoo.com ([68.142.200.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EClUr-0004o3-5t for pce@ietf.org; Tue, 06 Sep 2005 18:00:53 -0400 Received: (qmail 61121 invoked by uid 60001); 6 Sep 2005 21:57:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lCKtQkcI5mVtAYUA3Id18+AR5Ub9gV0gJib4uPkSJ5qCc9K7m68TeWTHFgRG1+Iv32URLbY4zzPUmhPwlaS7gdZte4ivZ/ShKD+QKl3ATtC5YOZcS5LfYCCt/Drs7yUKZAgNpTb82h76RK03UZCOWksJL6ns4oW0DdtsWMMQTS8= ; Message-ID: <20050906215732.61119.qmail@web30508.mail.mud.yahoo.com> Received: from [213.94.132.54] by web30508.mail.mud.yahoo.com via HTTP; Tue, 06 Sep 2005 22:57:32 BST Date: Tue, 6 Sep 2005 22:57:32 +0100 (BST) From: Stephen Morris Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt To: Adrian Farrel , LE ROUX Jean-Louis RD-CORE-LAN In-Reply-To: <013d01c5b217$b0b103f0$93849ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.5 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA02835 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Adrian, Jean-Louis, All A network manager would probably want NMS data on all of the PCEs in the network. It's a useful mechanism in discovery to let the managed entities (PCEs in this case) notify the NMS about changes (such as capability). This is particularly so in cases where there are many such entities. So, I think we have 2 related points here: (1) External entities (e.g., NMS) should be able to listen in on PCE changes, including detecting new PCEs as they appear. This reduces polling. (2) PCEs should be able to assist the NMS in discovering them and their capabilities I'm basically trying to reduce the amount of discovery-related traffic. The latter often gives network management a bad name :-). Best wishes Stephen --- Adrian Farrel wrote: > Hi, >=20 > Jean-Louis is right; the requirement is focused on > allowing PCEs to convey > information to PCCs. >=20 > Another entity would be able to "listen in" and > gather information for its > own use, but such a requirement is out of scope for > this document. >=20 > I guess it depends on the purpose of the function > you are suggesting. For > example, if you want the NMS to be able to track the > status of the PCE, > this would probably be a perfectly adequate > technique. However, it does > rely on the NMS being able to listen in. That is: > suppose the solution to > PCE discovery is an opaque LSA in OSPF; you would > need the NMS to be able > to participate (at least passively) in the OSPF > exchanges. Since the NMS > may be remote through a distinct management plane > network, this might not > be possible. >=20 > The alternative solution to gathering status > information at the NMS would > appear to be unchanged from the way network devices > report status > information today. From an IETF standardisation > point of view, this > requires MIB modules to allow the NMS to read > information and to let the > PCE report asynchronous Notifications. Obviously, > piles of other > proprietary or standard mechanisms exist outside the > IETF. >=20 > Cheers, > Adrian >=20 > ----- Original Message -----=20 > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > To: "Stephen Morris" ; > ; > ; "JP Vasseur" > > Cc: "Ting_Wo Chung" ; > ; "Richard > Rabbat" ; > "raymond.zhang" > ; "Paul Mabey" > > Sent: Monday, September 05, 2005 6:49 AM > Subject: RE: [Pce] Re: Progress on > draft-ietf-pce-discovery-reqs-01.txt >=20 >=20 > Hi Stephen, >=20 > If the "interested entity" is a PCC then the answer > is YES. >=20 >=20 > Regards >=20 > JL >=20 > > -----Message d'origine----- > > De : pce-bounces@lists.ietf.org > > [mailto:pce-bounces@lists.ietf.org] De la part de > Stephen Morris > > Envoy=E9 : dimanche 4 septembre 2005 23:27 > > =C0 : dpapadimitriou@psg.com; > dimitri.papadimitriou@alcatel.be; > > JP Vasseur > > Cc : Ting_Wo Chung; pce@ietf.org; Richard Rabbat; > > raymond.zhang; Paul Mabey > > Objet : Re: [Pce] Re: Progress on > draft-ietf-pce-discovery-reqs-01.txt > > > > Hi JP, All > > In section 6.3. "PCE Information Synchronization", > does this > > requirement allow for a PCE to notify an > interested entity > > (e.g., a network management system) of a > capability (or some > > other) change? > > Best wishes > > Stephen > > > > --- dimitri papadimitriou > > wrote: > > > > > hi jp, all > > > > > > the following chart discussed by JL during the > last meeting pretty > > > well summarize the issues > > > > > > > > > > > > > > > based on the discussion one has had during the > > > meeting (and even if it > > > not appropriate to consider specific > implementation) > > > one could draw some > > > line that for "discovering" the exact state > (load, > > > congestion) and > > > detailed capabilities a protocol preserving > several > > > requirements such as > > > adapted to exchange of such detailed > information, > > > minimize overhead > > > (conservative), confidentiality, etc. > > > > > > thanks, > > > - dimitri. > > > > > > > > > > > > JP Vasseur wrote: > > > > > > > Hi Jean-Louis, > > > > > > > > On Aug 31, 2005, at 3:13 AM, LE ROUX > Jean-Louis > > > RD-CORE-LAN wrote: > > > > > > > >> Hi Jean-Philippe, > > > >> > > > >> we plan to post a new revision by > mid-september. > > > >> Is that OK? > > > >> > > > > > > > > Perfect, thanks. Provided that the remaining > > > issues are sorted out, we > > > > could go for WG LC on this ID. > > > > > > > > JP. > > > > > > > >> Regards, > > > >> > > > >> JL > > > >> > > > >> > > > >>> -----Message d'origine----- > > > >>> De : JP Vasseur [mailto:jvasseur@cisco.com] > > > >>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 > > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul > Mabey; > > > Eiji Oki; > > > >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang > > > >>> Cc : pce@ietf.org > > > >>> Objet : Progress on > > > draft-ietf-pce-discovery-reqs-01.txt > > > >>> > > > >>> Hi, > > > >>> > > > >>> First of all, thanks for the very > significant > > > progress which > > > >>> has been made on this ID over the past 6 > months. > > > As discussed > > > >>> during the last meeting in Paris, there are > > > still a few > > > >>> issues to be sorted out. > > > >>> Could we try to close on these remaining > issues > > > so as to > > > >>> quickly start the protocol work (we're a bit > > > late on this Milestone) ? > > > >>> > > > >>> Thanks. > > > >>> > > > >>> JP. > > > >>> > > > >> > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > . > > > > > > > > > > _______________________________________________ > > > Pce mailing list > > > Pce@lists.ietf.org >=20 =3D=3D=3D message truncated =3D=3D=3D =09 ___________________________________________________________=20 To help you stay safe and secure online, we've developed the all new Yaho= o! Security Centre. http://uk.security.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Sep 07 06:51:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECxWp-0007yj-8p; Wed, 07 Sep 2005 06:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECxWo-0007ye-Ez for pce@megatron.ietf.org; Wed, 07 Sep 2005 06:51:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09583 for ; Wed, 7 Sep 2005 06:51:39 -0400 (EDT) Received: from relay1.mail.uk.clara.net ([80.168.70.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECxZv-0000z6-QL for pce@ietf.org; Wed, 07 Sep 2005 06:54:58 -0400 Received: from du-069-0495.access.clara.net ([217.158.145.241] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1ECxWR-0004vl-JC; Wed, 07 Sep 2005 11:51:23 +0100 Message-ID: <036f01c5b39a$7912ae10$93849ed9@Puppy> From: "Adrian Farrel" To: "Stephen Morris" , "LE ROUX Jean-Louis RD-CORE-LAN" References: <20050906215732.61119.qmail@web30508.mail.mud.yahoo.com> Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Date: Wed, 7 Sep 2005 11:00:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA09583 Cc: pce@ietf.org 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, > A network manager would probably want NMS data on all > of the PCEs in the network. It's a useful mechanism in > discovery to let the managed entities (PCEs in this > case) notify the NMS about changes (such as > capability). This is particularly so in cases where > there are many such entities. Yes, but let's not get things out of proportion. There will always be at least as many network switches/routers as there are PCEs in any network (such is the nature of the architecture). How do switches/routers currently keep their capabilities (i.e. inventory= ) up-to-date with NMS? Why shouldn't PCEs use the same technique? > So, I think we have 2 related points here: > (1) External entities (e.g., NMS) should be able to > listen in on PCE changes, including detecting new PCEs > as they appear. This reduces polling. Agreed. If the NMS is capable of listening, there is nothing in any of th= e suggestions that prohibits it. However, we should not, I think, make it compulsory for an NMS to listen to the PCE discovery protocols since this may be operationally impossible in some configurations. > (2) PCEs should be able to assist the NMS in > discovering them and their capabilities Certainly if we allow capabilities exchange as part of the PCC-PCE protocol, this would be possible. The NMS would simply behave as a PCC (which it will probably want to do anyway for computational purposes). > I'm basically trying to reduce the amount of > discovery-related traffic. The latter often gives > network management a bad name :-). > > Best wishes > Stephen > > --- Adrian Farrel wrote: > > > Hi, > > > > Jean-Louis is right; the requirement is focused on > > allowing PCEs to convey > > information to PCCs. > > > > Another entity would be able to "listen in" and > > gather information for its > > own use, but such a requirement is out of scope for > > this document. > > > > I guess it depends on the purpose of the function > > you are suggesting. For > > example, if you want the NMS to be able to track the > > status of the PCE, > > this would probably be a perfectly adequate > > technique. However, it does > > rely on the NMS being able to listen in. That is: > > suppose the solution to > > PCE discovery is an opaque LSA in OSPF; you would > > need the NMS to be able > > to participate (at least passively) in the OSPF > > exchanges. Since the NMS > > may be remote through a distinct management plane > > network, this might not > > be possible. > > > > The alternative solution to gathering status > > information at the NMS would > > appear to be unchanged from the way network devices > > report status > > information today. From an IETF standardisation > > point of view, this > > requires MIB modules to allow the NMS to read > > information and to let the > > PCE report asynchronous Notifications. Obviously, > > piles of other > > proprietary or standard mechanisms exist outside the > > IETF. > > > > Cheers, > > Adrian > > > > ----- Original Message -----=20 > > From: "LE ROUX Jean-Louis RD-CORE-LAN" > > > > To: "Stephen Morris" ; > > ; > > ; "JP Vasseur" > > > > Cc: "Ting_Wo Chung" ; > > ; "Richard > > Rabbat" ; > > "raymond.zhang" > > ; "Paul Mabey" > > > > Sent: Monday, September 05, 2005 6:49 AM > > Subject: RE: [Pce] Re: Progress on > > draft-ietf-pce-discovery-reqs-01.txt > > > > > > Hi Stephen, > > > > If the "interested entity" is a PCC then the answer > > is YES. > > > > > > Regards > > > > JL > > > > > -----Message d'origine----- > > > De : pce-bounces@lists.ietf.org > > > [mailto:pce-bounces@lists.ietf.org] De la part de > > Stephen Morris > > > Envoy=E9 : dimanche 4 septembre 2005 23:27 > > > =C0 : dpapadimitriou@psg.com; > > dimitri.papadimitriou@alcatel.be; > > > JP Vasseur > > > Cc : Ting_Wo Chung; pce@ietf.org; Richard Rabbat; > > > raymond.zhang; Paul Mabey > > > Objet : Re: [Pce] Re: Progress on > > draft-ietf-pce-discovery-reqs-01.txt > > > > > > Hi JP, All > > > In section 6.3. "PCE Information Synchronization", > > does this > > > requirement allow for a PCE to notify an > > interested entity > > > (e.g., a network management system) of a > > capability (or some > > > other) change? > > > Best wishes > > > Stephen > > > > > > --- dimitri papadimitriou > > > wrote: > > > > > > > hi jp, all > > > > > > > > the following chart discussed by JL during the > > last meeting pretty > > > > well summarize the issues > > > > > > > > > > > > > > > > > > > > > > based on the discussion one has had during the > > > > meeting (and even if it > > > > not appropriate to consider specific > > implementation) > > > > one could draw some > > > > line that for "discovering" the exact state > > (load, > > > > congestion) and > > > > detailed capabilities a protocol preserving > > several > > > > requirements such as > > > > adapted to exchange of such detailed > > information, > > > > minimize overhead > > > > (conservative), confidentiality, etc. > > > > > > > > thanks, > > > > - dimitri. > > > > > > > > > > > > > > > > JP Vasseur wrote: > > > > > > > > > Hi Jean-Louis, > > > > > > > > > > On Aug 31, 2005, at 3:13 AM, LE ROUX > > Jean-Louis > > > > RD-CORE-LAN wrote: > > > > > > > > > >> Hi Jean-Philippe, > > > > >> > > > > >> we plan to post a new revision by > > mid-september. > > > > >> Is that OK? > > > > >> > > > > > > > > > > Perfect, thanks. Provided that the remaining > > > > issues are sorted out, we > > > > > could go for WG LC on this ID. > > > > > > > > > > JP. > > > > > > > > > >> Regards, > > > > >> > > > > >> JL > > > > >> > > > > >> > > > > >>> -----Message d'origine----- > > > > >>> De : JP Vasseur [mailto:jvasseur@cisco.com] > > > > >>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 > > > > >>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul > > Mabey; > > > > Eiji Oki; > > > > >>> Richard Rabbat; Ting_Wo Chung; raymond.zhang > > > > >>> Cc : pce@ietf.org > > > > >>> Objet : Progress on > > > > draft-ietf-pce-discovery-reqs-01.txt > > > > >>> > > > > >>> Hi, > > > > >>> > > > > >>> First of all, thanks for the very > > significant > > > > progress which > > > > >>> has been made on this ID over the past 6 > > months. > > > > As discussed > > > > >>> during the last meeting in Paris, there are > > > > still a few > > > > >>> issues to be sorted out. > > > > >>> Could we try to close on these remaining > > issues > > > > so as to > > > > >>> quickly start the protocol work (we're a bit > > > > late on this Milestone) ? > > > > >>> > > > > >>> Thanks. > > > > >>> > > > > >>> JP. > > > > >>> > > > > >> > > > > > > > > > > > > _______________________________________________ > > > > > Pce mailing list > > > > > Pce@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/pce > > > > > > > > > > . > > > > > > > > > > > > > _______________________________________________ > > > > Pce mailing list > > > > Pce@lists.ietf.org > > > =3D=3D=3D message truncated =3D=3D=3D > > > > > ___________________________________________________________ > To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Sep 07 07:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyAU-0007xy-DB; Wed, 07 Sep 2005 07:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECyAS-0007xo-EH for pce@megatron.ietf.org; Wed, 07 Sep 2005 07:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12643 for ; Wed, 7 Sep 2005 07:32:39 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECyDc-00029J-Jc for pce@ietf.org; Wed, 07 Sep 2005 07:35:57 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Sep 2005 07:32:32 -0400 X-IronPort-AV: i="3.96,175,1122868800"; d="scan'208"; a="69275300:sNHT35712520" 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 j87BWGTE011684; Wed, 7 Sep 2005 07:32:28 -0400 (EDT) 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.211); Wed, 7 Sep 2005 07:32:19 -0400 Received: from [192.168.1.100] ([10.86.240.125]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Sep 2005 07:32:18 -0400 In-Reply-To: <036f01c5b39a$7912ae10$93849ed9@Puppy> References: <20050906215732.61119.qmail@web30508.mail.mud.yahoo.com> <036f01c5b39a$7912ae10$93849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <4DE2CB37-CEC3-4889-ABFC-2DD431C0FFA4@cisco.com> Content-Transfer-Encoding: quoted-printable From: JP Vasseur Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Date: Wed, 7 Sep 2005 07:32:47 -0400 To: Adrian Farrel , stephenbjm@yahoo.com X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 07 Sep 2005 11:32:18.0789 (UTC) FILETIME=[CE0A7150:01C5B39F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Content-Transfer-Encoding: quoted-printable 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Adding a few comments. On Sep 7, 2005, at 6:00 AM, Adrian Farrel wrote: > Hi, > > >> A network manager would probably want NMS data on all >> of the PCEs in the network. It's a useful mechanism in >> discovery to let the managed entities (PCEs in this >> case) notify the NMS about changes (such as >> capability). As pointed out in other emails related to this thread, there is =20 nothing preventing the NMS to listen the PCE discovery protocol. That said, (1) NMS will undoubtedly require more data that what will/should be =20 provided by PCE discovery (since PCCs will not need as much data as NMS) (2) Some NMS may not support the PCE discovery protocol. We're seeking for volunteers to work on future MIBs ... Could we =20 count you in ? >> This is particularly so in cases where >> there are many such entities. >> > > Yes, but let's not get things out of proportion. There will always =20 > be at > least as many network switches/routers as there are PCEs in any =20 > network > (such is the nature of the architecture). > > How do switches/routers currently keep their capabilities (i.e. =20 > inventory) > up-to-date with NMS? Why shouldn't PCEs use the same technique? > > >> So, I think we have 2 related points here: >> (1) External entities (e.g., NMS) should be able to >> listen in on PCE changes, including detecting new PCEs >> as they appear. This reduces polling. >> > > Agreed. If the NMS is capable of listening, there is nothing in any =20= > of the > suggestions that prohibits it. However, we should not, I think, =20 > make it > compulsory for an NMS to listen to the PCE discovery protocols =20 > since this > may be operationally impossible in some configurations. > See my comment (2) above. > >> (2) PCEs should be able to assist the NMS in >> discovering them and their capabilities >> > > Certainly if we allow capabilities exchange as part of the PCC-PCE > protocol, this would be possible. The NMS would simply behave as a PCC > (which it will probably want to do anyway for computational purposes). > I'm not really convinced here ... If the NMS does not require path =20 computation (which is likely to be the case in various =20 circumstances), having the NMS acting as a PCC (even if the PCE =20 communication protocol support detailed capability discovery), I'd =20 prefer the NMS to rely on MIBs. Thanks. JP. > >> I'm basically trying to reduce the amount of >> discovery-related traffic. The latter often gives >> network management a bad name :-). >> >> Best wishes >> Stephen >> >> --- Adrian Farrel wrote: >> >> >>> Hi, >>> >>> Jean-Louis is right; the requirement is focused on >>> allowing PCEs to convey >>> information to PCCs. >>> >>> Another entity would be able to "listen in" and >>> gather information for its >>> own use, but such a requirement is out of scope for >>> this document. >>> >>> I guess it depends on the purpose of the function >>> you are suggesting. For >>> example, if you want the NMS to be able to track the >>> status of the PCE, >>> this would probably be a perfectly adequate >>> technique. However, it does >>> rely on the NMS being able to listen in. That is: >>> suppose the solution to >>> PCE discovery is an opaque LSA in OSPF; you would >>> need the NMS to be able >>> to participate (at least passively) in the OSPF >>> exchanges. Since the NMS >>> may be remote through a distinct management plane >>> network, this might not >>> be possible. >>> >>> The alternative solution to gathering status >>> information at the NMS would >>> appear to be unchanged from the way network devices >>> report status >>> information today. =46rom an IETF standardisation >>> point of view, this >>> requires MIB modules to allow the NMS to read >>> information and to let the >>> PCE report asynchronous Notifications. Obviously, >>> piles of other >>> proprietary or standard mechanisms exist outside the >>> IETF. >>> >>> Cheers, >>> Adrian >>> >>> ----- Original Message ----- >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>> >>> To: "Stephen Morris" ; >>> ; >>> ; "JP Vasseur" >>> >>> Cc: "Ting_Wo Chung" ; >>> ; "Richard >>> Rabbat" ; >>> "raymond.zhang" >>> ; "Paul Mabey" >>> >>> Sent: Monday, September 05, 2005 6:49 AM >>> Subject: RE: [Pce] Re: Progress on >>> draft-ietf-pce-discovery-reqs-01.txt >>> >>> >>> Hi Stephen, >>> >>> If the "interested entity" is a PCC then the answer >>> is YES. >>> >>> >>> Regards >>> >>> JL >>> >>> >>>> -----Message d'origine----- >>>> De : pce-bounces@lists.ietf.org >>>> [mailto:pce-bounces@lists.ietf.org] De la part de >>>> >>> Stephen Morris >>> >>>> Envoy=E9 : dimanche 4 septembre 2005 23:27 >>>> =C0 : dpapadimitriou@psg.com; >>>> >>> dimitri.papadimitriou@alcatel.be; >>> >>>> JP Vasseur >>>> Cc : Ting_Wo Chung; pce@ietf.org; Richard Rabbat; >>>> raymond.zhang; Paul Mabey >>>> Objet : Re: [Pce] Re: Progress on >>>> >>> draft-ietf-pce-discovery-reqs-01.txt >>> >>>> >>>> Hi JP, All >>>> In section 6.3. "PCE Information Synchronization", >>>> >>> does this >>> >>>> requirement allow for a PCE to notify an >>>> >>> interested entity >>> >>>> (e.g., a network management system) of a >>>> >>> capability (or some >>> >>>> other) change? >>>> Best wishes >>>> Stephen >>>> >>>> --- dimitri papadimitriou >>>> wrote: >>>> >>>> >>>>> hi jp, all >>>>> >>>>> the following chart discussed by JL during the >>>>> >>> last meeting pretty >>> >>>>> well summarize the issues >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >>>>> >>>>> based on the discussion one has had during the >>>>> meeting (and even if it >>>>> not appropriate to consider specific >>>>> >>> implementation) >>> >>>>> one could draw some >>>>> line that for "discovering" the exact state >>>>> >>> (load, >>> >>>>> congestion) and >>>>> detailed capabilities a protocol preserving >>>>> >>> several >>> >>>>> requirements such as >>>>> adapted to exchange of such detailed >>>>> >>> information, >>> >>>>> minimize overhead >>>>> (conservative), confidentiality, etc. >>>>> >>>>> thanks, >>>>> - dimitri. >>>>> >>>>> >>>>> >>>>> JP Vasseur wrote: >>>>> >>>>> >>>>>> Hi Jean-Louis, >>>>>> >>>>>> On Aug 31, 2005, at 3:13 AM, LE ROUX >>>>>> >>> Jean-Louis >>> >>>>> RD-CORE-LAN wrote: >>>>> >>>>>> >>>>>> >>>>>>> Hi Jean-Philippe, >>>>>>> >>>>>>> we plan to post a new revision by >>>>>>> >>> mid-september. >>> >>>>>>> Is that OK? >>>>>>> >>>>>>> >>>>>> >>>>>> Perfect, thanks. Provided that the remaining >>>>>> >>>>> issues are sorted out, we >>>>> >>>>>> could go for WG LC on this ID. >>>>>> >>>>>> JP. >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> JL >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : JP Vasseur [mailto:jvasseur@cisco.com] >>>>>>>> Envoy=E9 : mardi 30 ao=FBt 2005 17:52 >>>>>>>> =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Paul >>>>>>>> >>> Mabey; >>> >>>>> Eiji Oki; >>>>> >>>>>>>> Richard Rabbat; Ting_Wo Chung; raymond.zhang >>>>>>>> Cc : pce@ietf.org >>>>>>>> Objet : Progress on >>>>>>>> >>>>> draft-ietf-pce-discovery-reqs-01.txt >>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> First of all, thanks for the very >>>>>>>> >>> significant >>> >>>>> progress which >>>>> >>>>>>>> has been made on this ID over the past 6 >>>>>>>> >>> months. >>> >>>>> As discussed >>>>> >>>>>>>> during the last meeting in Paris, there are >>>>>>>> >>>>> still a few >>>>> >>>>>>>> issues to be sorted out. >>>>>>>> Could we try to close on these remaining >>>>>>>> >>> issues >>> >>>>> so as to >>>>> >>>>>>>> quickly start the protocol work (we're a bit >>>>>>>> >>>>> late on this Milestone) ? >>>>> >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> JP. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>> _______________________________________________ >>> >>>>>> Pce mailing list >>>>>> Pce@lists.ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/pce >>>>>> >>>>>> . >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pce mailing list >>>>> Pce@lists.ietf.org >>>>> >>> >>> >> =3D=3D=3D message truncated =3D=3D=3D >> >> >> >> >> ___________________________________________________________ >> To help you stay safe and secure online, we've developed the all new >> > Yahoo! Security Centre. http://uk.security.yahoo.com > >> >> >> > > > _______________________________________________ > 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 Sep 08 17:11:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTg3-0008Aw-Bv; Thu, 08 Sep 2005 17:11:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTfz-0008AM-Mk for pce@megatron.ietf.org; Thu, 08 Sep 2005 17:11:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17600 for ; Thu, 8 Sep 2005 17:11:16 -0400 (EDT) Received: from web30508.mail.mud.yahoo.com ([68.142.200.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDTjH-0008CA-3I for pce@ietf.org; Thu, 08 Sep 2005 17:14:53 -0400 Received: (qmail 90812 invoked by uid 60001); 8 Sep 2005 21:10:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WktkSmAftUYzxTZ5LPCdQ9CfTAhXNc+TcSFrVLwXro3T2OgZOnj3TSGZSnolJbYd7rsEL0rhMGXdRCN5rkS8mMSR9xJ1Dcy59Wt9Ny7ikpiaKkVjyRhBp7P8dSm4J53Ptid4fW91+arQAnqupFTu5L6+AIIMksy1KlflIOObCtY= ; Message-ID: <20050908211059.90810.qmail@web30508.mail.mud.yahoo.com> Received: from [213.94.135.251] by web30508.mail.mud.yahoo.com via HTTP; Thu, 08 Sep 2005 22:10:58 BST Date: Thu, 8 Sep 2005 22:10:58 +0100 (BST) From: Stephen Morris Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt To: JP Vasseur , Adrian Farrel In-Reply-To: <4DE2CB37-CEC3-4889-ABFC-2DD431C0FFA4@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: 8bit 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi JP I'd be happy to help with the MIB work. Just one reply below :-). Best wishes Stephen --- JP Vasseur wrote: > Hi, > > Adding a few comments. > > On Sep 7, 2005, at 6:00 AM, Adrian Farrel wrote: > > > Hi, > > > > > >> A network manager would probably want NMS data on > all > >> of the PCEs in the network. It's a useful > mechanism in > >> discovery to let the managed entities (PCEs in > this > >> case) notify the NMS about changes (such as > >> capability). > > As pointed out in other emails related to this > thread, there is > nothing preventing the NMS to listen the PCE > discovery protocol. > > That said, > (1) NMS will undoubtedly require more data that what > will/should be > provided by PCE discovery (since PCCs will not need > as much data as NMS) > (2) Some NMS may not support the PCE discovery > protocol. > > We're seeking for volunteers to work on future MIBs > ... Could we > count you in ? > > >> This is particularly so in cases where > >> there are many such entities. > >> > > > > Yes, but let's not get things out of proportion. > There will always > > be at > > least as many network switches/routers as there > are PCEs in any > > network > > (such is the nature of the architecture). > > > > How do switches/routers currently keep their > capabilities (i.e. > > inventory) > > up-to-date with NMS? Why shouldn't PCEs use the > same technique? > > > > > >> So, I think we have 2 related points here: > >> (1) External entities (e.g., NMS) should be able > to > >> listen in on PCE changes, including detecting new > PCEs > >> as they appear. This reduces polling. > >> > > > > Agreed. If the NMS is capable of listening, there > is nothing in any > > of the > > suggestions that prohibits it. However, we should > not, I think, > > make it > > compulsory for an NMS to listen to the PCE > discovery protocols > > since this > > may be operationally impossible in some > configurations. Good point. Often, the NMS will have its own of discovery software that relies on a heady cocktail of MIBs, ping, etc. I guess my main point is that the PCE discovery requirements should try to make life a little easier on the NMS :-). > > > > See my comment (2) above. > > > > >> (2) PCEs should be able to assist the NMS in > >> discovering them and their capabilities > >> > > > > Certainly if we allow capabilities exchange as > part of the PCC-PCE > > protocol, this would be possible. The NMS would > simply behave as a PCC > > (which it will probably want to do anyway for > computational purposes). > > > > I'm not really convinced here ... If the NMS does > not require path > computation (which is likely to be the case in > various > circumstances), having the NMS acting as a PCC (even > if the PCE > communication protocol support detailed capability > discovery), I'd > prefer the NMS to rely on MIBs. > > Thanks. > > JP. > > > > >> I'm basically trying to reduce the amount of > >> discovery-related traffic. The latter often gives > >> network management a bad name :-). > >> > >> Best wishes > >> Stephen > >> > >> --- Adrian Farrel wrote: > >> > >> > >>> Hi, > >>> > >>> Jean-Louis is right; the requirement is focused > on > >>> allowing PCEs to convey > >>> information to PCCs. > >>> > >>> Another entity would be able to "listen in" and > >>> gather information for its > >>> own use, but such a requirement is out of scope > for > >>> this document. > >>> > >>> I guess it depends on the purpose of the > function > >>> you are suggesting. For > >>> example, if you want the NMS to be able to track > the > >>> status of the PCE, > >>> this would probably be a perfectly adequate > >>> technique. However, it does > >>> rely on the NMS being able to listen in. That > is: > >>> suppose the solution to > >>> PCE discovery is an opaque LSA in OSPF; you > would > >>> need the NMS to be able > >>> to participate (at least passively) in the OSPF > >>> exchanges. Since the NMS > >>> may be remote through a distinct management > plane > >>> network, this might not > >>> be possible. > >>> > >>> The alternative solution to gathering status > >>> information at the NMS would > >>> appear to be unchanged from the way network > devices > >>> report status > >>> information today. From an IETF standardisation > >>> point of view, this > >>> requires MIB modules to allow the NMS to read > >>> information and to let the > >>> PCE report asynchronous Notifications. > Obviously, > >>> piles of other > >>> proprietary or standard mechanisms exist outside > the > >>> IETF. > >>> > >>> Cheers, > >>> Adrian > >>> > >>> ----- Original Message ----- > >>> From: "LE ROUX Jean-Louis RD-CORE-LAN" > >>> > >>> To: "Stephen Morris" ; > >>> ; > >>> ; "JP Vasseur" > >>> > >>> Cc: "Ting_Wo Chung" ; > >>> ; "Richard > >>> Rabbat" ; > >>> "raymond.zhang" > >>> ; "Paul Mabey" > >>> > >>> Sent: Monday, September 05, 2005 6:49 AM > >>> Subject: RE: [Pce] Re: Progress on > >>> draft-ietf-pce-discovery-reqs-01.txt > >>> > >>> > >>> Hi Stephen, > >>> > >>> If the "interested entity" is a PCC then the > answer > >>> is YES. > >>> > >>> > >>> Regards > >>> > >>> JL > >>> > >>> > >>>> -----Message d'origine----- > >>>> De : pce-bounces@lists.ietf.org > >>>> [mailto:pce-bounces@lists.ietf.org] De la part > de > === message truncated === ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Sep 08 17:30:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTyo-0005OZ-Qq; Thu, 08 Sep 2005 17:30:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTyn-0005OM-Oe for pce@megatron.ietf.org; Thu, 08 Sep 2005 17:30:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19195 for ; Thu, 8 Sep 2005 17:30:42 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDU2F-0000XT-DF for pce@ietf.org; Thu, 08 Sep 2005 17:34:20 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 08 Sep 2005 14:30:37 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j88LUTum022427; Thu, 8 Sep 2005 14:30:33 -0700 (PDT) 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.211); Thu, 8 Sep 2005 17:30:11 -0400 Received: from [192.168.1.100] ([10.86.240.233]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Sep 2005 17:30:10 -0400 In-Reply-To: <20050908211059.90810.qmail@web30508.mail.mud.yahoo.com> References: <20050908211059.90810.qmail@web30508.mail.mud.yahoo.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9FCAD292-562F-472F-8FDB-0E884BD2B512@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Re: Progress on draft-ietf-pce-discovery-reqs-01.txt Date: Thu, 8 Sep 2005 17:30:38 -0400 To: Stephen Morris X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 08 Sep 2005 21:30:10.0434 (UTC) FILETIME=[7D9ED620:01C5B4BC] X-Spam-Score: 0.7 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Content-Transfer-Encoding: 7bit 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Stephen, On Sep 8, 2005, at 5:10 PM, Stephen Morris wrote: > Hi JP > I'd be happy to help with the MIB work. good, thanks. JP. > Just one reply > below :-). > Best wishes > Stephen > > --- JP Vasseur wrote: > > >> Hi, >> >> Adding a few comments. >> >> On Sep 7, 2005, at 6:00 AM, Adrian Farrel wrote: >> >> >>> Hi, >>> >>> >>> >>>> A network manager would probably want NMS data on >>>> >> all >> >>>> of the PCEs in the network. It's a useful >>>> >> mechanism in >> >>>> discovery to let the managed entities (PCEs in >>>> >> this >> >>>> case) notify the NMS about changes (such as >>>> capability). >>>> >> >> As pointed out in other emails related to this >> thread, there is >> nothing preventing the NMS to listen the PCE >> discovery protocol. >> >> That said, >> (1) NMS will undoubtedly require more data that what >> will/should be >> provided by PCE discovery (since PCCs will not need >> as much data as NMS) >> (2) Some NMS may not support the PCE discovery >> protocol. >> >> We're seeking for volunteers to work on future MIBs >> ... Could we >> count you in ? >> >> >>>> This is particularly so in cases where >>>> there are many such entities. >>>> >>>> >>> >>> Yes, but let's not get things out of proportion. >>> >> There will always >> >>> be at >>> least as many network switches/routers as there >>> >> are PCEs in any >> >>> network >>> (such is the nature of the architecture). >>> >>> How do switches/routers currently keep their >>> >> capabilities (i.e. >> >>> inventory) >>> up-to-date with NMS? Why shouldn't PCEs use the >>> >> same technique? >> >>> >>> >>> >>>> So, I think we have 2 related points here: >>>> (1) External entities (e.g., NMS) should be able >>>> >> to >> >>>> listen in on PCE changes, including detecting new >>>> >> PCEs >> >>>> as they appear. This reduces polling. >>>> >>>> >>> >>> Agreed. If the NMS is capable of listening, there >>> >> is nothing in any >> >>> of the >>> suggestions that prohibits it. However, we should >>> >> not, I think, >> >>> make it >>> compulsory for an NMS to listen to the PCE >>> >> discovery protocols >> >>> since this >>> may be operationally impossible in some >>> >> configurations. >> > > Good point. Often, the NMS will have its own of > discovery software that relies on a heady cocktail of > MIBs, ping, etc. I guess my main point is that the PCE > discovery requirements should try to make life a > little easier on the NMS :-). > > >>> >>> >> >> See my comment (2) above. >> >> >>> >>> >>>> (2) PCEs should be able to assist the NMS in >>>> discovering them and their capabilities >>>> >>>> >>> >>> Certainly if we allow capabilities exchange as >>> >> part of the PCC-PCE >> >>> protocol, this would be possible. The NMS would >>> >> simply behave as a PCC >> >>> (which it will probably want to do anyway for >>> >> computational purposes). >> >>> >>> >> >> I'm not really convinced here ... If the NMS does >> not require path >> computation (which is likely to be the case in >> various >> circumstances), having the NMS acting as a PCC (even >> if the PCE >> communication protocol support detailed capability >> discovery), I'd >> prefer the NMS to rely on MIBs. >> >> Thanks. >> >> JP. >> >> >>> >>> >>>> I'm basically trying to reduce the amount of >>>> discovery-related traffic. The latter often gives >>>> network management a bad name :-). >>>> >>>> Best wishes >>>> Stephen >>>> >>>> --- Adrian Farrel wrote: >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> Jean-Louis is right; the requirement is focused >>>>> >> on >> >>>>> allowing PCEs to convey >>>>> information to PCCs. >>>>> >>>>> Another entity would be able to "listen in" and >>>>> gather information for its >>>>> own use, but such a requirement is out of scope >>>>> >> for >> >>>>> this document. >>>>> >>>>> I guess it depends on the purpose of the >>>>> >> function >> >>>>> you are suggesting. For >>>>> example, if you want the NMS to be able to track >>>>> >> the >> >>>>> status of the PCE, >>>>> this would probably be a perfectly adequate >>>>> technique. However, it does >>>>> rely on the NMS being able to listen in. That >>>>> >> is: >> >>>>> suppose the solution to >>>>> PCE discovery is an opaque LSA in OSPF; you >>>>> >> would >> >>>>> need the NMS to be able >>>>> to participate (at least passively) in the OSPF >>>>> exchanges. Since the NMS >>>>> may be remote through a distinct management >>>>> >> plane >> >>>>> network, this might not >>>>> be possible. >>>>> >>>>> The alternative solution to gathering status >>>>> information at the NMS would >>>>> appear to be unchanged from the way network >>>>> >> devices >> >>>>> report status >>>>> information today. From an IETF standardisation >>>>> point of view, this >>>>> requires MIB modules to allow the NMS to read >>>>> information and to let the >>>>> PCE report asynchronous Notifications. >>>>> >> Obviously, >> >>>>> piles of other >>>>> proprietary or standard mechanisms exist outside >>>>> >> the >> >>>>> IETF. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> ----- Original Message ----- >>>>> From: "LE ROUX Jean-Louis RD-CORE-LAN" >>>>> >>>>> To: "Stephen Morris" ; >>>>> ; >>>>> ; "JP Vasseur" >>>>> >>>>> Cc: "Ting_Wo Chung" ; >>>>> ; "Richard >>>>> Rabbat" ; >>>>> "raymond.zhang" >>>>> ; "Paul Mabey" >>>>> >>>>> Sent: Monday, September 05, 2005 6:49 AM >>>>> Subject: RE: [Pce] Re: Progress on >>>>> draft-ietf-pce-discovery-reqs-01.txt >>>>> >>>>> >>>>> Hi Stephen, >>>>> >>>>> If the "interested entity" is a PCC then the >>>>> >> answer >> >>>>> is YES. >>>>> >>>>> >>>>> Regards >>>>> >>>>> JL >>>>> >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : pce-bounces@lists.ietf.org >>>>>> [mailto:pce-bounces@lists.ietf.org] De la part >>>>>> >> de >> >> > === message truncated === > > > > > ___________________________________________________________ > How much free photo storage do you get? Store your holiday > snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Sep 17 15:29:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGiNo-0003x1-2H; Sat, 17 Sep 2005 15:29:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGiNm-0003ww-DS for pce@megatron.ietf.org; Sat, 17 Sep 2005 15:29:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00995 for ; Sat, 17 Sep 2005 15:29:52 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGiT2-00074t-DU for pce@ietf.org; Sat, 17 Sep 2005 15:35:21 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Sep 2005 15:29:45 -0400 X-IronPort-AV: i="3.97,119,1125892800"; d="scan'208,217"; a="70675008:sNHT42404880" 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 j8HJTbT6018303; Sat, 17 Sep 2005 15:29:38 -0400 (EDT) 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.211); Sat, 17 Sep 2005 15:29:37 -0400 Received: from [192.168.1.100] ([10.86.242.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 17 Sep 2005 15:29:37 -0400 Mime-Version: 1.0 (Apple Message framework v734) To: pce@ietf.org Message-Id: <6C579D40-E89C-439C-9C03-124A5308997E@cisco.com> From: JP Vasseur Date: Sat, 17 Sep 2005 15:30:05 -0400 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 17 Sep 2005 19:29:37.0312 (UTC) FILETIME=[240FC200:01C5BBBE] X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Subject: [Pce] New revision of PCEP posted (revision 02) 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="===============2088452040==" Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org --===============2088452040== Content-Type: multipart/alternative; boundary=Apple-Mail-28-501833734 --Apple-Mail-28-501833734 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Dear WG, Several issues were discussed in Paris that have been fixed in this new revision 02 of PCEP: The list of issues were: 1) Non consensus on the less-constrained path computation aspects => Removed from the draft 2) Concerns related to the ENCAP object => Removed and new objects defined with a PCEP codepoint 3) Need for a PCEP keepalive mechanism => Added 4) Need for a section to discuss the compliance of PCEP to the generic PCE communication requirement ID => Added In addition, we also clarified several sections, fixed some typos, ambiguities, ... Thanks for all the comments received so far. As usual, comments are very welcome. JP. --Apple-Mail-28-501833734 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear WG,

Several issues were = discussed in Paris that have been fixed in this new revision 02 of = PCEP:

The = list of issues were:
1) Non consensus on the less-constrained path = computation aspects =3D> Removed from the = draft
2) Concerns related to the ENCAP object =3D>= Removed and new objects defined with a PCEP = codepoint
3) Need for a PCEP keepalive mechanism =3D> = Added
4) Need for a section to discuss the = compliance of PCEP to the generic PCE communication requirement ID =3D>= Added

In = addition, we also clarified several sections, fixed some typos, = ambiguities, ... Thanks for all the comments received so far.

As usual, comments are very welcome.

JP.
= --Apple-Mail-28-501833734-- --===============2088452040== 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 --===============2088452040==-- From pce-bounces@lists.ietf.org Tue Sep 20 11:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHjtq-0006g5-Te; Tue, 20 Sep 2005 11:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHjtp-0006fh-QW for pce@megatron.ietf.org; Tue, 20 Sep 2005 11:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08479 for ; Tue, 20 Sep 2005 11:19:11 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHjze-0008Al-IT for pce@ietf.org; Tue, 20 Sep 2005 11:25:16 -0400 Received: from du-069-0237.access.clara.net ([217.158.132.237] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EHjta-0005nI-9S; Tue, 20 Sep 2005 16:18:59 +0100 Message-ID: <0e6201c5bdf7$04cf3f70$28849ed9@Puppy> From: "Adrian Farrel" To: Date: Tue, 20 Sep 2005 13:39:43 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Selecting a PCC-PCE protocol 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, We need to move forward in our selection of the protocol on which the WG will work. There is an obvious candidate in draft-vasseur-pce-pcep-02.txt We have consulted the Applications Area and they suggested using XML over HTTP. I would like to have all of the hats in the ring before we make the decision so please speak up now if you have any other suggestions. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 20 17:01:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpFB-0004ce-Mj; Tue, 20 Sep 2005 17:01:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHpF7-0004bC-Gx for pce@megatron.ietf.org; Tue, 20 Sep 2005 17:01:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05473 for ; Tue, 20 Sep 2005 17:01:30 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHpKy-0003G7-85 for pce@ietf.org; Tue, 20 Sep 2005 17:07:39 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2005 14:01:21 -0700 X-IronPort-AV: i="3.97,127,1125903600"; d="scan'208"; a="660884433:sNHT28663264" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8KL1D4Z022071; Tue, 20 Sep 2005 14:01:19 -0700 (PDT) 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.211); Tue, 20 Sep 2005 17:01:11 -0400 Received: from [192.168.1.100] ([10.86.240.224]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 17:01:11 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Tue, 20 Sep 2005 17:01:36 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 20 Sep 2005 21:01:11.0116 (UTC) FILETIME=[6DDCF8C0:01C5BE26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Comments requested on section 6.1.15 draft-ietf-pce-comm-protocol-gen-reqs-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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, The DT is currently working hard to address the remaining issues related to draft-ietf-pce-comm-protocol-gen-reqs-01.txt with the objective to start a WG last call right after the publication of this next revision. There is in particular one section for which comments are very welcome: section 6.1.15 (Scalability). Some of you asked for "indicative boundary numbers". Considering the lack of deployments at that point, I personally think that providing numbers is a bit hazardous but we could I guess come up with rough estimates of what such numbers should be, based on our current set of expectations, while stressing the fact that PCE protocols should be designed for greater scalability. Thus such numbers should be interpreted as "minimum values" (to be spelled out in the document). At this point, the following metrics have been proposed: (1) number of PCCs (2) number of PCEs (3) number of PCCs communicating with a single PCE (4) number of PCEs communicated to by a single PCC (5) number of PCEs communicated to by another PCE (6) number of domains (7) number of path requests per unit of time (8) handling bursts of requests per unit of time I would suggest to remove (1), (2) and (6) as they are not related to the PCEP (thus out of the scope of this requirement document). Please let us know if you have any comment or disagreement with this approach (preferably by Sept 23th). Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 20 18:47:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqtg-0001xQ-SA; Tue, 20 Sep 2005 18:47:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHqtf-0001xL-Kf for pce@megatron.ietf.org; Tue, 20 Sep 2005 18:47:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12245 for ; Tue, 20 Sep 2005 18:47:28 -0400 (EDT) Received: from mail131.messagelabs.com ([216.82.242.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EHqzX-0005t7-47 for pce@ietf.org; Tue, 20 Sep 2005 18:53:38 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-131.messagelabs.com!1127256436!9263686!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 25999 invoked from network); 20 Sep 2005 22:47:16 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-4.tower-131.messagelabs.com with SMTP; 20 Sep 2005 22:47:16 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 431D9D370022F923; Tue, 20 Sep 2005 18:47:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Comments requested on section 6.1.15draft-ietf-pce-comm-protocol-gen-reqs-01.txt Date: Tue, 20 Sep 2005 17:47:15 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA937B@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Pce] Comments requested on section 6.1.15draft-ietf-pce-comm-protocol-gen-reqs-01.txt Thread-Index: AcW+JpgbuDZ9OJYZRDOUmitT9Krn1QACc82Q From: "Ash, Gerald R \(Jerry\), ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org JP, All, > The DT is currently working hard to address the remaining issues =20 > related to draft-ietf-pce-comm-protocol-gen-reqs-01.txt with the =20 > objective to start a WG last call right after the publication=20 > of this next revision. There is in particular one section for > which comments are very welcome: section 6.1.15 (Scalability). >=20 > Some of you asked for "indicative boundary numbers". >=20 > Considering the lack of deployments at that point, I personally > think that providing numbers is a bit hazardous but we could I guess > come up with rough estimates of what such numbers should be, based > on our current set of expectations, while stressing the fact that > PCE protocols should be designed for greater scalability. Thus such =20 > numbers should be interpreted as "minimum values" (to be spelled out =20 > in the document). >=20 > At this point, the following metrics have been proposed: >=20 > (1) number of PCCs > (2) number of PCEs > (3) number of PCCs communicating with a single PCE > (4) number of PCEs communicated to by a single PCC > (5) number of PCEs communicated to by another PCE > (6) number of domains > (7) number of path requests per unit of time > (8) handling bursts of requests per unit of time >=20 > I would suggest to remove (1), (2) and (6) as they are not related > to the PCEP (thus out of the scope of this requirement document). >=20 > Please let us know if you have any comment or disagreement with this =20 > approach (preferably by Sept 23th). Dimitri's original comment back in July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html suggested that 'boundary numbers' be specified for the items listed in Section 6.1.15 (Scalability). While I was skeptical (and still am) that these boundary numbers could/should be specified (see http://www1.ietf.org/mail-archive/web/pce/current/msg00273.html), it was agreed at IETF-63 to include 'order-of-magnitude' values in the updated draft. This has been done in the submitted update (to be announced), as follows: "6.1.15 Scalability The PCECP MUST scale well, at least as good as linearly, with an increase of any of the following parameters (note, minimum order of magnitude estimates of what the PCECP should support are given in parenthesis): - number of PCCs (1000/domain) - number of PCEs (100/domain) - number of PCCs communicating with a single PCE (1000) - number of PCEs communicated to by a single PCC (100) - number of PCEs communicated to by another PCE (100) - number of domains (20) - number of path request messages (average of 10/second/PCE) - handling bursts of requests (burst of 100/second/PCE within a 10- second interval)." IMO, all of these parameters relate directly or indirectly (as in the case of #1, #2, and #6) to PCECP scalability. My interpretation is that the PCECP MUST support domains having these boundary numbers or larger. Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 20 19:12:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrHh-00010u-0m; Tue, 20 Sep 2005 19:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHrHe-0000zr-QW for pce@megatron.ietf.org; Tue, 20 Sep 2005 19:12:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13659 for ; Tue, 20 Sep 2005 19:12:15 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHrNZ-0006X7-KU for pce@ietf.org; Tue, 20 Sep 2005 19:18:26 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Sep 2005 16:12:09 -0700 X-IronPort-AV: i="3.97,128,1125903600"; d="scan'208"; a="660918269:sNHT31098276" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8KNC64V002818; Tue, 20 Sep 2005 16:12:07 -0700 (PDT) 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.211); Tue, 20 Sep 2005 19:12:06 -0400 Received: from [192.168.1.100] ([10.86.240.205]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Sep 2005 19:12:05 -0400 In-Reply-To: <9473683187ADC049A855ED2DA739ABCA09FA937B@KCCLUST06EVS1.ugd.att.com> References: <9473683187ADC049A855ED2DA739ABCA09FA937B@KCCLUST06EVS1.ugd.att.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [Pce] Comments requested on section 6.1.15draft-ietf-pce-comm-protocol-gen-reqs-01.txt Date: Tue, 20 Sep 2005 19:12:30 -0400 To: "Ash, Gerald R ((Jerry)), ALABS" X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 20 Sep 2005 23:12:05.0944 (UTC) FILETIME=[B7B49B80:01C5BE38] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi Jerry, On Sep 20, 2005, at 6:47 PM, Ash, Gerald R ((Jerry)), ALABS wrote: > JP, All, > > >> The DT is currently working hard to address the remaining issues >> related to draft-ietf-pce-comm-protocol-gen-reqs-01.txt with the >> objective to start a WG last call right after the publication >> of this next revision. There is in particular one section for >> which comments are very welcome: section 6.1.15 (Scalability). >> >> Some of you asked for "indicative boundary numbers". >> >> Considering the lack of deployments at that point, I personally >> think that providing numbers is a bit hazardous but we could I guess >> come up with rough estimates of what such numbers should be, based >> on our current set of expectations, while stressing the fact that >> PCE protocols should be designed for greater scalability. Thus such >> numbers should be interpreted as "minimum values" (to be spelled out >> in the document). >> >> At this point, the following metrics have been proposed: >> >> (1) number of PCCs >> (2) number of PCEs >> (3) number of PCCs communicating with a single PCE >> (4) number of PCEs communicated to by a single PCC >> (5) number of PCEs communicated to by another PCE >> (6) number of domains >> (7) number of path requests per unit of time >> (8) handling bursts of requests per unit of time >> >> I would suggest to remove (1), (2) and (6) as they are not related >> to the PCEP (thus out of the scope of this requirement document). >> >> Please let us know if you have any comment or disagreement with this >> approach (preferably by Sept 23th). >> > > Dimitri's original comment back in July > http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html > suggested that 'boundary numbers' be specified for the items listed in > Section 6.1.15 (Scalability). While I was skeptical (and still am) > that > these boundary numbers could/should be specified (see > http://www1.ietf.org/mail-archive/web/pce/current/msg00273.html), > it was > agreed at IETF-63 to include 'order-of-magnitude' values in the > updated > draft. This has been done in the submitted update (to be > announced), as > follows: > > "6.1.15 Scalability > > The PCECP MUST scale well, at least as good as linearly, with an > increase of any of the following parameters (note, minimum order of > magnitude estimates of what the PCECP should support are given in > parenthesis): > > - number of PCCs (1000/domain) > - number of PCEs (100/domain) > - number of PCCs communicating with a single PCE (1000) > - number of PCEs communicated to by a single PCC (100) > - number of PCEs communicated to by another PCE (100) > - number of domains (20) > - number of path request messages (average of 10/second/PCE) > - handling bursts of requests (burst of 100/second/PCE within a 10- > second interval)." > > IMO, all of these parameters relate directly or indirectly (as in the > case of #1, #2, and #6) to PCECP scalability. Ok let's take the example of (1). What really matters is the max number of PCC that a PCE should have a session with (metric 3) not the total number of PCCs. You could for instance have a total of 1000 PCCs in a domain but no more than 100 PCCs communicating with a PCE. Why would the PCECP take of the total number of PCCs ? Same reasoning applies to (2) and (6). > My interpretation is that > the PCECP MUST support domains having these boundary numbers or > larger. > Good, Others, please voice your opinion. Thanks. JP. > Thanks, > Jerry > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Sep 21 10:50:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5vE-0004G4-KM; Wed, 21 Sep 2005 10:50:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5v8-0004Dv-9Q; Wed, 21 Sep 2005 10:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25473; Wed, 21 Sep 2005 10:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI61B-0004Dd-GF; Wed, 21 Sep 2005 10:56:17 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EI5v7-0000hr-Mk; Wed, 21 Sep 2005 10:50:01 -0400 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, 21 Sep 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-architecture-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: , Sender: pce-bounces@lists.ietf.org 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) Architecture Author(s) : A. Farrel, et al. Filename : draft-ietf-pce-architecture-02.txt Pages : 32 Date : 2005-9-21 Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-architecture-02.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-architecture-02.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-architecture-02.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: <2005-9-21104025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-architecture-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-architecture-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-21104025.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 Sep 21 15:50:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAbl-00087E-LG; Wed, 21 Sep 2005 15:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAbT-0007zy-CZ; Wed, 21 Sep 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15283; Wed, 21 Sep 2005 15:50:01 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIAhY-0004j5-9q; Wed, 21 Sep 2005 15:56:20 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EIAbR-000641-NP; Wed, 21 Sep 2005 15:50:01 -0400 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, 21 Sep 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-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: , Sender: pce-bounces@lists.ietf.org 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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-02.txt Pages : 20 Date : 2005-9-21 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-02.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-comm-protocol-gen-reqs-02.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-comm-protocol-gen-reqs-02.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: <2005-9-21105843.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-comm-protocol-gen-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-comm-protocol-gen-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-21105843.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 Thu Sep 22 08:02:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIPmF-00049C-Kr; Thu, 22 Sep 2005 08:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIPmE-00048p-MW for pce@megatron.ietf.org; Thu, 22 Sep 2005 08:02:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24653 for ; Thu, 22 Sep 2005 08:02:09 -0400 (EDT) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIPsK-00078g-Gq for pce@ietf.org; Thu, 22 Sep 2005 08:08:34 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-2.tower-126.messagelabs.com!1127390406!7453667!23 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 1152 invoked from network); 22 Sep 2005 12:01:51 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-2.tower-126.messagelabs.com with SMTP; 22 Sep 2005 12:01:51 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 431D9D3700270721 for pce@ietf.org; Thu, 22 Sep 2005 08:01:51 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 22 Sep 2005 07:01:50 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA938E@KCCLUST06EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt Thread-Index: AcW+5tbhuvjnw/mxTqCxDp/RdlYbpAAhK8nw From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi All, Please review and comment on the updated version of the PCE communications protocol (PCECP) generic requirements I-D http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-02.txt. The changes include those listed on slide 3 of the Paris meeting: http://www3.ietf.org/proceedings/05aug/slides/pce-2/sld3.htm and responses to Adrian's comprehensive review sent to the design team (these are all editorial comments). The most substantive changes are the inclusion of "boundary number" thresholds in Section 6.1.15 (Scalability). Dimitri suggested back in July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html that boundary numbers be specified, and it was agreed at IETF-63 to include 'order-of-magnitude' values in the updated draft. This has been done in the submitted update, and JP requested comments on this Section in his posting 2 days ago http://www1.ietf.org/mail-archive/web/pce/current/msg00418.html. Our objective is to start a WG last call soon. We look forward to your review and comments. Thanks, Regards, Jerry -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Wednesday, September 21, 2005 3:50 PM To: i-d-announce@ietf.org Cc: pce@ietf.org Subject: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt=20 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 : PCE Communication Protocol Generic Requirements Author(s) : J. Le Roux, J. Ash Filename : draft-ietf-pce-comm-protocol-gen-reqs-02.txt Pages : 20 Date : 2005-9-21 =09 The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req s-02.txt _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Sep 23 07:47:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIm1T-0004XB-26; Fri, 23 Sep 2005 07:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIm1P-0004WS-Sg for pce@megatron.ietf.org; Fri, 23 Sep 2005 07:47:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09327 for ; Fri, 23 Sep 2005 07:47:18 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIm7q-00044f-0b for pce@ietf.org; Fri, 23 Sep 2005 07:53:58 -0400 Received: from du-069-0165.access.clara.net ([217.158.132.165] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EIm1D-000IO8-7F for pce@ietf.org; Fri, 23 Sep 2005 12:47:08 +0100 Message-ID: <131001c5c034$eaf1ba70$28849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 23 Sep 2005 12:44:12 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Fw: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org FYI ----- Original Message ----- From: To: Sent: Friday, September 23, 2005 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada > > There are two (2) Internet-Draft cutoff dates for the 64th > IETF Meeting in Vancouver, British Columbia, Canada: > > October 17th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > October 17th 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, > October 10th at 9:00 AM ET. > > October 24th: 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, October 24th 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, November 7th 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 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Sat Sep 24 07:13:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ7yH-0008W0-E2; Sat, 24 Sep 2005 07:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ7yG-0008TP-9L for pce@megatron.ietf.org; Sat, 24 Sep 2005 07:13:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00332 for ; Sat, 24 Sep 2005 07:13:28 -0400 (EDT) Received: from relay3.mail.uk.clara.net ([80.168.70.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJ84s-0003xb-80 for pce@ietf.org; Sat, 24 Sep 2005 07:20:23 -0400 Received: from du-069-0185.access.clara.net ([217.158.132.185] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EJ7yC-000Ksp-Df for pce@ietf.org; Sat, 24 Sep 2005 12:13:29 +0100 Message-ID: <143a01c5c0f9$664fc260$28849ed9@Puppy> From: "Adrian Farrel" To: Date: Sat, 24 Sep 2005 12:11:55 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Changes to the PCE Architecture I-D 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi all, Thanks for the review comments from all and sundry on this I-D. The new revision attempts to address your concerns and questions. The main changes are: Add clarification that PCE is not a substitute for the routing paradigm that already exists, but is complementary to it. Also make clear that we are not intending to apply PCE to "The Internet" (compare with the charter). Try to moderate the opinion that has been formed that PCE is an "oracle in the sky" by re-stating that PCEs may be distributed on each and every LSR in the network. Strengthen the text discussing the applicability of and interaction with crankback. In particular, point out that PCE and crankback are not incompatible, but that both might be used in conjunction to build a sensible inter-domain routing system. Add some discussion of guaranteed LSP establishment (i.e. non-contention for resources) to explain that this can only work where all path computations for the whole network are coordinated and where network resources cannot fail. Add a further example usage to the architectural models: the management model. In this case the PCC is not an LSR, but is a management station (such as an NMS). Add a new section to describe the "view from PCC". This section is intended to resolve the discussions of terminology. We have not changed the terminology which we feel presents the overall view of the architecture, but we recognise the value of describing the functional model especially from the perspective of the PCC. Therefore this new section includes that description and relates it to the architectural terms previously defined. We have strengthened the discussion of Policy, but we have not attempted to complete this topic as we expect the details to be fleshed out in a new I-D that Lou has promised to produce. Note that we have not made any additions to the security session despite comments about this section on the mailing list and in Paris. On re-reading the section we could not find anything further to say. If you have any issues on this section then please suggest text. Thanks, Adrian _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Sep 27 11:44:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKHci-00019P-Mn; Tue, 27 Sep 2005 11:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKHcg-00018w-Uf for pce@megatron.ietf.org; Tue, 27 Sep 2005 11:44:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21444 for ; Tue, 27 Sep 2005 11:44:00 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKHjx-00018u-Es for pce@ietf.org; Tue, 27 Sep 2005 11:51:34 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Sep 2005 11:43:54 -0400 X-IronPort-AV: i="3.97,150,1125892800"; d="scan'208"; a="71959561:sNHT26801000" 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 j8RFhTR7019302 for ; Tue, 27 Sep 2005 11:43:51 -0400 (EDT) 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.211); Tue, 27 Sep 2005 11:43:43 -0400 Received: from [192.168.1.100] ([10.86.242.141]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 11:43:42 -0400 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pce@ietf.org From: JP Vasseur Date: Tue, 27 Sep 2005 11:43:58 -0400 X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 27 Sep 2005 15:43:42.0962 (UTC) FILETIME=[3D2B9520:01C5C37A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Working Group Last call on draft-ietf-pce-architecture-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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, draft-ietf-pce-architecture-02.txt has been edited addressing the list of open issues and is now ready for working group last call. This email initiates a working group last call on draft-ietf-pce- architecture-02.txt. The last call will end on Tuesday 11th October at noon EST. Please send your comments to the mailing list and copy the chairs. Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Sep 29 11:47:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0dG-0006j5-E0; Thu, 29 Sep 2005 11:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0dE-0006iv-EI for pce@megatron.ietf.org; Thu, 29 Sep 2005 11:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19586 for ; Thu, 29 Sep 2005 11:47:33 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL0kt-0005iq-Pp for pce@ietf.org; Thu, 29 Sep 2005 11:55:33 -0400 Received: from du-069-0048.access.clara.net ([217.158.132.48] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EL0d1-000DSu-6T for pce@ietf.org; Thu, 29 Sep 2005 16:47:23 +0100 Message-ID: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> From: "Adrian Farrel" To: Date: Thu, 29 Sep 2005 15:27:13 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Subject: [Pce] Choosing the PCE protocol 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org Hi, Three candidate protocols have been brought to my attention for us to consider. These are (in no specific order): - HTTP - PCECP (as draft-vasseur-pce-pcep-02.txt) - COPS I would like to close the nomination period, and move on to select our protocol. The best approach will be if supporters of the candidate protocols indicate (briefly) why their proposed protocol is suitable. It would also be helpful if they were frank about what the weaknesses of their proposal are. And please - this is not an election, it is an interview process. Thanks, Adrian PS The reason why JP is keeping quite on this is that he is an author of draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not occupying the chair during this discussion. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Sep 29 12:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0qC-0001WU-Fp; Thu, 29 Sep 2005 12:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0qB-0001WK-Kq for pce@megatron.ietf.org; Thu, 29 Sep 2005 12:00:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20120 for ; Thu, 29 Sep 2005 12:00:56 -0400 (EDT) Received: from relay2.mail.uk.clara.net ([80.168.70.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL0xr-00062E-Bo for pce@ietf.org; Thu, 29 Sep 2005 12:08:56 -0400 Received: from du-069-0048.access.clara.net ([217.158.132.48] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EL0q8-000HgK-6o for pce@ietf.org; Thu, 29 Sep 2005 17:00:57 +0100 Message-ID: <050b01c5c50f$63088050$be849ed9@Puppy> From: "Adrian Farrel" To: References: <04ba01c5c50d$7e5edcc0$be849ed9@Puppy> Subject: Re: [Pce] Choosing the PCE protocol Date: Thu, 29 Sep 2005 17:03:49 +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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: pce-bounces@lists.ietf.org Errors-To: pce-bounces@lists.ietf.org All, I should have been more careful with my acronyms. PCECP is the generic protocol. In other words, what the requirements describe. The job vacancy we are trying to fill. PCEP is JP's (and others) proposed solution. Cheers, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, September 29, 2005 3:27 PM Subject: [Pce] Choosing the PCE protocol > Hi, > > Three candidate protocols have been brought to my attention for us to > consider. These are (in no specific order): > - HTTP > - PCECP (as draft-vasseur-pce-pcep-02.txt) > - COPS > > I would like to close the nomination period, and move on to select our > protocol. > > The best approach will be if supporters of the candidate protocols > indicate (briefly) why their proposed protocol is suitable. It would also > be helpful if they were frank about what the weaknesses of their proposal > are. > > And please - this is not an election, it is an interview process. > > Thanks, > Adrian > > PS The reason why JP is keeping quite on this is that he is an author of > draft-vasseur-pce-pcep-02.txt and so (quite rightly) is not occupying the > chair during this discussion. > > > > > _______________________________________________ > 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