[MPLS2006 INTERNATIONAL CONFERENCE] Reminder, CFP : one month = left

From pce-bounces@lists.ietf.org Tue Apr 04 18:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtic-0001xf-Of; Tue, 04 Apr 2006 18:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtib-0001xa-3Q for pce@ietf.org; Tue, 04 Apr 2006 18:09:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtiZ-0003UO-P9 for pce@ietf.org; Tue, 04 Apr 2006 18:09:45 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Apr 2006 15:09:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,164,1141632000"; d="scan'208,217"; a="25183646:sNHT123425502" 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 k34M9gVU016446; Tue, 4 Apr 2006 18:09:43 -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); Tue, 4 Apr 2006 18:09:42 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Apr 2006 18:09:42 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) To: pce@ietf.org Message-Id: <3AD4AF1E-0187-4588-9EED-2587155BA407@cisco.com> From: JP Vasseur Date: Tue, 4 Apr 2006 18:09:07 -0400 X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 04 Apr 2006 22:09:42.0097 (UTC) FILETIME=[7929E410:01C65834] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Pce] IETF-65 PCE Working Group meeting minutes (draft) available X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986921628==" Errors-To: pce-bounces@lists.ietf.org --===============1986921628== Content-Type: multipart/alternative; boundary=Apple-Mail-92-525107028 --Apple-Mail-92-525107028 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, You can find the draft of the IETF-65 PCE WG minutes at: https:// datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Please provide your potential comments by April 14. Thanks. JP. --Apple-Mail-92-525107028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

You can find the draft of = the IETF-65 PCE WG minutes at:=A0https://datatracker.ietf.org/public/meeting_materials.cgi?meetin= g_num=3D65

Please provide your potential comments by April = 14.

Thanks.

JP.

= --Apple-Mail-92-525107028-- --===============1986921628== 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 --===============1986921628==-- From pce-bounces@lists.ietf.org Wed Apr 05 18:20:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGMB-0002C7-Mk; Wed, 05 Apr 2006 18:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGMA-00027s-Ps for pce@ietf.org; Wed, 05 Apr 2006 18:20:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGM9-0000TW-1t for pce@ietf.org; Wed, 05 Apr 2006 18:20:06 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2006 15:20:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,91,1144047600"; d="scan'208,217"; a="25277432:sNHT60084766" 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 k35MK3Wc004332; Wed, 5 Apr 2006 18:20:03 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 18:20:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Apr 2006 18:19:54 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comparison of Encryption vs. Path Key Solutions for the CPS ID. Thread-Index: AcZYoa17yPX/wRg0S0Wcwz2H4PidHgAXKKKQ From: "Rich Bradford $rbradfor$" To: , X-OriginalArrivalTime: 05 Apr 2006 22:20:03.0008 (UTC) FILETIME=[15AB2400:01C658FF] X-Spam-Score: 0.1 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: Subject: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPS ID. 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="===============1269095663==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1269095663== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658FF.1571E0A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C658FF.1571E0A3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHN1Z2dlc3RlZCBpbiBEYWxsYXMsIEnigJl2ZSBkZXNjcmliZWQgc29tZSBvZiB0 aGUgdHJhZGVvZmZzIGJldHdlZW4gdGhlIHR3byBzb2x1dGlvbnMgZGVzY3JpYmVkIGluIGRyYWZ0 LXJicmFkZm9yLWNjYW1wLWNvbmZpZGVudGlhbC1zZWdtZW50LTAwLnR4dC4NCg0KLS0gUmljaA0K DQogDQoNClRoZSBDb25maWRlbnRpYWwgUGF0aCBTZWdtZW50IChDUFMpIElEIHByb3ZpZGVzIHR3 byB2ZXJ5IGRpZmZlcmVudCBidXQgZXF1YWxseSB2YWxpZCBzb2x1dGlvbnMsIHRoZSBQYXRoIEtl eSBTdWJvYmplY3QgKFBLUykgc29sdXRpb24gYW5kIHRoZSBQcml2YXRlIFJvdXRlIFN1Ym9iamVj dCAoUFJTKSBzb2x1dGlvbi4gVGhpcyBub3RlIGV4YW1pbmVzIGEgbnVtYmVyIG9mIHRoZSBhZHZh bnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIGVhY2ggc29sdXRpb24uIA0KDQogDQoNCkluIHNo b3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMgZm9yIGFu IEFTIGJ5IHNhdmluZyBpdCBpbiBhIGRhdGFiYXNlIGFuZCByZXBsYWNpbmcgaXQgd2l0aCBhIGtl eSBpbiB0aGUgRVJPLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNSIGZvciB0 aGF0IEFTIG11c3QgcXVlcnkgdGhlIFBDRSBmb3IgYW4gZXhwYW5zaW9uLg0KDQpUaGUgUFJTIHNv bHV0aW9uIGFsbG93cyBhIENQUyBmb3IgYW4gQVMgdG8gYmUgaGlkZGVuIGJ5IGVuY3J5cHRpbmcg aXQsIHdoaWNoIG1heSBiZSBkb25lIGJ5IGEgUENFIG9yIGJ5IHRoZSBIZWFkLUVuZCBMU1IuIER1 cmluZyB0aGUgTFNQIHNldHVwLCB0aGUgaW5ncmVzcyBMU1IgZm9yIHRoYXQgQVMgbXVzdCB1c2Ug YSBkZWNyeXB0aW9uIGtleSB0byBvYnRhaW4gdGhlIGV4cGFuc2lvbiAoaW1wbHlpbmcgYW4gZWFy bGllciBleGNoYW5nZSBvciBjb25maWd1cmF0aW9uKS4gDQoNCiANCg0KVGhlIG1ham9yIGRpZmZl cmVuY2VzIGJldHdlZW4gdGhlIG1lY2hhbmlzbXMgaW52b2x2ZSAoMSkgYWRkaXRpb25hbCBjb250 cm9sIG1lc3NhZ2VzLCAoMikgcGVyZm9ybWFuY2UgaXNzdWVzIGV4cGFuZGluZyB0aG9zZSBvYmpl Y3RzLCAoMykgdGhlIGFkZGl0aW9uIG9mIHN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRp b24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzIHRvcG9sb2dpZXMgb2YgZWFj aCBzb2x1dGlvbi4pLCBhbmQgKDUpIHRoZSBzaXplIG9mIG9iamVjdHMgYWRkZWQgdG8gZXhpc3Rp bmcgbWVzc2FnZXMuDQoNCiANCg0KKDEpIEFkZGl0aW9uYWwgQ29udHJvbCBNZXNzYWdlIE92ZXJo ZWFkOg0KDQpUaGUgUEtTIHNvbHV0aW9uIHJlcXVpcmVzIGEgbWVjaGFuaXNtIHRvIGV4cGFuZCB0 aGUgUGF0aCBLZXkgdXBvbiByZWNlaXB0IG9mIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC4gU2luY2Ug dGhlIFBDRSB3aGljaCBjYWxjdWxhdGVkIHRoZSBQYXRoIEtleSBtaWdodCBub3QgcmVzaWRlIGlu IHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNp b24gZnJvbSB0aGUgUENFLCByZXF1aXJpbmcgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGV4Y2hhbmdl IGJlZm9yZSBMU1Agc2V0dXAgY2FuIHByb2NlZWQuIFRoZSBQYXRoIEVuY3J5cHRpb24gc29sdXRp b24gZG9lcyBub3QgcmVxdWlyZSB0aGlzIGV4dHJhIGV4Y2hhbmdlIGJldHdlZW4gdGhlIFBDRSBh bmQgdGhlIGluZ3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9u IGtleSBuZWVkcyB0byBiZSBleGNoYW5nZWQgb25seSB3aGVuIGl0IGlzIGNoYW5nZWQuIFRoZSBy ZXN1bHQgaXMgYWRkaXRpb25hbCBkZWxheSBkdXJpbmcgZXZlcnkgTFNQIHNldHVwIGZvciB0aGUg UEtTIHNvbHV0aW9uIGJ1dCBubyBhZGRpdGlvbmFsIGRlbGF5IGZvciB0aGUgUFJTIHNvbHV0aW9u Lg0KDQogDQoNCiANCg0KKDIpIFBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOg0KDQpUaGUgUEtTIHNv bHV0aW9uIG11c3QgbWFpbnRhaW4gYSAodGVtcG9yYXJ5KSBkYXRhYmFzZSBvZiBrZXlzIGFkZGlu ZyBvdmVyaGVhZCB0byB0aGUgUENFLiBUaGUgUFJTIHNvbHV0aW9uIHJlcXVpcmVzIHRoZSBlbmNy eXB0aW9uIG9mIHRoZSBDUFMgaW4gdGhlIFBDRSBhbmQgZGVjcnlwdGlvbiBvZiB0aGUgQ1BTIGlu IHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBpbnRlbnNpdmUuIE5vdGUgdGhhdCBpbiBjYXNl IG9mIGEgYnVyc3Qgb2YgcmVxdWVzdHMsIGVuY3J5cHRpb24gb2YgbGFyZ2UgbnVtYmVyIG9mIENQ UyBtYXkgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIFBDRSByZXNwb25zZSB0aW1lLg0KDQogDQoNCigz KSBBZGRpdGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOg0KDQpUaGUgUEtTIHNvbHV0aW9uIHJlcXVp cmVzIHRoZSBhZGRpdGlvbiBvZiBwYXRoLXNwZWNpZmljIHN0YXRlIGFuZCBtYWludGVuYW5jZSBv ZiBhIGRhdGFiYXNlIGluIHRoZSBQQ0UuIFRoZSBQUlMgc29sdXRpb24gcmVxdWlyZXMgbm8gYWRk aXRpb25hbCBzdGF0ZS4NCg0KIA0KDQogDQoNCig0KSBTb2x1dGlvbiBTY29wZToNCg0KVGhlIFBL UyBhbmQgUFJTIHNvbHV0aW9ucyBib3RoIHdvcmsgd2VsbCBpbiBjb25qdW5jdGlvbiB3aXRoIGEg UENFIHRvIGVuY29kZSBhbmQgZGVjb2RlIHRoZSBDUFMuIEhvd2V2ZXIgdGhlIFBLUyBwcm92aWRl cyBubyBkaXJlY3Qgc29sdXRpb24gd2l0aG91dCBhIFBDRS4gVGhpcyBwcmV2ZW50cyB0aGUgUEtT IHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrIHN0cmFk ZGxlcyBCJ3MgbmV0d29yayBhbmQgd2hlcmUgQSB3YW50cyB0byB1c2UgYW4gRVJPIGZvciBhIHNl Z21lbnQgb2YgdGhlIExTUCBhY3Jvc3MgdGhlIGludGVydmVuaW5nIG5ldHdvcmssIGUuZy4gKG5l dEEpLShuZXRCKS0obmV0QSkuIEluIGFkZGl0aW9uLCB0aGUgUFJTIGNvdWxkIGJlIHVzZWQgdG8g cmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJldHVybmVk IFJSTykgY3Jvc3NlcyBtdWx0aXBsZSBib3VuZGFyaWVzLiBGaW5hbGx5LCBhIFBSUyBzb2x1dGlv biBjb3VsZCBiZSBhZGFwdGVkIHRvIHJldHVybiBhY3R1YWwgZmFpbHVyZSBsb2NhdGlvbnMgaW4g UEVSUnMgYW5kL29yIFBBVEhURUFScywgd2hpbGUga2VlcGluZyB0aGUgZmFpbHVyZSBsb2NhdGlv biBjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtleS4gQ3VycmVu dGx5IHByaXZhY3kgb2YgdGhpcyBzb3VyY2UgaXMgbWFpbnRhaW5lZCBieSByZXR1cm5pbmcgdGhl IGFkZHJlc3Mgb2YgYm9yZGVyIG5vZGVzLCB3aGljaCBjYW4gYmUgdmVyeSBtaXNsZWFkaW5nLg0K DQogDQoNCig1KSBNZXNzYWdlIE9iamVjdCBPdmVyaGVhZDoNCg0KVGhlIFBLUyBzb2x1dGlvbiBw cm92aWRlcyBhIHZlcnkgY29tcGFjdCBrZXkgb3IgdG9rZW4gdG8gaWRlbnRpZnkgYSBwYXRoIHNl Z21lbnQsIHdoaWNoIGdlbmVyYWxseSBhbGxvd3MgZm9yIHNtYWxsZXIgRVJPcyB0byBiZSByZXR1 cm5lZCBieSB0aGUgUENFIGFuZCB0byBiZSByZXF1ZXN0ZWQgaW4gdGhlIHJlc3VsdGluZyBQQVRI IG1lc3NhZ2UuIEEgUFJTIHdoaWNoIGNvbnRhaW5zIGEgQ1BTIG11c3QgZ2VuZXJhbGx5IGJlIGF0 IGxlYXN0IGFzIGxhcmdlIGFzIHRoZSB1bmVuY3J5cHRlZCBQQVRIIHRocm91Z2ggdGhlIEFTIGFu ZCBtYXkgYmUgc2lnbmlmaWNhbnRseSBsYXJnZXIgaWYgaXQgaXMgZGVzaXJhYmxlIHRvIGhpZGUg dGhlIG51bWJlciBvZiBob3BzIHdpdGhpbiB0aGUgbmV0d29yayBmcm9tIGV4dGVybmFsIHZpZXcg YnkgcGFkZGluZyB0aGUgUFJTLiBUaGUgcmVzdWx0IGlzIHBvdGVudGlhbGx5IGxhcmdlciBQQVRI IChhbmQgUENFUCkgbWVzc2FnZXMgZm9yIHRoZSBQUlMgc29sdXRpb24uDQoNCiANCg0KIA0KDQpQ bGVhc2Ugbm90ZSB0aGF0IHRoZSB0cmFkZW9mZnMgbGlzdGVkIGhlcmUgYXJlIGZvciB0aGUgY3Vy cmVudCBJLUQuIFNvbWUgb2YgdGhlIHNob3J0Y29taW5ncyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxk IGJlIG1pdGlnYXRlZCBieSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBvcHRpbWl6YXRpb25zLiBG b3IgZXhhbXBsZSwgYSBQQ0UgY291bGQgY2hvb3NlIHRvIHNpZ25hbCB0aGUgQ1BTIGV4cGFuc2lv biB0byB0aGUgZW50cnkgYm91bmRhcnkgTFNSLCBzaGlmdGluZyB0aGUgYnVyZGVuIG9mIG1haW50 YWluaW5nIHRoZSBQS1Mgc3RhdGUgdG8gdGhlIExTUiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZv cm1hbmNlIGhpdCBkdXJpbmcgTFNQIHNldHVwLiBBIHNpbWlsYXIgZXhjaGFuZ2UgY291bGQgYmUg cGVyZm9ybWVkIGZvciB0aGUgUFJTIGNhc2UsIGVsaW1pbmF0aW5nIHRoZSBuZWVkIGZvciBhIHNl cGFyYXRlIGtleSBleGNoYW5nZS4gVGhlc2UgZXhhbXBsZXMgb2YgZXh0ZW5zaW9ucyBhcmUgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGUgSUQsIGJ1dCBtaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGlu ZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgdHdvIHNvbHV0aW9ucy4NCg0KIA0KDQogDQoNCg== ------_=_NextPart_001_01C658FF.1571E0A3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3Jk IiB4bWxuczpzdDE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIg eG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1l dGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IkNpdHkiLz4NCjxvOlNtYXJ0VGFnVHlw ZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFn cyINCiBuYW1lPSJwbGFjZSIvPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhh dmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KaDENCgl7bWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjMuMHB0Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7DQoJ Zm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseTpBcmlhbDt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4 dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5D aGFwdGVyLCBsaS5DaGFwdGVyLCBkaXYuQ2hhcHRlcg0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWJlZm9yZTph bHdheXM7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo2ODg5NDE0NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTQ4MzQ2NjggNTA2NDg4NjY0IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAxIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPg0KPC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+QXMgc3VnZ2VzdGVkIGluIDxzdDE6Q2l0 eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+RGFsbGFzPC9zdDE6cGxhY2U+PC9zdDE6 Q2l0eT4sDQpJ4oCZdmUgZGVzY3JpYmVkIHNvbWUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRo ZSB0d28gc29sdXRpb25zIGRlc2NyaWJlZA0KaW4gZHJhZnQtcmJyYWRmb3ItY2NhbXAtY29uZmlk ZW50aWFsLXNlZ21lbnQtMDAudHh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4tLSBSaWNoPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5U aGUgQ29uZmlkZW50aWFsIFBhdGggU2VnbWVudCAoQ1BTKSBJRCBwcm92aWRlcyB0d28gdmVyeSBk aWZmZXJlbnQgYnV0DQplcXVhbGx5IHZhbGlkIHNvbHV0aW9ucywgdGhlIFBhdGggS2V5IFN1Ym9i amVjdCAoUEtTKSBzb2x1dGlvbiBhbmQgdGhlIFByaXZhdGUNClJvdXRlIFN1Ym9iamVjdCAoUFJT KSBzb2x1dGlvbi4gVGhpcyBub3RlIGV4YW1pbmVzIGEgbnVtYmVyIG9mIHRoZSBhZHZhbnRhZ2Vz DQphbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIHNvbHV0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PkluIHNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMg Zm9yIGFuIEFTIGJ5DQpzYXZpbmcgaXQgaW4gYSBkYXRhYmFzZSBhbmQgcmVwbGFjaW5nIGl0IHdp dGggYSBrZXkgaW4gdGhlIEVSTy4gRHVyaW5nIHRoZSBMU1ANCnNldHVwLCB0aGUgaW5ncmVzcyBM U1IgZm9yIHRoYXQgQVMgbXVzdCBxdWVyeSB0aGUgUENFIGZvciBhbiBleHBhbnNpb24uPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PlRoZSBQUlMgc29sdXRpb24gYWxsb3dzIGEgQ1BTIGZvciBhbiBBUyB0byBiZSBoaWRkZW4gYnkg ZW5jcnlwdGluZyBpdCwNCndoaWNoIG1heSBiZSBkb25lIGJ5IGEgUENFIG9yIGJ5IHRoZSBIZWFk LUVuZCBMU1IuIER1cmluZyB0aGUgTFNQIHNldHVwLCB0aGUNCmluZ3Jlc3MgTFNSIGZvciB0aGF0 IEFTIG11c3QgdXNlIGEgZGVjcnlwdGlvbiBrZXkgdG8gb2J0YWluIHRoZSBleHBhbnNpb24NCihp bXBseWluZyBhbiBlYXJsaWVyIGV4Y2hhbmdlIG9yIGNvbmZpZ3VyYXRpb24pLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPlRoZSBtYWpvciBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBtZWNoYW5pc21zIGlu dm9sdmUgKDEpIGFkZGl0aW9uYWwNCmNvbnRyb2wgbWVzc2FnZXMsICgyKSBwZXJmb3JtYW5jZSBp c3N1ZXMgZXhwYW5kaW5nIHRob3NlIG9iamVjdHMsICgzKSB0aGUNCmFkZGl0aW9uIG9mIHN0YXRl IHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRpb24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0 bw0KdmFyaW91cyB0b3BvbG9naWVzIG9mIGVhY2ggc29sdXRpb24uKSwgYW5kICg1KSB0aGUgc2l6 ZSBvZiBvYmplY3RzIGFkZGVkIHRvDQpleGlzdGluZyBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPigxKSBBZGRpdGlvbmFsIENvbnRyb2wgTWVzc2FnZSBPdmVyaGVhZDo8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+VGhlIFBL UyBzb2x1dGlvbiByZXF1aXJlcyBhIG1lY2hhbmlzbSB0byBleHBhbmQgdGhlIFBhdGggS2V5IHVw b24NCnJlY2VpcHQgb2YgdGhlIExTUCBzZXR1cCByZXF1ZXN0LiBTaW5jZSB0aGUgUENFIHdoaWNo IGNhbGN1bGF0ZWQgdGhlIFBhdGggS2V5DQptaWdodCBub3QgcmVzaWRlIGluIHRoZSBlbnRyeSBi b3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNpb24NCmZyb20gdGhl IFBDRSwgcmVxdWlyaW5nIGFuIGFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgTFNQ IHNldHVwIGNhbg0KcHJvY2VlZC4gVGhlIFBhdGggRW5jcnlwdGlvbiBzb2x1dGlvbiBkb2VzIG5v dCByZXF1aXJlIHRoaXMgZXh0cmEgZXhjaGFuZ2UNCmJldHdlZW4gdGhlIFBDRSBhbmQgdGhlIGlu Z3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9uIGtleQ0KbmVl ZHMgdG8gYmUgZXhjaGFuZ2VkIG9ubHkgd2hlbiBpdCBpcyBjaGFuZ2VkLiBUaGUgcmVzdWx0IGlz IGFkZGl0aW9uYWwgZGVsYXkNCmR1cmluZyBldmVyeSBMU1Agc2V0dXAgZm9yIHRoZSBQS1Mgc29s dXRpb24gYnV0IG5vIGFkZGl0aW9uYWwgZGVsYXkgZm9yIHRoZSBQUlMNCnNvbHV0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0 Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigyKSBQQ0UgYW5kIExTUiBQZXJmb3JtYW5jZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEy LjBwdCc+VGhlIFBLUyBzb2x1dGlvbiBtdXN0IG1haW50YWluIGEgKHRlbXBvcmFyeSkgZGF0YWJh c2Ugb2Yga2V5cyBhZGRpbmcNCm92ZXJoZWFkIHRvIHRoZSBQQ0UuIFRoZSBQUlMgc29sdXRpb24g cmVxdWlyZXMgdGhlIGVuY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0aGUNClBDRSBhbmQgZGVjcnlw dGlvbiBvZiB0aGUgQ1BTIGluIHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBpbnRlbnNpdmUu IE5vdGUNCnRoYXQgaW4gY2FzZSBvZiBhIGJ1cnN0IG9mIHJlcXVlc3RzLCBlbmNyeXB0aW9uIG9m IGxhcmdlIG51bWJlciBvZiBDUFMgbWF5IGhhdmUNCmFuIGltcGFjdCBvbiB0aGUgUENFIHJlc3Bv bnNlIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oMykgQWRkaXRpb24gb2YgU3RhdGUgaW4gdGhl IFBDRTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+VGhlIFBLUyBzb2x1dGlvbiByZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgcGF0 aC1zcGVjaWZpYyBzdGF0ZSBhbmQNCm1haW50ZW5hbmNlIG9mIGEgZGF0YWJhc2UgaW4gdGhlIFBD RS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1aXJlcyBubyBhZGRpdGlvbmFsDQpzdGF0ZS48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oNCkgU29sdXRpb24gU2NvcGU6PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlRoZSBQ S1MgYW5kIFBSUyBzb2x1dGlvbnMgYm90aCB3b3JrIHdlbGwgaW4gY29uanVuY3Rpb24gd2l0aCBh IFBDRSB0bw0KZW5jb2RlIGFuZCBkZWNvZGUgdGhlIENQUy4gSG93ZXZlciB0aGUgUEtTIHByb3Zp ZGVzIG5vIGRpcmVjdCBzb2x1dGlvbiB3aXRob3V0DQphIFBDRS4gVGhpcyBwcmV2ZW50cyB0aGUg UEtTIHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrDQpz dHJhZGRsZXMgQidzIG5ldHdvcmsgYW5kIHdoZXJlIEEgd2FudHMgdG8gdXNlIGFuIEVSTyBmb3Ig YSBzZWdtZW50IG9mIHRoZSBMU1ANCmFjcm9zcyB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5n LiAobmV0QSktKG5ldEIpLShuZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMNCmNvdWxkIGJlIHVz ZWQgdG8gcmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJl dHVybmVkIFJSTykNCmNyb3NzZXMgbXVsdGlwbGUgYm91bmRhcmllcy4gRmluYWxseSwgYSBQUlMg c29sdXRpb24gY291bGQgYmUgYWRhcHRlZCB0byByZXR1cm4NCmFjdHVhbCBmYWlsdXJlIGxvY2F0 aW9ucyBpbiBQRVJScyBhbmQvb3IgUEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJl DQpsb2NhdGlvbiBjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtl eS4gQ3VycmVudGx5IHByaXZhY3kgb2YNCnRoaXMgc291cmNlIGlzIG1haW50YWluZWQgYnkgcmV0 dXJuaW5nIHRoZSBhZGRyZXNzIG9mIGJvcmRlciBub2Rlcywgd2hpY2ggY2FuDQpiZSB2ZXJ5IG1p c2xlYWRpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oNSkgTWVzc2FnZSBPYmplY3QgT3ZlcmhlYWQ6 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox Mi4wcHQnPlRoZSBQS1Mgc29sdXRpb24gcHJvdmlkZXMgYSB2ZXJ5IGNvbXBhY3Qga2V5IG9yIHRv a2VuIHRvIGlkZW50aWZ5IGENCnBhdGggc2VnbWVudCwgd2hpY2ggZ2VuZXJhbGx5IGFsbG93cyBm b3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRoZSBQQ0UNCmFuZCB0byBiZSByZXF1 ZXN0ZWQgaW4gdGhlIHJlc3VsdGluZyBQQVRIIG1lc3NhZ2UuIEEgUFJTIHdoaWNoIGNvbnRhaW5z IGEgQ1BTDQptdXN0IGdlbmVyYWxseSBiZSBhdCBsZWFzdCBhcyBsYXJnZSBhcyB0aGUgdW5lbmNy eXB0ZWQgUEFUSCB0aHJvdWdoIHRoZSBBUyBhbmQgbWF5DQpiZSBzaWduaWZpY2FudGx5IGxhcmdl ciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVtYmVyIG9mIGhvcHMgd2l0aGluDQp0 aGUgbmV0d29yayBmcm9tIGV4dGVybmFsIHZpZXcgYnkgcGFkZGluZyB0aGUgUFJTLiBUaGUgcmVz dWx0IGlzIHBvdGVudGlhbGx5DQpsYXJnZXIgUEFUSCAoYW5kIFBDRVApIG1lc3NhZ2VzIGZvciB0 aGUgUFJTIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlBsZWFzZSBu b3RlIHRoYXQgdGhlIHRyYWRlb2ZmcyBsaXN0ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEkt RC4NClNvbWUgb2YgdGhlIHNob3J0Y29taW5ncyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxkIGJlIG1p dGlnYXRlZCBieQ0KaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgb3B0aW1pemF0aW9ucy4gRm9yIGV4 YW1wbGUsIGEgUENFIGNvdWxkIGNob29zZSB0bw0Kc2lnbmFsIHRoZSBDUFMgZXhwYW5zaW9uIHRv IHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHNoaWZ0aW5nIHRoZSBidXJkZW4gb2YNCm1haW50YWlu aW5nIHRoZSBQS1Mgc3RhdGUgdG8gdGhlIExTUiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZvcm1h bmNlIGhpdCBkdXJpbmcNCkxTUCBzZXR1cC4gQSBzaW1pbGFyIGV4Y2hhbmdlIGNvdWxkIGJlIHBl cmZvcm1lZCBmb3IgdGhlIFBSUyBjYXNlLCBlbGltaW5hdGluZw0KdGhlIG5lZWQgZm9yIGEgc2Vw YXJhdGUga2V5IGV4Y2hhbmdlLiBUaGVzZSBleGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlv bmQNCnRoZSBzY29wZSBvZiB0aGUgSUQsIGJ1dCBtaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGlu ZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUNCnR3byBzb2x1dGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPsKgPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+ DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C658FF.1571E0A3-- --===============1269095663== 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 --===============1269095663==-- From pce-bounces@lists.ietf.org Thu Apr 06 02:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRNy9-0005ft-O4; Thu, 06 Apr 2006 02:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRNy7-0005dz-O9 for pce@ietf.org; Thu, 06 Apr 2006 02:27:47 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRNy0-0001pu-EL for pce@ietf.org; Thu, 06 Apr 2006 02:27:47 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k366Rbki002624 for ; Thu, 6 Apr 2006 15:27:37 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k366RbR8011785 for ; Thu, 6 Apr 2006 15:27:37 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k366RaZY005657 for ; Thu, 6 Apr 2006 15:27:36 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k366RaiD005563 for ; Thu, 6 Apr 2006 15:27:36 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k366RZtZ023041 for ; Thu, 6 Apr 2006 15:27:35 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k366RY67023036 for ; Thu, 6 Apr 2006 15:27:34 +0900 (JST) Received: from [129.60.79.121] ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k366RYbw028240 for ; Thu, 6 Apr 2006 15:27:34 +0900 (JST) Date: Thu, 06 Apr 2006 15:27:31 +0900 From: Eiji Oki To: pce@ietf.org Message-Id: <20060406142658.D272.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_4434A6A1D27304386D38_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: Subject: [Pce] Fw: I-D ACTION:draft-oki-pce-inter-layer-frwk-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --------_4434A6A1D27304386D38_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi all, As suggested in Dallas meeting, the inter-layer applicability draft (draft-oki-pce-inter-layer-app-00.txt) was changed to an inter-layer framework draft, which is posted as http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt Main changes are: - the draft name and tile from "applicability" to "framework". - other related texts. Any comments and suggestions are highly appreciated. Thank you. Eiji Forwarded by Eiji Oki ----------------------- Original Message ----------------------- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Date: Wed, 05 Apr 2006 15:50:02 -0400 Subject: I-D ACTION:draft-oki-pce-inter-layer-frwk-00.txt ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-oki-pce-inter-layer-frwk-00.txt Pages : 1 Date : 2006-4-5 A network may comprise of multiple layers. It is important to globally optimize network resources utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for the PCE-based path computation architecture to inter-layer MPLS and GMPLS traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-oki-pce-inter-layer-frwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------------- Original Message Ends -------------------- -- Eiji Oki, Ph. D. Senior Research Engineer NTT Network Service Systems Laboratories 3-9-11 Midori-cho Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-3441, Fax: +81-422-59-3787 E-mail: oki.eiji@lab.ntt.co.jp --------_4434A6A1D27304386D38_MULTIPART_MIXED_ Content-Type: message/rfc822 Content-Description: I-D ACTION:draft-oki-pce-inter-layer-frwk-00.txt Return-Path: Received: from eclscan1.m.ecl.ntt.co.jp (eclscan1.m.ecl.ntt.co.jp [129.60.5.67]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k35JqEFE028498; Thu, 6 Apr 2006 04:52:14 +0900 (JST) Received: from eclscan1.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan1.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35JqEIv011299; Thu, 6 Apr 2006 04:52:14 +0900 (JST) Received: from idmb.m.ecl.ntt.co.jp. (idmb.m.ecl.ntt.co.jp [129.60.5.3]) by eclscan1.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35JqDw2011294; Thu, 6 Apr 2006 04:52:13 +0900 (JST) Received: from nttmail2.ecl.ntt.co.jp (nttmail2.ecl.ntt.co.jp [129.60.57.213]) by idmb.m.ecl.ntt.co.jp. (8.13.5/8.13.5) with ESMTP id k35JqDhh026213; Thu, 6 Apr 2006 04:52:13 +0900 (JST) Received: from vcs4.rdh.ecl.ntt.co.jp (vcs4 [129.60.39.111]) by nttmail2.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35JqD3p007403; Thu, 6 Apr 2006 04:52:13 +0900 (JST) Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113]) by vcs4.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35JqC6U002364; Thu, 6 Apr 2006 04:52:12 +0900 (JST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by mfs4.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35JqBAb018909; Thu, 6 Apr 2006 04:52:11 +0900 (JST) Received: from megatron.ietf.org (megatron.ietf.org [156.154.16.145]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k35Jq9ke001359; Thu, 6 Apr 2006 04:52:10 +0900 (JST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE1K-0008UA-SD; Wed, 05 Apr 2006 15:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRE0x-0007tk-7w for i-d-announce@ietf.org; Wed, 05 Apr 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRE0w-0007N3-Kj for i-d-announce@ietf.org; Wed, 05 Apr 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k35Jo2vP011029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FRE0w-0003uG-1Y for i-d-announce@ietf.org; Wed, 05 Apr 2006 15:50:02 -0400 Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 05 Apr 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: I-D ACTION:draft-oki-pce-inter-layer-frwk-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org Status: Content-Type: Multipart/Mixed; Boundary="NextPart" Content-Transfer-Encoding: 7bit --NextPart Content-Type: text/plain Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-oki-pce-inter-layer-frwk-00.txt Pages : 1 Date : 2006-4-5 A network may comprise of multiple layers. It is important to globally optimize network resources utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for the PCE-based path computation architecture to inter-layer MPLS and GMPLS traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-oki-pce-inter-layer-frwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" Content-Transfer-Encoding: 7bit --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-4-5140423.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-oki-pce-inter-layer-frwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Disposition: attachment; filename="draft-oki-pce-inter-layer-frwk-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2006-4-5140423.I-D@ietf.org> --OtherAccess-- --NextPart MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------_4434A6A1D27304386D38_MULTIPART_MIXED_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce --------_4434A6A1D27304386D38_MULTIPART_MIXED_-- From pce-bounces@lists.ietf.org Thu Apr 06 08:52:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTyI-0005bx-AW; Thu, 06 Apr 2006 08:52:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRTyG-0005bs-NJ for pce@ietf.org; Thu, 06 Apr 2006 08:52:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRTyG-00078R-3T for pce@ietf.org; Thu, 06 Apr 2006 08:52:20 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2006 08:52:20 -0400 X-IronPort-AV: i="4.04,93,1144036800"; d="scan'208,217"; a="85855309:sNHT56985632" 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 k36CqJWc028200; Thu, 6 Apr 2006 08:52:19 -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); Thu, 6 Apr 2006 08:52:19 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 08:52:18 -0400 In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> References: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Message-Id: From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPS ID. Date: Thu, 6 Apr 2006 08:51:43 -0400 To: Rich Bradford ((rbradfor)) X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 06 Apr 2006 12:52:18.0233 (UTC) FILETIME=[EFE4BA90:01C65978] X-Spam-Score: 0.1 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: ccamp@ops.ietf.org, 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="===============0549359990==" Errors-To: pce-bounces@lists.ietf.org --===============0549359990== Content-Type: multipart/alternative; boundary=Apple-Mail-121-664462459 --Apple-Mail-121-664462459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Thanks for the summary Rich. PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution, (2) You would prefer one solution (which one and why ?) (3) You think that there is a need for both Thanks. JP. On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > > > > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > > > > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > > > > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-121-664462459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Thanks for the summary = Rich.

PCE WG = members: thanks to provide your feedback on whether:

(1) You = think that there is a need for such solution,

(2) You = would prefer one solution (which one and why ?)

(3) You = think that there is a need for both

Thanks.

JP.

On Apr 5, 2006, = at 6:19 PM, Rich Bradford ((rbradfor)) wrote:

=
Hi,
As = suggested in Dallas, I=92ve described some of the = tradeoffs between the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.=
-- = Rich
=A0
The Confidential Path Segment (CPS) ID provides two very = different but equally valid solutions, the Path Key Subobject (PKS) = solution and the Private Route Subobject (PRS) solution. This note = examines a number of the advantages and disadvantages of each solution. =
=A0
In = short: The PKS solution allows a PCE to hide the CPS for an AS by saving = it in a database and replacing it with a key in the ERO. During the LSP = setup, the ingress LSR for that AS must query the PCE for an = expansion.
The PRS solution allows a CPS for an AS to be hidden by = encrypting it, which may be done by a PCE or by the Head-End LSR. During = the LSP setup, the ingress LSR for that AS must use a decryption key to = obtain the expansion (implying an earlier exchange or configuration). =
=A0
The major differences between the mechanisms involve (1) = additional control messages, (2) performance issues expanding those = objects, (3) the addition of state to the PCE, (4) the solution scope = (i.e. applicability to various topologies of each solution.), and (5) = the size of objects added to existing = messages.
=A0
(1) Additional Control Message = Overhead:
The PKS solution requires a mechanism to expand the Path Key = upon receipt of the LSP setup request. Since the PCE which calculated = the Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS = solution.
=A0
=A0
(2) PCE and LSR Performance:
The PKS solution must maintain a (temporary) = database of keys adding overhead to the PCE. The PRS solution requires = the encryption of the CPS in the PCE and decryption of the CPS in the = LSR, which could be CPU intensive. Note that in case of a burst of = requests, encryption of large number of CPS may have an impact on the = PCE response time.
=A0
(3) Addition of State in the = PCE:
The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.
=A0
=A0
(4) Solution Scope:
The PKS and PRS solutions both work well in = conjunction with a PCE to encode and decode the CPS. However the PKS = provides no direct solution without a PCE. This prevents the PKS = solution for working in the case where A's network straddles B's network = and where A wants to use an ERO for a segment of the LSP across the = intervening network, e.g. (netA)-(netB)-(netA). In addition, the PRS = could be used to record a CPS even if the path (and therefore the = returned RRO) crosses multiple boundaries. Finally, a PRS solution could = be adapted to return actual failure locations in PERRs and/or PATHTEARs, = while keeping the failure location confidential from LSRs without a = decryption key. Currently privacy of this source is maintained by = returning the address of border nodes, which can be very = misleading.
=A0
(5) Message Object Overhead:
The PKS solution provides a very compact key = or token to identify a path segment, which generally allows for smaller = EROs to be returned by the PCE and to be requested in the resulting PATH = message. A PRS which contains a CPS must generally be at least as large = as the unencrypted PATH through the AS and may be significantly larger = if it is desirable to hide the number of hops within the network from = external view by padding the PRS. The result is potentially larger PATH = (and PCEP) messages for the PRS solution.
=A0
=A0
Please note that the tradeoffs listed here = are for the current I-D. Some of the shortcomings of each approach could = be mitigated by implementation-specific optimizations. For example, a = PCE could choose to signal the CPS expansion to the entry boundary LSR, = shifting the burden of maintaining the PKS state to the LSR and = eliminating the performance hit during LSP setup. A similar exchange = could be performed for the PRS case, eliminating the need for a separate = key exchange. These examples of extensions are beyond the scope of the = ID, but might be useful when weighing the pros and cons of the two = solutions.
=A0
=A0

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

= --Apple-Mail-121-664462459-- --===============0549359990== 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 --===============0549359990==-- From pce-bounces@lists.ietf.org Fri Apr 14 12:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQmK-00011f-Al; Fri, 14 Apr 2006 12:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUQmI-0000w0-Gd for pce@ietf.org; Fri, 14 Apr 2006 12:04:10 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUQmH-0006ih-9A for pce@ietf.org; Fri, 14 Apr 2006 12:04:10 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Apr 2006 09:04:09 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,121,1144047600"; d="scan'208"; a="25918535:sNHT19959112" 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 k3EG48TL017423; Fri, 14 Apr 2006 12:04:08 -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); Fri, 14 Apr 2006 12:04:08 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Apr 2006 12:04:08 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6EB0674B-3725-4863-ADC2-22C2CE5EE468@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Fri, 14 Apr 2006 12:04:04 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 14 Apr 2006 16:04:08.0237 (UTC) FILETIME=[0FB1F5D0:01C65FDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Pce] Final PCE WG Minutes - IETF 65 have been uploaded X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, You can find IETF-65 PCE WG minutes at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Apr 14 18:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWL3-0001PJ-CQ; Fri, 14 Apr 2006 18:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWL2-0001P9-3y for pce@ietf.org; Fri, 14 Apr 2006 18:00:24 -0400 Received: from mail2.noc.data.net.uk ([80.68.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUWL1-00029m-Hd for pce@ietf.org; Fri, 14 Apr 2006 18:00:24 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FUWKw-0003Eg-00 for pce@ietf.org; Fri, 14 Apr 2006 23:00:18 +0100 Received: from Puppy ([217.158.132.56] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 23:00:55 +0100 Message-ID: <154901c6600e$e08837b0$bf849ed9@Puppy> From: "Adrian Farrel" To: Date: Fri, 14 Apr 2006 23:00:19 +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-OriginalArrivalTime: 14 Apr 2006 22:00:56.0000 (UTC) FILETIME=[E7B75C00:01C6600E] X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Pce] Proposed Response to the OIF X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, We received a communication from the OIF way back in February (copy at the end of this email). After much discussion with the IAB on the issue we think it would be premature to establish a formal process for exchange of information. Our logic is that we do not yet have a protocol specification that is close to being ready for consideration for interoperability testing. However, we do recognise the benefit of exchanging ideas with participants in the OIF and want to share our progress with them. Therefore, I am proposing the following reply. Please let me know your opinions. Thanks, Adrian ===== To: Jim Jones, OIF TC Chair From: Adrian Farrel and JP Vasseur, IETF PCE Co-Chairs Cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Subject: Your communication about closer ties with the PCE Working Group Dear Jim, Thank you for your interest in the work of the PCE working group and for expressing an interest in cooperation between your Forum and the working group. The PCE working group is still at a relatively early stage, and while it has specified an architecture and some protocol requirements its protocols are as yet immature. We feel, therefore, that it would be premature to instigate a liaison relationship to develop interoperable products and services. However, we would very much appreciate the opinions of all participants in the OIF with regard to our work. The latest versions of our Internet-Drafts can be found at the PCE working group charter page http://www.ietf.org/html.charters/pce-charter.html and can be downloaded without charge simply by clicking on the links. Opinions and questions on the work are welcomed on the PCE mailing list. The mailing list is open to everyone without charge or membership requirements. Instructions for signing up to the mailing list can be found on the charter page. Best regards, Adrian Farrel and JP Vasseur IETF PCE Working Group Co-Chairs > ====== > > To: Adrian Farrel and J.P. Vasseur, IETF PCE WG Co-Chairs > From: Jim Jones, OIF TC Chair > Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors > Subject: Proposal to establish a liaison to IETF PCE WG > > Dear Adrian and JP, > > The OIF is interested in initiating a cooperative liaison with the PCE WG, > WG in the spirit of fostering cooperation for achieving interoperability > of intelligent optical networks. > > The mission of the Optical Internetworking Forum (OIF) is to foster the > development and deployment of interoperable products and services for > data switching and routing using optical networking technologies. > > To date OIF has had issued Interoperability Agreements (IAs) in the > areas of physical link layer interoperability and network control plane > interoperability. OIF has also been successful with multiple > interoperability demonstrations using OIF IAs and ITU-T > Recommendations as the basis for the interoperability demonstrations. > > We would like to propose that Richard Bradford of Cisco act as liaison > between the two organizations. > > Best regards, > Jim Jones > OIF Technical Committee Chair _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Fri Apr 14 18:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUX7E-00077Y-28; Fri, 14 Apr 2006 18:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUX75-00076K-KI; Fri, 14 Apr 2006 18:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUX75-0003YM-AO; Fri, 14 Apr 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3EMo29W021299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Apr 2006 22:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FUX74-0005Ob-2y; Fri, 14 Apr 2006 18:50:02 -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: Fri, 14 Apr 2006 18:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-architecture-05.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : A Path Computation Element (PCE) Based Architecture Author(s) : A. Farrel, et al. Filename : draft-ietf-pce-architecture-05.txt Pages : 37 Date : 2006-4-14 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-architecture-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-architecture-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-14152651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-architecture-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-architecture-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-14152651.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 Mon Apr 17 11:21:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVXw-0001dJ-Fe; Mon, 17 Apr 2006 11:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVVXu-0001d8-N8 for pce@ietf.org; Mon, 17 Apr 2006 11:21:46 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVVXt-0003aS-Dt for pce@ietf.org; Mon, 17 Apr 2006 11:21:46 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-3.cisco.com with ESMTP; 17 Apr 2006 08:21:45 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3HFLhw5004403; Mon, 17 Apr 2006 08:21:44 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 11:21:43 -0400 Received: from [161.44.71.244] ([161.44.71.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Apr 2006 11:21:43 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Date: Mon, 17 Apr 2006 11:21:42 -0400 To: pce@ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 17 Apr 2006 15:21:43.0553 (UTC) FILETIME=[A22F3F10:01C66232] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear WG, As you know, we already have a WG ID for the Inter-layer requirements (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it was discussed to convert the Inter-layer applicability ID into an inter-layer framework ID, which has now been posted: draft-oki-pce- inter-layer-frwk-00.txt. Could you please voice on opinion on adopting draft-oki-pce-inter- layer-frwk-00.txt as a PCE WG document ? Thanks. JP. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 17 13:18:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXN9-0003Dn-AC; Mon, 17 Apr 2006 13:18:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXN7-0003Di-Oi for pce@ietf.org; Mon, 17 Apr 2006 13:18:45 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVXN5-0001Uy-EM for pce@ietf.org; Mon, 17 Apr 2006 13:18:45 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k3HHIgeG015855; Mon, 17 Apr 2006 13:18:42 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28469; Mon, 17 Apr 2006 13:18:41 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Mon, 17 Apr 2006 13:18:40 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0DDAF29C@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: JP Vasseur Subject: RE: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.t xt as a new PCE WG document ? Date: Mon, 17 Apr 2006 13:18:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Dear JP, :-) I support this work as a working group document. The ideas are good, relevant and the document shows a good start in the right direction for a PCE WG document. The work relates to the text in the third paragraph of the existing charter and the first Work Item. The first Work Item may need to be explicitly expanded to include the inter-layer work as well as inter-area and inter-AS. -- Eric Gray --> -----Original Message----- --> From: JP Vasseur [mailto:jvasseur@cisco.com] --> Sent: Monday, April 17, 2006 11:22 AM --> To: pce@ietf.org --> Subject: [Pce] opinion on adopting --> draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? --> --> Dear WG, --> --> As you know, we already have a WG ID for the Inter-layer --> requirements --> (draft-ietf-pce-inter-layer-req-01.txt). During the last WG --> meeting, --> it was discussed to convert the Inter-layer applicability --> ID into an --> inter-layer framework ID, which has now been posted: --> [http://www.ietf.org/internet-drafts/draft-oki-pce-inter-layer-frwk-00.txt] --> --> Could you please voice on opinion on adopting [this draft] as a --> PCE WG document ? --> --> Thanks. --> --> JP. --> --> _______________________________________________ --> Pce mailing list --> Pce@lists.ietf.org --> https://www1.ietf.org/mailman/listinfo/pce --> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 17 13:52:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXtX-0003Op-GI; Mon, 17 Apr 2006 13:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVXtW-0003Ok-9z for pce@ietf.org; Mon, 17 Apr 2006 13:52:14 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVXtU-00042n-W7 for pce@ietf.org; Mon, 17 Apr 2006 13:52:14 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1145296301!10448548!16 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 26519 invoked from network); 17 Apr 2006 17:52:11 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-120.messagelabs.com with SMTP; 17 Apr 2006 17:52:11 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE002D4FF6; Mon, 17 Apr 2006 13:52:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Date: Mon, 17 Apr 2006 12:52:10 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC764E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Thread-Index: AcZiMq4aXVQuzqziRg2E4rCv70GzLwAFItzw From: "Ash, Gerald R $Jerry$, ALABS" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org > Could you please voice on opinion on adopting draft-oki-pce-inter-=20 > layer-frwk-00.txt as a PCE WG document? Support. IMO some of the informative references should be normative (pce-arch, etc.)? Thanks, Jerry _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 17 18:31:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcFz-0007Df-OY; Mon, 17 Apr 2006 18:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcFy-0007Da-MM for pce@ietf.org; Mon, 17 Apr 2006 18:31:42 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcFx-00015e-CT for pce@ietf.org; Mon, 17 Apr 2006 18:31:42 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k3HMVe1Z047683; Mon, 17 Apr 2006 15:31:40 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k3HMVe507791; Mon, 17 Apr 2006 15:31:40 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Mon, 17 Apr 2006 15:31:40 -0700 (PDT) From: Arthi Ayyangar To: JP Vasseur Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> Message-ID: <20060417152916.B80665@zircon.juniper.net> References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org > As you know, we already have a WG ID for the Inter-layer requirements > (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it was > discussed to convert the Inter-layer applicability ID into an inter-layer > framework ID, which has now been posted: draft-oki-pce- > inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? ------> I support adopting this document as a WG document. -arthi _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 18 03:13:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkOj-0005KP-Kg; Tue, 18 Apr 2006 03:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkOh-0005KK-SS for pce@ietf.org; Tue, 18 Apr 2006 03:13:15 -0400 Received: from gw.imc.kth.se ([193.10.152.67] helo=oberon.imc.kth.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVkOg-0001Sj-Dy for pce@ietf.org; Tue, 18 Apr 2006 03:13:15 -0400 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3I72tKb012911 for ; Tue, 18 Apr 2006 09:02:56 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Tue, 18 Apr 2006 09:11:59 +0200 Message-ID: <4444913E.6070207@pi.se> Date: Tue, 18 Apr 2006 09:11:58 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org yes this should be a wg doc /Loa JP Vasseur wrote: > Dear WG, > > As you know, we already have a WG ID for the Inter-layer requirements > (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it > was discussed to convert the Inter-layer applicability ID into an > inter-layer framework ID, which has now been posted: draft-oki-pce- > inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 18 03:35:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkjw-0002Ac-4c; Tue, 18 Apr 2006 03:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVkju-000296-LR for pce@ietf.org; Tue, 18 Apr 2006 03:35:10 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVkap-0002cQ-Mt for pce@ietf.org; Tue, 18 Apr 2006 03:25:49 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3I7PgvD003271 for ; Tue, 18 Apr 2006 16:25:42 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3I7Pfa3000456 for ; Tue, 18 Apr 2006 16:25:41 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3I7Pewp004826 for ; Tue, 18 Apr 2006 16:25:40 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3I7PeIV014289 for ; Tue, 18 Apr 2006 16:25:40 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3I7PdPl013092 for ; Tue, 18 Apr 2006 16:25:39 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3I7Pdxr013089 for ; Tue, 18 Apr 2006 16:25:39 +0900 (JST) Received: from INOUE-LETS-CFW2.lab.ntt.co.jp ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k3I7Pcvg001963 for ; Tue, 18 Apr 2006 16:25:39 +0900 (JST) Message-Id: <6.0.0.20.2.20060418161516.05daba00@imb.m.ecl.ntt.co.jp> X-Sender: ii004@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 18 Apr 2006 16:16:42 +0900 To: pce@ietf.org From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? In-Reply-To: <4444913E.6070207@pi.se> References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> <4444913E.6070207@pi.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, I support adopting this. Ichiro >> Dear WG, >> As you know, we already have a WG ID for the Inter-layer requirements >> (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it was discussed to convert the Inter-layer applicability ID into an >> inter-layer framework ID, which has now been posted: draft-oki-pce- inter-layer-frwk-00.txt. >> Could you please voice on opinion on adopting draft-oki-pce-inter- layer-frwk-00.txt as a PCE WG document ? >> Thanks. >> JP. >> _______________________________________________ >> Pce mailing list >> Pce@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 18 04:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlWE-0007VD-UP; Tue, 18 Apr 2006 04:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlWD-0007V8-BI for pce@ietf.org; Tue, 18 Apr 2006 04:25:05 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVlW7-0007Hs-KN for pce@ietf.org; Tue, 18 Apr 2006 04:25:05 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXW00LZ5T1HIC@szxga03-in.huawei.com> for pce@ietf.org; Tue, 18 Apr 2006 16:32:05 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IXW00AIET1GM9@szxga03-in.huawei.com> for pce@ietf.org; Tue, 18 Apr 2006 16:32:05 +0800 (CST) Received: from z18605 ([10.110.114.158]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IXW00LKYTBD3N@szxml02-in.huawei.com> for pce@ietf.org; Tue, 18 Apr 2006 16:38:01 +0800 (CST) Date: Tue, 18 Apr 2006 15:55:48 +0800 From: Zhang Renhai Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? To: pce@ietf.org Message-id: <002e01c662bd$818ed3c0$9e726e0a@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 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org I support this to be a WG doc. Thanks, Zhang ----- Original Message ----- From: "JP Vasseur" To: Sent: Monday, April 17, 2006 11:21 PM Subject: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? > > Dear WG, > > As you know, we already have a WG ID for the Inter-layer requirements > (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, > it was discussed to convert the Inter-layer applicability ID into an > inter-layer framework ID, which has now been posted: draft-oki-pce- > inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Tue Apr 18 09:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVq8h-0006yL-7v; Tue, 18 Apr 2006 09:21:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVq8f-0006yG-TA for pce@ietf.org; Tue, 18 Apr 2006 09:21:05 -0400 Received: from ns1.cpanel.btnaccess.com ([205.177.121.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVq8e-0006to-Lq for pce@ietf.org; Tue, 18 Apr 2006 09:21:05 -0400 Received: from [65.213.193.47] (helo=Isovaio08) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.52) id 1FVq8d-0007U8-SP; Tue, 18 Apr 2006 09:21:03 -0400 From: "Rajiv Papneja" To: "'JP Vasseur'" , Subject: RE: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Date: Tue, 18 Apr 2006 09:21:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> Thread-Index: AcZiMqyV8yFHLfmZTTuPvdlWqL4N5gAuCQiA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Message-Id: > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: Monday, April 17, 2006 11:22 AM > To: pce@ietf.org > Subject: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt > asa new PCE WG document ? > > Dear WG, > > As you know, we already have a WG ID for the Inter-layer requirements > (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, > it was discussed to convert the Inter-layer applicability ID into an > inter-layer framework ID, which has now been posted: draft-oki-pce- > inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? [rp] [rp] I support this being as a WG document. /Rajiv > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Apr 19 08:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBqM-0001Je-E8; Wed, 19 Apr 2006 08:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBqL-0001JZ-Uh for pce@ietf.org; Wed, 19 Apr 2006 08:31:37 -0400 Received: from smail3.alcatel.fr ([64.208.49.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWBqK-0000M3-IU for pce@ietf.org; Wed, 19 Apr 2006 08:31:37 -0400 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k3JCVZc4008651 for ; Wed, 19 Apr 2006 14:31:35 +0200 Received: from [172.25.80.62] ([172.25.80.62]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006041914313410:3891 ; Wed, 19 Apr 2006 14:31:34 +0200 Message-ID: <44462DA5.8000803@alcatel.fr> Date: Wed, 19 Apr 2006 13:31:33 +0100 From: Richard.Douville@alcatel.fr Organization: Alcatel User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pce@ietf.org Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/19/2006 14:31:34, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/19/2006 14:31:35, Serialize complete at 04/19/2006 14:31:35 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org I support the draft to be a WG doc. Thanks, Richard D. JP Vasseur wrote: > Dear WG, > > As you know, we already have a WG ID for the Inter-layer requirements > (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it > was discussed to convert the Inter-layer applicability ID into an > inter-layer framework ID, which has now been posted: draft-oki-pce- > inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > -- Richard Douville Alcatel Research & Innovation Center System and Architecture of Transport Networks, SART Route de Nozay F-91460 Marcoussis, France. Phone : 33 1.69.63.44.31 Fax : 33 1.69.63.18.65 Email : Richard.Douville@alcatel.fr _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Apr 19 10:12:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDQ2-0007zw-CB; Wed, 19 Apr 2006 10:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWDQ1-0007zr-0u for pce@ietf.org; Wed, 19 Apr 2006 10:12:33 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWDPx-0005eK-5v for pce@ietf.org; Wed, 19 Apr 2006 10:12:32 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2006 07:12:28 -0700 X-IronPort-AV: i="4.04,135,1144047600"; d="scan'208,217"; a="269699828:sNHT54355860" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3JECOVM014093 for ; Wed, 19 Apr 2006 07:12:28 -0700 (PDT) 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); Wed, 19 Apr 2006 10:12:27 -0400 Received: from [161.44.71.244] ([161.44.71.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 10:12:27 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) To: pce@ietf.org Message-Id: References: From: JP Vasseur Date: Wed, 19 Apr 2006 10:12:26 -0400 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 19 Apr 2006 14:12:27.0488 (UTC) FILETIME=[49CD8E00:01C663BB] X-Spam-Score: 0.8 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: Subject: [Pce] Fwd: IESG Statement: Normative and Informative References 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="===============1885267652==" Errors-To: pce-bounces@lists.ietf.org --===============1885267652== Content-Type: multipart/alternative; boundary=Apple-Mail-25--354978160 --Apple-Mail-25--354978160 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: IESG Secretary > Date: April 19, 2006 9:50:00 AM EDT > To: IETF Announcement list > Subject: IESG Statement: Normative and Informative References > > Normative and Informative References > > Nearly all RFCs contain citations to other documents, and these are > listed in a References section near the end of the RFC. There are many > styles for references, and the RFCs have one of their own. Please > follow the reference style used in recent RFCs. Please note that for > documents that have been assigned an STD or BCP number, the number > must > be included in the reference. > > Within an RFC, references to other documents fall into two general > categories: "normative" and "informative". Normative references > specify > documents that must be read to understand or implement the technology > in the new RFC, or whose technology must be present for the technology > in the new RFC to work. An informative reference is not normative; > rather, it only provides additional information. For example, an > informative reference might provide background or historical > information. Informative references are not required to implement the > technology in the RFC. > > Note 1: Even references that are relevant only for optional features > must be classified as normative if they meet the above conditions for > normative references. > > Note 2: It is not considered necessary to cite basic specifications > that may be safely assumed to be known to practitioners (for example, > RFC 791 need not be cited in every specification that mentions IPv4). > > Note 3: The normative/informative distinction is relevant in > any document that amounts to a technical specification, even > if its intended status is Experimental or Informational. > > Note 4: Normative references in RFCs cannot be to "work in progress" > documents such as Internet Drafts. Drafts with such references will > not be published as RFCs until the references are also published. > > The distinction between normative and informative references is often > important. The IETF standards process according to RFC 2026 and RFC > 3967, > and the RFC Editor publication process, both need to know whether a > reference to a work in progress is normative. An RFC cannot be > published > until all of the documents that it lists as normative references > have been > published. In practice, this often results in the simultaneous > publication > of a group of interrelated RFCs. > > For these reasons, the IESG and the RFC Editor have established > guidelines that will request separate reference lists for normative > and informative references in Internet Drafts and RFCs. For example, > if both types are present, there would be two reference subsections, > numbered s.1 and s.2 for example: > > s.1. Normative References > > xxx > ... > xxx > > s.2. Informative References > > xxx > ... > xxx > > Of course, if there is only one type of reference, only one > section is needed. > > The IESG > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail-25--354978160 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Date: April 19, 2006 9:50:00 AM = EDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: IESG Statement: Normative and = Informative References=A0

Nearly all = RFCs contain citations to other documents, and these are
listed in a References section near the end of the = RFC. There are many
styles for references, and = the RFCs have one of their own. Please
follow = the reference style used in recent RFCs. Please note that for
documents that have been assigned an STD or BCP = number, the number must
be included = in the reference.

Within an RFC, references to other documents fall = into two general
categories: "normative" and = "informative". Normative references specify
in the new RFC, or whose = technology must be present for the technology
in the new RFC to work. An informative reference is = not normative;
rather, it only provides = additional information. For example, an
information. Informative references are not required = to implement the
technology in the RFC.

Note 1: = Even references that are relevant only for optional features
must be classified as normative if they meet the = above conditions for
normative = references.

Note 2: It is not considered necessary to cite basic = specifications
that may be safely assumed to be = known to practitioners (for example,
RFC 791 need = not be cited in every specification that mentions IPv4).

Note 3: = The normative/informative distinction is relevant in
any document that amounts to a technical = specification, even
if its intended status is = Experimental or Informational.

Note 4: Normative references in = RFCs cannot be to "work in progress"
documents = such as Internet Drafts. Drafts with such references will
not be published as RFCs until the references are = also published.

The distinction between normative and informative = references is often
important. The IETF = standards process according to RFC 2026 and RFC 3967,
and the RFC Editor publication process, both need to = know whether a
reference to a work in progress = is normative. An RFC cannot be published
until = all of the documents that it lists as normative references have = been
published. In practice, this = often results in the simultaneous publication
of a group of interrelated RFCs.

For = these reasons, the IESG and the RFC Editor have established
guidelines that will request separate reference = lists for normative
and informative references = in Internet Drafts and RFCs. For example,
if both = types are present, there would be two reference subsections,
numbered s.1 and s.2 for example:

s.1. = Normative References
xxx
xxx

s.2. = Informative References
xxx
xxx

Of course, if = there is only one type of reference, only one
section is needed.

The = IESG

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

=
= --Apple-Mail-25--354978160-- --===============1885267652== 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 --===============1885267652==-- From pce-bounces@lists.ietf.org Wed Apr 19 20:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWMuz-0003oO-4y; Wed, 19 Apr 2006 20:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWMux-0003nz-7e for pce@ietf.org; Wed, 19 Apr 2006 20:21:07 -0400 Received: from mail1.noc.data.net.uk ([80.68.34.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWMuw-00018n-Ic for pce@ietf.org; Wed, 19 Apr 2006 20:21:07 -0400 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FWMvK-0008Pm-00 for pce@ietf.org; Thu, 20 Apr 2006 01:21:30 +0100 Received: from Puppy ([125.200.105.80] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 01:21:34 +0100 Message-ID: <064c01c66410$56b51480$2101fe0a@Puppy> From: "Adrian Farrel" To: Date: Thu, 20 Apr 2006 01:18:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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-OriginalArrivalTime: 20 Apr 2006 00:21:34.0421 (UTC) FILETIME=[6178F850:01C66410] X-Spam-Score: 0.6 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [Pce] Fw: IESG Statement: Normative and Informative References X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Hi, Good advice from the IESG on how to classify your references in I-Ds. Adrian ----- Original Message ----- From: "IESG Secretary" To: "IETF Announcement list" Sent: Wednesday, April 19, 2006 2:50 PM Subject: IESG Statement: Normative and Informative References > Normative and Informative References > > Nearly all RFCs contain citations to other documents, and these are > listed in a References section near the end of the RFC. There are many > styles for references, and the RFCs have one of their own. Please > follow the reference style used in recent RFCs. Please note that for > documents that have been assigned an STD or BCP number, the number must > be included in the reference. > > Within an RFC, references to other documents fall into two general > categories: "normative" and "informative". Normative references specify > documents that must be read to understand or implement the technology > in the new RFC, or whose technology must be present for the technology > in the new RFC to work. An informative reference is not normative; > rather, it only provides additional information. For example, an > informative reference might provide background or historical > information. Informative references are not required to implement the > technology in the RFC. > > Note 1: Even references that are relevant only for optional features > must be classified as normative if they meet the above conditions for > normative references. > > Note 2: It is not considered necessary to cite basic specifications > that may be safely assumed to be known to practitioners (for example, > RFC 791 need not be cited in every specification that mentions IPv4). > > Note 3: The normative/informative distinction is relevant in > any document that amounts to a technical specification, even > if its intended status is Experimental or Informational. > > Note 4: Normative references in RFCs cannot be to "work in progress" > documents such as Internet Drafts. Drafts with such references will > not be published as RFCs until the references are also published. > > The distinction between normative and informative references is often > important. The IETF standards process according to RFC 2026 and RFC 3967, > and the RFC Editor publication process, both need to know whether a > reference to a work in progress is normative. An RFC cannot be published > until all of the documents that it lists as normative references have been > published. In practice, this often results in the simultaneous publication > of a group of interrelated RFCs. > > For these reasons, the IESG and the RFC Editor have established > guidelines that will request separate reference lists for normative > and informative references in Internet Drafts and RFCs. For example, > if both types are present, there would be two reference subsections, > numbered s.1 and s.2 for example: > > s.1. Normative References > > xxx > ... > xxx > > s.2. Informative References > > xxx > ... > xxx > > Of course, if there is only one type of reference, only one > section is needed. > > The IESG > > _______________________________________________ > 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 Wed Apr 19 23:06:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPUk-00088U-DI; Wed, 19 Apr 2006 23:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPUj-00088K-2m for pce@ietf.org; Wed, 19 Apr 2006 23:06:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWNnV-0004Cl-Fa for pce@ietf.org; Wed, 19 Apr 2006 21:17:29 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWNWD-0002z8-DI for pce@ietf.org; Wed, 19 Apr 2006 20:59:41 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K0xGBH004074; Thu, 20 Apr 2006 09:59:16 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K0xFpm020355; Thu, 20 Apr 2006 09:59:15 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K0xFgZ000790; Thu, 20 Apr 2006 09:59:15 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K0xFEu010617; Thu, 20 Apr 2006 09:59:15 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3K0xEYW008560; Thu, 20 Apr 2006 09:59:14 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf.m.ecl.ntt.co.jp [129.60.5.230]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3K0xEJ2008557; Thu, 20 Apr 2006 09:59:14 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp ([129.60.80.92]) by imf.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k3K0xB7k028094; Thu, 20 Apr 2006 09:59:11 +0900 (JST) Message-Id: <5.1.1.9.2.20060420095926.06c37c38@imf.m.ecl.ntt.co.jp> X-Sender: tt043@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Thu, 20 Apr 2006 10:00:01 +0900 To: JP Vasseur , pce@ietf.org From: Tomonori TAKEDA Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Yes Tomonori At 11:21 06/04/17 -0400, JP Vasseur wrote: >Dear WG, > >As you know, we already have a WG ID for the Inter-layer requirements >(draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, >it was discussed to convert the Inter-layer applicability ID into an >inter-layer framework ID, which has now been posted: draft-oki-pce- >inter-layer-frwk-00.txt. > >Could you please voice on opinion on adopting draft-oki-pce-inter- >layer-frwk-00.txt as a PCE WG document ? > >Thanks. > >JP. > >_______________________________________________ >Pce mailing list >Pce@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Wed Apr 19 23:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPcZ-0004qk-Ed; Wed, 19 Apr 2006 23:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWPcY-0004qf-3q for pce@ietf.org; Wed, 19 Apr 2006 23:14:18 -0400 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWPcW-0002Gf-8a for pce@ietf.org; Wed, 19 Apr 2006 23:14:18 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K3EDVH024625; Thu, 20 Apr 2006 12:14:13 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K3EC7Y016003; Thu, 20 Apr 2006 12:14:12 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K3EBbH023624; Thu, 20 Apr 2006 12:14:11 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k3K3EBHA002980; Thu, 20 Apr 2006 12:14:11 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3K3EAt5025358; Thu, 20 Apr 2006 12:14:10 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k3K3EAFB025355; Thu, 20 Apr 2006 12:14:10 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.125]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k3K3E8YX024395; Thu, 20 Apr 2006 12:14:10 +0900 (JST) Message-ID: <4446FC80.8060204@lab.ntt.co.jp> Date: Thu, 20 Apr 2006 12:14:08 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: JP Vasseur Subject: Re: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> In-Reply-To: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: pce@ietf.org X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Yes. I support adopting draft-oki-pce-inter-layer-frwk-00.txt as a PCE WG document. -- Kohei Shiomoto NTT Network Service Systems Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Phone +81 422 59 4402 Fax +81 422 59 3787 JP Vasseur wrote: > Dear WG, > > As you know, we already have a WG ID for the Inter-layer requirements > (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it > was discussed to convert the Inter-layer applicability ID into an > inter-layer framework ID, which has now been posted: draft-oki-pce- > inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce > > _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Apr 20 00:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWQlW-00077W-P2; Thu, 20 Apr 2006 00:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWQlV-00077R-Jk for pce@ietf.org; Thu, 20 Apr 2006 00:27:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWQlU-0005eH-85 for pce@ietf.org; Thu, 20 Apr 2006 00:27:37 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 Apr 2006 21:27:36 -0700 X-IronPort-AV: i="4.04,137,1144047600"; d="scan'208"; a="269968835:sNHT29951172" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3K4RZh0015747 for ; Wed, 19 Apr 2006 21:27:35 -0700 (PDT) Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 19 Apr 2006 21:27:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Date: Wed, 19 Apr 2006 21:27:34 -0700 Message-ID: <70BC84B185C3EE448EDB7AB8956D3B0E0196E4BD@xmb-sjc-234.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Thread-Index: AcZiMqtpdvw6LC2BRVujWS2WuOlIHgB//QtA From: "Dean Cheng $dcheng$" To: "Jean Philippe Vasseur $jvasseur$" , X-OriginalArrivalTime: 20 Apr 2006 04:27:35.0436 (UTC) FILETIME=[BFB91CC0:01C66432] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org Yes it should be a WG document. Dean=20 > -----Original Message----- > From: Jean Philippe Vasseur (jvasseur)=20 > Sent: Monday, April 17, 2006 8:22 AM > To: pce@ietf.org > Subject: [Pce] opinion on adopting=20 > draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? >=20 > Dear WG, >=20 > As you know, we already have a WG ID for the Inter-layer=20 > requirements (draft-ietf-pce-inter-layer-req-01.txt). During=20 > the last WG meeting, it was discussed to convert the=20 > Inter-layer applicability ID into an inter-layer framework=20 > ID, which has now been posted: draft-oki-pce- inter-layer-frwk-00.txt. >=20 > Could you please voice on opinion on adopting=20 > draft-oki-pce-inter- layer-frwk-00.txt as a PCE WG document ? >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Thu Apr 20 16:32:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfp8-0001QC-L9; Thu, 20 Apr 2006 16:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWfp7-0001OT-FD for pce@ietf.org; Thu, 20 Apr 2006 16:32:21 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWfp7-0004it-2M for pce@ietf.org; Thu, 20 Apr 2006 16:32:21 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2006 13:32:21 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,141,1144047600"; d="scan'208,217"; a="26325785:sNHT40744388" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3KKWKvF001516 for ; Thu, 20 Apr 2006 16:32:20 -0400 (EDT) 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, 20 Apr 2006 16:32:20 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 16:32:20 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) To: pce@ietf.org Message-Id: References: <5C916970-C572-456A-9061-93D5FD5F5343@cisco.com> From: JP Vasseur Subject: Fwd: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document ? Date: Thu, 20 Apr 2006 16:32:18 -0400 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 20 Apr 2006 20:32:20.0097 (UTC) FILETIME=[85AB6F10:01C664B9] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1695909064==" Errors-To: pce-bounces@lists.ietf.org --===============1695909064== Content-Type: multipart/alternative; boundary=Apple-Mail-13--245785854 --Apple-Mail-13--245785854 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, Considering the support for this ID to become a WG doc, please author thanks to post as WG document. JP. Begin forwarded message: > From: JP Vasseur > Date: April 17, 2006 11:21:42 AM EDT > To: pce@ietf.org > Subject: [Pce] opinion on adopting draft-oki-pce-inter-layer- > frwk-00.txt as a new PCE WG document ? > > Dear WG, > > As you know, we already have a WG ID for the Inter-layer > requirements (draft-ietf-pce-inter-layer-req-01.txt). During the > last WG meeting, it was discussed to convert the Inter-layer > applicability ID into an inter-layer framework ID, which has now > been posted: draft-oki-pce-inter-layer-frwk-00.txt. > > Could you please voice on opinion on adopting draft-oki-pce-inter- > layer-frwk-00.txt as a PCE WG document ? > > Thanks. > > JP. > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-13--245785854 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Hi,

Considering the support for = this ID to become a WG doc, please author thanks to post as WG = document.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = April 17, 2006 11:21:42 AM EDT
To: pce@ietf.org
Subject: = [Pce] opinion on adopting = draft-oki-pce-inter-layer-frwk-00.txt as a new PCE WG document = ?

=
Dear WG,

As you know, we already have a = WG ID for the Inter-layer requirements = (draft-ietf-pce-inter-layer-req-01.txt). During the last WG meeting, it = was discussed to convert the Inter-layer applicability ID into an = inter-layer framework ID, which has now been posted: = draft-oki-pce-inter-layer-frwk-00.txt.

Could you = please voice on opinion on adopting = draft-oki-pce-inter-layer-frwk-00.txt as a PCE WG document ?

JP.

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

= --Apple-Mail-13--245785854-- --===============1695909064== 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 --===============1695909064==-- From pce-bounces@lists.ietf.org Fri Apr 21 12:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyqm-00018I-DY; Fri, 21 Apr 2006 12:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWyql-00018D-Ul for pce@ietf.org; Fri, 21 Apr 2006 12:51:19 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWyqi-0001yw-WF for pce@ietf.org; Fri, 21 Apr 2006 12:51:19 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 18:51:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Fri, 21 Apr 2006 18:51:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5Ddwg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , "Rich Bradford" X-OriginalArrivalTime: 21 Apr 2006 16:51:08.0082 (UTC) FILETIME=[C9586920:01C66563] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ba8529e77affe49b0f315db98a262ee Cc: ccamp@ops.ietf.org, 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="===============0360857771==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0360857771== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66563.C8AC21C9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66563.C8AC21C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, Richard =20 Please see inline, ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 6 avril 2006 14:52 =C0 : Rich Bradford Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =09 =09 Hi,=20 Thanks for the summary Rich. PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution,=20 =20 Yes definitely, confidentiality is a key requirements in an = inter-provider context. =20 (2) You would prefer one solution (which one and why ?)=20 =20 (3) You think that there is a need for both=20 =20 Answer to (2) and (3): It seems to me that we should end-up with a single solution so as to = ease interworking. =09 IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be = loose anyway, so there will not be any confidentiality issue.=20 If have some concerns regarding the cost of encryption, particularly = for large paths (we need to think about future P2MP applications with a = large number of hops...). By the way, encryption approaches are really = vulnerable to DoS attacks. Hence I would strongly favor the PKS solution. The optimization = suggested, which consists of sending the computed path segment to the = LSR in an unsolicited manner, just after the computation, sounds = relevant and should be further investigated. =20 Best Regards, =20 JL =20 =20 =20 =09 =09 Thanks. JP. On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: Hi, As suggested in Dallas, I've described some of the tradeoffs between = the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt. -- Rich =09 The Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.=20 =09 In short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it in a database and replacing it with a key in the ERO. During = the LSP setup, the ingress LSR for that AS must query the PCE for an = expansion. The PRS solution allows a CPS for an AS to be hidden by encrypting it, = which may be done by a PCE or by the Head-End LSR. During the LSP setup, = the ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).=20 =09 The major differences between the mechanisms involve (1) additional = control messages, (2) performance issues expanding those objects, (3) = the addition of state to the PCE, (4) the solution scope (i.e. = applicability to various topologies of each solution.), and (5) the size = of objects added to existing messages. =09 (1) Additional Control Message Overhead: The PKS solution requires a mechanism to expand the Path Key upon = receipt of the LSP setup request. Since the PCE which calculated the = Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS solution. =09 =09 (2) PCE and LSR Performance: The PKS solution must maintain a (temporary) database of keys adding = overhead to the PCE. The PRS solution requires the encryption of the CPS = in the PCE and decryption of the CPS in the LSR, which could be CPU = intensive. Note that in case of a burst of requests, encryption of large = number of CPS may have an impact on the PCE response time. =09 (3) Addition of State in the PCE: The PKS solution requires the addition of path-specific state and = maintenance of a database in the PCE. The PRS solution requires no = additional state. =09 =09 (4) Solution Scope: The PKS and PRS solutions both work well in conjunction with a PCE to = encode and decode the CPS. However the PKS provides no direct solution = without a PCE. This prevents the PKS solution for working in the case = where A's network straddles B's network and where A wants to use an ERO = for a segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading. =09 (5) Message Object Overhead: The PKS solution provides a very compact key or token to identify a = path segment, which generally allows for smaller EROs to be returned by = the PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution. =09 =09 Please note that the tradeoffs listed here are for the current I-D. = Some of the shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two solutions. =09 =09 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C66563.C8AC21C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi JP, Richard

Please see inline,

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 6 avril = 2006=20 14:52
=C0 : Rich Bradford
Cc : = ccamp@ops.ietf.org;=20 pce@ietf.org
Objet : Re: [Pce] Comparison of Encryption = vs.=20 Path Key Solutions for the CPSID.

Hi,

Thanks for the summary Rich.

PCE WG members: thanks to provide your feedback on whether:

(1) You think=20 that there is a need for such solution,

Yes=20 definitely, confidentiality is a key requirements in an inter-provider = context.

(2) You would=20 prefer one solution (which one and why ?)

(3) You think=20 that there is a need for both

Answer to (2) and=20 (3):

It seems to me=20 that we should end-up with a single solution so as to ease=20 interworking.

IMO in an inter-AS MPLS-TE environment without PCEs, the = paths=20 will be loose anyway, so there will not be any = confidentiality=20 issue.

If have some=20 concerns regarding the cost of encryption, particularly for large = paths=20 (we need to think about future P2MP applications with a large number = of=20 hops...). By the way, encryption approaches are really vulnerable to = DoS=20 attacks.

Hence I would strongly favor the PKS solution. The = optimization=20 suggested, which consists of sending the computed path segment to = the LSR=20 in an unsolicited manner, just after the computation, sounds = relevant and=20 should be further investigated.

Best=20 Regards,

JL

Thanks.

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) = wrote:

Hi,

As suggested in Dallas, I=92ve described some of = the=20 tradeoffs between the two solutions described in=20 = draft-rbradfor-ccamp-confidential-segment-00.txt.

-- Rich

The Confidential Path Segment (CPS) ID = provides two=20 very different but equally valid solutions, the Path Key Subobject = (PKS)=20 solution and the Private Route Subobject (PRS) solution. This note = examines=20 a number of the advantages and disadvantages of each solution.=20

In short: The PKS solution allows a PCE to = hide the=20 CPS for an AS by saving it in a database and replacing it with a key = in the=20 ERO. During the LSP setup, the ingress LSR for that AS must query = the PCE=20 for an expansion.

The PRS solution allows a CPS for an AS to = be hidden=20 by encrypting it, which may be done by a PCE or by the Head-End LSR. = During=20 the LSP setup, the ingress LSR for that AS must use a decryption key = to=20 obtain the expansion (implying an earlier exchange or = configuration).=20

The major differences between the = mechanisms involve=20 (1) additional control messages, (2) performance issues expanding = those=20 objects, (3) the addition of state to the PCE, (4) the solution = scope (i.e.=20 applicability to various topologies of each solution.), and (5) the = size of=20 objects added to existing messages.

(1) Additional Control Message=20 Overhead:

The PKS solution requires a mechanism to = expand the=20 Path Key upon receipt of the LSP setup request. Since the PCE which=20 calculated the Path Key might not reside in the entry boundary LSR, = the LSR=20 must request the expansion from the PCE, requiring an additional = message=20 exchange before LSP setup can proceed. The Path Encryption solution = does not=20 require this extra exchange between the PCE and the ingress node for = every=20 LSP. Rather, the decryption key needs to be exchanged only when it = is=20 changed. The result is additional delay during every LSP setup for = the PKS=20 solution but no additional delay for the PRS=20 solution.

(2) PCE and LSR=20 Performance:

The PKS solution must maintain a = (temporary)=20 database of keys adding overhead to the PCE. The PRS solution = requires the=20 encryption of the CPS in the PCE and decryption of the CPS in the = LSR, which=20 could be CPU intensive. Note that in case of a burst of requests, = encryption=20 of large number of CPS may have an impact on the PCE response=20 time.

(3) Addition of State in the=20 PCE:

The PKS solution requires the addition of=20 path-specific state and maintenance of a database in the PCE. The = PRS=20 solution requires no additional state.

(4) Solution = Scope:

The PKS and PRS solutions both work well = in=20 conjunction with a PCE to encode and decode the CPS. However the PKS = provides no direct solution without a PCE. This prevents the PKS = solution=20 for working in the case where A's network straddles B's network and = where A=20 wants to use an ERO for a segment of the LSP across the intervening = network,=20 e.g. (netA)-(netB)-(netA). In addition, the PRS could be used to = record a=20 CPS even if the path (and therefore the returned RRO) crosses = multiple=20 boundaries. Finally, a PRS solution could be adapted to return = actual=20 failure locations in PERRs and/or PATHTEARs, while keeping the = failure=20 location confidential from LSRs without a decryption key. Currently = privacy=20 of this source is maintained by returning the address of border = nodes, which=20 can be very misleading.

(5) Message Object=20 Overhead:

The PKS solution provides a very compact = key or=20 token to identify a path segment, which generally allows for smaller = EROs to=20 be returned by the PCE and to be requested in the resulting PATH = message. A=20 PRS which contains a CPS must generally be at least as large as the=20 unencrypted PATH through the AS and may be significantly larger if = it is=20 desirable to hide the number of hops within the network from = external view=20 by padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note that the tradeoffs listed here = are for=20 the current I-D. Some of the shortcomings of each approach could be=20 mitigated by implementation-specific optimizations. For example, a = PCE could=20 choose to signal the CPS expansion to the entry boundary LSR, = shifting the=20 burden of maintaining the PKS state to the LSR and eliminating the=20 performance hit during LSP setup. A similar exchange could be = performed for=20 the PRS case, eliminating the need for a separate key exchange. = These=20 examples of extensions are beyond the scope of the ID, but might be = useful=20 when weighing the pros and cons of the two=20 solutions.

_______________________________________________

Pce mailing list

Pce@lists.ietf.org

https://www1.ietf.org= /mailman/listinfo/pce

= ------_=_NextPart_001_01C66563.C8AC21C9-- --===============0360857771== 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 --===============0360857771==-- From pce-bounces@lists.ietf.org Fri Apr 21 13:11:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWzA0-0006rl-4y; Fri, 21 Apr 2006 13:11:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWz9z-0006rg-2z for pce@ietf.org; Fri, 21 Apr 2006 13:11:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWz9x-0003WA-Ri for pce@ietf.org; Fri, 21 Apr 2006 13:11:11 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Apr 2006 10:11:10 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,145,1144047600"; d="scan'208"; a="26395231:sNHT22950472" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3LHB9vF018750 for ; Fri, 21 Apr 2006 13:11:09 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 13:11:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Date: Fri, 21 Apr 2006 13:11:08 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] opinion on adopting draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? Thread-Index: AcZiMqw3jnYS/xKJTkKpQk445skFVgDM9qqg From: "Zafar Ali $zali$" To: "Jean Philippe Vasseur $jvasseur$" , X-OriginalArrivalTime: 21 Apr 2006 17:11:09.0456 (UTC) FILETIME=[956B8900:01C66566] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org > -----Original Message----- > From: Jean Philippe Vasseur (jvasseur)=20 > Sent: Monday, April 17, 2006 11:22 AM > To: pce@ietf.org > Subject: [Pce] opinion on adopting=20 > draft-oki-pce-inter-layer-frwk-00.txt asa new PCE WG document ? >=20 > Dear WG, >=20 > As you know, we already have a WG ID for the Inter-layer=20 > requirements (draft-ietf-pce-inter-layer-req-01.txt). During=20 > the last WG meeting, it was discussed to convert the=20 > Inter-layer applicability ID into an inter-layer framework=20 > ID, which has now been posted: draft-oki-pce- inter-layer-frwk-00.txt. >=20 > Could you please voice on opinion on adopting=20 > draft-oki-pce-inter- layer-frwk-00.txt as a PCE WG document ? >=20 Yes,=20 Thanks Regards... Zafar =20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce >=20 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce From pce-bounces@lists.ietf.org Mon Apr 24 18:05:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY9BA-0004AR-R9; Mon, 24 Apr 2006 18:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5SH-0007ZQ-Ds for pce@ietf.org; Mon, 24 Apr 2006 14:06:37 -0400 Received: from test-iport-3.cisco.com ([171.71.176.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5SD-0000Jb-Ou for pce@ietf.org; Mon, 24 Apr 2006 14:06:37 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 24 Apr 2006 11:06:31 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3OI6RhE005986; Mon, 24 Apr 2006 11:06:30 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 14:06:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Mon, 24 Apr 2006 14:06:01 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5DdwgAJosi6A= From: "Rich Bradford $rbradfor$" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Jean Philippe Vasseur $jvasseur$" X-OriginalArrivalTime: 24 Apr 2006 18:06:25.0669 (UTC) FILETIME=[CD46BB50:01C667C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 X-Mailman-Approved-At: Mon, 24 Apr 2006 18:05:11 -0400 Cc: ccamp@ops.ietf.org, 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="===============2047120577==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============2047120577== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C667C9.BF3F36CD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C667C9.BF3F36CD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SkwsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LiBJdOKAmXMgYWx3YXlzIGRpZmZpY3VsdCB0byBj aG9vc2UgYmV0d2VlbiBtdWx0aXBsZSBzb2x1dGlvbnMgd2hlbiB0aGVyZSBhcmUgc28gbWFueSB0 cmFkZW9mZnMgYmV0d2VlbiB0aGUgc29sdXRpb25zLiAgDQoNCiANCg0KUmVnYXJkaW5nIHRoZSBv cHRpbWl6YXRpb24gd2hlcmUgdGhlIFBDRSBzZW5kcyB0aGUgTFNSIHRoZSB1bnNvbGljaXRlZCBj b21wdXRlZCBwYXRoIHNlZ21lbnQuICBJdCB3YXMgYSBkaWZmaWN1bHQgY2hvaWNlIHdoZXRoZXIg b3Igbm90IHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGlzIGluIHRoZSBvcmlnaW5hbCBk cmFmdCwgc2luY2UgaXQgaXMgbW9yZSBjb21wbGV4LiBXaGljaCBhc3BlY3Qgb2YgdGhlIG9wdGlt aXphdGlvbiBzZWVtZWQgbW9zdCBpbXBvcnRhbnQ/IFdhcyBpdCB0aGF0IGl04oCZcyBtb3JlIGVm ZmljaWVudCBkdXJpbmcgTFNQIHNldHVwIG9yIGJlY2F1c2UgaXQgY291bGQgYmUgdXNlZCB0byBz aGlmdCB0aGUgYnVyZGVuIG9mIG1haW50YWluaW5nIHN0YXRlIGZyb20gdGhlIFBDRSB0byB0aGUg TFNSPw0KDQpUaGFua3Mgb25jZSBhZ2FpbiBmb3IgeW91ciBvcGluaW9uLiANCg0KQmVzdCBSZWdh cmRzLA0KDQogIFJpY2gNCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpGcm9tOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4gW21haWx0bzpqZWFubG91aXMu bGVyb3V4QGZyYW5jZXRlbGVjb20uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMjEsIDIwMDYg MTI6NTEgUE0NClRvOiBKZWFuIFBoaWxpcHBlIFZhc3NldXIgKGp2YXNzZXVyKTsgUmljaCBCcmFk Zm9yZCAocmJyYWRmb3IpDQpDYzogY2NhbXBAb3BzLmlldGYub3JnOyBwY2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbUGNlXSBDb21wYXJpc29uIG9mIEVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNv bHV0aW9ucyBmb3IgdGhlIENQU0lELg0KDQogDQoNCkhpIEpQLCBSaWNoYXJkDQoNCiANCg0KUGxl YXNlIHNlZSBpbmxpbmUsDQoNCgkgDQoNCgkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCg0KCURlIDogSlAgVmFzc2V1ciBbbWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbV0gDQoJ RW52b3nDqSA6IGpldWRpIDYgYXZyaWwgMjAwNiAxNDo1Mg0KCcOAIDogUmljaCBCcmFkZm9yZA0K CUNjIDogY2NhbXBAb3BzLmlldGYub3JnOyBwY2VAaWV0Zi5vcmcNCglPYmpldCA6IFJlOiBbUGNl XSBDb21wYXJpc29uIG9mIEVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNvbHV0aW9ucyBmb3IgdGhl IENQU0lELg0KDQoJSGksIA0KDQoJIA0KDQoJVGhhbmtzIGZvciB0aGUgc3VtbWFyeSBSaWNoLg0K DQoJIA0KDQoJUENFIFdHIG1lbWJlcnM6IHRoYW5rcyB0byBwcm92aWRlIHlvdXIgZmVlZGJhY2sg b24gd2hldGhlcjoNCg0KCSgxKSBZb3UgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1 Y2ggc29sdXRpb24sIA0KDQoJIA0KDQoJWWVzIGRlZmluaXRlbHksIGNvbmZpZGVudGlhbGl0eSBp cyBhIGtleSByZXF1aXJlbWVudHMgaW4gYW4gaW50ZXItcHJvdmlkZXIgY29udGV4dC4NCg0KCSAN Cg0KCSgyKSBZb3Ugd291bGQgcHJlZmVyIG9uZSBzb2x1dGlvbiAod2hpY2ggb25lIGFuZCB3aHkg PykgDQoNCgkgDQoNCgkoMykgWW91IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBib3Ro IA0KDQoJIA0KDQoJQW5zd2VyIHRvICgyKSBhbmQgKDMpOg0KDQoJSXQgc2VlbXMgdG8gbWUgdGhh dCB3ZSBzaG91bGQgZW5kLXVwIHdpdGggYSBzaW5nbGUgc29sdXRpb24gc28gYXMgdG8gZWFzZSBp bnRlcndvcmtpbmcuDQoNCglJTU8gaW4gYW4gaW50ZXItQVMgTVBMUy1URSBlbnZpcm9ubWVudCB3 aXRob3V0IFBDRXMsIHRoZSBwYXRocyB3aWxsIGJlIGxvb3NlIGFueXdheSwgc28gdGhlcmUgd2ls bCBub3QgYmUgYW55IGNvbmZpZGVudGlhbGl0eSBpc3N1ZS4gDQoNCglJZiBoYXZlIHNvbWUgY29u Y2VybnMgcmVnYXJkaW5nIHRoZSBjb3N0IG9mIGVuY3J5cHRpb24sIHBhcnRpY3VsYXJseSBmb3Ig bGFyZ2UgcGF0aHMgKHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgZnV0dXJlIFAyTVAgYXBwbGljYXRp b25zIHdpdGggYSBsYXJnZSBudW1iZXIgb2YgaG9wcy4uLikuIEJ5IHRoZSB3YXksIGVuY3J5cHRp b24gYXBwcm9hY2hlcyBhcmUgcmVhbGx5IHZ1bG5lcmFibGUgdG8gRG9TIGF0dGFja3MuDQoNCglI ZW5jZSBJIHdvdWxkIHN0cm9uZ2x5IGZhdm9yIHRoZSBQS1Mgc29sdXRpb24uIFRoZSBvcHRpbWl6 YXRpb24gc3VnZ2VzdGVkLCB3aGljaCBjb25zaXN0cyBvZiBzZW5kaW5nIHRoZSBjb21wdXRlZCBw YXRoIHNlZ21lbnQgdG8gdGhlIExTUiBpbiBhbiB1bnNvbGljaXRlZCBtYW5uZXIsIGp1c3QgYWZ0 ZXIgdGhlIGNvbXB1dGF0aW9uLCBzb3VuZHMgcmVsZXZhbnQgYW5kIHNob3VsZCBiZSBmdXJ0aGVy IGludmVzdGlnYXRlZC4NCg0KCSANCg0KCUJlc3QgUmVnYXJkcywNCg0KCSANCg0KCUpMDQoNCgkg DQoNCgkgDQoNCgkgDQoNCgkgDQoNCglUaGFua3MuDQoNCgkgDQoNCglKUC4NCg0KCSANCg0KCU9u IEFwciA1LCAyMDA2LCBhdCA2OjE5IFBNLCBSaWNoIEJyYWRmb3JkICgocmJyYWRmb3IpKSB3cm90 ZToNCg0KCQ0KCQ0KCQ0KDQoJSGksDQoNCglBcyBzdWdnZXN0ZWQgaW4gRGFsbGFzLCBJ4oCZdmUg ZGVzY3JpYmVkIHNvbWUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSB0d28gc29sdXRpb25z IGRlc2NyaWJlZCBpbiBkcmFmdC1yYnJhZGZvci1jY2FtcC1jb25maWRlbnRpYWwtc2VnbWVudC0w MC50eHQuDQoNCgktLSBSaWNoDQoNCglUaGUgQ29uZmlkZW50aWFsIFBhdGggU2VnbWVudCAoQ1BT KSBJRCBwcm92aWRlcyB0d28gdmVyeSBkaWZmZXJlbnQgYnV0IGVxdWFsbHkgdmFsaWQgc29sdXRp b25zLCB0aGUgUGF0aCBLZXkgU3Vib2JqZWN0IChQS1MpIHNvbHV0aW9uIGFuZCB0aGUgUHJpdmF0 ZSBSb3V0ZSBTdWJvYmplY3QgKFBSUykgc29sdXRpb24uIFRoaXMgbm90ZSBleGFtaW5lcyBhIG51 bWJlciBvZiB0aGUgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIHNvbHV0aW9u LiANCg0KCUluIHNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRo ZSBDUFMgZm9yIGFuIEFTIGJ5IHNhdmluZyBpdCBpbiBhIGRhdGFiYXNlIGFuZCByZXBsYWNpbmcg aXQgd2l0aCBhIGtleSBpbiB0aGUgRVJPLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jl c3MgTFNSIGZvciB0aGF0IEFTIG11c3QgcXVlcnkgdGhlIFBDRSBmb3IgYW4gZXhwYW5zaW9uLg0K DQoJVGhlIFBSUyBzb2x1dGlvbiBhbGxvd3MgYSBDUFMgZm9yIGFuIEFTIHRvIGJlIGhpZGRlbiBi eSBlbmNyeXB0aW5nIGl0LCB3aGljaCBtYXkgYmUgZG9uZSBieSBhIFBDRSBvciBieSB0aGUgSGVh ZC1FbmQgTFNSLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNSIGZvciB0aGF0 IEFTIG11c3QgdXNlIGEgZGVjcnlwdGlvbiBrZXkgdG8gb2J0YWluIHRoZSBleHBhbnNpb24gKGlt cGx5aW5nIGFuIGVhcmxpZXIgZXhjaGFuZ2Ugb3IgY29uZmlndXJhdGlvbikuIA0KDQoJVGhlIG1h am9yIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIG1lY2hhbmlzbXMgaW52b2x2ZSAoMSkgYWRkaXRp b25hbCBjb250cm9sIG1lc3NhZ2VzLCAoMikgcGVyZm9ybWFuY2UgaXNzdWVzIGV4cGFuZGluZyB0 aG9zZSBvYmplY3RzLCAoMykgdGhlIGFkZGl0aW9uIG9mIHN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0 aGUgc29sdXRpb24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzIHRvcG9sb2dp ZXMgb2YgZWFjaCBzb2x1dGlvbi4pLCBhbmQgKDUpIHRoZSBzaXplIG9mIG9iamVjdHMgYWRkZWQg dG8gZXhpc3RpbmcgbWVzc2FnZXMuDQoNCgkoMSkgQWRkaXRpb25hbCBDb250cm9sIE1lc3NhZ2Ug T3ZlcmhlYWQ6DQoNCglUaGUgUEtTIHNvbHV0aW9uIHJlcXVpcmVzIGEgbWVjaGFuaXNtIHRvIGV4 cGFuZCB0aGUgUGF0aCBLZXkgdXBvbiByZWNlaXB0IG9mIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC4g U2luY2UgdGhlIFBDRSB3aGljaCBjYWxjdWxhdGVkIHRoZSBQYXRoIEtleSBtaWdodCBub3QgcmVz aWRlIGluIHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBl eHBhbnNpb24gZnJvbSB0aGUgUENFLCByZXF1aXJpbmcgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGV4 Y2hhbmdlIGJlZm9yZSBMU1Agc2V0dXAgY2FuIHByb2NlZWQuIFRoZSBQYXRoIEVuY3J5cHRpb24g c29sdXRpb24gZG9lcyBub3QgcmVxdWlyZSB0aGlzIGV4dHJhIGV4Y2hhbmdlIGJldHdlZW4gdGhl IFBDRSBhbmQgdGhlIGluZ3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNy eXB0aW9uIGtleSBuZWVkcyB0byBiZSBleGNoYW5nZWQgb25seSB3aGVuIGl0IGlzIGNoYW5nZWQu IFRoZSByZXN1bHQgaXMgYWRkaXRpb25hbCBkZWxheSBkdXJpbmcgZXZlcnkgTFNQIHNldHVwIGZv ciB0aGUgUEtTIHNvbHV0aW9uIGJ1dCBubyBhZGRpdGlvbmFsIGRlbGF5IGZvciB0aGUgUFJTIHNv bHV0aW9uLg0KDQoJKDIpIFBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOg0KDQoJVGhlIFBLUyBzb2x1 dGlvbiBtdXN0IG1haW50YWluIGEgKHRlbXBvcmFyeSkgZGF0YWJhc2Ugb2Yga2V5cyBhZGRpbmcg b3ZlcmhlYWQgdG8gdGhlIFBDRS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1aXJlcyB0aGUgZW5jcnlw dGlvbiBvZiB0aGUgQ1BTIGluIHRoZSBQQ0UgYW5kIGRlY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0 aGUgTFNSLCB3aGljaCBjb3VsZCBiZSBDUFUgaW50ZW5zaXZlLiBOb3RlIHRoYXQgaW4gY2FzZSBv ZiBhIGJ1cnN0IG9mIHJlcXVlc3RzLCBlbmNyeXB0aW9uIG9mIGxhcmdlIG51bWJlciBvZiBDUFMg bWF5IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBQQ0UgcmVzcG9uc2UgdGltZS4NCg0KCSgzKSBBZGRp dGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOg0KDQoJVGhlIFBLUyBzb2x1dGlvbiByZXF1aXJlcyB0 aGUgYWRkaXRpb24gb2YgcGF0aC1zcGVjaWZpYyBzdGF0ZSBhbmQgbWFpbnRlbmFuY2Ugb2YgYSBk YXRhYmFzZSBpbiB0aGUgUENFLiBUaGUgUFJTIHNvbHV0aW9uIHJlcXVpcmVzIG5vIGFkZGl0aW9u YWwgc3RhdGUuDQoNCgkoNCkgU29sdXRpb24gU2NvcGU6DQoNCglUaGUgUEtTIGFuZCBQUlMgc29s dXRpb25zIGJvdGggd29yayB3ZWxsIGluIGNvbmp1bmN0aW9uIHdpdGggYSBQQ0UgdG8gZW5jb2Rl IGFuZCBkZWNvZGUgdGhlIENQUy4gSG93ZXZlciB0aGUgUEtTIHByb3ZpZGVzIG5vIGRpcmVjdCBz b2x1dGlvbiB3aXRob3V0IGEgUENFLiBUaGlzIHByZXZlbnRzIHRoZSBQS1Mgc29sdXRpb24gZm9y IHdvcmtpbmcgaW4gdGhlIGNhc2Ugd2hlcmUgQSdzIG5ldHdvcmsgc3RyYWRkbGVzIEIncyBuZXR3 b3JrIGFuZCB3aGVyZSBBIHdhbnRzIHRvIHVzZSBhbiBFUk8gZm9yIGEgc2VnbWVudCBvZiB0aGUg TFNQIGFjcm9zcyB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5nLiAobmV0QSktKG5ldEIpLShu ZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMgY291bGQgYmUgdXNlZCB0byByZWNvcmQgYSBDUFMg ZXZlbiBpZiB0aGUgcGF0aCAoYW5kIHRoZXJlZm9yZSB0aGUgcmV0dXJuZWQgUlJPKSBjcm9zc2Vz IG11bHRpcGxlIGJvdW5kYXJpZXMuIEZpbmFsbHksIGEgUFJTIHNvbHV0aW9uIGNvdWxkIGJlIGFk YXB0ZWQgdG8gcmV0dXJuIGFjdHVhbCBmYWlsdXJlIGxvY2F0aW9ucyBpbiBQRVJScyBhbmQvb3Ig UEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJlIGxvY2F0aW9uIGNvbmZpZGVudGlh bCBmcm9tIExTUnMgd2l0aG91dCBhIGRlY3J5cHRpb24ga2V5LiBDdXJyZW50bHkgcHJpdmFjeSBv ZiB0aGlzIHNvdXJjZSBpcyBtYWludGFpbmVkIGJ5IHJldHVybmluZyB0aGUgYWRkcmVzcyBvZiBi b3JkZXIgbm9kZXMsIHdoaWNoIGNhbiBiZSB2ZXJ5IG1pc2xlYWRpbmcuDQoNCgkoNSkgTWVzc2Fn ZSBPYmplY3QgT3ZlcmhlYWQ6DQoNCglUaGUgUEtTIHNvbHV0aW9uIHByb3ZpZGVzIGEgdmVyeSBj b21wYWN0IGtleSBvciB0b2tlbiB0byBpZGVudGlmeSBhIHBhdGggc2VnbWVudCwgd2hpY2ggZ2Vu ZXJhbGx5IGFsbG93cyBmb3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRoZSBQQ0Ug YW5kIHRvIGJlIHJlcXVlc3RlZCBpbiB0aGUgcmVzdWx0aW5nIFBBVEggbWVzc2FnZS4gQSBQUlMg d2hpY2ggY29udGFpbnMgYSBDUFMgbXVzdCBnZW5lcmFsbHkgYmUgYXQgbGVhc3QgYXMgbGFyZ2Ug YXMgdGhlIHVuZW5jcnlwdGVkIFBBVEggdGhyb3VnaCB0aGUgQVMgYW5kIG1heSBiZSBzaWduaWZp Y2FudGx5IGxhcmdlciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVtYmVyIG9mIGhv cHMgd2l0aGluIHRoZSBuZXR3b3JrIGZyb20gZXh0ZXJuYWwgdmlldyBieSBwYWRkaW5nIHRoZSBQ UlMuIFRoZSByZXN1bHQgaXMgcG90ZW50aWFsbHkgbGFyZ2VyIFBBVEggKGFuZCBQQ0VQKSBtZXNz YWdlcyBmb3IgdGhlIFBSUyBzb2x1dGlvbi4NCg0KCVBsZWFzZSBub3RlIHRoYXQgdGhlIHRyYWRl b2ZmcyBsaXN0ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEktRC4gU29tZSBvZiB0aGUgc2hv cnRjb21pbmdzIG9mIGVhY2ggYXBwcm9hY2ggY291bGQgYmUgbWl0aWdhdGVkIGJ5IGltcGxlbWVu dGF0aW9uLXNwZWNpZmljIG9wdGltaXphdGlvbnMuIEZvciBleGFtcGxlLCBhIFBDRSBjb3VsZCBj aG9vc2UgdG8gc2lnbmFsIHRoZSBDUFMgZXhwYW5zaW9uIHRvIHRoZSBlbnRyeSBib3VuZGFyeSBM U1IsIHNoaWZ0aW5nIHRoZSBidXJkZW4gb2YgbWFpbnRhaW5pbmcgdGhlIFBLUyBzdGF0ZSB0byB0 aGUgTFNSIGFuZCBlbGltaW5hdGluZyB0aGUgcGVyZm9ybWFuY2UgaGl0IGR1cmluZyBMU1Agc2V0 dXAuIEEgc2ltaWxhciBleGNoYW5nZSBjb3VsZCBiZSBwZXJmb3JtZWQgZm9yIHRoZSBQUlMgY2Fz ZSwgZWxpbWluYXRpbmcgdGhlIG5lZWQgZm9yIGEgc2VwYXJhdGUga2V5IGV4Y2hhbmdlLiBUaGVz ZSBleGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBJRCwg YnV0IG1pZ2h0IGJlIHVzZWZ1bCB3aGVuIHdlaWdoaW5nIHRoZSBwcm9zIGFuZCBjb25zIG9mIHRo ZSB0d28gc29sdXRpb25zLg0KDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KCVBjZSBtYWlsaW5nIGxpc3QNCg0KCVBjZUBsaXN0cy5pZXRmLm9yZw0K DQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCgkgDQoNCg== ------_=_NextPart_001_01C667C9.BF3F36CD Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJhZGRyZXNzIi8+DQo8bzpTbWFydFRh Z1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiDQogbmFtZT0icGxhY2UiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJDaXR5Ii8+ DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0iU3RyZWV0Ii8+DQo8IS0tW2lmICFtc29dPg0KPHN0 eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8 IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMg TWluY2hvIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCiAvKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpoMQ0KCXttYXJnaW4tdG9wOjEyLjBw dDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206My4wcHQ7DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsN Cgltc28tbGlzdDpsMCBsZXZlbDEgbGZvMTsNCglmb250LXNpemU6MTYuMHB0Ow0KCWZvbnQtZmFt aWx5OkFyaWFsO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5D aGFwdGVyLCBsaS5DaGFwdGVyLCBkaXYuQ2hhcHRlcg0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWJlZm9yZTph bHdheXM7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6Ymx1ZTsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9u MTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4 ODk0MTQ2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox NDgzNDY2OCA1MDY0ODg2NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+DQo8L3N0eWxlPg0KDQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZs aW5rPWJsdWUgc3R5bGU9J1dPUkQtV1JBUDogYnJlYWstd29yZDtraHRtbC1uYnNwLW1vZGU6IHNw YWNlOw0Ka2h0bWwtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNz PVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPkpMLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6Ni4wcHQnPjxmb250IHNpemU9MyBjb2xv cj1ibHVlDQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOmJsdWUnPlRoYW5rcw0KZm9yIHRoZSByZXBseS4gSXTigJlzIGFsd2F5 cyBkaWZmaWN1bHQgdG8gY2hvb3NlIGJldHdlZW4gbXVsdGlwbGUgc29sdXRpb25zIHdoZW4NCnRo ZXJlIGFyZSBzbyBtYW55IHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSBzb2x1dGlvbnMuwqAgPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSd0ZXh0LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 Ymx1ZSc+UmVnYXJkaW5nDQp0aGUgb3B0aW1pemF0aW9uIHdoZXJlIHRoZSBQQ0Ugc2VuZHMgdGhl IExTUiB0aGUgdW5zb2xpY2l0ZWQgY29tcHV0ZWQgcGF0aA0Kc2VnbWVudC4gwqBJdCB3YXMgYSBk aWZmaWN1bHQgY2hvaWNlIHdoZXRoZXIgb3Igbm90IHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBv Zg0KdGhpcyBpbiB0aGUgb3JpZ2luYWwgZHJhZnQsIHNpbmNlIGl0IGlzIG1vcmUgY29tcGxleC4g V2hpY2ggYXNwZWN0IG9mIHRoZQ0Kb3B0aW1pemF0aW9uIHNlZW1lZCBtb3N0IGltcG9ydGFudD8g V2FzIGl0IHRoYXQgaXTigJlzIG1vcmUgZWZmaWNpZW50IGR1cmluZyBMU1ANCnNldHVwIG9yIGJl Y2F1c2UgaXQgY291bGQgYmUgdXNlZCB0byBzaGlmdCB0aGUgYnVyZGVuIG9mIG1haW50YWluaW5n IHN0YXRlIGZyb20NCnRoZSBQQ0UgdG8gdGhlIExTUj88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjYuMHB0Jz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZQ0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5UaGFua3MNCm9uY2UgYWdhaW4gZm9y IHlvdXIgb3Bpbmlvbi4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWUNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+QmVzdA0KUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjYuMHB0Jz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZQ0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz7CoCBSaWNoPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1h bCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8 aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoNCjwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFj ZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhv bWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTIN CmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRh aG9tYSc+IDxzdDE6U3RyZWV0DQp3OnN0PSJvbiI+PHN0MTphZGRyZXNzIHc6c3Q9Im9uIj5MRSBS T1VYIEplYW4tTG91aXMgUkQ8L3N0MTphZGRyZXNzPjwvc3QxOlN0cmVldD4tQ09SRS1MQU4NCltt YWlsdG86amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbV0gPGJyPg0KPGI+PHNwYW4g c3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gRnJpZGF5LCBBcHJpbCAy MSwgMjAwNiAxMjo1MQ0KUE08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ VG86PC9zcGFuPjwvYj4gSmVhbiBQaGlsaXBwZSBWYXNzZXVyDQooanZhc3NldXIpOyBSaWNoIEJy YWRmb3JkIChyYnJhZGZvcik8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ Q2M6PC9zcGFuPjwvYj4gY2NhbXBAb3BzLmlldGYub3JnOw0KcGNlQGlldGYub3JnPGJyPg0KPGI+ PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtQ Y2VdIENvbXBhcmlzb24gb2YNCkVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNvbHV0aW9ucyBmb3Ig dGhlIENQU0lELjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5IaSBKUCwgUmljaGFyZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPlBsZWFzZSBzZWUgaW5saW5lLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7DQptYXJnaW4tbGVmdDozLjc1 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQn Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIgc2l6ZT0yIHdp ZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiSW5kZXg9LTE+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxi Pjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3Bhbg0KbGFuZz1GUiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RGUmbmJzcDs6PC9z cGFuPjwvZm9udD48L2I+PGZvbnQNCnNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBsYW5nPUZSIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+DQpKUCBWYXNzZXVyIFtt YWlsdG86anZhc3NldXJAY2lzY28uY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWln aHQ6Ym9sZCc+RW52b3nDqSZuYnNwOzo8L3NwYW4+PC9iPiBqZXVkaSA2IGF2cmlsIDIwMDYNCjE0 OjUyPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPsOAJm5ic3A7Ojwvc3Bh bj48L2I+IFJpY2ggQnJhZGZvcmQ8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9s ZCc+Q2MmbmJzcDs6PC9zcGFuPjwvYj4gY2NhbXBAb3BzLmlldGYub3JnOw0KcGNlQGlldGYub3Jn PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9iamV0Jm5ic3A7Ojwvc3Bh bj48L2I+IFJlOiBbUGNlXSBDb21wYXJpc29uDQpvZiBFbmNyeXB0aW9uIHZzLiBQYXRoIEtleSBT b2x1dGlvbnMgZm9yIHRoZSBDUFNJRC48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9RlI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+SGksIDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlRoYW5rcyBmb3Ig dGhlIHN1bW1hcnkgUmljaC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+UENFIFdHIG1lbWJlcnM6IHRoYW5rcyB0byBwcm92aWRlIHlvdXIg ZmVlZGJhY2sgb24gd2hldGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigxKSBZb3UgdGhp bmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1Y2ggc29sdXRpb24sPC9zcGFuPjwvZm9udD48 Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+WWVzIGRlZmluaXRlbHksIGNvbmZpZGVudGlhbGl0eSBpcyBhIGtl eQ0KcmVxdWlyZW1lbnRzIGluIGFuIGludGVyLXByb3ZpZGVyIGNvbnRleHQuPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigyKSBZb3Ugd291 bGQgcHJlZmVyIG9uZSBzb2x1dGlvbiAod2hpY2ggb25lIGFuZCB3aHkgPyk8L3NwYW4+PC9mb250 Pjxmb250DQpzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigzKSBZb3Ug dGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGJvdGg8L3NwYW4+PC9mb250Pjxmb250IHNp emU9Mg0KY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5BbnN3ZXIgdG8gKDIpIGFuZCAoMyk6PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+SXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91 bGQgZW5kLXVwIHdpdGgNCmEgc2luZ2xlIHNvbHV0aW9uIHNvIGFzIHRvJm5ic3A7ZWFzZSBpbnRl cndvcmtpbmcuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6Ymx1ZSc+SU1PJm5ic3A7aW4gYW4gaW50ZXItQVMgTVBMUy1URQ0KZW52aXJvbm1l bnQgd2l0aG91dCBQQ0VzLCB0aGUgcGF0aHMgd2lsbCBiZSBsb29zZSBhbnl3YXksJm5ic3A7c28N CnRoZXJlJm5ic3A7d2lsbCBub3QgYmUmbmJzcDthbnkgY29uZmlkZW50aWFsaXR5IGlzc3VlLiA8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5JZiBo YXZlIHNvbWUgY29uY2VybnMmbmJzcDtyZWdhcmRpbmcgdGhlDQpjb3N0IG9mIGVuY3J5cHRpb24s IHBhcnRpY3VsYXJseSBmb3IgbGFyZ2UgcGF0aHMgKHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgZnV0 dXJlDQpQMk1QIGFwcGxpY2F0aW9ucyB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIGhvcHMuLi4pLiBC eSB0aGUgd2F5LCBlbmNyeXB0aW9uDQphcHByb2FjaGVzIGFyZSByZWFsbHkgdnVsbmVyYWJsZSB0 byBEb1MgYXR0YWNrcy48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5IZW5jZSBJJm5ic3A7d291bGQgc3Ryb25nbHkgZmF2b3IgdGhlIFBLUw0Kc29s dXRpb24uIFRoZSBvcHRpbWl6YXRpb24gc3VnZ2VzdGVkLCZuYnNwO3doaWNoIGNvbnNpc3RzIG9m IHNlbmRpbmcgdGhlDQpjb21wdXRlZCBwYXRoIHNlZ21lbnQgdG8gdGhlIExTUiBpbiBhbiB1bnNv bGljaXRlZCBtYW5uZXIsIGp1c3QgYWZ0ZXIgdGhlDQpjb21wdXRhdGlvbiwmbmJzcDtzb3VuZHMg cmVsZXZhbnQgYW5kIHNob3VsZCBiZSBmdXJ0aGVyIGludmVzdGlnYXRlZC48L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPkJlc3QgUmVnYXJkcyw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUn PkpMPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5UaGFu a3MuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPkpQLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5PbiBBcHIgNSwgMjAwNiwgYXQgNjoxOSBQTSwgUmlj aCBCcmFkZm9yZCAoKHJicmFkZm9yKSkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlNNQVJUVEFHVFlQRSBuYW1lPSJDaXR5IiBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PE86U01BUlRU QUdUWVBFIG5hbWU9InBsYWNlIiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOnNtYXJ0dGFncyI+SGksPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkFzIHN1Z2dlc3RlZCBp biA8U1QxOkNJVFkgdTE6c3Q9Im9uIj48U1QxOlBMQUNFIHUxOnN0PSJvbiI+PHN0MTpDaXR5DQp3 OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+RGFsbGFzPC9TVDE6UExBQ0U+PC9TVDE6Q0lU WT48L3N0MTpwbGFjZT48L3N0MTpDaXR5PiwNCknigJl2ZSBkZXNjcmliZWQgc29tZSBvZiB0aGUg dHJhZGVvZmZzIGJldHdlZW4gdGhlIHR3byBzb2x1dGlvbnMgZGVzY3JpYmVkIGluDQpkcmFmdC1y YnJhZGZvci1jY2FtcC1jb25maWRlbnRpYWwtc2VnbWVudC0wMC50eHQuPE86UD48L086UD48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0K c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQnPi0tIFJpY2g8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PE86UD48L086UD5UaGUNCkNvbmZpZGVudGlh bCBQYXRoIFNlZ21lbnQgKENQUykgSUQgcHJvdmlkZXMgdHdvIHZlcnkgZGlmZmVyZW50IGJ1dCBl cXVhbGx5DQp2YWxpZCBzb2x1dGlvbnMsIHRoZSBQYXRoIEtleSBTdWJvYmplY3QgKFBLUykgc29s dXRpb24gYW5kIHRoZSBQcml2YXRlIFJvdXRlDQpTdWJvYmplY3QgKFBSUykgc29sdXRpb24uIFRo aXMgbm90ZSBleGFtaW5lcyBhIG51bWJlciBvZiB0aGUgYWR2YW50YWdlcyBhbmQNCmRpc2FkdmFu dGFnZXMgb2YgZWFjaCBzb2x1dGlvbi4gPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+SW4N CnNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMgZm9y IGFuIEFTIGJ5IHNhdmluZyBpdCBpbg0KYSBkYXRhYmFzZSBhbmQgcmVwbGFjaW5nIGl0IHdpdGgg YSBrZXkgaW4gdGhlIEVSTy4gRHVyaW5nIHRoZSBMU1Agc2V0dXAsIHRoZQ0KaW5ncmVzcyBMU1Ig Zm9yIHRoYXQgQVMgbXVzdCBxdWVyeSB0aGUgUENFIGZvciBhbiBleHBhbnNpb24uPE86UD48L086 UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMi4wcHQnPlRoZSBQUlMgc29sdXRpb24NCmFsbG93cyBhIENQUyBmb3IgYW4gQVMgdG8gYmUg aGlkZGVuIGJ5IGVuY3J5cHRpbmcgaXQsIHdoaWNoIG1heSBiZSBkb25lIGJ5IGENClBDRSBvciBi eSB0aGUgSGVhZC1FbmQgTFNSLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNS IGZvciB0aGF0IEFTDQptdXN0IHVzZSBhIGRlY3J5cHRpb24ga2V5IHRvIG9idGFpbiB0aGUgZXhw YW5zaW9uIChpbXBseWluZyBhbiBlYXJsaWVyIGV4Y2hhbmdlDQpvciBjb25maWd1cmF0aW9uKS4g PE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+VGhlDQptYWpvciBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHRoZSBtZWNoYW5pc21zIGludm9sdmUgKDEpIGFkZGl0aW9uYWwgY29udHJvbA0KbWVzc2Fn ZXMsICgyKSBwZXJmb3JtYW5jZSBpc3N1ZXMgZXhwYW5kaW5nIHRob3NlIG9iamVjdHMsICgzKSB0 aGUgYWRkaXRpb24gb2YNCnN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRpb24gc2NvcGUg KGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzDQp0b3BvbG9naWVzIG9mIGVhY2ggc29sdXRp b24uKSwgYW5kICg1KSB0aGUgc2l6ZSBvZiBvYmplY3RzIGFkZGVkIHRvIGV4aXN0aW5nDQptZXNz YWdlcy48TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PE86UD48L086UD4oMSkNCkFkZGl0aW9uYWwgQ29udHJv bCBNZXNzYWdlIE92ZXJoZWFkOjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0aW9uDQpy ZXF1aXJlcyBhIG1lY2hhbmlzbSB0byBleHBhbmQgdGhlIFBhdGggS2V5IHVwb24gcmVjZWlwdCBv ZiB0aGUgTFNQIHNldHVwDQpyZXF1ZXN0LiBTaW5jZSB0aGUgUENFIHdoaWNoIGNhbGN1bGF0ZWQg dGhlIFBhdGggS2V5IG1pZ2h0IG5vdCByZXNpZGUgaW4gdGhlDQplbnRyeSBib3VuZGFyeSBMU1Is IHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNpb24gZnJvbSB0aGUgUENFLCByZXF1aXJp bmcNCmFuIGFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgTFNQIHNldHVwIGNhbiBw cm9jZWVkLiBUaGUgUGF0aA0KRW5jcnlwdGlvbiBzb2x1dGlvbiBkb2VzIG5vdCByZXF1aXJlIHRo aXMgZXh0cmEgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgUENFIGFuZA0KdGhlIGluZ3Jlc3Mgbm9kZSBm b3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9uIGtleSBuZWVkcyB0byBiZQ0KZXhj aGFuZ2VkIG9ubHkgd2hlbiBpdCBpcyBjaGFuZ2VkLiBUaGUgcmVzdWx0IGlzIGFkZGl0aW9uYWwg ZGVsYXkgZHVyaW5nIGV2ZXJ5DQpMU1Agc2V0dXAgZm9yIHRoZSBQS1Mgc29sdXRpb24gYnV0IG5v IGFkZGl0aW9uYWwgZGVsYXkgZm9yIHRoZSBQUlMgc29sdXRpb24uPE86UD48L086UD48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn PjxPOlA+PC9POlA+PE86UD48L086UD4oMikNClBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOjxPOlA+ PC9POlA+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0aW9uDQptdXN0IG1haW50YWluIGEgKHRlbXBvcmFy eSkgZGF0YWJhc2Ugb2Yga2V5cyBhZGRpbmcgb3ZlcmhlYWQgdG8gdGhlIFBDRS4gVGhlDQpQUlMg c29sdXRpb24gcmVxdWlyZXMgdGhlIGVuY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0aGUgUENFIGFu ZCBkZWNyeXB0aW9uIG9mDQp0aGUgQ1BTIGluIHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBp bnRlbnNpdmUuIE5vdGUgdGhhdCBpbiBjYXNlIG9mIGEgYnVyc3QNCm9mIHJlcXVlc3RzLCBlbmNy eXB0aW9uIG9mIGxhcmdlIG51bWJlciBvZiBDUFMgbWF5IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBQ Q0UNCnJlc3BvbnNlIHRpbWUuPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+KDMpDQpBZGRp dGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0 aW9uDQpyZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgcGF0aC1zcGVjaWZpYyBzdGF0ZSBhbmQgbWFp bnRlbmFuY2Ugb2YgYSBkYXRhYmFzZSBpbg0KdGhlIFBDRS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1 aXJlcyBubyBhZGRpdGlvbmFsIHN0YXRlLjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48TzpQPjwvTzpQPjxP OlA+PC9POlA+KDQpDQpTb2x1dGlvbiBTY29wZTo8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIFBLUyBh bmQgUFJTDQpzb2x1dGlvbnMgYm90aCB3b3JrIHdlbGwgaW4gY29uanVuY3Rpb24gd2l0aCBhIFBD RSB0byBlbmNvZGUgYW5kIGRlY29kZSB0aGUNCkNQUy4gSG93ZXZlciB0aGUgUEtTIHByb3ZpZGVz IG5vIGRpcmVjdCBzb2x1dGlvbiB3aXRob3V0IGEgUENFLiBUaGlzIHByZXZlbnRzDQp0aGUgUEtT IHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrIHN0cmFk ZGxlcyBCJ3MNCm5ldHdvcmsgYW5kIHdoZXJlIEEgd2FudHMgdG8gdXNlIGFuIEVSTyBmb3IgYSBz ZWdtZW50IG9mIHRoZSBMU1AgYWNyb3NzIHRoZQ0KaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5nLiAo bmV0QSktKG5ldEIpLShuZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMgY291bGQgYmUNCnVzZWQg dG8gcmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJldHVy bmVkIFJSTykgY3Jvc3Nlcw0KbXVsdGlwbGUgYm91bmRhcmllcy4gRmluYWxseSwgYSBQUlMgc29s dXRpb24gY291bGQgYmUgYWRhcHRlZCB0byByZXR1cm4gYWN0dWFsDQpmYWlsdXJlIGxvY2F0aW9u cyBpbiBQRVJScyBhbmQvb3IgUEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJlIGxv Y2F0aW9uDQpjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtleS4g Q3VycmVudGx5IHByaXZhY3kgb2YgdGhpcw0Kc291cmNlIGlzIG1haW50YWluZWQgYnkgcmV0dXJu aW5nIHRoZSBhZGRyZXNzIG9mIGJvcmRlciBub2Rlcywgd2hpY2ggY2FuIGJlDQp2ZXJ5IG1pc2xl YWRpbmcuPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+KDUpDQpNZXNzYWdlIE9iamVjdCBP dmVyaGVhZDo8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIFBLUyBzb2x1dGlvbg0KcHJvdmlkZXMgYSB2 ZXJ5IGNvbXBhY3Qga2V5IG9yIHRva2VuIHRvIGlkZW50aWZ5IGEgcGF0aCBzZWdtZW50LCB3aGlj aA0KZ2VuZXJhbGx5IGFsbG93cyBmb3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRo ZSBQQ0UgYW5kIHRvIGJlIHJlcXVlc3RlZA0KaW4gdGhlIHJlc3VsdGluZyBQQVRIIG1lc3NhZ2Uu IEEgUFJTIHdoaWNoIGNvbnRhaW5zIGEgQ1BTIG11c3QgZ2VuZXJhbGx5IGJlIGF0DQpsZWFzdCBh cyBsYXJnZSBhcyB0aGUgdW5lbmNyeXB0ZWQgUEFUSCB0aHJvdWdoIHRoZSBBUyBhbmQgbWF5IGJl IHNpZ25pZmljYW50bHkNCmxhcmdlciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVt YmVyIG9mIGhvcHMgd2l0aGluIHRoZSBuZXR3b3JrIGZyb20NCmV4dGVybmFsIHZpZXcgYnkgcGFk ZGluZyB0aGUgUFJTLiBUaGUgcmVzdWx0IGlzIHBvdGVudGlhbGx5IGxhcmdlciBQQVRIIChhbmQN ClBDRVApIG1lc3NhZ2VzIGZvciB0aGUgUFJTIHNvbHV0aW9uLjxPOlA+PC9POlA+PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48 TzpQPjwvTzpQPjxPOlA+PC9POlA+UGxlYXNlDQpub3RlIHRoYXQgdGhlIHRyYWRlb2ZmcyBsaXN0 ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEktRC4gU29tZSBvZiB0aGUNCnNob3J0Y29taW5n cyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxkIGJlIG1pdGlnYXRlZCBieSBpbXBsZW1lbnRhdGlvbi1z cGVjaWZpYw0Kb3B0aW1pemF0aW9ucy4gRm9yIGV4YW1wbGUsIGEgUENFIGNvdWxkIGNob29zZSB0 byBzaWduYWwgdGhlIENQUyBleHBhbnNpb24gdG8NCnRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHNo aWZ0aW5nIHRoZSBidXJkZW4gb2YgbWFpbnRhaW5pbmcgdGhlIFBLUyBzdGF0ZSB0byB0aGUNCkxT UiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZvcm1hbmNlIGhpdCBkdXJpbmcgTFNQIHNldHVwLiBB IHNpbWlsYXIgZXhjaGFuZ2UNCmNvdWxkIGJlIHBlcmZvcm1lZCBmb3IgdGhlIFBSUyBjYXNlLCBl bGltaW5hdGluZyB0aGUgbmVlZCBmb3IgYSBzZXBhcmF0ZSBrZXkNCmV4Y2hhbmdlLiBUaGVzZSBl eGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBJRCwgYnV0 DQptaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGluZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUg dHdvIHNvbHV0aW9ucy48TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PE86UD48 L086UD48TzpQPjwvTzpQPjwvTzpTTUFSVFRBR1RZUEU+PC9POlNNQVJUVEFHVFlQRT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEyLjBwdCc+UGNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJl Zj0ibWFpbHRvOlBjZUBsaXN0cy5pZXRmLm9yZyI+UGNlQGxpc3RzLmlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGNlIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w Y2U8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C667C9.BF3F36CD-- --===============2047120577== 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 --===============2047120577==-- From pce-bounces@lists.ietf.org Tue Apr 25 09:16:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNP1-0003t4-Oi; Tue, 25 Apr 2006 09:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYN8e-0006ci-0P for pce@ietf.org; Tue, 25 Apr 2006 08:59:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYN8b-0006b7-NY for pce@ietf.org; Tue, 25 Apr 2006 08:59:31 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2006 05:59:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,153,1144047600"; d="scan'208,217"; a="26623886:sNHT66162804" 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 k3PCxSvF024543; Tue, 25 Apr 2006 08:59: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); Tue, 25 Apr 2006 08:59:27 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 08:59:25 -0400 In-Reply-To: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> References: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Tue, 25 Apr 2006 08:59:23 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 25 Apr 2006 12:59:25.0514 (UTC) FILETIME=[146BE2A0:01C66868] X-Spam-Score: 0.1 (/) X-Scan-Signature: f0068523cb6bca15634130f00012b297 X-Mailman-Approved-At: Tue, 25 Apr 2006 09:16:26 -0400 Cc: ccamp@ops.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="===============0261007390==" Errors-To: pce-bounces@lists.ietf.org --===============0261007390== Content-Type: multipart/alternative; boundary=Apple-Mail-19-159039474 --Apple-Mail-19-159039474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Thanks for your feed-back, suggesting to go ahead with one solution, =20 the PKS. Indeed, the proposed optimization could be specified in a =20 further revision (being optional). Others, any opinion ? Thanks. JP. On Apr 24, 2006, at 2:06 PM, Rich Bradford ((rbradfor)) wrote: > JL, > > Thanks for the reply. It=92s always difficult to choose between =20 > multiple solutions when there are so many tradeoffs between the =20 > solutions. > > > > Regarding the optimization where the PCE sends the LSR the =20 > unsolicited computed path segment. It was a difficult choice =20 > whether or not to include a description of this in the original =20 > draft, since it is more complex. Which aspect of the optimization =20 > seemed most important? Was it that it=92s more efficient during LSP =20= > setup or because it could be used to shift the burden of =20 > maintaining state from the PCE to the LSR? > > Thanks once again for your opinion. > > Best Regards, > > Rich > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Friday, April 21, 2006 12:51 PM > To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) > Cc: ccamp@ops.ietf.org; pce@ietf.org > Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > > > Hi JP, Richard > > > > Please see inline, > > > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 6 avril 2006 14:52 > =C0 : Rich Bradford > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > Hi, > > > > Thanks for the summary Rich. > > > > PCE WG members: thanks to provide your feedback on whether: > > (1) You think that there is a need for such solution, > > > > Yes definitely, confidentiality is a key requirements in an inter-=20 > provider context. > > > > (2) You would prefer one solution (which one and why ?) > > > > (3) You think that there is a need for both > > > > Answer to (2) and (3): > > It seems to me that we should end-up with a single solution so as =20 > to ease interworking. > > IMO in an inter-AS MPLS-TE environment without PCEs, the paths will =20= > be loose anyway, so there will not be any confidentiality issue. > > If have some concerns regarding the cost of encryption, =20 > particularly for large paths (we need to think about future P2MP =20 > applications with a large number of hops...). By the way, =20 > encryption approaches are really vulnerable to DoS attacks. > > Hence I would strongly favor the PKS solution. The optimization =20 > suggested, which consists of sending the computed path segment to =20 > the LSR in an unsolicited manner, just after the computation, =20 > sounds relevant and should be further investigated. > > > > Best Regards, > > > > JL > > > > > > > > > > Thanks. > > > > JP. > > > > On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > > > > > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-19-159039474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Thanks for your feed-back, = suggesting to go ahead with one solution, the PKS. Indeed, the proposed = optimization could be specified in a further revision (being = optional).

Others, any opinion = ?

Thanks.

JP.

On = Apr 24, 2006, at 2:06 PM, Rich Bradford ((rbradfor)) wrote:

JL,Thanks for the reply. It=92s = always difficult to choose between multiple solutions when there are so = many tradeoffs between the solutions.=A0Regarding the optimization = where the PCE sends the LSR the unsolicited computed path segment. =A0It = was a difficult choice whether or not to include a description of this = in the original draft, since it is more complex. Which aspect of the = optimization seemed most important? Was it that it=92s more efficient = during LSP setup or because it could be used to shift the burden of = maintaining state from the PCE to the LSR?Thanks once again for your = opinion.
Best Regards,
=A0 Rich
From: LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux= @francetelecom.com]
Sent: Friday, April 21, 2006 12:51 PM
Jean Philippe = Vasseur (jvasseur); Rich Bradford (rbradfor)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.
Hi JP, = Richard
=A0Please see = inline,
=
=A0
JP Vasseur [mailto:jvasseur@cisco.com] =
jeudi 6 avril = 2006 14:52
Rich = Bradford
ccamp@ops.ietf.org; pce@ietf.org
Re: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.
Hi,
=A0
Thanks for the summary Rich.=A0
PCE WG members: thanks to provide your = feedback on whether:
(1) You think that there is a need for such = solution,=A0=A0Yes definitely, = confidentiality is a key requirements in an inter-provider = context.
=A0
(2) You would prefer one solution (which one = and why ?)=A0=A0(3) You think that there is a need for = both=A0=A0Answer to (2) and = (3):
It seems to me that we = should end-up with a single solution so as to=A0ease = interworking.
IMO=A0in an inter-AS MPLS-TE environment without PCEs, the = paths will be loose anyway,=A0so there=A0will not be=A0any = confidentiality issue.
If have some concerns=A0regarding the cost of encryption, = particularly for large paths (we need to think about future P2MP = applications with a large number of hops...). By the way, encryption = approaches are really vulnerable to DoS = attacks.
Hence I=A0would = strongly favor the PKS solution. The optimization suggested,=A0which = consists of sending the computed path segment to the LSR in an = unsolicited manner, just after the computation,=A0sounds relevant and = should be further investigated.=A0Best = Regards,
=A0
JL
=A0
=A0
=A0
=A0
Thanks.
=A0
JP.
On Apr 5, 2006, at 6:19 PM, Rich Bradford = ((rbradfor)) wrote:

Hi,As suggested = in , I=92ve described some of the tradeoffs between the = two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.-- = RichThe = Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.In short: The = PKS solution allows a PCE to hide the CPS for an AS by saving it in a = database and replacing it with a key in the ERO. During the LSP setup, = the ingress LSR for that AS must query the PCE for an = expansion.
The PRS = solution allows a CPS for an AS to be hidden by encrypting it, which may = be done by a PCE or by the Head-End LSR. During the LSP setup, the = ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).The major = differences between the mechanisms involve (1) additional control = messages, (2) performance issues expanding those objects, (3) the = addition of state to the PCE, (4) the solution scope (i.e. applicability = to various topologies of each solution.), and (5) the size of objects = added to existing messages.
(1) Additional = Control Message Overhead:
The PKS = solution requires a mechanism to expand the Path Key upon receipt of the = LSP setup request. Since the PCE which calculated the Path Key might not = reside in the entry boundary LSR, the LSR must request the expansion = from the PCE, requiring an additional message exchange before LSP setup = can proceed. The Path Encryption solution does not require this extra = exchange between the PCE and the ingress node for every LSP. Rather, the = decryption key needs to be exchanged only when it is changed. The result = is additional delay during every LSP setup for the PKS solution but no = additional delay for the PRS solution.
(2) PCE and = LSR Performance:
The PKS = solution must maintain a (temporary) database of keys adding overhead to = the PCE. The PRS solution requires the encryption of the CPS in the PCE = and decryption of the CPS in the LSR, which could be CPU intensive. Note = that in case of a burst of requests, encryption of large number of CPS = may have an impact on the PCE response time.(3) Addition = of State in the PCE:
The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.
(4) Solution = Scope:
The PKS and = PRS solutions both work well in conjunction with a PCE to encode and = decode the CPS. However the PKS provides no direct solution without a = PCE. This prevents the PKS solution for working in the case where A's = network straddles B's network and where A wants to use an ERO for a = segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading.
(5) Message = Object Overhead:
The PKS = solution provides a very compact key or token to identify a path = segment, which generally allows for smaller EROs to be returned by the = PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.
Please note = that the tradeoffs listed here are for the current I-D. Some of the = shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two = solutions.
Pce mailing list
https://www1.ietf.org/mailman/listinfo/pce

= --Apple-Mail-19-159039474-- --===============0261007390== 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 --===============0261007390==-- From pce-bounces@lists.ietf.org Wed Apr 26 15:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq1h-0000dK-5E; Wed, 26 Apr 2006 15:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq1S-0000Zu-Rc; Wed, 26 Apr 2006 15:50:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq1S-00082p-3c; Wed, 26 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3QJo1vP023369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYq1R-00076o-Kd; Wed, 26 Apr 2006 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, 26 Apr 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pce@ietf.org Subject: [Pce] I-D ACTION:draft-ietf-pce-inter-layer-frwk-00.txt X-BeenThere: pce@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pce-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element Working Group of the IETF. Title : Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering Author(s) : E. Oki, et al. Filename : draft-ietf-pce-inter-layer-frwk-00.txt Pages : 15 Date : 2006-4-26 A network may comprise of multiple layers. It is important to globally optimize network resources utilization, taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. The Path Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering. This document describes a framework for the PCE-based path computation architecture to inter-layer MPLS and GMPLS traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual Network Topology Manager (VNTM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-frwk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pce-inter-layer-frwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pce-inter-layer-frwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26115953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pce-inter-layer-frwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pce-inter-layer-frwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26115953.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 Apr 27 09:43:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6ly-0001at-I4; Thu, 27 Apr 2006 09:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6dE-0006JB-Jf for pce@ietf.org; Thu, 27 Apr 2006 09:34:08 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6Qp-0004Mb-3e for pce@ietf.org; Thu, 27 Apr 2006 09:21:20 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 15:21:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Thu, 27 Apr 2006 15:21:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5DdwgAJosi6AAi6EtcA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Rich Bradford $rbradfor$" , "Jean Philippe Vasseur $jvasseur$" X-OriginalArrivalTime: 27 Apr 2006 13:21:15.0187 (UTC) FILETIME=[75DFA030:01C669FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6aa9751a99a375c56c6a892e94827f72 X-Mailman-Approved-At: Thu, 27 Apr 2006 09:43:09 -0400 Cc: ccamp@ops.ietf.org, 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="===============0559392960==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0559392960== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C669FD.758FF101" This is a multi-part message in MIME format. ------_=_NextPart_001_01C669FD.758FF101 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 Please see inline, ________________________________ De : Rich Bradford (rbradfor) [mailto:rbradfor@cisco.com]=20 Envoy=E9 : lundi 24 avril 2006 20:06 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur) Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =09 =09 JL, Thanks for the reply. It's always difficult to choose between multiple = solutions when there are so many tradeoffs between the solutions. =20 =20 Regarding the optimization where the PCE sends the LSR the unsolicited = computed path segment. It was a difficult choice whether or not to = include a description of this in the original draft, since it is more = complex. Which aspect of the optimization seemed most important? Was it = that it's more efficient during LSP setup or because it could be used to = shift the burden of maintaining state from the PCE to the LSR?=20 =20 IMO the most important optimization is the gain in LSP setup time, = which may be significant, and this is of particular =20 importance during end-to-end LSP restoration upon failure. Let's assume an inter-AS path computation with an AS-path length =3D N: -Without this optimization the LSP signaling time would be N* = Intra-AS-RSVP-sig + N* LSR-PCE exchanges. -With this optimization the LSP signaling time would be N* = Intra-AS-RSVP-sig Hence the gain in signaling time is N*LSR-PCE exchanges. And the good thing is that the path computation time would not be = impacted at all by this procedure as the PCE-LSR unsolicited = notification is done in // with the BRPC procedure. =20 There may be one minor con: During the BRPC you don't know a priori = which path segment will finally be selected, hence you need to send the = path segment to all ASBR LSRs connected to the upstream AS...but this is = a minor issue, because there are not so many ASBRs connected to the = upstream AS (two or three). You will have to remove the information on = the ASBR if no Path message is received after the expiration of a = timer... =20 Regards, =20 JL =20 =20 =20 =20 =20 =20 =20 =20 Thanks once again for your opinion.=20 Best Regards, Rich =20 =09 ________________________________ From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]=20 Sent: Friday, April 21, 2006 12:51 PM To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) Cc: ccamp@ops.ietf.org; pce@ietf.org Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =20 Hi JP, Richard =20 Please see inline, =20 =09 ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 6 avril 2006 14:52 =C0 : Rich Bradford Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. Hi,=20 =20 Thanks for the summary Rich. =20 PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution,=20 =20 Yes definitely, confidentiality is a key requirements in an = inter-provider context. =20 (2) You would prefer one solution (which one and why ?)=20 =20 (3) You think that there is a need for both=20 =20 Answer to (2) and (3): It seems to me that we should end-up with a single solution so as to = ease interworking. IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be = loose anyway, so there will not be any confidentiality issue.=20 If have some concerns regarding the cost of encryption, particularly = for large paths (we need to think about future P2MP applications with a = large number of hops...). By the way, encryption approaches are really = vulnerable to DoS attacks. Hence I would strongly favor the PKS solution. The optimization = suggested, which consists of sending the computed path segment to the = LSR in an unsolicited manner, just after the computation, sounds = relevant and should be further investigated. =20 Best Regards, =20 JL =20 =20 =20 =20 Thanks. =20 JP. =20 On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: =09 =09 =09 Hi, As suggested in Dallas, I've described some of the tradeoffs between = the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt. -- Rich The Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.=20 In short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it in a database and replacing it with a key in the ERO. During = the LSP setup, the ingress LSR for that AS must query the PCE for an = expansion. The PRS solution allows a CPS for an AS to be hidden by encrypting it, = which may be done by a PCE or by the Head-End LSR. During the LSP setup, = the ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).=20 The major differences between the mechanisms involve (1) additional = control messages, (2) performance issues expanding those objects, (3) = the addition of state to the PCE, (4) the solution scope (i.e. = applicability to various topologies of each solution.), and (5) the size = of objects added to existing messages. (1) Additional Control Message Overhead: The PKS solution requires a mechanism to expand the Path Key upon = receipt of the LSP setup request. Since the PCE which calculated the = Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS solution. (2) PCE and LSR Performance: The PKS solution must maintain a (temporary) database of keys adding = overhead to the PCE. The PRS solution requires the encryption of the CPS = in the PCE and decryption of the CPS in the LSR, which could be CPU = intensive. Note that in case of a burst of requests, encryption of large = number of CPS may have an impact on the PCE response time. (3) Addition of State in the PCE: The PKS solution requires the addition of path-specific state and = maintenance of a database in the PCE. The PRS solution requires no = additional state. (4) Solution Scope: The PKS and PRS solutions both work well in conjunction with a PCE to = encode and decode the CPS. However the PKS provides no direct solution = without a PCE. This prevents the PKS solution for working in the case = where A's network straddles B's network and where A wants to use an ERO = for a segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading. (5) Message Object Overhead: The PKS solution provides a very compact key or token to identify a = path segment, which generally allows for smaller EROs to be returned by = the PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution. Please note that the tradeoffs listed here are for the current I-D. = Some of the shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two solutions. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01C669FD.758FF101 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Richard,

Please see inline,

De : Rich Bradford (rbradfor) = [mailto:rbradfor@cisco.com]
Envoy=E9 : lundi 24 avril = 2006=20 20:06
=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean = Philippe Vasseur=20 (jvasseur)
Cc : ccamp@ops.ietf.org;=20 pce@ietf.org
Objet : RE: [Pce] Comparison of Encryption = vs.=20 Path Key Solutions for the CPSID.

JL,

Thanks=20 for the reply. It=92s always difficult to choose between multiple = solutions when=20 there are so many tradeoffs between the solutions. =20

Regarding = the=20 optimization where the PCE sends the LSR the unsolicited computed path = segment. It was a difficult choice whether or not to include a=20 description of this in the original draft, since it is more complex. = Which=20 aspect of the optimization seemed most important? Was it that it=92s = more=20 efficient during LSP setup or because it could be used to shift the = burden of=20 maintaining state from the PCE to the LSR?

IMO the most important = optimization=20 is the gain in LSP setup time, which may be significant, and = this is=20 of particular

importance during end-to-end = LSP=20 restoration upon failure.

Let's assume an inter-AS = path=20 computation with an AS-path length =3D = N:

-Without this optimization = the LSP=20 signaling time would be N* Intra-AS-RSVP-sig + N* LSR-PCE=20 exchanges.

-With this optimization the = LSP=20 signaling time would be N* = Intra-AS-RSVP-sig

Hence the gain in signaling = time is=20 N*LSR-PCE exchanges.

And the good thing = is that the=20 path computation time would not be impacted at all by this = procedure as=20 the PCE-LSR unsolicited notification is done in // with the BRPC=20 procedure.

There may be one minor con:=20 During the BRPC you don't = know a priori=20 which path segment will finally be selected, hence you need to send = the path=20 segment to all ASBR LSRs connected to the upstream AS...but = this is=20 a minor issue, because there are not so many ASBRs connected to the = upstream=20 AS (two or three). You will have to remove the information = on the=20 ASBR if no Path message is received after the expiration of a=20 timer...

Regards,

JL

<= /P>
Thanks=20 once again for your opinion.

Best=20 Regards,

=20 Rich

From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN=20 [mailto:jeanlouis.leroux@francetelecom.com]
Sent: Friday, April 21, 2006 = 12:51=20 PM
To: Jean = Philippe Vasseur=20 (jvasseur); Rich Bradford (rbradfor)
Cc: ccamp@ops.ietf.org;=20 pce@ietf.org
Subject: RE:=20 [Pce] Comparison of Encryption vs. Path Key Solutions for the=20 CPSID.

Hi JP,=20 Richard

Please see=20 inline,

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 6 avril = 2006=20 14:52
=C0 : = Rich=20 Bradford
Cc :=20 ccamp@ops.ietf.org; pce@ietf.org
Objet : Re: [Pce] = Comparison of=20 Encryption vs. Path Key Solutions for the CPSID.

Hi,

Thanks for the summary=20 Rich.

PCE WG members: thanks to provide your = feedback on=20 whether:

(1) You think that there is a need for = such=20 solution,

Yes = definitely,=20 confidentiality is a key requirements in an inter-provider=20 context.

(2) You would prefer one solution (which = one and why=20 ?)

(3) You think that there is a need for=20 both

Answer to = (2) and=20 (3):

It seems = to me that=20 we should end-up with a single solution so as to ease=20 interworking.

IMO in an=20 inter-AS MPLS-TE environment without PCEs, the paths will be loose=20 anyway, so there will not be any confidentiality = issue.=20

If have = some=20 concerns regarding the cost of encryption, particularly for = large paths=20 (we need to think about future P2MP applications with a large number = of=20 hops...). By the way, encryption approaches are really vulnerable to = DoS=20 attacks.

Hence = I would=20 strongly favor the PKS solution. The optimization = suggested, which=20 consists of sending the computed path segment to the LSR in an = unsolicited=20 manner, just after the computation, sounds relevant and should = be=20 further investigated.

Best=20 Regards,

JL

Thanks.

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford=20 ((rbradfor)) wrote:

Hi,

As = suggested in=20 Dallas, = I=92ve=20 described some of the tradeoffs between the two solutions described = in=20 = draft-rbradfor-ccamp-confidential-segment-00.txt.

-- = Rich

The=20 Confidential Path Segment (CPS) ID provides two very different but = equally=20 valid solutions, the Path Key Subobject (PKS) solution and the = Private Route=20 Subobject (PRS) solution. This note examines a number of the = advantages and=20 disadvantages of each solution. =

In=20 short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it=20 in a database and replacing it with a key in the ERO. During the LSP = setup,=20 the ingress LSR for that AS must query the PCE for an=20 expansion.

The PRS solution=20 allows a CPS for an AS to be hidden by encrypting it, which may be = done by a=20 PCE or by the Head-End LSR. During the LSP setup, the ingress LSR = for that=20 AS must use a decryption key to obtain the expansion (implying an = earlier=20 exchange or configuration).

The=20 major differences between the mechanisms involve (1) additional = control=20 messages, (2) performance issues expanding those objects, (3) the = addition=20 of state to the PCE, (4) the solution scope (i.e. applicability to = various=20 topologies of each solution.), and (5) the size of objects added to = existing=20 messages.

(1)=20 Additional Control Message = Overhead:

The PKS solution=20 requires a mechanism to expand the Path Key upon receipt of the LSP = setup=20 request. Since the PCE which calculated the Path Key might not = reside in the=20 entry boundary LSR, the LSR must request the expansion from the PCE, = requiring an additional message exchange before LSP setup can = proceed. The=20 Path Encryption solution does not require this extra exchange = between the=20 PCE and the ingress node for every LSP. Rather, the decryption key = needs to=20 be exchanged only when it is changed. The result is additional delay = during=20 every LSP setup for the PKS solution but no additional delay for the = PRS=20 solution.

(2) PCE and LSR=20 Performance:

The PKS solution=20 must maintain a (temporary) database of keys adding overhead to the = PCE. The=20 PRS solution requires the encryption of the CPS in the PCE and = decryption of=20 the CPS in the LSR, which could be CPU intensive. Note that in case = of a=20 burst of requests, encryption of large number of CPS may have an = impact on=20 the PCE response time.

(3)=20 Addition of State in the = PCE:

The PKS solution=20 requires the addition of path-specific state and maintenance of a = database=20 in the PCE. The PRS solution requires no additional=20 state.

(4) Solution=20 Scope:

The PKS and PRS=20 solutions both work well in conjunction with a PCE to encode and = decode the=20 CPS. However the PKS provides no direct solution without a PCE. This = prevents the PKS solution for working in the case where A's network=20 straddles B's network and where A wants to use an ERO for a segment = of the=20 LSP across the intervening network, e.g. (netA)-(netB)-(netA). In = addition,=20 the PRS could be used to record a CPS even if the path (and = therefore the=20 returned RRO) crosses multiple boundaries. Finally, a PRS solution = could be=20 adapted to return actual failure locations in PERRs and/or = PATHTEARs, while=20 keeping the failure location confidential from LSRs without a = decryption=20 key. Currently privacy of this source is maintained by returning the = address=20 of border nodes, which can be very=20 misleading.

(5)=20 Message Object Overhead:

The PKS solution=20 provides a very compact key or token to identify a path segment, = which=20 generally allows for smaller EROs to be returned by the PCE and to = be=20 requested in the resulting PATH message. A PRS which contains a CPS = must=20 generally be at least as large as the unencrypted PATH through the = AS and=20 may be significantly larger if it is desirable to hide the number of = hops=20 within the network from external view by padding the PRS. The result = is=20 potentially larger PATH (and PCEP) messages for the PRS=20 solution.

Please note that the = tradeoffs=20 listed here are for the current I-D. Some of the shortcomings of = each=20 approach could be mitigated by implementation-specific = optimizations. For=20 example, a PCE could choose to signal the CPS expansion to the entry = boundary LSR, shifting the burden of maintaining the PKS state to = the LSR=20 and eliminating the performance hit during LSP setup. A similar = exchange=20 could be performed for the PRS case, eliminating the need for a = separate key=20 exchange. These examples of extensions are beyond the scope of the = ID, but=20 might be useful when weighing the pros and cons of the two=20 solutions.

___________= ____________________________________

Pce mailing = list

Pce@lists.ietf.org

https://www1.ietf.org= /mailman/listinfo/pce

<= /BLOCKQUOTE> ------_=_NextPart_001_01C669FD.758FF101-- --===============0559392960== 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 --===============0559392960==-- From pce-bounces@lists.ietf.org Thu Apr 27 09:43:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6lz-0001b7-4O; Thu, 27 Apr 2006 09:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6dA-0006Id-Sb for pce@ietf.org; Thu, 27 Apr 2006 09:34:04 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6VS-0004Yi-3f for pce@ietf.org; Thu, 27 Apr 2006 09:26:07 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2006 06:26:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208,217"; a="26811744:sNHT74531850" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3RDQ3vF007607; Thu, 27 Apr 2006 09:26:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 09:26:04 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 09:26:00 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Message-Id: <4CA3EE07-6890-452C-AE6B-BD8EA4128412@cisco.com> From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Thu, 27 Apr 2006 09:25:58 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 13:26:00.0225 (UTC) FILETIME=[1FC4F910:01C669FE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8d99e2862a1ba097be60bce990cc30ed X-Mailman-Approved-At: Thu, 27 Apr 2006 09:43:09 -0400 Cc: ccamp@ops.ietf.org, 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="===============1723186209==" Errors-To: pce-bounces@lists.ietf.org --===============1723186209== Content-Type: multipart/alternative; boundary=Apple-Mail-53-333433759 --Apple-Mail-53-333433759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Jean-Louis, On Apr 27, 2006, at 9:21 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Richard, > > Please see inline, > > De : Rich Bradford (rbradfor) [mailto:rbradfor@cisco.com] > Envoy=E9 : lundi 24 avril 2006 20:06 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur) > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > JL, > > Thanks for the reply. It=92s always difficult to choose between =20 > multiple solutions when there are so many tradeoffs between the =20 > solutions. > > > > Regarding the optimization where the PCE sends the LSR the =20 > unsolicited computed path segment. It was a difficult choice =20 > whether or not to include a description of this in the original =20 > draft, since it is more complex. Which aspect of the optimization =20 > seemed most important? Was it that it=92s more efficient during LSP =20= > setup or because it could be used to shift the burden of =20 > maintaining state from the PCE to the LSR? > > > IMO the most important optimization is the gain in LSP setup time, =20 > which may be significant, and this is of particular > > importance during end-to-end LSP restoration upon failure. > > Let's assume an inter-AS path computation with an AS-path length =3D = N: > > -Without this optimization the LSP signaling time would be N* Intra-=20= > AS-RSVP-sig + N* LSR-PCE exchanges. > > -With this optimization the LSP signaling time would be N* Intra-AS-=20= > RSVP-sig > > Hence the gain in signaling time is N*LSR-PCE exchanges. > > And the good thing is that the path computation time would not be =20 > impacted at all by this procedure as the PCE-LSR unsolicited =20 > notification is done in // with the BRPC procedure. > > > There may be one minor con: During the BRPC you don't know a priori =20= > which path segment will finally be selected, hence you need to send =20= > the path segment to all ASBR LSRs connected to the upstream =20 > AS...but this is a minor issue, because there are not so many ASBRs =20= > connected to the upstream AS (two or three). You will have to =20 > remove the information on the ASBR if no Path message is received =20 > after the expiration of a timer... Agree, this is a temporary state ... that would have been maintained =20 by the PCE anyway. Cheers. JP. > > Regards, > > > JL > > > > > > > > > > > Thanks once again for your opinion. > > Best Regards, > > Rich > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Friday, April 21, 2006 12:51 PM > To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) > Cc: ccamp@ops.ietf.org; pce@ietf.org > Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > > > Hi JP, Richard > > > > Please see inline, > > > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 6 avril 2006 14:52 > =C0 : Rich Bradford > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > Hi, > > > > Thanks for the summary Rich. > > > > PCE WG members: thanks to provide your feedback on whether: > > (1) You think that there is a need for such solution, > > > > Yes definitely, confidentiality is a key requirements in an inter-=20 > provider context. > > > > (2) You would prefer one solution (which one and why ?) > > > > (3) You think that there is a need for both > > > > Answer to (2) and (3): > > It seems to me that we should end-up with a single solution so as =20 > to ease interworking. > > IMO in an inter-AS MPLS-TE environment without PCEs, the paths will =20= > be loose anyway, so there will not be any confidentiality issue. > > If have some concerns regarding the cost of encryption, =20 > particularly for large paths (we need to think about future P2MP =20 > applications with a large number of hops...). By the way, =20 > encryption approaches are really vulnerable to DoS attacks. > > Hence I would strongly favor the PKS solution. The optimization =20 > suggested, which consists of sending the computed path segment to =20 > the LSR in an unsolicited manner, just after the computation, =20 > sounds relevant and should be further investigated. > > > > Best Regards, > > > > JL > > > > > > > > > > Thanks. > > > > JP. > > > > On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > > > > > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-53-333433759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi = Jean-Louis,

On Apr 27, 2006, at 9:21 AM, LE ROUX = Jean-Louis RD-CORE-LAN wrote:

Rich Bradford = (rbradfor) [mailto:rbradfor@cisco.com] =
lundi 24 avril 2006 20:06
=C0=A0: LE ROUX Jean-Louis RD-CORE-LAN; = Jean Philippe Vasseur (jvasseur)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] Comparison of Encryption vs. Path Key = Solutions for the CPSID.

JL,
Thanks for the = reply. It=92s always difficult to choose between multiple solutions when = there are so many tradeoffs between the solutions.=A0
=A0
IMO=A0the most important optimization is the gain in = LSP setup time, which=A0may be=A0significant, and this is of = particular=A0
importance during end-to-end LSP restoration upon = failure.
Let's assume an inter-AS path computation with an = AS-path length =3D N:
-Without this = optimization the LSP signaling time would be N* Intra-AS-RSVP-sig + N* = LSR-PCE exchanges.
-With this optimization = the LSP signaling time would be N* = Intra-AS-RSVP-sig
Hence the gain in = signaling time is N*LSR-PCE = exchanges.
And=A0the good thing is=A0that the path computation = time=A0would not be impacted at all by this procedure as the PCE-LSR = unsolicited notification is done in // with the BRPC = procedure.
=A0
There may be one minor con: = During the BRPC you don't = know a priori which path segment will finally be selected, hence you = need to send the path segment=A0to all ASBR LSRs=A0connected to the = upstream AS...but this is a minor issue, because there are not so many = ASBRs connected to the upstream AS (two or three).=A0You will have = to=A0remove the information on the ASBR=A0if no Path message is received = after the expiration of a = timer...
<= /BLOCKQUOTE>Agree, this is a temporary state ... that would have been = maintained by the PCE anyway.

Cheers.

JP.
=A0
Regards,
=A0
JL
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0Thanks once again for your = opinion.
Best = Regards,
=A0 = Rich
LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux= @francetelecom.com]
Sent: Friday, April 21, 2006 12:51 PM
Jean Philippe = Vasseur (jvasseur); Rich Bradford (rbradfor)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.
=A0
Hi JP, Richard
=A0
Please see inline,
=A0

De=A0: JP Vasseur [mailto:jvasseur@cisco.com] =
jeudi 6 avril = 2006 14:52
Rich = Bradford
ccamp@ops.ietf.org; pce@ietf.org
Re: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.
Hi,
=A0
Thanks for the summary Rich.=A0
PCE WG members: thanks to provide your = feedback on whether:
(1) You think that there is a need for such = solution,=A0=A0Yes definitely, = confidentiality is a key requirements in an inter-provider = context.
=A0
(2) You would prefer one solution (which one = and why ?)=A0=A0(3) You think that there is a need for = both=A0=A0Answer to (2) and = (3):
It seems to me that we = should end-up with a single solution so as to=A0ease = interworking.
IMO=A0in an inter-AS MPLS-TE environment without PCEs, the = paths will be loose anyway,=A0so there=A0will not be=A0any = confidentiality issue.
If have some concerns=A0regarding the cost of encryption, = particularly for large paths (we need to think about future P2MP = applications with a large number of hops...). By the way, encryption = approaches are really vulnerable to DoS = attacks.
Hence I=A0would = strongly favor the PKS solution. The optimization suggested,=A0which = consists of sending the computed path segment to the LSR in an = unsolicited manner, just after the computation,=A0sounds relevant and = should be further investigated.=A0Best = Regards,
=A0
JL
=A0
=A0
=A0
=A0
Thanks.
=A0
JP.
On Apr 5, 2006, at 6:19 PM, Rich Bradford = ((rbradfor)) wrote:

Hi,As suggested in , I=92ve described some of the tradeoffs between the = two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.-- = RichThe = Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.In short: The = PKS solution allows a PCE to hide the CPS for an AS by saving it in a = database and replacing it with a key in the ERO. During the LSP setup, = the ingress LSR for that AS must query the PCE for an = expansion.
The PRS = solution allows a CPS for an AS to be hidden by encrypting it, which may = be done by a PCE or by the Head-End LSR. During the LSP setup, the = ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).The major = differences between the mechanisms involve (1) additional control = messages, (2) performance issues expanding those objects, (3) the = addition of state to the PCE, (4) the solution scope (i.e. applicability = to various topologies of each solution.), and (5) the size of objects = added to existing messages.
(1) Additional = Control Message Overhead:
The PKS = solution requires a mechanism to expand the Path Key upon receipt of the = LSP setup request. Since the PCE which calculated the Path Key might not = reside in the entry boundary LSR, the LSR must request the expansion = from the PCE, requiring an additional message exchange before LSP setup = can proceed. The Path Encryption solution does not require this extra = exchange between the PCE and the ingress node for every LSP. Rather, the = decryption key needs to be exchanged only when it is changed. The result = is additional delay during every LSP setup for the PKS solution but no = additional delay for the PRS solution.
(2) PCE and LSR Performance:The PKS = solution must maintain a (temporary) database of keys adding overhead to = the PCE. The PRS solution requires the encryption of the CPS in the PCE = and decryption of the CPS in the LSR, which could be CPU intensive. Note = that in case of a burst of requests, encryption of large number of CPS = may have an impact on the PCE response time.(3) Addition = of State in the PCE:
The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.
(4) Solution = Scope:
The PKS and = PRS solutions both work well in conjunction with a PCE to encode and = decode the CPS. However the PKS provides no direct solution without a = PCE. This prevents the PKS solution for working in the case where A's = network straddles B's network and where A wants to use an ERO for a = segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading.
(5) Message Object Overhead:The PKS = solution provides a very compact key or token to identify a path = segment, which generally allows for smaller EROs to be returned by the = PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.
Please note = that the tradeoffs listed here are for the current I-D. Some of the = shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two = solutions.
Pce mailing list
https://www1.ietf.org/mailman/listinfo/pce

= --Apple-Mail-53-333433759-- --===============1723186209== 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 --===============1723186209==-- From pce-bounces@lists.ietf.org Fri Apr 28 12:52:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWD4-0007ct-Fn; Fri, 28 Apr 2006 12:52:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZWD3-0007co-Ro for pce@ietf.org; Fri, 28 Apr 2006 12:52:49 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZWD2-0005ZI-8D for pce@ietf.org; Fri, 28 Apr 2006 12:52:49 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 18:52:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Apr 2006 18:52:45 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026035E86A2@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MPLS2006 INTERNATIONAL CONFERENCE] Reminder, CFP : one month left Thread-Index: AcZq5CqRt18EcZEOQy6cCO0DFxi/9g== From: "MOIGNARD Renaud RD-CORE-LAN" To: X-OriginalArrivalTime: 28 Apr 2006 16:52:46.0868 (UTC) FILETIME=[2D1E3540:01C66AE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Subject: [Pce] [MPLS2006 INTERNATIONAL CONFERENCE] Reminder, CFP : one month left 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="===============1535627936==" Errors-To: pce-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1535627936== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66AE4.2CA1858C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66AE4.2CA1858C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MPLS 2006 INTERNATIONAL CONFERENCE=20 http://www.mpls2006.com=20 OCTOBER 15-18, 2006=20 WASHINGTON, DC=20 Reminder : one month left for the paper submission !!! CALL FOR PRESENTATION=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 MPLS 2006 (), the 9th Annual International = Conference on MPLS and Related Technologies, will be held on October 15 = through 18, 2006, in Washington, DC. The Program Committee of MPLS2006 = is soliciting presentation proposals for the conference. If you wish to = suggest a particular topic for possible presentation at the event, = please send a one page proposal (including speaker's contact = information) to the attention of the Technical Program Committee at = mpls2005-cfp@isocore.com by May 26, 2006. This year's conference will include, but will not be limited to, the = following=20 topics:=20 - MPLS in multi-area and multi-AS networks=20 - Point-to-multipoint MPLS and applications=20 - Supporting multicast in MPLS VPNs and for VPLS=20 - Single and Multi-hop Pseudowire placement, setup and management=20 - Providing QoS in MPLS networks=20 - MPLS network management=20 - OAM for MPLS networks=20 - MPLS in the Next Generation Network=20 - Voice over IP/MPLS=20 - IMS an IPTv over MPLS=20 - Triple-play applications on MPLS=20 - MPLS-enabled Advanced services and converged networks=20 - Interworking and migration for MPLS and GMPLS=20 - Multi-layer networks and integration with non-packet technologies=20 - Deploying, interworking and operating L2 and L3 MPLS VPNs=20 - MPLS deployment experience: scaling, performance and security=20 - Testing the technology: MPLS test tools and experience=20 - Protection, restoration and reliability=20 - Network processors for MPLS and GMPLS=20 - MPLS/GMPLS control plane resilience, scaling and robustness=20 - MPLS TE applications of the Path Computation Element (PCE)=20 - Motivations and requirements for extending MPLS into the access = network=20 - MPLS and IPv6=20 The program committee is looking for original and unpublished work to = continue the tradition initiated by this conference in 1998 of covering = cutting-edge topics. Presentations addressing new technologies and = operational experience are solicited from network equipment vendors, = service providers, the research community, and government and enterprise = users. Renaud Moignard , Ph. D.=20 Head of R&D team - IP/MPLS networks france telecom R&D / CORE/CPN 2, avenue Pierre Marzin, 22307 Lannion C=E9dex, France Tel : +33 2 96 05 35 28 - Fax : +33 2 96 05 18 52 e-mail : renaud.moignard@francetelecom.com ------_=_NextPart_001_01C66AE4.2CA1858C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [MPLS2006 INTERNATIONAL CONFERENCE] Reminder, CFP : one month = left
MPLS 2006 INTERNATIONAL = CONFERENCE
http://www.mpls2006.com
OCTOBER 15-18, = 2006
WASHINGTON, DC
Reminder : = one month left for the paper submission !!!
CALL FOR = PRESENTATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
MPLS 2006 (<http://www.mpls2006.com>), the 9th Annual International = Conference on MPLS and Related Technologies, will be held on October 15 = through 18, 2006, in Washington, DC. The Program Committee of MPLS2006 = is soliciting presentation proposals for the conference. If you wish to = suggest a particular topic for possible presentation at the event, = please send a one page proposal (including speaker's contact = information) to the attention of the Technical Program Committee at = mpls2005-cfp@isocore.com by May 26, 2006.

This year's conference will = include, but will not be limited to, the following
topics:
- MPLS in multi-area and = multi-AS networks
- Point-to-multipoint MPLS = and applications
- Supporting multicast in = MPLS VPNs and for VPLS
- Single and Multi-hop = Pseudowire placement, setup and management
- Providing QoS in MPLS = networks
- MPLS network = management
- OAM for MPLS = networks
- MPLS in the Next Generation = Network
- Voice over = IP/MPLS
- IMS an IPTv over = MPLS
- Triple-play applications on = MPLS
- MPLS-enabled Advanced = services and converged networks
- Interworking and migration = for MPLS and GMPLS
- Multi-layer networks and = integration with non-packet technologies
- Deploying, interworking and = operating L2 and L3 MPLS VPNs
- MPLS deployment experience: = scaling, performance and security
- Testing the technology: = MPLS test tools and experience
- Protection, restoration and = reliability
- Network processors for MPLS = and GMPLS
- MPLS/GMPLS control plane = resilience, scaling and robustness
- MPLS TE applications of the = Path Computation Element (PCE)
- Motivations and = requirements for extending MPLS into the access network
- MPLS and IPv6
The program committee is looking = for original and unpublished work to continue the tradition initiated by = this conference in 1998 of covering cutting-edge topics. Presentations = addressing new technologies and operational experience are solicited = from network equipment vendors, service providers, the research = community, and government and enterprise users.

Renaud = Moignard , Ph. D.
Head of R&D team - = IP/MPLS networks
france = telecom = R&D / CORE/CPN
2, avenue Pierre = Marzin, 22307 Lannion C=E9dex, France
Tel : +33 2 96 05 35 28 = - Fax : +33 2 96 05 18 52
e-mail : = renaud.moignard@francetelecom.com
------_=_NextPart_001_01C66AE4.2CA1858C-- --===============1535627936== 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 --===============1535627936==--