From jon.harrison@metaswitch.com Tue Nov 1 06:41:40 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FC81F0C42 for ; Tue, 1 Nov 2011 06:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzA6cE54OfMI for ; Tue, 1 Nov 2011 06:41:38 -0700 (PDT) Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 85BA21F0C77 for ; Tue, 1 Nov 2011 06:41:37 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by enficsets2.metaswitch.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 1 Nov 2011 13:41:26 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.01.0339.001; Tue, 1 Nov 2011 13:41:33 +0000 From: Jonathan Harrison To: Zhangfatai Thread-Topic: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02 Thread-Index: AcyO+SR1JBDgzbDXQLy9a3WTPeeQgAAKmUiAAADpxYAAsnoXAAAZDjWAAEBtpgAAGMidAAAFxz2AABsxh4AAAqmUgAEU0IzQ Date: Tue, 1 Nov 2011 13:41:32 +0000 Message-ID: References: <8E6DCB79-DEB7-4CBC-9641-54EADF945DFA@ericsson.com> <4EA72DFA.80605@labn.net> <4EA7FB13.2030509@labn.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:41:40 -0000 SGkgRmF0YWksDQoNCkkgYWdyZWUgdGhhdCBubyByZWFsIG5lZWQgdG8gc2VwYXJhdGUgdGhlIGR5 bmFtaWMgYW5kIHN0YXRpYyBpbmZvcm1hdGlvbiwgc28gYWxsIG9mIHRoZSBsYWJlbCBpbmZvcm1h dGlvbiBjYW4gYmUgYWR2ZXJ0aXNlZCBpbiBhIHNpbmdsZSBMU0EuDQoNCklmIHRoZSBvbmx5IG1v dGl2YXRpb24gZm9yIGEgbmV3IHRvcCBsZXZlbCBUTFYgd2FzIHRvIGFsbG93IHRoaXMgc2VwYXJh dGlvbiwgdGhlbiBubyBuZXcgdG9wIGxldmVsIFRMViBpcyBuZWVkZWQgLSBhbGwgb2YgdGhlIFRF IHBhcmFtZXRlcnMgYW5kIGxhYmVsIGF2YWlsYWJpbGl0eSBpbmZvcm1hdGlvbiBmb3IgYSBsaW5r IHNob3VsZCBiZSBhZHZlcnRpc2VkIGluIGEgc2luZ2xlIExTQSBjb250YWluaW5nIGEgc2luZ2xl IExpbmsgVExWLg0KDQpUaGFua3MsDQpKb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBaaGFuZ2ZhdGFpDQpTZW50OiAyNyBPY3RvYmVyIDIwMTEgMDM6 MzYNClRvOiBaaGFuZ2ZhdGFpOyBsYWJuIC0gTG91IEJlcmdlcg0KQ2M6IEpvbmF0aGFuIEhhcnJp c29uOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCByZWdhcmRp bmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIN Cg0KSGkgQWNlZSwgSm9uYXRoYW4gYW5kIExvdSwNCg0KV2hlbiBJIHdhcyBnb2luZyB0byB1cGRh dGUgdGhlIGRyYWZ0LCBJIGZvdW5kIHRoYXQgaXQgY2Fubm90IHNlcGFyYXRlIHRoZSBkeW5hbWlj IGFuZCBzdGF0aWMgbGluayBpbmZvcm1hdGlvbiBieSBpbnRyb2R1Y2luZyBhIG5ldyB0b3AgTGV2 ZWwgTGluayBUTFZzLCBpLmUuLCBpZiB3ZSBzdGlsbCBuZWVkIHRvIHNlcGFyYXRlIHRoZSBkeW5h bWljIGFuZCBzdGF0aWMgbGluayBpbmZvcm1hdGlvbiwgd2UgbWF5IHN0aWxsIG5lZWQgdGhlIHNp bWlsYXIgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFNlY3Rpb24gNCBhbmQgNS4xIG9mIHRoaXMgZHJh ZnQsIHBsZWFzZSBoYXZlIGEgbG9vayBhdCB0aGVzZSBzZWN0aW9ucy4NCg0KV2hlbiBJIGxvb2tl ZCBhdCB3aGF0IEFjZWUgc2FpZCBiZWxvdyBhZ2FpbiwgSSB0aGluayBwZW9wbGUgaW5jbHVkaW5n IG1lIG1heSBtaXggdGhlIG5vZGUgaW5mb3JtYXRpb24gYW5kIGxpbmsgaW5mb3JtYXRpb24gYXQg c29tZSBleHRlbnQuIEFjdHVhbGx5LCB0aGUgY29ubmVjdGl2aXR5IG1hdHJpeCBpcyBhIGtpbmQg b2Ygbm9kZSBpbmZvcm1hdGlvbiBhbmQgaXQgaXMgY2FycmllZCBpbiBhIG5ldyB0b3AgTm9kZSBU TFYuIA0KDQpGb3IgdGhlIGxpbmsgaW5mb3JtYXRpb24sIHRoZXJlIGlzIG5vdCB0b28gbXVjaCBp bmZvcm1hdGlvbihQb3J0IExhYmVsIFJlc3RyaWN0aW9ucywgQXZhaWxhYmxlIExhYmVscywgU2hh cmVkIEJhY2t1cCBMYWJlbHMpLCBzbyBhIHNpbmdsZSBMaW5rIExTQSBzaG91bGQgYmUgT0suIFdo eSB3ZSB3YW50ZWQgdG8gdXNlIG11bHRpcGxlIExTQXMgdG8gYWR2ZXJ0aXNlIHRoZSBzYW1lIGxp bmsgaW5mb3JtYXRpb24/IFRoZSBvcmlnaW5hbCByZWFzb24gaXMgdGhhdCB3ZSB3YW50IHRvIHNl cGFyYXRlIHRoZSBkeW5hbWljIGFuZCBzdGF0aWMgbGluayBpbmZvcm1hdGlvbiB0byByZWR1Y2Ug dGhlIHJvdXRpbmcgc2NhbGFiaWxpdHkgaXNzdWUuDQoNCkhvd2V2ZXIsIEkgdGhpbmsgdGhlIGR5 bmFtaWMgb2YgbGFiZWwgYXZhaWxhYmlsaXR5IGlzIHNpbWlsYXIgdG8gdGhlIGJhbmR3aWR0aCBv ZiBURE0gb3IgUFNDIGFuZCB0aGVyZSBhcmUgbm8gcHJvdG9jb2wgcHJvY2VkdXJlcyBzbyBmYXIg dG8gZGVmaW5lIGhvdyB0byBzZXBhcmF0ZSB0aGUgZHluYW1pYyBhbmQgc3RhdGljIGxpbmsgaW5m b3JtYXRpb24uDQoNClNvLCB0byBtYWtlIHRoaW5ncyBzaW1wbGUsIEkgdGhpbmsgd2UgY2FuIGp1 c3QgdXNlIG9uZSBzaW5nbGUgTFNBIHRvIGluY2x1ZGUgYWxsIHRoZSBpbmZvcm1hdGlvbiBvZiBv bmUgTGluay4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcz8NCg0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQo+PiBXaGlsZSBJIGFkbWl0IHRoZXJlIGlzIHNvbWUgYW1iaWd1aXR5IGhlcmUs IEkgY29uY3VyIHdpdGggSm9uYXRoYW4gdGhhdCB0aGlzIHdvdWxkIHJlc3VsdCBpbiBpbmNvbXBh dGliaWxpdHkgcHJvYmxlbXMgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuIERvIHdlIHJl YWxseSB0aGluayBoYXZlIG1vcmUgaW5mb3JtYXRpb24gZm9yIGEgc2luZ2xlIGxpbmsgdGhhbiB3 aWxsIG5vcm1hbGx5IGZpdCBpbiBhbiBMU0EgdGhhdCBiZSBhZHZlcnRpc2VkIG92ZXIgYSBzdGFu ZGFyZCBldGhlcm5ldCBsaW5rIChNVFUgMTUwMCBieXRlcykgd2l0aG91dCBJUCBmcmFnbWVudGF0 aW9uPyBJZiB0aGlzIGlzIGEgcmFyZSBjYXNlLCBJJ2Qgc2F5IHRoYXQgaXQgaXMgb2sgZm9yIHRo ZSBMU0EgdG8gYmVjb21lIGxhcmdlLCBpLmUuLCByZXF1aXJlIElQIGZyYWdtZW50YXRpb24gZm9y IGFkdmVydGlzZW1lbnQuIElmIHRoZSB3ZSBleHBlY3QgdGhlIGNvbnN0cmFpbnQgaW5mb3JtYXRp b24gdG8gbm9ybWFsbHkgcmVxdWlyZSBmcmFnbWVudGF0aW9uLCBJJ2QgcmVjb21tZW5kIGEgbmV3 IHRvcC1sZXZlbCBUTFYsIHRoZSBMaW5rLUNvbnN0cmFpbnQgVExWLg0KDQoNCg0KDQoNCg0KVGhh bmtzDQrCoA0KRmF0YWkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBaaGFuZ2ZhdGFpDQpTZW50OiAyMDEx5bm0MTDmnIgyN+aXpSA5OjE5DQpUbzogTG91 IEJlcmdlcg0KQ2M6IEpvbmF0aGFuIEhhcnJpc29uOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtDQ0FNUF0gQ29tbWVudCByZWdhcmRpbmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5l cmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDINCg0KSGkgTG91LA0KDQpJIGdvdCB5b3VyIHBvaW50 cy4NCg0KTXkgbGFzdCBzZW50ZW5jZSBzaG91bGQgZ28gdG8gdGhlIFdHLCBJIGp1c3Qgd2FudGVk IHRvIHNlZSB3aGV0aGVyIHRoZXJlIGFyZSBvdGhlciBvcGluaW9ucyBvbiB0aGUgbmV3IHRvcCBs ZXZlbCBsaW5rIFRMVi4gDQoNCg0KDQpUaGFua3MNCsKgDQpGYXRhaQ0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRd IA0KU2VudDogMjAxMeW5tDEw5pyIMjbml6UgMjA6MjENClRvOiBaaGFuZ2ZhdGFpDQpDYzogQWNl ZSBMaW5kZW07IEpvbmF0aGFuIEhhcnJpc29uOyBjY2FtcEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGVAdG9vbHMuaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgcmVnYXJkaW5nIGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyDQoNCkZhdGFpLA0KCQ0KDQpPbiAxMC8y Ni8yMDExIDU6MzUgQU0sIFpoYW5nZmF0YWkgd3JvdGU6DQo+IEhpIExvdSwgQWNlZSBhbmQgYWxs LA0KPiANCj4gSSBhbSBmaW5lIHRvIGhhdmUgYSBuZXcgdG9wIGxldmVsIExpbmsgVExWIHRvIGlu Y2x1ZGUgdGhlIGdlbmVyaWMgbGluayBpbmZvcm1hdGlvbiBpZiB0aGUgV0cgbGlrZSB0aGF0Lg0K PiANCj4gVG8gYXZvaWQgdGhpcyB3b3JrIGJhY2sgYW5kIGZvcnRoLCBwbGVhc2Ugc2hhcmUgeW91 ciBjb25jZXJucyBiZWZvcmUgd2UgdXBkYXRlIHRoaXMgZHJhZnQuDQoNCkknbSBub3Qgc3VyZSB3 aGF0IGFkZGl0aW9uYWwgaW5wdXQgeW91J3JlIGxvb2tpbmcgZm9yLiAgTXkgb25seQ0KYWRkaXRp b25hbCBjb21tZW50IGlzOg0KPiBJIHRoaW5rIHRoZSBtb3JlIHNwZWNpZmljL2RldGFpbGVkIHdl IGNhbiBtYWtlIHRoZW0sDQo+IHRoZSBmYXN0ZXIgdGhlIG9wZW4gZGlzY3Vzc2lvbnMgd2lsbCBi ZSByZXNvbHZlZC4NCg0KSW4gb3RoZXIgd29yZHMsIEkgYmVsaWV2ZSB0aGF0IHNvbWUgbW9yZSBj b25mb3JtYW5jZSBsYW5ndWFnZSBhbmQNCnNwZWNpZmljIHJlcXVpcmVtZW50cyBvbiBmb3JtYXR0 aW5nIGFuZCBUTFYgY29uc3RydWN0aW9uL3BhcnNpbmcgd291bGQNCmJlIGJlbmVmaWNpYWwuDQoN CkxvdQ0KDQo+IA0KPiANCj4gVGhhbmtzDQo+ICANCj4gRmF0YWkNCj4gDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBs YWJuLm5ldF0gDQo+IFNlbnQ6IDIwMTHlubQxMOaciDI25pelIDU6NDYNCj4gVG86IEFjZWUgTGlu ZGVtDQo+IENjOiBaaGFuZ2ZhdGFpOyBKb25hdGhhbiBIYXJyaXNvbjsgY2NhbXBAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlQHRvb2xz LmlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgcmVnYXJkaW5nIGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyDQo+IA0KPiBB Y2VlLA0KPiANCj4gSW4gc2hvcnQgSSBhZ3JlZSB3aXRoIHlvdSAxMDAlLiAgU2VlIGJlbG93IGZv ciBtb3JlIGRldGFpbGVkICByZXNwb25zZXMNCj4gaW4tbGluZS4NCj4gDQo+IE9uIDEwLzI0LzIw MTEgMTE6MDAgQU0sIEFjZWUgTGluZGVtIHdyb3RlOg0KPj4gSGkgRmF0YWksDQo+Pg0KPj4gT24g T2N0IDIzLCAyMDExLCBhdCAxMTowMyBQTSwgWmhhbmdmYXRhaSB3cm90ZToNCj4+DQo+PiBIaSBB Y2VlLA0KPj4NCj4+IFlvdSBzYWlkIGFzIGZvbGxvd3MsIHBsZWFzZSBzZWUgaW5saW5lLg0KPj4g PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQo+Pg0KPj4gSXQgZG9lc24ndCBleHBsaWNpdGx5IHByZXZlbnQgaXQgYnV0IGl0IGRv ZXMgc28gaW1wbGljaXRseS4gSWYgeW91DQo+PiBhZHZlcnRpc2UgbXVsdGlwbGUgT1NQRiBURSBM U0FzIHdpdGggYSB0b3AtbGV2ZWwgTGluayBUTFYgZm9yIHRoZQ0KPj4gc2FtZSBsaW5rLCB0aGVy ZSBpcyBubyB3YXkgdG8gY29ycmVsYXRlIHRoZW0gc2luY2UgUkZDIDM2MzAgZG9lcw0KPj4gc3Bl Y2lmeSB0aGF0IHRoZSBMaW5rIElEIHN1Yi1UTFYgbWF5IG9ubHkgb2NjdXIgYXQgbW9zdCBvbmNl Lg0KPj4NCj4+IFRoZSBMaW5rIFR5cGUgYW5kIExpbmsgSUQgc3ViLVRMVnMgYXJlIG1hbmRhdG9y eSwgaS5lLiwgbXVzdCBhcHBlYXINCj4+IGV4YWN0bHkgb25jZS4gQWxsIG90aGVyIHN1Yi1UTFZz IGRlZmluZWQgaGVyZSBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlLg0KPj4gVGhlc2UgcmVzdHJpY3Rp b25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4gVW5yZWNvZ25pemVkDQo+PiBz dWItVExWcyBhcmUgaWdub3JlZC4NCj4+DQo+PiBbRmF0YWldIEkgdGhpbmsgdGhlIHJlc3RyaWN0 aW9uIGZvciB0aGlzIHBhcmFncmFwaCBzaG91bGQgYmUgaW4gdGhlDQo+PiBzY29wZSBvZiBvbmUg TGluayBUTFYgb3Igb25lIExTQS4gSWYgYSBURSBsaW5rIGlzIGFkdmVydGlzZWQgYnkNCj4+IG11 bHRpcGxlIExTQXMgKHdpdGggbXVsdGlwbGUgTGluayBUTFZzKSwgdGhlIExpbmsgSUQgYW5kIExp bmsgdHlwZQ0KPj4gTVVTVCBiZSBhZHZlcnRpc2VkIHJlc3BlY3RpdmVseSwgYW5kIHRoZW4gd2Ug Y2FuIHVzZSBMaW5rIElEIGFuZCBMaW5rDQo+PiBUeXBlIHRvIGNvcnJlbGF0ZSB0aGVtIGZvciB0 aGUgc2FtZSBURSBsaW5rLg0KPj4NCj4+IFJGQyAzNjMwIG1ha2VzIG5vIHByb3Zpc2lvbiBmb3Ig bXVsdGlwbGUgT1NQRiBURSBMU0FzIHdpdGggYQ0KPj4gdG9wLWxldmVsIExpbmsgVExWIGZvciBh IGdpdmVuIGxpbmsuIEl0IGNvdWxkIGJlIG1hZGUgdG8gd29yayBhcyB5b3UNCj4+IHN1Z2dlc3Qg YnV0IGl0IGNlcnRhaW5seSBpc24ndCBzcGVjaWZpZWQuDQo+Pg0KPj4gV2hpbGUgSSBhZG1pdCB0 aGVyZSBpcyBzb21lIGFtYmlndWl0eSBoZXJlLCBJIGNvbmN1ciB3aXRoIEpvbmF0aGFuDQo+PiB0 aGF0IHRoaXMgd291bGQgcmVzdWx0IGluIGluY29tcGF0aWJpbGl0eSBwcm9ibGVtcyB3aXRoIGV4 aXN0aW5nDQo+PiBpbXBsZW1lbnRhdGlvbnMuIA0KPiANCj4gSSBjb21wbGV0ZWx5IGFncmVlLiAg SSdkIG5lZWQgdG8gY2hlY2sgY29kZSB0byBzZWUgaWYgdGhlIGltcGxlbWVudGF0aW9uDQo+IEkg aGF2ZSBlYXN5IGFjY2VzcyB0byB3aWxsIGhhbmRsZSB0aGlzIGNhc2Ugb24gcmVjZWl2ZSwgYnV0 IEkgY2FuJ3QNCj4gdGhpbmsgb2YgY2FzZSB3aGVyZSBzdWNoIHVzYWdlIHdvdWxkIGJlIGdlbmVy YXRlZC4NCj4gDQo+PiBEbyB3ZSByZWFsbHkgdGhpbmsgaGF2ZSBtb3JlIGluZm9ybWF0aW9uIGZv ciBhDQo+PiBzaW5nbGUgbGluayB0aGFuIHdpbGwgbm9ybWFsbHkgZml0IGluIGFuIExTQSB0aGF0 IGJlIGFkdmVydGlzZWQgb3Zlcg0KPj4gYSBzdGFuZGFyZCBldGhlcm5ldCBsaW5rIChNVFUgMTUw MCBieXRlcykgd2l0aG91dCBJUCBmcmFnbWVudGF0aW9uPw0KPj4gSWYgdGhpcyBpcyBhIHJhcmUg Y2FzZSwgSSdkIHNheSB0aGF0IGl0IGlzIG9rIGZvciB0aGUgTFNBIHRvIGJlY29tZQ0KPj4gbGFy Z2UsIGkuZS4sIHJlcXVpcmUgSVAgZnJhZ21lbnRhdGlvbiBmb3IgYWR2ZXJ0aXNlbWVudC4gSWYg dGhlIHdlDQo+PiBleHBlY3QgdGhlIGNvbnN0cmFpbnQgaW5mb3JtYXRpb24gdG8gbm9ybWFsbHkg cmVxdWlyZSBmcmFnbWVudGF0aW9uLA0KPj4gSSdkIHJlY29tbWVuZCBhIG5ldyB0b3AtbGV2ZWwg VExWLCB0aGUgTGluay1Db25zdHJhaW50IFRMVi4NCj4gDQo+IEFnYWluLCBhZ3JlZSB3aXRoIGJv dGggY29tbWVudHMvcmVjb21tZW5kYXRpb25zLiAgUGVyaGFwcyBjYWxsIGl0IHRoZQ0KPiBMaW5r LUZyYWdtZW50IFRMViwgb3IgUGFydGlhbCBMaW5rIFRMVi4uLg0KPiANCj4+DQo+PiBbRmF0YWld IEkgdGhpbmsgZm9yIHRoZSB0eXBpY2FsIGNhc2VzLCBvbmUgTFNBIChvciBvbmUgTGluayBUTFYp IG1heQ0KPj4gYmUgc3VmZmljaWVudCBmb3IgYSBURSBsaW5rLCBidXQgc29tZSBwZW9wbGUgbGlr ZSB0byBnaXZlIHNvbWUgcmFyZQ0KPj4gb3IgZXh0cmVtZSBleGFtcGxlcyB0byBqdXN0aWZ5IHRo ZWlyIHRob3VnaHQuIENvbXBhcmVkIHdpdGggYSBuZXcNCj4+IHRvcC1sZXZlbCBUTFYsIEkgd291 bGQgc2F5IEkgd291bGQgbGlrZSB0byByZS11c2UgdGhlIGV4aXN0aW5nDQo+PiB0b3AtbGV2ZWwg TGluayBUTFYgYmVjYXVzZSB0aGlzIGZvbGxvd3MgdGhlIOKAnEfigJ0gb2YgR01QTFMuDQo+Pg0K Pj4gSSdsbCBsZXQgTG91IGFuZCBvdGhlciBjb21tZW50IG9uIHdoYXQgaXMgbW9yZSBjb25zaXN0 ZW50IHdpdGggR01QTFMuDQo+IA0KPiBXZWxsIHRoaXMgaXMgc29tZXRoaW5nIGZvciB0aGUgV0cg dG8gZGlzY3Vzcy4gIE15IHBlcnNvbmFsIChub3QgY2hhaXIpDQo+IHBlcnNwZWN0aXZlIHNlZW1z IGFsaWduZWQgd2l0aCB5b3VycyAoQWNlZSdzKS4NCj4gDQo+PiBIb3dldmVyLCBJIHNoYXJlIHRo ZSBjb25jZXJuIHRoYXQgdGhpcyBleHRlbnNpb24gd2lsbCBiZSBpbmNvbXBhdGlibGUNCj4+IHdp dGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gQ291bGQgbm90IGFncmVlIG1vcmUu ICBNeSBpbXByZXNzaW9uIChhcyBjaGFpcikgaXMgdGhhdCBtdWNoIG9mIHRoZSBXU09ODQo+IHJl bGF0ZWQgZGlzY3Vzc2lvbiBoYXMgdG8gZG8gd2l0aCB0aGUgZGVncmVlIHRoYXQgdGhlIGN1cnJl bnQgV0cgZHJhZnRzDQo+IGFyZSBvcGVuIHRvIGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbnMgKGFu ZCBwb3NzaWJsZSBpbmNvbXBhdGlibGUNCj4gaW1wbGVtZW50YXRpb25zKS4gIEkgdGhpbmsgdGhl IG1vcmUgc3BlY2lmaWMvZGV0YWlsZWQgd2UgY2FuIG1ha2UgdGhlbSwNCj4gdGhlIGZhc3RlciB0 aGUgb3BlbiBkaXNjdXNzaW9ucyB3aWxsIGJlIHJlc29sdmVkLg0KPiANCj4gTG91DQo+IA0KPj4N Cj4+IFRoYW5rcywNCj4+IEFjZWVzDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBUaGFua3MN Cj4+DQo+PiBGYXRhaQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBBY2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0NCj4+IFNlbnQ6 IDIwMTHlubQxMOaciDIw5pelIDIxOjUzDQo+PiBUbzogWmhhbmdmYXRhaQ0KPj4gQ2M6IEpvbmF0 aGFuIEhhcnJpc29uOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt b3NwZi10ZUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5l cmFsLWNvbnN0cmFpbnRzLW9zcGYtdGVAdG9vbHMuaWV0Zi5vcmc+OyBjY2FtcEBpZXRmLm9yZzxt YWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21tZW50IHJl Z2FyZGluZyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10 ZS0wMg0KPj4NCj4+IEhpIEZhdGFpLA0KPj4NCj4+IE9uIE9jdCAyMCwgMjAxMSwgYXQgODo0MyBB TSwgWmhhbmdmYXRhaSB3cm90ZToNCj4+DQo+PiBIaSBKb25hdGhhbiwNCj4+DQo+PiBJIGFncmVl IHdpdGggeW91IHRoYXQgUkZDIDM2MzAgZG9lcyBub3Qgc3RhdGUgZXhwbGljaXRseSBob3cgYW4g T1NQRiBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZ2VuZXJhdGUgbXVsdGlwbGUgVEUgbGluayBUTFZz IGZvciB0aGUgc2FtZSBsaW5rLg0KPj4NCj4+IEkgb25seSBzYXcgYSBzZW50ZW5jZSB0byBkZXNj cmliZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gTGluayBUTFYgYW5kIExTQTogIOKAnE9ubHkg b25lIExpbmsgVExWIHNoYWxsIGJlIGNhcnJpZWQgaW4gZWFjaCBMU0EsIGFsbG93aW5nIGZvciBm aW5lIGdyYW51bGFyaXR5IGNoYW5nZXMgaW4gdG9wb2xvZ3ku4oCdDQo+Pg0KPj4gSG93ZXZlciwg b2J2aW91c2x5LCBSRkMgMzYzMCBkb2VzIG5vdCBwcm92ZW50IHRvIGFkdmVydGlzZSBhIFRFIGxp bmsgaW5mb3JtYXRpb24gIGJ5IG11bHRpcGxlIExTQXMgKGluY2x1ZGluZyBvbmx5IG9uZSBsaW5r IFRMViByZXNwZWN0aXZlbHkpLg0KPj4NCj4+IEl0IGRvZXNuJ3QgZXhwbGljaXRseSBwcmV2ZW50 IGl0IGJ1dCBpdCBkb2VzIHNvIGltcGxpY2l0bHkuIElmIHlvdSBhZHZlcnRpc2UgbXVsdGlwbGUg T1NQRiBURSBMU0FzIHdpdGggYSB0b3AtbGV2ZWwgTGluayBUTFYgZm9yIHRoZSBzYW1lIGxpbmss IHRoZXJlIGlzIG5vIHdheSB0byBjb3JyZWxhdGUgdGhlbSBzaW5jZSBSRkMgMzYzMCBkb2VzIHNw ZWNpZnkgdGhhdCB0aGUgTGluayBJRCBzdWItVExWIG1heSBvbmx5IG9jY3VyIGF0IG1vc3Qgb25j ZS4NCj4+DQo+PiAgICBUaGUgTGluayBUeXBlIGFuZCBMaW5rIElEIHN1Yi1UTFZzIGFyZSBtYW5k YXRvcnksIGkuZS4sIG11c3QgYXBwZWFyDQo+PiBleGFjdGx5IG9uY2UuIEFsbCBvdGhlciBzdWIt VExWcyBkZWZpbmVkIGhlcmUgbWF5IG9jY3VyIGF0IG1vc3QNCj4+IG9uY2UuIFRoZXNlIHJlc3Ry aWN0aW9ucyBuZWVkIG5vdCBhcHBseSB0byBmdXR1cmUgc3ViLVRMVnMuDQo+PiBVbnJlY29nbml6 ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuDQo+Pg0KPj4NCj4+IFdoaWxlIEkgYWRtaXQgdGhlcmUg aXMgc29tZSBhbWJpZ3VpdHkgaGVyZSwgSSBjb25jdXIgd2l0aCBKb25hdGhhbiB0aGF0IHRoaXMg d291bGQgcmVzdWx0IGluIGluY29tcGF0aWJpbGl0eSBwcm9ibGVtcyB3aXRoIGV4aXN0aW5nIGlt cGxlbWVudGF0aW9ucy4gRG8gd2UgcmVhbGx5IHRoaW5rIGhhdmUgbW9yZSBpbmZvcm1hdGlvbiBm b3IgYSBzaW5nbGUgbGluayB0aGFuIHdpbGwgbm9ybWFsbHkgZml0IGluIGFuIExTQSB0aGF0IGJl IGFkdmVydGlzZWQgb3ZlciBhIHN0YW5kYXJkIGV0aGVybmV0IGxpbmsgKE1UVSAxNTAwIGJ5dGVz KSB3aXRob3V0IElQIGZyYWdtZW50YXRpb24/IElmIHRoaXMgaXMgYSByYXJlIGNhc2UsIEknZCBz YXkgdGhhdCBpdCBpcyBvayBmb3IgdGhlIExTQSB0byBiZWNvbWUgbGFyZ2UsIGkuZS4sIHJlcXVp cmUgSVAgZnJhZ21lbnRhdGlvbiBmb3IgYWR2ZXJ0aXNlbWVudC4gSWYgdGhlIHdlIGV4cGVjdCB0 aGUgY29uc3RyYWludCBpbmZvcm1hdGlvbiB0byBub3JtYWxseSByZXF1aXJlIGZyYWdtZW50YXRp b24sIEknZCByZWNvbW1lbmQgYSBuZXcgdG9wLWxldmVsIFRMViwgdGhlIExpbmstQ29uc3RyYWlu dCBUTFYuDQo+Pg0KPj4gVGhhbmtzLCBBY2VlDQo+Pg0KPj4NCj4+IFRoaXMgZHJhZnQgW0dFTi1P U1BGXSBkZXNjcmliZXMgdGhlIGV4dGVuc2lvbnMgdG8gUkZDIDM2MzAsIHNvIGl0IGNhbiBkZWZp bmUgdGhlc2UgcHJvY2VkdXJlcy4NCj4+DQo+PiBJIGFncmVlIHdpdGggeW91IHRoYXQgd2Ugc2hv dWxkIGhhdmUgY2xlYXIgZGVzY3JpcHRpb25zIG9uIHlvdXIgdGhyZWUgcG9pbnRzLiBGb3IgdGhl IGZpcnN0IHBvaW50LCBJIHRoaW5rIHRoaXMgZHJhZnQgaGFzIHN0YXRlZCB0aGlzIGV4cGxpY2l0 bHkgaW4gU2VjdGlvbiA0IGFuZCA1LjEuIEZvciB0aGUgb3RoZXIgdHdvIHBvaW50cywgd2UgbmVl ZCBzb21lIHJlZmluZW1lbnRzIHRvIGFkZHJlc3MgdGhlbS4NCj4+DQo+PiBXZSB3aWxsIGFkZCBz b21lIHRleHQgdG8gYWRkcmVzcyB0aGVtIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+Pg0KPj4gPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gLSAgICAgICBBIGNsZWFyIHN0YXRlbWVudCB0aGF0 IG11bHRpcGxlIFRMVnMgYXJlIGFsbG93ZWQgZm9yIHRoZSBzYW1lIGxpbmsuDQo+PiAtICAgICAg IFJ1bGVzIHNwZWNpZnlpbmcgaG93IHN1Yi1UTFZzIGNhbiBiZSBkaXN0cmlidXRlZCBhY3Jvc3Mg dGhlIG11bHRpcGxlIFRMVnMgKGUuZy4gdGhlcmUgbXVzdCBiZSBhdCBtb3N0IG9uZSBBdmFpbGFi bGUgTGFiZWxzIHN1Yi1UTFYgYWNyb3NzIGFsbCBUTFZzIGZvciB0aGUgc2FtZSBsaW5rKS4NCj4+ IC0gICAgICAgUnVsZXMgc3BlY2lmeWluZyBob3cgbXVsdGlwbGUgVExWcyBzaG91bGQgYmUgaW50 ZXJwcmV0ZWQuICAoVGhpcyBzaG91bGQgYmUgc2ltcGxlIGlmIHRoZSBydWxlcyBmb3IgYnVpbGRp bmcgdGhlIFRMVnMgYXJlIHdlbGwgZGVmaW5lZC4pDQo+Pg0KPj4NCj4+IFRoYW5rcw0KPj4NCj4+ IEZhdGFpDQo+Pg0KPj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSm9uYXRoYW4gSGFycmlzb24NCj4+IFNlbnQ6IDIwMTHlubQxMOaciDIw5pelIDE1OjIz DQo+PiBUbzogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYt dGVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1j b25zdHJhaW50cy1vc3BmLXRlQHRvb2xzLmlldGYub3JnPg0KPj4gQ2M6IGNjYW1wQGlldGYub3Jn PG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFtDQ0FNUF0gQ29tbWVudCByZWdh cmRpbmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUt MDINCj4+DQo+PiBIaSBhdXRob3JzLA0KPj4NCj4+IEkgZG9u4oCZdCBrbm93IGlmIHlvdeKAmXZl IGJlZW4gZm9sbG93aW5nIHRoZSB0aHJlYWQgYmVsb3csIGJ1dCB0aGUgZGlzY3Vzc2lvbiBhcHBl YXJzIHRvIGhhdmUgc29tZSByZWxldmFuY2UgdG8gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5l cmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIuDQo+Pg0KPj4gVGhlIGRpc2N1c3Npb24gYmVsb3cg aXMgYWJvdXQgdGhlIExpbmsgVExWIGRlZmluZWQgaW4gUkZDIDM2MzAuICBUaGUgcHJvYmxlbSBp cyB0aGF0IFJGQyAzNjMwIGlzIG5vdCBjbGVhciB3aGV0aGVyIGluZm9ybWF0aW9uIGFib3V0IGEg c2luZ2xlIGxpbmsgY2FuIGJlIHNwcmVhZCBhY3Jvc3MgbW9yZSB0aGFuIG9uZSBMaW5rIFRMVi4g IFNpZ25pZmljYW50bHksIFJGQyAzNjMwIGRvZXMgbm90IHByb3ZpZGUgYW55IHJ1bGVzIGFzIHRv IGhvdyBhbiBPU1BGIGltcGxlbWVudGF0aW9uIHNob3VsZCBnZW5lcmF0ZSBtdWx0aXBsZSBURSBs aW5rIFRMVnMgZm9yIHRoZSBzYW1lIGxpbmsuICBTaW1pbGFybHksIGl0IGRvZXMgbm90IGluZGlj YXRlIGhvdyBhbiBPU1BGIGltcGxlbWVudGF0aW9uIHNob3VsZCBoYW5kbGUgbXVsdGlwbGUgcmVj ZWl2ZWQgTGluayBUTFZzIGZvciB0aGUgc2FtZSBsaW5rLiAgRm9yIGV4YW1wbGUsIGlmIGFuIE9T UEYgaW1wbGVtZW50YXRpb24gcmVjZWl2ZXMgdHdvIExpbmsgVExWcywgYm90aCBvZiB3aGljaCBo YXZlIHRoZSBzYW1lIGxpbmsgdHlwZSBhbmQgbGluayBJRCBzdWItVExWcywgYnV0IGRpZmZlcmVu dCB2YWx1ZXMgZm9yIHRoZSBVbnJlc2VydmVkIGJhbmR3aWR0aCBzdWItVExWLCB3aGF0IHNob3Vs ZCBpdCBkbz8NCj4+DQo+PiBJbiBzdW1tYXJ5LCB0aGUgYmVoYXZpb3Igb2YgYW4gT1NQRiBpbXBs ZW1lbnRhdGlvbiByZWNlaXZpbmcgbXVsdGlwbGUgTGluayBUTFZzIGZvciB0aGUgc2FtZSBsaW5r IGlzIG5vdCB3ZWxsIGRlZmluZWQuICBJIHN1c3BlY3QgdGhhdCBtb3N0IE9TUEYgaW1wbGVtZW50 YXRpb25zIGFzc3VtZSB0aGF0IHRoZXJlIGlzIGF0IG1vc3Qgb25lIExpbmsgVExWIGZvciBlYWNo IGxpbmsuICBIZW5jZSB0aGUgc3VnZ2VzdGlvbiBvZiBzZWN0aW9uIDUgb2YgZHJhZnQtaWV0Zi1j Y2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIgZm9yIHVzaW5nIG11bHRp cGxlIExpbmsgVExWcyBpcyBsaWtlbHkgdG8gbGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5IHByb2Js ZW1zLg0KPj4NCj4+IFRoZSBzb2x1dGlvbiBtaWdodCBiZSB0byBkZWZpbmUgYSBuZXcgVExWIHR5 cGUgKEdlbmVyaWMgTGluayBUTFY/KSBmb3IgZGlzdHJpYnV0aW5nIHRoZSBQb3J0IExhYmVsIFJl c3RyaWN0aW9ucywgQXZhaWxhYmxlIExhYmVscyBhbmQgQXZhaWxhYmxlIFNoYXJlZCBCYWNrdXAg TGFiZWwgc3ViLVRMVnMgaW4gT1NQRiwgYWxvbmcgd2l0aCBhIGNsZWFyIGRlc2NyaXB0aW9uIG9m IGl0cyB1c2UuICBJbiBwYXJ0aWN1bGFyLCB3ZSBuZWVkIHRoZSBmb2xsb3dpbmcuDQo+PiAtICAg ICAgIEEgY2xlYXIgc3RhdGVtZW50IHRoYXQgbXVsdGlwbGUgVExWcyBhcmUgYWxsb3dlZCBmb3Ig dGhlIHNhbWUgbGluay4NCj4+IC0gICAgICAgUnVsZXMgc3BlY2lmeWluZyBob3cgc3ViLVRMVnMg Y2FuIGJlIGRpc3RyaWJ1dGVkIGFjcm9zcyB0aGUgbXVsdGlwbGUgVExWcyAoZS5nLiB0aGVyZSBt dXN0IGJlIGF0IG1vc3Qgb25lIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViBhY3Jvc3MgYWxsIFRM VnMgZm9yIHRoZSBzYW1lIGxpbmspLg0KPj4gLSAgICAgICBSdWxlcyBzcGVjaWZ5aW5nIGhvdyBt dWx0aXBsZSBUTFZzIHNob3VsZCBiZSBpbnRlcnByZXRlZC4gIChUaGlzIHNob3VsZCBiZSBzaW1w bGUgaWYgdGhlIHJ1bGVzIGZvciBidWlsZGluZyB0aGUgVExWcyBhcmUgd2VsbCBkZWZpbmVkLikN Cj4+DQo+PiBMZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4NCj4+DQo+PiBUaGFua3MsDQo+PiBK b24NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGNjYW1w LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQo+PiBTZW50OiAx MCBPY3RvYmVyIDIwMTEgMTc6MzYNCj4+IFRvOiBBbmRyZWEgWmFuYXJkaQ0KPj4gQ2M6IGNjYW1w QGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1v c3BmLTA2LnR4dA0KPj4NCj4+IEhpIEFuZHJlYSwNCj4+DQo+PiBJIHNlZSB5b3VyIHBvaW50IG1v cmUgY2xlYXJseS4gWW91IGFyZSBjb25jZXJuZWQgYWJvdXQgdGhlIGludGVyb3BlcmFiaWxpdHkg aXNzdWUgYmV5b25kIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcm90b2NvbCB0byBlbnN1cmUg dHdvIGltcGxlbWVudGF0aW9ucyBzaG91bGQgaW50ZXJvcGVyYXRlIGVhY2ggb3RoZXIuIFRvIHRo YXQgZW5kLCBwbGVhc2UgcHJvcG9zZSBzb21lIHRleHQuIFRoYW5rcy4NCj4+DQo+PiBCZXN0IFJl Z2FyZHMsDQo+PiBZb3VuZw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBBbmRyZWEgWmFuYXJkaSBbbWFpbHRvOmFuZHJlYS56YW5hcmRpQGNyZWF0ZS1uZXQub3Jn XQ0KPj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDA5LCAyMDExIDExOjUzIEFNDQo+PiBUbzogTGVl eW91bmcNCj4+IENjOiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+PiBT dWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2ln bmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+DQo+PiBIaSBZb3VuZywNCj4+DQo+PiBJ IHRoaW5rIEkgY2xhcmlmaWVkIHdoYXQgSSBtZWFudCBpbiBteSByZXBseSB0byBBY2VlIGNvbW1l bnRzLg0KPj4NCj4+IEFueXdheSwgbXkgb3JpZ2luYWwgY29tbWVudHMgd2VyZSByZWxhdGVkIHRv Og0KPj4NCj4+IGEuICB0aGUgcG9zc2liaWxpdHkgb2Ygc2VuZGluZyBhIFRFIExpbmsgTFNBIHVw ZGF0ZSAoc2FtZSBJRCwgbmV3IHNlcXVlbmNlIG51bWJlcikNCj4+ICAgICAgd2l0aG91dCBzb21l IHN1Yi1UTFZzIGlmIHRoZWlyIHZhbHVlIGlzIHVuY2hhbmdlZCwgYXMgSSB1bmRlcnN0b29kIHdo ZW4geW91IHdyb3RlDQo+Pg0KPj4gICAgICAiQWxsIG90aGVyIHN1Yi1UTFYgYXJlIG9wdGlvbmFs IGFuZCBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlDQo+PiAgICAgICAod2hlbiB0aGVyZSBhcmUgZW5v dWdoIGNoYW5nZXMgZnJvbSB0aGUgcHJldmlvdXMgcGVyaW9kIHRoYXQgZGVzZXJ2ZSBhbiB1cGRh dGUpDQo+PiAgICAgICBhbmQgX25lZWQgbm90XyBiZSBpbmNsdWRlZCBpbiB0aGUgVEUgTGluayBU TFYgd2hlbiB0aGVyZSBpcyBubyBuZWVkIGZvciB1cGRhdGluZy4iDQo+Pg0KPj4gICAgIChidXQg Y29ycmVjdCBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBzZW50ZW5jZSkNCj4+DQo+PiAgICAg VGhpcyBjbGVhcmx5IGNhbid0IHdvcmsgZHVlIHRvIGhvdyB0aGUgVEUgREIgc3luY2hyb25pemF0 aW9uIHdvcmtzLg0KPj4NCj4+ICAgICBOb3RlIHRoYXQgYWxzbyBjcmVhdGluZyBhIG5ldyBMU0Eg KG5ldyBJRCkgd2l0aCBvbmx5IHRoZSBjaGFuZ2VkIHN1Yi1UTFZzIGRvZXNuJ3QNCj4+ICAgICB3 b3JrLCBhcyB5b3Ugd2lsbCBoYXZlIHR3byBkaWZmZXJlbnQgdmFsdWVzIGZvciB0aGUgc2FtZSBz dWItVExWDQo+PiAgICAgKGFzIHRoZSBvbGQgTFNBIGFuZCB0aGUgbmV3IExTQSBhcmUgYm90aCBw cmVzZW50IGluIHRoZSBURSBEQikNCj4+DQo+PiAgICAgSSByZWFkIHRoZSAibWF5IG9jY3VyIGF0 IGxlYXN0IG9uY2UiIGluIFJGQyAzNjMwIGFzOg0KPj4gICAgICJpdCBtYXkgYmUgb21pdHRlZCBp ZiBpdCBkb2VzIG5vdCBhcHBseSB0byB0aGUgbGluayI7DQo+PiAgICAgYnV0IGlmIGl0IGFwcGxp ZXMsIGl0IG11c3QgYmUgcHJlc2VudCBpbiBhbGwgdXBkYXRlcw0KPj4gICAgICh1bmxlc3MgeW91 IHdhbnQgdG8gY2xlYXIgaXRzIHZhbHVlKQ0KPj4NCj4+DQo+PiBiLiB0aGUgZmFjdCB0aGF0IFJG QyAzNjMwIGFsbG93cyB0aGUgcG9zc2liaWxpdHkgb2Ygc3BsaXR0aW5nIHRoZQ0KPj4gICAgIHNl dCBvZiBzdWItVExWcyBvZiBhIFRFIExpbmsgaW4gZGlmZmVyZW50IExTQXMgKGRpZmZlcmVudCBJ RHMpDQo+PiAgICAgW3RoZSBpbXBsZW1lbnRhdGlvbiBJIGNoZWNrZWQgZG9lc24ndCBzdXBwb3J0 IHRoaXMgc2NlbmFyaW9dDQo+Pg0KPj4gICAgIFRoaXMgY291bGQgYmUgYSBtYXR0ZXIgb2YgaW50 ZXJwcmV0YXRpb247IGJ1dCBhcyBpdCdzIG5vdCBleHBsaWNpdGx5DQo+PiAgICAgc3RhdGVkLCB0 aGUgc2ltcGxlc3QgaW50ZXJwcmV0YXRpb24gaXMgdXN1YWxseSB0aGUgb25lIGFjY2VwdGVkLg0K Pj4NCj4+IEkgcGVyZmVjdGx5IGFncmVlIHRoYXQgc3BsaXR0aW5nIGEgc2V0IG9mIGF0dHJpYnV0 ZXMgcmVsYXRlZCB0bw0KPj4gYSAnbG9naWNhbCcgaW5zdGFuY2UgaW4gdHdvIG9yIG1vcmUgZGlm ZmVyZW50IExTQXMgaXMgYSB2aWFibGUgc29sdXRpb24NCj4+IChhcyBmYXIgYXMgeW91IGtlZXAg dGhlIHN1YnNldHMgZGlzam9pbnQgYW5kIHRoZSBzdXBwb3J0IGZvciB0aGlzDQo+PiBzb2x1dGlv biBpcyBleHBsaWNpdGx5IHJlcXVlc3RlZDsgYW5kIHRoaXMgaXMgc29tZWhvdyBzdGF0ZWQNCj4+ IGluIHRoZSBkcmFmdCBpbiBDaGFwLiAzLjIuMSkuDQo+Pg0KPj4gRXZlbiBpZiwgaW4gbXkgb3Bp bmlvbiwgd291bGQgYmUgcHJlZmVyYWJsZSB0byBoYXZlIHNvbWUgcnVsZQ0KPj4gZGVmaW5lZDsg ZXNwZWNpYWxseSBpZiB0aGUgcmVhc29uIGZvciB0aGUgc3BsaXR0aW5nIGlzIHRoZSBkeW5hbWlj cw0KPj4gb2YgdGhlIHVwZGF0ZXMgYW5kIG5vdCBqdXN0IHRoZSBzaXplLg0KPj4NCj4+IFNvcnJ5 IGlmIHRoZXJlIGhhcyBiZWVuIGFueSBtaXN1bmRlcnN0YW5kaW5nLg0KPj4NCj4+IFJlZ2FyZHMN Cj4+IEFuZHJlYQ0KPj4NCj4+DQo+PiBPbiAxMC8wOC8yMDExIDEyOjQ2IEFNLCBMZWV5b3VuZyB3 cm90ZToNCj4+PiBIaSBBbmRyZWEsDQo+Pj4NCj4+PiBTb3JyeSBmb3IgbXkgbGF0ZSByZXNwb25z ZSB0byB5b3VyIHF1ZXN0aW9ucy4gUGxlYXNlIHNlZSBpbi1saW5lIGZvciBteSBjb21tZW50cy4g VGhhbmtzLg0KPj4+DQo+Pj4gWW91bmcNCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogQW5kcmVhIFphbmFyZGkgW21haWx0bzphbmRyZWEuemFuYXJkaUBjcmVh dGUtbmV0Lm9yZ10NCj4+PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA0LCAyMDExIDk6MTAgQU0N Cj4+PiBUbzogTGVleW91bmcNCj4+PiBDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGll dGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+DQo+Pj4gSGkg WW91bmcsDQo+Pj4NCj4+PiB3aXRoIHJlc3BlY3QgdG8gdGhlIFRFIERCIG1hbmFnZW1lbnQgb2Yg bWlzc2luZyBzdWItVExWcyBpbiBMU0EgdXBkYXRlcywNCj4+PiBJIGNoZWNrZWQgdGhlIGJlaGF2 aW9yIG9mIGEgY29tbWVyY2lhbCBPU1BGLVRFIGltcGxlbWVudGF0aW9uLg0KPj4+DQo+Pj4gWU9V Tkc+PiAgSGVyZSBJIGFzc3VtZWQgdGhlIExTQXMgYXJlIHR3byBkaWZmZXJlbnQgTFNBcyAoaWRl bnRpZmllZCBieSB0aGUgTFNBIElEKS4NCj4+Pg0KPj4+IFRoZSBwb2ludCBpcyB0aGF0LCBpZiB0 aGUgVEUgREIgaXMgdGhlIHNldCBvZiBMU0FzLCB0aGF0J3MgaG93IGl0IHdvcmtzDQo+Pj4gYXMg dGhlIFRFIERCIGNvbnRhaW5zIG9ubHkgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGFuIExTQSBpbnN0 YW5jZQ0KPj4+IGFuZCB5b3UgY2FuIG5vdCBtZXJnZSB0aGUgY29udGVudCBvZiBkaWZmZXJlbnQg TFNBIHZlcnNpb25zDQo+Pj4gKHlvdSBjb3VsZCBrZWVwIGFuIGludGVybmFsIG1vZGVsIGZvciB0 aGUgbGlua3Mgd2l0aCB0aGVpciBhdHRyaWJ1dGVzDQo+Pj4gdXBkYXRlZCBpbmRlcGVuZGVudGx5 LCBidXQgd2hlbiB0d28gbmVpZ2hib3JzIHN5bmNocm9uaXplIHRoZWlyIERCLA0KPj4+IHRoZXkg c3luY2hyb25pemUgdGhlIExTQSBzZXQsIG5vdCB0aGUgaW50ZXJuYWwgbW9kZWxzKS4NCj4+Pg0K Pj4+IFlPVU5HPj4gIEhlcmUgaXMgYSBiaXQgY29uZnVzaW5nLiBUaGUgVEUgREIgc3luY2hyb25p emF0aW9uIHByb2Nlc3MgY2hlY2tzIHRoZSBzYW1lIExTQSBhbmQgdGhlIHNlcXVlbmNlIG51bWJl ciAod2hpY2ggeW91IGFyZSByZWZlcnJpbmcgYXMgdGhlIHZlcnNpb24gb2YgYW4gTFNBIGluc3Rh bmNlKS4gV2hlbiB0aGUgbm9kZSBpZGVudGlmaWVzIHRoZSBzYW1lIExTQSB3aXRoIGRpZmZlcmVu dCBzZXF1ZW5jZSBudW1iZXIsIHRoZW4gaXQgZmx1c2hlcyB0aGUgTFNBIHdpdGggdGhlIGxvd2Vy IHNlcXVlbmNlIG51bWJlci4gQnV0IHRoZSBURSBEQiBzeW5jaCBwcm9jZXNzIGRvZXMgbm90IGNo ZWNrIGVhY2ggb3RoZXIgZm9yIGRpZmZlcmVudCBMU0FzICh3aGljaCBpcyBpZGVudGlmaWVkIGJ5 IHRoZSBMU0EgSUQpLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFdpdGggcmVzcGVjdCB0byBSRkMgMzYz MCwgaXQgc3RhdGVzOg0KPj4+DQo+Pj4gICAgMi40LjIuICBMaW5rIFRMVg0KPj4+DQo+Pj4gICAg ICAgVGhlIExpbmsgVExWIGRlc2NyaWJlcyBhIHNpbmdsZSBsaW5rLg0KPj4+DQo+Pj4gSSByZWFk ICdkZXNjcmliZXMnIGFzICdmdWxseSBkZXNjcmliZXMnIChub3QgJ3BhcnRpYWxseSBkZXNjcmli ZXMnKTsNCj4+PiBzbyBJIGRvbid0IHNlZSB3aGVyZSBpdCBzdXBwb3J0cy9zdWdnZXN0cyB0aGUg ZGl2aXNpb24gb2YgdGhlIGF0dHJpYnV0ZXMgb24gbXVsdGlwbGUNCj4+PiBMU0EgaW5zdGFuY2Vz IGFuZCB0aGF0J3Mgd2h5IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIGZvciB0 aGUNCj4+PiBzYW1lIGxpbmsgaXMgbm90IHN1cHBvcnRlZCBieSBjdXJyZW50IGltcGxlbWVudGF0 aW9ucy4NCj4+Pg0KPj4+IFlPVU5HPj4gIFJGQzM2MzAgZGlmZmVyZW50aWF0ZXMgdGhlIG1hbmRh dG9yeSBlbGVtZW50IGZyb20gb3RoZXIgZW50aXRpZXMgdGhhdCBjYW4gYXBwZWFyICJhdCBtb3N0 IiBvbmNlLg0KPj4+IFRoaXMgaXMgZnJvbSBSRkMgMzYzMCBTZWN0aW9uIDIuNC4yOg0KPj4+DQo+ Pj4gICAgIFRoZSBMaW5rIFR5cGUgYW5kIExpbmsgSUQgc3ViLVRMVnMgYXJlIG1hbmRhdG9yeSwg aS5lLiwgbXVzdCBhcHBlYXINCj4+PiAgICAgZXhhY3RseSBvbmNlLiAgQWxsIG90aGVyIHN1Yi1U TFZzIGRlZmluZWQgaGVyZSBtYXkgb2NjdXIgYXQgbW9zdA0KPj4+ICAgICBvbmNlLiAgVGhlc2Ug cmVzdHJpY3Rpb25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4NCj4+PiAgICAg VW5yZWNvZ25pemVkIHN1Yi1UTFZzIGFyZSBpZ25vcmVkLg0KPj4+DQo+Pj4gWU9VTkc+PiAgSXQg ZG9lcyBub3QgbWFuZGF0ZSBvdGhlciBzdWItVExWcyB0byBhcHBlYXIgZXhhY3RseSBvbmNlOyBp dCByYXRoZXIgc2F5cyBpdCBtYXkgb2NjdXIgImF0IG1vc3Qgb25jZSIgLS0gc291bmQgbGlrZSB0 byBtZQ0KPj4+IFlPVU5HPj4gIHRoaXMgaXMgYW4gb3B0aW9uYWwgZWxlbWVudC4NCj4+Pg0KPj4+ IEl0J3MgYSBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiBhbmQgaXQncyBmaW5lIHRvIHN1Z2dlc3Qg aXQgZm9yIG90aGVyIHRvcCBsZXZlbCBUTFZzLA0KPj4+IGJ1dCBpdCdzIG5vdCB0aGUgb25lIGRl ZmluZWQgYnkgUkZDIDM2MzAgZm9yIFRFIExpbmtzLCBpbiBteSBvcGluaW9uLg0KPj4+DQo+Pj4g TXkgcG9pbnQgaXMgaW4gYXZvaWRpbmcgYW1iaWd1aXRpZXM6IGlmIHRoZSBzdXBwb3J0IGZvciBt dWx0aXBsZSBMU0EgaW5zdGFuY2VzIGZvciB0aGUNCj4+PiBzYW1lIGVudGl0eSB0b3AgVExWIGlz IHJlcXVlc3RlZCwgaXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgc3RhdGVkIGFzIG1hbmRhdG9yeQ0K Pj4+IChwb3NzaWJseSBwcm92aWRpbmcgZXhwbGljaXQgcnVsZXMgZm9yIHRoZSBzdWJkaXZpc2lv biwgYXMgaW4gQ2hhcC4gMyBvZiB0aGUgZHJhZnQpLg0KPj4+DQo+Pj4NCj4+PiBZT1VORz4+ICBX aGVuIHlvdSBoYXZlIGRpZmZlcmVudCBzdWItc2V0cyBvZiBUTFYncyB0byBiZSBwYWNrYWdlZCB1 bmRlciB0aGUgT1BTRiBURSBMU0EsIHlvdSBjYW4gdXNlIGEgZGlmZmVyZW50IExTQSBJRCBmcm9t IHRoZSBwcmV2aW91c2x5IHVzZWQgb25lIHRvIGF2b2lkIGFtYmlndWl0aWVzLiBUaGVuIHRoZXNl IGFyZSBzaW1wbHkgdHdvIGRpZmZlcmVudCBMU0FzIGFuZCB3b3VsZCBub3QgY29uZnVzZSB0aGUg VEUgREIgc3luYyBwcm9jZXNzIGFzIHdlbGwgYXMgZmxvb2RpbmcgcHJvY2Vzcy4NCj4+Pg0KPj4+ IFJlZ2FyZHMsDQo+Pj4gQW5kcmVhDQo+Pj4NCj4+PiBPbiAxMC8wMy8yMDExIDA5OjM0IFBNLCBM ZWV5b3VuZyB3cm90ZToNCj4+Pj4gSGkgQW5kcmVhLA0KPj4+Pg0KPj4+PiBUaGFua3MgZm9yIHlv dXIgaW50ZXJlc3QgYW5kIGlucHV0IHRvIHRoaXMgaXNzdWUuDQo+Pj4+DQo+Pj4+IE15IG92ZXJh bGwgcG9pbnQgd2FzIHRoYXQgdGhlIGN1cnJlbnQgR01QTFMgVEUgTFNBIChwZXIgUkZDIDM2MzAp IGRvZXMgbm90IHNwZWNpZnkgZGV0YWlsIGltcGxlbWVudGF0aW9ucyBhcyB0byBob3cgdG8gZGl2 aWRlIHVwIHRoZSBURSBMaW5rIFRMVnMgaW50byBzdGF0aWMgdnMuIGR5bmFtaWMgbm9yIGhvdyB0 byB1c2UgbXVsdGlwbGUgVEUgTFNBcy4gVGhlIGN1cnJlbnQgV1NPTiBkb2N1bWVudCBmb2xsb3dz IGEgc2ltaWxhciBkb2N1bWVudCBwaGlsb3NvcGh5IHdpdGggdGhlIEdNUExTIHByZWRlY2Vzc29y Lg0KPj4+Pg0KPj4+PiBSZWdhcmRpbmcgeW91ciBwb2ludCBvbiBob3cgdGhlIFRFIERCIHdvcmtz IGluIHJlZ2FyZCB0byBtaXNzaW5nIHN1Yi1UTFZzIGFyZSBkZWxldGVkIHNlZW1zIHRvIG1lIGEg cGFydGljdWxhciBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggaXMgbW9zdCBzaW1wbGlzdGljIGluIG5h dHVyZS4NCj4+Pj4NCj4+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+PiBZb3VuZw0KPj4+Pg0KPj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNjYW1wLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZWEgWmFuYXJkaQ0KPj4+PiBTZW50OiBNb25kYXks IE9jdG9iZXIgMDMsIDIwMTEgOToxNCBBTQ0KPj4+PiBUbzogTGVleW91bmcNCj4+Pj4gQ2M6IGNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtD Q0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmls aXR5LW9zcGYtMDYudHh0DQo+Pj4+DQo+Pj4+IEhpIFlvdW5nLA0KPj4+Pg0KPj4+PiBJIHdhcyBm b2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gYW5kIEkgaGF2ZSBhIGRvdWJ0IGFib3V0DQo+Pj4+IHlv dXIgZXhhbXBsZSByZWxhdGVkIHRvIHRoZSBURSBMaW5rIFRMVi4NCj4+Pj4NCj4+Pj4gSXQncyB0 cnVlIHRoYXQgdGhlIGF0dHJpYnV0ZXMgc3ViLVRMViBhcmUgbm90IG1hbmRhdG9yeSBwZXIgUkZD IDM2MzAsDQo+Pj4+IGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgbWVhbnMgdGhhdCB0aGV5IGNhbiBi ZSBub3QgaW5jbHVkZWQgaW4gYW4gTFNBIHVwZGF0ZQ0KPj4+PiBpZiB1bmNoYW5nZWQgKGltcGx5 aW5nIHRoYXQgdGhlIHByZXZpb3VzIHZhbHVlIHBlcnNpc3RzKS4NCj4+Pj4NCj4+Pj4gQXMgZm9y IG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IE9TUEYtVEUgd29ya3MsIHRoZSBtYW5hZ2VkIFRFIERC IGVudGl0eSBpcyB0aGUgTFNBLg0KPj4+PiBXaGVuIGFuIExTQSB1cGRhdGUgaXMgcHJvY2Vzc2Vk LCB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBkZWxldGVkIGZyb20gdGhlIFRFIERCDQo+Pj4+IGFu ZCBpdCBpcyByZXBsYWNlZCBieSB0aGUgbmV3IG9uZTogbGluayBhdHRyaWJ1dGVzIHJlbGF0ZWQg dG8gbWlzc2luZyBzdWItVExWIGFyZQ0KPj4+PiBkZWxldGVkLCBzbyB0aGV5IG11c3QgYmUgcHJl c2VudCBldmVuIGlmIHVuY2hhbmdlZC4NCj4+Pj4NCj4+Pj4gSW4gdGhlb3J5LCB0aGUgc2V0IG9m IGxpbmsgYXR0cmlidXRlcyBjb3VsZCBiZSBzdGF0aWNhbGx5IGRpdmlkZWQNCj4+Pj4gaW4gdHdv IGRpZmZlcmVudCBMU0FzIGluc3RhbmNlcyAodXBkYXRlZCBpbmRlcGVuZGVudGx5KSwNCj4+Pj4g YnV0IEkgZG9uJ3QgdGhpbmsgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgaGFuZGxlIHRoaXMgc2Nl bmFyaW8NCj4+Pj4gKGFsc28gYmVjYXVzZSwgaW4gbXkgb3BpbmlvbiwgaXQncyBub3Qgc3VnZ2Vz dGVkIGJ5IFJGQyAzNjMwIGFuZA0KPj4+PiAgICAgaXQgZ2l2ZXMgbm8gcnVsZSBvbiBob3cgdG8g ZGl2aWRlIHRoZW0pLg0KPj4+Pg0KPj4+PiBCdXQgSSBhc2sgdG8gdGhlIG1haWxpbmcgbGlzdCBp ZiB0aGlzIGlzIHRoZSBjb3JyZWN0IGludGVycHJldGF0aW9uLg0KPj4+Pg0KPj4+PiBSZWdhcmRz LA0KPj4+PiBBbmRyZWENCj4+Pj4NCj4+Pj4gT24gMDkvMzAvMjAxMSAxMToxNiBQTSwgTGVleW91 bmcgd3JvdGU6DQo+Pj4+PiBIaSBQaWVycmUsDQo+Pj4+Pg0KPj4+Pj4gSSBnb3QgeW91ciBwb2lu dC4gTGV0IG1lIGFzayB5b3UgdGhpcyBxdWVzdGlvbi4gSW4gdGhlIGN1cnJlbnQgR01QTFMgT1NQ RiBURSBMaW5rIFRMViBhcmUgZGVmaW5lZCB1bmRlciBPcGFxdWUgVEUgTFNBIHdpdGggdGhlIGZv bGxvd2luZyBhdHRyaWJ1dGVzOg0KPj4+Pj4NCj4+Pj4+IC0gVEUgTWV0cmljDQo+Pj4+PiAtIG1h eCBCL1cNCj4+Pj4+IC0gbWF4IHJlc2VydmFibGUgYi93DQo+Pj4+PiAtIHVucmVzZXJ2ZWQgYi93 DQo+Pj4+PiAtIEFkbWluIEdyb3VwDQo+Pj4+PiAtIExpbmsgUHJvdGVjdGlvbiBUeXBlDQo+Pj4+ PiAtIFNSTEcNCj4+Pj4+IC0gSVNDRA0KPj4+Pj4gLSBldGMuDQo+Pj4+Pg0KPj4+Pj4gQW5kIHRo ZXNlIGFyZSBhIG1peHR1cmUgb2Ygc3RhdGljIGFuZCBkeW5hbWljIGluZm9ybWF0aW9uIGFuZCB5 ZXQgdGhleSBhcmUgYXNzZW1ibGVkIHRvZ2V0aGVyIGFzIG9uZSBURSBMaW5rIFRMVi4gRm9yIGlu c3RhbmNlIHRoZSBJU0NEIGlzIHF1aXRlIHNpbWlsYXIgdG8gUmVzb3VyY2UgQmxvY2sgSW5mbyBp biB0aGF0IGl0IGRvZXMgbm90IGNoYW5nZSBvZnRlbiB1bmxlc3MgdGhlcmUgYXJlIG5ldyBlbGVt ZW50cyBhZGRlZCBpbiB0aGUgbm9kZSBvciBjb25maWd1cmF0aW9uIGNoYW5nZXMgYW5kIHlldCBp dCBpcyBwYWNrYWdlZCB0b2dldGhlciB3aXRoIG90aGVyIGR5bmFtaWMgaW5mb3JtYXRpb24uDQo+ Pj4+Pg0KPj4+Pj4gV2h5Pw0KPj4+Pj4NCj4+Pj4+IFRoZXJlIGFyZSBtYW55IHdheXMgdG8ga2Vl cCBzdGF0aWMvdW5jaGFuZ2VkIGluZm9ybWF0aW9uIGZyb20gYmVpbmcgZmxvb2RlZC4gT25seSB0 aGUgTGluayBUeXBlIGFuZCBMaW5rIElEIHdoaWNoIGFyZSBtYW5kYXRvcnkgaW4gdGhlIFRFIExp bmsgVExWIHBlciBSRkMzNjMwLiBBbGwgb3RoZXIgc3ViLVRMViBhcmUgb3B0aW9uYWwgYW5kIG1h eSBvY2N1ciBhdCBtb3N0IG9uY2UgKHdoZW4gdGhlcmUgYXJlIGVub3VnaCBjaGFuZ2VzIGZyb20g dGhlIHByZXZpb3VzIHBlcmlvZCB0aGF0IGRlc2VydmUgYW4gdXBkYXRlKSBhbmQgbmVlZCBub3Qg YmUgaW5jbHVkZWQgaW4gdGhlIFRFIExpbmsgVExWIHdoZW4gdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dXBkYXRpbmcuDQo+Pj4+Pg0KPj4+Pj4gSSByZWFsbHkgZG9uJ3Qgc2VlIHRoZSBuZWVkIGZvciBh IHNlcGFyYXRlIHRvcC1sZXZlbCBUTFYgYW5kL29yIGEgc2VwYXJhdGUgTFNBIGZvciB0aGUgUmVz b3VyY2UgQmxvY2sgaW5mb3JtYXRpb24uDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IFlv dW5nDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+Pj4gRnJvbTogUEVMT1NPLCBQSUVSUkUgKFBJRVJSRSkgW21haWx0bzpwaWVycmUucGVs b3NvQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4+Pj4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDMw LCAyMDExIDk6MzkgQU0NCj4+Pj4+IFRvOiBMZWV5b3VuZzsgY2NhbXBAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wQGlldGYub3JnPg0KPj4+Pj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0DQo+ Pj4+Pg0KPj4+Pj4gSGkgWW91bmcsDQo+Pj4+Pg0KPj4+Pj4gSSB1bmRlcnN0YW5kIHRoZSBjb250 ZW50IG9mIHlvdXIgYW5zd2VyLCBidXQgSSdtIG5vdCBzYXRpc2ZpZWQgd2l0aCBpdC4NCj4+Pj4+ IE15IGNvbmNlcm4gZGVhbHMgd2l0aCBwcm92aWRpbmcgYSB1bmlxdWUgcmVhZGluZy9pbnRlcnBy ZXRhdGlvbiBvZiB0aGUgT1NQRi1URSBleHRlbnNpb25zLg0KPj4+Pj4gV2Ugd291bGQgbGlrZSB0 byBtYWtlIHN1cmUgdGhhdCBhbnkgaW1wbGVtZW50YXRpb24gY29tcGx5aW5nIHRvIHRoZSBkcmFm dHMgd291bGQgcHJvdmlkZSB0aGUgc2FtZSBMU0FzIHdoZW4gYXBwbGllZCB0byB0aGUgc2FtZSBu ZXR3b3JrLg0KPj4+Pj4gV2l0aCB0aGlzIHBlcnNwZWN0aXZlIGluIG1pbmQsIHdlIHdpc2ggdG8g Z2V0IGRyYWZ0cyB3aXRoIHN1ZmZpY2llbnQgZG9jdW1lbnRhdGlvbiB0byBtYWtlIHN1cmUgdGhl IExTQSBkZXNpZ24gcHJvY2VzcyB0byBiZSBkZXBpY3RlZCwgYnkgZGVzaWduIHJ1bGVzLg0KPj4+ Pj4NCj4+Pj4+IEhlbmNlIHRoZSBjb250ZW50IG9mIHlvdXIgYW5zd2VyIGxlYXZpbmcgbWUgdGhl ICJvcHBvcnR1bml0eSB0byBkbyBhcyBJIHdpc2giLCBpcyBub3QgcGxlYXNpbmcgbWUsIEkgd291 bGQgcmF0aGVyIGhhdmUgc3RyaWN0IHJ1bGVzLCBhbmQgZGlzY3Vzc2lvbnMgd2l0aCB0aGUgV0cg b24gdGhlIGRlc2lnbiBvZiB0aG9zZS4NCj4+Pj4+IFRoYXQgaXMgd2h5IGEgZmlyc3QgZGVzaWdu IHJ1bGUsIHdlIGNvdWxkIGFncmVlIG9uIGlzOiB0byBnYXRoZXIgdGhlIFJlc291cmNlIEJsb2Nr IEluZm9ybWF0aW9uIFRMVnMgaW5zaWRlIGEgZGVkaWNhdGVkIExTQSwgcG9zc2libHkgd2l0aCBh IGRlZGljYXRlZCB0b3AtbGV2ZWwgVExWICh3aGljaCBpbiBteSBtaW5kIGFsbG93cyB0byBlbmZv cmNlIHRoaXMgZGVzaWduIHJ1bGUpLg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+ Pj4gLSBQaWVycmUNCj4+Pj4+DQo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+ Pj4+IERlIDogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXQ0KPj4+Pj4gRW52 b3nDqSA6IG1lcmNyZWRpIDI4IHNlcHRlbWJyZSAyMDExIDAwOjA2DQo+Pj4+PiDDgCA6IFBFTE9T TywgUElFUlJFIChQSUVSUkUpOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ DQo+Pj4+PiBPYmpldCA6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAt d3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4NCj4+Pj4+IEhpIFBp ZXJyZSwNCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ugc2VlLWlubGluZSBmb3IgbXkgcmVwbHkgdG8geW91 ciBmaXJzdCBwb2ludC4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gWW91bmcNCj4+Pj4+ DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogUEVMT1NPLCBQ SUVSUkUgKFBJRVJSRSkgW21haWx0bzpwaWVycmUucGVsb3NvQGFsY2F0ZWwtbHVjZW50LmNvbV0N Cj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxMSAzOjI4IEFNDQo+Pj4+PiBU bzogTGVleW91bmc7IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+Pj4+ IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1z aWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4NCj4+Pj4+IEhpIFlvdW5nLCBh bmQgQ0NBTVBlcnMsDQo+Pj4+Pg0KPj4+Pj4gSSB3YXMgb2ZmIHRoZSBtYWlsaW5nIGxpc3RzIGZv ciB0aGUgbGFzdCB0d28gd2Vla3MgYW5kIGJlaW5nIGJhY2sgSSBub3RpY2UgYSBsb3Qgb2YgZXhj aGFuZ2VzLCB3aGljaCBJJ20gdmVyeSBnbGFkIG9mLg0KPj4+Pj4gSSd2ZSBhbHNvIG5vdGljZWQg bWFueSBkcmFmdHMgaGF2ZSBiZWVuIHVwZGF0ZWQuDQo+Pj4+PiBDb25jZXJuaW5nIHRoaXMgc3Bl Y2lmaWMgZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYs IEkgd2FudGVkIHRvIGNvbW1lbnQgc2VjdGlvbiAzLg0KPj4+Pj4gQmFjayBpbiBRdWViZWMsIEkg ZXhwcmVzc2VkIG15IHBvaW50IG9mIHZpZXcgKHNoYXJlZCB3aXRoIEN5cmlsLCBKdWxpZW4gYW5k IEdpb3Zhbm5pKSB0aGF0IGN1cnJlbnQgZHJhZnRzIHdlcmUgbGFja2luZyBndWlkYW5jZSByZWdh cmRpbmcgdGhlIHdheSB0byBkZXNpZ24gTFNBcyB0aGF0IHdlcmUgdG8gZGVwaWN0IGFuIFdTT04g bm9kZSB3aXRoIE9FT3MuDQo+Pj4+PiBUaGlzIHNlY3Rpb24gMyBwcm92aWRlcyBhZGRpdGlvbmFs IG1hdGVyaWFsIHRvIGhlbHAgZGVzaWduaW5nIHRoZSBMU0EuDQo+Pj4+PiBJIHdvdWxkIGxpa2Ug dG8ga25vdyB3aGV0aGVyIGF1dGhvcnMgYXJlIHdpbGxpbmcgdG8gcHVyc3VlIGZ1cnRoZXIgaW4g dGhpcyBkaXJlY3Rpb24sIHdoaWNoIGlzIHRvIG15IG1pbmQgYSByZWFsIGNvcm5lciBzdG9uZSwg dGhhdCB3b3VsZCBoZWxwIGV2ZXJ5b25lIGFncmVlIG9uIGEgc29sdXRpb24uDQo+Pj4+PiBBIGZp cnN0IHBvaW50IGNvdWxkIGNvbmNlcm4gdGhlIFJlc291cmNlIEJsb2NrIEluZm9ybWF0aW9uIChy ZW1pbmRlcjo8UmVzb3VyY2VCbG9ja0luZm8+ICAgIDo6PSAoWzxSZXNvdXJjZVNldD5dPElucHV0 Q29uc3RyYWludHM+ICAgIDxQcm9jZXNzaW5nQ2FwYWJpbGl0aWVzPiAgICA8T3V0cHV0Q29uc3Ry YWludHM+KToNCj4+Pj4+ICAgICAgICAgV2UgYWxsIGFncmVlIHRoYXQgdGhlc2UgaW5mb3JtYXRp b24gYXJlIHN0YXRpYywgdGhhdCB3ZSBzaG91bGQgbm90IHJlcGxpY2F0ZSB0aGlzIFRMViB3aGF0 ZXZlciB0aGUgbnVtYmVyIG5vdCB0aGUgbGF5b3V0IG9mIE9FTyBib2FyZHMgb2YgYSBnaXZlbiB0 eXBlLg0KPj4+Pj4gVGhlbiwgd2UgY291bGQgZGVkaWNhdGUgYSBzcGVjaWZpYyBpbmRlcGVuZGFu dCBmbG9vZGluZyBlbnRpdHkuIFRoaXMgd291bGQgYmUgZGVmaW5lZCBvbmNlIGZvciBhbGwsIGFu ZCB0aGF0IHdvdWxkIG5vdCBsZWF2ZSByb29tIHRvIGRpZmZlcmVudCBpbnRlcnByZXRhdGlvbnMu DQo+Pj4+PiBXaGF0IGFib3V0IHRoaXMgZmlyc3QgcG9pbnQ/DQo+Pj4+Pg0KPj4+Pj4gWU9VTkc+ PiAgICBJZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSwgd2hhdCB5b3UgYXJlIHNheWluZyBp cyBzaW5jZSB0aGUgUmVzb3VyY2UgQmxvY2sgSW5mbyBzdWItVExWIGlzIHZlcnkgc3RhdGljIGlu IG5hdHVyZSwgYWR2ZXJ0aXNlbWVudCBvZiB0aGlzIHN1Yi1UTFYgc2hvdWxkIGJlIHRyZWF0ZWQg ZGlmZmVyZW50bHkgZnJvbSB0aGUgcmVzdCBvZiBzdGF0aWMtVExWcyAod2hpY2ggbWF5IGNoYW5n ZSBvdmVyIHRpbWUpLiBJcyB0aGlzIHdoYXQgeW91IGFyZSBzYXlpbmc/DQo+Pj4+Pg0KPj4+Pj4g SWYgbXkgaW50ZXJwcmV0YXRpb24gb2YgeW91ciBjb21tZW50IGlzIGNvcnJlY3QsDQo+Pj4+Pg0K Pj4+Pj4gLSBUaGUgY3VycmVudCBtZWNoYW5pc20gYWxsb3dzIHdoYXQgeW91IHdhbnQ6IFBsZWFz ZSBzZWUgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDMuMg0KPj4+Pj4gICAgICAgIklu IHRoZSBoaWdobHkgdW5saWtlbHkgZXZlbnQgdGhhdCBhIFdTT04gc3ViLVRMViBieSBpdHNlbGYg d291bGQNCj4+Pj4+ICAgICAgIHJlc3VsdCBpbiBhbiBMU0EgZXhjZWVkaW5nIHRoZSBNVFUsIGFs bCBmaXZlIFdTT04gc3BlY2lmaWMgc3ViLVRMVnMNCj4+Pj4+ICAgICAgIGluIHRoaXMgZG9jdW1l bnQgcHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgYWxsb3cgdGhlbSB0byBiZSBzdWJkaXZpZGVkDQo+ Pj4+PiAgICAgICBpbnRvIHNtYWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBzZXBh cmF0ZSBPU1BGIFRFIExTQXMuIg0KPj4+Pj4NCj4+Pj4+IEFjY29yZGluZyB0byB0aGlzIGNsYXVz ZSwgeW91IGNhbiBzZXBhcmF0ZSB0aGUgUmVzb3VyY2UgQmxvY2sgSW5mbyBTdWItVExWIGFzIHRo ZSBzb2xlIGVudHJ5IGRlZmluZWQgaW4gdGhlIE9wdGljYWwgTm9kZSBwcm9wZXJ0eSBUTFYgaW4g YSBzZXBhcmF0ZSBURSBMU0EgZnJvbSB0aGUgcmVzdCBpZiB5b3Ugd2lsbC4gTm90aGluZyBwcmV2 ZW50cyB0aGlzIHBhcnRpY3VsYXIgd2F5IG9mIHBhY2thZ2luZy4gKElzbid0IHRoaXMgd2hhdCB5 b3UgbWVhbnQgImEgc3BlY2lmaWMgaW5kZXBlbmRlbnQgZmxvb2RpbmcgZW50aXR5Ij8pDQo+Pj4+ Pg0KPj4+Pj4gLSBQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhpcyBleHBsYW5hdGlvbiBzYXRpc2Zp ZXMgeW91LiBUaGFua3MgLS0tIFlvdW5nDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+DQo+ Pj4+PiBQaWVycmUNCj4+Pj4+DQo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+ Pj4+IERlIDogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIExlZXlv dW5nIEVudm95w6kgOiBqZXVkaSAxNSBzZXB0ZW1icmUgMjAxMSAyMTo1OSDDgCA6IGNjYW1wQGll dGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4gT2JqZXQgOiBSZTogW0NDQU1QXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50 eHQNCj4+Pj4+DQo+Pj4+PiBIaSBhbGwsDQo+Pj4+Pg0KPj4+Pj4gQWZ0ZXIgMDUgdmVyc2lvbiBw dWJsaWNhdGlvbiwgQWNlZSBwcm92aWRlZCBhIG51bWJlciBvZiB2YWx1YWJsZSBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMuIFRoaXMgcmV2aXNpb24gKDA2KSByZWZsZWN0cyB0aG9zZSBjaGFuZ2Vz LiBQbGVhc2Ugbm90ZSB0aGUgZm9sbG93aW5nIHVwZGF0ZXM6DQo+Pj4+Pg0KPj4+Pj4gLSBDaGFu Z2UgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdCB0byAiR01QTFMgT1NQRiBFbmhhbmNlbWVudC4uLiIg ZnJvbSAiT1NQRiBFbmhhbmNlbWVudC4uLiIgdG8gbWFrZSBzdXJlIHRoZSBjaGFuZ2VzIGFwcGx5 IHRvIHRoZSBHTVBMUyBPU1BGIHJhdGhlciB0aGFuIHRoZSBiYXNlIE9TUEYuDQo+Pj4+Pg0KPj4+ Pj4gLSBBZGQgc3BlY2lmaWMgT1NQRiBwcm9jZWR1cmVzIG9uIGhvdyBzdWItVExWcyBhcmUgcGFj a2FnZWQgcGVyIFtSRkMzNjMwXSBhbmQgZWRpdG9yaWFsIGNoYW5nZSBpbmNsdWRpbmcgYXZvaWRp bmcgIm11bHRpcGxlIGluc3RhbmNlcyBvZiBURSBMU0EiIHRvICJtdWx0aXBsZSBURSBMU0FzIi4N Cj4+Pj4+DQo+Pj4+PiBZb3VyIGNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQuIFRoYW5r cy4NCj4+Pj4+DQo+Pj4+PiBCZXN0IFJlZ2FyZHMuDQo+Pj4+PiBZb3VuZw0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogY2NhbXAtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjY2Ft cC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4+PiBTZW50OiBUaHVyc2RheSwg U2VwdGVtYmVyIDE1LCAyMDExIDI6NDggUE0NCj4+Pj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4+Pj4+IENjOiBjY2FtcEBpZXRmLm9y ZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4 dA0KPj4+Pj4NCj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lIFdvcmtp bmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+Pg0KPj4+Pj4gICBUaXRsZSAgICAgICAgICAgOiBH TVBMUyBPU1BGIEVuaGFuY2VtZW50IGZvciBTaWduYWwgYW5kIE5ldHdvcmsgRWxlbWVudCBDb21w YXRpYmlsaXR5IGZvciBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MNCj4+Pj4+ ICAgQXV0aG9yKHMpICAgICAgIDogWW91bmcgTGVlDQo+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEdyZWcgTS4gQmVybnN0ZWluDQo+Pj4+PiAgIEZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+ Pj4gICBQYWdlcyAgICAgICAgICAgOiAxNA0KPj4+Pj4gICBEYXRlICAgICAgICAgICAgOiAyMDEx LTA5LTE1DQo+Pj4+Pg0KPj4+Pj4gICAgICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBHTVBMUyBP U1BGIHJvdXRpbmcgZW5oYW5jZW1lbnRzIHRvIHN1cHBvcnQNCj4+Pj4+ICAgICAgIHNpZ25hbCBj b21wYXRpYmlsaXR5IGNvbnN0cmFpbnRzIGFzc29jaWF0ZWQgd2l0aCBXU09OIG5ldHdvcmsNCj4+ Pj4+ICAgICAgIGVsZW1lbnRzLiBUaGVzZSByb3V0aW5nIGVuaGFuY2VtZW50cyBhcmUgcmVxdWly ZWQgaW4gY29tbW9uIG9wdGljYWwNCj4+Pj4+ICAgICAgIG9yIGh5YnJpZCBlbGVjdHJvLW9wdGlj YWwgbmV0d29ya3Mgd2hlcmUgbm90IGFsbCBvZiB0aGUgb3B0aWNhbA0KPj4+Pj4gICAgICAgc2ln bmFscyBpbiB0aGUgbmV0d29yayBhcmUgY29tcGF0aWJsZSB3aXRoIGFsbCBuZXR3b3JrIGVsZW1l bnRzDQo+Pj4+PiAgICAgICBwYXJ0aWNpcGF0aW5nIGluIHRoZSBuZXR3b3JrLg0KPj4+Pj4NCj4+ Pj4+ICAgICAgIFRoaXMgY29tcGF0aWJpbGl0eSBjb25zdHJhaW50IG1vZGVsIGlzIGFwcGxpY2Fi bGUgdG8gY29tbW9uIG9wdGljYWwNCj4+Pj4+ICAgICAgIG9yIGh5YnJpZCBlbGVjdHJvIG9wdGlj YWwgc3lzdGVtcyBzdWNoIGFzIE9FTyBzd2l0Y2hlcywgcmVnZW5lcmF0b3JzLA0KPj4+Pj4gICAg ICAgYW5kIHdhdmVsZW5ndGggY29udmVydGVycyBzaW5jZSBzdWNoIHN5c3RlbXMgY2FuIGJlIGxp bWl0ZWQgdG8NCj4+Pj4+ICAgICAgIHByb2Nlc3Npbmcgb25seSBjZXJ0YWluIHR5cGVzIG9mIFdT T04gc2lnbmFscy4NCj4+Pj4+DQo+Pg0KPj4NCj4+IC0tDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gQW5kcmVhIFphbmFyZGkN Cj4+IENSRUFURS1ORVQNCj4+IEVuZ2luZWVyaW5nICYgRmFzdCBQcm90b3R5cGluZyAoRU5HSU5F KSBBcmVhDQo+PiBTZW5pb3IgRW5naW5lZXINCj4+IFZpYSBhbGxhIENhc2NhdGEgNTYvRCAtIDM4 MTIzIFBvdm8gVHJlbnRvIChJdGFseSkNCj4+IGUtbWFpbDogYW5kcmVhLnphbmFyZGlAY3JlYXRl LW5ldC5vcmc8bWFpbHRvOmFuZHJlYS56YW5hcmRpQGNyZWF0ZS1uZXQub3JnPg0KPj4gVGVsOiAo KzM5KSAwNDYxIDQwODQwMCAtIGludGVybm8vZXh0ZW5zaW9uIDE0MDcNCj4+IE1vYmlsZTogKCsz OSkgMzQwIDAwMTE4MzcNCj4+IEZheDogKCszOSkgMDQ2MSA0MjExNTcNCj4+IFNreXBlOiB6YW5h cmRpX2FuZHJlYQ0KPj4gd3d3LmNyZWF0ZS1uZXQub3JnPGh0dHA6Ly93d3cuY3JlYXRlLW5ldC5v cmc+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4NCj4+IFRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRlbmRlZCBv bmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0bw0KPj4gd2hpY2ggaXQgaXMgYWRkcmVzc2Vk IGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQNCj4+IG1hdGVy aWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1 c2Ugb2YsIG9yDQo+PiB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9uLCB0aGlz IGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3INCj4+IGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkIGFjY29yZGluZyB0byB0aGUNCj4+IEl0YWxp YW4gTGF3IDE5Ni8yMDAzIG9mIHRoZSBMZWdpc2xhdHVyZS4gSWYgeW91IHJlY2VpdmVkIHRoaXMg aW4gZXJyb3IsDQo+PiBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1h dGVyaWFsIGZyb20gYW55IGNvbXB1dGVyLg0KPj4NCj4+IExlIGluZm9ybWF6aW9uaSBjb250ZW51 dGUgaW4gcXVlc3RvIG1lc3NhZ2dpbyBkaSBwb3N0YSBlbGV0dHJvbmljYSBlIG5laQ0KPj4gZmls ZSBhbGxlZ2F0aSBzb25vIGRhIGNvbnNpZGVyYXJzaSBzdHJldHRhbWVudGUgcmlzZXJ2YXRlLiBJ bCBsb3JvIHV0aWxpenpvDQo+PiBlJyBjb25zZW50aXRvIGVzY2x1c2l2YW1lbnRlIGFsIGRlc3Rp bmF0YXJpbyBkZWwgbWVzc2FnZ2lvLCBwZXIgbGUgZmluYWxpdGEnDQo+PiBpbmRpY2F0ZSBuZWwg bWVzc2FnZ2lvIHN0ZXNzby4gUXVhbG9yYSByaWNldmVzdGUgcXVlc3RvIG1lc3NhZ2dpbyBzZW56 YQ0KPj4gZXNzZXJuZSBpbCBkZXN0aW5hdGFyaW8sIFZpIHByZWdoaWFtbyBjb3J0ZXNlbWVudGUg ZGkgZGFyY2VuZSBub3RpemlhIHZpYQ0KPj4gZS1tYWlsIGUgZGkgcHJvY2VkZXJlIGFsbGEgY2Fu Y2VsbGF6aW9uZSBkZWwgbWVzc2FnZ2lvIHN0ZXNzbyBkYWwgVm9zdHJvDQo+PiBzaXN0ZW1hLiBU cmF0dGVuZXJlIGlsIG1lc3NhZ2dpbyBzdGVzc28sIGRpdnVsZ2FybG8gYW5jaGUgaW4gcGFydGUs DQo+PiBkaXN0cmlidWlybG8gYWQgYWx0cmkgc29nZ2V0dGksIGNvcGlhcmxvLCBvZCB1dGlsaXp6 YXJsbyBwZXIgZmluYWxpdGEnDQo+PiBkaXZlcnNlLCBjb3N0aXR1aXNjZSBjb21wb3J0YW1lbnRv IGNvbnRyYXJpbyBhaSBwcmluY2lwaSBkZXR0YXRpIGRhbCBELiBMZ3MuDQo+PiAxOTYvMjAwMy4N Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NBTVBAaWV0 Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IENDQU1QIG1haWxpbmcgbGlzdA0KPj4gQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGlldGYu b3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4N Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxp c3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo= From db3546@att.com Tue Nov 1 13:18:55 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFC611E81CF for ; Tue, 1 Nov 2011 13:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn8sNAng7KOp for ; Tue, 1 Nov 2011 13:18:55 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2E81111E8193 for ; Tue, 1 Nov 2011 13:18:55 -0700 (PDT) X-Env-Sender: db3546@att.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1320178728!47675058!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8555 invoked from network); 1 Nov 2011 20:18:49 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Nov 2011 20:18:49 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA1KJG6h022216 for ; Tue, 1 Nov 2011 16:19:16 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA1KJApt022080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 1 Nov 2011 16:19:10 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.168]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0339.001; Tue, 1 Nov 2011 16:18:42 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: CCAMP Draft Agenda Thread-Index: AcyY03Q9yKyZC1pGRBuxKjI7gDtQow== Date: Tue, 1 Nov 2011 20:18:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] CCAMP Draft Agenda X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:18:56 -0000 CCAMP, The draft agenda has been uploaded: http://www.ietf.org/proceedings/82/agenda/ccamp.htm Let us know if we missed anyone- Deborah, Lou, Dan From zhangfatai@huawei.com Tue Nov 1 19:45:40 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358911E80A0 for ; Tue, 1 Nov 2011 19:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.06 X-Spam-Level: X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnpVruEGvjT2 for ; Tue, 1 Nov 2011 19:45:37 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3211E80DC for ; Tue, 1 Nov 2011 19:45:36 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU000C22IAHQB@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 02 Nov 2011 10:44:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU000FY2IAGXH@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 02 Nov 2011 10:44:41 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV62788; Wed, 02 Nov 2011 10:44:38 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 10:44:34 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.196]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 10:44:31 +0800 Date: Wed, 02 Nov 2011 02:44:30 +0000 From: Zhangfatai In-reply-to: X-Originating-IP: [10.70.76.157] To: Jonathan Harrison Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02 Thread-index: AcyO+SR1JBDgzbDXQLy9a3WTPeeQgAAKmUiA//+R9YD/+enWIIAMcmyAgAIDbQD//ran0IACPdiA//6h04D//Tv1sP/yWSwA/+NRnkA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <8E6DCB79-DEB7-4CBC-9641-54EADF945DFA@ericsson.com> <4EA72DFA.80605@labn.net> <4EA7FB13.2030509@labn.net> Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comment regarding draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 02:45:41 -0000 R3JlYXQsIHRoYW5rcywgSm9uIGFuZCBBY2VlLg0KDQoNCg0KDQoNCg0KVGhhbmtzDQrCoA0KRmF0 YWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvbmF0aGFuIEhhcnJpc29u IFttYWlsdG86am9uLmhhcnJpc29uQG1ldGFzd2l0Y2guY29tXSANClNlbnQ6IDIwMTHlubQxMeac iDHml6UgMjE6NDINClRvOiBaaGFuZ2ZhdGFpDQpDYzogY2NhbXBAaWV0Zi5vcmc7IEFjZWUgTGlu ZGVtOyBsYWJuIC0gTG91IEJlcmdlcg0KU3ViamVjdDogUkU6IFtDQ0FNUF0gQ29tbWVudCByZWdh cmRpbmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUt MDINCg0KSGkgRmF0YWksDQoNCkkgYWdyZWUgdGhhdCBubyByZWFsIG5lZWQgdG8gc2VwYXJhdGUg dGhlIGR5bmFtaWMgYW5kIHN0YXRpYyBpbmZvcm1hdGlvbiwgc28gYWxsIG9mIHRoZSBsYWJlbCBp bmZvcm1hdGlvbiBjYW4gYmUgYWR2ZXJ0aXNlZCBpbiBhIHNpbmdsZSBMU0EuDQoNCklmIHRoZSBv bmx5IG1vdGl2YXRpb24gZm9yIGEgbmV3IHRvcCBsZXZlbCBUTFYgd2FzIHRvIGFsbG93IHRoaXMg c2VwYXJhdGlvbiwgdGhlbiBubyBuZXcgdG9wIGxldmVsIFRMViBpcyBuZWVkZWQgLSBhbGwgb2Yg dGhlIFRFIHBhcmFtZXRlcnMgYW5kIGxhYmVsIGF2YWlsYWJpbGl0eSBpbmZvcm1hdGlvbiBmb3Ig YSBsaW5rIHNob3VsZCBiZSBhZHZlcnRpc2VkIGluIGEgc2luZ2xlIExTQSBjb250YWluaW5nIGEg c2luZ2xlIExpbmsgVExWLg0KDQpUaGFua3MsDQpKb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaaGFuZ2ZhdGFpDQpTZW50OiAyNyBPY3RvYmVyIDIw MTEgMDM6MzYNClRvOiBaaGFuZ2ZhdGFpOyBsYWJuIC0gTG91IEJlcmdlcg0KQ2M6IEpvbmF0aGFu IEhhcnJpc29uOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCBy ZWdhcmRpbmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYt dGUtMDINCg0KSGkgQWNlZSwgSm9uYXRoYW4gYW5kIExvdSwNCg0KV2hlbiBJIHdhcyBnb2luZyB0 byB1cGRhdGUgdGhlIGRyYWZ0LCBJIGZvdW5kIHRoYXQgaXQgY2Fubm90IHNlcGFyYXRlIHRoZSBk eW5hbWljIGFuZCBzdGF0aWMgbGluayBpbmZvcm1hdGlvbiBieSBpbnRyb2R1Y2luZyBhIG5ldyB0 b3AgTGV2ZWwgTGluayBUTFZzLCBpLmUuLCBpZiB3ZSBzdGlsbCBuZWVkIHRvIHNlcGFyYXRlIHRo ZSBkeW5hbWljIGFuZCBzdGF0aWMgbGluayBpbmZvcm1hdGlvbiwgd2UgbWF5IHN0aWxsIG5lZWQg dGhlIHNpbWlsYXIgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFNlY3Rpb24gNCBhbmQgNS4xIG9mIHRo aXMgZHJhZnQsIHBsZWFzZSBoYXZlIGEgbG9vayBhdCB0aGVzZSBzZWN0aW9ucy4NCg0KV2hlbiBJ IGxvb2tlZCBhdCB3aGF0IEFjZWUgc2FpZCBiZWxvdyBhZ2FpbiwgSSB0aGluayBwZW9wbGUgaW5j bHVkaW5nIG1lIG1heSBtaXggdGhlIG5vZGUgaW5mb3JtYXRpb24gYW5kIGxpbmsgaW5mb3JtYXRp b24gYXQgc29tZSBleHRlbnQuIEFjdHVhbGx5LCB0aGUgY29ubmVjdGl2aXR5IG1hdHJpeCBpcyBh IGtpbmQgb2Ygbm9kZSBpbmZvcm1hdGlvbiBhbmQgaXQgaXMgY2FycmllZCBpbiBhIG5ldyB0b3Ag Tm9kZSBUTFYuIA0KDQpGb3IgdGhlIGxpbmsgaW5mb3JtYXRpb24sIHRoZXJlIGlzIG5vdCB0b28g bXVjaCBpbmZvcm1hdGlvbihQb3J0IExhYmVsIFJlc3RyaWN0aW9ucywgQXZhaWxhYmxlIExhYmVs cywgU2hhcmVkIEJhY2t1cCBMYWJlbHMpLCBzbyBhIHNpbmdsZSBMaW5rIExTQSBzaG91bGQgYmUg T0suIFdoeSB3ZSB3YW50ZWQgdG8gdXNlIG11bHRpcGxlIExTQXMgdG8gYWR2ZXJ0aXNlIHRoZSBz YW1lIGxpbmsgaW5mb3JtYXRpb24/IFRoZSBvcmlnaW5hbCByZWFzb24gaXMgdGhhdCB3ZSB3YW50 IHRvIHNlcGFyYXRlIHRoZSBkeW5hbWljIGFuZCBzdGF0aWMgbGluayBpbmZvcm1hdGlvbiB0byBy ZWR1Y2UgdGhlIHJvdXRpbmcgc2NhbGFiaWxpdHkgaXNzdWUuDQoNCkhvd2V2ZXIsIEkgdGhpbmsg dGhlIGR5bmFtaWMgb2YgbGFiZWwgYXZhaWxhYmlsaXR5IGlzIHNpbWlsYXIgdG8gdGhlIGJhbmR3 aWR0aCBvZiBURE0gb3IgUFNDIGFuZCB0aGVyZSBhcmUgbm8gcHJvdG9jb2wgcHJvY2VkdXJlcyBz byBmYXIgdG8gZGVmaW5lIGhvdyB0byBzZXBhcmF0ZSB0aGUgZHluYW1pYyBhbmQgc3RhdGljIGxp bmsgaW5mb3JtYXRpb24uDQoNClNvLCB0byBtYWtlIHRoaW5ncyBzaW1wbGUsIEkgdGhpbmsgd2Ug Y2FuIGp1c3QgdXNlIG9uZSBzaW5nbGUgTFNBIHRvIGluY2x1ZGUgYWxsIHRoZSBpbmZvcm1hdGlv biBvZiBvbmUgTGluay4NCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcz8NCg0KDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQo+PiBXaGlsZSBJIGFkbWl0IHRoZXJlIGlzIHNvbWUgYW1iaWd1aXR5 IGhlcmUsIEkgY29uY3VyIHdpdGggSm9uYXRoYW4gdGhhdCB0aGlzIHdvdWxkIHJlc3VsdCBpbiBp bmNvbXBhdGliaWxpdHkgcHJvYmxlbXMgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuIERv IHdlIHJlYWxseSB0aGluayBoYXZlIG1vcmUgaW5mb3JtYXRpb24gZm9yIGEgc2luZ2xlIGxpbmsg dGhhbiB3aWxsIG5vcm1hbGx5IGZpdCBpbiBhbiBMU0EgdGhhdCBiZSBhZHZlcnRpc2VkIG92ZXIg YSBzdGFuZGFyZCBldGhlcm5ldCBsaW5rIChNVFUgMTUwMCBieXRlcykgd2l0aG91dCBJUCBmcmFn bWVudGF0aW9uPyBJZiB0aGlzIGlzIGEgcmFyZSBjYXNlLCBJJ2Qgc2F5IHRoYXQgaXQgaXMgb2sg Zm9yIHRoZSBMU0EgdG8gYmVjb21lIGxhcmdlLCBpLmUuLCByZXF1aXJlIElQIGZyYWdtZW50YXRp b24gZm9yIGFkdmVydGlzZW1lbnQuIElmIHRoZSB3ZSBleHBlY3QgdGhlIGNvbnN0cmFpbnQgaW5m b3JtYXRpb24gdG8gbm9ybWFsbHkgcmVxdWlyZSBmcmFnbWVudGF0aW9uLCBJJ2QgcmVjb21tZW5k IGEgbmV3IHRvcC1sZXZlbCBUTFYsIHRoZSBMaW5rLUNvbnN0cmFpbnQgVExWLg0KDQoNCg0KDQoN Cg0KVGhhbmtzDQrCoA0KRmF0YWkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBaaGFuZ2ZhdGFpDQpTZW50OiAyMDEx5bm0MTDmnIgyN+aXpSA5OjE5DQpU bzogTG91IEJlcmdlcg0KQ2M6IEpvbmF0aGFuIEhhcnJpc29uOyBjY2FtcEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtDQ0FNUF0gQ29tbWVudCByZWdhcmRpbmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDINCg0KSGkgTG91LA0KDQpJIGdvdCB5b3Vy IHBvaW50cy4NCg0KTXkgbGFzdCBzZW50ZW5jZSBzaG91bGQgZ28gdG8gdGhlIFdHLCBJIGp1c3Qg d2FudGVkIHRvIHNlZSB3aGV0aGVyIHRoZXJlIGFyZSBvdGhlciBvcGluaW9ucyBvbiB0aGUgbmV3 IHRvcCBsZXZlbCBsaW5rIFRMVi4gDQoNCg0KDQpUaGFua3MNCsKgDQpGYXRhaQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFi bi5uZXRdIA0KU2VudDogMjAxMeW5tDEw5pyIMjbml6UgMjA6MjENClRvOiBaaGFuZ2ZhdGFpDQpD YzogQWNlZSBMaW5kZW07IEpvbmF0aGFuIEhhcnJpc29uOyBjY2FtcEBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGVAdG9vbHMuaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgcmVnYXJkaW5nIGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyDQoNCkZhdGFpLA0KCQ0KDQpP biAxMC8yNi8yMDExIDU6MzUgQU0sIFpoYW5nZmF0YWkgd3JvdGU6DQo+IEhpIExvdSwgQWNlZSBh bmQgYWxsLA0KPiANCj4gSSBhbSBmaW5lIHRvIGhhdmUgYSBuZXcgdG9wIGxldmVsIExpbmsgVExW IHRvIGluY2x1ZGUgdGhlIGdlbmVyaWMgbGluayBpbmZvcm1hdGlvbiBpZiB0aGUgV0cgbGlrZSB0 aGF0Lg0KPiANCj4gVG8gYXZvaWQgdGhpcyB3b3JrIGJhY2sgYW5kIGZvcnRoLCBwbGVhc2Ugc2hh cmUgeW91ciBjb25jZXJucyBiZWZvcmUgd2UgdXBkYXRlIHRoaXMgZHJhZnQuDQoNCkknbSBub3Qg c3VyZSB3aGF0IGFkZGl0aW9uYWwgaW5wdXQgeW91J3JlIGxvb2tpbmcgZm9yLiAgTXkgb25seQ0K YWRkaXRpb25hbCBjb21tZW50IGlzOg0KPiBJIHRoaW5rIHRoZSBtb3JlIHNwZWNpZmljL2RldGFp bGVkIHdlIGNhbiBtYWtlIHRoZW0sDQo+IHRoZSBmYXN0ZXIgdGhlIG9wZW4gZGlzY3Vzc2lvbnMg d2lsbCBiZSByZXNvbHZlZC4NCg0KSW4gb3RoZXIgd29yZHMsIEkgYmVsaWV2ZSB0aGF0IHNvbWUg bW9yZSBjb25mb3JtYW5jZSBsYW5ndWFnZSBhbmQNCnNwZWNpZmljIHJlcXVpcmVtZW50cyBvbiBm b3JtYXR0aW5nIGFuZCBUTFYgY29uc3RydWN0aW9uL3BhcnNpbmcgd291bGQNCmJlIGJlbmVmaWNp YWwuDQoNCkxvdQ0KDQo+IA0KPiANCj4gVGhhbmtzDQo+ICANCj4gRmF0YWkNCj4gDQo+IA0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJl cmdlckBsYWJuLm5ldF0gDQo+IFNlbnQ6IDIwMTHlubQxMOaciDI25pelIDU6NDYNCj4gVG86IEFj ZWUgTGluZGVtDQo+IENjOiBaaGFuZ2ZhdGFpOyBKb25hdGhhbiBIYXJyaXNvbjsgY2NhbXBAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRl QHRvb2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIENvbW1lbnQgcmVnYXJkaW5n IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyDQo+ IA0KPiBBY2VlLA0KPiANCj4gSW4gc2hvcnQgSSBhZ3JlZSB3aXRoIHlvdSAxMDAlLiAgU2VlIGJl bG93IGZvciBtb3JlIGRldGFpbGVkICByZXNwb25zZXMNCj4gaW4tbGluZS4NCj4gDQo+IE9uIDEw LzI0LzIwMTEgMTE6MDAgQU0sIEFjZWUgTGluZGVtIHdyb3RlOg0KPj4gSGkgRmF0YWksDQo+Pg0K Pj4gT24gT2N0IDIzLCAyMDExLCBhdCAxMTowMyBQTSwgWmhhbmdmYXRhaSB3cm90ZToNCj4+DQo+ PiBIaSBBY2VlLA0KPj4NCj4+IFlvdSBzYWlkIGFzIGZvbGxvd3MsIHBsZWFzZSBzZWUgaW5saW5l Lg0KPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQo+Pg0KPj4gSXQgZG9lc24ndCBleHBsaWNpdGx5IHByZXZlbnQgaXQgYnV0 IGl0IGRvZXMgc28gaW1wbGljaXRseS4gSWYgeW91DQo+PiBhZHZlcnRpc2UgbXVsdGlwbGUgT1NQ RiBURSBMU0FzIHdpdGggYSB0b3AtbGV2ZWwgTGluayBUTFYgZm9yIHRoZQ0KPj4gc2FtZSBsaW5r LCB0aGVyZSBpcyBubyB3YXkgdG8gY29ycmVsYXRlIHRoZW0gc2luY2UgUkZDIDM2MzAgZG9lcw0K Pj4gc3BlY2lmeSB0aGF0IHRoZSBMaW5rIElEIHN1Yi1UTFYgbWF5IG9ubHkgb2NjdXIgYXQgbW9z dCBvbmNlLg0KPj4NCj4+IFRoZSBMaW5rIFR5cGUgYW5kIExpbmsgSUQgc3ViLVRMVnMgYXJlIG1h bmRhdG9yeSwgaS5lLiwgbXVzdCBhcHBlYXINCj4+IGV4YWN0bHkgb25jZS4gQWxsIG90aGVyIHN1 Yi1UTFZzIGRlZmluZWQgaGVyZSBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlLg0KPj4gVGhlc2UgcmVz dHJpY3Rpb25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4gVW5yZWNvZ25pemVk DQo+PiBzdWItVExWcyBhcmUgaWdub3JlZC4NCj4+DQo+PiBbRmF0YWldIEkgdGhpbmsgdGhlIHJl c3RyaWN0aW9uIGZvciB0aGlzIHBhcmFncmFwaCBzaG91bGQgYmUgaW4gdGhlDQo+PiBzY29wZSBv ZiBvbmUgTGluayBUTFYgb3Igb25lIExTQS4gSWYgYSBURSBsaW5rIGlzIGFkdmVydGlzZWQgYnkN Cj4+IG11bHRpcGxlIExTQXMgKHdpdGggbXVsdGlwbGUgTGluayBUTFZzKSwgdGhlIExpbmsgSUQg YW5kIExpbmsgdHlwZQ0KPj4gTVVTVCBiZSBhZHZlcnRpc2VkIHJlc3BlY3RpdmVseSwgYW5kIHRo ZW4gd2UgY2FuIHVzZSBMaW5rIElEIGFuZCBMaW5rDQo+PiBUeXBlIHRvIGNvcnJlbGF0ZSB0aGVt IGZvciB0aGUgc2FtZSBURSBsaW5rLg0KPj4NCj4+IFJGQyAzNjMwIG1ha2VzIG5vIHByb3Zpc2lv biBmb3IgbXVsdGlwbGUgT1NQRiBURSBMU0FzIHdpdGggYQ0KPj4gdG9wLWxldmVsIExpbmsgVExW IGZvciBhIGdpdmVuIGxpbmsuIEl0IGNvdWxkIGJlIG1hZGUgdG8gd29yayBhcyB5b3UNCj4+IHN1 Z2dlc3QgYnV0IGl0IGNlcnRhaW5seSBpc24ndCBzcGVjaWZpZWQuDQo+Pg0KPj4gV2hpbGUgSSBh ZG1pdCB0aGVyZSBpcyBzb21lIGFtYmlndWl0eSBoZXJlLCBJIGNvbmN1ciB3aXRoIEpvbmF0aGFu DQo+PiB0aGF0IHRoaXMgd291bGQgcmVzdWx0IGluIGluY29tcGF0aWJpbGl0eSBwcm9ibGVtcyB3 aXRoIGV4aXN0aW5nDQo+PiBpbXBsZW1lbnRhdGlvbnMuIA0KPiANCj4gSSBjb21wbGV0ZWx5IGFn cmVlLiAgSSdkIG5lZWQgdG8gY2hlY2sgY29kZSB0byBzZWUgaWYgdGhlIGltcGxlbWVudGF0aW9u DQo+IEkgaGF2ZSBlYXN5IGFjY2VzcyB0byB3aWxsIGhhbmRsZSB0aGlzIGNhc2Ugb24gcmVjZWl2 ZSwgYnV0IEkgY2FuJ3QNCj4gdGhpbmsgb2YgY2FzZSB3aGVyZSBzdWNoIHVzYWdlIHdvdWxkIGJl IGdlbmVyYXRlZC4NCj4gDQo+PiBEbyB3ZSByZWFsbHkgdGhpbmsgaGF2ZSBtb3JlIGluZm9ybWF0 aW9uIGZvciBhDQo+PiBzaW5nbGUgbGluayB0aGFuIHdpbGwgbm9ybWFsbHkgZml0IGluIGFuIExT QSB0aGF0IGJlIGFkdmVydGlzZWQgb3Zlcg0KPj4gYSBzdGFuZGFyZCBldGhlcm5ldCBsaW5rIChN VFUgMTUwMCBieXRlcykgd2l0aG91dCBJUCBmcmFnbWVudGF0aW9uPw0KPj4gSWYgdGhpcyBpcyBh IHJhcmUgY2FzZSwgSSdkIHNheSB0aGF0IGl0IGlzIG9rIGZvciB0aGUgTFNBIHRvIGJlY29tZQ0K Pj4gbGFyZ2UsIGkuZS4sIHJlcXVpcmUgSVAgZnJhZ21lbnRhdGlvbiBmb3IgYWR2ZXJ0aXNlbWVu dC4gSWYgdGhlIHdlDQo+PiBleHBlY3QgdGhlIGNvbnN0cmFpbnQgaW5mb3JtYXRpb24gdG8gbm9y bWFsbHkgcmVxdWlyZSBmcmFnbWVudGF0aW9uLA0KPj4gSSdkIHJlY29tbWVuZCBhIG5ldyB0b3At bGV2ZWwgVExWLCB0aGUgTGluay1Db25zdHJhaW50IFRMVi4NCj4gDQo+IEFnYWluLCBhZ3JlZSB3 aXRoIGJvdGggY29tbWVudHMvcmVjb21tZW5kYXRpb25zLiAgUGVyaGFwcyBjYWxsIGl0IHRoZQ0K PiBMaW5rLUZyYWdtZW50IFRMViwgb3IgUGFydGlhbCBMaW5rIFRMVi4uLg0KPiANCj4+DQo+PiBb RmF0YWldIEkgdGhpbmsgZm9yIHRoZSB0eXBpY2FsIGNhc2VzLCBvbmUgTFNBIChvciBvbmUgTGlu ayBUTFYpIG1heQ0KPj4gYmUgc3VmZmljaWVudCBmb3IgYSBURSBsaW5rLCBidXQgc29tZSBwZW9w bGUgbGlrZSB0byBnaXZlIHNvbWUgcmFyZQ0KPj4gb3IgZXh0cmVtZSBleGFtcGxlcyB0byBqdXN0 aWZ5IHRoZWlyIHRob3VnaHQuIENvbXBhcmVkIHdpdGggYSBuZXcNCj4+IHRvcC1sZXZlbCBUTFYs IEkgd291bGQgc2F5IEkgd291bGQgbGlrZSB0byByZS11c2UgdGhlIGV4aXN0aW5nDQo+PiB0b3At bGV2ZWwgTGluayBUTFYgYmVjYXVzZSB0aGlzIGZvbGxvd3MgdGhlIOKAnEfigJ0gb2YgR01QTFMu DQo+Pg0KPj4gSSdsbCBsZXQgTG91IGFuZCBvdGhlciBjb21tZW50IG9uIHdoYXQgaXMgbW9yZSBj b25zaXN0ZW50IHdpdGggR01QTFMuDQo+IA0KPiBXZWxsIHRoaXMgaXMgc29tZXRoaW5nIGZvciB0 aGUgV0cgdG8gZGlzY3Vzcy4gIE15IHBlcnNvbmFsIChub3QgY2hhaXIpDQo+IHBlcnNwZWN0aXZl IHNlZW1zIGFsaWduZWQgd2l0aCB5b3VycyAoQWNlZSdzKS4NCj4gDQo+PiBIb3dldmVyLCBJIHNo YXJlIHRoZSBjb25jZXJuIHRoYXQgdGhpcyBleHRlbnNpb24gd2lsbCBiZSBpbmNvbXBhdGlibGUN Cj4+IHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLg0KPiANCj4gQ291bGQgbm90IGFncmVl IG1vcmUuICBNeSBpbXByZXNzaW9uIChhcyBjaGFpcikgaXMgdGhhdCBtdWNoIG9mIHRoZSBXU09O DQo+IHJlbGF0ZWQgZGlzY3Vzc2lvbiBoYXMgdG8gZG8gd2l0aCB0aGUgZGVncmVlIHRoYXQgdGhl IGN1cnJlbnQgV0cgZHJhZnRzDQo+IGFyZSBvcGVuIHRvIGRpZmZlcmVudCBpbnRlcnByZXRhdGlv bnMgKGFuZCBwb3NzaWJsZSBpbmNvbXBhdGlibGUNCj4gaW1wbGVtZW50YXRpb25zKS4gIEkgdGhp bmsgdGhlIG1vcmUgc3BlY2lmaWMvZGV0YWlsZWQgd2UgY2FuIG1ha2UgdGhlbSwNCj4gdGhlIGZh c3RlciB0aGUgb3BlbiBkaXNjdXNzaW9ucyB3aWxsIGJlIHJlc29sdmVkLg0KPiANCj4gTG91DQo+ IA0KPj4NCj4+IFRoYW5rcywNCj4+IEFjZWVzDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBU aGFua3MNCj4+DQo+PiBGYXRhaQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiBGcm9tOiBBY2VlIExpbmRlbSBbbWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0NCj4+ IFNlbnQ6IDIwMTHlubQxMOaciDIw5pelIDIxOjUzDQo+PiBUbzogWmhhbmdmYXRhaQ0KPj4gQ2M6 IEpvbmF0aGFuIEhhcnJpc29uOyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3Ry YWludHMtb3NwZi10ZUB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGVAdG9vbHMuaWV0Zi5vcmc+OyBjY2FtcEBpZXRm Lm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBDb21t ZW50IHJlZ2FyZGluZyBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt b3NwZi10ZS0wMg0KPj4NCj4+IEhpIEZhdGFpLA0KPj4NCj4+IE9uIE9jdCAyMCwgMjAxMSwgYXQg ODo0MyBBTSwgWmhhbmdmYXRhaSB3cm90ZToNCj4+DQo+PiBIaSBKb25hdGhhbiwNCj4+DQo+PiBJ IGFncmVlIHdpdGggeW91IHRoYXQgUkZDIDM2MzAgZG9lcyBub3Qgc3RhdGUgZXhwbGljaXRseSBo b3cgYW4gT1NQRiBpbXBsZW1lbnRhdGlvbiBzaG91bGQgZ2VuZXJhdGUgbXVsdGlwbGUgVEUgbGlu ayBUTFZzIGZvciB0aGUgc2FtZSBsaW5rLg0KPj4NCj4+IEkgb25seSBzYXcgYSBzZW50ZW5jZSB0 byBkZXNjcmliZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gTGluayBUTFYgYW5kIExTQTogIOKA nE9ubHkgb25lIExpbmsgVExWIHNoYWxsIGJlIGNhcnJpZWQgaW4gZWFjaCBMU0EsIGFsbG93aW5n IGZvciBmaW5lIGdyYW51bGFyaXR5IGNoYW5nZXMgaW4gdG9wb2xvZ3ku4oCdDQo+Pg0KPj4gSG93 ZXZlciwgb2J2aW91c2x5LCBSRkMgMzYzMCBkb2VzIG5vdCBwcm92ZW50IHRvIGFkdmVydGlzZSBh IFRFIGxpbmsgaW5mb3JtYXRpb24gIGJ5IG11bHRpcGxlIExTQXMgKGluY2x1ZGluZyBvbmx5IG9u ZSBsaW5rIFRMViByZXNwZWN0aXZlbHkpLg0KPj4NCj4+IEl0IGRvZXNuJ3QgZXhwbGljaXRseSBw cmV2ZW50IGl0IGJ1dCBpdCBkb2VzIHNvIGltcGxpY2l0bHkuIElmIHlvdSBhZHZlcnRpc2UgbXVs dGlwbGUgT1NQRiBURSBMU0FzIHdpdGggYSB0b3AtbGV2ZWwgTGluayBUTFYgZm9yIHRoZSBzYW1l IGxpbmssIHRoZXJlIGlzIG5vIHdheSB0byBjb3JyZWxhdGUgdGhlbSBzaW5jZSBSRkMgMzYzMCBk b2VzIHNwZWNpZnkgdGhhdCB0aGUgTGluayBJRCBzdWItVExWIG1heSBvbmx5IG9jY3VyIGF0IG1v c3Qgb25jZS4NCj4+DQo+PiAgICBUaGUgTGluayBUeXBlIGFuZCBMaW5rIElEIHN1Yi1UTFZzIGFy ZSBtYW5kYXRvcnksIGkuZS4sIG11c3QgYXBwZWFyDQo+PiBleGFjdGx5IG9uY2UuIEFsbCBvdGhl ciBzdWItVExWcyBkZWZpbmVkIGhlcmUgbWF5IG9jY3VyIGF0IG1vc3QNCj4+IG9uY2UuIFRoZXNl IHJlc3RyaWN0aW9ucyBuZWVkIG5vdCBhcHBseSB0byBmdXR1cmUgc3ViLVRMVnMuDQo+PiBVbnJl Y29nbml6ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuDQo+Pg0KPj4NCj4+IFdoaWxlIEkgYWRtaXQg dGhlcmUgaXMgc29tZSBhbWJpZ3VpdHkgaGVyZSwgSSBjb25jdXIgd2l0aCBKb25hdGhhbiB0aGF0 IHRoaXMgd291bGQgcmVzdWx0IGluIGluY29tcGF0aWJpbGl0eSBwcm9ibGVtcyB3aXRoIGV4aXN0 aW5nIGltcGxlbWVudGF0aW9ucy4gRG8gd2UgcmVhbGx5IHRoaW5rIGhhdmUgbW9yZSBpbmZvcm1h dGlvbiBmb3IgYSBzaW5nbGUgbGluayB0aGFuIHdpbGwgbm9ybWFsbHkgZml0IGluIGFuIExTQSB0 aGF0IGJlIGFkdmVydGlzZWQgb3ZlciBhIHN0YW5kYXJkIGV0aGVybmV0IGxpbmsgKE1UVSAxNTAw IGJ5dGVzKSB3aXRob3V0IElQIGZyYWdtZW50YXRpb24/IElmIHRoaXMgaXMgYSByYXJlIGNhc2Us IEknZCBzYXkgdGhhdCBpdCBpcyBvayBmb3IgdGhlIExTQSB0byBiZWNvbWUgbGFyZ2UsIGkuZS4s IHJlcXVpcmUgSVAgZnJhZ21lbnRhdGlvbiBmb3IgYWR2ZXJ0aXNlbWVudC4gSWYgdGhlIHdlIGV4 cGVjdCB0aGUgY29uc3RyYWludCBpbmZvcm1hdGlvbiB0byBub3JtYWxseSByZXF1aXJlIGZyYWdt ZW50YXRpb24sIEknZCByZWNvbW1lbmQgYSBuZXcgdG9wLWxldmVsIFRMViwgdGhlIExpbmstQ29u c3RyYWludCBUTFYuDQo+Pg0KPj4gVGhhbmtzLCBBY2VlDQo+Pg0KPj4NCj4+IFRoaXMgZHJhZnQg W0dFTi1PU1BGXSBkZXNjcmliZXMgdGhlIGV4dGVuc2lvbnMgdG8gUkZDIDM2MzAsIHNvIGl0IGNh biBkZWZpbmUgdGhlc2UgcHJvY2VkdXJlcy4NCj4+DQo+PiBJIGFncmVlIHdpdGggeW91IHRoYXQg d2Ugc2hvdWxkIGhhdmUgY2xlYXIgZGVzY3JpcHRpb25zIG9uIHlvdXIgdGhyZWUgcG9pbnRzLiBG b3IgdGhlIGZpcnN0IHBvaW50LCBJIHRoaW5rIHRoaXMgZHJhZnQgaGFzIHN0YXRlZCB0aGlzIGV4 cGxpY2l0bHkgaW4gU2VjdGlvbiA0IGFuZCA1LjEuIEZvciB0aGUgb3RoZXIgdHdvIHBvaW50cywg d2UgbmVlZCBzb21lIHJlZmluZW1lbnRzIHRvIGFkZHJlc3MgdGhlbS4NCj4+DQo+PiBXZSB3aWxs IGFkZCBzb21lIHRleHQgdG8gYWRkcmVzcyB0aGVtIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+Pg0K Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4gLSAgICAgICBBIGNsZWFyIHN0YXRlbWVu dCB0aGF0IG11bHRpcGxlIFRMVnMgYXJlIGFsbG93ZWQgZm9yIHRoZSBzYW1lIGxpbmsuDQo+PiAt ICAgICAgIFJ1bGVzIHNwZWNpZnlpbmcgaG93IHN1Yi1UTFZzIGNhbiBiZSBkaXN0cmlidXRlZCBh Y3Jvc3MgdGhlIG11bHRpcGxlIFRMVnMgKGUuZy4gdGhlcmUgbXVzdCBiZSBhdCBtb3N0IG9uZSBB dmFpbGFibGUgTGFiZWxzIHN1Yi1UTFYgYWNyb3NzIGFsbCBUTFZzIGZvciB0aGUgc2FtZSBsaW5r KS4NCj4+IC0gICAgICAgUnVsZXMgc3BlY2lmeWluZyBob3cgbXVsdGlwbGUgVExWcyBzaG91bGQg YmUgaW50ZXJwcmV0ZWQuICAoVGhpcyBzaG91bGQgYmUgc2ltcGxlIGlmIHRoZSBydWxlcyBmb3Ig YnVpbGRpbmcgdGhlIFRMVnMgYXJlIHdlbGwgZGVmaW5lZC4pDQo+Pg0KPj4NCj4+IFRoYW5rcw0K Pj4NCj4+IEZhdGFpDQo+Pg0KPj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgSm9uYXRoYW4gSGFycmlzb24NCj4+IFNlbnQ6IDIwMTHlubQxMOaciDIw5pel IDE1OjIzDQo+PiBUbzogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRz LW9zcGYtdGVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2Vu ZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlQHRvb2xzLmlldGYub3JnPg0KPj4gQ2M6IGNjYW1wQGll dGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFtDQ0FNUF0gQ29tbWVu dCByZWdhcmRpbmcgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9z cGYtdGUtMDINCj4+DQo+PiBIaSBhdXRob3JzLA0KPj4NCj4+IEkgZG9u4oCZdCBrbm93IGlmIHlv deKAmXZlIGJlZW4gZm9sbG93aW5nIHRoZSB0aHJlYWQgYmVsb3csIGJ1dCB0aGUgZGlzY3Vzc2lv biBhcHBlYXJzIHRvIGhhdmUgc29tZSByZWxldmFuY2UgdG8gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIuDQo+Pg0KPj4gVGhlIGRpc2N1c3Npb24g YmVsb3cgaXMgYWJvdXQgdGhlIExpbmsgVExWIGRlZmluZWQgaW4gUkZDIDM2MzAuICBUaGUgcHJv YmxlbSBpcyB0aGF0IFJGQyAzNjMwIGlzIG5vdCBjbGVhciB3aGV0aGVyIGluZm9ybWF0aW9uIGFi b3V0IGEgc2luZ2xlIGxpbmsgY2FuIGJlIHNwcmVhZCBhY3Jvc3MgbW9yZSB0aGFuIG9uZSBMaW5r IFRMVi4gIFNpZ25pZmljYW50bHksIFJGQyAzNjMwIGRvZXMgbm90IHByb3ZpZGUgYW55IHJ1bGVz IGFzIHRvIGhvdyBhbiBPU1BGIGltcGxlbWVudGF0aW9uIHNob3VsZCBnZW5lcmF0ZSBtdWx0aXBs ZSBURSBsaW5rIFRMVnMgZm9yIHRoZSBzYW1lIGxpbmsuICBTaW1pbGFybHksIGl0IGRvZXMgbm90 IGluZGljYXRlIGhvdyBhbiBPU1BGIGltcGxlbWVudGF0aW9uIHNob3VsZCBoYW5kbGUgbXVsdGlw bGUgcmVjZWl2ZWQgTGluayBUTFZzIGZvciB0aGUgc2FtZSBsaW5rLiAgRm9yIGV4YW1wbGUsIGlm IGFuIE9TUEYgaW1wbGVtZW50YXRpb24gcmVjZWl2ZXMgdHdvIExpbmsgVExWcywgYm90aCBvZiB3 aGljaCBoYXZlIHRoZSBzYW1lIGxpbmsgdHlwZSBhbmQgbGluayBJRCBzdWItVExWcywgYnV0IGRp ZmZlcmVudCB2YWx1ZXMgZm9yIHRoZSBVbnJlc2VydmVkIGJhbmR3aWR0aCBzdWItVExWLCB3aGF0 IHNob3VsZCBpdCBkbz8NCj4+DQo+PiBJbiBzdW1tYXJ5LCB0aGUgYmVoYXZpb3Igb2YgYW4gT1NQ RiBpbXBsZW1lbnRhdGlvbiByZWNlaXZpbmcgbXVsdGlwbGUgTGluayBUTFZzIGZvciB0aGUgc2Ft ZSBsaW5rIGlzIG5vdCB3ZWxsIGRlZmluZWQuICBJIHN1c3BlY3QgdGhhdCBtb3N0IE9TUEYgaW1w bGVtZW50YXRpb25zIGFzc3VtZSB0aGF0IHRoZXJlIGlzIGF0IG1vc3Qgb25lIExpbmsgVExWIGZv ciBlYWNoIGxpbmsuICBIZW5jZSB0aGUgc3VnZ2VzdGlvbiBvZiBzZWN0aW9uIDUgb2YgZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIgZm9yIHVzaW5n IG11bHRpcGxlIExpbmsgVExWcyBpcyBsaWtlbHkgdG8gbGVhZCB0byBpbnRlcm9wZXJhYmlsaXR5 IHByb2JsZW1zLg0KPj4NCj4+IFRoZSBzb2x1dGlvbiBtaWdodCBiZSB0byBkZWZpbmUgYSBuZXcg VExWIHR5cGUgKEdlbmVyaWMgTGluayBUTFY/KSBmb3IgZGlzdHJpYnV0aW5nIHRoZSBQb3J0IExh YmVsIFJlc3RyaWN0aW9ucywgQXZhaWxhYmxlIExhYmVscyBhbmQgQXZhaWxhYmxlIFNoYXJlZCBC YWNrdXAgTGFiZWwgc3ViLVRMVnMgaW4gT1NQRiwgYWxvbmcgd2l0aCBhIGNsZWFyIGRlc2NyaXB0 aW9uIG9mIGl0cyB1c2UuICBJbiBwYXJ0aWN1bGFyLCB3ZSBuZWVkIHRoZSBmb2xsb3dpbmcuDQo+ PiAtICAgICAgIEEgY2xlYXIgc3RhdGVtZW50IHRoYXQgbXVsdGlwbGUgVExWcyBhcmUgYWxsb3dl ZCBmb3IgdGhlIHNhbWUgbGluay4NCj4+IC0gICAgICAgUnVsZXMgc3BlY2lmeWluZyBob3cgc3Vi LVRMVnMgY2FuIGJlIGRpc3RyaWJ1dGVkIGFjcm9zcyB0aGUgbXVsdGlwbGUgVExWcyAoZS5nLiB0 aGVyZSBtdXN0IGJlIGF0IG1vc3Qgb25lIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViBhY3Jvc3Mg YWxsIFRMVnMgZm9yIHRoZSBzYW1lIGxpbmspLg0KPj4gLSAgICAgICBSdWxlcyBzcGVjaWZ5aW5n IGhvdyBtdWx0aXBsZSBUTFZzIHNob3VsZCBiZSBpbnRlcnByZXRlZC4gIChUaGlzIHNob3VsZCBi ZSBzaW1wbGUgaWYgdGhlIHJ1bGVzIGZvciBidWlsZGluZyB0aGUgVExWcyBhcmUgd2VsbCBkZWZp bmVkLikNCj4+DQo+PiBMZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4NCj4+DQo+PiBUaGFua3Ms DQo+PiBKb24NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlZXlvdW5nDQo+PiBT ZW50OiAxMCBPY3RvYmVyIDIwMTEgMTc6MzYNCj4+IFRvOiBBbmRyZWEgWmFuYXJkaQ0KPj4gQ2M6 IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBb Q0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJp bGl0eS1vc3BmLTA2LnR4dA0KPj4NCj4+IEhpIEFuZHJlYSwNCj4+DQo+PiBJIHNlZSB5b3VyIHBv aW50IG1vcmUgY2xlYXJseS4gWW91IGFyZSBjb25jZXJuZWQgYWJvdXQgdGhlIGludGVyb3BlcmFi aWxpdHkgaXNzdWUgYmV5b25kIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcm90b2NvbCB0byBl bnN1cmUgdHdvIGltcGxlbWVudGF0aW9ucyBzaG91bGQgaW50ZXJvcGVyYXRlIGVhY2ggb3RoZXIu IFRvIHRoYXQgZW5kLCBwbGVhc2UgcHJvcG9zZSBzb21lIHRleHQuIFRoYW5rcy4NCj4+DQo+PiBC ZXN0IFJlZ2FyZHMsDQo+PiBZb3VuZw0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiBBbmRyZWEgWmFuYXJkaSBbbWFpbHRvOmFuZHJlYS56YW5hcmRpQGNyZWF0ZS1u ZXQub3JnXQ0KPj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDA5LCAyMDExIDExOjUzIEFNDQo+PiBU bzogTGVleW91bmcNCj4+IENjOiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ DQo+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdz b24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+DQo+PiBIaSBZb3VuZywNCj4+ DQo+PiBJIHRoaW5rIEkgY2xhcmlmaWVkIHdoYXQgSSBtZWFudCBpbiBteSByZXBseSB0byBBY2Vl IGNvbW1lbnRzLg0KPj4NCj4+IEFueXdheSwgbXkgb3JpZ2luYWwgY29tbWVudHMgd2VyZSByZWxh dGVkIHRvOg0KPj4NCj4+IGEuICB0aGUgcG9zc2liaWxpdHkgb2Ygc2VuZGluZyBhIFRFIExpbmsg TFNBIHVwZGF0ZSAoc2FtZSBJRCwgbmV3IHNlcXVlbmNlIG51bWJlcikNCj4+ICAgICAgd2l0aG91 dCBzb21lIHN1Yi1UTFZzIGlmIHRoZWlyIHZhbHVlIGlzIHVuY2hhbmdlZCwgYXMgSSB1bmRlcnN0 b29kIHdoZW4geW91IHdyb3RlDQo+Pg0KPj4gICAgICAiQWxsIG90aGVyIHN1Yi1UTFYgYXJlIG9w dGlvbmFsIGFuZCBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlDQo+PiAgICAgICAod2hlbiB0aGVyZSBh cmUgZW5vdWdoIGNoYW5nZXMgZnJvbSB0aGUgcHJldmlvdXMgcGVyaW9kIHRoYXQgZGVzZXJ2ZSBh biB1cGRhdGUpDQo+PiAgICAgICBhbmQgX25lZWQgbm90XyBiZSBpbmNsdWRlZCBpbiB0aGUgVEUg TGluayBUTFYgd2hlbiB0aGVyZSBpcyBubyBuZWVkIGZvciB1cGRhdGluZy4iDQo+Pg0KPj4gICAg IChidXQgY29ycmVjdCBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBzZW50ZW5jZSkNCj4+DQo+ PiAgICAgVGhpcyBjbGVhcmx5IGNhbid0IHdvcmsgZHVlIHRvIGhvdyB0aGUgVEUgREIgc3luY2hy b25pemF0aW9uIHdvcmtzLg0KPj4NCj4+ICAgICBOb3RlIHRoYXQgYWxzbyBjcmVhdGluZyBhIG5l dyBMU0EgKG5ldyBJRCkgd2l0aCBvbmx5IHRoZSBjaGFuZ2VkIHN1Yi1UTFZzIGRvZXNuJ3QNCj4+ ICAgICB3b3JrLCBhcyB5b3Ugd2lsbCBoYXZlIHR3byBkaWZmZXJlbnQgdmFsdWVzIGZvciB0aGUg c2FtZSBzdWItVExWDQo+PiAgICAgKGFzIHRoZSBvbGQgTFNBIGFuZCB0aGUgbmV3IExTQSBhcmUg Ym90aCBwcmVzZW50IGluIHRoZSBURSBEQikNCj4+DQo+PiAgICAgSSByZWFkIHRoZSAibWF5IG9j Y3VyIGF0IGxlYXN0IG9uY2UiIGluIFJGQyAzNjMwIGFzOg0KPj4gICAgICJpdCBtYXkgYmUgb21p dHRlZCBpZiBpdCBkb2VzIG5vdCBhcHBseSB0byB0aGUgbGluayI7DQo+PiAgICAgYnV0IGlmIGl0 IGFwcGxpZXMsIGl0IG11c3QgYmUgcHJlc2VudCBpbiBhbGwgdXBkYXRlcw0KPj4gICAgICh1bmxl c3MgeW91IHdhbnQgdG8gY2xlYXIgaXRzIHZhbHVlKQ0KPj4NCj4+DQo+PiBiLiB0aGUgZmFjdCB0 aGF0IFJGQyAzNjMwIGFsbG93cyB0aGUgcG9zc2liaWxpdHkgb2Ygc3BsaXR0aW5nIHRoZQ0KPj4g ICAgIHNldCBvZiBzdWItVExWcyBvZiBhIFRFIExpbmsgaW4gZGlmZmVyZW50IExTQXMgKGRpZmZl cmVudCBJRHMpDQo+PiAgICAgW3RoZSBpbXBsZW1lbnRhdGlvbiBJIGNoZWNrZWQgZG9lc24ndCBz dXBwb3J0IHRoaXMgc2NlbmFyaW9dDQo+Pg0KPj4gICAgIFRoaXMgY291bGQgYmUgYSBtYXR0ZXIg b2YgaW50ZXJwcmV0YXRpb247IGJ1dCBhcyBpdCdzIG5vdCBleHBsaWNpdGx5DQo+PiAgICAgc3Rh dGVkLCB0aGUgc2ltcGxlc3QgaW50ZXJwcmV0YXRpb24gaXMgdXN1YWxseSB0aGUgb25lIGFjY2Vw dGVkLg0KPj4NCj4+IEkgcGVyZmVjdGx5IGFncmVlIHRoYXQgc3BsaXR0aW5nIGEgc2V0IG9mIGF0 dHJpYnV0ZXMgcmVsYXRlZCB0bw0KPj4gYSAnbG9naWNhbCcgaW5zdGFuY2UgaW4gdHdvIG9yIG1v cmUgZGlmZmVyZW50IExTQXMgaXMgYSB2aWFibGUgc29sdXRpb24NCj4+IChhcyBmYXIgYXMgeW91 IGtlZXAgdGhlIHN1YnNldHMgZGlzam9pbnQgYW5kIHRoZSBzdXBwb3J0IGZvciB0aGlzDQo+PiBz b2x1dGlvbiBpcyBleHBsaWNpdGx5IHJlcXVlc3RlZDsgYW5kIHRoaXMgaXMgc29tZWhvdyBzdGF0 ZWQNCj4+IGluIHRoZSBkcmFmdCBpbiBDaGFwLiAzLjIuMSkuDQo+Pg0KPj4gRXZlbiBpZiwgaW4g bXkgb3Bpbmlvbiwgd291bGQgYmUgcHJlZmVyYWJsZSB0byBoYXZlIHNvbWUgcnVsZQ0KPj4gZGVm aW5lZDsgZXNwZWNpYWxseSBpZiB0aGUgcmVhc29uIGZvciB0aGUgc3BsaXR0aW5nIGlzIHRoZSBk eW5hbWljcw0KPj4gb2YgdGhlIHVwZGF0ZXMgYW5kIG5vdCBqdXN0IHRoZSBzaXplLg0KPj4NCj4+ IFNvcnJ5IGlmIHRoZXJlIGhhcyBiZWVuIGFueSBtaXN1bmRlcnN0YW5kaW5nLg0KPj4NCj4+IFJl Z2FyZHMNCj4+IEFuZHJlYQ0KPj4NCj4+DQo+PiBPbiAxMC8wOC8yMDExIDEyOjQ2IEFNLCBMZWV5 b3VuZyB3cm90ZToNCj4+PiBIaSBBbmRyZWEsDQo+Pj4NCj4+PiBTb3JyeSBmb3IgbXkgbGF0ZSBy ZXNwb25zZSB0byB5b3VyIHF1ZXN0aW9ucy4gUGxlYXNlIHNlZSBpbi1saW5lIGZvciBteSBjb21t ZW50cy4gVGhhbmtzLg0KPj4+DQo+Pj4gWW91bmcNCj4+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4gRnJvbTogQW5kcmVhIFphbmFyZGkgW21haWx0bzphbmRyZWEuemFuYXJk aUBjcmVhdGUtbmV0Lm9yZ10NCj4+PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDA0LCAyMDExIDk6 MTAgQU0NCj4+PiBUbzogTGVleW91bmcNCj4+PiBDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNj YW1wQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+DQo+ Pj4gSGkgWW91bmcsDQo+Pj4NCj4+PiB3aXRoIHJlc3BlY3QgdG8gdGhlIFRFIERCIG1hbmFnZW1l bnQgb2YgbWlzc2luZyBzdWItVExWcyBpbiBMU0EgdXBkYXRlcywNCj4+PiBJIGNoZWNrZWQgdGhl IGJlaGF2aW9yIG9mIGEgY29tbWVyY2lhbCBPU1BGLVRFIGltcGxlbWVudGF0aW9uLg0KPj4+DQo+ Pj4gWU9VTkc+PiAgSGVyZSBJIGFzc3VtZWQgdGhlIExTQXMgYXJlIHR3byBkaWZmZXJlbnQgTFNB cyAoaWRlbnRpZmllZCBieSB0aGUgTFNBIElEKS4NCj4+Pg0KPj4+IFRoZSBwb2ludCBpcyB0aGF0 LCBpZiB0aGUgVEUgREIgaXMgdGhlIHNldCBvZiBMU0FzLCB0aGF0J3MgaG93IGl0IHdvcmtzDQo+ Pj4gYXMgdGhlIFRFIERCIGNvbnRhaW5zIG9ubHkgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIGFuIExT QSBpbnN0YW5jZQ0KPj4+IGFuZCB5b3UgY2FuIG5vdCBtZXJnZSB0aGUgY29udGVudCBvZiBkaWZm ZXJlbnQgTFNBIHZlcnNpb25zDQo+Pj4gKHlvdSBjb3VsZCBrZWVwIGFuIGludGVybmFsIG1vZGVs IGZvciB0aGUgbGlua3Mgd2l0aCB0aGVpciBhdHRyaWJ1dGVzDQo+Pj4gdXBkYXRlZCBpbmRlcGVu ZGVudGx5LCBidXQgd2hlbiB0d28gbmVpZ2hib3JzIHN5bmNocm9uaXplIHRoZWlyIERCLA0KPj4+ IHRoZXkgc3luY2hyb25pemUgdGhlIExTQSBzZXQsIG5vdCB0aGUgaW50ZXJuYWwgbW9kZWxzKS4N Cj4+Pg0KPj4+IFlPVU5HPj4gIEhlcmUgaXMgYSBiaXQgY29uZnVzaW5nLiBUaGUgVEUgREIgc3lu Y2hyb25pemF0aW9uIHByb2Nlc3MgY2hlY2tzIHRoZSBzYW1lIExTQSBhbmQgdGhlIHNlcXVlbmNl IG51bWJlciAod2hpY2ggeW91IGFyZSByZWZlcnJpbmcgYXMgdGhlIHZlcnNpb24gb2YgYW4gTFNB IGluc3RhbmNlKS4gV2hlbiB0aGUgbm9kZSBpZGVudGlmaWVzIHRoZSBzYW1lIExTQSB3aXRoIGRp ZmZlcmVudCBzZXF1ZW5jZSBudW1iZXIsIHRoZW4gaXQgZmx1c2hlcyB0aGUgTFNBIHdpdGggdGhl IGxvd2VyIHNlcXVlbmNlIG51bWJlci4gQnV0IHRoZSBURSBEQiBzeW5jaCBwcm9jZXNzIGRvZXMg bm90IGNoZWNrIGVhY2ggb3RoZXIgZm9yIGRpZmZlcmVudCBMU0FzICh3aGljaCBpcyBpZGVudGlm aWVkIGJ5IHRoZSBMU0EgSUQpLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFdpdGggcmVzcGVjdCB0byBS RkMgMzYzMCwgaXQgc3RhdGVzOg0KPj4+DQo+Pj4gICAgMi40LjIuICBMaW5rIFRMVg0KPj4+DQo+ Pj4gICAgICAgVGhlIExpbmsgVExWIGRlc2NyaWJlcyBhIHNpbmdsZSBsaW5rLg0KPj4+DQo+Pj4g SSByZWFkICdkZXNjcmliZXMnIGFzICdmdWxseSBkZXNjcmliZXMnIChub3QgJ3BhcnRpYWxseSBk ZXNjcmliZXMnKTsNCj4+PiBzbyBJIGRvbid0IHNlZSB3aGVyZSBpdCBzdXBwb3J0cy9zdWdnZXN0 cyB0aGUgZGl2aXNpb24gb2YgdGhlIGF0dHJpYnV0ZXMgb24gbXVsdGlwbGUNCj4+PiBMU0EgaW5z dGFuY2VzIGFuZCB0aGF0J3Mgd2h5IEkgdGhpbmsgdGhhdCBtdWx0aXBsZSBMU0EgaW5zdGFuY2Vz IGZvciB0aGUNCj4+PiBzYW1lIGxpbmsgaXMgbm90IHN1cHBvcnRlZCBieSBjdXJyZW50IGltcGxl bWVudGF0aW9ucy4NCj4+Pg0KPj4+IFlPVU5HPj4gIFJGQzM2MzAgZGlmZmVyZW50aWF0ZXMgdGhl IG1hbmRhdG9yeSBlbGVtZW50IGZyb20gb3RoZXIgZW50aXRpZXMgdGhhdCBjYW4gYXBwZWFyICJh dCBtb3N0IiBvbmNlLg0KPj4+IFRoaXMgaXMgZnJvbSBSRkMgMzYzMCBTZWN0aW9uIDIuNC4yOg0K Pj4+DQo+Pj4gICAgIFRoZSBMaW5rIFR5cGUgYW5kIExpbmsgSUQgc3ViLVRMVnMgYXJlIG1hbmRh dG9yeSwgaS5lLiwgbXVzdCBhcHBlYXINCj4+PiAgICAgZXhhY3RseSBvbmNlLiAgQWxsIG90aGVy IHN1Yi1UTFZzIGRlZmluZWQgaGVyZSBtYXkgb2NjdXIgYXQgbW9zdA0KPj4+ICAgICBvbmNlLiAg VGhlc2UgcmVzdHJpY3Rpb25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4NCj4+ PiAgICAgVW5yZWNvZ25pemVkIHN1Yi1UTFZzIGFyZSBpZ25vcmVkLg0KPj4+DQo+Pj4gWU9VTkc+ PiAgSXQgZG9lcyBub3QgbWFuZGF0ZSBvdGhlciBzdWItVExWcyB0byBhcHBlYXIgZXhhY3RseSBv bmNlOyBpdCByYXRoZXIgc2F5cyBpdCBtYXkgb2NjdXIgImF0IG1vc3Qgb25jZSIgLS0gc291bmQg bGlrZSB0byBtZQ0KPj4+IFlPVU5HPj4gIHRoaXMgaXMgYW4gb3B0aW9uYWwgZWxlbWVudC4NCj4+ Pg0KPj4+IEl0J3MgYSBwb3NzaWJsZSBpbXBsZW1lbnRhdGlvbiBhbmQgaXQncyBmaW5lIHRvIHN1 Z2dlc3QgaXQgZm9yIG90aGVyIHRvcCBsZXZlbCBUTFZzLA0KPj4+IGJ1dCBpdCdzIG5vdCB0aGUg b25lIGRlZmluZWQgYnkgUkZDIDM2MzAgZm9yIFRFIExpbmtzLCBpbiBteSBvcGluaW9uLg0KPj4+ DQo+Pj4gTXkgcG9pbnQgaXMgaW4gYXZvaWRpbmcgYW1iaWd1aXRpZXM6IGlmIHRoZSBzdXBwb3J0 IGZvciBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIGZvciB0aGUNCj4+PiBzYW1lIGVudGl0eSB0b3Ag VExWIGlzIHJlcXVlc3RlZCwgaXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgc3RhdGVkIGFzIG1hbmRh dG9yeQ0KPj4+IChwb3NzaWJseSBwcm92aWRpbmcgZXhwbGljaXQgcnVsZXMgZm9yIHRoZSBzdWJk aXZpc2lvbiwgYXMgaW4gQ2hhcC4gMyBvZiB0aGUgZHJhZnQpLg0KPj4+DQo+Pj4NCj4+PiBZT1VO Rz4+ICBXaGVuIHlvdSBoYXZlIGRpZmZlcmVudCBzdWItc2V0cyBvZiBUTFYncyB0byBiZSBwYWNr YWdlZCB1bmRlciB0aGUgT1BTRiBURSBMU0EsIHlvdSBjYW4gdXNlIGEgZGlmZmVyZW50IExTQSBJ RCBmcm9tIHRoZSBwcmV2aW91c2x5IHVzZWQgb25lIHRvIGF2b2lkIGFtYmlndWl0aWVzLiBUaGVu IHRoZXNlIGFyZSBzaW1wbHkgdHdvIGRpZmZlcmVudCBMU0FzIGFuZCB3b3VsZCBub3QgY29uZnVz ZSB0aGUgVEUgREIgc3luYyBwcm9jZXNzIGFzIHdlbGwgYXMgZmxvb2RpbmcgcHJvY2Vzcy4NCj4+ Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4gQW5kcmVhDQo+Pj4NCj4+PiBPbiAxMC8wMy8yMDExIDA5OjM0 IFBNLCBMZWV5b3VuZyB3cm90ZToNCj4+Pj4gSGkgQW5kcmVhLA0KPj4+Pg0KPj4+PiBUaGFua3Mg Zm9yIHlvdXIgaW50ZXJlc3QgYW5kIGlucHV0IHRvIHRoaXMgaXNzdWUuDQo+Pj4+DQo+Pj4+IE15 IG92ZXJhbGwgcG9pbnQgd2FzIHRoYXQgdGhlIGN1cnJlbnQgR01QTFMgVEUgTFNBIChwZXIgUkZD IDM2MzApIGRvZXMgbm90IHNwZWNpZnkgZGV0YWlsIGltcGxlbWVudGF0aW9ucyBhcyB0byBob3cg dG8gZGl2aWRlIHVwIHRoZSBURSBMaW5rIFRMVnMgaW50byBzdGF0aWMgdnMuIGR5bmFtaWMgbm9y IGhvdyB0byB1c2UgbXVsdGlwbGUgVEUgTFNBcy4gVGhlIGN1cnJlbnQgV1NPTiBkb2N1bWVudCBm b2xsb3dzIGEgc2ltaWxhciBkb2N1bWVudCBwaGlsb3NvcGh5IHdpdGggdGhlIEdNUExTIHByZWRl Y2Vzc29yLg0KPj4+Pg0KPj4+PiBSZWdhcmRpbmcgeW91ciBwb2ludCBvbiBob3cgdGhlIFRFIERC IHdvcmtzIGluIHJlZ2FyZCB0byBtaXNzaW5nIHN1Yi1UTFZzIGFyZSBkZWxldGVkIHNlZW1zIHRv IG1lIGEgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggaXMgbW9zdCBzaW1wbGlzdGlj IGluIG5hdHVyZS4NCj4+Pj4NCj4+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+PiBZb3VuZw0KPj4+Pg0K Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBjY2FtcC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZWEgWmFuYXJkaQ0KPj4+PiBTZW50OiBN b25kYXksIE9jdG9iZXIgMDMsIDIwMTEgOToxNCBBTQ0KPj4+PiBUbzogTGVleW91bmcNCj4+Pj4g Q2M6IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDog UmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21w YXRpYmlsaXR5LW9zcGYtMDYudHh0DQo+Pj4+DQo+Pj4+IEhpIFlvdW5nLA0KPj4+Pg0KPj4+PiBJ IHdhcyBmb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gYW5kIEkgaGF2ZSBhIGRvdWJ0IGFib3V0DQo+ Pj4+IHlvdXIgZXhhbXBsZSByZWxhdGVkIHRvIHRoZSBURSBMaW5rIFRMVi4NCj4+Pj4NCj4+Pj4g SXQncyB0cnVlIHRoYXQgdGhlIGF0dHJpYnV0ZXMgc3ViLVRMViBhcmUgbm90IG1hbmRhdG9yeSBw ZXIgUkZDIDM2MzAsDQo+Pj4+IGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgbWVhbnMgdGhhdCB0aGV5 IGNhbiBiZSBub3QgaW5jbHVkZWQgaW4gYW4gTFNBIHVwZGF0ZQ0KPj4+PiBpZiB1bmNoYW5nZWQg KGltcGx5aW5nIHRoYXQgdGhlIHByZXZpb3VzIHZhbHVlIHBlcnNpc3RzKS4NCj4+Pj4NCj4+Pj4g QXMgZm9yIG15IHVuZGVyc3RhbmRpbmcgb2YgaG93IE9TUEYtVEUgd29ya3MsIHRoZSBtYW5hZ2Vk IFRFIERCIGVudGl0eSBpcyB0aGUgTFNBLg0KPj4+PiBXaGVuIGFuIExTQSB1cGRhdGUgaXMgcHJv Y2Vzc2VkLCB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBkZWxldGVkIGZyb20gdGhlIFRFIERCDQo+ Pj4+IGFuZCBpdCBpcyByZXBsYWNlZCBieSB0aGUgbmV3IG9uZTogbGluayBhdHRyaWJ1dGVzIHJl bGF0ZWQgdG8gbWlzc2luZyBzdWItVExWIGFyZQ0KPj4+PiBkZWxldGVkLCBzbyB0aGV5IG11c3Qg YmUgcHJlc2VudCBldmVuIGlmIHVuY2hhbmdlZC4NCj4+Pj4NCj4+Pj4gSW4gdGhlb3J5LCB0aGUg c2V0IG9mIGxpbmsgYXR0cmlidXRlcyBjb3VsZCBiZSBzdGF0aWNhbGx5IGRpdmlkZWQNCj4+Pj4g aW4gdHdvIGRpZmZlcmVudCBMU0FzIGluc3RhbmNlcyAodXBkYXRlZCBpbmRlcGVuZGVudGx5KSwN Cj4+Pj4gYnV0IEkgZG9uJ3QgdGhpbmsgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgaGFuZGxlIHRo aXMgc2NlbmFyaW8NCj4+Pj4gKGFsc28gYmVjYXVzZSwgaW4gbXkgb3BpbmlvbiwgaXQncyBub3Qg c3VnZ2VzdGVkIGJ5IFJGQyAzNjMwIGFuZA0KPj4+PiAgICAgaXQgZ2l2ZXMgbm8gcnVsZSBvbiBo b3cgdG8gZGl2aWRlIHRoZW0pLg0KPj4+Pg0KPj4+PiBCdXQgSSBhc2sgdG8gdGhlIG1haWxpbmcg bGlzdCBpZiB0aGlzIGlzIHRoZSBjb3JyZWN0IGludGVycHJldGF0aW9uLg0KPj4+Pg0KPj4+PiBS ZWdhcmRzLA0KPj4+PiBBbmRyZWENCj4+Pj4NCj4+Pj4gT24gMDkvMzAvMjAxMSAxMToxNiBQTSwg TGVleW91bmcgd3JvdGU6DQo+Pj4+PiBIaSBQaWVycmUsDQo+Pj4+Pg0KPj4+Pj4gSSBnb3QgeW91 ciBwb2ludC4gTGV0IG1lIGFzayB5b3UgdGhpcyBxdWVzdGlvbi4gSW4gdGhlIGN1cnJlbnQgR01Q TFMgT1NQRiBURSBMaW5rIFRMViBhcmUgZGVmaW5lZCB1bmRlciBPcGFxdWUgVEUgTFNBIHdpdGgg dGhlIGZvbGxvd2luZyBhdHRyaWJ1dGVzOg0KPj4+Pj4NCj4+Pj4+IC0gVEUgTWV0cmljDQo+Pj4+ PiAtIG1heCBCL1cNCj4+Pj4+IC0gbWF4IHJlc2VydmFibGUgYi93DQo+Pj4+PiAtIHVucmVzZXJ2 ZWQgYi93DQo+Pj4+PiAtIEFkbWluIEdyb3VwDQo+Pj4+PiAtIExpbmsgUHJvdGVjdGlvbiBUeXBl DQo+Pj4+PiAtIFNSTEcNCj4+Pj4+IC0gSVNDRA0KPj4+Pj4gLSBldGMuDQo+Pj4+Pg0KPj4+Pj4g QW5kIHRoZXNlIGFyZSBhIG1peHR1cmUgb2Ygc3RhdGljIGFuZCBkeW5hbWljIGluZm9ybWF0aW9u IGFuZCB5ZXQgdGhleSBhcmUgYXNzZW1ibGVkIHRvZ2V0aGVyIGFzIG9uZSBURSBMaW5rIFRMVi4g Rm9yIGluc3RhbmNlIHRoZSBJU0NEIGlzIHF1aXRlIHNpbWlsYXIgdG8gUmVzb3VyY2UgQmxvY2sg SW5mbyBpbiB0aGF0IGl0IGRvZXMgbm90IGNoYW5nZSBvZnRlbiB1bmxlc3MgdGhlcmUgYXJlIG5l dyBlbGVtZW50cyBhZGRlZCBpbiB0aGUgbm9kZSBvciBjb25maWd1cmF0aW9uIGNoYW5nZXMgYW5k IHlldCBpdCBpcyBwYWNrYWdlZCB0b2dldGhlciB3aXRoIG90aGVyIGR5bmFtaWMgaW5mb3JtYXRp b24uDQo+Pj4+Pg0KPj4+Pj4gV2h5Pw0KPj4+Pj4NCj4+Pj4+IFRoZXJlIGFyZSBtYW55IHdheXMg dG8ga2VlcCBzdGF0aWMvdW5jaGFuZ2VkIGluZm9ybWF0aW9uIGZyb20gYmVpbmcgZmxvb2RlZC4g T25seSB0aGUgTGluayBUeXBlIGFuZCBMaW5rIElEIHdoaWNoIGFyZSBtYW5kYXRvcnkgaW4gdGhl IFRFIExpbmsgVExWIHBlciBSRkMzNjMwLiBBbGwgb3RoZXIgc3ViLVRMViBhcmUgb3B0aW9uYWwg YW5kIG1heSBvY2N1ciBhdCBtb3N0IG9uY2UgKHdoZW4gdGhlcmUgYXJlIGVub3VnaCBjaGFuZ2Vz IGZyb20gdGhlIHByZXZpb3VzIHBlcmlvZCB0aGF0IGRlc2VydmUgYW4gdXBkYXRlKSBhbmQgbmVl ZCBub3QgYmUgaW5jbHVkZWQgaW4gdGhlIFRFIExpbmsgVExWIHdoZW4gdGhlcmUgaXMgbm8gbmVl ZCBmb3IgdXBkYXRpbmcuDQo+Pj4+Pg0KPj4+Pj4gSSByZWFsbHkgZG9uJ3Qgc2VlIHRoZSBuZWVk IGZvciBhIHNlcGFyYXRlIHRvcC1sZXZlbCBUTFYgYW5kL29yIGEgc2VwYXJhdGUgTFNBIGZvciB0 aGUgUmVzb3VyY2UgQmxvY2sgaW5mb3JtYXRpb24uDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+ Pj4+IFlvdW5nDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4gRnJvbTogUEVMT1NPLCBQSUVSUkUgKFBJRVJSRSkgW21haWx0bzpwaWVy cmUucGVsb3NvQGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4+Pj4+IFNlbnQ6IEZyaWRheSwgU2VwdGVt YmVyIDMwLCAyMDExIDk6MzkgQU0NCj4+Pj4+IFRvOiBMZWV5b3VuZzsgY2NhbXBAaWV0Zi5vcmc8 bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KPj4+Pj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYu dHh0DQo+Pj4+Pg0KPj4+Pj4gSGkgWW91bmcsDQo+Pj4+Pg0KPj4+Pj4gSSB1bmRlcnN0YW5kIHRo ZSBjb250ZW50IG9mIHlvdXIgYW5zd2VyLCBidXQgSSdtIG5vdCBzYXRpc2ZpZWQgd2l0aCBpdC4N Cj4+Pj4+IE15IGNvbmNlcm4gZGVhbHMgd2l0aCBwcm92aWRpbmcgYSB1bmlxdWUgcmVhZGluZy9p bnRlcnByZXRhdGlvbiBvZiB0aGUgT1NQRi1URSBleHRlbnNpb25zLg0KPj4+Pj4gV2Ugd291bGQg bGlrZSB0byBtYWtlIHN1cmUgdGhhdCBhbnkgaW1wbGVtZW50YXRpb24gY29tcGx5aW5nIHRvIHRo ZSBkcmFmdHMgd291bGQgcHJvdmlkZSB0aGUgc2FtZSBMU0FzIHdoZW4gYXBwbGllZCB0byB0aGUg c2FtZSBuZXR3b3JrLg0KPj4+Pj4gV2l0aCB0aGlzIHBlcnNwZWN0aXZlIGluIG1pbmQsIHdlIHdp c2ggdG8gZ2V0IGRyYWZ0cyB3aXRoIHN1ZmZpY2llbnQgZG9jdW1lbnRhdGlvbiB0byBtYWtlIHN1 cmUgdGhlIExTQSBkZXNpZ24gcHJvY2VzcyB0byBiZSBkZXBpY3RlZCwgYnkgZGVzaWduIHJ1bGVz Lg0KPj4+Pj4NCj4+Pj4+IEhlbmNlIHRoZSBjb250ZW50IG9mIHlvdXIgYW5zd2VyIGxlYXZpbmcg bWUgdGhlICJvcHBvcnR1bml0eSB0byBkbyBhcyBJIHdpc2giLCBpcyBub3QgcGxlYXNpbmcgbWUs IEkgd291bGQgcmF0aGVyIGhhdmUgc3RyaWN0IHJ1bGVzLCBhbmQgZGlzY3Vzc2lvbnMgd2l0aCB0 aGUgV0cgb24gdGhlIGRlc2lnbiBvZiB0aG9zZS4NCj4+Pj4+IFRoYXQgaXMgd2h5IGEgZmlyc3Qg ZGVzaWduIHJ1bGUsIHdlIGNvdWxkIGFncmVlIG9uIGlzOiB0byBnYXRoZXIgdGhlIFJlc291cmNl IEJsb2NrIEluZm9ybWF0aW9uIFRMVnMgaW5zaWRlIGEgZGVkaWNhdGVkIExTQSwgcG9zc2libHkg d2l0aCBhIGRlZGljYXRlZCB0b3AtbGV2ZWwgVExWICh3aGljaCBpbiBteSBtaW5kIGFsbG93cyB0 byBlbmZvcmNlIHRoaXMgZGVzaWduIHJ1bGUpLg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+ Pg0KPj4+Pj4gLSBQaWVycmUNCj4+Pj4+DQo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4+Pj4+IERlIDogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3ZWkuY29tXQ0KPj4+ Pj4gRW52b3nDqSA6IG1lcmNyZWRpIDI4IHNlcHRlbWJyZSAyMDExIDAwOjA2DQo+Pj4+PiDDgCA6 IFBFTE9TTywgUElFUlJFIChQSUVSUkUpOyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0 Zi5vcmc+DQo+Pj4+PiBPYmpldCA6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4NCj4+Pj4+ IEhpIFBpZXJyZSwNCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ugc2VlLWlubGluZSBmb3IgbXkgcmVwbHkg dG8geW91ciBmaXJzdCBwb2ludC4NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gWW91bmcN Cj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogUEVM T1NPLCBQSUVSUkUgKFBJRVJSRSkgW21haWx0bzpwaWVycmUucGVsb3NvQGFsY2F0ZWwtbHVjZW50 LmNvbV0NCj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxMSAzOjI4IEFNDQo+ Pj4+PiBUbzogTGVleW91bmc7IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4N Cj4+Pj4+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAt d3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4NCj4+Pj4+IEhpIFlv dW5nLCBhbmQgQ0NBTVBlcnMsDQo+Pj4+Pg0KPj4+Pj4gSSB3YXMgb2ZmIHRoZSBtYWlsaW5nIGxp c3RzIGZvciB0aGUgbGFzdCB0d28gd2Vla3MgYW5kIGJlaW5nIGJhY2sgSSBub3RpY2UgYSBsb3Qg b2YgZXhjaGFuZ2VzLCB3aGljaCBJJ20gdmVyeSBnbGFkIG9mLg0KPj4+Pj4gSSd2ZSBhbHNvIG5v dGljZWQgbWFueSBkcmFmdHMgaGF2ZSBiZWVuIHVwZGF0ZWQuDQo+Pj4+PiBDb25jZXJuaW5nIHRo aXMgc3BlY2lmaWMgZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9z cGYtMDYsIEkgd2FudGVkIHRvIGNvbW1lbnQgc2VjdGlvbiAzLg0KPj4+Pj4gQmFjayBpbiBRdWVi ZWMsIEkgZXhwcmVzc2VkIG15IHBvaW50IG9mIHZpZXcgKHNoYXJlZCB3aXRoIEN5cmlsLCBKdWxp ZW4gYW5kIEdpb3Zhbm5pKSB0aGF0IGN1cnJlbnQgZHJhZnRzIHdlcmUgbGFja2luZyBndWlkYW5j ZSByZWdhcmRpbmcgdGhlIHdheSB0byBkZXNpZ24gTFNBcyB0aGF0IHdlcmUgdG8gZGVwaWN0IGFu IFdTT04gbm9kZSB3aXRoIE9FT3MuDQo+Pj4+PiBUaGlzIHNlY3Rpb24gMyBwcm92aWRlcyBhZGRp dGlvbmFsIG1hdGVyaWFsIHRvIGhlbHAgZGVzaWduaW5nIHRoZSBMU0EuDQo+Pj4+PiBJIHdvdWxk IGxpa2UgdG8ga25vdyB3aGV0aGVyIGF1dGhvcnMgYXJlIHdpbGxpbmcgdG8gcHVyc3VlIGZ1cnRo ZXIgaW4gdGhpcyBkaXJlY3Rpb24sIHdoaWNoIGlzIHRvIG15IG1pbmQgYSByZWFsIGNvcm5lciBz dG9uZSwgdGhhdCB3b3VsZCBoZWxwIGV2ZXJ5b25lIGFncmVlIG9uIGEgc29sdXRpb24uDQo+Pj4+ PiBBIGZpcnN0IHBvaW50IGNvdWxkIGNvbmNlcm4gdGhlIFJlc291cmNlIEJsb2NrIEluZm9ybWF0 aW9uIChyZW1pbmRlcjo8UmVzb3VyY2VCbG9ja0luZm8+ICAgIDo6PSAoWzxSZXNvdXJjZVNldD5d PElucHV0Q29uc3RyYWludHM+ICAgIDxQcm9jZXNzaW5nQ2FwYWJpbGl0aWVzPiAgICA8T3V0cHV0 Q29uc3RyYWludHM+KToNCj4+Pj4+ICAgICAgICAgV2UgYWxsIGFncmVlIHRoYXQgdGhlc2UgaW5m b3JtYXRpb24gYXJlIHN0YXRpYywgdGhhdCB3ZSBzaG91bGQgbm90IHJlcGxpY2F0ZSB0aGlzIFRM ViB3aGF0ZXZlciB0aGUgbnVtYmVyIG5vdCB0aGUgbGF5b3V0IG9mIE9FTyBib2FyZHMgb2YgYSBn aXZlbiB0eXBlLg0KPj4+Pj4gVGhlbiwgd2UgY291bGQgZGVkaWNhdGUgYSBzcGVjaWZpYyBpbmRl cGVuZGFudCBmbG9vZGluZyBlbnRpdHkuIFRoaXMgd291bGQgYmUgZGVmaW5lZCBvbmNlIGZvciBh bGwsIGFuZCB0aGF0IHdvdWxkIG5vdCBsZWF2ZSByb29tIHRvIGRpZmZlcmVudCBpbnRlcnByZXRh dGlvbnMuDQo+Pj4+PiBXaGF0IGFib3V0IHRoaXMgZmlyc3QgcG9pbnQ/DQo+Pj4+Pg0KPj4+Pj4g WU9VTkc+PiAgICBJZiBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSwgd2hhdCB5b3UgYXJlIHNh eWluZyBpcyBzaW5jZSB0aGUgUmVzb3VyY2UgQmxvY2sgSW5mbyBzdWItVExWIGlzIHZlcnkgc3Rh dGljIGluIG5hdHVyZSwgYWR2ZXJ0aXNlbWVudCBvZiB0aGlzIHN1Yi1UTFYgc2hvdWxkIGJlIHRy ZWF0ZWQgZGlmZmVyZW50bHkgZnJvbSB0aGUgcmVzdCBvZiBzdGF0aWMtVExWcyAod2hpY2ggbWF5 IGNoYW5nZSBvdmVyIHRpbWUpLiBJcyB0aGlzIHdoYXQgeW91IGFyZSBzYXlpbmc/DQo+Pj4+Pg0K Pj4+Pj4gSWYgbXkgaW50ZXJwcmV0YXRpb24gb2YgeW91ciBjb21tZW50IGlzIGNvcnJlY3QsDQo+ Pj4+Pg0KPj4+Pj4gLSBUaGUgY3VycmVudCBtZWNoYW5pc20gYWxsb3dzIHdoYXQgeW91IHdhbnQ6 IFBsZWFzZSBzZWUgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDMuMg0KPj4+Pj4gICAg ICAgIkluIHRoZSBoaWdobHkgdW5saWtlbHkgZXZlbnQgdGhhdCBhIFdTT04gc3ViLVRMViBieSBp dHNlbGYgd291bGQNCj4+Pj4+ICAgICAgIHJlc3VsdCBpbiBhbiBMU0EgZXhjZWVkaW5nIHRoZSBN VFUsIGFsbCBmaXZlIFdTT04gc3BlY2lmaWMgc3ViLVRMVnMNCj4+Pj4+ICAgICAgIGluIHRoaXMg ZG9jdW1lbnQgcHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgYWxsb3cgdGhlbSB0byBiZSBzdWJkaXZp ZGVkDQo+Pj4+PiAgICAgICBpbnRvIHNtYWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBp biBzZXBhcmF0ZSBPU1BGIFRFIExTQXMuIg0KPj4+Pj4NCj4+Pj4+IEFjY29yZGluZyB0byB0aGlz IGNsYXVzZSwgeW91IGNhbiBzZXBhcmF0ZSB0aGUgUmVzb3VyY2UgQmxvY2sgSW5mbyBTdWItVExW IGFzIHRoZSBzb2xlIGVudHJ5IGRlZmluZWQgaW4gdGhlIE9wdGljYWwgTm9kZSBwcm9wZXJ0eSBU TFYgaW4gYSBzZXBhcmF0ZSBURSBMU0EgZnJvbSB0aGUgcmVzdCBpZiB5b3Ugd2lsbC4gTm90aGlu ZyBwcmV2ZW50cyB0aGlzIHBhcnRpY3VsYXIgd2F5IG9mIHBhY2thZ2luZy4gKElzbid0IHRoaXMg d2hhdCB5b3UgbWVhbnQgImEgc3BlY2lmaWMgaW5kZXBlbmRlbnQgZmxvb2RpbmcgZW50aXR5Ij8p DQo+Pj4+Pg0KPj4+Pj4gLSBQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhpcyBleHBsYW5hdGlvbiBz YXRpc2ZpZXMgeW91LiBUaGFua3MgLS0tIFlvdW5nDQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+ Pj4+DQo+Pj4+PiBQaWVycmUNCj4+Pj4+DQo+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4+Pj4+IERlIDogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNl c0BpZXRmLm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IExlZXlvdW5nIEVudm95w6kgOiBqZXVkaSAxNSBzZXB0ZW1icmUgMjAxMSAyMTo1OSDDgCA6IGNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4gT2JqZXQgOiBSZTogW0NDQU1QXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3Nw Zi0wNi50eHQNCj4+Pj4+DQo+Pj4+PiBIaSBhbGwsDQo+Pj4+Pg0KPj4+Pj4gQWZ0ZXIgMDUgdmVy c2lvbiBwdWJsaWNhdGlvbiwgQWNlZSBwcm92aWRlZCBhIG51bWJlciBvZiB2YWx1YWJsZSBjb21t ZW50cyBhbmQgc3VnZ2VzdGlvbnMuIFRoaXMgcmV2aXNpb24gKDA2KSByZWZsZWN0cyB0aG9zZSBj aGFuZ2VzLiBQbGVhc2Ugbm90ZSB0aGUgZm9sbG93aW5nIHVwZGF0ZXM6DQo+Pj4+Pg0KPj4+Pj4g LSBDaGFuZ2UgdGhlIHRpdGxlIG9mIHRoZSBkcmFmdCB0byAiR01QTFMgT1NQRiBFbmhhbmNlbWVu dC4uLiIgZnJvbSAiT1NQRiBFbmhhbmNlbWVudC4uLiIgdG8gbWFrZSBzdXJlIHRoZSBjaGFuZ2Vz IGFwcGx5IHRvIHRoZSBHTVBMUyBPU1BGIHJhdGhlciB0aGFuIHRoZSBiYXNlIE9TUEYuDQo+Pj4+ Pg0KPj4+Pj4gLSBBZGQgc3BlY2lmaWMgT1NQRiBwcm9jZWR1cmVzIG9uIGhvdyBzdWItVExWcyBh cmUgcGFja2FnZWQgcGVyIFtSRkMzNjMwXSBhbmQgZWRpdG9yaWFsIGNoYW5nZSBpbmNsdWRpbmcg YXZvaWRpbmcgIm11bHRpcGxlIGluc3RhbmNlcyBvZiBURSBMU0EiIHRvICJtdWx0aXBsZSBURSBM U0FzIi4NCj4+Pj4+DQo+Pj4+PiBZb3VyIGNvbW1lbnRzIGFyZSBhbHdheXMgYXBwcmVjaWF0ZWQu IFRoYW5rcy4NCj4+Pj4+DQo+Pj4+PiBCZXN0IFJlZ2FyZHMuDQo+Pj4+PiBZb3VuZw0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4+PiBTZW50OiBUaHVy c2RheSwgU2VwdGVtYmVyIDE1LCAyMDExIDI6NDggUE0NCj4+Pj4+IFRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCj4+Pj4+IENjOiBjY2FtcEBp ZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4+PiBTdWJqZWN0OiBbQ0NBTVBdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3Bm LTA2LnR4dA0KPj4+Pj4NCj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5l IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+Pg0KPj4+Pj4gICBUaXRsZSAgICAgICAg ICAgOiBHTVBMUyBPU1BGIEVuaGFuY2VtZW50IGZvciBTaWduYWwgYW5kIE5ldHdvcmsgRWxlbWVu dCBDb21wYXRpYmlsaXR5IGZvciBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MN Cj4+Pj4+ICAgQXV0aG9yKHMpICAgICAgIDogWW91bmcgTGVlDQo+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEdyZWcgTS4gQmVybnN0ZWluDQo+Pj4+PiAgIEZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4 dA0KPj4+Pj4gICBQYWdlcyAgICAgICAgICAgOiAxNA0KPj4+Pj4gICBEYXRlICAgICAgICAgICAg OiAyMDExLTA5LTE1DQo+Pj4+Pg0KPj4+Pj4gICAgICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBH TVBMUyBPU1BGIHJvdXRpbmcgZW5oYW5jZW1lbnRzIHRvIHN1cHBvcnQNCj4+Pj4+ICAgICAgIHNp Z25hbCBjb21wYXRpYmlsaXR5IGNvbnN0cmFpbnRzIGFzc29jaWF0ZWQgd2l0aCBXU09OIG5ldHdv cmsNCj4+Pj4+ICAgICAgIGVsZW1lbnRzLiBUaGVzZSByb3V0aW5nIGVuaGFuY2VtZW50cyBhcmUg cmVxdWlyZWQgaW4gY29tbW9uIG9wdGljYWwNCj4+Pj4+ICAgICAgIG9yIGh5YnJpZCBlbGVjdHJv LW9wdGljYWwgbmV0d29ya3Mgd2hlcmUgbm90IGFsbCBvZiB0aGUgb3B0aWNhbA0KPj4+Pj4gICAg ICAgc2lnbmFscyBpbiB0aGUgbmV0d29yayBhcmUgY29tcGF0aWJsZSB3aXRoIGFsbCBuZXR3b3Jr IGVsZW1lbnRzDQo+Pj4+PiAgICAgICBwYXJ0aWNpcGF0aW5nIGluIHRoZSBuZXR3b3JrLg0KPj4+ Pj4NCj4+Pj4+ICAgICAgIFRoaXMgY29tcGF0aWJpbGl0eSBjb25zdHJhaW50IG1vZGVsIGlzIGFw cGxpY2FibGUgdG8gY29tbW9uIG9wdGljYWwNCj4+Pj4+ICAgICAgIG9yIGh5YnJpZCBlbGVjdHJv IG9wdGljYWwgc3lzdGVtcyBzdWNoIGFzIE9FTyBzd2l0Y2hlcywgcmVnZW5lcmF0b3JzLA0KPj4+ Pj4gICAgICAgYW5kIHdhdmVsZW5ndGggY29udmVydGVycyBzaW5jZSBzdWNoIHN5c3RlbXMgY2Fu IGJlIGxpbWl0ZWQgdG8NCj4+Pj4+ICAgICAgIHByb2Nlc3Npbmcgb25seSBjZXJ0YWluIHR5cGVz IG9mIFdTT04gc2lnbmFscy4NCj4+Pj4+DQo+Pg0KPj4NCj4+IC0tDQo+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gQW5kcmVhIFph bmFyZGkNCj4+IENSRUFURS1ORVQNCj4+IEVuZ2luZWVyaW5nICYgRmFzdCBQcm90b3R5cGluZyAo RU5HSU5FKSBBcmVhDQo+PiBTZW5pb3IgRW5naW5lZXINCj4+IFZpYSBhbGxhIENhc2NhdGEgNTYv RCAtIDM4MTIzIFBvdm8gVHJlbnRvIChJdGFseSkNCj4+IGUtbWFpbDogYW5kcmVhLnphbmFyZGlA Y3JlYXRlLW5ldC5vcmc8bWFpbHRvOmFuZHJlYS56YW5hcmRpQGNyZWF0ZS1uZXQub3JnPg0KPj4g VGVsOiAoKzM5KSAwNDYxIDQwODQwMCAtIGludGVybm8vZXh0ZW5zaW9uIDE0MDcNCj4+IE1vYmls ZTogKCszOSkgMzQwIDAwMTE4MzcNCj4+IEZheDogKCszOSkgMDQ2MSA0MjExNTcNCj4+IFNreXBl OiB6YW5hcmRpX2FuZHJlYQ0KPj4gd3d3LmNyZWF0ZS1uZXQub3JnPGh0dHA6Ly93d3cuY3JlYXRl LW5ldC5vcmc+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4NCj4+IFRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRl bmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0bw0KPj4gd2hpY2ggaXQgaXMgYWRk cmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQNCj4+ IG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBv dGhlciB1c2Ugb2YsIG9yDQo+PiB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1cG9u LCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3INCj4+IGVudGl0aWVzIG90aGVyIHRoYW4g dGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkIGFjY29yZGluZyB0byB0aGUNCj4+ IEl0YWxpYW4gTGF3IDE5Ni8yMDAzIG9mIHRoZSBMZWdpc2xhdHVyZS4gSWYgeW91IHJlY2VpdmVk IHRoaXMgaW4gZXJyb3IsDQo+PiBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlIG1hdGVyaWFsIGZyb20gYW55IGNvbXB1dGVyLg0KPj4NCj4+IExlIGluZm9ybWF6aW9uaSBj b250ZW51dGUgaW4gcXVlc3RvIG1lc3NhZ2dpbyBkaSBwb3N0YSBlbGV0dHJvbmljYSBlIG5laQ0K Pj4gZmlsZSBhbGxlZ2F0aSBzb25vIGRhIGNvbnNpZGVyYXJzaSBzdHJldHRhbWVudGUgcmlzZXJ2 YXRlLiBJbCBsb3JvIHV0aWxpenpvDQo+PiBlJyBjb25zZW50aXRvIGVzY2x1c2l2YW1lbnRlIGFs IGRlc3RpbmF0YXJpbyBkZWwgbWVzc2FnZ2lvLCBwZXIgbGUgZmluYWxpdGEnDQo+PiBpbmRpY2F0 ZSBuZWwgbWVzc2FnZ2lvIHN0ZXNzby4gUXVhbG9yYSByaWNldmVzdGUgcXVlc3RvIG1lc3NhZ2dp byBzZW56YQ0KPj4gZXNzZXJuZSBpbCBkZXN0aW5hdGFyaW8sIFZpIHByZWdoaWFtbyBjb3J0ZXNl bWVudGUgZGkgZGFyY2VuZSBub3RpemlhIHZpYQ0KPj4gZS1tYWlsIGUgZGkgcHJvY2VkZXJlIGFs bGEgY2FuY2VsbGF6aW9uZSBkZWwgbWVzc2FnZ2lvIHN0ZXNzbyBkYWwgVm9zdHJvDQo+PiBzaXN0 ZW1hLiBUcmF0dGVuZXJlIGlsIG1lc3NhZ2dpbyBzdGVzc28sIGRpdnVsZ2FybG8gYW5jaGUgaW4g cGFydGUsDQo+PiBkaXN0cmlidWlybG8gYWQgYWx0cmkgc29nZ2V0dGksIGNvcGlhcmxvLCBvZCB1 dGlsaXp6YXJsbyBwZXIgZmluYWxpdGEnDQo+PiBkaXZlcnNlLCBjb3N0aXR1aXNjZSBjb21wb3J0 YW1lbnRvIGNvbnRyYXJpbyBhaSBwcmluY2lwaSBkZXR0YXRpIGRhbCBELiBMZ3MuDQo+PiAxOTYv MjAwMy4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NB TVBAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4gQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1Q QGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWls aW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NjYW1wDQo= From Alan.Davey@metaswitch.com Wed Nov 2 03:10:01 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D85811E815D for ; Wed, 2 Nov 2011 03:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9udcnkX+WBc for ; Wed, 2 Nov 2011 03:09:56 -0700 (PDT) Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF5921F8B9B for ; Wed, 2 Nov 2011 03:09:24 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by enficsets2.metaswitch.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 2 Nov 2011 10:09:11 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 10:09:17 +0000 From: Alan Davey To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths Thread-Index: AcyX1RR10CtFlVFDRAKC9usPJOD2LQAD0Oyw Date: Wed, 2 Nov 2011 10:09:17 +0000 Message-ID: References: <038d01cc9596$5d429760$17c7c620$@olddog.co.uk> <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> <4EAEA9A2.7000900@cttc.es> In-Reply-To: <4EAEA9A2.7000900@cttc.es> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:104:4001:72:cd01:f8b0:5a18:1e14] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:10:01 -0000 Hi Ramon I think that this is a separate point to those in the errata. =20 My view on your question is that the egress must signal its link endpoint i= dentification for each IGP instance and therefore there must be N instances= of the object in the Resv in your example. Each instance of the object co= uld be considered to be associated with a different IGP instance identifier= even if the TLV is not actually present. In the general case, the values = of the other fields and TLVs in the LSP_TUNNEL_INTERFACE_ID objects may not= be the same. For example, the interface address could be different for ea= ch IGP instance. Regards Alan Davey -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of R= amon Casellas Sent: 31 October 2011 13:58 To: ccamp@ietf.org Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signal= ed Hierarchical Label Switched Paths El 31/10/2011 14:20, Adrian Farrel escribi=F3: > Looks fine, but I would like to hear agreement from the WG. > > Thanks, > Adrian > >> -----Original Message----- >> From: Alan Davey [mailto:Alan.Davey@metaswitch.com] >> Original text: >> The TLV has meaning only in a Path message. It SHOULD NOT be >> included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and >> MUST be ignored if found. >> >> Corrected text: >> The TLV has meaning only in a Path message. At most one TLV >> MAY appear in a single LSP_TUNNEL_INTERFACE_ID object. >> >> The TLV SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object >> in a Resv message and MUST be ignored if found. Hi Adrian, Alan, all I'm a bit confused about this part. If : - several LSP_TUNNEL_INTERFACE_ID are used in the Path message to=20 announce the same link in different instances (say N), and - a TLV is used in each LSP_TUNNEL_INTERFACE_ID within such Path message=20 (with the instance), and - the TLVs SHOULD be suppressed in Resv, do we end up with 1 or N identical LSP_TUNNEL_INTERFACE_ID in the Resv=20 (assuming no other TLVs)? It seems that they could be coalesced into 1, in order not to be in=20 contradiction with section 3.4 ("Each instance MUST have a different IGP Instance Identifier", which could be understood to preclude=20 identical copies. but probably I am missing something) So either there are N instances with the TLV (which it shouldn't by the=20 above text but must according to 3.4) or 1 without TLV?. I would say the=20 latter, but I would like your comments R. ---------------------------------- Section 3.4 quote It is possible that an LSP will be used to offer capacity and connectivity to multiple other networks. In this case, multiple instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the same Path and Resv messages. Each instance MUST have a different IGP Instance Identifier. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From ramon.casellas@cttc.es Wed Nov 2 03:21:13 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E933111E814E for ; Wed, 2 Nov 2011 03:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fmDVNArK3LY for ; Wed, 2 Nov 2011 03:21:13 -0700 (PDT) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0518311E8149 for ; Wed, 2 Nov 2011 03:21:12 -0700 (PDT) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA2AKxHi008871; Wed, 2 Nov 2011 11:21:04 +0100 Received: from [84.88.61.50] (unknown [84.88.61.50]) by castor (Postfix) with ESMTP id 412B92FC284; Wed, 2 Nov 2011 11:21:00 +0100 (CET) Message-ID: <4EB119F1.7010309@cttc.es> Date: Wed, 02 Nov 2011 11:22:41 +0100 From: Ramon Casellas Organization: CTTC User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Alan Davey References: <038d01cc9596$5d429760$17c7c620$@olddog.co.uk> <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> <4EAEA9A2.7000900@cttc.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 02 Nov 2011 11:21:00 +0100 (CET) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:21:14 -0000 El 02/11/2011 11:09, Alan Davey escribió: > Hi Ramon > > I think that this is a separate point to those in the errata. > > My view on your question is that the egress must signal its link endpoint identification for each IGP instance and therefore there must be N instances of the object in the Resv in your example. Each instance of the object could be considered to be associated with a different IGP instance identifier even if the TLV is not actually present. In the general case, the values of the other fields and TLVs in the LSP_TUNNEL_INTERFACE_ID objects may not be the same. For example, the interface address could be different for each IGP instance. Fair enough, I guess I was wondering whether the text in sect 3.4 should be clarified, or it clearly means "Each instance MUST have a different IGP Instance Identifier if the TLV is present". Thanks R. Section 3.4 "In this case, multiple (...) Each instance MUST have a different IGP Instance Identifier." From lberger@labn.net Wed Nov 2 04:27:30 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8B11E8166 for ; Wed, 2 Nov 2011 04:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.926 X-Spam-Level: X-Spam-Status: No, score=-99.926 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXq665zpp0aM for ; Wed, 2 Nov 2011 04:27:29 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id C394D11E815C for ; Wed, 2 Nov 2011 04:27:25 -0700 (PDT) Received: (qmail 9720 invoked by uid 0); 2 Nov 2011 11:27:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 2 Nov 2011 11:27:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=UoId+BqRW75qMNLivhScRJQ9utgcz4LB+BtAuHNd14s=; b=KPXwKNp7QA5ZJVMLVSByS0E0LYA9m7qSCH96eKbot9m0E+A7hYc+S7LWbUs3+kVQGpYPiqrJVMzTlWe2yq0LSDR8d43s5MrOwFv17s8n+TrzxWOIpxLfCrnkI0vSsGOQ; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RLYyZ-0002GY-F4; Wed, 02 Nov 2011 05:27:23 -0600 Message-ID: <4EB1291F.4000003@labn.net> Date: Wed, 02 Nov 2011 07:27:27 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <038d01cc9596$5d429760$17c7c620$@olddog.co.uk> <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> In-Reply-To: <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, 'Alan Davey' Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:27:30 -0000 Adrian/Alan, I think there are separable issues here that should be addressed independently. Item 2 below is easy, and clear cut. It should result in an errata. Item 1 is more problematic as an errata. I agree with Adrian's analysis: RFC 6107 states that advertisement of "multiple instances of the LSP_TUNNEL_INTERFACE_ID object are permitted", but doesn't say it's required or that multiple TLVs of the same type are not permitted. Based on this, I think it's reasonable to have an errata that highlights that a receiver should be prepared to receive both multiple LSP_TUNNEL_INTERFACE_ID objects and multiple TLVs of the same time within a single object. While it may be reasonable for an errata to suggest reducing the number of options, I think changing behavior on the wire really needs to be run through the normal working group process. Lou On 10/31/2011 9:20 AM, Adrian Farrel wrote: > Looks fine, but I would like to hear agreement from the WG. > > Thanks, > Adrian > >> -----Original Message----- >> From: Alan Davey [mailto:Alan.Davey@metaswitch.com] >> Sent: 31 October 2011 11:41 >> To: Adrian Farrel Personal >> Cc: ccamp@ietf.org >> Subject: RE: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled >> Hierarchical Label Switched Paths >> >> Hi Adrian >> >> Thank you for your response, and for spotting another erratum in RFC6107. I >> propose raising the following technical errata against the RFC, both in > section 3.2. >> Please let me know whether or not you agree. >> >> 1. State that at most one Target IGP Identification TLV may appear in a > single >> LSP_TUNNEL_INTERFACE_ID object. >> >> Original text: >> The TLV has meaning only in a Path message. It SHOULD NOT be >> included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and >> MUST be ignored if found. >> >> Corrected text: >> The TLV has meaning only in a Path message. At most one TLV >> MAY appear in a single LSP_TUNNEL_INTERFACE_ID object. >> >> The TLV SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object >> in a Resv message and MUST be ignored if found. >> >> 2. Section 3.2, change Resv message to Path message. >> >> Original text: >> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >> object in a Resv message is set (i.e., one) indicating that the LSP >> is not to be advertised as a link, this TLV SHOULD NOT be present and >> MUST be ignored if encountered. >> >> Corrected text: >> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >> object in a Path message is set (i.e., one) indicating that the LSP >> is not to be advertised as a link, this TLV SHOULD NOT be present and >> MUST be ignored if encountered. >> >> Regards >> Alan Davey >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >> Adrian Farrel >> Sent: 28 October 2011 18:24 >> To: Alan Davey; ccamp@ietf.org >> Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled >> Hierarchical Label Switched Paths >> >> Hi Alan, >> >> Nice to be made to read stuff because you come across typos. I think that >> Section 3.2 >> >> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >> object in a Resv message is set (i.e., one) indicating that the LSP >> is not to be advertised as a link, this TLV SHOULD NOT be present and >> MUST be ignored if encountered. >> >> s/Resv/Path/ ! >> >> That merits an erratum if anyone can be bothered. >> >>> I have a question on RFC6107; is it permitted to have more than one >>> Target IGP Identification TLV in a single LSP_TUNNEL_INTERFACE_ID object? >>> >>> I cannot find a definitive statement in the RFC as to whether or not > multiple >>> Target IGP Identification TLVs are permitted in a single object. >> >> Agreed. No such statement found. >> >>> However, I think that this should NOT be permitted. >>> >>> My thinking is as follows. >>> - Section 3.4 states that "It is possible that an LSP will be used to offer >>> capacity and connectivity to multiple other networks. In this case, >>> multiple instances of the LSP_TUNNEL_INTERFACE_ID object are >>> permitted in the same Path and Resv messages." >>> - My reading of this is that if multiple Target IGP Identification TLVs >>> are required then they should each appear in a separate >>> LSP_TUNNEL_INTERFACE_ID object. >>> - However, if multiple Target IGP Identification TLVs are permitted >>> in a single LSP_TUNNEL_INTERFACE_ID object then there are two >>> protocol constructs with the same meaning, which could lead to >>> interoperability problems. >>> - Therefore RFC6107 should state that at most one Target IGP >>> Identification TLV may appear in a single LSP_TUNNEL_INTERFACE_ID >>> object, but I cannot find any such statement. >> >> i wouldn't object to imposing this limitation, but I don't see it as >> particularly necessary: why would there be interop problems if both multiple >> TLVs and multiple objects are allowed? Conservative on what you send, liberal > on >> what you receive. Since the RFC does not (currently) prohibit either option, >> there would be no reason for an implementation to not be able to receive > either. >> >> I don't read "are permitted" to mean "required" >> >> There would seem to be a (minor) saving of bits on the wire in the case that >> multiple uses share the settings of the common part of the object. However, >> since this is pretty unlikely: >> 1. The chance of multiple TLVs being present is small >> 2. The hardship of banning multiple TLVs is small >> >> This could probably (just about) qualify for an erratum. Really it is a >> technical change, not a typographical fix, but we might squeeze it in as a one >> line change. >> >> Cheers, >> Adrian >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From Alan.Davey@metaswitch.com Thu Nov 3 04:13:14 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8611E80AC for ; Thu, 3 Nov 2011 04:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNEbUCPEehKi for ; Thu, 3 Nov 2011 04:13:13 -0700 (PDT) Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2911E8088 for ; Thu, 3 Nov 2011 04:13:13 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by enficsets2.metaswitch.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 3 Nov 2011 11:12:44 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.01.0339.001; Thu, 3 Nov 2011 11:12:51 +0000 From: Alan Davey To: labn - Lou Berger , Aria - Adrian Farrel Personal Thread-Topic: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths Thread-Index: AQHMmVJoo4Fd+uXAVUeuU5/U2TBjP5WbACTA Date: Thu, 3 Nov 2011 11:12:50 +0000 Message-ID: References: <038d01cc9596$5d429760$17c7c620$@olddog.co.uk> <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> <4EB1291F.4000003@labn.net> In-Reply-To: <4EB1291F.4000003@labn.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:104:4001:72:cd01:f8b0:5a18:1e14] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 11:13:14 -0000 Lou Thank you for your response. I agree on item 2. On item 1, I think that the question is; has anyone implemented sending mul= tiple IGP Instance TLVs in the same object. If they have then we cannot raise an erratum. If they have not then we have the chance to tighten the spec and reduce the= chances of interoperability issues. Regards Alan -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: 02 November 2011 11:27 To: Aria - Adrian Farrel Personal Cc: Alan Davey; ccamp@ietf.org Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signal= ed Hierarchical Label Switched Paths Adrian/Alan, I think there are separable issues here that should be addressed independently. Item 2 below is easy, and clear cut. It should result in an errata. Item 1 is more problematic as an errata. I agree with Adrian's analysis: RFC 6107 states that advertisement of "multiple instances of the LSP_TUNNEL_INTERFACE_ID object are permitted", but doesn't say it's required or that multiple TLVs of the same type are not permitted. Based on this, I think it's reasonable to have an errata that highlights that a receiver should be prepared to receive both multiple LSP_TUNNEL_INTERFACE_ID objects and multiple TLVs of the same time within a single object. While it may be reasonable for an errata to suggest reducing the number of options, I think changing behavior on the wire really needs to be run through the normal working group process. Lou On 10/31/2011 9:20 AM, Adrian Farrel wrote: > Looks fine, but I would like to hear agreement from the WG. >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Alan Davey [mailto:Alan.Davey@metaswitch.com] >> Sent: 31 October 2011 11:41 >> To: Adrian Farrel Personal >> Cc: ccamp@ietf.org >> Subject: RE: [CCAMP] Question on RFC6107, Procedures for Dynamically Sig= naled >> Hierarchical Label Switched Paths >> >> Hi Adrian >> >> Thank you for your response, and for spotting another erratum in RFC6107= . I >> propose raising the following technical errata against the RFC, both in > section 3.2. >> Please let me know whether or not you agree. >> >> 1. State that at most one Target IGP Identification TLV may appear in a > single >> LSP_TUNNEL_INTERFACE_ID object. >> >> Original text: >> The TLV has meaning only in a Path message. It SHOULD NOT be >> included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and >> MUST be ignored if found. >> >> Corrected text: >> The TLV has meaning only in a Path message. At most one TLV >> MAY appear in a single LSP_TUNNEL_INTERFACE_ID object. >> >> The TLV SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object >> in a Resv message and MUST be ignored if found. >> >> 2. Section 3.2, change Resv message to Path message. >> >> Original text: >> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >> object in a Resv message is set (i.e., one) indicating that the LSP >> is not to be advertised as a link, this TLV SHOULD NOT be present and >> MUST be ignored if encountered. >> >> Corrected text: >> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >> object in a Path message is set (i.e., one) indicating that the LSP >> is not to be advertised as a link, this TLV SHOULD NOT be present and >> MUST be ignored if encountered. >> >> Regards >> Alan Davey >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf O= f >> Adrian Farrel >> Sent: 28 October 2011 18:24 >> To: Alan Davey; ccamp@ietf.org >> Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Sig= naled >> Hierarchical Label Switched Paths >> >> Hi Alan, >> >> Nice to be made to read stuff because you come across typos. I think tha= t >> Section 3.2 >> >> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >> object in a Resv message is set (i.e., one) indicating that the LSP >> is not to be advertised as a link, this TLV SHOULD NOT be present and >> MUST be ignored if encountered. >> >> s/Resv/Path/ ! >> >> That merits an erratum if anyone can be bothered. >> >>> I have a question on RFC6107; is it permitted to have more than one >>> Target IGP Identification TLV in a single LSP_TUNNEL_INTERFACE_ID objec= t? >>> >>> I cannot find a definitive statement in the RFC as to whether or not > multiple >>> Target IGP Identification TLVs are permitted in a single object. >> >> Agreed. No such statement found. >> >>> However, I think that this should NOT be permitted. >>> >>> My thinking is as follows. >>> - Section 3.4 states that "It is possible that an LSP will be used to o= ffer >>> capacity and connectivity to multiple other networks. In this case, >>> multiple instances of the LSP_TUNNEL_INTERFACE_ID object are >>> permitted in the same Path and Resv messages." >>> - My reading of this is that if multiple Target IGP Identification TLVs >>> are required then they should each appear in a separate >>> LSP_TUNNEL_INTERFACE_ID object. >>> - However, if multiple Target IGP Identification TLVs are permitted >>> in a single LSP_TUNNEL_INTERFACE_ID object then there are two >>> protocol constructs with the same meaning, which could lead to >>> interoperability problems. >>> - Therefore RFC6107 should state that at most one Target IGP >>> Identification TLV may appear in a single LSP_TUNNEL_INTERFACE_ID >>> object, but I cannot find any such statement. >> >> i wouldn't object to imposing this limitation, but I don't see it as >> particularly necessary: why would there be interop problems if both mult= iple >> TLVs and multiple objects are allowed? Conservative on what you send, li= beral > on >> what you receive. Since the RFC does not (currently) prohibit either opt= ion, >> there would be no reason for an implementation to not be able to receive > either. >> >> I don't read "are permitted" to mean "required" >> >> There would seem to be a (minor) saving of bits on the wire in the case = that >> multiple uses share the settings of the common part of the object. Howev= er, >> since this is pretty unlikely: >> 1. The chance of multiple TLVs being present is small >> 2. The hardship of banning multiple TLVs is small >> >> This could probably (just about) qualify for an erratum. Really it is a >> technical change, not a typographical fix, but we might squeeze it in as= a one >> line change. >> >> Cheers, >> Adrian >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 >=20 From lberger@labn.net Thu Nov 3 06:03:22 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF1E11E80AC for ; Thu, 3 Nov 2011 06:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.952 X-Spam-Level: X-Spam-Status: No, score=-99.952 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkAR-9r2DGgj for ; Thu, 3 Nov 2011 06:03:21 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id ABD6D11E808E for ; Thu, 3 Nov 2011 06:03:21 -0700 (PDT) Received: (qmail 25632 invoked by uid 0); 3 Nov 2011 13:03:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 3 Nov 2011 13:03:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=GcTBKImgrVD5rTxdZaz8Ih+9h5j8VZR8I9bh6L9admM=; b=K3rrIQ2pg4VPopxobR8jmZLHD6MBMi8M8CL9vj7rUJQHZsPOS/x/NV/FjOtTLHu9u43cKMz1Xnh755Ve/wcupCcS9MC3rm6CEEWYScJpt22yjEzd83LycInCtkVSdwiq; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RLwwz-0000Rg-2b; Thu, 03 Nov 2011 07:03:21 -0600 Message-ID: <4EB2911D.4030500@labn.net> Date: Thu, 03 Nov 2011 09:03:25 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Alan Davey References: <038d01cc9596$5d429760$17c7c620$@olddog.co.uk> <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> <4EB1291F.4000003@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:03:22 -0000 Alan, Erratum are to report technical errors or editorial changes. I don't think an erratum can be used to change defined (or under-defined) protocol behavior. I think this takes a bis. Certainly, if no one cares about the option you want to eliminate, this will speed the bis process... Lou On 11/3/2011 7:12 AM, Alan Davey wrote: > Lou > > Thank you for your response. I agree on item 2. > > On item 1, I think that the question is; has anyone implemented sending multiple IGP Instance TLVs in the same object. > > If they have then we cannot raise an erratum. > > If they have not then we have the chance to tighten the spec and reduce the chances of interoperability issues. > > Regards > Alan > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 02 November 2011 11:27 > To: Aria - Adrian Farrel Personal > Cc: Alan Davey; ccamp@ietf.org > Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths > > Adrian/Alan, > > I think there are separable issues here that should be addressed > independently. > > Item 2 below is easy, and clear cut. It should result in an errata. > > Item 1 is more problematic as an errata. I agree with Adrian's > analysis: RFC 6107 states that advertisement of "multiple instances of > the LSP_TUNNEL_INTERFACE_ID object are permitted", but doesn't say it's > required or that multiple TLVs of the same type are not permitted. > Based on this, I think it's reasonable to have an errata that highlights > that a receiver should be prepared to receive both multiple > LSP_TUNNEL_INTERFACE_ID objects and multiple TLVs of the same time > within a single object. While it may be reasonable for an errata to > suggest reducing the number of options, I think changing behavior on the > wire really needs to be run through the normal working group process. > > Lou > > On 10/31/2011 9:20 AM, Adrian Farrel wrote: >> Looks fine, but I would like to hear agreement from the WG. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: Alan Davey [mailto:Alan.Davey@metaswitch.com] >>> Sent: 31 October 2011 11:41 >>> To: Adrian Farrel Personal >>> Cc: ccamp@ietf.org >>> Subject: RE: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled >>> Hierarchical Label Switched Paths >>> >>> Hi Adrian >>> >>> Thank you for your response, and for spotting another erratum in RFC6107. I >>> propose raising the following technical errata against the RFC, both in >> section 3.2. >>> Please let me know whether or not you agree. >>> >>> 1. State that at most one Target IGP Identification TLV may appear in a >> single >>> LSP_TUNNEL_INTERFACE_ID object. >>> >>> Original text: >>> The TLV has meaning only in a Path message. It SHOULD NOT be >>> included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and >>> MUST be ignored if found. >>> >>> Corrected text: >>> The TLV has meaning only in a Path message. At most one TLV >>> MAY appear in a single LSP_TUNNEL_INTERFACE_ID object. >>> >>> The TLV SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object >>> in a Resv message and MUST be ignored if found. >>> >>> 2. Section 3.2, change Resv message to Path message. >>> >>> Original text: >>> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >>> object in a Resv message is set (i.e., one) indicating that the LSP >>> is not to be advertised as a link, this TLV SHOULD NOT be present and >>> MUST be ignored if encountered. >>> >>> Corrected text: >>> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >>> object in a Path message is set (i.e., one) indicating that the LSP >>> is not to be advertised as a link, this TLV SHOULD NOT be present and >>> MUST be ignored if encountered. >>> >>> Regards >>> Alan Davey >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >>> Adrian Farrel >>> Sent: 28 October 2011 18:24 >>> To: Alan Davey; ccamp@ietf.org >>> Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled >>> Hierarchical Label Switched Paths >>> >>> Hi Alan, >>> >>> Nice to be made to read stuff because you come across typos. I think that >>> Section 3.2 >>> >>> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >>> object in a Resv message is set (i.e., one) indicating that the LSP >>> is not to be advertised as a link, this TLV SHOULD NOT be present and >>> MUST be ignored if encountered. >>> >>> s/Resv/Path/ ! >>> >>> That merits an erratum if anyone can be bothered. >>> >>>> I have a question on RFC6107; is it permitted to have more than one >>>> Target IGP Identification TLV in a single LSP_TUNNEL_INTERFACE_ID object? >>>> >>>> I cannot find a definitive statement in the RFC as to whether or not >> multiple >>>> Target IGP Identification TLVs are permitted in a single object. >>> >>> Agreed. No such statement found. >>> >>>> However, I think that this should NOT be permitted. >>>> >>>> My thinking is as follows. >>>> - Section 3.4 states that "It is possible that an LSP will be used to offer >>>> capacity and connectivity to multiple other networks. In this case, >>>> multiple instances of the LSP_TUNNEL_INTERFACE_ID object are >>>> permitted in the same Path and Resv messages." >>>> - My reading of this is that if multiple Target IGP Identification TLVs >>>> are required then they should each appear in a separate >>>> LSP_TUNNEL_INTERFACE_ID object. >>>> - However, if multiple Target IGP Identification TLVs are permitted >>>> in a single LSP_TUNNEL_INTERFACE_ID object then there are two >>>> protocol constructs with the same meaning, which could lead to >>>> interoperability problems. >>>> - Therefore RFC6107 should state that at most one Target IGP >>>> Identification TLV may appear in a single LSP_TUNNEL_INTERFACE_ID >>>> object, but I cannot find any such statement. >>> >>> i wouldn't object to imposing this limitation, but I don't see it as >>> particularly necessary: why would there be interop problems if both multiple >>> TLVs and multiple objects are allowed? Conservative on what you send, liberal >> on >>> what you receive. Since the RFC does not (currently) prohibit either option, >>> there would be no reason for an implementation to not be able to receive >> either. >>> >>> I don't read "are permitted" to mean "required" >>> >>> There would seem to be a (minor) saving of bits on the wire in the case that >>> multiple uses share the settings of the common part of the object. However, >>> since this is pretty unlikely: >>> 1. The chance of multiple TLVs being present is small >>> 2. The hardship of banning multiple TLVs is small >>> >>> This could probably (just about) qualify for an erratum. Really it is a >>> technical change, not a typographical fix, but we might squeeze it in as a one >>> line change. >>> >>> Cheers, >>> Adrian >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> > > > > From loa@pi.nu Thu Nov 3 09:25:08 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF91F0C8B; Thu, 3 Nov 2011 09:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADMJQIkKbOwZ; Thu, 3 Nov 2011 09:25:06 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id E47341F0C7C; Thu, 3 Nov 2011 09:25:05 -0700 (PDT) Received: from [10.154.180.254] (unknown [129.192.185.163]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 653BB2A8004; Thu, 3 Nov 2011 17:25:03 +0100 (CET) Message-ID: <4EB2C05C.5070809@pi.nu> Date: Thu, 03 Nov 2011 09:25:00 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org Subject: [CCAMP] mpls wg last call on draft-ietf-mpls-tp-security-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:25:08 -0000 Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-security-framework-02.txt. Please review the document and send comments to the mpls working group mailing list (mpls@ietf.org). This working group last call ends on November 16th. /Loa for the mpls wg co-charis -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From nurit.sprecher@nsn.com Thu Nov 3 09:27:37 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA5F11E813A; Thu, 3 Nov 2011 09:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsD2+UohstAk; Thu, 3 Nov 2011 09:27:37 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B17EB11E8099; Thu, 3 Nov 2011 09:27:36 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA3GRZY9009737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 17:27:35 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA3GRXw3012380; Thu, 3 Nov 2011 17:27:35 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 17:27:04 +0100 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 Date: Thu, 3 Nov 2011 17:26:53 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326404AFC739@DEMUEXC014.nsn-intra.net> In-Reply-To: <4EB2C05C.5070809@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework Thread-Index: AcyaRSyQeeKq0da0RwCJ/zH5JycWeAAADNbQ References: <4EB2C05C.5070809@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , X-OriginalArrivalTime: 03 Nov 2011 16:27:04.0299 (UTC) FILETIME=[6C0B1BB0:01CC9A45] Cc: CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org Subject: Re: [CCAMP] [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 16:27:37 -0000 I think it is a very important document and I support its publication... Best regards, Nurit -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Thursday, November 03, 2011 6:25 PM To: mpls@ietf.org Cc: CCAMP; MPLS-TP ad hoc team; pwe3@ietf.org Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-security-framework Working Group, this is to start a two week working group last call on draft-ietf-mpls-tp-security-framework-02.txt. Please review the document and send comments to the mpls working group mailing list (mpls@ietf.org). This working group last call ends on November 16th. /Loa for the mpls wg co-charis --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregb@grotto-networking.com Thu Nov 3 10:29:26 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2B11E80DA for ; Thu, 3 Nov 2011 10:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-6zpZF208r4 for ; Thu, 3 Nov 2011 10:29:25 -0700 (PDT) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by ietfa.amsl.com (Postfix) with ESMTP id 717F711E8083 for ; Thu, 3 Nov 2011 10:29:25 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id pA3HTLhG028119; Thu, 3 Nov 2011 17:29:23 +0000 Message-ID: <4EB2CF6E.5080308@grotto-networking.com> Date: Thu, 03 Nov 2011 10:29:18 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jonathan Harrison References: <4DDD443D.5070206@grotto-networking.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=zgJRYWJCDPtlHRFV3FRxMPO68I426JnXhrd70MTovIE= c=1 sm=1 a=yAP4_T4JbDAA:10 a=rIlffkoAhzUA:10 a=xOaALFOtT5cA:10 a=8nJEP1OIZ-IA:10 a=B4uWGr+4DaAYpgidvygSiQ==:17 a=VZAVAGJQAAAA:8 a=48vgC7mUAAAA:8 a=8jnMKPJvKWP7dz7rslcA:9 a=jaxHP6CVOqPPZOW3mo4A:7 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=gKoBFSd7Po4A:10 a=lZB815dzVvQA:10 a=B4uWGr+4DaAYpgidvygSiQ==:117 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Update: draft-ietf-ccamp-general-constraint-encode-05 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 17:29:26 -0000 Hi Jonathan, sorry for the delay I've been swamped with other projects. See response below. We could add some clarifying text and possibly and example if desired. Greg On 10/20/2011 12:22 AM, Jonathan Harrison wrote: > Hi Greg, > > I've got a question on draft-ietf-ccamp-general-constraint-encode-05 that I hope you can answer. The description of LABEL_RANGE1 is as follows. > > "In this case the accompanying MaxLabelRange indicates the maximum > range of the labels. The corresponding label set is used to indicate > the overall label range. Specific center label information can be > obtained from dynamic label in use information. It is assumed that > both center label and range tuning can be done without causing faults > to existing signals." > > > From this, it isn't entirely clear to me what labels may or may not be used on a port advertising this type of Port Label Restriction - is it just the set of labels in the label set field? This constraint was motivated a type of tunable wave band add/drop multi-plexer. The device can add/drop wavelengths within fixed range from its tuning center. So we need three pieces of information: (a) the total set of wavelengths that could possibly be reached (the labels in the label set field), (b) the range of wavelengths that the device can process at once (MaxLabelRange), (c) the current wavelengths (available labels sub-TLV) in use (tells us constraints on tuning the devices up or down to incorporate more wavelengths). A pre-print of the journal paper with nice color figures illustrating this device can be found at http://www.grotto-networking.com/sites/default/files/ModelingWSONswitchesV6_0.pdf. > Would it be possible for you to add an example in Appendix A to give an example of how LABEL_RANGE1 might be used (and how the specific center label information would be obtained from the dynamic label in use information)? > > Thanks, > Jon > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein > Sent: 25 May 2011 19:03 > To: ccamp@ietf.org > Subject: [CCAMP] Update: draft-ietf-ccamp-general-constraint-encode-05 > > Hi CCAMPers interested in WSON, the previous draft (version 04) of > "General Network Element Constraint Encoding for GMPLS Controlled > Networks" was expiring so we needed to refresh with a new version. There > are no changes technical or otherwise in the document. > > This document and four other WSON documents are ready for last call but > were deferred pending a write up from Pierre Peloso concerning some type > of alternative information model and encoding. In the CCAMP Prague > meeting minutes (http://www.ietf.org/proceedings/80/minutes/ccamp.htm) > there was a commitment to resolve this issue quickly. It has now been > two months. On April 2 we furnished an analysis of what we though the > scheme proposed by Peloso was and demonstrated that the proposed > increase in complexity might save 10-20 bytes, an insignificant amount. > > Was an alternate information/encoding still being pursued by Peloso or > others? If so when can we see it? Or can we finally move these documents > into last call. > > Best Regards > > Greg > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From jon.harrison@metaswitch.com Fri Nov 4 04:03:03 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422A721F8BEC for ; Fri, 4 Nov 2011 04:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqtdiyiV9MeZ for ; Fri, 4 Nov 2011 04:03:02 -0700 (PDT) Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id A2A8821F8B1A for ; Fri, 4 Nov 2011 04:03:01 -0700 (PDT) Received: from ENFIRHCAS1.datcon.co.uk (172.18.4.12) by enficsets2.metaswitch.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 4 Nov 2011 11:02:49 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.01.0339.001; Fri, 4 Nov 2011 11:02:56 +0000 From: Jonathan Harrison To: Greg Bernstein Thread-Topic: [CCAMP] Update: draft-ietf-ccamp-general-constraint-encode-05 Thread-Index: AcwbBfdqrDsecx58QNaYjRZjujlx3hzZyCpAAvhBWwAAJMwpgA== Date: Fri, 4 Nov 2011 11:02:56 +0000 Message-ID: References: <4DDD443D.5070206@grotto-networking.com> <4EB2CF6E.5080308@grotto-networking.com> In-Reply-To: <4EB2CF6E.5080308@grotto-networking.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Update: draft-ietf-ccamp-general-constraint-encode-05 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 11:03:03 -0000 Hi Greg, Thanks for the response - that makes it much clearer. If you add some clarifying text similar to that below, that'd be great. If= the additional clarifying text includes a reference to your journal paper,= an example in the draft probably isn't necessary. Thanks, Jon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Bernstein Sent: 03 November 2011 17:29 To: Jonathan Harrison Cc: ccamp@ietf.org Subject: Re: [CCAMP] Update: draft-ietf-ccamp-general-constraint-encode-05 Hi Jonathan, sorry for the delay I've been swamped with other projects.=20 See response below. We could add some clarifying text and possibly and=20 example if desired. Greg On 10/20/2011 12:22 AM, Jonathan Harrison wrote: > Hi Greg, > > I've got a question on draft-ietf-ccamp-general-constraint-encode-05 that= I hope you can answer. The description of LABEL_RANGE1 is as follows. > > "In this case the accompanying MaxLabelRange indicates the maximum > range of the labels. The corresponding label set is used to indicate > the overall label range. Specific center label information can be > obtained from dynamic label in use information. It is assumed that > both center label and range tuning can be done without causing faults > to existing signals." > > > From this, it isn't entirely clear to me what labels may or may not be = used on a port advertising this type of Port Label Restriction - is it just= the set of labels in the label set field? This constraint was motivated a type of tunable wave band add/drop=20 multi-plexer. The device can add/drop wavelengths within fixed range=20 from its tuning center. So we need three pieces of information: (a) the=20 total set of wavelengths that could possibly be reached (the labels in=20 the label set field), (b) the range of wavelengths that the device can=20 process at once (MaxLabelRange), (c) the current wavelengths (available=20 labels sub-TLV) in use (tells us constraints on tuning the devices up=20 or down to incorporate more wavelengths). A pre-print of the journal=20 paper with nice color figures illustrating this device can be found at=20 http://www.grotto-networking.com/sites/default/files/ModelingWSONswitchesV6= _0.pdf. > Would it be possible for you to add an example in Appendix A to give an e= xample of how LABEL_RANGE1 might be used (and how the specific center label= information would be obtained from the dynamic label in use information)? > > Thanks, > Jon > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Greg Bernstein > Sent: 25 May 2011 19:03 > To: ccamp@ietf.org > Subject: [CCAMP] Update: draft-ietf-ccamp-general-constraint-encode-05 > > Hi CCAMPers interested in WSON, the previous draft (version 04) of > "General Network Element Constraint Encoding for GMPLS Controlled > Networks" was expiring so we needed to refresh with a new version. There > are no changes technical or otherwise in the document. > > This document and four other WSON documents are ready for last call but > were deferred pending a write up from Pierre Peloso concerning some type > of alternative information model and encoding. In the CCAMP Prague > meeting minutes (http://www.ietf.org/proceedings/80/minutes/ccamp.htm) > there was a commitment to resolve this issue quickly. It has now been > two months. On April 2 we furnished an analysis of what we though the > scheme proposed by Peloso was and demonstrated that the proposed > increase in complexity might save 10-20 bytes, an insignificant amount. > > Was an alternate information/encoding still being pursued by Peloso or > others? If so when can we see it? Or can we finally move these documents > into last call. > > Best Regards > > Greg > --=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From ADhillon@infinera.com Fri Nov 4 10:00:33 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB8D21F8C59 for ; Fri, 4 Nov 2011 10:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5C5FhFjY-yH for ; Fri, 4 Nov 2011 10:00:32 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 55FD121F8C58 for ; Fri, 4 Nov 2011 10:00:31 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.01.0323.003; Fri, 4 Nov 2011 10:00:30 -0700 From: Abinder Dhillon To: Ramon Casellas , "ccamp@ietf.org" Thread-Topic: [CCAMP] Please provide your comments - draft-dhillon-ccamp-super-channel-ospfte-ext Thread-Index: AQHMmxNBV0aG46TUO0aZewIi0kTv+g== Date: Fri, 4 Nov 2011 17:00:06 +0000 Message-ID: <8FCABE5E435B954A8B67947E4F08B12F0AB1D166@SV-EXDB-PROD1.infinera.com> References: <8FCABE5E435B954A8B67947E4F08B12F0AB1B0CE@SV-EXDB-PROD1.infinera.com> <4EA9ACD7.8070705@cttc.es> In-Reply-To: <4EA9ACD7.8070705@cttc.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.128] Content-Type: multipart/alternative; boundary="_000_8FCABE5E435B954A8B67947E4F08B12F0AB1D166SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] Please provide your comments - draft-dhillon-ccamp-super-channel-ospfte-ext X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 17:00:34 -0000 --_000_8FCABE5E435B954A8B67947E4F08B12F0AB1D166SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ramon, Thanks for your comments. For super channel, there is not much meaning of Max LSP BW in bps. All we need to specify is the max number of spectral slices. I am proposin= g to have this information in ISCD specific inform field. So my take will be either we can ignore the max lsp BW for SwitchCap=3DSCS= C. If we want to show the Max LSP BW in bps then we can convert the spectral bandwidth into bps base= d on the modulation. I have provided more details in ver01 of this draft. Please take a look and= let me know if you have any other questions. Regards......Abinder From: Ramon Casellas [mailto:ramon.casellas@cttc.es] Sent: Thursday, October 27, 2011 12:11 PM To: ccamp@ietf.org Subject: Re: [CCAMP] Please provide your comments - draft-dhillon-ccamp-sup= er-channel-ospfte-ext El 27/10/2011 20:42, Abinder Dhillon escribi=F3: Folks, http://datatracker.ietf.org/doc/draft-dhillon-ccamp-super-channel-ospfte-ex= t Regards.....Abinder Hi Abinder, Interesting draft, thank you. One question, if I may: what bandwidth values (Unreserved, Max LSP Bw. per = priority etc.) do you disseminate for the ISCD and other sub-TLVs? Regardless of the actual encoding, we all seem to agree on disseminating av= ailable frequency ranges (or nominal freqs in the flexi-grid). Yet I don't see a trivial mapping between available optical spectrum freque= ncy ranges (e.g. within the C band) and "bytes per second". The only mapping I can think of, if we assume a superchannel as a contiguou= s frequency slot (without gaps), is to identify the greatest available freq= uency range (in GHz) and to assume a worst case modulation with 1 Hz =3D 1 = bit/s Even in this case, the unreserved bandwidth per priority does not seem very= useful, since it does not account for fragmentation, and this also means t= hat the "max lsp bw" is updated at each change, imho. Alternatively, if nominal flexi-grid frequencies are disseminated, aren't a= ll bandwidth-related (sub)TLVs somehow deprecated? Your comments are much welcome :-) Thanks in advance and best regards Ramon --_000_8FCABE5E435B954A8B67947E4F08B12F0AB1D166SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ramon,

 

Thanks for your commen= ts.

 

For super channel, the= re is not much meaning of Max LSP BW in bps.

All we need to specify=  is the max number of spectral slices. I am proposing to have this in= formation in ISCD specific inform  field.

 

So my take will be eit= her we can ignore the max lsp BW  for SwitchCap=3DSCSC.  If we wa= nt to show the

Max LSP BW in bps then= we can convert the  spectral bandwidth into bps based on the modulati= on.

 

I have provided more d= etails in ver01 of this draft. Please take a look and let me  know if = you have any other questions.

 

Regards……A= binder

 

From: Ramon Casellas= [mailto:ramon.casellas@cttc.es]
Sent: Thursday, October 27, 2011 12:11 PM
To: ccamp@ietf.org
Subject: Re: [CCAMP] Please provide your comments - draft-dhillon-cc= amp-super-channel-ospfte-ext

 

El 27/10/2011 20:42, Abinder Dhillon escribi=F3:

Folks,

 

http://datatracker.ietf.org/doc/draft-= dhillon-ccamp-super-channel-ospfte-ext

 

Regards…..Abinder


Hi Abinder,

Interesting draft, thank you.

One question, if I may: what bandwidth values (Unreserved, Max LSP Bw. per = priority etc.) do you disseminate for the ISCD and other sub-TLVs?
Regardless of the actual encoding, we all seem to agree on disseminating av= ailable frequency ranges (or nominal freqs in the flexi-grid).
Yet I don't see a trivial mapping between available optical spectrum freque= ncy ranges (e.g. within the C band) and "bytes per second".

The only mapping I can think of, if we assume a superchannel as a contiguou= s frequency slot (without gaps), is to identify the greatest available freq= uency range (in GHz) and to assume a worst case modulation with 1 Hz =3D 1 = bit/s
Even in this case, the unreserved bandwidth per priority does not seem very= useful, since it does not account for fragmentation, and this also means t= hat the "max lsp bw" is updated at each change, imho.

Alternatively, if nominal flexi-grid frequencies are disseminated, aren't a= ll bandwidth-related (sub)TLVs somehow deprecated?

Your comments are much welcome :-)

Thanks in advance and best regards
Ramon

--_000_8FCABE5E435B954A8B67947E4F08B12F0AB1D166SVEXDBPROD1infi_-- From db3546@att.com Fri Nov 4 11:10:57 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4BA21F851F for ; Fri, 4 Nov 2011 11:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b5ou549r4wk for ; Fri, 4 Nov 2011 11:10:57 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 141C521F85EF for ; Fri, 4 Nov 2011 11:10:52 -0700 (PDT) X-Env-Sender: db3546@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1320430237!28756669!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7328 invoked from network); 4 Nov 2011 18:10:38 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Nov 2011 18:10:38 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA4IB53a010299 for ; Fri, 4 Nov 2011 14:11:05 -0400 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA4IB4p0010276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Nov 2011 14:11:04 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.168]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0339.001; Fri, 4 Nov 2011 14:10:36 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Updated CCAMP Agenda posted Thread-Index: AcybHQx3IlLo25T0SAudkLQV/140Xg== Date: Fri, 4 Nov 2011 18:10:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] Updated CCAMP Agenda posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 18:10:58 -0000 Hi, An updated CCAMP Agenda has been posted: http://www.ietf.org/proceedings/82/agenda/ccamp.htm Deborah and Lou From Alan.Davey@metaswitch.com Mon Nov 7 06:07:25 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C68A21F8AAF for ; Mon, 7 Nov 2011 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjUe+YDz73My for ; Mon, 7 Nov 2011 06:07:21 -0800 (PST) Received: from ENFICSETS3.metaswitch.com (enficsets3.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id A34AE21F8A62 for ; Mon, 7 Nov 2011 06:07:20 -0800 (PST) Received: from ENFIRHCAS1.datcon.co.uk (172.18.4.12) by ENFICSETS3.metaswitch.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 7 Nov 2011 14:07:10 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHCAS1.datcon.co.uk ([fe80::85a7:aa4e:2516:c2ad%11]) with mapi id 14.01.0339.001; Mon, 7 Nov 2011 14:07:19 +0000 From: Alan Davey To: labn - Lou Berger Thread-Topic: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths Thread-Index: AQHMmVJoo4Fd+uXAVUeuU5/U2TBjP5WbACTAgAAfKICABi22EA== Date: Mon, 7 Nov 2011 14:07:18 +0000 Message-ID: References: <038d01cc9596$5d429760$17c7c620$@olddog.co.uk> <068801cc97cf$cfcd1450$6f673cf0$@olddog.co.uk> <4EB1291F.4000003@labn.net> <4EB2911D.4030500@labn.net> In-Reply-To: <4EB2911D.4030500@labn.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:104:4001:72:9874:bf7:f600:bc8f] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signaled Hierarchical Label Switched Paths X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 14:07:25 -0000 Lou Thank you for clarifying the process. I think that it would be overkill to create a bis of RFC6170 to clarify wha= t is a fairly arcane corner of the protocol and therefore I will not pursue= this. However, I will raise an erratum for the issue spotted by Adrian. Regards Alan -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: 03 November 2011 13:03 To: Alan Davey Cc: Aria - Adrian Farrel Personal; ccamp@ietf.org Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Signal= ed Hierarchical Label Switched Paths Alan, Erratum are to report technical errors or editorial changes. I don't think an erratum can be used to change defined (or under-defined) protocol behavior. I think this takes a bis. Certainly, if no one cares about the option you want to eliminate, this will speed the bis process... Lou On 11/3/2011 7:12 AM, Alan Davey wrote: > Lou >=20 > Thank you for your response. I agree on item 2. >=20 > On item 1, I think that the question is; has anyone implemented sending m= ultiple IGP Instance TLVs in the same object. >=20 > If they have then we cannot raise an erratum. >=20 > If they have not then we have the chance to tighten the spec and reduce t= he chances of interoperability issues. >=20 > Regards > Alan >=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net]=20 > Sent: 02 November 2011 11:27 > To: Aria - Adrian Farrel Personal > Cc: Alan Davey; ccamp@ietf.org > Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Sign= aled Hierarchical Label Switched Paths >=20 > Adrian/Alan, >=20 > I think there are separable issues here that should be addressed > independently. >=20 > Item 2 below is easy, and clear cut. It should result in an errata. >=20 > Item 1 is more problematic as an errata. I agree with Adrian's > analysis: RFC 6107 states that advertisement of "multiple instances of > the LSP_TUNNEL_INTERFACE_ID object are permitted", but doesn't say it's > required or that multiple TLVs of the same type are not permitted. > Based on this, I think it's reasonable to have an errata that highlights > that a receiver should be prepared to receive both multiple > LSP_TUNNEL_INTERFACE_ID objects and multiple TLVs of the same time > within a single object. While it may be reasonable for an errata to > suggest reducing the number of options, I think changing behavior on the > wire really needs to be run through the normal working group process. >=20 > Lou >=20 > On 10/31/2011 9:20 AM, Adrian Farrel wrote: >> Looks fine, but I would like to hear agreement from the WG. >> >> Thanks, >> Adrian >> >>> -----Original Message----- >>> From: Alan Davey [mailto:Alan.Davey@metaswitch.com] >>> Sent: 31 October 2011 11:41 >>> To: Adrian Farrel Personal >>> Cc: ccamp@ietf.org >>> Subject: RE: [CCAMP] Question on RFC6107, Procedures for Dynamically Si= gnaled >>> Hierarchical Label Switched Paths >>> >>> Hi Adrian >>> >>> Thank you for your response, and for spotting another erratum in RFC610= 7. I >>> propose raising the following technical errata against the RFC, both in >> section 3.2. >>> Please let me know whether or not you agree. >>> >>> 1. State that at most one Target IGP Identification TLV may appear in = a >> single >>> LSP_TUNNEL_INTERFACE_ID object. >>> >>> Original text: >>> The TLV has meaning only in a Path message. It SHOULD NOT be >>> included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and >>> MUST be ignored if found. >>> >>> Corrected text: >>> The TLV has meaning only in a Path message. At most one TLV >>> MAY appear in a single LSP_TUNNEL_INTERFACE_ID object. >>> >>> The TLV SHOULD NOT be included in the LSP_TUNNEL_INTERFACE_ID object >>> in a Resv message and MUST be ignored if found. >>> >>> 2. Section 3.2, change Resv message to Path message. >>> >>> Original text: >>> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >>> object in a Resv message is set (i.e., one) indicating that the LSP >>> is not to be advertised as a link, this TLV SHOULD NOT be present an= d >>> MUST be ignored if encountered. >>> >>> Corrected text: >>> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >>> object in a Path message is set (i.e., one) indicating that the LSP >>> is not to be advertised as a link, this TLV SHOULD NOT be present an= d >>> MUST be ignored if encountered. >>> >>> Regards >>> Alan Davey >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of >>> Adrian Farrel >>> Sent: 28 October 2011 18:24 >>> To: Alan Davey; ccamp@ietf.org >>> Subject: Re: [CCAMP] Question on RFC6107, Procedures for Dynamically Si= gnaled >>> Hierarchical Label Switched Paths >>> >>> Hi Alan, >>> >>> Nice to be made to read stuff because you come across typos. I think th= at >>> Section 3.2 >>> >>> If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID >>> object in a Resv message is set (i.e., one) indicating that the LSP >>> is not to be advertised as a link, this TLV SHOULD NOT be present an= d >>> MUST be ignored if encountered. >>> >>> s/Resv/Path/ ! >>> >>> That merits an erratum if anyone can be bothered. >>> >>>> I have a question on RFC6107; is it permitted to have more than one >>>> Target IGP Identification TLV in a single LSP_TUNNEL_INTERFACE_ID obje= ct? >>>> >>>> I cannot find a definitive statement in the RFC as to whether or not >> multiple >>>> Target IGP Identification TLVs are permitted in a single object. >>> >>> Agreed. No such statement found. >>> >>>> However, I think that this should NOT be permitted. >>>> >>>> My thinking is as follows. >>>> - Section 3.4 states that "It is possible that an LSP will be used to = offer >>>> capacity and connectivity to multiple other networks. In this case, >>>> multiple instances of the LSP_TUNNEL_INTERFACE_ID object are >>>> permitted in the same Path and Resv messages." >>>> - My reading of this is that if multiple Target IGP Identification TLV= s >>>> are required then they should each appear in a separate >>>> LSP_TUNNEL_INTERFACE_ID object. >>>> - However, if multiple Target IGP Identification TLVs are permitted >>>> in a single LSP_TUNNEL_INTERFACE_ID object then there are two >>>> protocol constructs with the same meaning, which could lead to >>>> interoperability problems. >>>> - Therefore RFC6107 should state that at most one Target IGP >>>> Identification TLV may appear in a single LSP_TUNNEL_INTERFACE_ID >>>> object, but I cannot find any such statement. >>> >>> i wouldn't object to imposing this limitation, but I don't see it as >>> particularly necessary: why would there be interop problems if both mul= tiple >>> TLVs and multiple objects are allowed? Conservative on what you send, l= iberal >> on >>> what you receive. Since the RFC does not (currently) prohibit either op= tion, >>> there would be no reason for an implementation to not be able to receiv= e >> either. >>> >>> I don't read "are permitted" to mean "required" >>> >>> There would seem to be a (minor) saving of bits on the wire in the case= that >>> multiple uses share the settings of the common part of the object. Howe= ver, >>> since this is pretty unlikely: >>> 1. The chance of multiple TLVs being present is small >>> 2. The hardship of banning multiple TLVs is small >>> >>> This could probably (just about) qualify for an erratum. Really it is a >>> technical change, not a typographical fix, but we might squeeze it in a= s a one >>> line change. >>> >>> Cheers, >>> Adrian >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >=20 >=20 >=20 >=20 From lberger@labn.net Mon Nov 7 07:46:16 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CD621F8C30 for ; Mon, 7 Nov 2011 07:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.979 X-Spam-Level: X-Spam-Status: No, score=-99.979 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSopvVE7trFN for ; Mon, 7 Nov 2011 07:46:11 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id A7D7D21F8C2D for ; Mon, 7 Nov 2011 07:46:11 -0800 (PST) Received: (qmail 8040 invoked by uid 0); 7 Nov 2011 15:46:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 7 Nov 2011 15:46:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=sMHgE4yM8c6kJGsM6+5aCdSveemYTsHjGxcB7HGQbA0=; b=gB71Vv3UIywp8NESFTZ0tT+HHtuSPOFXF+q05dp9iHzFwVPHMmVOl9+akGP3Q285HWXLtUYWTvGVrg2AZhQsYfGn3KoaBjtbXq1zAhpM2eUzLlk9azFBATxTf90e0vOT; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RNROj-0006N1-Qu; Mon, 07 Nov 2011 08:46:09 -0700 Message-ID: <4EB7FD42.3020900@labn.net> Date: Mon, 07 Nov 2011 10:46:10 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Slides for next week X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:46:16 -0000 Presenters, Please send Dan and the chairs your slides by the end of the day Sunday Nov 13. This will ensure we have all slides uploaded in time for the first session on Tuesday. Also some reminders: - See http://tools.ietf.org/wg/ccamp/agenda for the latest agenda and allotted presentation time. - Allotted time includes setup/presentation *and* discussion. - Please allow sufficient time for discussion on any issues and questions you have for the WG. Keep in mind that WG discussion and feedback are the main reasons for presenting. - To maximize presentation time, the secretary/chairs will post all slides prior to the session and present from a single laptop. Any file or laptop swapping will come out of the presenters allotted time and is not considered to be good use of the WG's time. Much thanks! Lou (Deborah and Dan) From lberger@labn.net Thu Nov 10 05:19:50 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA221F8B4E for ; Thu, 10 Nov 2011 05:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.985 X-Spam-Level: X-Spam-Status: No, score=-99.985 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ivurWc4OB+g for ; Thu, 10 Nov 2011 05:19:49 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 093DD21F8B4D for ; Thu, 10 Nov 2011 05:19:48 -0800 (PST) Received: (qmail 4708 invoked by uid 0); 10 Nov 2011 13:19:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 10 Nov 2011 13:19:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=lopim9afNkr9BbMcUcVGnejjnicPKs2sdiTFwf9RMeY=; b=M6I7j2L4HPinBxslidYDQjEvCIAth/31iKCNC/vfvBMdUMviPzSF4wZcLZghq9ot/DmtjWFnWWaPID446uJRURACkhHuUJv6kgmAzX8pRmY61HDJPsAjkQVbT5fIcxFt; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1ROUXk-0004Y8-GX for ccamp@ietf.org; Thu, 10 Nov 2011 06:19:48 -0700 Message-ID: <4EBBCF73.7020603@labn.net> Date: Thu, 10 Nov 2011 08:19:47 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Fwd: Etherpad for collaborative note-taking X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 13:19:50 -0000 FYI - there's a new tool available at http://tools.ietf.org/wg/ccamp/minutes In the spirit of cloud sourcing, please feel free to add your comments/notes during the session. I've gotten things started by adding in the agenda. Lou -------- Original Message -------- Subject: Etherpad for collaborative note-taking Date: Wed, 09 Nov 2011 11:43:24 +0100 From: Henrik Levkowetz To: WG Chairs Hi, Acting on a recent suggestion from Peter Saint-Andre (on ietf@ietf.org), I've now set up an instance of Etherpad Lite (http://etherpad.org/) on one of the tools servers, and used it to make a collaborative notes document available for all WGs with a posted agenda for IETF-82. You'll find it both linked in and embedded in the minutes page for your WG on tools.ietf.org; for an example see http://tools.ietf.org/wg/clue/minutes The note documents will be visible on the minutes page until you submit official minutes for the meeting, at which time they will be replaced by the minutes. The etherpad documents will still be accessible directly at the etherpad URL for some time after the meeting, but will be archived and replaced by new empty documents before the next meeting. Comments and suggestions are welcome! Best regards, Henrik From wwwrun@rfc-editor.org Thu Nov 10 09:06:01 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869B221F8B7F for ; Thu, 10 Nov 2011 09:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.22 X-Spam-Level: X-Spam-Status: No, score=-102.22 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX9Hu1Ava9mK for ; Thu, 10 Nov 2011 09:06:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D08CC21F8B73 for ; Thu, 10 Nov 2011 09:06:00 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6064162180; Thu, 10 Nov 2011 09:00:58 -0800 (PST) To: shiomoto.kohei@lab.ntt.co.jp, adrian@olddog.co.uk, stbryant@cisco.com, adrian@olddog.co.uk, lberger@labn.net, dbrungard@att.com From: RFC Errata System Message-Id: <20111110170100.6064162180@rfc-editor.org> Date: Thu, 10 Nov 2011 09:00:58 -0800 (PST) Cc: ccamp@ietf.org, Alan.Davey@metaswitch.com, rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC6107 (3018) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 17:06:01 -0000 The following errata report has been submitted for RFC6107, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6107&eid=3018 -------------------------------------- Type: Technical Reported by: Alan Davey Section: 3.2 Original Text ------------- If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID object in a Resv message is set (i.e., one) indicating that the LSP is not to be advertised as a link, this TLV SHOULD NOT be present and MUST be ignored if encountered. Corrected Text -------------- If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID object in a Path message is set (i.e., one) indicating that the LSP is not to be advertised as a link, this TLV SHOULD NOT be present and MUST be ignored if encountered. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6107 (draft-ietf-ccamp-lsp-hierarchy-bis-08) -------------------------------------- Title : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Publication Date : February 2011 Author(s) : K. Shiomoto, Ed., A. Farrel, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From cathryn@infc.ulst.ac.uk Fri Nov 11 01:13:05 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABBB21F899D for ; Fri, 11 Nov 2011 01:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqXlsj9UEm4U for ; Fri, 11 Nov 2011 01:13:05 -0800 (PST) Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4936921F891D for ; Fri, 11 Nov 2011 01:13:01 -0800 (PST) Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id pAB9D1YJ029187 for ; Fri, 11 Nov 2011 09:13:01 GMT Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by m0.ulster.ac.uk (UU/BC) with ESMTP id pAB9D1pw006861 for ; Fri, 11 Nov 2011 09:13:01 GMT (envelope-from cathryn@infc.ulst.ac.uk) Received: from localhost (localhost.localdomain [127.0.0.1]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 17B0F3D06E1 for ; Fri, 11 Nov 2011 09:13:01 +0000 (GMT) X-Virus-Scanned: amavisd-new at martello.infc.ulst.ac.uk Received: from martello.infc.ulst.ac.uk ([127.0.0.1]) by localhost (martello.infc.ulst.ac.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soor0D1nZgX3 for ; Fri, 11 Nov 2011 09:12:56 +0000 (GMT) Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 0B29B3D05BD for ; Fri, 11 Nov 2011 09:12:56 +0000 (GMT) Date: Fri, 11 Nov 2011 09:12:55 +0000 (GMT) From: "Peoples, Cathryn" To: CCAMP@ietf.org Message-ID: <546927133.601321002775992.JavaMail.root@martello.infc.ulst.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [193.61.166.86] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL5_64) Subject: [CCAMP] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Maui, Hawaii, USA X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 09:13:05 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From db3546@att.com Fri Nov 11 19:44:31 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2D51F0C3D; Fri, 11 Nov 2011 19:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjJA6KzaATtS; Fri, 11 Nov 2011 19:44:30 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9791F0C38; Fri, 11 Nov 2011 19:44:29 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1321069468!738248!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11954 invoked from network); 12 Nov 2011 03:44:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-14.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 12 Nov 2011 03:44:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAC3itGp007943; Fri, 11 Nov 2011 22:44:55 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAC3is3B007940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Nov 2011 22:44:54 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.112]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0339.001; Fri, 11 Nov 2011 22:44:26 -0500 From: "BRUNGARD, DEBORAH A" To: "adrian@olddog.co.uk" Thread-Topic: Please publish draft-ietf-ccamp-rfc5787bis-03 Thread-Index: Acyg7VtsZzyB2Hw9TbGyim0gi+gwHg== Date: Sat, 12 Nov 2011 03:44:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ep9T GeaY IeI5 Jm3i LLQI LtTl Np72 ORs9 PU/2 Rb+i S4sO W2a+ XvV3 abv7 ePqs gE07; 3; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcABAAGkAZQB0AGYALgBvAHIAZwA7AGkAZQBzAGcALQBzAGUAYwByAGUAdABhAHIAeQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {8641E7D9-A15D-4C8B-BFBA-AC73E673D677}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Sat, 12 Nov 2011 03:44:18 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAHIAZgBjADUANwA4ADcAYgBpAHMALQAwADMA x-cr-puzzleid: {8641E7D9-A15D-4C8B-BFBA-AC73E673D677} x-originating-ip: [135.70.37.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "iesg-secretary@ietf.org" Subject: [CCAMP] Please publish draft-ietf-ccamp-rfc5787bis-03 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 03:44:31 -0000 PROTO-write-up for: draft-ietf-ccamp-rfc5787bis-03.txt Intended status: Proposed Standard (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Deborah Brungard is the Document Shepherd. She has reviewed the document and believes it is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has been adequately reviewed. In addition, it was Liaisoned with ITU-T. It was previously published with Experimental Status, some minor updates have been incorporated. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns or issues. No IPR found in the datatracker. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is very good consensus behind this document. It was moved to Standards track based on significant interest expressed by the working grou= p. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate Checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Split looks okay. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA section looks good. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, no automated checks needed. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document received much attention and discussion in its early revisions. The document has been stable for quite some time, mainly needing revisions as part of the publication process for Standards Track. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There have been no public statements related to implementations, though significant interest was expressed when the working group was polled for interest in moving to standards track. From adrian@olddog.co.uk Sat Nov 12 14:29:14 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98D121F89B8 for ; Sat, 12 Nov 2011 14:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6MSrYR2s-2w for ; Sat, 12 Nov 2011 14:29:14 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2138C21F893C for ; Sat, 12 Nov 2011 14:29:13 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id pACMTC73004313 for ; Sat, 12 Nov 2011 22:29:12 GMT Received: from 950129200 (203-69-99-16.HINET-IP.hinet.net [203.69.99.16] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id pACMT9wa004290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 12 Nov 2011 22:29:11 GMT From: "Adrian Farrel" To: Date: Sat, 12 Nov 2011 22:29:07 -0000 Message-ID: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AcyhinYiQsOh76uLSlunbu9Vrv2EFA== Subject: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 22:29:15 -0000 Hi, I wanted to see whether we can prime the discussions of flexi-grid labels in advance of the WG meetings this week. It looks like we have successfully agreed that there are two significant differences between the label formats defined in http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext The first point seems relatively minor: Should we use a new value for the Grid field or should we continue to use the value that indicates DWDM. In favor of continuing to use the DWDM value is the fact that the ITU-T has not defined a new grid for flexible wavelength assignments. In fact, the ITU-T says that flexible assignments should be made from the DWDM grid. On the other hand we need to understand that the fields in GMPLS objects exist to make implementation easier and to convey information. There is no need for a direct mapping to ITU-T grids. Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is correct that the flexible grid wavelengths will be suggested from the ITU-T DWDM grid, but it is not being as helpful as it could be. When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not implying that there is a new and different grid defined by the ITU-T. What it is saying is that the label is a flexi-grid label selected from the grid defined by the ITU-T for that purpose (i.e., the DWDM grid). Personally, i don't see this as a very large issue. draft-farrkingel would work just as well if we decide to use Grid==1. however, I think it is marginally more helpful and useful to be able to recognise the different label use cases (fixed grid / flexible grid) by looking at a field early in the Label object. Conversely, I don't believe that draft-zhang would be broken by using Grid==3. So my compromise proposal is that both I-Ds use Grid==3. Then we can concentrate on the more significant second issue (see separate email). What do folk think? Cheers, Adrian From adrian@olddog.co.uk Sat Nov 12 17:34:36 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1776F21F8AC3 for ; Sat, 12 Nov 2011 17:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEhXkfOAp37q for ; Sat, 12 Nov 2011 17:34:35 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id F0CCE21F8ABE for ; Sat, 12 Nov 2011 17:34:34 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAD1YT6U021510 for ; Sun, 13 Nov 2011 01:34:33 GMT Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAD1YNIR021486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 13 Nov 2011 01:34:27 GMT From: "Adrian Farrel" To: Date: Sun, 13 Nov 2011 01:34:21 -0000 Message-ID: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AcyhpCfI7o9JPdPYRsiidOB4aUW3+g== Subject: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:34:36 -0000 Hi, Second email on the differences between the label formats defined in http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext This issue is more complicated than the first issue. This question has two sub-points: a. where do we carry the flexi-grid m parameter? b. where do we carry traffic parameters for flexi-grid? draft-zhang is a more comprehensive document that draft-farrkingel because it aims to cover a number of significant signaling parameters for RSVP-TE. draft-farrkingel only attempts to define a label structure. Thus, the question we need to resolve is not where to carry the traffic parameters for flexi-grid, but what constitutes a label in flexi-grid? Maybe we should start this with the question: what is a label? RFC 3471 says: A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. So, what information do we need to carry in a label to satisfy that? I think it is a full description of the channel, and AFAICS for flexi-grid this includes the m parameter. Thanks, Adrian From Dirk.Schroetter@ecitele.com Sat Nov 12 19:01:55 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A771C21F84DC for ; Sat, 12 Nov 2011 19:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.703 X-Spam-Level: X-Spam-Status: No, score=-3.703 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DdBt6cxehXQ for ; Sat, 12 Nov 2011 19:01:55 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id BA97521F84B7 for ; Sat, 12 Nov 2011 19:01:54 -0800 (PST) X-Env-Sender: Dirk.Schroetter@ecitele.com X-Msg-Ref: server-8.tower-182.messagelabs.com!1321153310!2890449!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 4197 invoked from network); 13 Nov 2011 03:01:51 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-8.tower-182.messagelabs.com with SMTP; 13 Nov 2011 03:01:51 -0000 X-AuditID: 93eaf2e7-b7f496d000000e76-b8-4ebf41158ba0 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 18.F1.03702.5114FBE4; Sun, 13 Nov 2011 06:01:25 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sun, 13 Nov 2011 05:01:50 +0200 From: Dirk Schroetter To: "adrian@olddog.co.uk" Date: Sun, 13 Nov 2011 05:01:48 +0200 Thread-Topic: [CCAMP] Trying to resolve flexi-grid issue 1 Thread-Index: AcyhsJX7ABhZxH8UTSqrDz6IvSmVXQ== Message-ID: References: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> In-Reply-To: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0gUURjt7uyuozk1rm57FYlpyqBMm82KNdelkKCXJhQhYdS4e90d251d ZkbRQpKoRLPwUUaLUisS24PsQRSYSvaj8oc9rLQS++GLzIos0ZKyGYfM/p37nXO+892Z7+KY oVsfg3O8hASeddP6MG3NyNj3BOOmtgymMxhvmazowSwDdT3ajZotjY0/NFuCty+DTM3eEmBl ed4rsRKiHEi0p9KZAlfA2otoinOk0maa8rlZO/IgXkqlWZ8P8Q7aFmaVixxPId7udXC8M5Xe umtngsWyLjnBTNuWLzUnpYTtdnEihRI8LOemPEgUWSei5IoyIe9ADirXK1CSC1HCgRrMVVl9 R+drjSr0X6kCJeAuWQ5CcUiuhfVP60NUvAg+62vSl4Mw3EC2ANh8fABTD2cALH37VWZwXE8m wQ+BTYohilwNT3bWzpgxMg6e6O7QKVgr49GuKaDgSDIZTtwoBap+A2wYHg9RcSIse/52pk6Q Nviy7qhGwQZZc2ysHyhRoWQKvD61UCkDebaJjmsaNcoEbw1N6NSZSdh4/ymmYiP80P9bp+qN sLe0Caj6VfBi85hexfHwUuAjpsZGwCfnB7SqNxo+CPZoK4HJPyfCP8fun2P3z7FfBNorwMi5 fVKOx8mYE5Gdk5AbJdq9nltAXZHhe+DnhWXtgMQBHU5kMW0ZBh1bIBZ52kE0rqGNRL5SWpDj dRS5WNG1X8h3I7EdQByjo4irttYMA+Fgiw4hwfuXssgfuQqLmW/3Kr9a2p/EMP8daBMxaB9N N5BOeecOIuRDwl9rLI7TkMhaIydGCMiJCnM5t/SP1uChSnK4nGxUNIToYz0i51T5DrAkxkRQ CkEqhCufn/Uq7+HI9PT0CDDJ94wk9iiqcHkXZ90jcmON3FhLtSiN5fcwS8WUgJvpia/iQ7fn vas99/X147Tus8znoemGikHr1R09m9Osbz5NtrDd4jzrt0D1+fd3LVOndBVdk7/GXthqxILv i5c3bo8LMlkVrzNanLsb9tWTj/KKz7h6s9MPZzPFO8sstdv2WR9+wUcDkH78xHr5SFZHuH/Y HLF+/NsS6/O+FbGnI2mt6GLNKzFBZP8AU/BGbuoDAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 03:01:55 -0000 Adrian, I would concur with your analysis and support your proposal. Cheers, /Dirk Sent from a mobile device. Please excuse any spelling errors. Am 13.11.2011 um 06:36 schrieb "Adrian Farrel" : > Hi, > > I wanted to see whether we can prime the discussions of flexi-grid labels= in > advance of the WG meetings this week. > > It looks like we have successfully agreed that there are two significant > differences between the label formats defined in > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-la= bel > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-t= e-ext > > The first point seems relatively minor: > > Should we use a new value for the Grid field or should we continue to use= the > value that indicates DWDM. > > In favor of continuing to use the DWDM value is the fact that the ITU-T ha= s not > defined a new grid for flexible wavelength assignments. In fact, the ITU-T= says > that flexible assignments should be made from the DWDM grid. > > On the other hand we need to understand that the fields in GMPLS objects e= xist > to make implementation easier and to convey information. There is no need= for a > direct mapping to ITU-T grids. > > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it is corre= ct that > the flexible grid wavelengths will be suggested from the ITU-T DWDM grid,= but it > is not being as helpful as it could be. > > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it is not im= plying > that there is a new and different grid defined by the ITU-T. What it is sa= ying > is that the label is a flexi-grid label selected from the grid defined by= the > ITU-T for that purpose (i.e., the DWDM grid). > > Personally, i don't see this as a very large issue. draft-farrkingel would= work > just as well if we decide to use Grid=3D=3D1. however, I think it is margi= nally more > helpful and useful to be able to recognise the different label use cases (= fixed > grid / flexible grid) by looking at a field early in the Label object. > Conversely, I don't believe that draft-zhang would be broken by using Grid= =3D=3D3. > > So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then we can c= oncentrate > on the more significant second issue (see separate email). > > What do folk think? > > Cheers, > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From daniele.ceccarelli@ericsson.com Sat Nov 12 23:25:00 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B5E21F8AF2 for ; Sat, 12 Nov 2011 23:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umq2bMr0xRM6 for ; Sat, 12 Nov 2011 23:25:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8121F8AF0 for ; Sat, 12 Nov 2011 23:24:59 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-32-4ebf70ca35c0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.25.09514.AC07FBE4; Sun, 13 Nov 2011 08:24:58 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 13 Nov 2011 08:24:58 +0100 From: Daniele Ceccarelli To: Dirk Schroetter , "adrian@olddog.co.uk" Date: Sun, 13 Nov 2011 08:24:56 +0100 Thread-Topic: [CCAMP] Trying to resolve flexi-grid issue 1 Thread-Index: AcyhsJX7ABhZxH8UTSqrDz6IvSmVXQAI8HDQ Message-ID: References: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:25:01 -0000 Hi Adrian, I think your proposal is reasonable. I don't see any particular issue in se= tting the Grid value to 1 or 3. Nevertheless the choice of value 3 is "more= efficient" under the assumption that all the information (fixed grid or fl= exible grid) is included into the label...and this leads to issue 2. Thanks and BR Daniele PS. @ Dirk: Congratulations for your automatic signature, the most clever i= 've ever seen :) -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= irk Schroetter Sent: domenica 13 novembre 2011 4.02 To: adrian@olddog.co.uk Cc: ccamp@ietf.org Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 Adrian, I would concur with your analysis and support your proposal. Cheers, /Dirk Sent from a mobile device. Please excuse any spelling errors. Am 13.11.2011 um 06:36 schrieb "Adrian Farrel" : > Hi, >=20 > I wanted to see whether we can prime the discussions of flexi-grid=20 > labels in advance of the WG meetings this week. >=20 > It looks like we have successfully agreed that there are two=20 > significant differences between the label formats defined in=20 > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambd > a-label and=20 > http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-t > e-ext >=20 > The first point seems relatively minor: >=20 > Should we use a new value for the Grid field or should we continue to=20 > use the value that indicates DWDM. >=20 > In favor of continuing to use the DWDM value is the fact that the=20 > ITU-T has not defined a new grid for flexible wavelength assignments.=20 > In fact, the ITU-T says that flexible assignments should be made from the= DWDM grid. >=20 > On the other hand we need to understand that the fields in GMPLS=20 > objects exist to make implementation easier and to convey information.=20 > There is no need for a direct mapping to ITU-T grids. >=20 > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it is=20 > correct that the flexible grid wavelengths will be suggested from the=20 > ITU-T DWDM grid, but it is not being as helpful as it could be. >=20 > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it is not=20 > implying that there is a new and different grid defined by the ITU-T.=20 > What it is saying is that the label is a flexi-grid label selected=20 > from the grid defined by the ITU-T for that purpose (i.e., the DWDM grid)= . >=20 > Personally, i don't see this as a very large issue. draft-farrkingel=20 > would work just as well if we decide to use Grid=3D=3D1. however, I think= =20 > it is marginally more helpful and useful to be able to recognise the=20 > different label use cases (fixed grid / flexible grid) by looking at a fi= eld early in the Label object. > Conversely, I don't believe that draft-zhang would be broken by using Gri= d=3D=3D3. >=20 > So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then we can= =20 > concentrate on the more significant second issue (see separate email). >=20 > What do folk think? >=20 > Cheers, > Adrian >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From daniele.ceccarelli@ericsson.com Sat Nov 12 23:38:13 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06E111E809A for ; Sat, 12 Nov 2011 23:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8GjH-f5tff6 for ; Sat, 12 Nov 2011 23:38:11 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2487311E8093 for ; Sat, 12 Nov 2011 23:38:10 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-64-4ebf73e2a708 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 44.C5.09514.2E37FBE4; Sun, 13 Nov 2011 08:38:10 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Sun, 13 Nov 2011 08:38:10 +0100 From: Daniele Ceccarelli To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Date: Sun, 13 Nov 2011 08:38:08 +0100 Thread-Topic: [CCAMP] Flexi-grid issue 2 Thread-Index: AcyhpCfI7o9JPdPYRsiidOB4aUW3+gAMTM1Q Message-ID: References: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> In-Reply-To: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:38:13 -0000 Hi Adrian, Hottest issue. The choice of putting the m parameter into the label seems t= o better fit with label definition, but on the other side, thinking of traf= fic parameters, they indicate the amount of resources requested, and the m = parameter indeed indicates right that. Both solutions seem to be acceptable. Further considerations might be neede= d. Thanks and BR=20 Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: domenica 13 novembre 2011 2.34 To: ccamp@ietf.org Subject: [CCAMP] Flexi-grid issue 2 Hi, Second email on the differences between the label formats defined in http:/= /datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te= -ext This issue is more complicated than the first issue. This question has two sub-points: a. where do we carry the flexi-grid m parameter? b. where do we carry traffic parameters for flexi-grid? draft-zhang is a more comprehensive document that draft-farrkingel because = it aims to cover a number of significant signaling parameters for RSVP-TE. draft-farrkingel only attempts to define a label structure. Thus, the question we need to resolve is not where to carry the traffic par= ameters for flexi-grid, but what constitutes a label in flexi-grid? Maybe we should start this with the question: what is a label? RFC 3471 say= s: =20 A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. So, what information do we need to carry in a label to satisfy that? I thin= k it is a full description of the channel, and AFAICS for flexi-grid this i= ncludes the m parameter. Thanks, Adrian _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From ramon.casellas@cttc.es Sun Nov 13 02:51:43 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2916321F841A for ; Sun, 13 Nov 2011 02:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMtANq0PpmPF for ; Sun, 13 Nov 2011 02:51:42 -0800 (PST) Received: from Scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by ietfa.amsl.com (Postfix) with ESMTP id 471F621F8B75 for ; Sun, 13 Nov 2011 02:51:41 -0800 (PST) Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by Scorpius.cttc.es (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pADApSR1029419; Sun, 13 Nov 2011 11:51:34 +0100 Received: from intranet.cttc.es (iptechwiki.cttc.es [84.88.62.225]) by castor (Postfix) with ESMTP id 9826E2FC1C4; Sun, 13 Nov 2011 11:51:28 +0100 (CET) Date: Sun, 13 Nov 2011 11:51:28 +0100 To: adrian@olddog.co.uk, ccamp@ietf.org From: Ramon Casellas Message-ID: X-Priority: 3 X-Mailer: PHPMailer 5.1 (phpmailer.sourceforge.net) X-Mailer: FeLaMiMail In-Reply-To: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> Organization: Centre Tecnologic de Telecomunicacions de Catalunya MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Sun, 13 Nov 2011 11:51:28 +0100 (CET) X-Scanned-By: MIMEDefang 2.67 on 84.88.62.197 Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 10:51:43 -0000 On 11/13/2011 02:34 AM, Adrian Farrel wrote: > 1st issue: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > should we use a new value for the Grid field or should we continue to use= the > value that indicates DWDM. I don't have a strong opinion on this. As discussed in private mails, it is= true that ITU-T sticks to DWDM, but IMHO with the main purpose of defining= a nominal set of frequencies and allowing management of frequency slots / = ranges. If the grid codepoint space remains purely within GMPLS, without ne= cessarily mapping to "1" and "2" from ITU, a new value could clearly mean "= flexi" as opposed to (if defined in the future) a fixed grid with 6.25 GHz = spacing. In any case, it remains a X-bit (32, 64, ?) label, and it is possi= ble to obtain the nominal central frequency for both. The "spectrum switche= d" nature as opposed to "wavelength switched" nature of the LSP can be dedu= ced from a higher context. I'm fine either way. > 2nd issue =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > So, what information do we need to carry in a label to satisfy that? I th= ink it > is a full description of the channel, and AFAICS for flexi-grid this incl= udes > the m parameter. My personal preference, although I understand both Fatai's and Yao's view o= n this, is also that the m parameter is part of the label, it is part of th= e definition of the switchable entity, simplifies upstream processing and h= as the "nice to have" feature of WSON and other SC that an ERO with explici= t label control captures the cross-connects. However, Fatai's view of m as = that the "amount of resource to be reserved" with regard to a total "capaci= ty" (optical spectrum) and as such is part of the sender descriptor / flow = descriptor / flowspec is also valid. It also has the practical advantage th= at it remains 32-bits, implementations may have relied in common data types= (uint32_t) to encode LSC labels. In the past, we considered a u32 label fo= llowing LSC labels where m was encoded in the WSON "identifier" field for S= SON Thanks Ramon --=20 From lberger@labn.net Sun Nov 13 06:24:08 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8021F8B68 for ; Sun, 13 Nov 2011 06:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.494 X-Spam-Level: X-Spam-Status: No, score=-99.494 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wmofkIWIBNQ for ; Sun, 13 Nov 2011 06:24:08 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 0B6F021F8B67 for ; Sun, 13 Nov 2011 06:24:07 -0800 (PST) Received: (qmail 9115 invoked by uid 0); 13 Nov 2011 14:24:08 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 13 Nov 2011 14:24:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=x9TGponzim6m0RdWcIAyYC8JtZgSiW9S38c/UNmVsog=; b=siO31jLnpVLJHNnfkiNg8FFAq2eob9wX8rgfNeuW3QghwNoQxReCO7mAYmJ4Jb9lG19QJPfnqMt2lZjtCaRpnlWJ6a8ty1RjvXSvip6NdmZyduqn4LXK+KrUmYjZqKr6; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RPaye-0002yI-8Z for ccamp@ietf.org; Sun, 13 Nov 2011 07:24:08 -0700 Message-ID: <4EBF1FEE.6020904@labn.net> Date: Sat, 12 Nov 2011 20:39:58 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] request to WG authors/editors who are not presenting this week X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 14:24:08 -0000 Authors of WG documents, If you are *not* presenting a WG document that you edit/author this week, please be prepared to say a few words on document status/progress/planned revisions in our first session. Alternatively, you can send this information to the WG mail list prior to Tuesday's meeting. Much thanks. From zhangfatai@huawei.com Sun Nov 13 17:41:32 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6411E80E7 for ; Sun, 13 Nov 2011 17:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-4.014, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmuXYv9TG5RN for ; Sun, 13 Nov 2011 17:41:32 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1B12711E80E5 for ; Sun, 13 Nov 2011 17:41:32 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM0062RNB1K2@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 14 Nov 2011 09:40:13 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00MBRNB1EL@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 14 Nov 2011 09:40:13 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA18039; Mon, 14 Nov 2011 09:40:12 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 09:40:10 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.92]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 09:40:03 +0800 Date: Mon, 14 Nov 2011 01:40:02 +0000 From: Zhangfatai In-reply-to: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> X-Originating-IP: [172.24.2.40] To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] Trying to resolve flexi-grid issue 1 Thread-index: AcyhinYiQsOh76uLSlunbu9Vrv2EFAA4rWhd X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> Subject: [CCAMP] =?gb2312?b?tPC4tDogIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdy?= =?gb2312?b?aWQgaXNzdWUgMQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:41:32 -0000 SGkgQWRyaWFuLA0KDQpGcm9tIHRlY2ggcG9pbnQgb2YgdmlldywgZWl0aGVyIHdheSBpcyBPSyBm b3IgW2RyYWZ0LXpoYW5nXSBpZiB0aGVyZSBpcyBubyBuZWVkIGZvciBhIGRpcmVjdCBtYXBwaW5n IHRvIElUVS1UIGdyaWRzLg0KDQoNClRoYW5rcw0KDQpGYXRhaQ0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9y ZyBbY2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBBZHJpYW4gRmFycmVsIFthZHJpYW5Ab2xk ZG9nLmNvLnVrXQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MIxM8jVIDY6MjkNCrW9OiBjY2FtcEBpZXRm Lm9yZw0K1vfM4jogW0NDQU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDEN Cg0KSGksDQoNCkkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNhbiBwcmltZSB0aGUgZGlzY3Vz c2lvbnMgb2YgZmxleGktZ3JpZCBsYWJlbHMgaW4NCmFkdmFuY2Ugb2YgdGhlIFdHIG1lZXRpbmdz IHRoaXMgd2Vlay4NCg0KSXQgbG9va3MgbGlrZSB3ZSBoYXZlIHN1Y2Nlc3NmdWxseSBhZ3JlZWQg dGhhdCB0aGVyZSBhcmUgdHdvIHNpZ25pZmljYW50DQpkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBs YWJlbCBmb3JtYXRzIGRlZmluZWQgaW4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmFycmtpbmdlbC1jY2FtcC1mbGV4aWdyaWQtbGFtYmRhLWxhYmVsDQphbmQgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1mbGV4aWJsZS1ncmlk LXJzdnAtdGUtZXh0DQoNClRoZSBmaXJzdCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5IG1pbm9yOg0K DQpTaG91bGQgd2UgdXNlIGEgbmV3IHZhbHVlIGZvciB0aGUgR3JpZCBmaWVsZCBvciBzaG91bGQg d2UgY29udGludWUgdG8gdXNlIHRoZQ0KdmFsdWUgdGhhdCBpbmRpY2F0ZXMgRFdETS4NCg0KSW4g ZmF2b3Igb2YgY29udGludWluZyB0byB1c2UgdGhlIERXRE0gdmFsdWUgaXMgdGhlIGZhY3QgdGhh dCB0aGUgSVRVLVQgaGFzIG5vdA0KZGVmaW5lZCBhIG5ldyBncmlkIGZvciBmbGV4aWJsZSB3YXZl bGVuZ3RoIGFzc2lnbm1lbnRzLiBJbiBmYWN0LCB0aGUgSVRVLVQgc2F5cw0KdGhhdCBmbGV4aWJs ZSBhc3NpZ25tZW50cyBzaG91bGQgYmUgbWFkZSBmcm9tIHRoZSBEV0RNIGdyaWQuDQoNCk9uIHRo ZSBvdGhlciBoYW5kIHdlIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGF0IHRoZSBmaWVsZHMgaW4gR01Q TFMgb2JqZWN0cyBleGlzdA0KdG8gbWFrZSBpbXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5kIHRvIGNv bnZleSBpbmZvcm1hdGlvbi4gVGhlcmUgaXMgbm8gbmVlZCBmb3IgYQ0KZGlyZWN0IG1hcHBpbmcg dG8gSVRVLVQgZ3JpZHMuDQoNClRodXMsIHdoZW4gZHJhZnQtemhhbmcgc3VnZ2VzdHMgdXNpbmcg R3JpZD09MSAoSVRVLVQgRFdETSkgaXQgaXMgY29ycmVjdCB0aGF0DQp0aGUgZmxleGlibGUgZ3Jp ZCB3YXZlbGVuZ3RocyB3aWxsIGJlIHN1Z2dlc3RlZCBmcm9tIHRoZSBJVFUtVCBEV0RNIGdyaWQs IGJ1dCBpdA0KaXMgbm90IGJlaW5nIGFzIGhlbHBmdWwgYXMgaXQgY291bGQgYmUuDQoNCldoZW4g ZHJhZnQtZmFycmtpbmdlbCBzdWdnZXN0cyB1c2luZyBHcmlkPT0zIChJVFUtVCBGbGV4KSBpdCBp cyBub3QgaW1wbHlpbmcNCnRoYXQgdGhlcmUgaXMgYSBuZXcgYW5kIGRpZmZlcmVudCBncmlkIGRl ZmluZWQgYnkgdGhlIElUVS1ULiBXaGF0IGl0IGlzIHNheWluZw0KaXMgdGhhdCB0aGUgbGFiZWwg aXMgYSBmbGV4aS1ncmlkIGxhYmVsIHNlbGVjdGVkIGZyb20gdGhlIGdyaWQgZGVmaW5lZCBieSB0 aGUNCklUVS1UIGZvciB0aGF0IHB1cnBvc2UgKGkuZS4sIHRoZSBEV0RNIGdyaWQpLg0KDQpQZXJz b25hbGx5LCBpIGRvbid0IHNlZSB0aGlzIGFzIGEgdmVyeSBsYXJnZSBpc3N1ZS4gZHJhZnQtZmFy cmtpbmdlbCB3b3VsZCB3b3JrDQpqdXN0IGFzIHdlbGwgaWYgd2UgZGVjaWRlIHRvIHVzZSBHcmlk PT0xLiBob3dldmVyLCBJIHRoaW5rIGl0IGlzIG1hcmdpbmFsbHkgbW9yZQ0KaGVscGZ1bCBhbmQg dXNlZnVsIHRvIGJlIGFibGUgdG8gcmVjb2duaXNlIHRoZSBkaWZmZXJlbnQgbGFiZWwgdXNlIGNh c2VzIChmaXhlZA0KZ3JpZCAvIGZsZXhpYmxlIGdyaWQpIGJ5IGxvb2tpbmcgYXQgYSBmaWVsZCBl YXJseSBpbiB0aGUgTGFiZWwgb2JqZWN0Lg0KQ29udmVyc2VseSwgSSBkb24ndCBiZWxpZXZlIHRo YXQgZHJhZnQtemhhbmcgd291bGQgYmUgYnJva2VuIGJ5IHVzaW5nIEdyaWQ9PTMuDQoNClNvIG15 IGNvbXByb21pc2UgcHJvcG9zYWwgaXMgdGhhdCBib3RoIEktRHMgdXNlIEdyaWQ9PTMuIFRoZW4g d2UgY2FuIGNvbmNlbnRyYXRlDQpvbiB0aGUgbW9yZSBzaWduaWZpY2FudCBzZWNvbmQgaXNzdWUg KHNlZSBzZXBhcmF0ZSBlbWFpbCkuDQoNCldoYXQgZG8gZm9sayB0aGluaz8NCg0KQ2hlZXJzLA0K QWRyaWFuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w From rrao@infinera.com Sun Nov 13 18:06:53 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343F81F0C53 for ; Sun, 13 Nov 2011 18:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwm-ptdGNyf1 for ; Sun, 13 Nov 2011 18:06:52 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 787801F0C62 for ; Sun, 13 Nov 2011 18:06:52 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.01.0339.001; Sun, 13 Nov 2011 18:06:51 -0800 From: Rajan Rao To: Daniele Ceccarelli , "adrian@olddog.co.uk" , "ccamp@ietf.org" Thread-Topic: [CCAMP] Flexi-grid issue 2 Thread-Index: AcyhpCfI7o9JPdPYRsiidOB4aUW3+gAMTM1QACbiC3A= Date: Mon, 14 Nov 2011 02:06:51 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D0ABF1C50@SV-EXDB-PROD1.infinera.com> References: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Marco Sosa , Abinder Dhillon , Iftekhar Hussain Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:06:53 -0000 Hi, The other thing we need to consider is OEO possibilities and use of values = other than 12.5GHz as base granularity in future.=20 Putting 'm' in traffic param does allow modifications by intermediate nodes= if we were to address the above possibilities. Having it in the label seem= s like the right approach. BTW, there is another draft on the same topic: draft-hussain-ccamp-super-channel-label-02.txt thanks Rajan -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Saturday, November 12, 2011 11:38 PM To: adrian@olddog.co.uk; ccamp@ietf.org Subject: Re: [CCAMP] Flexi-grid issue 2 Hi Adrian, Hottest issue. The choice of putting the m parameter into the label seems t= o better fit with label definition, but on the other side, thinking of traf= fic parameters, they indicate the amount of resources requested, and the m = parameter indeed indicates right that. Both solutions seem to be acceptable. Further considerations might be neede= d. Thanks and BR=20 Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: domenica 13 novembre 2011 2.34 To: ccamp@ietf.org Subject: [CCAMP] Flexi-grid issue 2 Hi, Second email on the differences between the label formats defined in http:/= /datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te= -ext This issue is more complicated than the first issue. This question has two sub-points: a. where do we carry the flexi-grid m parameter? b. where do we carry traffic parameters for flexi-grid? draft-zhang is a more comprehensive document that draft-farrkingel because = it aims to cover a number of significant signaling parameters for RSVP-TE. draft-farrkingel only attempts to define a label structure. Thus, the question we need to resolve is not where to carry the traffic par= ameters for flexi-grid, but what constitutes a label in flexi-grid? Maybe we should start this with the question: what is a label? RFC 3471 say= s: =20 A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. So, what information do we need to carry in a label to satisfy that? I thin= k it is a full description of the channel, and AFAICS for flexi-grid this i= ncludes the m parameter. Thanks, Adrian _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From malcolm.betts@zte.com.cn Sun Nov 13 18:11:49 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4517521F8447; Sun, 13 Nov 2011 18:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajYSZgdec7YK; Sun, 13 Nov 2011 18:11:45 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 476F71F0C62; Sun, 13 Nov 2011 18:11:44 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901461793122; Mon, 14 Nov 2011 10:00:32 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 5206.1571691418; Mon, 14 Nov 2011 10:11:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pAE2BQD7023687; Mon, 14 Nov 2011 10:11:26 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> References: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> To: adrian@olddog.co.uk MIME-Version: 1.0 X-KeepSent: A8325D10:731B69BA-85257948:0009F3EE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Sun, 13 Nov 2011 21:11:18 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-14 10:11:27, Serialize complete at 2011-11-14 10:11:27 Content-Type: multipart/alternative; boundary="=_alternative 000C092D85257948_=" X-MAIL: mse01.zte.com.cn pAE2BQD7023687 Cc: ccamp@ietf.org, ccamp-bounces@ietf.org Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:11:49 -0000 This is a multipart message in MIME format. --=_alternative 000C092D85257948_= Content-Type: text/plain; charset="US-ASCII" Hi Adrian, Interesting questions, but I think we need to consider the bigger picture first. A few quick thoughts: One motivation for the flexi-grid is to support the next generation optical signals (>100Gb/s) that cannot be efficiently accommodated with the current fixed grid. However, we can expect to see flexi-grid deployed before these higher bit rate systems. The current fixed grid provides an implicit guard band between optical channels (and slots can be left unused to allow a greater guard band). With flexi-grid we will probably need to specify the guard band. The guard band will probably need to defined by a PCE application but we will need to define the parameters. Given that transiting an OADM narrows the optical bandwidth it may be possible to optimize the network by adjusting the requested bandwidth based on the number of OADMs in the path. How would we "retain" this information to support restoration. I expect that we will have a concatenation of flexi-grid and fixed grid links (managed via a PCE) in the network. How will we signal for example for a slot to carry 10Gb/s signal across a network that includes the concatenation of fixed grid and flexi-grid segments. The implication of routing (RWA) may also be interesting. The flexi-grid will result in bandwidth fragmentation as traffic is added and removed from links. We need to consider the need to defragment the link. I think that the implications of flexi-grid go beyond signalling into routing (RWA). The SG 15 will be meeting in December and will hold discussion on the use of the flexi-grid. It would be useful to provide, either formally or informally a set of questions. Regards, Malcolm "Adrian Farrel" Sent by: ccamp-bounces@ietf.org 12/11/2011 05:29 PM Please respond to adrian@olddog.co.uk To cc Subject [CCAMP] Trying to resolve flexi-grid issue 1 Hi, I wanted to see whether we can prime the discussions of flexi-grid labels in advance of the WG meetings this week. It looks like we have successfully agreed that there are two significant differences between the label formats defined in http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext The first point seems relatively minor: Should we use a new value for the Grid field or should we continue to use the value that indicates DWDM. In favor of continuing to use the DWDM value is the fact that the ITU-T has not defined a new grid for flexible wavelength assignments. In fact, the ITU-T says that flexible assignments should be made from the DWDM grid. On the other hand we need to understand that the fields in GMPLS objects exist to make implementation easier and to convey information. There is no need for a direct mapping to ITU-T grids. Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is correct that the flexible grid wavelengths will be suggested from the ITU-T DWDM grid, but it is not being as helpful as it could be. When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not implying that there is a new and different grid defined by the ITU-T. What it is saying is that the label is a flexi-grid label selected from the grid defined by the ITU-T for that purpose (i.e., the DWDM grid). Personally, i don't see this as a very large issue. draft-farrkingel would work just as well if we decide to use Grid==1. however, I think it is marginally more helpful and useful to be able to recognise the different label use cases (fixed grid / flexible grid) by looking at a field early in the Label object. Conversely, I don't believe that draft-zhang would be broken by using Grid==3. So my compromise proposal is that both I-Ds use Grid==3. Then we can concentrate on the more significant second issue (see separate email). What do folk think? Cheers, Adrian _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 000C092D85257948_= Content-Type: text/html; charset="US-ASCII" Hi Adrian,

Interesting questions, but I think we need to consider the bigger picture first.  A few quick thoughts:

One motivation for the flexi-grid is to support the next generation optical signals (>100Gb/s) that cannot be efficiently accommodated with the current fixed grid.  However, we can expect to see flexi-grid deployed before these higher bit rate systems.

The current fixed grid provides an implicit guard band between optical channels (and slots can be left unused to allow a greater guard band).  With flexi-grid we will probably need to specify the guard band.  The guard band will probably need to defined by a PCE application but we will need to define the parameters.  

Given that transiting an OADM narrows the optical bandwidth it may be possible to optimize the network by adjusting the requested bandwidth based on the number of OADMs in the path.  How would we "retain" this information to support restoration.

I expect that we will have a concatenation of flexi-grid and fixed grid links (managed via a PCE) in the network.  How will we signal for example for a slot to carry 10Gb/s signal across a network that includes the concatenation of fixed grid and flexi-grid segments.  The implication of routing (RWA) may also be interesting.

The flexi-grid will result in bandwidth fragmentation as traffic is added and removed from links.  We need to consider the need to defragment the link.

I think that the implications of flexi-grid go beyond signalling into routing (RWA).

The SG 15 will be meeting in December and will hold discussion on the use of the flexi-grid.  It would be useful to provide, either formally or informally a set of questions.

Regards,

Malcolm



"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: ccamp-bounces@ietf.org

12/11/2011 05:29 PM
Please respond to
adrian@olddog.co.uk
To
<ccamp@ietf.org>
cc
Subject
[CCAMP] Trying to resolve flexi-grid issue 1





Hi,

I wanted to see whether we can prime the discussions of flexi-grid labels in
advance of the WG meetings this week.

It looks like we have successfully agreed that there are two significant
differences between the label formats defined in
http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label
and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext

The first point seems relatively minor:

Should we use a new value for the Grid field or should we continue to use the
value that indicates DWDM.

In favor of continuing to use the DWDM value is the fact that the ITU-T has not
defined a new grid for flexible wavelength assignments. In fact, the ITU-T says
that flexible assignments should be made from the DWDM grid.

On the other hand we need to understand that the fields in GMPLS objects exist
to make implementation easier and to convey information. There is no need for a
direct mapping to ITU-T grids.

Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is correct that
the flexible grid wavelengths will be suggested from the ITU-T DWDM grid, but it
is not being as helpful as it could be.

When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not implying
that there is a new and different grid defined by the ITU-T. What it is saying
is that the label is a flexi-grid label selected from the grid defined by the
ITU-T for that purpose (i.e., the DWDM grid).

Personally, i don't see this as a very large issue. draft-farrkingel would work
just as well if we decide to use Grid==1. however, I think it is marginally more
helpful and useful to be able to recognise the different label use cases (fixed
grid / flexible grid) by looking at a field early in the Label object.
Conversely, I don't believe that draft-zhang would be broken by using Grid==3.

So my compromise proposal is that both I-Ds use Grid==3. Then we can concentrate
on the more significant second issue (see separate email).

What do folk think?

Cheers,
Adrian

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--=_alternative 000C092D85257948_=-- From zhangfatai@huawei.com Sun Nov 13 18:20:33 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D3511E8105 for ; Sun, 13 Nov 2011 18:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=-3.813, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRCLlShq6mit for ; Sun, 13 Nov 2011 18:20:33 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C63F411E8116 for ; Sun, 13 Nov 2011 18:20:32 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00LOUP62IJ@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 14 Nov 2011 10:20:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM007U8P5NU3@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 14 Nov 2011 10:20:26 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY66781; Mon, 14 Nov 2011 10:20:25 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 10:20:23 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.92]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 10:20:13 +0800 Date: Mon, 14 Nov 2011 02:20:12 +0000 From: Zhangfatai In-reply-to: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> X-Originating-IP: [172.24.2.40] To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] Flexi-grid issue 2 Thread-index: AcyhpCfI7o9JPdPYRsiidOB4aUW3+gAzfwpy X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> Subject: [CCAMP] =?gb2312?b?tPC4tDogIEZsZXhpLWdyaWQgaXNzdWUgMg==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:20:33 -0000 SGkgQWRyaWFuLA0KDQpEbyB5b3UgYWdyZWUgdGhhdCAibSIgc2hvdWxkIGFsc28gYmUgcHV0IGlu dG8gVHJhZmZpYyBQYXJhbWV0ZXJzIG9iamVjdCwgd2hpY2ggaW5kaWNhdGVzIGhvdyBtdWNoIHJl c291cmNlIHNob3VsZCBiZSByZXNlcnZlZCBiZWZvcmUgd2UgZGVjaWRlIHdoZXRoZXJlIHdlIHNo b3VsZCBwdXQgIm0iIGluIHRoZSBMYWJlbD8NCg0KVGFsa2luZyBhYm91dCB0aGUgTGFiZWwgZGVm aW5pdGlvbiBmcm9tIFJGQzM0NzEsIHRoZSBMYWJlbCBkZWZpbmVkIGluIFtkcmFmdC16aGFuZ10g Y29udGFpbnMgImVub3VnaCBpbmZvcm1hdGlvbiIgdG8gYWxsb3cgdGhlIHJlY2VpdmluZyBub2Rl IHRvIHByb2dyYW0gaXRzIGNyb3NzIGNvbm5lY3QsIGllLiwgbm90aGluZyBpcyBtaXNzZWQgZnJv bSBteSB1bmRlcnN0YW5kaW5nLiAgDQoNCldlIGtub3cgdGhhdCB0aGUgcmVjaXZlaW5nIG5vZGUg Y2Fubm90IHByb2dyYW0gaXRzIGNyb3NzIGNvbm5lY3QgY29ycmVjdGx5IGJ5IHVzaW5nIG9ubHkg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGUgIkxhYmVsIiwgYmVjYXVzZSBpdCBhbHNv IG5lZWRzIHRvIGdldCBzb21lIG90aGVyIGluZm9ybWF0aW9uIChlLmcuLCBURSBsaW5rIG9yIGNv bXBvbmVudCBsaW5rIGluZm9ybWF0aW9uKSBmcm9tIG90aGVyIFJTVlAgb2JqZWN0cyBzdWNoIGFz IEVSTyBvciBSU1ZQLUhPUC4NCg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBoYXZlIGFueSBtaXN1 bmRlcnN0YW5kaW5nLg0KDQpGYXRhaQ0KDQpUaGFua3MNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW2Nj YW1wLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQWRyaWFuIEZhcnJlbCBbYWRyaWFuQG9sZGRvZy5j by51a10NCreiy83KsbzkOiAyMDExxOoxMdTCMTPI1SA5OjM0DQq1vTogY2NhbXBAaWV0Zi5vcmcN Ctb3zOI6IFtDQ0FNUF0gRmxleGktZ3JpZCBpc3N1ZSAyDQoNCkhpLA0KDQpTZWNvbmQgZW1haWwg b24gdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGxhYmVsIGZvcm1hdHMgZGVmaW5lZCBpbg0K aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZs ZXhpZ3JpZC1sYW1iZGEtbGFiZWwNCmFuZCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpoYW5nLWNjYW1wLWZsZXhpYmxlLWdyaWQtcnN2cC10ZS1leHQNCg0KVGhpcyBpc3N1 ZSBpcyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhlIGZpcnN0IGlzc3VlLiBUaGlzIHF1ZXN0aW9u IGhhcyB0d28NCnN1Yi1wb2ludHM6DQphLiB3aGVyZSBkbyB3ZSBjYXJyeSB0aGUgZmxleGktZ3Jp ZCBtIHBhcmFtZXRlcj8NCmIuIHdoZXJlIGRvIHdlIGNhcnJ5IHRyYWZmaWMgcGFyYW1ldGVycyBm b3IgZmxleGktZ3JpZD8NCg0KZHJhZnQtemhhbmcgaXMgYSBtb3JlIGNvbXByZWhlbnNpdmUgZG9j dW1lbnQgdGhhdCBkcmFmdC1mYXJya2luZ2VsIGJlY2F1c2UgaXQNCmFpbXMgdG8gY292ZXIgYSBu dW1iZXIgb2Ygc2lnbmlmaWNhbnQgc2lnbmFsaW5nIHBhcmFtZXRlcnMgZm9yIFJTVlAtVEUuDQpk cmFmdC1mYXJya2luZ2VsIG9ubHkgYXR0ZW1wdHMgdG8gZGVmaW5lIGEgbGFiZWwgc3RydWN0dXJl Lg0KDQpUaHVzLCB0aGUgcXVlc3Rpb24gd2UgbmVlZCB0byByZXNvbHZlIGlzIG5vdCB3aGVyZSB0 byBjYXJyeSB0aGUgdHJhZmZpYw0KcGFyYW1ldGVycyBmb3IgZmxleGktZ3JpZCwgYnV0IHdoYXQg Y29uc3RpdHV0ZXMgYSBsYWJlbCBpbiBmbGV4aS1ncmlkPw0KDQpNYXliZSB3ZSBzaG91bGQgc3Rh cnQgdGhpcyB3aXRoIHRoZSBxdWVzdGlvbjogd2hhdCBpcyBhIGxhYmVsPyBSRkMgMzQ3MSBzYXlz Og0KDQogICBBIGdlbmVyYWxpemVkIGxhYmVsIGNvbnRhaW5zIGVub3VnaCBpbmZvcm1hdGlvbiB0 byBhbGxvdyB0aGUgcmVjZWl2aW5nDQogICBub2RlIHRvIHByb2dyYW0gaXRzIGNyb3NzIGNvbm5l Y3QsIHJlZ2FyZGxlc3Mgb2YgdGhlIHR5cGUgb2YgdGhpcw0KICAgY3Jvc3MgY29ubmVjdCwgc3Vj aCB0aGF0IHRoZSBpbmdyZXNzIHNlZ21lbnRzIG9mIHRoZSBwYXRoIGFyZQ0KICAgcHJvcGVybHkg am9pbmVkLg0KDQpTbywgd2hhdCBpbmZvcm1hdGlvbiBkbyB3ZSBuZWVkIHRvIGNhcnJ5IGluIGEg bGFiZWwgdG8gc2F0aXNmeSB0aGF0PyBJIHRoaW5rIGl0DQppcyBhIGZ1bGwgZGVzY3JpcHRpb24g b2YgdGhlIGNoYW5uZWwsIGFuZCBBRkFJQ1MgZm9yIGZsZXhpLWdyaWQgdGhpcyBpbmNsdWRlcw0K dGhlIG0gcGFyYW1ldGVyLg0KDQpUaGFua3MsDQpBZHJpYW4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA= From IHussain@infinera.com Sun Nov 13 18:48:44 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1172321F85DB; Sun, 13 Nov 2011 18:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgZd33FWXRyn; Sun, 13 Nov 2011 18:48:42 -0800 (PST) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6021F85F2; Sun, 13 Nov 2011 18:48:39 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.01.0339.001; Sun, 13 Nov 2011 18:48:39 -0800 From: Iftekhar Hussain To: "Malcolm.BETTS@zte.com.cn" , "adrian@olddog.co.uk" Thread-Topic: [CCAMP] Trying to resolve flexi-grid issue 1 Thread-Index: AQHMonQD2c7ZtHt1xkGvdL4otrxNMJWrpkiA Date: Mon, 14 Nov 2011 02:48:38 +0000 Message-ID: References: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB38DFCSVEXDBPROD1infi_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" , Vinayak Dangui , Marco Sosa , Abinder Dhillon , "ccamp-bounces@ietf.org" Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:48:44 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB38DFCSVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Malcolm, Agreed with your observation about fragmentation in flexible grid. BTW, thi= s is one of the reasons why we need to consider flexible approach for label= definition that allows defragmentation (e.g., see split-spectrum super-c= hannel option in http://tools.ietf.org/html/draft-hussain-ccamp-super-chan= nel-label-02). Regarding consideration about guard-band, I think, it can be considered as = a part of path computation constraint - does not necessarily need to advert= ise this as a part of routing. Regards, Iftekhar From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] Sent: Sunday, November 13, 2011 6:11 PM To: adrian@olddog.co.uk Cc: ccamp@ietf.org; ccamp-bounces@ietf.org Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 Hi Adrian, Interesting questions, but I think we need to consider the bigger picture f= irst. A few quick thoughts: One motivation for the flexi-grid is to support the next generation optical= signals (>100Gb/s) that cannot be efficiently accommodated with the curren= t fixed grid. However, we can expect to see flexi-grid deployed before the= se higher bit rate systems. The current fixed grid provides an implicit guard band between optical chan= nels (and slots can be left unused to allow a greater guard band). With fl= exi-grid we will probably need to specify the guard band. The guard band w= ill probably need to defined by a PCE application but we will need to defin= e the parameters. Given that transiting an OADM narrows the optical bandwidth it may be possi= ble to optimize the network by adjusting the requested bandwidth based on t= he number of OADMs in the path. How would we "retain" this information to = support restoration. I expect that we will have a concatenation of flexi-grid and fixed grid lin= ks (managed via a PCE) in the network. How will we signal for example for = a slot to carry 10Gb/s signal across a network that includes the concatenat= ion of fixed grid and flexi-grid segments. The implication of routing (RWA= ) may also be interesting. The flexi-grid will result in bandwidth fragmentation as traffic is added a= nd removed from links. We need to consider the need to defragment the link= . I think that the implications of flexi-grid go beyond signalling into routi= ng (RWA). The SG 15 will be meeting in December and will hold discussion on the use o= f the flexi-grid. It would be useful to provide, either formally or inform= ally a set of questions. Regards, Malcolm "Adrian Farrel" > Sent by: ccamp-bounces@ietf.org 12/11/2011 05:29 PM Please respond to adrian@olddog.co.uk To > cc Subject [CCAMP] Trying to resolve flexi-grid issue 1 Hi, I wanted to see whether we can prime the discussions of flexi-grid labels i= n advance of the WG meetings this week. It looks like we have successfully agreed that there are two significant differences between the label formats defined in http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-lab= el and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te= -ext The first point seems relatively minor: Should we use a new value for the Grid field or should we continue to use t= he value that indicates DWDM. In favor of continuing to use the DWDM value is the fact that the ITU-T has= not defined a new grid for flexible wavelength assignments. In fact, the ITU-T = says that flexible assignments should be made from the DWDM grid. On the other hand we need to understand that the fields in GMPLS objects ex= ist to make implementation easier and to convey information. There is no need f= or a direct mapping to ITU-T grids. Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it is correc= t that the flexible grid wavelengths will be suggested from the ITU-T DWDM grid, b= ut it is not being as helpful as it could be. When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it is not imp= lying that there is a new and different grid defined by the ITU-T. What it is say= ing is that the label is a flexi-grid label selected from the grid defined by t= he ITU-T for that purpose (i.e., the DWDM grid). Personally, i don't see this as a very large issue. draft-farrkingel would = work just as well if we decide to use Grid=3D=3D1. however, I think it is margin= ally more helpful and useful to be able to recognise the different label use cases (f= ixed grid / flexible grid) by looking at a field early in the Label object. Conversely, I don't believe that draft-zhang would be broken by using Grid= =3D=3D3. So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then we can co= ncentrate on the more significant second issue (see separate email). What do folk think? Cheers, Adrian _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB38DFCSVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Malcolm,

 <= /p>

Agreed with your observat= ion about fragmentation in flexible grid. BTW, this is one of the reasons w= hy we need to consider flexible approach for label definition that allows defragmentation (e.g., see  split-spectrum  super-ch= annel option in  http://tools.ietf.org/html/draft-hussain-ccamp-super-= channel-label-02).

 <= /p>

Regarding consideration a= bout guard-band, I think, it can be considered as a part of path computatio= n constraint - does not necessarily need to advertise this as a part of routing.

 <= /p>

Regards,

Iftekhar

 <= /p>

From: Malcolm.= BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
Sent: Sunday, November 13, 2011 6:11 PM
To: adrian@olddog.co.uk
Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1=

 

Hi Adrian,=

Interesting questions, but I think we need to consider the bigge= r picture first.  A few quick thoughts:

One motivation for the flexi-grid is to support the next generat= ion optical signals (>100Gb/s) that cannot be efficiently accommodated w= ith the current fixed grid.  However, we can expect to see flexi-grid deployed before these higher bit rate systems.

The current fixed grid provides an implicit guard band between o= ptical channels (and slots can be left unused to allow a greater guard band= ).  With flexi-grid we will probably need to specify the guard band.  The guard band will probably need to defined by a PCE ap= plication but we will need to define the parameters.  

Given that transiting an OADM narrows the optical bandwidth it m= ay be possible to optimize the network by adjusting the requested bandwidth= based on the number of OADMs in the path.  How would we "retain" this information to support restoration.

I expect that we will have a concatenation of flexi-grid and fix= ed grid links (managed via a PCE) in the network.  How will we signal = for example for a slot to carry 10Gb/s signal across a network that includes the concatenation of fixed grid and flexi-grid segments. &nb= sp;The implication of routing (RWA) may also be interesting.

The flexi-grid will result in bandwidth fragmentation as traffic= is added and removed from links.  We need to consider the need to def= ragment the link.

I think that the implications of flexi-grid go beyond signalling= into routing (RWA).

The SG 15 will be meeting in December and will hold discussion o= n the use of the flexi-grid.  It would be useful to provide, either fo= rmally or informally a set of questions.

Regards,

Malcolm


"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: ccamp-bounces@ietf.org

12/11/2011 05:29 PM

Please respond to
adrian@olddog.co.uk<= /o:p>

To

<ccam= p@ietf.org>

cc

Subject

[CCAMP] Trying to resolve flexi-grid issue= 1

 




Hi,

I wanted to see whether we can prime the discussions of flexi-grid labe= ls in
advance of the WG meetings this week.

It looks like we have successfully agreed that there are two significan= t
differences between the label formats defined in
http://datatrack= er.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label
and http:= //datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext

The first point seems relatively minor:

Should we use a new value for the Grid field or should we continue to u= se the
value that indicates DWDM.

In favor of continuing to use the DWDM value is the fact that the ITU-T= has not
defined a new grid for flexible wavelength assignments. In fact, the IT= U-T says
that flexible assignments should be made from the DWDM grid.

On the other hand we need to understand that the fields in GMPLS object= s exist
to make implementation easier and to convey information. There is no ne= ed for a
direct mapping to ITU-T grids.

Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it is co= rrect that
the flexible grid wavelengths will be suggested from the ITU-T DWDM gri= d, but it
is not being as helpful as it could be.

When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it is not= implying
that there is a new and different grid defined by the ITU-T. What it is= saying
is that the label is a flexi-grid label selected from the grid defined = by the
ITU-T for that purpose (i.e., the DWDM grid).

Personally, i don't see this as a very large issue. draft-farrkingel wo= uld work
just as well if we decide to use Grid=3D=3D1. however, I think it is ma= rginally more
helpful and useful to be able to recognise the different label use case= s (fixed
grid / flexible grid) by looking at a field early in the Label object.<= /tt>
Conversely, I don't believe that draft-zhang would be broken by using G= rid=3D=3D3.

So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then we ca= n concentrate
on the more significant second issue (see separate email).

What do folk think?

Cheers,
Adrian

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp=

--_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB38DFCSVEXDBPROD1infi_-- From adrian@olddog.co.uk Sun Nov 13 18:48:46 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5BE21F86D0 for ; Sun, 13 Nov 2011 18:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltVhmiI3hhR6 for ; Sun, 13 Nov 2011 18:48:46 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBD721F858D for ; Sun, 13 Nov 2011 18:48:45 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAE2mgCX028782; Mon, 14 Nov 2011 02:48:43 GMT Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAE2mZpt028754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 02:48:40 GMT From: "Adrian Farrel" To: References: <020a01cca18a$7fd31340$7f7939c0$@olddog.co.uk> In-Reply-To: Date: Mon, 14 Nov 2011 02:48:33 -0000 Message-ID: <03be01cca277$eaca5bc0$c05f1340$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQGTBu2ea0XsaN6czk57ALpSHyK4BgHIZQGslhCdXoA= Cc: ccamp@ietf.org Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:48:46 -0000 > The SG 15 will be meeting in December and will hold discussion on the > use of the flexi-grid. =A0It would be useful to provide, either = formally or=20 > informally a set of questions.=20 Yes. And it needs to be clear within CCAMP that we cannot (which is stronger = than must not!) get ahead of Q6/15. At the risk of asking you to talk to yourself, it may be really helpful = for you to work with John Drake to build this list of questions. A From adrian@olddog.co.uk Sun Nov 13 18:54:56 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA03F1F0CA5 for ; Sun, 13 Nov 2011 18:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFisnunetpnB for ; Sun, 13 Nov 2011 18:54:55 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 63BCE1F0CA3 for ; Sun, 13 Nov 2011 18:54:55 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAE2slUm011211; Mon, 14 Nov 2011 02:54:47 GMT Received: from 950129200 (dhcp-11f1.meeting.ietf.org [130.129.17.241]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAE2sbwq011182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Nov 2011 02:54:44 GMT From: "Adrian Farrel" To: "'Zhangfatai'" , References: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> In-Reply-To: Date: Mon, 14 Nov 2011 02:54:35 -0000 Message-ID: <03d001cca278$c41f69b0$4c5e3d10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQIkh/xTAcc9aMBM1GNnWfiiOKVkqwJZI5CIlOkV9aA= Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 02:54:56 -0000 Hi, I've not spent a lot of time looking at the traffic parameters, but yes. = It seems to me that part of requesting the LSP could include specifying a = number of parameters related to capacity and construction. That would mean that = "m" might reasonably be in the traffic parameters (or maybe there would be a = choice of values of m) and the final chosen value of m would then be placed in the = label. You are, of course, right that issues like interface ID and component = interface ID are also necessary for XC programming. A > -----Original Message----- > From: Zhangfatai [mailto:zhangfatai@huawei.com] > Sent: 14 November 2011 02:20 > To: adrian@olddog.co.uk; ccamp@ietf.org > Subject: =B4=F0=B8=B4: [CCAMP] Flexi-grid issue 2 >=20 > Hi Adrian, >=20 > Do you agree that "m" should also be put into Traffic Parameters = object, which > indicates how much resource should be reserved before we decide = whethere we > should put "m" in the Label? >=20 > Talking about the Label definition from RFC3471, the Label defined in = [draft- > zhang] contains "enough information" to allow the receiving node to = program its > cross connect, ie., nothing is missed from my understanding. >=20 > We know that the reciveing node cannot program its cross connect = correctly by > using only the information contained in the "Label", because it also = needs to get > some other information (e.g., TE link or component link information) = from other > RSVP objects such as ERO or RSVP-HOP. >=20 > Please correct me if I have any misunderstanding. >=20 > Fatai >=20 > Thanks >=20 >=20 > ________________________________________ > =B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] = =B4=FA=B1=ED Adrian Farrel > [adrian@olddog.co.uk] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C213=C8=D5 9:34 > =B5=BD: ccamp@ietf.org > =D6=F7=CC=E2: [CCAMP] Flexi-grid issue 2 >=20 > Hi, >=20 > Second email on the differences between the label formats defined in > = http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-l= abel > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-e= xt >=20 > This issue is more complicated than the first issue. This question has = two > sub-points: > a. where do we carry the flexi-grid m parameter? > b. where do we carry traffic parameters for flexi-grid? >=20 > draft-zhang is a more comprehensive document that draft-farrkingel = because it > aims to cover a number of significant signaling parameters for = RSVP-TE. > draft-farrkingel only attempts to define a label structure. >=20 > Thus, the question we need to resolve is not where to carry the = traffic > parameters for flexi-grid, but what constitutes a label in flexi-grid? >=20 > Maybe we should start this with the question: what is a label? RFC = 3471 says: >=20 > A generalized label contains enough information to allow the = receiving > node to program its cross connect, regardless of the type of this > cross connect, such that the ingress segments of the path are > properly joined. >=20 > So, what information do we need to carry in a label to satisfy that? I = think it > is a full description of the channel, and AFAICS for flexi-grid this = includes > the m parameter. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From li.yao3@zte.com.cn Sun Nov 13 19:12:12 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B4A1F0C8E; Sun, 13 Nov 2011 19:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aACvsJWXDXQy; Sun, 13 Nov 2011 19:12:11 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2171F0C94; Sun, 13 Nov 2011 19:12:09 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131461793122; Mon, 14 Nov 2011 11:07:21 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.3901946125; Mon, 14 Nov 2011 11:12:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAE3Bl4P000831; Mon, 14 Nov 2011 11:11:47 +0800 (GMT-8) (envelope-from li.yao3@zte.com.cn) In-Reply-To: To: Iftekhar Hussain MIME-Version: 1.0 X-KeepSent: 9AD63CE4:9FD05216-48257948:0010997C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.yao3@zte.com.cn Date: Mon, 14 Nov 2011 11:13:04 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-14 11:11:49, Serialize complete at 2011-11-14 11:11:49 Content-Type: multipart/alternative; boundary="=_alternative 0011913B48257948_=" X-MAIL: mse02.zte.com.cn pAE3Bl4P000831 Cc: Abinder Dhillon , "ccamp@ietf.org" , "ccamp-bounces@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmU6ICBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4?= =?gb2312?b?aS1ncmlkIGlzc3VlIDE=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:12:12 -0000 This is a multipart message in MIME format. --=_alternative 0011913B48257948_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSWZ0ZWtoYXI6DQoNClBsZWFzZSBzZWUgYmVsb3cuIA0KDQpjY2FtcC1ib3VuY2VzQGlldGYu b3JnINC009ogMjAxMS0xMS0xNCAxMDo0ODozODoNCg0KPiBIaSBNYWxjb2xtLA0KPiANCj4gQWdy ZWVkIHdpdGggeW91ciBvYnNlcnZhdGlvbiBhYm91dCBmcmFnbWVudGF0aW9uIGluIGZsZXhpYmxl IGdyaWQuIA0KPiBCVFcsIHRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBuZWVkIHRv IGNvbnNpZGVyIGZsZXhpYmxlIA0KPiBhcHByb2FjaCBmb3IgbGFiZWwgZGVmaW5pdGlvbiB0aGF0 IGFsbG93cyBkZWZyYWdtZW50YXRpb24gKGUuZy4sIHNlZQ0KPiBzcGxpdC1zcGVjdHJ1bSAgc3Vw ZXItY2hhbm5lbCBvcHRpb24gaW4gIGh0dHA6Ly90b29scy5pZXRmLg0KPiBvcmcvaHRtbC9kcmFm dC1odXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwtMDIpLg0KDQo8WWFvPkFjdHVhbGx5 LCBmcmFnbWVudGF0aW9uIHdpbGwgYXBwZWFyIGFzIHRyYWZmaWMgaXMgDQogYWRkZWQgYW5kIHJl bW92ZWQgZnJvbSBsaW5rcy4gVGhlIHdvcmsgb2YgZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZSBs ZWZ0IA0KdG8gY29tcHV0YXRpb24gZW50aXR5IGxpa2UgUENFLiANCkhvd2V2ZXIsIHdoZXRoZXIg dGhlIHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGggY29udGludW91cyBmb3JtIGlzIG5vdCAN CmNsZWFyLg0KDQoNCj4gDQo+IFJlZ2FyZGluZyBjb25zaWRlcmF0aW9uIGFib3V0IGd1YXJkLWJh bmQsIEkgdGhpbmssIGl0IGNhbiBiZSANCj4gY29uc2lkZXJlZCBhcyBhIHBhcnQgb2YgcGF0aCBj b21wdXRhdGlvbiBjb25zdHJhaW50IC0gZG9lcyBub3QgDQo+IG5lY2Vzc2FyaWx5IG5lZWQgdG8g YWR2ZXJ0aXNlIHRoaXMgYXMgYSBwYXJ0IG9mIHJvdXRpbmcuIA0KDQoNCjxZYW8+IEFncmVlLg0K DQoNCj4gDQo+IFJlZ2FyZHMsDQo+IElmdGVraGFyDQo+IA0KPiBGcm9tOiBNYWxjb2xtLkJFVFRT QHp0ZS5jb20uY24gW21haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY25dIA0KPiBTZW50OiBT dW5kYXksIE5vdmVtYmVyIDEzLCAyMDExIDY6MTEgUE0NCj4gVG86IGFkcmlhbkBvbGRkb2cuY28u dWsNCj4gQ2M6IGNjYW1wQGlldGYub3JnOyBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbQ0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KPiAN Cj4gSGkgQWRyaWFuLCANCj4gDQo+IEludGVyZXN0aW5nIHF1ZXN0aW9ucywgYnV0IEkgdGhpbmsg d2UgbmVlZCB0byBjb25zaWRlciB0aGUgYmlnZ2VyIA0KPiBwaWN0dXJlIGZpcnN0LiAgQSBmZXcg cXVpY2sgdGhvdWdodHM6IA0KPiANCj4gT25lIG1vdGl2YXRpb24gZm9yIHRoZSBmbGV4aS1ncmlk IGlzIHRvIHN1cHBvcnQgdGhlIG5leHQgZ2VuZXJhdGlvbiANCj4gb3B0aWNhbCBzaWduYWxzICg+ MTAwR2IvcykgdGhhdCBjYW5ub3QgYmUgZWZmaWNpZW50bHkgYWNjb21tb2RhdGVkIA0KPiB3aXRo IHRoZSBjdXJyZW50IGZpeGVkIGdyaWQuICBIb3dldmVyLCB3ZSBjYW4gZXhwZWN0IHRvIHNlZSBm bGV4aS0NCj4gZ3JpZCBkZXBsb3llZCBiZWZvcmUgdGhlc2UgaGlnaGVyIGJpdCByYXRlIHN5c3Rl bXMuIA0KPiANCj4gVGhlIGN1cnJlbnQgZml4ZWQgZ3JpZCBwcm92aWRlcyBhbiBpbXBsaWNpdCBn dWFyZCBiYW5kIGJldHdlZW4gDQo+IG9wdGljYWwgY2hhbm5lbHMgKGFuZCBzbG90cyBjYW4gYmUg bGVmdCB1bnVzZWQgdG8gYWxsb3cgYSBncmVhdGVyIA0KPiBndWFyZCBiYW5kKS4gIFdpdGggZmxl eGktZ3JpZCB3ZSB3aWxsIHByb2JhYmx5IG5lZWQgdG8gc3BlY2lmeSB0aGUgDQo+IGd1YXJkIGJh bmQuICBUaGUgZ3VhcmQgYmFuZCB3aWxsIHByb2JhYmx5IG5lZWQgdG8gZGVmaW5lZCBieSBhIFBD RSANCj4gYXBwbGljYXRpb24gYnV0IHdlIHdpbGwgbmVlZCB0byBkZWZpbmUgdGhlIHBhcmFtZXRl cnMuIA0KPiANCj4gR2l2ZW4gdGhhdCB0cmFuc2l0aW5nIGFuIE9BRE0gbmFycm93cyB0aGUgb3B0 aWNhbCBiYW5kd2lkdGggaXQgbWF5IA0KPiBiZSBwb3NzaWJsZSB0byBvcHRpbWl6ZSB0aGUgbmV0 d29yayBieSBhZGp1c3RpbmcgdGhlIHJlcXVlc3RlZCANCj4gYmFuZHdpZHRoIGJhc2VkIG9uIHRo ZSBudW1iZXIgb2YgT0FETXMgaW4gdGhlIHBhdGguICBIb3cgd291bGQgd2UgDQo+ICJyZXRhaW4i IHRoaXMgaW5mb3JtYXRpb24gdG8gc3VwcG9ydCByZXN0b3JhdGlvbi4gDQo+IA0KPiBJIGV4cGVj dCB0aGF0IHdlIHdpbGwgaGF2ZSBhIGNvbmNhdGVuYXRpb24gb2YgZmxleGktZ3JpZCBhbmQgZml4 ZWQgDQo+IGdyaWQgbGlua3MgKG1hbmFnZWQgdmlhIGEgUENFKSBpbiB0aGUgbmV0d29yay4gIEhv dyB3aWxsIHdlIHNpZ25hbCANCj4gZm9yIGV4YW1wbGUgZm9yIGEgc2xvdCB0byBjYXJyeSAxMEdi L3Mgc2lnbmFsIGFjcm9zcyBhIG5ldHdvcmsgdGhhdCANCj4gaW5jbHVkZXMgdGhlIGNvbmNhdGVu YXRpb24gb2YgZml4ZWQgZ3JpZCBhbmQgZmxleGktZ3JpZCBzZWdtZW50cy4gDQo+IFRoZSBpbXBs aWNhdGlvbiBvZiByb3V0aW5nIChSV0EpIG1heSBhbHNvIGJlIGludGVyZXN0aW5nLiANCj4gDQo+ IFRoZSBmbGV4aS1ncmlkIHdpbGwgcmVzdWx0IGluIGJhbmR3aWR0aCBmcmFnbWVudGF0aW9uIGFz IHRyYWZmaWMgaXMgDQo+IGFkZGVkIGFuZCByZW1vdmVkIGZyb20gbGlua3MuICBXZSBuZWVkIHRv IGNvbnNpZGVyIHRoZSBuZWVkIHRvIA0KPiBkZWZyYWdtZW50IHRoZSBsaW5rLiANCj4gDQo+IEkg dGhpbmsgdGhhdCB0aGUgaW1wbGljYXRpb25zIG9mIGZsZXhpLWdyaWQgZ28gYmV5b25kIHNpZ25h bGxpbmcgDQo+IGludG8gcm91dGluZyAoUldBKS4gDQo+IA0KPiBUaGUgU0cgMTUgd2lsbCBiZSBt ZWV0aW5nIGluIERlY2VtYmVyIGFuZCB3aWxsIGhvbGQgZGlzY3Vzc2lvbiBvbiANCj4gdGhlIHVz ZSBvZiB0aGUgZmxleGktZ3JpZC4gIEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwcm92aWRlLCBlaXRo ZXIgDQo+IGZvcm1hbGx5IG9yIGluZm9ybWFsbHkgYSBzZXQgb2YgcXVlc3Rpb25zLiANCj4gDQo+ IFJlZ2FyZHMsIA0KPiANCj4gTWFsY29sbSANCj4gDQoNCj4gDQo+ICJBZHJpYW4gRmFycmVsIiA8 YWRyaWFuQG9sZGRvZy5jby51az4gDQo+IFNlbnQgYnk6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcg DQo+IDEyLzExLzIwMTEgMDU6MjkgUE0gDQo+IA0KPiBQbGVhc2UgcmVzcG9uZCB0bw0KPiBhZHJp YW5Ab2xkZG9nLmNvLnVrDQo+IA0KPiBUbw0KPiANCj4gPGNjYW1wQGlldGYub3JnPiANCj4gDQo+ IGNjDQo+IA0KPiBTdWJqZWN0DQo+IA0KPiBbQ0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhp LWdyaWQgaXNzdWUgMQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBIaSwNCj4gDQo+IEkgd2Fu dGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNhbiBwcmltZSB0aGUgZGlzY3Vzc2lvbnMgb2YgZmxleGkt Z3JpZCANCmxhYmVscyBpbg0KPiBhZHZhbmNlIG9mIHRoZSBXRyBtZWV0aW5ncyB0aGlzIHdlZWsu DQo+IA0KPiBJdCBsb29rcyBsaWtlIHdlIGhhdmUgc3VjY2Vzc2Z1bGx5IGFncmVlZCB0aGF0IHRo ZXJlIGFyZSB0d28gc2lnbmlmaWNhbnQNCj4gZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgbGFiZWwg Zm9ybWF0cyBkZWZpbmVkIGluDQo+IA0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC1sYW1iZGEtbGFiZWwNCj4gYW5kIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctY2NhbXAtZmxleGlibGUtZ3Jp ZC0NCj4gcnN2cC10ZS1leHQNCj4gDQo+IFRoZSBmaXJzdCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5 IG1pbm9yOg0KPiANCj4gU2hvdWxkIHdlIHVzZSBhIG5ldyB2YWx1ZSBmb3IgdGhlIEdyaWQgZmll bGQgb3Igc2hvdWxkIHdlIGNvbnRpbnVlIHRvIA0KdXNlIHRoZQ0KPiB2YWx1ZSB0aGF0IGluZGlj YXRlcyBEV0RNLg0KPiANCj4gSW4gZmF2b3Igb2YgY29udGludWluZyB0byB1c2UgdGhlIERXRE0g dmFsdWUgaXMgdGhlIGZhY3QgdGhhdCB0aGUgDQo+IElUVS1UIGhhcyBub3QNCj4gZGVmaW5lZCBh IG5ldyBncmlkIGZvciBmbGV4aWJsZSB3YXZlbGVuZ3RoIGFzc2lnbm1lbnRzLiBJbiBmYWN0LCAN CnRoZUlUVS1UIHNheXMNCj4gdGhhdCBmbGV4aWJsZSBhc3NpZ25tZW50cyBzaG91bGQgYmUgbWFk ZSBmcm9tIHRoZSBEV0RNIGdyaWQuDQo+IA0KPiBPbiB0aGUgb3RoZXIgaGFuZCB3ZSBuZWVkIHRv IHVuZGVyc3RhbmQgdGhhdCB0aGUgZmllbGRzIGluIEdNUExTIG9iamVjdHMgDQpleGlzdA0KPiB0 byBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llciBhbmQgdG8gY29udmV5IGluZm9ybWF0aW9uLiBU aGVyZSBpcyBub25lZWQgDQpmb3IgYQ0KPiBkaXJlY3QgbWFwcGluZyB0byBJVFUtVCBncmlkcy4N Cj4gDQo+IFRodXMsIHdoZW4gZHJhZnQtemhhbmcgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MSAoSVRV LVQgRFdETSkgaXQgaXMgY29ycmVjdCANCnRoYXQNCj4gdGhlIGZsZXhpYmxlIGdyaWQgd2F2ZWxl bmd0aHMgd2lsbCBiZSBzdWdnZXN0ZWQgZnJvbSB0aGUgSVRVLVQgRFdETSANCj4gZ3JpZCwgYnV0 IGl0DQo+IGlzIG5vdCBiZWluZyBhcyBoZWxwZnVsIGFzIGl0IGNvdWxkIGJlLg0KPiANCj4gV2hl biBkcmFmdC1mYXJya2luZ2VsIHN1Z2dlc3RzIHVzaW5nIEdyaWQ9PTMgKElUVS1UIEZsZXgpIGl0 IGlzIG5vdCANCmltcGx5aW5nDQo+IHRoYXQgdGhlcmUgaXMgYSBuZXcgYW5kIGRpZmZlcmVudCBn cmlkIGRlZmluZWQgYnkgdGhlIElUVS1ULiBXaGF0IGl0aXMgDQpzYXlpbmcNCj4gaXMgdGhhdCB0 aGUgbGFiZWwgaXMgYSBmbGV4aS1ncmlkIGxhYmVsIHNlbGVjdGVkIGZyb20gdGhlIGdyaWQgZGVm aW5lZCANCmJ5IHRoZQ0KPiBJVFUtVCBmb3IgdGhhdCBwdXJwb3NlIChpLmUuLCB0aGUgRFdETSBn cmlkKS4NCj4gDQo+IFBlcnNvbmFsbHksIGkgZG9uJ3Qgc2VlIHRoaXMgYXMgYSB2ZXJ5IGxhcmdl IGlzc3VlLiANCmRyYWZ0LWZhcnJraW5nZWx3b3VsZCB3b3JrDQo+IGp1c3QgYXMgd2VsbCBpZiB3 ZSBkZWNpZGUgdG8gdXNlIEdyaWQ9PTEuIGhvd2V2ZXIsIEkgdGhpbmsgaXQgaXMgDQo+IG1hcmdp bmFsbHkgbW9yZQ0KPiBoZWxwZnVsIGFuZCB1c2VmdWwgdG8gYmUgYWJsZSB0byByZWNvZ25pc2Ug dGhlIGRpZmZlcmVudCBsYWJlbCB1c2UgDQo+IGNhc2VzIChmaXhlZA0KPiBncmlkIC8gZmxleGli bGUgZ3JpZCkgYnkgbG9va2luZyBhdCBhIGZpZWxkIGVhcmx5IGluIHRoZSBMYWJlbCBvYmplY3Qu DQo+IENvbnZlcnNlbHksIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGRyYWZ0LXpoYW5nIHdvdWxkIGJl IGJyb2tlbiBieSB1c2luZyANCkdyaWQ9PTMuDQo+IA0KPiBTbyBteSBjb21wcm9taXNlIHByb3Bv c2FsIGlzIHRoYXQgYm90aCBJLURzIHVzZSBHcmlkPT0zLiBUaGVuIHdlIGNhbg0KPiBjb25jZW50 cmF0ZQ0KPiBvbiB0aGUgbW9yZSBzaWduaWZpY2FudCBzZWNvbmQgaXNzdWUgKHNlZSBzZXBhcmF0 ZSBlbWFpbCkuDQo+IA0KPiBXaGF0IGRvIGZvbGsgdGhpbms/DQo+IA0KPiBDaGVlcnMsDQo+IEFk cmlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1Q QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAN Cg0K --=_alternative 0011913B48257948_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+SGkgSWZ0 ZWtoYXI6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9 InNhbnMtc2VyaWYiPlBsZWFzZSBzZWUgYmVsb3cuPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDExLTExLTE0IDEwOjQ4OjM4Ojxicj4NCjxicj4NCiZndDsg SGkgTWFsY29sbSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEFncmVlZCB3aXRoIHlvdXIg b2JzZXJ2YXRpb24gYWJvdXQgZnJhZ21lbnRhdGlvbg0KaW4gZmxleGlibGUgZ3JpZC4gPGJyPg0K Jmd0OyBCVFcsIHRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBuZWVkIHRvIGNvbnNp ZGVyIGZsZXhpYmxlIDxicj4NCiZndDsgYXBwcm9hY2ggZm9yIGxhYmVsIGRlZmluaXRpb24gdGhh dCBhbGxvd3MgZGVmcmFnbWVudGF0aW9uIChlLmcuLCBzZWU8YnI+DQomZ3Q7IHNwbGl0LXNwZWN0 cnVtICZuYnNwO3N1cGVyLWNoYW5uZWwgb3B0aW9uIGluICZuYnNwO2h0dHA6Ly90b29scy5pZXRm Ljxicj4NCiZndDsgb3JnL2h0bWwvZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxh YmVsLTAyKS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDAwODA+Jmx0O1lhbyZndDtBY3R1YWxseSwgZnJhZ21lbnRhdGlvbiB3aWxsDQphcHBlYXIgYXMg dHJhZmZpYyBpcyA8YnI+DQogYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gVGhlIHdvcmsg b2YgZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZSBsZWZ0DQp0byBjb21wdXRhdGlvbiBlbnRpdHkg bGlrZSBQQ0UuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4 MD5Ib3dldmVyLCB3aGV0aGVyIHRoZSBzbGljZXMgd2lsbCBiZQ0Kc3dpdGNoZWQgd2l0aCBjb250 aW51b3VzIGZvcm0gaXMgbm90IGNsZWFyLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgUmVnYXJkaW5nIGNvbnNpZGVyYXRpb24gYWJvdXQgZ3VhcmQtYmFuZCwgSSB0aGlu aywNCml0IGNhbiBiZSA8YnI+DQomZ3Q7IGNvbnNpZGVyZWQgYXMgYSBwYXJ0IG9mIHBhdGggY29t cHV0YXRpb24gY29uc3RyYWludCAtIGRvZXMgbm90IDxicj4NCiZndDsgbmVjZXNzYXJpbHkgbmVl ZCB0byBhZHZlcnRpc2UgdGhpcyBhcyBhIHBhcnQgb2Ygcm91dGluZy4gPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwPiZsdDtZYW8mZ3Q7 IEFncmVlLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgUmVnYXJkcyw8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSWZ0ZWtoYXI8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb206IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiBbbWFpbHRv Ok1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbl0NCjxicj4NCiZndDsgU2VudDogU3VuZGF5LCBOb3Zl bWJlciAxMywgMjAxMSA2OjExIFBNPGJyPg0KJmd0OyBUbzogYWRyaWFuQG9sZGRvZy5jby51azxi cj4NCiZndDsgQ2M6IGNjYW1wQGlldGYub3JnOyBjY2FtcC1ib3VuY2VzQGlldGYub3JnPGJyPg0K Jmd0OyBTdWJqZWN0OiBSZTogW0NDQU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1ncmlkIGlz c3VlIDE8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhpIEFkcmlhbiwgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEludGVyZXN0aW5nIHF1ZXN0aW9ucywgYnV0IEkgdGhpbmsgd2UgbmVlZCB0byBj b25zaWRlciB0aGUgYmlnZ2VyDQo8YnI+DQomZ3Q7IHBpY3R1cmUgZmlyc3QuICZuYnNwO0EgZmV3 IHF1aWNrIHRob3VnaHRzOiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT25lIG1vdGl2YXRpb24gZm9y IHRoZSBmbGV4aS1ncmlkIGlzIHRvIHN1cHBvcnQgdGhlIG5leHQgZ2VuZXJhdGlvbg0KPGJyPg0K Jmd0OyBvcHRpY2FsIHNpZ25hbHMgKCZndDsxMDBHYi9zKSB0aGF0IGNhbm5vdCBiZSBlZmZpY2ll bnRseSBhY2NvbW1vZGF0ZWQNCjxicj4NCiZndDsgd2l0aCB0aGUgY3VycmVudCBmaXhlZCBncmlk LiAmbmJzcDtIb3dldmVyLCB3ZSBjYW4gZXhwZWN0IHRvIHNlZSBmbGV4aS08YnI+DQomZ3Q7IGdy aWQgZGVwbG95ZWQgYmVmb3JlIHRoZXNlIGhpZ2hlciBiaXQgcmF0ZSBzeXN0ZW1zLiA8YnI+DQom Z3Q7IDxicj4NCiZndDsgVGhlIGN1cnJlbnQgZml4ZWQgZ3JpZCBwcm92aWRlcyBhbiBpbXBsaWNp dCBndWFyZCBiYW5kIGJldHdlZW4gPGJyPg0KJmd0OyBvcHRpY2FsIGNoYW5uZWxzIChhbmQgc2xv dHMgY2FuIGJlIGxlZnQgdW51c2VkIHRvIGFsbG93IGEgZ3JlYXRlcg0KPGJyPg0KJmd0OyBndWFy ZCBiYW5kKS4gJm5ic3A7V2l0aCBmbGV4aS1ncmlkIHdlIHdpbGwgcHJvYmFibHkgbmVlZCB0byBz cGVjaWZ5DQp0aGUgPGJyPg0KJmd0OyBndWFyZCBiYW5kLiAmbmJzcDtUaGUgZ3VhcmQgYmFuZCB3 aWxsIHByb2JhYmx5IG5lZWQgdG8gZGVmaW5lZCBieQ0KYSBQQ0UgPGJyPg0KJmd0OyBhcHBsaWNh dGlvbiBidXQgd2Ugd2lsbCBuZWVkIHRvIGRlZmluZSB0aGUgcGFyYW1ldGVycy4gJm5ic3A7IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBHaXZlbiB0aGF0IHRyYW5zaXRpbmcgYW4gT0FETSBuYXJyb3dz IHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdCBtYXkNCjxicj4NCiZndDsgYmUgcG9zc2libGUgdG8g b3B0aW1pemUgdGhlIG5ldHdvcmsgYnkgYWRqdXN0aW5nIHRoZSByZXF1ZXN0ZWQgPGJyPg0KJmd0 OyBiYW5kd2lkdGggYmFzZWQgb24gdGhlIG51bWJlciBvZiBPQURNcyBpbiB0aGUgcGF0aC4gJm5i c3A7SG93IHdvdWxkDQp3ZSA8YnI+DQomZ3Q7ICZxdW90O3JldGFpbiZxdW90OyB0aGlzIGluZm9y bWF0aW9uIHRvIHN1cHBvcnQgcmVzdG9yYXRpb24uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGV4 cGVjdCB0aGF0IHdlIHdpbGwgaGF2ZSBhIGNvbmNhdGVuYXRpb24gb2YgZmxleGktZ3JpZCBhbmQg Zml4ZWQNCjxicj4NCiZndDsgZ3JpZCBsaW5rcyAobWFuYWdlZCB2aWEgYSBQQ0UpIGluIHRoZSBu ZXR3b3JrLiAmbmJzcDtIb3cgd2lsbCB3ZSBzaWduYWwNCjxicj4NCiZndDsgZm9yIGV4YW1wbGUg Zm9yIGEgc2xvdCB0byBjYXJyeSAxMEdiL3Mgc2lnbmFsIGFjcm9zcyBhIG5ldHdvcmsgdGhhdA0K PGJyPg0KJmd0OyBpbmNsdWRlcyB0aGUgY29uY2F0ZW5hdGlvbiBvZiBmaXhlZCBncmlkIGFuZCBm bGV4aS1ncmlkIHNlZ21lbnRzLg0KJm5ic3A7PGJyPg0KJmd0OyBUaGUgaW1wbGljYXRpb24gb2Yg cm91dGluZyAoUldBKSBtYXkgYWxzbyBiZSBpbnRlcmVzdGluZy4gPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFRoZSBmbGV4aS1ncmlkIHdpbGwgcmVzdWx0IGluIGJhbmR3aWR0aCBmcmFnbWVudGF0aW9u IGFzIHRyYWZmaWMgaXMNCjxicj4NCiZndDsgYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4g Jm5ic3A7V2UgbmVlZCB0byBjb25zaWRlciB0aGUgbmVlZCB0bw0KPGJyPg0KJmd0OyBkZWZyYWdt ZW50IHRoZSBsaW5rLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGF0IHRoZSBpbXBs aWNhdGlvbnMgb2YgZmxleGktZ3JpZCBnbyBiZXlvbmQgc2lnbmFsbGluZyA8YnI+DQomZ3Q7IGlu dG8gcm91dGluZyAoUldBKS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBTRyAxNSB3aWxsIGJl IG1lZXRpbmcgaW4gRGVjZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uIG9uDQo8YnI+DQom Z3Q7IHRoZSB1c2Ugb2YgdGhlIGZsZXhpLWdyaWQuICZuYnNwO0l0IHdvdWxkIGJlIHVzZWZ1bCB0 byBwcm92aWRlLCBlaXRoZXINCjxicj4NCiZndDsgZm9ybWFsbHkgb3IgaW5mb3JtYWxseSBhIHNl dCBvZiBxdWVzdGlvbnMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLCA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgTWFsY29sbSA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsg Jmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7IDxicj4NCiZndDsgU2VudCBieTogY2NhbXAtYm91 bmNlc0BpZXRmLm9yZyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMTIv MTEvMjAxMSAwNToyOSBQTSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyBQbGVhc2UgcmVzcG9uZCB0bzxicj4NCiZndDsgYWRyaWFuQG9sZGRvZy5jby51 azwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFRvPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJmx0O2NjYW1w QGlldGYub3JnJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBjYzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IFN1YmplY3Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K Jmd0OyBbQ0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMTwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdhbnRlZCB0byBz ZWUgd2hldGhlciB3ZSBjYW4gcHJpbWUgdGhlIGRpc2N1c3Npb25zIG9mIGZsZXhpLWdyaWQNCmxh YmVscyBpbjxicj4NCiZndDsgYWR2YW5jZSBvZiB0aGUgV0cgbWVldGluZ3MgdGhpcyB3ZWVrLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBJdCBsb29rcyBsaWtlIHdlIGhhdmUgc3VjY2Vzc2Z1bGx5IGFn cmVlZCB0aGF0IHRoZXJlIGFyZSB0d28gc2lnbmlmaWNhbnQ8YnI+DQomZ3Q7IGRpZmZlcmVuY2Vz IGJldHdlZW4gdGhlIGxhYmVsIGZvcm1hdHMgZGVmaW5lZCBpbjxicj4NCiZndDsgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC1s YW1iZGEtbGFiZWw8YnI+DQomZ3Q7IGFuZCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpoYW5nLWNjYW1wLWZsZXhpYmxlLWdyaWQtPGJyPg0KJmd0OyByc3ZwLXRlLWV4dDxi cj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZmlyc3QgcG9pbnQgc2VlbXMgcmVsYXRpdmVseSBtaW5v cjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgU2hvdWxkIHdlIHVzZSBhIG5ldyB2YWx1ZSBmb3IgdGhl IEdyaWQgZmllbGQgb3Igc2hvdWxkIHdlIGNvbnRpbnVlDQp0byB1c2UgdGhlPGJyPg0KJmd0OyB2 YWx1ZSB0aGF0IGluZGljYXRlcyBEV0RNLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJbiBmYXZvciBv ZiBjb250aW51aW5nIHRvIHVzZSB0aGUgRFdETSB2YWx1ZSBpcyB0aGUgZmFjdCB0aGF0IHRoZQ0K PGJyPg0KJmd0OyBJVFUtVCBoYXMgbm90PGJyPg0KJmd0OyBkZWZpbmVkIGEgbmV3IGdyaWQgZm9y IGZsZXhpYmxlIHdhdmVsZW5ndGggYXNzaWdubWVudHMuIEluIGZhY3QsIHRoZUlUVS1UDQpzYXlz PGJyPg0KJmd0OyB0aGF0IGZsZXhpYmxlIGFzc2lnbm1lbnRzIHNob3VsZCBiZSBtYWRlIGZyb20g dGhlIERXRE0gZ3JpZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gdGhlIG90aGVyIGhhbmQgd2Ug bmVlZCB0byB1bmRlcnN0YW5kIHRoYXQgdGhlIGZpZWxkcyBpbiBHTVBMUyBvYmplY3RzDQpleGlz dDxicj4NCiZndDsgdG8gbWFrZSBpbXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5kIHRvIGNvbnZleSBp bmZvcm1hdGlvbi4gVGhlcmUgaXMNCm5vbmVlZCBmb3IgYTxicj4NCiZndDsgZGlyZWN0IG1hcHBp bmcgdG8gSVRVLVQgZ3JpZHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRodXMsIHdoZW4gZHJhZnQt emhhbmcgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MSAoSVRVLVQgRFdETSkgaXQgaXMgY29ycmVjdA0K dGhhdDxicj4NCiZndDsgdGhlIGZsZXhpYmxlIGdyaWQgd2F2ZWxlbmd0aHMgd2lsbCBiZSBzdWdn ZXN0ZWQgZnJvbSB0aGUgSVRVLVQgRFdETQ0KPGJyPg0KJmd0OyBncmlkLCBidXQgaXQ8YnI+DQom Z3Q7IGlzIG5vdCBiZWluZyBhcyBoZWxwZnVsIGFzIGl0IGNvdWxkIGJlLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBXaGVuIGRyYWZ0LWZhcnJraW5nZWwgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MyAoSVRV LVQgRmxleCkgaXQgaXMgbm90DQppbXBseWluZzxicj4NCiZndDsgdGhhdCB0aGVyZSBpcyBhIG5l dyBhbmQgZGlmZmVyZW50IGdyaWQgZGVmaW5lZCBieSB0aGUgSVRVLVQuIFdoYXQNCml0aXMgc2F5 aW5nPGJyPg0KJmd0OyBpcyB0aGF0IHRoZSBsYWJlbCBpcyBhIGZsZXhpLWdyaWQgbGFiZWwgc2Vs ZWN0ZWQgZnJvbSB0aGUgZ3JpZCBkZWZpbmVkDQpieSB0aGU8YnI+DQomZ3Q7IElUVS1UIGZvciB0 aGF0IHB1cnBvc2UgKGkuZS4sIHRoZSBEV0RNIGdyaWQpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBQ ZXJzb25hbGx5LCBpIGRvbid0IHNlZSB0aGlzIGFzIGEgdmVyeSBsYXJnZSBpc3N1ZS4gZHJhZnQt ZmFycmtpbmdlbHdvdWxkDQp3b3JrPGJyPg0KJmd0OyBqdXN0IGFzIHdlbGwgaWYgd2UgZGVjaWRl IHRvIHVzZSBHcmlkPT0xLiBob3dldmVyLCBJIHRoaW5rIGl0IGlzIDxicj4NCiZndDsgbWFyZ2lu YWxseSBtb3JlPGJyPg0KJmd0OyBoZWxwZnVsIGFuZCB1c2VmdWwgdG8gYmUgYWJsZSB0byByZWNv Z25pc2UgdGhlIGRpZmZlcmVudCBsYWJlbCB1c2UNCjxicj4NCiZndDsgY2FzZXMgKGZpeGVkPGJy Pg0KJmd0OyBncmlkIC8gZmxleGlibGUgZ3JpZCkgYnkgbG9va2luZyBhdCBhIGZpZWxkIGVhcmx5 IGluIHRoZSBMYWJlbCBvYmplY3QuPGJyPg0KJmd0OyBDb252ZXJzZWx5LCBJIGRvbid0IGJlbGll dmUgdGhhdCBkcmFmdC16aGFuZyB3b3VsZCBiZSBicm9rZW4gYnkgdXNpbmcNCkdyaWQ9PTMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFNvIG15IGNvbXByb21pc2UgcHJvcG9zYWwgaXMgdGhhdCBib3Ro IEktRHMgdXNlIEdyaWQ9PTMuIFRoZW4gd2UgY2FuPGJyPg0KJmd0OyBjb25jZW50cmF0ZTxicj4N CiZndDsgb24gdGhlIG1vcmUgc2lnbmlmaWNhbnQgc2Vjb25kIGlzc3VlIChzZWUgc2VwYXJhdGUg ZW1haWwpLjxicj4NCiZndDsgPGJyPg0KJmd0OyBXaGF0IGRvIGZvbGsgdGhpbms/PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IEFkcmlhbjxicj4NCiZndDsgPGJyPg0KJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEND QU1QIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQo8L2ZvbnQ+PC90dD4N Cg== --=_alternative 0011913B48257948_=-- From cyril.margaria@nsn.com Sun Nov 13 19:13:41 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3841F0CB0 for ; Sun, 13 Nov 2011 19:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3FQUSH5t-ee for ; Sun, 13 Nov 2011 19:13:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A67121F0C8E for ; Sun, 13 Nov 2011 19:13:40 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAE3Da7R028513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2011 04:13:36 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAE3DaRB025532; Mon, 14 Nov 2011 04:13:36 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 04:13:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 14 Nov 2011 04:13:33 +0100 Message-ID: In-Reply-To: <03d001cca278$c41f69b0$4c5e3d10$@olddog.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Flexi-grid issue 2 Thread-Index: AQIkh/xTAcc9aMBM1GNnWfiiOKVkqwJZI5CIlOkV9aCAAARQEA== References: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> <03d001cca278$c41f69b0$4c5e3d10$@olddog.co.uk> From: "Margaria, Cyril (NSN - DE/Munich)" To: , "Zhangfatai" , X-OriginalArrivalTime: 14 Nov 2011 03:13:36.0085 (UTC) FILETIME=[65E16850:01CCA27B] Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:13:42 -0000 SGksIA0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IG0gc2hvdWxkIGJlIGluIHRoZSB0cmFmZmljIHBh cmFtZXRlcnMgYmVjYXVzZSBpdCBkZXNjcmliZXMgdGhlIGNhcGFjaXR5Lg0KUmVnYXJkaW5nIHRo ZSBsYWJlbCwgaWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSBSRkM0NjA2IChhbmQgcmVjZW50IE9U TiB3b3JrKSAgdGhlIGxhYmVsIGFsb25lIGlzIG5vdCB0aGUgb25seSANCmluZm9ybWF0aW9uIChh bHNvIHdoZW4gYWRkaW5nIHRoZSBpbnRlcmZhY2UgaW5mb3JtYXRpb24pIGlzIG5vdCBlbm91Z2gs IHRoZSB0cmFmZmljIHBhcmFtZXRlcnMgYXJlIGFsc28gdXNlZC4NCg0KSGF2aW5nIHRoZSAibSIg YWRkaXRpb25hbGx5IGluIHRoZSBsYWJlbCBzZWVtcyBhbHNvIHRvIGJlIGNvbnNpZGVyZWQsIGl0 IHNlZW1zIHBvc3NpYmxlIHRoYXQgdGhlICJtIiBtaWdodCBiZSBpbmZsdWVuY2VkIGJ5IHRoZSBz d2l0Y2hpbmcgZWxlbWVudCBhbmQgY2hhbmdlIGhvcC1ieS1ob3AuDQoNCk15IDIgY2VudHMuDQoN Cg0KQmVzdCByZWdhcmRzIC8gTWl0IGZyZXVuZGxpY2hlbiBHcsO8w59lbg0KQ3lyaWwgTWFyZ2Fy aWENCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g T2YgZXh0IEFkcmlhbiBGYXJyZWwNCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxNCwgMjAxMSAx MDo1NSBBTQ0KPiBUbzogJ1poYW5nZmF0YWknOyBjY2FtcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW0NDQU1QXSBGbGV4aS1ncmlkIGlzc3VlIDINCj4gDQo+IEhpLA0KPiANCj4gSSd2ZSBub3Qg c3BlbnQgYSBsb3Qgb2YgdGltZSBsb29raW5nIGF0IHRoZSB0cmFmZmljIHBhcmFtZXRlcnMsIGJ1 dA0KPiB5ZXMuIEl0IHNlZW1zIHRvIG1lIHRoYXQgcGFydCBvZiByZXF1ZXN0aW5nIHRoZSBMU1Ag Y291bGQgaW5jbHVkZQ0KPiBzcGVjaWZ5aW5nIGEgbnVtYmVyIG9mIHBhcmFtZXRlcnMgcmVsYXRl ZCB0byBjYXBhY2l0eSBhbmQgY29uc3RydWN0aW9uLg0KPiBUaGF0IHdvdWxkIG1lYW4gdGhhdCAi bSIgbWlnaHQgcmVhc29uYWJseSBiZSBpbiB0aGUgdHJhZmZpYyBwYXJhbWV0ZXJzDQo+IChvciBt YXliZSB0aGVyZSB3b3VsZCBiZSBhIGNob2ljZSBvZiB2YWx1ZXMgb2YgbSkgYW5kIHRoZSBmaW5h bCBjaG9zZW4NCj4gdmFsdWUgb2YgbSB3b3VsZCB0aGVuIGJlIHBsYWNlZCBpbiB0aGUgbGFiZWwu DQo+IA0KPiBZb3UgYXJlLCBvZiBjb3Vyc2UsIHJpZ2h0IHRoYXQgaXNzdWVzIGxpa2UgaW50ZXJm YWNlIElEIGFuZCBjb21wb25lbnQNCj4gaW50ZXJmYWNlIElEIGFyZSBhbHNvIG5lY2Vzc2FyeSBm b3IgWEMgcHJvZ3JhbW1pbmcuDQo+IA0KPiBBDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNv bV0NCj4gPiBTZW50OiAxNCBOb3ZlbWJlciAyMDExIDAyOjIwDQo+ID4gVG86IGFkcmlhbkBvbGRk b2cuY28udWs7IGNjYW1wQGlldGYub3JnDQo+ID4gU3ViamVjdDog562U5aSNOiBbQ0NBTVBdIEZs ZXhpLWdyaWQgaXNzdWUgMg0KPiA+DQo+ID4gSGkgQWRyaWFuLA0KPiA+DQo+ID4gRG8geW91IGFn cmVlIHRoYXQgIm0iIHNob3VsZCBhbHNvIGJlIHB1dCBpbnRvIFRyYWZmaWMgUGFyYW1ldGVycw0K PiA+IG9iamVjdCwgd2hpY2ggaW5kaWNhdGVzIGhvdyBtdWNoIHJlc291cmNlIHNob3VsZCBiZSBy ZXNlcnZlZCBiZWZvcmUNCj4gd2UNCj4gPiBkZWNpZGUgd2hldGhlcmUgd2Ugc2hvdWxkIHB1dCAi bSIgaW4gdGhlIExhYmVsPw0KPiA+DQo+ID4gVGFsa2luZyBhYm91dCB0aGUgTGFiZWwgZGVmaW5p dGlvbiBmcm9tIFJGQzM0NzEsIHRoZSBMYWJlbCBkZWZpbmVkIGluDQo+ID4gW2RyYWZ0LSB6aGFu Z10gY29udGFpbnMgImVub3VnaCBpbmZvcm1hdGlvbiIgdG8gYWxsb3cgdGhlIHJlY2VpdmluZw0K PiA+IG5vZGUgdG8gcHJvZ3JhbQ0KPiBpdHMNCj4gPiBjcm9zcyBjb25uZWN0LCBpZS4sIG5vdGhp bmcgaXMgbWlzc2VkIGZyb20gbXkgdW5kZXJzdGFuZGluZy4NCj4gPg0KPiA+IFdlIGtub3cgdGhh dCB0aGUgcmVjaXZlaW5nIG5vZGUgY2Fubm90IHByb2dyYW0gaXRzIGNyb3NzIGNvbm5lY3QNCj4g PiBjb3JyZWN0bHkgYnkgdXNpbmcgb25seSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo ZSAiTGFiZWwiLA0KPiA+IGJlY2F1c2UgaXQgYWxzbyBuZWVkcyB0bw0KPiBnZXQNCj4gPiBzb21l IG90aGVyIGluZm9ybWF0aW9uIChlLmcuLCBURSBsaW5rIG9yIGNvbXBvbmVudCBsaW5rIGluZm9y bWF0aW9uKQ0KPiA+IGZyb20NCj4gb3RoZXINCj4gPiBSU1ZQIG9iamVjdHMgc3VjaCBhcyBFUk8g b3IgUlNWUC1IT1AuDQo+ID4NCj4gPiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGhhdmUgYW55IG1p c3VuZGVyc3RhbmRpbmcuDQo+ID4NCj4gPiBGYXRhaQ0KPiA+DQo+ID4gVGhhbmtzDQo+ID4NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiDlj5Hk u7bkuro6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqCBBZHJpYW4NCj4gRmFycmVsDQo+ID4gW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+ID4g5Y+R 6YCB5pe26Ze0OiAyMDEx5bm0MTHmnIgxM+aXpSA5OjM0DQo+ID4g5YiwOiBjY2FtcEBpZXRmLm9y Zw0KPiA+IOS4u+mimDogW0NDQU1QXSBGbGV4aS1ncmlkIGlzc3VlIDINCj4gPg0KPiA+IEhpLA0K PiA+DQo+ID4gU2Vjb25kIGVtYWlsIG9uIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBsYWJl bCBmb3JtYXRzIGRlZmluZWQgaW4NCj4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZhcnJraW5nZWwtY2NhbXAtZmxleGlncmlkLQ0KPiBsYW1iZA0KPiA+IGEtbGFiZWwN Cj4gPiBhbmQNCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1j Y2FtcC1mbGV4aWJsZS1ncmlkLXJzdnAtDQo+IHRlLWV4dA0KPiA+DQo+ID4gVGhpcyBpc3N1ZSBp cyBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhlIGZpcnN0IGlzc3VlLiBUaGlzIHF1ZXN0aW9uDQo+ IGhhcw0KPiA+IHR3bw0KPiA+IHN1Yi1wb2ludHM6DQo+ID4gYS4gd2hlcmUgZG8gd2UgY2Fycnkg dGhlIGZsZXhpLWdyaWQgbSBwYXJhbWV0ZXI/DQo+ID4gYi4gd2hlcmUgZG8gd2UgY2FycnkgdHJh ZmZpYyBwYXJhbWV0ZXJzIGZvciBmbGV4aS1ncmlkPw0KPiA+DQo+ID4gZHJhZnQtemhhbmcgaXMg YSBtb3JlIGNvbXByZWhlbnNpdmUgZG9jdW1lbnQgdGhhdCBkcmFmdC1mYXJya2luZ2VsDQo+ID4g YmVjYXVzZSBpdCBhaW1zIHRvIGNvdmVyIGEgbnVtYmVyIG9mIHNpZ25pZmljYW50IHNpZ25hbGlu ZyBwYXJhbWV0ZXJzDQo+IGZvciBSU1ZQLVRFLg0KPiA+IGRyYWZ0LWZhcnJraW5nZWwgb25seSBh dHRlbXB0cyB0byBkZWZpbmUgYSBsYWJlbCBzdHJ1Y3R1cmUuDQo+ID4NCj4gPiBUaHVzLCB0aGUg cXVlc3Rpb24gd2UgbmVlZCB0byByZXNvbHZlIGlzIG5vdCB3aGVyZSB0byBjYXJyeSB0aGUNCj4g PiB0cmFmZmljIHBhcmFtZXRlcnMgZm9yIGZsZXhpLWdyaWQsIGJ1dCB3aGF0IGNvbnN0aXR1dGVz IGEgbGFiZWwgaW4NCj4gZmxleGktZ3JpZD8NCj4gPg0KPiA+IE1heWJlIHdlIHNob3VsZCBzdGFy dCB0aGlzIHdpdGggdGhlIHF1ZXN0aW9uOiB3aGF0IGlzIGEgbGFiZWw/IFJGQw0KPiAzNDcxIHNh eXM6DQo+ID4NCj4gPiAgICBBIGdlbmVyYWxpemVkIGxhYmVsIGNvbnRhaW5zIGVub3VnaCBpbmZv cm1hdGlvbiB0byBhbGxvdyB0aGUNCj4gcmVjZWl2aW5nDQo+ID4gICAgbm9kZSB0byBwcm9ncmFt IGl0cyBjcm9zcyBjb25uZWN0LCByZWdhcmRsZXNzIG9mIHRoZSB0eXBlIG9mIHRoaXMNCj4gPiAg ICBjcm9zcyBjb25uZWN0LCBzdWNoIHRoYXQgdGhlIGluZ3Jlc3Mgc2VnbWVudHMgb2YgdGhlIHBh dGggYXJlDQo+ID4gICAgcHJvcGVybHkgam9pbmVkLg0KPiA+DQo+ID4gU28sIHdoYXQgaW5mb3Jt YXRpb24gZG8gd2UgbmVlZCB0byBjYXJyeSBpbiBhIGxhYmVsIHRvIHNhdGlzZnkgdGhhdD8NCj4g SQ0KPiA+IHRoaW5rDQo+IGl0DQo+ID4gaXMgYSBmdWxsIGRlc2NyaXB0aW9uIG9mIHRoZSBjaGFu bmVsLCBhbmQgQUZBSUNTIGZvciBmbGV4aS1ncmlkIHRoaXMNCj4gPiBpbmNsdWRlcyB0aGUgbSBw YXJhbWV0ZXIuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gQWRyaWFuDQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IENDQU1QIG1haWxp bmcgbGlzdA0KPiA+IENDQU1QQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== From li.yao3@zte.com.cn Sun Nov 13 19:21:07 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F191F0C5F; Sun, 13 Nov 2011 19:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn-maR4mTHdB; Sun, 13 Nov 2011 19:21:06 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 897261F0C47; Sun, 13 Nov 2011 19:21:00 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131461793122; Mon, 14 Nov 2011 11:16:18 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 20387.3792047829; Mon, 14 Nov 2011 11:20:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAE3KohT012892; Mon, 14 Nov 2011 11:20:50 +0800 (GMT-8) (envelope-from li.yao3@zte.com.cn) In-Reply-To: To: li.yao3@zte.com.cn MIME-Version: 1.0 X-KeepSent: 235A7B15:C11763D5-48257948:00125174; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.yao3@zte.com.cn Date: Mon, 14 Nov 2011 11:22:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-14 11:20:52, Serialize complete at 2011-11-14 11:20:52 Content-Type: multipart/alternative; boundary="=_alternative 0012655148257948_=" X-MAIL: mse02.zte.com.cn pAE3KohT012892 Cc: Abinder Dhillon , "ccamp@ietf.org" , Iftekhar Hussain , "ccamp-bounces@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6IFJlOiAgVHJ5aW5nIHRvIHJlc29s?= =?gb2312?b?dmUgZmxleGktZ3JpZCBpc3N1ZSAx?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:21:07 -0000 This is a multipart message in MIME format. --=_alternative 0012655148257948_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQUxMOg0KDQpDb3JyZWN0IG15IG1pc3Rha2UuIndoZXRoZXIgdGhlIHNsaWNlcyB3aWxsIGJl IHN3aXRjaGVkIHdpdGggY29udGludW91cyANCmZvcm0gaXMgbm90IGNsZWFyLiIgc2hvdWxkIGJl IA0KIndoZXRoZXIgdGhlIHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGggdW5jb250aW51b3Vz IGZvcm0gaXMgbm90IGNsZWFyLiINCg0KY2NhbXAtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEt MTEtMTQgMTE6MTM6MDQ6DQoNCj4gDQo+IEhpIElmdGVraGFyOiANCj4gDQo+IFBsZWFzZSBzZWUg YmVsb3cuIA0KPiANCj4gY2NhbXAtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEtMTEtMTQgMTA6 NDg6Mzg6DQo+IA0KPiA+IEhpIE1hbGNvbG0sIA0KPiA+IA0KPiA+IEFncmVlZCB3aXRoIHlvdXIg b2JzZXJ2YXRpb24gYWJvdXQgZnJhZ21lbnRhdGlvbiBpbiBmbGV4aWJsZSBncmlkLiANCj4gPiBC VFcsIHRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBuZWVkIHRvIGNvbnNpZGVyIGZs ZXhpYmxlIA0KPiA+IGFwcHJvYWNoIGZvciBsYWJlbCBkZWZpbml0aW9uIHRoYXQgYWxsb3dzIGRl ZnJhZ21lbnRhdGlvbiAoZS5nLiwgc2VlDQo+ID4gc3BsaXQtc3BlY3RydW0gIHN1cGVyLWNoYW5u ZWwgb3B0aW9uIGluICBodHRwOi8vdG9vbHMuaWV0Zi4NCj4gPiBvcmcvaHRtbC9kcmFmdC1odXNz YWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwtMDIpLiANCj4gDQo+IDxZYW8+QWN0dWFsbHks IGZyYWdtZW50YXRpb24gd2lsbCBhcHBlYXIgYXMgdHJhZmZpYyBpcyANCj4gYWRkZWQgYW5kIHJl bW92ZWQgZnJvbSBsaW5rcy4gVGhlIHdvcmsgb2YgZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZSAN Cj4gbGVmdCB0byBjb21wdXRhdGlvbiBlbnRpdHkgbGlrZSBQQ0UuIA0KPiBIb3dldmVyLCB3aGV0 aGVyIHRoZSBzbGljZXMgd2lsbCBiZSBzd2l0Y2hlZCB3aXRoIGNvbnRpbnVvdXMgZm9ybSBpc25v dCANCmNsZWFyLg0KPiANCj4gDQo+ID4gDQo+ID4gUmVnYXJkaW5nIGNvbnNpZGVyYXRpb24gYWJv dXQgZ3VhcmQtYmFuZCwgSSB0aGluaywgaXQgY2FuIGJlIA0KPiA+IGNvbnNpZGVyZWQgYXMgYSBw YXJ0IG9mIHBhdGggY29tcHV0YXRpb24gY29uc3RyYWludCAtIGRvZXMgbm90IA0KPiA+IG5lY2Vz c2FyaWx5IG5lZWQgdG8gYWR2ZXJ0aXNlIHRoaXMgYXMgYSBwYXJ0IG9mIHJvdXRpbmcuIA0KPiAN Cj4gDQo+IDxZYW8+IEFncmVlLiANCj4gDQo+IA0KPiA+IA0KPiA+IFJlZ2FyZHMsIA0KPiA+IElm dGVraGFyIA0KPiA+IA0KPiA+IEZyb206IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiBbbWFpbHRv Ok1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbl0gDQo+ID4gU2VudDogU3VuZGF5LCBOb3ZlbWJlciAx MywgMjAxMSA2OjExIFBNDQo+ID4gVG86IGFkcmlhbkBvbGRkb2cuY28udWsNCj4gPiBDYzogY2Nh bXBAaWV0Zi5vcmc7IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0ND QU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDEgDQo+ID4gDQo+ID4gSGkg QWRyaWFuLCANCj4gPiANCj4gPiBJbnRlcmVzdGluZyBxdWVzdGlvbnMsIGJ1dCBJIHRoaW5rIHdl IG5lZWQgdG8gY29uc2lkZXIgdGhlIGJpZ2dlciANCj4gPiBwaWN0dXJlIGZpcnN0LiAgQSBmZXcg cXVpY2sgdGhvdWdodHM6IA0KPiA+IA0KPiA+IE9uZSBtb3RpdmF0aW9uIGZvciB0aGUgZmxleGkt Z3JpZCBpcyB0byBzdXBwb3J0IHRoZSBuZXh0IGdlbmVyYXRpb24gDQo+ID4gb3B0aWNhbCBzaWdu YWxzICg+MTAwR2IvcykgdGhhdCBjYW5ub3QgYmUgZWZmaWNpZW50bHkgYWNjb21tb2RhdGVkIA0K PiA+IHdpdGggdGhlIGN1cnJlbnQgZml4ZWQgZ3JpZC4gIEhvd2V2ZXIsIHdlIGNhbiBleHBlY3Qg dG8gc2VlIGZsZXhpLQ0KPiA+IGdyaWQgZGVwbG95ZWQgYmVmb3JlIHRoZXNlIGhpZ2hlciBiaXQg cmF0ZSBzeXN0ZW1zLiANCj4gPiANCj4gPiBUaGUgY3VycmVudCBmaXhlZCBncmlkIHByb3ZpZGVz IGFuIGltcGxpY2l0IGd1YXJkIGJhbmQgYmV0d2VlbiANCj4gPiBvcHRpY2FsIGNoYW5uZWxzIChh bmQgc2xvdHMgY2FuIGJlIGxlZnQgdW51c2VkIHRvIGFsbG93IGEgZ3JlYXRlciANCj4gPiBndWFy ZCBiYW5kKS4gIFdpdGggZmxleGktZ3JpZCB3ZSB3aWxsIHByb2JhYmx5IG5lZWQgdG8gc3BlY2lm eSB0aGUgDQo+ID4gZ3VhcmQgYmFuZC4gIFRoZSBndWFyZCBiYW5kIHdpbGwgcHJvYmFibHkgbmVl ZCB0byBkZWZpbmVkIGJ5IGEgUENFIA0KPiA+IGFwcGxpY2F0aW9uIGJ1dCB3ZSB3aWxsIG5lZWQg dG8gZGVmaW5lIHRoZSBwYXJhbWV0ZXJzLiANCj4gPiANCj4gPiBHaXZlbiB0aGF0IHRyYW5zaXRp bmcgYW4gT0FETSBuYXJyb3dzIHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdCBtYXkgDQo+ID4gYmUg cG9zc2libGUgdG8gb3B0aW1pemUgdGhlIG5ldHdvcmsgYnkgYWRqdXN0aW5nIHRoZSByZXF1ZXN0 ZWQgDQo+ID4gYmFuZHdpZHRoIGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgT0FETXMgaW4gdGhlIHBh dGguICBIb3cgd291bGQgd2UgDQo+ID4gInJldGFpbiIgdGhpcyBpbmZvcm1hdGlvbiB0byBzdXBw b3J0IHJlc3RvcmF0aW9uLiANCj4gPiANCj4gPiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgaGF2ZSBh IGNvbmNhdGVuYXRpb24gb2YgZmxleGktZ3JpZCBhbmQgZml4ZWQgDQo+ID4gZ3JpZCBsaW5rcyAo bWFuYWdlZCB2aWEgYSBQQ0UpIGluIHRoZSBuZXR3b3JrLiAgSG93IHdpbGwgd2Ugc2lnbmFsIA0K PiA+IGZvciBleGFtcGxlIGZvciBhIHNsb3QgdG8gY2FycnkgMTBHYi9zIHNpZ25hbCBhY3Jvc3Mg YSBuZXR3b3JrIHRoYXQgDQo+ID4gaW5jbHVkZXMgdGhlIGNvbmNhdGVuYXRpb24gb2YgZml4ZWQg Z3JpZCBhbmQgZmxleGktZ3JpZCBzZWdtZW50cy4gDQo+ID4gVGhlIGltcGxpY2F0aW9uIG9mIHJv dXRpbmcgKFJXQSkgbWF5IGFsc28gYmUgaW50ZXJlc3RpbmcuIA0KPiA+IA0KPiA+IFRoZSBmbGV4 aS1ncmlkIHdpbGwgcmVzdWx0IGluIGJhbmR3aWR0aCBmcmFnbWVudGF0aW9uIGFzIHRyYWZmaWMg aXMgDQo+ID4gYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gIFdlIG5lZWQgdG8gY29uc2lk ZXIgdGhlIG5lZWQgdG8gDQo+ID4gZGVmcmFnbWVudCB0aGUgbGluay4gDQo+ID4gDQo+ID4gSSB0 aGluayB0aGF0IHRoZSBpbXBsaWNhdGlvbnMgb2YgZmxleGktZ3JpZCBnbyBiZXlvbmQgc2lnbmFs bGluZyANCj4gPiBpbnRvIHJvdXRpbmcgKFJXQSkuIA0KPiA+IA0KPiA+IFRoZSBTRyAxNSB3aWxs IGJlIG1lZXRpbmcgaW4gRGVjZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uIG9uIA0KPiA+ IHRoZSB1c2Ugb2YgdGhlIGZsZXhpLWdyaWQuICBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlk ZSwgZWl0aGVyIA0KPiA+IGZvcm1hbGx5IG9yIGluZm9ybWFsbHkgYSBzZXQgb2YgcXVlc3Rpb25z LiANCj4gPiANCj4gPiBSZWdhcmRzLCANCj4gPiANCj4gPiBNYWxjb2xtIA0KPiA+IA0KPiANCj4g PiANCj4gPiAiQWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+IA0KPiA+IFNlbnQg Ynk6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgDQo+ID4gMTIvMTEvMjAxMSAwNToyOSBQTSANCj4g PiANCj4gPiBQbGVhc2UgcmVzcG9uZCB0bw0KPiA+IGFkcmlhbkBvbGRkb2cuY28udWsgDQo+ID4g DQo+ID4gVG8gDQo+ID4gDQo+ID4gPGNjYW1wQGlldGYub3JnPiANCj4gPiANCj4gPiBjYyANCj4g PiANCj4gPiBTdWJqZWN0IA0KPiA+IA0KPiA+IFtDQ0FNUF0gVHJ5aW5nIHRvIHJlc29sdmUgZmxl eGktZ3JpZCBpc3N1ZSAxIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ IEhpLA0KPiA+IA0KPiA+IEkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNhbiBwcmltZSB0aGUg ZGlzY3Vzc2lvbnMgb2YgDQpmbGV4aS1ncmlkbGFiZWxzIGluDQo+ID4gYWR2YW5jZSBvZiB0aGUg V0cgbWVldGluZ3MgdGhpcyB3ZWVrLg0KPiA+IA0KPiA+IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBz dWNjZXNzZnVsbHkgYWdyZWVkIHRoYXQgdGhlcmUgYXJlIHR3byANCnNpZ25pZmljYW50DQo+ID4g ZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgbGFiZWwgZm9ybWF0cyBkZWZpbmVkIGluDQo+ID4gaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhp Z3JpZC0NCj4gbGFtYmRhLWxhYmVsDQo+ID4gYW5kIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtemhhbmctY2NhbXAtZmxleGlibGUtZ3JpZC0NCj4gPiByc3ZwLXRlLWV4dA0K PiA+IA0KPiA+IFRoZSBmaXJzdCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5IG1pbm9yOg0KPiA+IA0K PiA+IFNob3VsZCB3ZSB1c2UgYSBuZXcgdmFsdWUgZm9yIHRoZSBHcmlkIGZpZWxkIG9yIHNob3Vs ZCB3ZSBjb250aW51ZXRvIA0KdXNlIHRoZQ0KPiA+IHZhbHVlIHRoYXQgaW5kaWNhdGVzIERXRE0u DQo+ID4gDQo+ID4gSW4gZmF2b3Igb2YgY29udGludWluZyB0byB1c2UgdGhlIERXRE0gdmFsdWUg aXMgdGhlIGZhY3QgdGhhdCB0aGUgDQo+ID4gSVRVLVQgaGFzIG5vdA0KPiA+IGRlZmluZWQgYSBu ZXcgZ3JpZCBmb3IgZmxleGlibGUgd2F2ZWxlbmd0aCBhc3NpZ25tZW50cy4gSW4gZmFjdCwgDQo+ IHRoZUlUVS1UIHNheXMNCj4gPiB0aGF0IGZsZXhpYmxlIGFzc2lnbm1lbnRzIHNob3VsZCBiZSBt YWRlIGZyb20gdGhlIERXRE0gZ3JpZC4NCj4gPiANCj4gPiBPbiB0aGUgb3RoZXIgaGFuZCB3ZSBu ZWVkIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUgZmllbGRzIGluIEdNUExTIA0KPiBvYmplY3RzIGV4 aXN0DQo+ID4gdG8gbWFrZSBpbXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5kIHRvIGNvbnZleSBpbmZv cm1hdGlvbi4gVGhlcmUgaXMgDQo+IG5vbmVlZCBmb3IgYQ0KPiA+IGRpcmVjdCBtYXBwaW5nIHRv IElUVS1UIGdyaWRzLg0KPiA+IA0KPiA+IFRodXMsIHdoZW4gZHJhZnQtemhhbmcgc3VnZ2VzdHMg dXNpbmcgR3JpZD09MSAoSVRVLVQgRFdETSkgaXQgaXMgDQo+IGNvcnJlY3QgdGhhdA0KPiA+IHRo ZSBmbGV4aWJsZSBncmlkIHdhdmVsZW5ndGhzIHdpbGwgYmUgc3VnZ2VzdGVkIGZyb20gdGhlIElU VS1UIERXRE0gDQo+ID4gZ3JpZCwgYnV0IGl0DQo+ID4gaXMgbm90IGJlaW5nIGFzIGhlbHBmdWwg YXMgaXQgY291bGQgYmUuDQo+ID4gDQo+ID4gV2hlbiBkcmFmdC1mYXJya2luZ2VsIHN1Z2dlc3Rz IHVzaW5nIEdyaWQ9PTMgKElUVS1UIEZsZXgpIGl0IGlzIG5vdCANCmltcGx5aW5nDQo+ID4gdGhh dCB0aGVyZSBpcyBhIG5ldyBhbmQgZGlmZmVyZW50IGdyaWQgZGVmaW5lZCBieSB0aGUgSVRVLVQu IFdoYXQgDQo+IGl0aXMgc2F5aW5nDQo+ID4gaXMgdGhhdCB0aGUgbGFiZWwgaXMgYSBmbGV4aS1n cmlkIGxhYmVsIHNlbGVjdGVkIGZyb20gdGhlIGdyaWQgDQo+IGRlZmluZWQgYnkgdGhlDQo+ID4g SVRVLVQgZm9yIHRoYXQgcHVycG9zZSAoaS5lLiwgdGhlIERXRE0gZ3JpZCkuDQo+ID4gDQo+ID4g UGVyc29uYWxseSwgaSBkb24ndCBzZWUgdGhpcyBhcyBhIHZlcnkgbGFyZ2UgaXNzdWUuIGRyYWZ0 LQ0KPiBmYXJya2luZ2Vsd291bGQgd29yaw0KPiA+IGp1c3QgYXMgd2VsbCBpZiB3ZSBkZWNpZGUg dG8gdXNlIEdyaWQ9PTEuIGhvd2V2ZXIsIEkgdGhpbmsgaXQgaXMgDQo+ID4gbWFyZ2luYWxseSBt b3JlDQo+ID4gaGVscGZ1bCBhbmQgdXNlZnVsIHRvIGJlIGFibGUgdG8gcmVjb2duaXNlIHRoZSBk aWZmZXJlbnQgbGFiZWwgdXNlIA0KPiA+IGNhc2VzIChmaXhlZA0KPiA+IGdyaWQgLyBmbGV4aWJs ZSBncmlkKSBieSBsb29raW5nIGF0IGEgZmllbGQgZWFybHkgaW4gdGhlIExhYmVsIG9iamVjdC4N Cj4gPiBDb252ZXJzZWx5LCBJIGRvbid0IGJlbGlldmUgdGhhdCBkcmFmdC16aGFuZyB3b3VsZCBi ZSBicm9rZW4gYnkgDQo+IHVzaW5nIEdyaWQ9PTMuDQo+ID4gDQo+ID4gU28gbXkgY29tcHJvbWlz ZSBwcm9wb3NhbCBpcyB0aGF0IGJvdGggSS1EcyB1c2UgR3JpZD09My4gVGhlbiB3ZSBjYW4NCj4g PiBjb25jZW50cmF0ZQ0KPiA+IG9uIHRoZSBtb3JlIHNpZ25pZmljYW50IHNlY29uZCBpc3N1ZSAo c2VlIHNlcGFyYXRlIGVtYWlsKS4NCj4gPiANCj4gPiBXaGF0IGRvIGZvbGsgdGhpbms/DQo+ID4g DQo+ID4gQ2hlZXJzLA0KPiA+IEFkcmlhbg0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4g Q0NBTVBAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gPiBDQ0FNUEBpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCg0K --=_alternative 0012655148257948_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFMTDo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvcnJlY3QgbXkgbWlzdGFrZS48 L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDt3aGV0aGVyDQp0aGUgc2xpY2VzIHdpbGwgYmUg c3dpdGNoZWQgd2l0aCA8aT5jb250aW51b3VzPC9pPiBmb3JtIGlzIG5vdCBjbGVhci4mcXVvdDsN CnNob3VsZCBiZSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O3doZXRo ZXIgdGhlIHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGggPC9mb250PjwvdHQ+PHR0Pjxmb250 IHNpemU9MiBjb2xvcj0jMDAwMDgwPjxpPnVuY29udGludW91czwvaT48L2ZvbnQ+PC90dD48dHQ+ PGZvbnQgc2l6ZT0yPg0KZm9ybSBpcyBub3QgY2xlYXIuJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5jY2FtcC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMS0x MS0xNCAxMToxMzowNDo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgSWZ0ZWtoYXI6IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugc2VlIGJlbG93LiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgY2NhbXAtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEtMTEtMTQgMTA6NDg6Mzg6PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsgSGkgTWFsY29sbSwgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsgQWdyZWVkIHdpdGggeW91ciBvYnNlcnZhdGlvbiBhYm91dCBmcmFnbWVu dGF0aW9uIGluIGZsZXhpYmxlDQpncmlkLiA8YnI+DQomZ3Q7ICZndDsgQlRXLCB0aGlzIGlzIG9u ZSBvZiB0aGUgcmVhc29ucyB3aHkgd2UgbmVlZCB0byBjb25zaWRlciBmbGV4aWJsZQ0KPGJyPg0K Jmd0OyAmZ3Q7IGFwcHJvYWNoIGZvciBsYWJlbCBkZWZpbml0aW9uIHRoYXQgYWxsb3dzIGRlZnJh Z21lbnRhdGlvbiAoZS5nLiwNCnNlZTxicj4NCiZndDsgJmd0OyBzcGxpdC1zcGVjdHJ1bSAmbmJz cDtzdXBlci1jaGFubmVsIG9wdGlvbiBpbiAmbmJzcDtodHRwOi8vdG9vbHMuaWV0Zi48YnI+DQom Z3Q7ICZndDsgb3JnL2h0bWwvZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVs LTAyKS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZsdDtZYW8mZ3Q7QWN0dWFsbHksIGZyYWdtZW50 YXRpb24gd2lsbCBhcHBlYXIgYXMgdHJhZmZpYyBpcyA8YnI+DQomZ3Q7IGFkZGVkIGFuZCByZW1v dmVkIGZyb20gbGlua3MuIFRoZSB3b3JrIG9mIGRlZnJhZ21lbnRhdGlvbiBzaG91bGQgYmUNCjxi cj4NCiZndDsgbGVmdCB0byBjb21wdXRhdGlvbiBlbnRpdHkgbGlrZSBQQ0UuIDxicj4NCiZndDsg SG93ZXZlciwgd2hldGhlciB0aGUgc2xpY2VzIHdpbGwgYmUgc3dpdGNoZWQgd2l0aCA8aT5jb250 aW51b3VzPC9pPg0KZm9ybSBpc25vdCBjbGVhci48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgUmVnYXJkaW5nIGNvbnNpZGVyYXRpb24g YWJvdXQgZ3VhcmQtYmFuZCwgSSB0aGluaywgaXQgY2FuIGJlDQo8YnI+DQomZ3Q7ICZndDsgY29u c2lkZXJlZCBhcyBhIHBhcnQgb2YgcGF0aCBjb21wdXRhdGlvbiBjb25zdHJhaW50IC0gZG9lcyBu b3QNCjxicj4NCiZndDsgJmd0OyBuZWNlc3NhcmlseSBuZWVkIHRvIGFkdmVydGlzZSB0aGlzIGFz IGEgcGFydCBvZiByb3V0aW5nLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7 WWFvJmd0OyBBZ3JlZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJz cDsgPGJyPg0KJmd0OyAmZ3Q7IFJlZ2FyZHMsIDxicj4NCiZndDsgJmd0OyBJZnRla2hhciA8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBGcm9tOiBNYWxjb2xtLkJFVFRTQHp0 ZS5jb20uY24gW21haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY25dDQo8YnI+DQomZ3Q7ICZn dDsgU2VudDogU3VuZGF5LCBOb3ZlbWJlciAxMywgMjAxMSA2OjExIFBNPGJyPg0KJmd0OyAmZ3Q7 IFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrPGJyPg0KJmd0OyAmZ3Q7IENjOiBjY2FtcEBpZXRmLm9y ZzsgY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogW0ND QU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDEgPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgSGkgQWRyaWFuLCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEludGVyZXN0aW5nIHF1ZXN0aW9ucywgYnV0IEkgdGhpbmsgd2UgbmVlZCB0byBj b25zaWRlciB0aGUgYmlnZ2VyDQo8YnI+DQomZ3Q7ICZndDsgcGljdHVyZSBmaXJzdC4gJm5ic3A7 QSBmZXcgcXVpY2sgdGhvdWdodHM6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT25l IG1vdGl2YXRpb24gZm9yIHRoZSBmbGV4aS1ncmlkIGlzIHRvIHN1cHBvcnQgdGhlIG5leHQgZ2Vu ZXJhdGlvbg0KPGJyPg0KJmd0OyAmZ3Q7IG9wdGljYWwgc2lnbmFscyAoJmd0OzEwMEdiL3MpIHRo YXQgY2Fubm90IGJlIGVmZmljaWVudGx5IGFjY29tbW9kYXRlZA0KPGJyPg0KJmd0OyAmZ3Q7IHdp dGggdGhlIGN1cnJlbnQgZml4ZWQgZ3JpZC4gJm5ic3A7SG93ZXZlciwgd2UgY2FuIGV4cGVjdCB0 bw0Kc2VlIGZsZXhpLTxicj4NCiZndDsgJmd0OyBncmlkIGRlcGxveWVkIGJlZm9yZSB0aGVzZSBo aWdoZXIgYml0IHJhdGUgc3lzdGVtcy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBU aGUgY3VycmVudCBmaXhlZCBncmlkIHByb3ZpZGVzIGFuIGltcGxpY2l0IGd1YXJkIGJhbmQgYmV0 d2Vlbg0KPGJyPg0KJmd0OyAmZ3Q7IG9wdGljYWwgY2hhbm5lbHMgKGFuZCBzbG90cyBjYW4gYmUg bGVmdCB1bnVzZWQgdG8gYWxsb3cgYSBncmVhdGVyDQo8YnI+DQomZ3Q7ICZndDsgZ3VhcmQgYmFu ZCkuICZuYnNwO1dpdGggZmxleGktZ3JpZCB3ZSB3aWxsIHByb2JhYmx5IG5lZWQgdG8gc3BlY2lm eQ0KdGhlIDxicj4NCiZndDsgJmd0OyBndWFyZCBiYW5kLiAmbmJzcDtUaGUgZ3VhcmQgYmFuZCB3 aWxsIHByb2JhYmx5IG5lZWQgdG8gZGVmaW5lZA0KYnkgYSBQQ0UgPGJyPg0KJmd0OyAmZ3Q7IGFw cGxpY2F0aW9uIGJ1dCB3ZSB3aWxsIG5lZWQgdG8gZGVmaW5lIHRoZSBwYXJhbWV0ZXJzLiAmbmJz cDsNCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgR2l2ZW4gdGhhdCB0cmFuc2l0aW5n IGFuIE9BRE0gbmFycm93cyB0aGUgb3B0aWNhbCBiYW5kd2lkdGggaXQNCm1heSA8YnI+DQomZ3Q7 ICZndDsgYmUgcG9zc2libGUgdG8gb3B0aW1pemUgdGhlIG5ldHdvcmsgYnkgYWRqdXN0aW5nIHRo ZSByZXF1ZXN0ZWQNCjxicj4NCiZndDsgJmd0OyBiYW5kd2lkdGggYmFzZWQgb24gdGhlIG51bWJl ciBvZiBPQURNcyBpbiB0aGUgcGF0aC4gJm5ic3A7SG93DQp3b3VsZCB3ZSA8YnI+DQomZ3Q7ICZn dDsgJnF1b3Q7cmV0YWluJnF1b3Q7IHRoaXMgaW5mb3JtYXRpb24gdG8gc3VwcG9ydCByZXN0b3Jh dGlvbi4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGV4cGVjdCB0aGF0IHdlIHdp bGwgaGF2ZSBhIGNvbmNhdGVuYXRpb24gb2YgZmxleGktZ3JpZCBhbmQNCmZpeGVkIDxicj4NCiZn dDsgJmd0OyBncmlkIGxpbmtzIChtYW5hZ2VkIHZpYSBhIFBDRSkgaW4gdGhlIG5ldHdvcmsuICZu YnNwO0hvdyB3aWxsDQp3ZSBzaWduYWwgPGJyPg0KJmd0OyAmZ3Q7IGZvciBleGFtcGxlIGZvciBh IHNsb3QgdG8gY2FycnkgMTBHYi9zIHNpZ25hbCBhY3Jvc3MgYSBuZXR3b3JrDQp0aGF0IDxicj4N CiZndDsgJmd0OyBpbmNsdWRlcyB0aGUgY29uY2F0ZW5hdGlvbiBvZiBmaXhlZCBncmlkIGFuZCBm bGV4aS1ncmlkIHNlZ21lbnRzLg0KJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBpbXBsaWNhdGlv biBvZiByb3V0aW5nIChSV0EpIG1heSBhbHNvIGJlIGludGVyZXN0aW5nLiA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBmbGV4aS1ncmlkIHdpbGwgcmVzdWx0IGluIGJhbmR3aWR0 aCBmcmFnbWVudGF0aW9uIGFzIHRyYWZmaWMNCmlzIDxicj4NCiZndDsgJmd0OyBhZGRlZCBhbmQg cmVtb3ZlZCBmcm9tIGxpbmtzLiAmbmJzcDtXZSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBuZWVkDQp0 byA8YnI+DQomZ3Q7ICZndDsgZGVmcmFnbWVudCB0aGUgbGluay4gPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyBJIHRoaW5rIHRoYXQgdGhlIGltcGxpY2F0aW9ucyBvZiBmbGV4aS1ncmlk IGdvIGJleW9uZCBzaWduYWxsaW5nDQo8YnI+DQomZ3Q7ICZndDsgaW50byByb3V0aW5nIChSV0Ep LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBTRyAxNSB3aWxsIGJlIG1lZXRp bmcgaW4gRGVjZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uDQpvbiA8YnI+DQomZ3Q7ICZn dDsgdGhlIHVzZSBvZiB0aGUgZmxleGktZ3JpZC4gJm5ic3A7SXQgd291bGQgYmUgdXNlZnVsIHRv IHByb3ZpZGUsDQplaXRoZXIgPGJyPg0KJmd0OyAmZ3Q7IGZvcm1hbGx5IG9yIGluZm9ybWFsbHkg YSBzZXQgb2YgcXVlc3Rpb25zLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFJlZ2Fy ZHMsIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTWFsY29sbSA8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O0Fkcmlh biBGYXJyZWwmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7IDxicj4NCiZndDsgJmd0 OyBTZW50IGJ5OiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgJmd0OyAxMi8xMS8y MDExIDA1OjI5IFBNIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUGxlYXNlIHJlc3Bv bmQgdG88YnI+DQomZ3Q7ICZndDsgYWRyaWFuQG9sZGRvZy5jby51ayA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IFRvIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmx0O2Nj YW1wQGlldGYub3JnJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGNjIDxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU3ViamVjdCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IFtDQ0FNUF0gVHJ5aW5nIHRvIHJlc29sdmUgZmxleGktZ3JpZCBpc3N1ZSAxIDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgSGksPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIHdhbnRlZCB0byBzZWUgd2hl dGhlciB3ZSBjYW4gcHJpbWUgdGhlIGRpc2N1c3Npb25zIG9mIGZsZXhpLWdyaWRsYWJlbHMNCmlu PGJyPg0KJmd0OyAmZ3Q7IGFkdmFuY2Ugb2YgdGhlIFdHIG1lZXRpbmdzIHRoaXMgd2Vlay48YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBzdWNjZXNz ZnVsbHkgYWdyZWVkIHRoYXQgdGhlcmUgYXJlIHR3bw0Kc2lnbmlmaWNhbnQ8YnI+DQomZ3Q7ICZn dDsgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgbGFiZWwgZm9ybWF0cyBkZWZpbmVkIGluPGJyPg0K Jmd0OyAmZ3Q7IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFycmtpbmdl bC1jY2FtcC1mbGV4aWdyaWQtPGJyPg0KJmd0OyBsYW1iZGEtbGFiZWw8YnI+DQomZ3Q7ICZndDsg YW5kIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctY2NhbXAtZmxl eGlibGUtZ3JpZC08YnI+DQomZ3Q7ICZndDsgcnN2cC10ZS1leHQ8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IFRoZSBmaXJzdCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5IG1pbm9yOjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU2hvdWxkIHdlIHVzZSBhIG5ldyB2YWx1ZSBmb3Ig dGhlIEdyaWQgZmllbGQgb3Igc2hvdWxkIHdlIGNvbnRpbnVldG8NCnVzZSB0aGU8YnI+DQomZ3Q7 ICZndDsgdmFsdWUgdGhhdCBpbmRpY2F0ZXMgRFdETS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IEluIGZhdm9yIG9mIGNvbnRpbnVpbmcgdG8gdXNlIHRoZSBEV0RNIHZhbHVlIGlzIHRo ZSBmYWN0IHRoYXQNCnRoZSA8YnI+DQomZ3Q7ICZndDsgSVRVLVQgaGFzIG5vdDxicj4NCiZndDsg Jmd0OyBkZWZpbmVkIGEgbmV3IGdyaWQgZm9yIGZsZXhpYmxlIHdhdmVsZW5ndGggYXNzaWdubWVu dHMuIEluIGZhY3QsDQo8YnI+DQomZ3Q7IHRoZUlUVS1UIHNheXM8YnI+DQomZ3Q7ICZndDsgdGhh dCBmbGV4aWJsZSBhc3NpZ25tZW50cyBzaG91bGQgYmUgbWFkZSBmcm9tIHRoZSBEV0RNIGdyaWQu PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPbiB0aGUgb3RoZXIgaGFuZCB3ZSBuZWVk IHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUgZmllbGRzIGluIEdNUExTDQo8YnI+DQomZ3Q7IG9iamVj dHMgZXhpc3Q8YnI+DQomZ3Q7ICZndDsgdG8gbWFrZSBpbXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5k IHRvIGNvbnZleSBpbmZvcm1hdGlvbi4gVGhlcmUNCmlzIDxicj4NCiZndDsgbm9uZWVkIGZvciBh PGJyPg0KJmd0OyAmZ3Q7IGRpcmVjdCBtYXBwaW5nIHRvIElUVS1UIGdyaWRzLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgVGh1cywgd2hlbiBkcmFmdC16aGFuZyBzdWdnZXN0cyB1c2lu ZyBHcmlkPT0xIChJVFUtVCBEV0RNKSBpdA0KaXMgPGJyPg0KJmd0OyBjb3JyZWN0IHRoYXQ8YnI+ DQomZ3Q7ICZndDsgdGhlIGZsZXhpYmxlIGdyaWQgd2F2ZWxlbmd0aHMgd2lsbCBiZSBzdWdnZXN0 ZWQgZnJvbSB0aGUgSVRVLVQNCkRXRE0gPGJyPg0KJmd0OyAmZ3Q7IGdyaWQsIGJ1dCBpdDxicj4N CiZndDsgJmd0OyBpcyBub3QgYmVpbmcgYXMgaGVscGZ1bCBhcyBpdCBjb3VsZCBiZS48YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFdoZW4gZHJhZnQtZmFycmtpbmdlbCBzdWdnZXN0cyB1 c2luZyBHcmlkPT0zIChJVFUtVCBGbGV4KSBpdA0KaXMgbm90IGltcGx5aW5nPGJyPg0KJmd0OyAm Z3Q7IHRoYXQgdGhlcmUgaXMgYSBuZXcgYW5kIGRpZmZlcmVudCBncmlkIGRlZmluZWQgYnkgdGhl IElUVS1ULg0KV2hhdCA8YnI+DQomZ3Q7IGl0aXMgc2F5aW5nPGJyPg0KJmd0OyAmZ3Q7IGlzIHRo YXQgdGhlIGxhYmVsIGlzIGEgZmxleGktZ3JpZCBsYWJlbCBzZWxlY3RlZCBmcm9tIHRoZSBncmlk DQo8YnI+DQomZ3Q7IGRlZmluZWQgYnkgdGhlPGJyPg0KJmd0OyAmZ3Q7IElUVS1UIGZvciB0aGF0 IHB1cnBvc2UgKGkuZS4sIHRoZSBEV0RNIGdyaWQpLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgUGVyc29uYWxseSwgaSBkb24ndCBzZWUgdGhpcyBhcyBhIHZlcnkgbGFyZ2UgaXNzdWUu IGRyYWZ0LTxicj4NCiZndDsgZmFycmtpbmdlbHdvdWxkIHdvcms8YnI+DQomZ3Q7ICZndDsganVz dCBhcyB3ZWxsIGlmIHdlIGRlY2lkZSB0byB1c2UgR3JpZD09MS4gaG93ZXZlciwgSSB0aGluayBp dA0KaXMgPGJyPg0KJmd0OyAmZ3Q7IG1hcmdpbmFsbHkgbW9yZTxicj4NCiZndDsgJmd0OyBoZWxw ZnVsIGFuZCB1c2VmdWwgdG8gYmUgYWJsZSB0byByZWNvZ25pc2UgdGhlIGRpZmZlcmVudCBsYWJl bA0KdXNlIDxicj4NCiZndDsgJmd0OyBjYXNlcyAoZml4ZWQ8YnI+DQomZ3Q7ICZndDsgZ3JpZCAv IGZsZXhpYmxlIGdyaWQpIGJ5IGxvb2tpbmcgYXQgYSBmaWVsZCBlYXJseSBpbiB0aGUgTGFiZWwN Cm9iamVjdC48YnI+DQomZ3Q7ICZndDsgQ29udmVyc2VseSwgSSBkb24ndCBiZWxpZXZlIHRoYXQg ZHJhZnQtemhhbmcgd291bGQgYmUgYnJva2VuDQpieSA8YnI+DQomZ3Q7IHVzaW5nIEdyaWQ9PTMu PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTbyBteSBjb21wcm9taXNlIHByb3Bvc2Fs IGlzIHRoYXQgYm90aCBJLURzIHVzZSBHcmlkPT0zLiBUaGVuDQp3ZSBjYW48YnI+DQomZ3Q7ICZn dDsgY29uY2VudHJhdGU8YnI+DQomZ3Q7ICZndDsgb24gdGhlIG1vcmUgc2lnbmlmaWNhbnQgc2Vj b25kIGlzc3VlIChzZWUgc2VwYXJhdGUgZW1haWwpLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgV2hhdCBkbyBmb2xrIHRoaW5rPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg Q2hlZXJzLDxicj4NCiZndDsgJmd0OyBBZHJpYW48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Jmd0OyAmZ3Q7IENDQU1QIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBDQ0FNUEBpZXRmLm9y Zzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IENDQU1QIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0 OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcDxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0012655148257948_=-- From IHussain@infinera.com Sun Nov 13 19:25:14 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9B1F0C47; Sun, 13 Nov 2011 19:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.926 X-Spam-Level: * X-Spam-Status: No, score=1.926 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIT38bSbKsn4; Sun, 13 Nov 2011 19:25:13 -0800 (PST) Received: from SV-CASHT-PROD3.infinera.com (sv-casht-prod3.infinera.com [8.4.225.26]) by ietfa.amsl.com (Postfix) with ESMTP id E7BE91F0CC0; Sun, 13 Nov 2011 19:25:12 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by SV-CASHT-PROD3.infinera.com ([::1]) with mapi id 14.01.0339.001; Sun, 13 Nov 2011 19:25:11 -0800 From: Iftekhar Hussain To: "li.yao3@zte.com.cn" Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiBSZTogIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdy?= =?gb2312?Q?id_issue_1?= Thread-Index: AQHMon0E8MAs64hCaEmP0nc25K1Uhg== Date: Mon, 14 Nov 2011 03:25:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE3DSVEXDBPROD1infi_" MIME-Version: 1.0 Cc: Marco Sosa , Abinder Dhillon , "ccamp@ietf.org" , "ccamp-bounces@ietf.org" , Vinayak Dangui Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogUmU6ICBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4?= =?gb2312?b?aS1ncmlkIGlzc3VlIDE=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:25:14 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE3DSVEXDBPROD1infi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWWFvLA0KDQpQbGVhc2Ugc2VlIGluLWxpbmUNCg0KRnJvbTogbGkueWFvM0B6dGUuY29tLmNu IFttYWlsdG86bGkueWFvM0B6dGUuY29tLmNuXQ0KU2VudDogU3VuZGF5LCBOb3ZlbWJlciAxMywg MjAxMSA3OjEzIFBNDQpUbzogSWZ0ZWtoYXIgSHVzc2Fpbg0KQ2M6IEFiaW5kZXIgRGhpbGxvbjsg Y2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFtDQ0FNUF0g tPC4tDogUmU6IFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KDQoNCkhpIElm dGVraGFyOg0KDQpQbGVhc2Ugc2VlIGJlbG93Lg0KDQpjY2FtcC1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIwMTEtMTEtMTQgMTA6NDg6Mzg6DQoN Cj4gSGkgTWFsY29sbSwNCj4NCj4gQWdyZWVkIHdpdGggeW91ciBvYnNlcnZhdGlvbiBhYm91dCBm cmFnbWVudGF0aW9uIGluIGZsZXhpYmxlIGdyaWQuDQo+IEJUVywgdGhpcyBpcyBvbmUgb2YgdGhl IHJlYXNvbnMgd2h5IHdlIG5lZWQgdG8gY29uc2lkZXIgZmxleGlibGUNCj4gYXBwcm9hY2ggZm9y IGxhYmVsIGRlZmluaXRpb24gdGhhdCBhbGxvd3MgZGVmcmFnbWVudGF0aW9uIChlLmcuLCBzZWUN Cj4gc3BsaXQtc3BlY3RydW0gIHN1cGVyLWNoYW5uZWwgb3B0aW9uIGluICBodHRwOi8vdG9vbHMu aWV0Zi4NCj4gb3JnL2h0bWwvZHJhZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVs LTAyKS4NCg0KPFlhbz5BY3R1YWxseSwgZnJhZ21lbnRhdGlvbiB3aWxsIGFwcGVhciBhcyB0cmFm ZmljIGlzDQphZGRlZCBhbmQgcmVtb3ZlZCBmcm9tIGxpbmtzLiBUaGUgd29yayBvZiBkZWZyYWdt ZW50YXRpb24gc2hvdWxkIGJlIGxlZnQgdG8gY29tcHV0YXRpb24gZW50aXR5IGxpa2UgUENFLg0K SG93ZXZlciwgd2hldGhlciB0aGUgc2xpY2VzIHdpbGwgYmUgc3dpdGNoZWQgd2l0aCBjb250aW51 b3VzIGZvcm0gaXMgbm90IGNsZWFyLg0KDQpbSWZ0ZWtoYXJdIFllcywgdHJ1ZSwgZnJhZ21lbnRh dGlvbiB3aWxsIG9jY3VyIGFzIGEgcmVzdWx0IG9mIGFkZGluZy9yZW1vdmluZyBvcHRpY2FsIExT UHMuICBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gobBkZWZyYWdtZW50YXRpb24gc2hvdWxk IGJlIGxlZnQgdG8gY29tcHV0YXRpb24gZW50aXR5obEuIFdoeT8gSG93IHdpbGwgUENFIGhlbHAg aW4gdGhpcyByZWdhcmQgqEMgY2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlLg0KDQpUaGFua3MsDQpJ ZnRla2hhcg0KDQoNCj4NCj4gUmVnYXJkaW5nIGNvbnNpZGVyYXRpb24gYWJvdXQgZ3VhcmQtYmFu ZCwgSSB0aGluaywgaXQgY2FuIGJlDQo+IGNvbnNpZGVyZWQgYXMgYSBwYXJ0IG9mIHBhdGggY29t cHV0YXRpb24gY29uc3RyYWludCAtIGRvZXMgbm90DQo+IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYWR2 ZXJ0aXNlIHRoaXMgYXMgYSBwYXJ0IG9mIHJvdXRpbmcuDQoNCg0KPFlhbz4gQWdyZWUuDQoNCg0K Pg0KPiBSZWdhcmRzLA0KPiBJZnRla2hhcg0KPg0KPiBGcm9tOiBNYWxjb2xtLkJFVFRTQHp0ZS5j b20uY248bWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbj4gW21haWx0bzpNYWxjb2xtLkJF VFRTQHp0ZS5jb20uY25dPG1haWx0bzpbbWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbl0+ DQo+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTMsIDIwMTEgNjoxMSBQTQ0KPiBUbzogYWRyaWFu QG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4NCj4gQ2M6IGNjYW1wQGll dGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz47IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFRyeWlu ZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KPg0KPiBIaSBBZHJpYW4sDQo+DQo+IElu dGVyZXN0aW5nIHF1ZXN0aW9ucywgYnV0IEkgdGhpbmsgd2UgbmVlZCB0byBjb25zaWRlciB0aGUg YmlnZ2VyDQo+IHBpY3R1cmUgZmlyc3QuICBBIGZldyBxdWljayB0aG91Z2h0czoNCj4NCj4gT25l IG1vdGl2YXRpb24gZm9yIHRoZSBmbGV4aS1ncmlkIGlzIHRvIHN1cHBvcnQgdGhlIG5leHQgZ2Vu ZXJhdGlvbg0KPiBvcHRpY2FsIHNpZ25hbHMgKD4xMDBHYi9zKSB0aGF0IGNhbm5vdCBiZSBlZmZp Y2llbnRseSBhY2NvbW1vZGF0ZWQNCj4gd2l0aCB0aGUgY3VycmVudCBmaXhlZCBncmlkLiAgSG93 ZXZlciwgd2UgY2FuIGV4cGVjdCB0byBzZWUgZmxleGktDQo+IGdyaWQgZGVwbG95ZWQgYmVmb3Jl IHRoZXNlIGhpZ2hlciBiaXQgcmF0ZSBzeXN0ZW1zLg0KPg0KPiBUaGUgY3VycmVudCBmaXhlZCBn cmlkIHByb3ZpZGVzIGFuIGltcGxpY2l0IGd1YXJkIGJhbmQgYmV0d2Vlbg0KPiBvcHRpY2FsIGNo YW5uZWxzIChhbmQgc2xvdHMgY2FuIGJlIGxlZnQgdW51c2VkIHRvIGFsbG93IGEgZ3JlYXRlcg0K PiBndWFyZCBiYW5kKS4gIFdpdGggZmxleGktZ3JpZCB3ZSB3aWxsIHByb2JhYmx5IG5lZWQgdG8g c3BlY2lmeSB0aGUNCj4gZ3VhcmQgYmFuZC4gIFRoZSBndWFyZCBiYW5kIHdpbGwgcHJvYmFibHkg bmVlZCB0byBkZWZpbmVkIGJ5IGEgUENFDQo+IGFwcGxpY2F0aW9uIGJ1dCB3ZSB3aWxsIG5lZWQg dG8gZGVmaW5lIHRoZSBwYXJhbWV0ZXJzLg0KPg0KPiBHaXZlbiB0aGF0IHRyYW5zaXRpbmcgYW4g T0FETSBuYXJyb3dzIHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdCBtYXkNCj4gYmUgcG9zc2libGUg dG8gb3B0aW1pemUgdGhlIG5ldHdvcmsgYnkgYWRqdXN0aW5nIHRoZSByZXF1ZXN0ZWQNCj4gYmFu ZHdpZHRoIGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgT0FETXMgaW4gdGhlIHBhdGguICBIb3cgd291 bGQgd2UNCj4gInJldGFpbiIgdGhpcyBpbmZvcm1hdGlvbiB0byBzdXBwb3J0IHJlc3RvcmF0aW9u Lg0KPg0KPiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgaGF2ZSBhIGNvbmNhdGVuYXRpb24gb2YgZmxl eGktZ3JpZCBhbmQgZml4ZWQNCj4gZ3JpZCBsaW5rcyAobWFuYWdlZCB2aWEgYSBQQ0UpIGluIHRo ZSBuZXR3b3JrLiAgSG93IHdpbGwgd2Ugc2lnbmFsDQo+IGZvciBleGFtcGxlIGZvciBhIHNsb3Qg dG8gY2FycnkgMTBHYi9zIHNpZ25hbCBhY3Jvc3MgYSBuZXR3b3JrIHRoYXQNCj4gaW5jbHVkZXMg dGhlIGNvbmNhdGVuYXRpb24gb2YgZml4ZWQgZ3JpZCBhbmQgZmxleGktZ3JpZCBzZWdtZW50cy4N Cj4gVGhlIGltcGxpY2F0aW9uIG9mIHJvdXRpbmcgKFJXQSkgbWF5IGFsc28gYmUgaW50ZXJlc3Rp bmcuDQo+DQo+IFRoZSBmbGV4aS1ncmlkIHdpbGwgcmVzdWx0IGluIGJhbmR3aWR0aCBmcmFnbWVu dGF0aW9uIGFzIHRyYWZmaWMgaXMNCj4gYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gIFdl IG5lZWQgdG8gY29uc2lkZXIgdGhlIG5lZWQgdG8NCj4gZGVmcmFnbWVudCB0aGUgbGluay4NCj4N Cj4gSSB0aGluayB0aGF0IHRoZSBpbXBsaWNhdGlvbnMgb2YgZmxleGktZ3JpZCBnbyBiZXlvbmQg c2lnbmFsbGluZw0KPiBpbnRvIHJvdXRpbmcgKFJXQSkuDQo+DQo+IFRoZSBTRyAxNSB3aWxsIGJl IG1lZXRpbmcgaW4gRGVjZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uIG9uDQo+IHRoZSB1 c2Ugb2YgdGhlIGZsZXhpLWdyaWQuICBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlkZSwgZWl0 aGVyDQo+IGZvcm1hbGx5IG9yIGluZm9ybWFsbHkgYSBzZXQgb2YgcXVlc3Rpb25zLg0KPg0KPiBS ZWdhcmRzLA0KPg0KPiBNYWxjb2xtDQo+DQoNCj4NCj4gIkFkcmlhbiBGYXJyZWwiIDxhZHJpYW5A b2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPj4NCj4gU2VudCBieTogY2Nh bXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4NCj4gMTIv MTEvMjAxMSAwNToyOSBQTQ0KPg0KPiBQbGVhc2UgcmVzcG9uZCB0bw0KPiBhZHJpYW5Ab2xkZG9n LmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPg0KPg0KPiBUbw0KPg0KPiA8Y2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4NCj4NCj4gY2MNCj4NCj4gU3ViamVjdA0K Pg0KPiBbQ0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KPg0KPg0K Pg0KPg0KPg0KPg0KPiBIaSwNCj4NCj4gSSB3YW50ZWQgdG8gc2VlIHdoZXRoZXIgd2UgY2FuIHBy aW1lIHRoZSBkaXNjdXNzaW9ucyBvZiBmbGV4aS1ncmlkIGxhYmVscyBpbg0KPiBhZHZhbmNlIG9m IHRoZSBXRyBtZWV0aW5ncyB0aGlzIHdlZWsuDQo+DQo+IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBz dWNjZXNzZnVsbHkgYWdyZWVkIHRoYXQgdGhlcmUgYXJlIHR3byBzaWduaWZpY2FudA0KPiBkaWZm ZXJlbmNlcyBiZXR3ZWVuIHRoZSBsYWJlbCBmb3JtYXRzIGRlZmluZWQgaW4NCj4gaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC1s YW1iZGEtbGFiZWwNCj4gYW5kIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt emhhbmctY2NhbXAtZmxleGlibGUtZ3JpZC0NCj4gcnN2cC10ZS1leHQNCj4NCj4gVGhlIGZpcnN0 IHBvaW50IHNlZW1zIHJlbGF0aXZlbHkgbWlub3I6DQo+DQo+IFNob3VsZCB3ZSB1c2UgYSBuZXcg dmFsdWUgZm9yIHRoZSBHcmlkIGZpZWxkIG9yIHNob3VsZCB3ZSBjb250aW51ZSB0byB1c2UgdGhl DQo+IHZhbHVlIHRoYXQgaW5kaWNhdGVzIERXRE0uDQo+DQo+IEluIGZhdm9yIG9mIGNvbnRpbnVp bmcgdG8gdXNlIHRoZSBEV0RNIHZhbHVlIGlzIHRoZSBmYWN0IHRoYXQgdGhlDQo+IElUVS1UIGhh cyBub3QNCj4gZGVmaW5lZCBhIG5ldyBncmlkIGZvciBmbGV4aWJsZSB3YXZlbGVuZ3RoIGFzc2ln bm1lbnRzLiBJbiBmYWN0LCB0aGVJVFUtVCBzYXlzDQo+IHRoYXQgZmxleGlibGUgYXNzaWdubWVu dHMgc2hvdWxkIGJlIG1hZGUgZnJvbSB0aGUgRFdETSBncmlkLg0KPg0KPiBPbiB0aGUgb3RoZXIg aGFuZCB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUgZmllbGRzIGluIEdNUExTIG9iamVj dHMgZXhpc3QNCj4gdG8gbWFrZSBpbXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5kIHRvIGNvbnZleSBp bmZvcm1hdGlvbi4gVGhlcmUgaXMgbm9uZWVkIGZvciBhDQo+IGRpcmVjdCBtYXBwaW5nIHRvIElU VS1UIGdyaWRzLg0KPg0KPiBUaHVzLCB3aGVuIGRyYWZ0LXpoYW5nIHN1Z2dlc3RzIHVzaW5nIEdy aWQ9PTEgKElUVS1UIERXRE0pIGl0IGlzIGNvcnJlY3QgdGhhdA0KPiB0aGUgZmxleGlibGUgZ3Jp ZCB3YXZlbGVuZ3RocyB3aWxsIGJlIHN1Z2dlc3RlZCBmcm9tIHRoZSBJVFUtVCBEV0RNDQo+IGdy aWQsIGJ1dCBpdA0KPiBpcyBub3QgYmVpbmcgYXMgaGVscGZ1bCBhcyBpdCBjb3VsZCBiZS4NCj4N Cj4gV2hlbiBkcmFmdC1mYXJya2luZ2VsIHN1Z2dlc3RzIHVzaW5nIEdyaWQ9PTMgKElUVS1UIEZs ZXgpIGl0IGlzIG5vdCBpbXBseWluZw0KPiB0aGF0IHRoZXJlIGlzIGEgbmV3IGFuZCBkaWZmZXJl bnQgZ3JpZCBkZWZpbmVkIGJ5IHRoZSBJVFUtVC4gV2hhdCBpdGlzIHNheWluZw0KPiBpcyB0aGF0 IHRoZSBsYWJlbCBpcyBhIGZsZXhpLWdyaWQgbGFiZWwgc2VsZWN0ZWQgZnJvbSB0aGUgZ3JpZCBk ZWZpbmVkIGJ5IHRoZQ0KPiBJVFUtVCBmb3IgdGhhdCBwdXJwb3NlIChpLmUuLCB0aGUgRFdETSBn cmlkKS4NCj4NCj4gUGVyc29uYWxseSwgaSBkb24ndCBzZWUgdGhpcyBhcyBhIHZlcnkgbGFyZ2Ug aXNzdWUuIGRyYWZ0LWZhcnJraW5nZWx3b3VsZCB3b3JrDQo+IGp1c3QgYXMgd2VsbCBpZiB3ZSBk ZWNpZGUgdG8gdXNlIEdyaWQ9PTEuIGhvd2V2ZXIsIEkgdGhpbmsgaXQgaXMNCj4gbWFyZ2luYWxs eSBtb3JlDQo+IGhlbHBmdWwgYW5kIHVzZWZ1bCB0byBiZSBhYmxlIHRvIHJlY29nbmlzZSB0aGUg ZGlmZmVyZW50IGxhYmVsIHVzZQ0KPiBjYXNlcyAoZml4ZWQNCj4gZ3JpZCAvIGZsZXhpYmxlIGdy aWQpIGJ5IGxvb2tpbmcgYXQgYSBmaWVsZCBlYXJseSBpbiB0aGUgTGFiZWwgb2JqZWN0Lg0KPiBD b252ZXJzZWx5LCBJIGRvbid0IGJlbGlldmUgdGhhdCBkcmFmdC16aGFuZyB3b3VsZCBiZSBicm9r ZW4gYnkgdXNpbmcgR3JpZD09My4NCj4NCj4gU28gbXkgY29tcHJvbWlzZSBwcm9wb3NhbCBpcyB0 aGF0IGJvdGggSS1EcyB1c2UgR3JpZD09My4gVGhlbiB3ZSBjYW4NCj4gY29uY2VudHJhdGUNCj4g b24gdGhlIG1vcmUgc2lnbmlmaWNhbnQgc2Vjb25kIGlzc3VlIChzZWUgc2VwYXJhdGUgZW1haWwp Lg0KPg0KPiBXaGF0IGRvIGZvbGsgdGhpbms/DQo+DQo+IENoZWVycywNCj4gQWRyaWFuDQo+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1Q IG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NBTVBAaWV0Zi5vcmc+DQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBs aXN0DQo+IENDQU1QQGlldGYub3JnPG1haWx0bzpDQ0FNUEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE3DSVEXDBPROD1infi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Yao,=

 <= /p>

Please see in-line

 <= /p>

From: li.yao3@= zte.com.cn [mailto:li.yao3@zte.com.cn]
Sent: Sunday, November 13, 2011 7:13 PM
To: Iftekhar Hussain
Cc: Abinder Dhillon; ccamp@ietf.org; ccamp-bounces@ietf.org
Subject: [CCAMP] =B4=F0=B8=B4: Re: Trying to resolve flexi-grid issue= 1

 


Hi Iftekhar:

Please see below.

ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 10:48:38:

> Hi Malcolm,
>  
> Agreed with your observation abou= t fragmentation in flexible grid.
> BTW, this is one of the reasons why we need to consider flexible <= /tt>
> approach for label definition that allows defragmentation (e.g., s= ee
> split-spectrum  super-channel option in  http://tools.ietf.
> org/html/draft-hussain-ccamp-super-channel-label-02). =

<Yao>Actually, fragme= ntation will appear as traffic is
added and removed from links. The work of defragmentation should be lef= t to computation entity like PCE.
However, whether the slices= will be switched with continuous form is not clear.

[Iftekhar] Yes, true, fra= gmentation will occur as a result of adding/removing optical LSPs.  I = am not sure what you mean =A1=B0defragmentation should be left to computation entity=A1=B1. Why? How will PCE help in this regard =A8C can y= ou please elaborate.

 <= /p>

Thanks,=

Iftekhar



>  
> Regarding consideration about gua= rd-band, I think, it can be
> considered as a part of path computation constraint - does not
> necessarily need to advertise this as a part of routing.


<Yao> Agree.


>  
> Regards,
> Iftekhar
>  
> From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
> Sent: Sunday, November 13, 2011 6:11 PM
> To: adrian@olddog.co.uk=
> Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
> Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
>  
> Hi Adrian,
>
> Interesting questions, but I think we need to consider the bigger =
> picture first.  A few quick thoughts:
>
> One motivation for the flexi-grid is to support the next generatio= n
> optical signals (>100Gb/s) that cannot be efficiently accommoda= ted
> with the current fixed grid.  However, we can expect to see f= lexi-
> grid deployed before these higher bit rate systems.
>
> The current fixed grid provides an implicit guard band between
> optical channels (and slots can be left unused to allow a greater =
> guard band).  With flexi-grid we will probably need to specif= y the
> guard band.  The guard band will probably need to defined by = a PCE
> application but we will need to define the parameters.  
>
> Given that transiting an OADM narrows the optical bandwidth it may=
> be possible to optimize the network by adjusting the requested
> bandwidth based on the number of OADMs in the path.  How woul= d we
> "retain" this information to support restoration. <= br> >
> I expect that we will have a concatenation of flexi-grid and fixed=
> grid links (managed via a PCE) in the network.  How will we s= ignal
> for example for a slot to carry 10Gb/s signal across a network tha= t
> includes the concatenation of fixed grid and flexi-grid segments. =  
> The implication of routing (RWA) may also be interesting. >
> The flexi-grid will result in bandwidth fragmentation as traffic i= s
> added and removed from links.  We need to consider the need t= o
> defragment the link.
>
> I think that the implications of flexi-grid go beyond signalling <= /tt>
> into routing (RWA).
>
> The SG 15 will be meeting in December and will hold discussion on =
> the use of the flexi-grid.  It would be useful to provide, ei= ther
> formally or informally a set of questions.
>
> Regards,
>
> Malcolm
>

>
> "Adrian Farrel" <adrian@olddog.co.uk>
> Sent by: ccamp-bounces@i= etf.org
> 12/11/2011 05:29 PM <= br> >
> Please respond to
> adrian@olddog.co.uk
>
> To
>
> <ccamp@ietf.org> =
>
> cc
>
> Subject
>
> [CCAMP] Trying to resolve flexi-grid issue 1
>
>  
>
>
>
>
> Hi,
>
> I wanted to see whether we can prime the discussions of flexi-grid= labels in
> advance of the WG meetings this week.
>
> It looks like we have successfully agreed that there are two signi= ficant
> differences between the label formats defined in
> http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-lab= el
> and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid- > rsvp-te-ext
>
> The first point seems relatively minor:
>
> Should we use a new value for the Grid field or should we continue= to use the
> value that indicates DWDM.
>
> In favor of continuing to use the DWDM value is the fact that the =
> ITU-T has not
> defined a new grid for flexible wavelength assignments. In fact, t= heITU-T says
> that flexible assignments should be made from the DWDM grid.<= br> >
> On the other hand we need to understand that the fields in GMPLS o= bjects exist
> to make implementation easier and to convey information. There is = noneed for a
> direct mapping to ITU-T grids.
>
> Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it = is correct that
> the flexible grid wavelengths will be suggested from the ITU-T DWD= M
> grid, but it
> is not being as helpful as it could be.
>
> When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it i= s not implying
> that there is a new and different grid defined by the ITU-T. What = itis saying
> is that the label is a flexi-grid label selected from the grid def= ined by the
> ITU-T for that purpose (i.e., the DWDM grid).
>
> Personally, i don't see this as a very large issue. draft-farrking= elwould work
> just as well if we decide to use Grid=3D=3D1. however, I think it = is
> marginally more
> helpful and useful to be able to recognise the different label use=
> cases (fixed
> grid / flexible grid) by looking at a field early in the Label obj= ect.
> Conversely, I don't believe that draft-zhang would be broken by us= ing Grid=3D=3D3.
>
> So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then = we can
> concentrate
> on the more significant second issue (see separate email). >
> What do folk think?
>
> Cheers,
> Adrian
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/ccamp

--_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE3DSVEXDBPROD1infi_-- From daniele.ceccarelli@ericsson.com Sun Nov 13 19:27:48 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC04A1F0CB6; Sun, 13 Nov 2011 19:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7YEEjkcs9-r; Sun, 13 Nov 2011 19:27:48 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 92A691F0C47; Sun, 13 Nov 2011 19:27:47 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-52-4ec08ab28cd0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 35.7B.09514.2BA80CE4; Mon, 14 Nov 2011 04:27:46 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 14 Nov 2011 04:27:46 +0100 From: Daniele Ceccarelli To: "ccamp-bounces@ietf.org" Date: Mon, 14 Nov 2011 04:27:45 +0100 Thread-Topic: [CCAMP] Flexi-grid issue 2 Thread-Index: AQHMon1guPVK0nNxWUGFm9TLjgEjnQ== Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:27:49 -0000 SGkgQ3lyaWwgYW5kIGFsbCwKCkhhdmluZyB0aGUgc2FtZSBwYXJhbWV0ZXIgaW4gdHdvIHBsYWNl IGNhbiBvZnRlbiBiZSB0aGUgcmVjaXBlIGZvciBhIGRpc2FzdGVyLCBpbiBjYXNlIHRoZXJlIGlz IHRoZSBuZWVkIHRvIGhhdmUgYW4gZW5kLXRvLWVuZCBwYXJhbWV0ZXIgcGx1cyBhbiBob3AtYnkt aG9wIG9uZSB3ZSBtaWdodCBjb25zaWRlciBoYXZpbmcgdHdvIGRpZmZlcmVudCBwYXJhbWV0ZXJz LgoKTm93IHRoZSBxdWVzdGlvbiBpczppcyB0aGlzIHBvc3NpYmxlPyBJIG1lYW4sIGlzIGl0IHBv c3NpYmxlIHRoYXQgYSBnaXZlbiBzbG90IHdpZHRoIGlzIGFza2VkIGZyb20gZW5kIHRvIGVuZCBi dXQgbGluayBieSBsaW5rIHRoZSByZXF1ZXN0IGNhbiBiZSBzYXRpc2ZpZWQgd2l0aCBkaWZmZXJl bnQgc2xvdCB3aWR0aD8gSWYgdGhlIGFuc3dlciBpcyBubywgSSB0aGluayBwdXR0aW5nIG0gaW4g dGhlIHRyYWZmaWMgcGFyYW1zIGNvdWxkIGJlIGVub3VnaCwgaWYgdGhlIGFuc3dlciBpcyBubyBJ IHRoaW5rIHR3byB2YWx1ZXMgbWlnaHQgYmUgbmVlZGVkLCBvbmUgaW4gdGhlIHRyYWZmaWMgcGFy YW1ldGVycyBhbmQgdGhlIG90aGVyIGluIHRoZSBsYWJlbC4KCk1heWJlIGl0IGlzIHdvcnRoIGFk ZGluZyB0aGlzIHF1ZXN0aW9uIHRvIHRoZSBsaXN0IEFkcmlhbiBhc2tlZCBmb3I/IFVubGVzcyBz b21lb25lIGFscmVhZHkgaGFzIGEgcXVlc3Rpb24uCgpUaGFua3MgCkRhbmllbGUKCioqKiBFLW1h aWwgdmlhIERNRSBwb3dlcmVkIGJ5IG1vYmlsZSBicm9hZGJhbmQgKioqCgotLU9yaWdpbmFsIG1l c3NhZ2UtLS0KU2VuZGVyOiAiY2NhbXAtYm91bmNlc0BpZXRmLm9yZyIgPGNjYW1wLWJvdW5jZXNA aWV0Zi5vcmc+ClNlbnQgdGltZTogMTMvbm92LzIwMTEgMjI6MTMKVG86IGFkcmlhbkBvbGRkb2cu Y28udWssIHpoYW5nZmF0YWlAaHVhd2VpLmNvbSwgY2NhbXBAaWV0Zi5vcmcKU3ViamVjdDogUmU6 IFtDQ0FNUF0gRmxleGktZ3JpZCBpc3N1ZSAyCgpIaSwgCgpJdCBzZWVtcyB0byBtZSB0aGF0IG0g c2hvdWxkIGJlIGluIHRoZSB0cmFmZmljIHBhcmFtZXRlcnMgYmVjYXVzZSBpdCBkZXNjcmliZXMg dGhlIGNhcGFjaXR5LgpSZWdhcmRpbmcgdGhlIGxhYmVsLCBpZiBJIHVuZGVyc3RhbmQgY29ycmVj dGx5IFJGQzQ2MDYgKGFuZCByZWNlbnQgT1ROIHdvcmspICB0aGUgbGFiZWwgYWxvbmUgaXMgbm90 IHRoZSBvbmx5IAppbmZvcm1hdGlvbiAoYWxzbyB3aGVuIGFkZGluZyB0aGUgaW50ZXJmYWNlIGlu Zm9ybWF0aW9uKSBpcyBub3QgZW5vdWdoLCB0aGUgdHJhZmZpYyBwYXJhbWV0ZXJzIGFyZSBhbHNv IHVzZWQuCgpIYXZpbmcgdGhlICJtIiBhZGRpdGlvbmFsbHkgaW4gdGhlIGxhYmVsIHNlZW1zIGFs c28gdG8gYmUgY29uc2lkZXJlZCwgaXQgc2VlbXMgcG9zc2libGUgdGhhdCB0aGUgIm0iIG1pZ2h0 IGJlIGluZmx1ZW5jZWQgYnkgdGhlIHN3aXRjaGluZyBlbGVtZW50IGFuZCBjaGFuZ2UgaG9wLWJ5 LWhvcC4KCk15IDIgY2VudHMuCgoKQmVzdCByZWdhcmRzIC8gTWl0IGZyZXVuZGxpY2hlbiBHcsO8 w59lbgpDeXJpbCBNYXJnYXJpYQoKCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9t OiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmCj4gT2YgZXh0IEFkcmlhbiBGYXJyZWwKPiBTZW50OiBNb25kYXksIE5vdmVtYmVy IDE0LCAyMDExIDEwOjU1IEFNCj4gVG86ICdaaGFuZ2ZhdGFpJzsgY2NhbXBAaWV0Zi5vcmcKPiBT dWJqZWN0OiBSZTogW0NDQU1QXSBGbGV4aS1ncmlkIGlzc3VlIDIKPiAKPiBIaSwKPiAKPiBJJ3Zl IG5vdCBzcGVudCBhIGxvdCBvZiB0aW1lIGxvb2tpbmcgYXQgdGhlIHRyYWZmaWMgcGFyYW1ldGVy cywgYnV0Cj4geWVzLiBJdCBzZWVtcyB0byBtZSB0aGF0IHBhcnQgb2YgcmVxdWVzdGluZyB0aGUg TFNQIGNvdWxkIGluY2x1ZGUKPiBzcGVjaWZ5aW5nIGEgbnVtYmVyIG9mIHBhcmFtZXRlcnMgcmVs YXRlZCB0byBjYXBhY2l0eSBhbmQgY29uc3RydWN0aW9uLgo+IFRoYXQgd291bGQgbWVhbiB0aGF0 ICJtIiBtaWdodCByZWFzb25hYmx5IGJlIGluIHRoZSB0cmFmZmljIHBhcmFtZXRlcnMKPiAob3Ig bWF5YmUgdGhlcmUgd291bGQgYmUgYSBjaG9pY2Ugb2YgdmFsdWVzIG9mIG0pIGFuZCB0aGUgZmlu YWwgY2hvc2VuCj4gdmFsdWUgb2YgbSB3b3VsZCB0aGVuIGJlIHBsYWNlZCBpbiB0aGUgbGFiZWwu Cj4gCj4gWW91IGFyZSwgb2YgY291cnNlLCByaWdodCB0aGF0IGlzc3VlcyBsaWtlIGludGVyZmFj ZSBJRCBhbmQgY29tcG9uZW50Cj4gaW50ZXJmYWNlIElEIGFyZSBhbHNvIG5lY2Vzc2FyeSBmb3Ig WEMgcHJvZ3JhbW1pbmcuCj4gCj4gQQo+IAo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0K PiA+IEZyb206IFpoYW5nZmF0YWkgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dCj4gPiBT ZW50OiAxNCBOb3ZlbWJlciAyMDExIDAyOjIwCj4gPiBUbzogYWRyaWFuQG9sZGRvZy5jby51azsg Y2NhbXBAaWV0Zi5vcmcKPiA+IFN1YmplY3Q6IOetlOWkjTogW0NDQU1QXSBGbGV4aS1ncmlkIGlz c3VlIDIKPiA+Cj4gPiBIaSBBZHJpYW4sCj4gPgo+ID4gRG8geW91IGFncmVlIHRoYXQgIm0iIHNo b3VsZCBhbHNvIGJlIHB1dCBpbnRvIFRyYWZmaWMgUGFyYW1ldGVycwo+ID4gb2JqZWN0LCB3aGlj aCBpbmRpY2F0ZXMgaG93IG11Y2ggcmVzb3VyY2Ugc2hvdWxkIGJlIHJlc2VydmVkIGJlZm9yZQo+ IHdlCj4gPiBkZWNpZGUgd2hldGhlcmUgd2Ugc2hvdWxkIHB1dCAibSIgaW4gdGhlIExhYmVsPwo+ ID4KPiA+IFRhbGtpbmcgYWJvdXQgdGhlIExhYmVsIGRlZmluaXRpb24gZnJvbSBSRkMzNDcxLCB0 aGUgTGFiZWwgZGVmaW5lZCBpbgo+ID4gW2RyYWZ0LSB6aGFuZ10gY29udGFpbnMgImVub3VnaCBp bmZvcm1hdGlvbiIgdG8gYWxsb3cgdGhlIHJlY2VpdmluZwo+ID4gbm9kZSB0byBwcm9ncmFtCj4g aXRzCj4gPiBjcm9zcyBjb25uZWN0LCBpZS4sIG5vdGhpbmcgaXMgbWlzc2VkIGZyb20gbXkgdW5k ZXJzdGFuZGluZy4KPiA+Cj4gPiBXZSBrbm93IHRoYXQgdGhlIHJlY2l2ZWluZyBub2RlIGNhbm5v dCBwcm9ncmFtIGl0cyBjcm9zcyBjb25uZWN0Cj4gPiBjb3JyZWN0bHkgYnkgdXNpbmcgb25seSB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSAiTGFiZWwiLAo+ID4gYmVjYXVzZSBpdCBh bHNvIG5lZWRzIHRvCj4gZ2V0Cj4gPiBzb21lIG90aGVyIGluZm9ybWF0aW9uIChlLmcuLCBURSBs aW5rIG9yIGNvbXBvbmVudCBsaW5rIGluZm9ybWF0aW9uKQo+ID4gZnJvbQo+IG90aGVyCj4gPiBS U1ZQIG9iamVjdHMgc3VjaCBhcyBFUk8gb3IgUlNWUC1IT1AuCj4gPgo+ID4gUGxlYXNlIGNvcnJl Y3QgbWUgaWYgSSBoYXZlIGFueSBtaXN1bmRlcnN0YW5kaW5nLgo+ID4KPiA+IEZhdGFpCj4gPgo+ ID4gVGhhbmtzCj4gPgo+ID4KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KPiA+IOWPkeS7tuS6ujogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbY2NhbXAtYm91bmNl c0BpZXRmLm9yZ10g5Luj6KGoIEFkcmlhbgo+IEZhcnJlbAo+ID4gW2FkcmlhbkBvbGRkb2cuY28u dWtdCj4gPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQxMeaciDEz5pelIDk6MzQKPiA+IOWIsDogY2Nh bXBAaWV0Zi5vcmcKPiA+IOS4u+mimDogW0NDQU1QXSBGbGV4aS1ncmlkIGlzc3VlIDIKPiA+Cj4g PiBIaSwKPiA+Cj4gPiBTZWNvbmQgZW1haWwgb24gdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhl IGxhYmVsIGZvcm1hdHMgZGVmaW5lZCBpbgo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC0KPiBsYW1iZAo+ID4gYS1sYWJl bAo+ID4gYW5kCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1j Y2FtcC1mbGV4aWJsZS1ncmlkLXJzdnAtCj4gdGUtZXh0Cj4gPgo+ID4gVGhpcyBpc3N1ZSBpcyBt b3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhlIGZpcnN0IGlzc3VlLiBUaGlzIHF1ZXN0aW9uCj4gaGFz Cj4gPiB0d28KPiA+IHN1Yi1wb2ludHM6Cj4gPiBhLiB3aGVyZSBkbyB3ZSBjYXJyeSB0aGUgZmxl eGktZ3JpZCBtIHBhcmFtZXRlcj8KPiA+IGIuIHdoZXJlIGRvIHdlIGNhcnJ5IHRyYWZmaWMgcGFy YW1ldGVycyBmb3IgZmxleGktZ3JpZD8KPiA+Cj4gPiBkcmFmdC16aGFuZyBpcyBhIG1vcmUgY29t cHJlaGVuc2l2ZSBkb2N1bWVudCB0aGF0IGRyYWZ0LWZhcnJraW5nZWwKPiA+IGJlY2F1c2UgaXQg YWltcyB0byBjb3ZlciBhIG51bWJlciBvZiBzaWduaWZpY2FudCBzaWduYWxpbmcgcGFyYW1ldGVy cwo+IGZvciBSU1ZQLVRFLgo+ID4gZHJhZnQtZmFycmtpbmdlbCBvbmx5IGF0dGVtcHRzIHRvIGRl ZmluZSBhIGxhYmVsIHN0cnVjdHVyZS4KPiA+Cj4gPiBUaHVzLCB0aGUgcXVlc3Rpb24gd2UgbmVl ZCB0byByZXNvbHZlIGlzIG5vdCB3aGVyZSB0byBjYXJyeSB0aGUKPiA+IHRyYWZmaWMgcGFyYW1l dGVycyBmb3IgZmxleGktZ3JpZCwgYnV0IHdoYXQgY29uc3RpdHV0ZXMgYSBsYWJlbCBpbgo+IGZs ZXhpLWdyaWQ/Cj4gPgo+ID4gTWF5YmUgd2Ugc2hvdWxkIHN0YXJ0IHRoaXMgd2l0aCB0aGUgcXVl c3Rpb246IHdoYXQgaXMgYSBsYWJlbD8gUkZDCj4gMzQ3MSBzYXlzOgo+ID4KPiA+ICAgIEEgZ2Vu ZXJhbGl6ZWQgbGFiZWwgY29udGFpbnMgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGFsbG93IHRoZQo+ IHJlY2VpdmluZwo+ID4gICAgbm9kZSB0byBwcm9ncmFtIGl0cyBjcm9zcyBjb25uZWN0LCByZWdh cmRsZXNzIG9mIHRoZSB0eXBlIG9mIHRoaXMKPiA+ICAgIGNyb3NzIGNvbm5lY3QsIHN1Y2ggdGhh dCB0aGUgaW5ncmVzcyBzZWdtZW50cyBvZiB0aGUgcGF0aCBhcmUKPiA+ICAgIHByb3Blcmx5IGpv aW5lZC4KPiA+Cj4gPiBTbywgd2hhdCBpbmZvcm1hdGlvbiBkbyB3ZSBuZWVkIHRvIGNhcnJ5IGlu IGEgbGFiZWwgdG8gc2F0aXNmeSB0aGF0Pwo+IEkKPiA+IHRoaW5rCj4gaXQKPiA+IGlzIGEgZnVs bCBkZXNjcmlwdGlvbiBvZiB0aGUgY2hhbm5lbCwgYW5kIEFGQUlDUyBmb3IgZmxleGktZ3JpZCB0 aGlzCj4gPiBpbmNsdWRlcyB0aGUgbSBwYXJhbWV0ZXIuCj4gPgo+ID4gVGhhbmtzLAo+ID4gQWRy aWFuCj4gPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiA+IENDQU1QIG1haWxpbmcgbGlzdAo+ID4gQ0NBTVBAaWV0Zi5vcmcKPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAKPiAKPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IENDQU1QIG1haWxpbmcgbGlzdAo+IEND QU1QQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpDQ0FNUCBt YWlsaW5nIGxpc3QKQ0NBTVBAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcA== From daniele.ceccarelli@ericsson.com Sun Nov 13 19:30:50 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DF411E80E3; Sun, 13 Nov 2011 19:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh1M8xD-lznw; Sun, 13 Nov 2011 19:30:50 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6E74011E80DA; Sun, 13 Nov 2011 19:30:49 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-fb-4ec08b68bccd Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AD.BB.09514.86B80CE4; Mon, 14 Nov 2011 04:30:48 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 14 Nov 2011 04:30:47 +0100 From: Daniele Ceccarelli To: "ccamp-bounces@ietf.org" CC: "ccamp@ietf.org" Date: Mon, 14 Nov 2011 04:30:47 +0100 Thread-Topic: [CCAMP] Flexi-grid issue 2 Thread-Index: AQHMon3NOu8xmxmsd0qqQkbWUokvGw== Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:30:50 -0000 RXJyYXRhIGNvcnJpZ2UKCkhpIEN5cmlsIGFuZCBhbGwsCgpIYXZpbmcgdGhlIHNhbWUgcGFyYW1l dGVyIGluIHR3byBwbGFjZSBjYW4gb2Z0ZW4gYmUgdGhlIHJlY2lwZSBmb3IgYSBkaXNhc3Rlciwg aW4gY2FzZSB0aGVyZSBpcyB0aGUgbmVlZCB0byBoYXZlIGFuIGVuZC10by1lbmQgcGFyYW1ldGVy IHBsdXMgYW4gaG9wLWJ5LWhvcCBvbmUgd2UgbWlnaHQgY29uc2lkZXIgaGF2aW5nIHR3byBkaWZm ZXJlbnQgcGFyYW1ldGVycy4KCk5vdyB0aGUgcXVlc3Rpb24gaXM6aXMgdGhpcyBwb3NzaWJsZT8g SSBtZWFuLCBpcyBpdCBwb3NzaWJsZSB0aGF0IGEgZ2l2ZW4gc2xvdCB3aWR0aCBpcyBhc2tlZCBm cm9tIGVuZCB0byBlbmQgYnV0IGxpbmsgYnkgbGluayB0aGUgcmVxdWVzdCBjYW4gYmUgc2F0aXNm aWVkIHdpdGggZGlmZmVyZW50IHNsb3Qgd2lkdGg/IElmIHRoZSBhbnN3ZXIgaXMgbm8sIEkgdGhp bmsgcHV0dGluZyBtIGluIHRoZSB0cmFmZmljIHBhcmFtcyBjb3VsZCBiZSBlbm91Z2gsIGlmIHRo ZSBhbnN3ZXIgaXMgWUVTIEkgdGhpbmsgdHdvIHZhbHVlcyBtaWdodCBiZSBuZWVkZWQsIG9uZSBp biB0aGUgdHJhZmZpYyBwYXJhbWV0ZXJzIGFuZCB0aGUgb3RoZXIgaW4gdGhlIGxhYmVsLgoKTWF5 YmUgaXQgaXMgd29ydGggYWRkaW5nIHRoaXMgcXVlc3Rpb24gdG8gdGhlIGxpc3QgQWRyaWFuIGFz a2VkIGZvcj8gVW5sZXNzIHNvbWVvbmUgYWxyZWFkeSBoYXMgYSBxdWVzdGlvbi4KClRoYW5rcyAK RGFuaWVsZQoKKioqIEUtbWFpbCB2aWEgRE1FIHBvd2VyZWQgYnkgbW9iaWxlIGJyb2FkYmFuZCAq KioKCi0tT3JpZ2luYWwgbWVzc2FnZS0tLQpTZW5kZXI6ICJjY2FtcC1ib3VuY2VzQGlldGYub3Jn IiA8Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4KU2VudCB0aW1lOiAxMy9ub3YvMjAxMSAyMjoxMwpU bzogYWRyaWFuQG9sZGRvZy5jby51aywgemhhbmdmYXRhaUBodWF3ZWkuY29tLCBjY2FtcEBpZXRm Lm9yZwpTdWJqZWN0OiBSZTogW0NDQU1QXSBGbGV4aS1ncmlkIGlzc3VlIDIKCkhpLCAKCkl0IHNl ZW1zIHRvIG1lIHRoYXQgbSBzaG91bGQgYmUgaW4gdGhlIHRyYWZmaWMgcGFyYW1ldGVycyBiZWNh dXNlIGl0IGRlc2NyaWJlcyB0aGUgY2FwYWNpdHkuClJlZ2FyZGluZyB0aGUgbGFiZWwsIGlmIEkg dW5kZXJzdGFuZCBjb3JyZWN0bHkgUkZDNDYwNiAoYW5kIHJlY2VudCBPVE4gd29yaykgIHRoZSBs YWJlbCBhbG9uZSBpcyBub3QgdGhlIG9ubHkgCmluZm9ybWF0aW9uIChhbHNvIHdoZW4gYWRkaW5n IHRoZSBpbnRlcmZhY2UgaW5mb3JtYXRpb24pIGlzIG5vdCBlbm91Z2gsIHRoZSB0cmFmZmljIHBh cmFtZXRlcnMgYXJlIGFsc28gdXNlZC4KCkhhdmluZyB0aGUgIm0iIGFkZGl0aW9uYWxseSBpbiB0 aGUgbGFiZWwgc2VlbXMgYWxzbyB0byBiZSBjb25zaWRlcmVkLCBpdCBzZWVtcyBwb3NzaWJsZSB0 aGF0IHRoZSAibSIgbWlnaHQgYmUgaW5mbHVlbmNlZCBieSB0aGUgc3dpdGNoaW5nIGVsZW1lbnQg YW5kIGNoYW5nZSBob3AtYnktaG9wLgoKTXkgMiBjZW50cy4KCgpCZXN0IHJlZ2FyZHMgLyBNaXQg ZnJldW5kbGljaGVuIEdyw7zDn2VuCkN5cmlsIE1hcmdhcmlhCgoKPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYKPiBPZiBleHQgQWRyaWFuIEZhcnJlbAo+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMTQsIDIwMTEgMTA6NTUgQU0KPiBUbzogJ1poYW5nZmF0YWknOyBj Y2FtcEBpZXRmLm9yZwo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEZsZXhpLWdyaWQgaXNzdWUgMgo+ IAo+IEhpLAo+IAo+IEkndmUgbm90IHNwZW50IGEgbG90IG9mIHRpbWUgbG9va2luZyBhdCB0aGUg dHJhZmZpYyBwYXJhbWV0ZXJzLCBidXQKPiB5ZXMuIEl0IHNlZW1zIHRvIG1lIHRoYXQgcGFydCBv ZiByZXF1ZXN0aW5nIHRoZSBMU1AgY291bGQgaW5jbHVkZQo+IHNwZWNpZnlpbmcgYSBudW1iZXIg b2YgcGFyYW1ldGVycyByZWxhdGVkIHRvIGNhcGFjaXR5IGFuZCBjb25zdHJ1Y3Rpb24uCj4gVGhh dCB3b3VsZCBtZWFuIHRoYXQgIm0iIG1pZ2h0IHJlYXNvbmFibHkgYmUgaW4gdGhlIHRyYWZmaWMg cGFyYW1ldGVycwo+IChvciBtYXliZSB0aGVyZSB3b3VsZCBiZSBhIGNob2ljZSBvZiB2YWx1ZXMg b2YgbSkgYW5kIHRoZSBmaW5hbCBjaG9zZW4KPiB2YWx1ZSBvZiBtIHdvdWxkIHRoZW4gYmUgcGxh Y2VkIGluIHRoZSBsYWJlbC4KPiAKPiBZb3UgYXJlLCBvZiBjb3Vyc2UsIHJpZ2h0IHRoYXQgaXNz dWVzIGxpa2UgaW50ZXJmYWNlIElEIGFuZCBjb21wb25lbnQKPiBpbnRlcmZhY2UgSUQgYXJlIGFs c28gbmVjZXNzYXJ5IGZvciBYQyBwcm9ncmFtbWluZy4KPiAKPiBBCj4gCj4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTogWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlA aHVhd2VpLmNvbV0KPiA+IFNlbnQ6IDE0IE5vdmVtYmVyIDIwMTEgMDI6MjAKPiA+IFRvOiBhZHJp YW5Ab2xkZG9nLmNvLnVrOyBjY2FtcEBpZXRmLm9yZwo+ID4gU3ViamVjdDog562U5aSNOiBbQ0NB TVBdIEZsZXhpLWdyaWQgaXNzdWUgMgo+ID4KPiA+IEhpIEFkcmlhbiwKPiA+Cj4gPiBEbyB5b3Ug YWdyZWUgdGhhdCAibSIgc2hvdWxkIGFsc28gYmUgcHV0IGludG8gVHJhZmZpYyBQYXJhbWV0ZXJz Cj4gPiBvYmplY3QsIHdoaWNoIGluZGljYXRlcyBob3cgbXVjaCByZXNvdXJjZSBzaG91bGQgYmUg cmVzZXJ2ZWQgYmVmb3JlCj4gd2UKPiA+IGRlY2lkZSB3aGV0aGVyZSB3ZSBzaG91bGQgcHV0ICJt IiBpbiB0aGUgTGFiZWw/Cj4gPgo+ID4gVGFsa2luZyBhYm91dCB0aGUgTGFiZWwgZGVmaW5pdGlv biBmcm9tIFJGQzM0NzEsIHRoZSBMYWJlbCBkZWZpbmVkIGluCj4gPiBbZHJhZnQtIHpoYW5nXSBj b250YWlucyAiZW5vdWdoIGluZm9ybWF0aW9uIiB0byBhbGxvdyB0aGUgcmVjZWl2aW5nCj4gPiBu b2RlIHRvIHByb2dyYW0KPiBpdHMKPiA+IGNyb3NzIGNvbm5lY3QsIGllLiwgbm90aGluZyBpcyBt aXNzZWQgZnJvbSBteSB1bmRlcnN0YW5kaW5nLgo+ID4KPiA+IFdlIGtub3cgdGhhdCB0aGUgcmVj aXZlaW5nIG5vZGUgY2Fubm90IHByb2dyYW0gaXRzIGNyb3NzIGNvbm5lY3QKPiA+IGNvcnJlY3Rs eSBieSB1c2luZyBvbmx5IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhlICJMYWJlbCIs Cj4gPiBiZWNhdXNlIGl0IGFsc28gbmVlZHMgdG8KPiBnZXQKPiA+IHNvbWUgb3RoZXIgaW5mb3Jt YXRpb24gKGUuZy4sIFRFIGxpbmsgb3IgY29tcG9uZW50IGxpbmsgaW5mb3JtYXRpb24pCj4gPiBm cm9tCj4gb3RoZXIKPiA+IFJTVlAgb2JqZWN0cyBzdWNoIGFzIEVSTyBvciBSU1ZQLUhPUC4KPiA+ Cj4gPiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGhhdmUgYW55IG1pc3VuZGVyc3RhbmRpbmcuCj4g Pgo+ID4gRmF0YWkKPiA+Cj4gPiBUaGFua3MKPiA+Cj4gPgo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+ID4g5Y+R5Lu25Lq6OiBjY2FtcC1ib3VuY2VzQGlldGYu b3JnIFtjY2FtcC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQWRyaWFuCj4gRmFycmVsCj4gPiBb YWRyaWFuQG9sZGRvZy5jby51a10KPiA+IOWPkemAgeaXtumXtDogMjAxMeW5tDEx5pyIMTPml6Ug OTozNAo+ID4g5YiwOiBjY2FtcEBpZXRmLm9yZwo+ID4g5Li76aKYOiBbQ0NBTVBdIEZsZXhpLWdy aWQgaXNzdWUgMgo+ID4KPiA+IEhpLAo+ID4KPiA+IFNlY29uZCBlbWFpbCBvbiB0aGUgZGlmZmVy ZW5jZXMgYmV0d2VlbiB0aGUgbGFiZWwgZm9ybWF0cyBkZWZpbmVkIGluCj4gPiBodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhcnJraW5nZWwtY2NhbXAtZmxleGlncmlkLQo+ IGxhbWJkCj4gPiBhLWxhYmVsCj4gPiBhbmQKPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXpoYW5nLWNjYW1wLWZsZXhpYmxlLWdyaWQtcnN2cC0KPiB0ZS1leHQKPiA+Cj4g PiBUaGlzIGlzc3VlIGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGUgZmlyc3QgaXNzdWUuIFRo aXMgcXVlc3Rpb24KPiBoYXMKPiA+IHR3bwo+ID4gc3ViLXBvaW50czoKPiA+IGEuIHdoZXJlIGRv IHdlIGNhcnJ5IHRoZSBmbGV4aS1ncmlkIG0gcGFyYW1ldGVyPwo+ID4gYi4gd2hlcmUgZG8gd2Ug Y2FycnkgdHJhZmZpYyBwYXJhbWV0ZXJzIGZvciBmbGV4aS1ncmlkPwo+ID4KPiA+IGRyYWZ0LXpo YW5nIGlzIGEgbW9yZSBjb21wcmVoZW5zaXZlIGRvY3VtZW50IHRoYXQgZHJhZnQtZmFycmtpbmdl bAo+ID4gYmVjYXVzZSBpdCBhaW1zIHRvIGNvdmVyIGEgbnVtYmVyIG9mIHNpZ25pZmljYW50IHNp Z25hbGluZyBwYXJhbWV0ZXJzCj4gZm9yIFJTVlAtVEUuCj4gPiBkcmFmdC1mYXJya2luZ2VsIG9u bHkgYXR0ZW1wdHMgdG8gZGVmaW5lIGEgbGFiZWwgc3RydWN0dXJlLgo+ID4KPiA+IFRodXMsIHRo ZSBxdWVzdGlvbiB3ZSBuZWVkIHRvIHJlc29sdmUgaXMgbm90IHdoZXJlIHRvIGNhcnJ5IHRoZQo+ ID4gdHJhZmZpYyBwYXJhbWV0ZXJzIGZvciBmbGV4aS1ncmlkLCBidXQgd2hhdCBjb25zdGl0dXRl cyBhIGxhYmVsIGluCj4gZmxleGktZ3JpZD8KPiA+Cj4gPiBNYXliZSB3ZSBzaG91bGQgc3RhcnQg dGhpcyB3aXRoIHRoZSBxdWVzdGlvbjogd2hhdCBpcyBhIGxhYmVsPyBSRkMKPiAzNDcxIHNheXM6 Cj4gPgo+ID4gICAgQSBnZW5lcmFsaXplZCBsYWJlbCBjb250YWlucyBlbm91Z2ggaW5mb3JtYXRp b24gdG8gYWxsb3cgdGhlCj4gcmVjZWl2aW5nCj4gPiAgICBub2RlIHRvIHByb2dyYW0gaXRzIGNy b3NzIGNvbm5lY3QsIHJlZ2FyZGxlc3Mgb2YgdGhlIHR5cGUgb2YgdGhpcwo+ID4gICAgY3Jvc3Mg Y29ubmVjdCwgc3VjaCB0aGF0IHRoZSBpbmdyZXNzIHNlZ21lbnRzIG9mIHRoZSBwYXRoIGFyZQo+ ID4gICAgcHJvcGVybHkgam9pbmVkLgo+ID4KPiA+IFNvLCB3aGF0IGluZm9ybWF0aW9uIGRvIHdl IG5lZWQgdG8gY2FycnkgaW4gYSBsYWJlbCB0byBzYXRpc2Z5IHRoYXQ/Cj4gSQo+ID4gdGhpbmsK PiBpdAo+ID4gaXMgYSBmdWxsIGRlc2NyaXB0aW9uIG9mIHRoZSBjaGFubmVsLCBhbmQgQUZBSUNT IGZvciBmbGV4aS1ncmlkIHRoaXMKPiA+IGluY2x1ZGVzIHRoZSBtIHBhcmFtZXRlci4KPiA+Cj4g PiBUaGFua3MsCj4gPiBBZHJpYW4KPiA+Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+ID4gQ0NBTVAgbWFpbGluZyBsaXN0Cj4gPiBDQ0FNUEBpZXRm Lm9yZwo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcAo+IAo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gQ0NBTVAg bWFpbGluZyBsaXN0Cj4gQ0NBTVBAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCkNDQU1QIG1haWxpbmcgbGlzdApDQ0FNUEBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCkNDQU1QIG1haWxpbmcgbGlzdApDQ0FNUEBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w From li.yao3@zte.com.cn Sun Nov 13 19:39:21 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7A11E81B7; Sun, 13 Nov 2011 19:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.212 X-Spam-Level: X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtR1fng8DttJ; Sun, 13 Nov 2011 19:39:20 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9243F11E81AE; Sun, 13 Nov 2011 19:39:19 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131461793122; Mon, 14 Nov 2011 11:34:36 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.4712137674; Mon, 14 Nov 2011 11:39:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pAE3dC7E034246; Mon, 14 Nov 2011 11:39:12 +0800 (GMT-8) (envelope-from li.yao3@zte.com.cn) In-Reply-To: To: Iftekhar Hussain MIME-Version: 1.0 X-KeepSent: 17490748:7CA8AD28-48257948:001356B6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.yao3@zte.com.cn Date: Mon, 14 Nov 2011 11:40:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-14 11:39:14, Serialize complete at 2011-11-14 11:39:14 Content-Type: multipart/alternative; boundary="=_alternative 001413BA48257948_=" X-MAIL: mse01.zte.com.cn pAE3dC7E034246 Cc: Marco Sosa , Abinder Dhillon , "ccamp@ietf.org" , "ccamp-bounces@ietf.org" , Vinayak Dangui Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 03:39:21 -0000 This is a multipart message in MIME format. --=_alternative 001413BA48257948_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 IEhpIElmdGVraGFyOiANCg0KIFBsZWFzZSBzZWUgaW5saW5lLiANCiANCj4gY2NhbXAtYm91bmNl c0BpZXRmLm9yZyDQtNPaIDIwMTEtMTEtMTQgMTA6NDg6Mzg6DQo+IA0KPiA+IEhpIE1hbGNvbG0s IA0KPiA+IA0KPiA+IEFncmVlZCB3aXRoIHlvdXIgb2JzZXJ2YXRpb24gYWJvdXQgZnJhZ21lbnRh dGlvbiBpbiBmbGV4aWJsZSBncmlkLiANCj4gPiBCVFcsIHRoaXMgaXMgb25lIG9mIHRoZSByZWFz b25zIHdoeSB3ZSBuZWVkIHRvIGNvbnNpZGVyIGZsZXhpYmxlIA0KPiA+IGFwcHJvYWNoIGZvciBs YWJlbCBkZWZpbml0aW9uIHRoYXQgYWxsb3dzIGRlZnJhZ21lbnRhdGlvbiAoZS5nLiwgc2VlDQo+ ID4gc3BsaXQtc3BlY3RydW0gIHN1cGVyLWNoYW5uZWwgb3B0aW9uIGluICBodHRwOi8vdG9vbHMu aWV0Zi4NCj4gPiBvcmcvaHRtbC9kcmFmdC1odXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFi ZWwtMDIpLiANCj4gDQo+IDxZYW8+QWN0dWFsbHksIGZyYWdtZW50YXRpb24gd2lsbCBhcHBlYXIg YXMgdHJhZmZpYyBpcyANCj4gYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gVGhlIHdvcmsg b2YgZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZSANCj4gbGVmdCB0byBjb21wdXRhdGlvbiBlbnRp dHkgbGlrZSBQQ0UuIA0KPiBIb3dldmVyLCB3aGV0aGVyIHRoZSBzbGljZXMgd2lsbCBiZSBzd2l0 Y2hlZCB3aXRoIGNvbnRpbnVvdXMgZm9ybSBpc25vdCANCmNsZWFyLg0KDQo+IFtJZnRla2hhcl0g WWVzLCB0cnVlLCBmcmFnbWVudGF0aW9uIHdpbGwgb2NjdXIgYXMgYSByZXN1bHQgb2YgDQo+IGFk ZGluZy9yZW1vdmluZyBvcHRpY2FsIExTUHMuICBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4g DQo+IKGwZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZSBsZWZ0IHRvIGNvbXB1dGF0aW9uIGVudGl0 eaGxLiBXaHk/IEhvdyANCj4gd2lsbCBQQ0UgaGVscCBpbiB0aGlzIHJlZ2FyZCCoQyBjYW4geW91 IHBsZWFzZSBlbGFib3JhdGUuDQoNCg0KPFlhbz4gSG93IHRvIG9yZ2FuaXplIHRoZSBmcmFnbWVu dGFsIHNsaWNlcyBpbnRvIGNvbnRpbnVvdXMgb25lcyBpcyANCnNvbWV0aGluZyBsaWtlIHJlc291 cmNlcyBvcHRpbWl6YXRpb24uIA0KVGhpcyBjYW4gYmUgZG9uZSB3aXRoIFBDRS4gV2hpbGUgaG93 IHRvIGRvIGl0IGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljLg0KIA0KVGhhbmtzLA0KWWFvIExp DQogDQogDQo+ID4gUmVnYXJkaW5nIGNvbnNpZGVyYXRpb24gYWJvdXQgZ3VhcmQtYmFuZCwgSSB0 aGluaywgaXQgY2FuIGJlIA0KPiA+IGNvbnNpZGVyZWQgYXMgYSBwYXJ0IG9mIHBhdGggY29tcHV0 YXRpb24gY29uc3RyYWludCAtIGRvZXMgbm90IA0KPiA+IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYWR2 ZXJ0aXNlIHRoaXMgYXMgYSBwYXJ0IG9mIHJvdXRpbmcuIA0KPiANCj4gDQo+IDxZYW8+IEFncmVl LiANCj4gDQo+IA0KPiA+IA0KPiA+IFJlZ2FyZHMsIA0KPiA+IElmdGVraGFyIA0KPiA+IA0KPiA+ IEZyb206IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiBbbWFpbHRvOk1hbGNvbG0uQkVUVFNAenRl LmNvbS5jbl0gDQo+ID4gU2VudDogU3VuZGF5LCBOb3ZlbWJlciAxMywgMjAxMSA2OjExIFBNDQo+ ID4gVG86IGFkcmlhbkBvbGRkb2cuY28udWsNCj4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IGNjYW1w LWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBUcnlpbmcgdG8gcmVz b2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDEgDQo+ID4gDQo+ID4gSGkgQWRyaWFuLCANCj4gPiANCj4g PiBJbnRlcmVzdGluZyBxdWVzdGlvbnMsIGJ1dCBJIHRoaW5rIHdlIG5lZWQgdG8gY29uc2lkZXIg dGhlIGJpZ2dlciANCj4gPiBwaWN0dXJlIGZpcnN0LiAgQSBmZXcgcXVpY2sgdGhvdWdodHM6IA0K PiA+IA0KPiA+IE9uZSBtb3RpdmF0aW9uIGZvciB0aGUgZmxleGktZ3JpZCBpcyB0byBzdXBwb3J0 IHRoZSBuZXh0IGdlbmVyYXRpb24gDQo+ID4gb3B0aWNhbCBzaWduYWxzICg+MTAwR2IvcykgdGhh dCBjYW5ub3QgYmUgZWZmaWNpZW50bHkgYWNjb21tb2RhdGVkIA0KPiA+IHdpdGggdGhlIGN1cnJl bnQgZml4ZWQgZ3JpZC4gIEhvd2V2ZXIsIHdlIGNhbiBleHBlY3QgdG8gc2VlIGZsZXhpLQ0KPiA+ IGdyaWQgZGVwbG95ZWQgYmVmb3JlIHRoZXNlIGhpZ2hlciBiaXQgcmF0ZSBzeXN0ZW1zLiANCj4g PiANCj4gPiBUaGUgY3VycmVudCBmaXhlZCBncmlkIHByb3ZpZGVzIGFuIGltcGxpY2l0IGd1YXJk IGJhbmQgYmV0d2VlbiANCj4gPiBvcHRpY2FsIGNoYW5uZWxzIChhbmQgc2xvdHMgY2FuIGJlIGxl ZnQgdW51c2VkIHRvIGFsbG93IGEgZ3JlYXRlciANCj4gPiBndWFyZCBiYW5kKS4gIFdpdGggZmxl eGktZ3JpZCB3ZSB3aWxsIHByb2JhYmx5IG5lZWQgdG8gc3BlY2lmeSB0aGUgDQo+ID4gZ3VhcmQg YmFuZC4gIFRoZSBndWFyZCBiYW5kIHdpbGwgcHJvYmFibHkgbmVlZCB0byBkZWZpbmVkIGJ5IGEg UENFIA0KPiA+IGFwcGxpY2F0aW9uIGJ1dCB3ZSB3aWxsIG5lZWQgdG8gZGVmaW5lIHRoZSBwYXJh bWV0ZXJzLiANCj4gPiANCj4gPiBHaXZlbiB0aGF0IHRyYW5zaXRpbmcgYW4gT0FETSBuYXJyb3dz IHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdCBtYXkgDQo+ID4gYmUgcG9zc2libGUgdG8gb3B0aW1p emUgdGhlIG5ldHdvcmsgYnkgYWRqdXN0aW5nIHRoZSByZXF1ZXN0ZWQgDQo+ID4gYmFuZHdpZHRo IGJhc2VkIG9uIHRoZSBudW1iZXIgb2YgT0FETXMgaW4gdGhlIHBhdGguICBIb3cgd291bGQgd2Ug DQo+ID4gInJldGFpbiIgdGhpcyBpbmZvcm1hdGlvbiB0byBzdXBwb3J0IHJlc3RvcmF0aW9uLiAN Cj4gPiANCj4gPiBJIGV4cGVjdCB0aGF0IHdlIHdpbGwgaGF2ZSBhIGNvbmNhdGVuYXRpb24gb2Yg ZmxleGktZ3JpZCBhbmQgZml4ZWQgDQo+ID4gZ3JpZCBsaW5rcyAobWFuYWdlZCB2aWEgYSBQQ0Up IGluIHRoZSBuZXR3b3JrLiAgSG93IHdpbGwgd2Ugc2lnbmFsIA0KPiA+IGZvciBleGFtcGxlIGZv ciBhIHNsb3QgdG8gY2FycnkgMTBHYi9zIHNpZ25hbCBhY3Jvc3MgYSBuZXR3b3JrIHRoYXQgDQo+ ID4gaW5jbHVkZXMgdGhlIGNvbmNhdGVuYXRpb24gb2YgZml4ZWQgZ3JpZCBhbmQgZmxleGktZ3Jp ZCBzZWdtZW50cy4gDQo+ID4gVGhlIGltcGxpY2F0aW9uIG9mIHJvdXRpbmcgKFJXQSkgbWF5IGFs c28gYmUgaW50ZXJlc3RpbmcuIA0KPiA+IA0KPiA+IFRoZSBmbGV4aS1ncmlkIHdpbGwgcmVzdWx0 IGluIGJhbmR3aWR0aCBmcmFnbWVudGF0aW9uIGFzIHRyYWZmaWMgaXMgDQo+ID4gYWRkZWQgYW5k IHJlbW92ZWQgZnJvbSBsaW5rcy4gIFdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIG5lZWQgdG8gDQo+ ID4gZGVmcmFnbWVudCB0aGUgbGluay4gDQo+ID4gDQo+ID4gSSB0aGluayB0aGF0IHRoZSBpbXBs aWNhdGlvbnMgb2YgZmxleGktZ3JpZCBnbyBiZXlvbmQgc2lnbmFsbGluZyANCj4gPiBpbnRvIHJv dXRpbmcgKFJXQSkuIA0KPiA+IA0KPiA+IFRoZSBTRyAxNSB3aWxsIGJlIG1lZXRpbmcgaW4gRGVj ZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uIG9uIA0KPiA+IHRoZSB1c2Ugb2YgdGhlIGZs ZXhpLWdyaWQuICBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlkZSwgZWl0aGVyIA0KPiA+IGZv cm1hbGx5IG9yIGluZm9ybWFsbHkgYSBzZXQgb2YgcXVlc3Rpb25zLiANCj4gPiANCj4gPiBSZWdh cmRzLCANCj4gPiANCj4gPiBNYWxjb2xtIA0KPiA+IA0KPiANCj4gPiANCj4gPiAiQWRyaWFuIEZh cnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+IA0KPiA+IFNlbnQgYnk6IGNjYW1wLWJvdW5jZXNA aWV0Zi5vcmcgDQo+ID4gMTIvMTEvMjAxMSAwNToyOSBQTSANCj4gPiANCj4gPiBQbGVhc2UgcmVz cG9uZCB0bw0KPiA+IGFkcmlhbkBvbGRkb2cuY28udWsgDQo+ID4gDQo+ID4gVG8gDQo+ID4gDQo+ ID4gPGNjYW1wQGlldGYub3JnPiANCj4gPiANCj4gPiBjYyANCj4gPiANCj4gPiBTdWJqZWN0IA0K PiA+IA0KPiA+IFtDQ0FNUF0gVHJ5aW5nIHRvIHJlc29sdmUgZmxleGktZ3JpZCBpc3N1ZSAxIA0K PiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEhpLA0KPiA+IA0KPiA+IEkg d2FudGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNhbiBwcmltZSB0aGUgZGlzY3Vzc2lvbnMgb2YgDQpm bGV4aS1ncmlkbGFiZWxzIGluDQo+ID4gYWR2YW5jZSBvZiB0aGUgV0cgbWVldGluZ3MgdGhpcyB3 ZWVrLg0KPiA+IA0KPiA+IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBzdWNjZXNzZnVsbHkgYWdyZWVk IHRoYXQgdGhlcmUgYXJlIHR3byANCnNpZ25pZmljYW50DQo+ID4gZGlmZmVyZW5jZXMgYmV0d2Vl biB0aGUgbGFiZWwgZm9ybWF0cyBkZWZpbmVkIGluDQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC0NCj4gbGFtYmRhLWxh YmVsDQo+ID4gYW5kIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmct Y2NhbXAtZmxleGlibGUtZ3JpZC0NCj4gPiByc3ZwLXRlLWV4dA0KPiA+IA0KPiA+IFRoZSBmaXJz dCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5IG1pbm9yOg0KPiA+IA0KPiA+IFNob3VsZCB3ZSB1c2Ug YSBuZXcgdmFsdWUgZm9yIHRoZSBHcmlkIGZpZWxkIG9yIHNob3VsZCB3ZSBjb250aW51ZXRvIA0K dXNlIHRoZQ0KPiA+IHZhbHVlIHRoYXQgaW5kaWNhdGVzIERXRE0uDQo+ID4gDQo+ID4gSW4gZmF2 b3Igb2YgY29udGludWluZyB0byB1c2UgdGhlIERXRE0gdmFsdWUgaXMgdGhlIGZhY3QgdGhhdCB0 aGUgDQo+ID4gSVRVLVQgaGFzIG5vdA0KPiA+IGRlZmluZWQgYSBuZXcgZ3JpZCBmb3IgZmxleGli bGUgd2F2ZWxlbmd0aCBhc3NpZ25tZW50cy4gSW4gZmFjdCwgDQo+IHRoZUlUVS1UIHNheXMNCj4g PiB0aGF0IGZsZXhpYmxlIGFzc2lnbm1lbnRzIHNob3VsZCBiZSBtYWRlIGZyb20gdGhlIERXRE0g Z3JpZC4NCj4gPiANCj4gPiBPbiB0aGUgb3RoZXIgaGFuZCB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQg dGhhdCB0aGUgZmllbGRzIGluIEdNUExTIA0KPiBvYmplY3RzIGV4aXN0DQo+ID4gdG8gbWFrZSBp bXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5kIHRvIGNvbnZleSBpbmZvcm1hdGlvbi4gVGhlcmUgaXMg DQo+IG5vbmVlZCBmb3IgYQ0KPiA+IGRpcmVjdCBtYXBwaW5nIHRvIElUVS1UIGdyaWRzLg0KPiA+ IA0KPiA+IFRodXMsIHdoZW4gZHJhZnQtemhhbmcgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MSAoSVRV LVQgRFdETSkgaXQgaXMgDQo+IGNvcnJlY3QgdGhhdA0KPiA+IHRoZSBmbGV4aWJsZSBncmlkIHdh dmVsZW5ndGhzIHdpbGwgYmUgc3VnZ2VzdGVkIGZyb20gdGhlIElUVS1UIERXRE0gDQo+ID4gZ3Jp ZCwgYnV0IGl0DQo+ID4gaXMgbm90IGJlaW5nIGFzIGhlbHBmdWwgYXMgaXQgY291bGQgYmUuDQo+ ID4gDQo+ID4gV2hlbiBkcmFmdC1mYXJya2luZ2VsIHN1Z2dlc3RzIHVzaW5nIEdyaWQ9PTMgKElU VS1UIEZsZXgpIGl0IGlzIG5vdCANCmltcGx5aW5nDQo+ID4gdGhhdCB0aGVyZSBpcyBhIG5ldyBh bmQgZGlmZmVyZW50IGdyaWQgZGVmaW5lZCBieSB0aGUgSVRVLVQuIFdoYXQgDQo+IGl0aXMgc2F5 aW5nDQo+ID4gaXMgdGhhdCB0aGUgbGFiZWwgaXMgYSBmbGV4aS1ncmlkIGxhYmVsIHNlbGVjdGVk IGZyb20gdGhlIGdyaWQgDQo+IGRlZmluZWQgYnkgdGhlDQo+ID4gSVRVLVQgZm9yIHRoYXQgcHVy cG9zZSAoaS5lLiwgdGhlIERXRE0gZ3JpZCkuDQo+ID4gDQo+ID4gUGVyc29uYWxseSwgaSBkb24n dCBzZWUgdGhpcyBhcyBhIHZlcnkgbGFyZ2UgaXNzdWUuIGRyYWZ0LQ0KPiBmYXJya2luZ2Vsd291 bGQgd29yaw0KPiA+IGp1c3QgYXMgd2VsbCBpZiB3ZSBkZWNpZGUgdG8gdXNlIEdyaWQ9PTEuIGhv d2V2ZXIsIEkgdGhpbmsgaXQgaXMgDQo+ID4gbWFyZ2luYWxseSBtb3JlDQo+ID4gaGVscGZ1bCBh bmQgdXNlZnVsIHRvIGJlIGFibGUgdG8gcmVjb2duaXNlIHRoZSBkaWZmZXJlbnQgbGFiZWwgdXNl IA0KPiA+IGNhc2VzIChmaXhlZA0KPiA+IGdyaWQgLyBmbGV4aWJsZSBncmlkKSBieSBsb29raW5n IGF0IGEgZmllbGQgZWFybHkgaW4gdGhlIExhYmVsIG9iamVjdC4NCj4gPiBDb252ZXJzZWx5LCBJ IGRvbid0IGJlbGlldmUgdGhhdCBkcmFmdC16aGFuZyB3b3VsZCBiZSBicm9rZW4gYnkgDQo+IHVz aW5nIEdyaWQ9PTMuDQo+ID4gDQo+ID4gU28gbXkgY29tcHJvbWlzZSBwcm9wb3NhbCBpcyB0aGF0 IGJvdGggSS1EcyB1c2UgR3JpZD09My4gVGhlbiB3ZSBjYW4NCj4gPiBjb25jZW50cmF0ZQ0KPiA+ IG9uIHRoZSBtb3JlIHNpZ25pZmljYW50IHNlY29uZCBpc3N1ZSAoc2VlIHNlcGFyYXRlIGVtYWls KS4NCj4gPiANCj4gPiBXaGF0IGRvIGZvbGsgdGhpbms/DQo+ID4gDQo+ID4gQ2hlZXJzLA0KPiA+ IEFkcmlhbg0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4gQ0NBTVBAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBDQ0FNUCBtYWls aW5nIGxpc3QNCj4gPiBDQ0FNUEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCg== --=_alternative 001413BA48257948_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDtIaSBJZnRla2hhcjogPGJyPg0KPGJyPg0KIFBs ZWFzZSBzZWUgaW5saW5lLiA8YnI+DQogPGJyPg0KJmd0OyBjY2FtcC1ib3VuY2VzQGlldGYub3Jn INC009ogMjAxMS0xMS0xNCAxMDo0ODozODo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSBN YWxjb2xtLCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBBZ3JlZWQgd2l0 aCB5b3VyIG9ic2VydmF0aW9uIGFib3V0IGZyYWdtZW50YXRpb24gaW4gZmxleGlibGUNCmdyaWQu IDxicj4NCiZndDsgJmd0OyBCVFcsIHRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBu ZWVkIHRvIGNvbnNpZGVyIGZsZXhpYmxlDQo8YnI+DQomZ3Q7ICZndDsgYXBwcm9hY2ggZm9yIGxh YmVsIGRlZmluaXRpb24gdGhhdCBhbGxvd3MgZGVmcmFnbWVudGF0aW9uIChlLmcuLA0Kc2VlPGJy Pg0KJmd0OyAmZ3Q7IHNwbGl0LXNwZWN0cnVtICZuYnNwO3N1cGVyLWNoYW5uZWwgb3B0aW9uIGlu ICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLjxicj4NCiZndDsgJmd0OyBvcmcvaHRtbC9kcmFmdC1o dXNzYWluLWNjYW1wLXN1cGVyLWNoYW5uZWwtbGFiZWwtMDIpLiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgJmx0O1lhbyZndDtBY3R1YWxseSwgZnJhZ21lbnRhdGlvbiB3aWxsIGFwcGVhciBhcyB0cmFm ZmljIGlzIDxicj4NCiZndDsgYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gVGhlIHdvcmsg b2YgZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZQ0KPGJyPg0KJmd0OyBsZWZ0IHRvIGNvbXB1dGF0 aW9uIGVudGl0eSBsaWtlIFBDRS4gPGJyPg0KJmd0OyBIb3dldmVyLCB3aGV0aGVyIHRoZSBzbGlj ZXMgd2lsbCBiZSBzd2l0Y2hlZCB3aXRoIGNvbnRpbnVvdXMgZm9ybQ0KaXNub3QgY2xlYXIuPGJy Pg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFtJZnRla2hhcl0gWWVz LCB0cnVlLCBmcmFnbWVudGF0aW9uIHdpbGwgb2NjdXINCmFzIGEgcmVzdWx0IG9mIDxicj4NCiZn dDsgYWRkaW5nL3JlbW92aW5nIG9wdGljYWwgTFNQcy4gJm5ic3A7SSBhbSBub3Qgc3VyZSB3aGF0 IHlvdSBtZWFuIDxicj4NCiZndDsgobBkZWZyYWdtZW50YXRpb24gc2hvdWxkIGJlIGxlZnQgdG8g Y29tcHV0YXRpb24gZW50aXR5obEuIFdoeT8gSG93DQo8YnI+DQomZ3Q7IHdpbGwgUENFIGhlbHAg aW4gdGhpcyByZWdhcmQgqEMgY2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlLjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmx0O1lhbyZndDsgSG93IHRvIG9yZ2Fu aXplIHRoZSBmcmFnbWVudGFsIHNsaWNlcw0KaW50byBjb250aW51b3VzIG9uZXMgaXMgc29tZXRo aW5nIGxpa2UgcmVzb3VyY2VzIG9wdGltaXphdGlvbi4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5UaGlzIGNhbiBiZSBkb25lIHdpdGggUENFLiBXaGlsZSBob3cgdG8gZG8gaXQg aXMgaW1wbGVtZW50YXRpb24NCnNwZWNpZmljLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jm5ic3A7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmtzLDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WWFvIExpPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZuYnNwOzxicj4NCiZndDsgJmd0OyBSZWdhcmRpbmcgY29uc2lkZXJhdGlvbiBhYm91dCBndWFy ZC1iYW5kLCBJIHRoaW5rLCBpdCBjYW4gYmUNCjxicj4NCiZndDsgJmd0OyBjb25zaWRlcmVkIGFz IGEgcGFydCBvZiBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0cmFpbnQgLSBkb2VzIG5vdA0KPGJyPg0K Jmd0OyAmZ3Q7IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYWR2ZXJ0aXNlIHRoaXMgYXMgYSBwYXJ0IG9m IHJvdXRpbmcuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZsdDtZYW8mZ3Q7IEFn cmVlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom Z3Q7ICZndDsgUmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7IElmdGVraGFyIDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiBb bWFpbHRvOk1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbl0NCjxicj4NCiZndDsgJmd0OyBTZW50OiBT dW5kYXksIE5vdmVtYmVyIDEzLCAyMDExIDY6MTEgUE08YnI+DQomZ3Q7ICZndDsgVG86IGFkcmlh bkBvbGRkb2cuY28udWs8YnI+DQomZ3Q7ICZndDsgQ2M6IGNjYW1wQGlldGYub3JnOyBjY2FtcC1i b3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFRyeWlu ZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxi cj4NCiZndDsgJmd0OyBIaSBBZHJpYW4sIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg SW50ZXJlc3RpbmcgcXVlc3Rpb25zLCBidXQgSSB0aGluayB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRo ZSBiaWdnZXINCjxicj4NCiZndDsgJmd0OyBwaWN0dXJlIGZpcnN0LiAmbmJzcDtBIGZldyBxdWlj ayB0aG91Z2h0czogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPbmUgbW90aXZhdGlv biBmb3IgdGhlIGZsZXhpLWdyaWQgaXMgdG8gc3VwcG9ydCB0aGUgbmV4dCBnZW5lcmF0aW9uDQo8 YnI+DQomZ3Q7ICZndDsgb3B0aWNhbCBzaWduYWxzICgmZ3Q7MTAwR2IvcykgdGhhdCBjYW5ub3Qg YmUgZWZmaWNpZW50bHkgYWNjb21tb2RhdGVkDQo8YnI+DQomZ3Q7ICZndDsgd2l0aCB0aGUgY3Vy cmVudCBmaXhlZCBncmlkLiAmbmJzcDtIb3dldmVyLCB3ZSBjYW4gZXhwZWN0IHRvDQpzZWUgZmxl eGktPGJyPg0KJmd0OyAmZ3Q7IGdyaWQgZGVwbG95ZWQgYmVmb3JlIHRoZXNlIGhpZ2hlciBiaXQg cmF0ZSBzeXN0ZW1zLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBjdXJyZW50 IGZpeGVkIGdyaWQgcHJvdmlkZXMgYW4gaW1wbGljaXQgZ3VhcmQgYmFuZCBiZXR3ZWVuDQo8YnI+ DQomZ3Q7ICZndDsgb3B0aWNhbCBjaGFubmVscyAoYW5kIHNsb3RzIGNhbiBiZSBsZWZ0IHVudXNl ZCB0byBhbGxvdyBhIGdyZWF0ZXINCjxicj4NCiZndDsgJmd0OyBndWFyZCBiYW5kKS4gJm5ic3A7 V2l0aCBmbGV4aS1ncmlkIHdlIHdpbGwgcHJvYmFibHkgbmVlZCB0byBzcGVjaWZ5DQp0aGUgPGJy Pg0KJmd0OyAmZ3Q7IGd1YXJkIGJhbmQuICZuYnNwO1RoZSBndWFyZCBiYW5kIHdpbGwgcHJvYmFi bHkgbmVlZCB0byBkZWZpbmVkDQpieSBhIFBDRSA8YnI+DQomZ3Q7ICZndDsgYXBwbGljYXRpb24g YnV0IHdlIHdpbGwgbmVlZCB0byBkZWZpbmUgdGhlIHBhcmFtZXRlcnMuICZuYnNwOw0KPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBHaXZlbiB0aGF0IHRyYW5zaXRpbmcgYW4gT0FETSBu YXJyb3dzIHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdA0KbWF5IDxicj4NCiZndDsgJmd0OyBiZSBw b3NzaWJsZSB0byBvcHRpbWl6ZSB0aGUgbmV0d29yayBieSBhZGp1c3RpbmcgdGhlIHJlcXVlc3Rl ZA0KPGJyPg0KJmd0OyAmZ3Q7IGJhbmR3aWR0aCBiYXNlZCBvbiB0aGUgbnVtYmVyIG9mIE9BRE1z IGluIHRoZSBwYXRoLiAmbmJzcDtIb3cNCndvdWxkIHdlIDxicj4NCiZndDsgJmd0OyAmcXVvdDty ZXRhaW4mcXVvdDsgdGhpcyBpbmZvcm1hdGlvbiB0byBzdXBwb3J0IHJlc3RvcmF0aW9uLiA8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgZXhwZWN0IHRoYXQgd2Ugd2lsbCBoYXZlIGEg Y29uY2F0ZW5hdGlvbiBvZiBmbGV4aS1ncmlkIGFuZA0KZml4ZWQgPGJyPg0KJmd0OyAmZ3Q7IGdy aWQgbGlua3MgKG1hbmFnZWQgdmlhIGEgUENFKSBpbiB0aGUgbmV0d29yay4gJm5ic3A7SG93IHdp bGwNCndlIHNpZ25hbCA8YnI+DQomZ3Q7ICZndDsgZm9yIGV4YW1wbGUgZm9yIGEgc2xvdCB0byBj YXJyeSAxMEdiL3Mgc2lnbmFsIGFjcm9zcyBhIG5ldHdvcmsNCnRoYXQgPGJyPg0KJmd0OyAmZ3Q7 IGluY2x1ZGVzIHRoZSBjb25jYXRlbmF0aW9uIG9mIGZpeGVkIGdyaWQgYW5kIGZsZXhpLWdyaWQg c2VnbWVudHMuDQombmJzcDs8YnI+DQomZ3Q7ICZndDsgVGhlIGltcGxpY2F0aW9uIG9mIHJvdXRp bmcgKFJXQSkgbWF5IGFsc28gYmUgaW50ZXJlc3RpbmcuIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgVGhlIGZsZXhpLWdyaWQgd2lsbCByZXN1bHQgaW4gYmFuZHdpZHRoIGZyYWdtZW50 YXRpb24gYXMgdHJhZmZpYw0KaXMgPGJyPg0KJmd0OyAmZ3Q7IGFkZGVkIGFuZCByZW1vdmVkIGZy b20gbGlua3MuICZuYnNwO1dlIG5lZWQgdG8gY29uc2lkZXIgdGhlIG5lZWQNCnRvIDxicj4NCiZn dDsgJmd0OyBkZWZyYWdtZW50IHRoZSBsaW5rLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IEkgdGhpbmsgdGhhdCB0aGUgaW1wbGljYXRpb25zIG9mIGZsZXhpLWdyaWQgZ28gYmV5b25k IHNpZ25hbGxpbmcNCjxicj4NCiZndDsgJmd0OyBpbnRvIHJvdXRpbmcgKFJXQSkuIDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIFNHIDE1IHdpbGwgYmUgbWVldGluZyBpbiBEZWNl bWJlciBhbmQgd2lsbCBob2xkIGRpc2N1c3Npb24NCm9uIDxicj4NCiZndDsgJmd0OyB0aGUgdXNl IG9mIHRoZSBmbGV4aS1ncmlkLiAmbmJzcDtJdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlkZSwN CmVpdGhlciA8YnI+DQomZ3Q7ICZndDsgZm9ybWFsbHkgb3IgaW5mb3JtYWxseSBhIHNldCBvZiBx dWVzdGlvbnMuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUmVnYXJkcywgPGJyPg0K Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBNYWxjb2xtIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7QWRyaWFuIEZhcnJlbCZx dW90OyAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNlbnQgYnk6 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgPGJyPg0KJmd0OyAmZ3Q7IDEyLzExLzIwMTEgMDU6Mjkg UE0gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQbGVhc2UgcmVzcG9uZCB0bzxicj4N CiZndDsgJmd0OyBhZHJpYW5Ab2xkZG9nLmNvLnVrIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgVG8gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbHQ7Y2NhbXBAaWV0Zi5v cmcmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgY2MgPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBTdWJqZWN0IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg W0NDQU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDEgPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSw8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNh biBwcmltZSB0aGUgZGlzY3Vzc2lvbnMgb2YgZmxleGktZ3JpZGxhYmVscw0KaW48YnI+DQomZ3Q7 ICZndDsgYWR2YW5jZSBvZiB0aGUgV0cgbWVldGluZ3MgdGhpcyB3ZWVrLjxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgSXQgbG9va3MgbGlrZSB3ZSBoYXZlIHN1Y2Nlc3NmdWxseSBhZ3Jl ZWQgdGhhdCB0aGVyZSBhcmUgdHdvDQpzaWduaWZpY2FudDxicj4NCiZndDsgJmd0OyBkaWZmZXJl bmNlcyBiZXR3ZWVuIHRoZSBsYWJlbCBmb3JtYXRzIGRlZmluZWQgaW48YnI+DQomZ3Q7ICZndDsg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZs ZXhpZ3JpZC08YnI+DQomZ3Q7IGxhbWJkYS1sYWJlbDxicj4NCiZndDsgJmd0OyBhbmQgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1mbGV4aWJsZS1ncmlk LTxicj4NCiZndDsgJmd0OyByc3ZwLXRlLWV4dDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgVGhlIGZpcnN0IHBvaW50IHNlZW1zIHJlbGF0aXZlbHkgbWlub3I6PGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyBTaG91bGQgd2UgdXNlIGEgbmV3IHZhbHVlIGZvciB0aGUgR3JpZCBm aWVsZCBvciBzaG91bGQgd2UgY29udGludWV0bw0KdXNlIHRoZTxicj4NCiZndDsgJmd0OyB2YWx1 ZSB0aGF0IGluZGljYXRlcyBEV0RNLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4g ZmF2b3Igb2YgY29udGludWluZyB0byB1c2UgdGhlIERXRE0gdmFsdWUgaXMgdGhlIGZhY3QgdGhh dA0KdGhlIDxicj4NCiZndDsgJmd0OyBJVFUtVCBoYXMgbm90PGJyPg0KJmd0OyAmZ3Q7IGRlZmlu ZWQgYSBuZXcgZ3JpZCBmb3IgZmxleGlibGUgd2F2ZWxlbmd0aCBhc3NpZ25tZW50cy4gSW4gZmFj dCwNCjxicj4NCiZndDsgdGhlSVRVLVQgc2F5czxicj4NCiZndDsgJmd0OyB0aGF0IGZsZXhpYmxl IGFzc2lnbm1lbnRzIHNob3VsZCBiZSBtYWRlIGZyb20gdGhlIERXRE0gZ3JpZC48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIHRoZSBvdGhlciBoYW5kIHdlIG5lZWQgdG8gdW5kZXJz dGFuZCB0aGF0IHRoZSBmaWVsZHMgaW4gR01QTFMNCjxicj4NCiZndDsgb2JqZWN0cyBleGlzdDxi cj4NCiZndDsgJmd0OyB0byBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llciBhbmQgdG8gY29udmV5 IGluZm9ybWF0aW9uLiBUaGVyZQ0KaXMgPGJyPg0KJmd0OyBub25lZWQgZm9yIGE8YnI+DQomZ3Q7 ICZndDsgZGlyZWN0IG1hcHBpbmcgdG8gSVRVLVQgZ3JpZHMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBUaHVzLCB3aGVuIGRyYWZ0LXpoYW5nIHN1Z2dlc3RzIHVzaW5nIEdyaWQ9PTEg KElUVS1UIERXRE0pIGl0DQppcyA8YnI+DQomZ3Q7IGNvcnJlY3QgdGhhdDxicj4NCiZndDsgJmd0 OyB0aGUgZmxleGlibGUgZ3JpZCB3YXZlbGVuZ3RocyB3aWxsIGJlIHN1Z2dlc3RlZCBmcm9tIHRo ZSBJVFUtVA0KRFdETSA8YnI+DQomZ3Q7ICZndDsgZ3JpZCwgYnV0IGl0PGJyPg0KJmd0OyAmZ3Q7 IGlzIG5vdCBiZWluZyBhcyBoZWxwZnVsIGFzIGl0IGNvdWxkIGJlLjxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgV2hlbiBkcmFmdC1mYXJya2luZ2VsIHN1Z2dlc3RzIHVzaW5nIEdyaWQ9 PTMgKElUVS1UIEZsZXgpIGl0DQppcyBub3QgaW1wbHlpbmc8YnI+DQomZ3Q7ICZndDsgdGhhdCB0 aGVyZSBpcyBhIG5ldyBhbmQgZGlmZmVyZW50IGdyaWQgZGVmaW5lZCBieSB0aGUgSVRVLVQuDQpX aGF0IDxicj4NCiZndDsgaXRpcyBzYXlpbmc8YnI+DQomZ3Q7ICZndDsgaXMgdGhhdCB0aGUgbGFi ZWwgaXMgYSBmbGV4aS1ncmlkIGxhYmVsIHNlbGVjdGVkIGZyb20gdGhlIGdyaWQNCjxicj4NCiZn dDsgZGVmaW5lZCBieSB0aGU8YnI+DQomZ3Q7ICZndDsgSVRVLVQgZm9yIHRoYXQgcHVycG9zZSAo aS5lLiwgdGhlIERXRE0gZ3JpZCkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBQZXJz b25hbGx5LCBpIGRvbid0IHNlZSB0aGlzIGFzIGEgdmVyeSBsYXJnZSBpc3N1ZS4gZHJhZnQtPGJy Pg0KJmd0OyBmYXJya2luZ2Vsd291bGQgd29yazxicj4NCiZndDsgJmd0OyBqdXN0IGFzIHdlbGwg aWYgd2UgZGVjaWRlIHRvIHVzZSBHcmlkPT0xLiBob3dldmVyLCBJIHRoaW5rIGl0DQppcyA8YnI+ DQomZ3Q7ICZndDsgbWFyZ2luYWxseSBtb3JlPGJyPg0KJmd0OyAmZ3Q7IGhlbHBmdWwgYW5kIHVz ZWZ1bCB0byBiZSBhYmxlIHRvIHJlY29nbmlzZSB0aGUgZGlmZmVyZW50IGxhYmVsDQp1c2UgPGJy Pg0KJmd0OyAmZ3Q7IGNhc2VzIChmaXhlZDxicj4NCiZndDsgJmd0OyBncmlkIC8gZmxleGlibGUg Z3JpZCkgYnkgbG9va2luZyBhdCBhIGZpZWxkIGVhcmx5IGluIHRoZSBMYWJlbA0Kb2JqZWN0Ljxi cj4NCiZndDsgJmd0OyBDb252ZXJzZWx5LCBJIGRvbid0IGJlbGlldmUgdGhhdCBkcmFmdC16aGFu ZyB3b3VsZCBiZSBicm9rZW4NCmJ5IDxicj4NCiZndDsgdXNpbmcgR3JpZD09My48YnI+DQomZ3Q7 ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFNvIG15IGNvbXByb21pc2UgcHJvcG9zYWwgaXMgdGhhdCBi b3RoIEktRHMgdXNlIEdyaWQ9PTMuIFRoZW4NCndlIGNhbjxicj4NCiZndDsgJmd0OyBjb25jZW50 cmF0ZTxicj4NCiZndDsgJmd0OyBvbiB0aGUgbW9yZSBzaWduaWZpY2FudCBzZWNvbmQgaXNzdWUg KHNlZSBzZXBhcmF0ZSBlbWFpbCkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBXaGF0 IGRvIGZvbGsgdGhpbms/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBDaGVlcnMsPGJy Pg0KJmd0OyAmZ3Q7IEFkcmlhbjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsg Q0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0 OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQom Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7ICZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IENDQU1QQGll dGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2NhbXA8L2ZvbnQ+PC90dD4NCg== --=_alternative 001413BA48257948_=-- From IHussain@infinera.com Sun Nov 13 20:17:53 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE911E808D; Sun, 13 Nov 2011 20:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVbDOpLAb2L8; Sun, 13 Nov 2011 20:17:51 -0800 (PST) Received: from SV-CASHT-PROD3.infinera.com (sv-casht-prod3.infinera.com [8.4.225.26]) by ietfa.amsl.com (Postfix) with ESMTP id 60E7E11E8086; Sun, 13 Nov 2011 20:17:51 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by SV-CASHT-PROD3.infinera.com ([::1]) with mapi id 14.01.0339.001; Sun, 13 Nov 2011 20:17:50 -0800 From: Iftekhar Hussain To: "li.yao3@zte.com.cn" Thread-Topic: [CCAMP] Trying to resolve flexi-grid issue 1 Thread-Index: AQHMon7/egeoJzjwUUWf5MNwoaMdd5WrwsKw Date: Mon, 14 Nov 2011 04:17:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE87SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: Marco Sosa , Abinder Dhillon , "ccamp@ietf.org" , "ccamp-bounces@ietf.org" , Vinayak Dangui Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 04:17:54 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE87SVEXDBPROD1infi_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Please see in-line From: li.yao3@zte.com.cn [mailto:li.yao3@zte.com.cn] Sent: Sunday, November 13, 2011 7:40 PM To: Iftekhar Hussain Cc: Abinder Dhillon; ccamp@ietf.org; ccamp-bounces@ietf.org; Marco Sosa; Vi= nayak Dangui Subject: RE: [CCAMP] Trying to resolve flexi-grid issue 1 Hi Iftekhar: Please see inline. > ccamp-bounces@ietf.org =1B$B > > Hi Malcolm, > > > > Agreed with your observation about fragmentation in flexible grid. > > BTW, this is one of the reasons why we need to consider flexible > > approach for label definition that allows defragmentation (e.g., see > > split-spectrum super-channel option in http://tools.ietf. > > org/html/draft-hussain-ccamp-super-channel-label-02). > > Actually, fragmentation will appear as traffic is > added and removed from links. The work of defragmentation should be > left to computation entity like PCE. > However, whether the slices will be switched with continuous form isnot c= lear. > [Iftekhar] Yes, true, fragmentation will occur as a result of > adding/removing optical LSPs. I am not sure what you mean > =1B$B!H=1B(Bdefragmentation should be left to computation entity=1B$B!I= =1B(B. Why? How > will PCE help in this regard - can you please elaborate. How to organize the fragmental slices into continuous ones is somethi= ng like resources optimization. This can be done with PCE. While how to do it is implementation specific. [Iftekhar] I am not sure how defragmentation can be achieved with PCE alone= . Thanks, Iftekhar Thanks, Yao Li > > Regarding consideration about guard-band, I think, it can be > > considered as a part of path computation constraint - does not > > necessarily need to advertise this as a part of routing. > > > Agree. > > > > > > Regards, > > Iftekhar > > > > From: Malcolm.BETTS@zte.com.cn [mailto= :Malcolm.BETTS@zte.com.cn] > > Sent: Sunday, November 13, 2011 6:11 PM > > To: adrian@olddog.co.uk > > Cc: ccamp@ietf.org; ccamp-bounces@ietf.org > > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 > > > > Hi Adrian, > > > > Interesting questions, but I think we need to consider the bigger > > picture first. A few quick thoughts: > > > > One motivation for the flexi-grid is to support the next generation > > optical signals (>100Gb/s) that cannot be efficiently accommodated > > with the current fixed grid. However, we can expect to see flexi- > > grid deployed before these higher bit rate systems. > > > > The current fixed grid provides an implicit guard band between > > optical channels (and slots can be left unused to allow a greater > > guard band). With flexi-grid we will probably need to specify the > > guard band. The guard band will probably need to defined by a PCE > > application but we will need to define the parameters. > > > > Given that transiting an OADM narrows the optical bandwidth it may > > be possible to optimize the network by adjusting the requested > > bandwidth based on the number of OADMs in the path. How would we > > "retain" this information to support restoration. > > > > I expect that we will have a concatenation of flexi-grid and fixed > > grid links (managed via a PCE) in the network. How will we signal > > for example for a slot to carry 10Gb/s signal across a network that > > includes the concatenation of fixed grid and flexi-grid segments. > > The implication of routing (RWA) may also be interesting. > > > > The flexi-grid will result in bandwidth fragmentation as traffic is > > added and removed from links. We need to consider the need to > > defragment the link. > > > > I think that the implications of flexi-grid go beyond signalling > > into routing (RWA). > > > > The SG 15 will be meeting in December and will hold discussion on > > the use of the flexi-grid. It would be useful to provide, either > > formally or informally a set of questions. > > > > Regards, > > > > Malcolm > > > > > > > "Adrian Farrel" > > > Sent by: ccamp-bounces@ietf.org > > 12/11/2011 05:29 PM > > > > Please respond to > > adrian@olddog.co.uk > > > > To > > > > > > > > > cc > > > > Subject > > > > [CCAMP] Trying to resolve flexi-grid issue 1 > > > > > > > > > > > > > > Hi, > > > > I wanted to see whether we can prime the discussions of flexi-gridlabel= s in > > advance of the WG meetings this week. > > > > It looks like we have successfully agreed that there are two significan= t > > differences between the label formats defined in > > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid- > lambda-label > > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid- > > rsvp-te-ext > > > > The first point seems relatively minor: > > > > Should we use a new value for the Grid field or should we continueto us= e the > > value that indicates DWDM. > > > > In favor of continuing to use the DWDM value is the fact that the > > ITU-T has not > > defined a new grid for flexible wavelength assignments. In fact, > theITU-T says > > that flexible assignments should be made from the DWDM grid. > > > > On the other hand we need to understand that the fields in GMPLS > objects exist > > to make implementation easier and to convey information. There is > noneed for a > > direct mapping to ITU-T grids. > > > > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it is > correct that > > the flexible grid wavelengths will be suggested from the ITU-T DWDM > > grid, but it > > is not being as helpful as it could be. > > > > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it is not= implying > > that there is a new and different grid defined by the ITU-T. What > itis saying > > is that the label is a flexi-grid label selected from the grid > defined by the > > ITU-T for that purpose (i.e., the DWDM grid). > > > > Personally, i don't see this as a very large issue. draft- > farrkingelwould work > > just as well if we decide to use Grid=3D=3D1. however, I think it is > > marginally more > > helpful and useful to be able to recognise the different label use > > cases (fixed > > grid / flexible grid) by looking at a field early in the Label object. > > Conversely, I don't believe that draft-zhang would be broken by > using Grid=3D=3D3. > > > > So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then we ca= n > > concentrate > > on the more significant second issue (see separate email). > > > > What do folk think? > > > > Cheers, > > Adrian > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE87SVEXDBPROD1infi_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Please see in-line

 <= /p>

From: li.yao3@= zte.com.cn [mailto:li.yao3@zte.com.cn]
Sent: Sunday, November 13, 2011 7:40 PM
To: Iftekhar Hussain
Cc: Abinder Dhillon; ccamp@ietf.org; ccamp-bounces@ietf.org; Marco S= osa; Vinayak Dangui
Subject: RE: [CCAMP] Trying to resolve flexi-grid issue 1=

 


 Hi Iftekhar:

Please see inline.

> ccamp-bounces@ietf.org =1B$B 2011-11-14 10:48:38:
>
> > Hi Malcolm,
> >  
> > Agreed with your observation about fragmentation in flexible = grid.
> > BTW, this is one of the reasons why we need to consider flexi= ble
> > approach for label definition that allows defragmentation (e.= g., see
> > split-spectrum  super-channel option in  http://tools.ietf.
> > org/html/draft-hussain-ccamp-super-channel-label-02). >
> <Yao>Actually, fragmentation will appear as traffic is =
> added and removed from links. The work of defragmentation should b= e
> left to computation entity like PCE.
> However, whether the slices will be switched with continuous form = isnot clear.

> [Iftekhar] Yes, true, fragmentati= on will occur as a result of
> adding/removing optical LSPs.  I am not sure what you mean
> =1B$B!H=1B(Bdefragmentation should be left to computation entity= =1B$B!I=1B(B. Why? How
> will PCE help in this regard – can you please elaborate.


<Yao> How to organize the fragme= ntal slices into continuous ones is something like resources optimization.
This can be done with PCE. While how t= o do it is implementation specific.

<= /p>

[Iftekhar] I am not s= ure how defragmentation can be achieved with PCE alone.

 

Thanks,

Iftekhar


Thanks,
Yao Li
 
 
> > Regarding consideration about guard-band, I think, it can be =
> > considered as a part of path computation constraint - does no= t
> > necessarily need to advertise this as a part of routing.
>
>
> <Yao> Agree.
>
>
> >  
> > Regards,
> > Iftekhar
> >  
> > From: Malcolm.BET= TS@zte.com.cn [mailto:Malcolm.BETTS@= zte.com.cn]
> > Sent: Sunday, November 13, 2011 6:11 PM
> > To: adrian@olddog.co.u= k
> > Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
> > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
> >  
> > Hi Adrian,
> >
> > Interesting questions, but I think we need to consider the bi= gger
> > picture first.  A few quick thoughts:
> >
> > One motivation for the flexi-grid is to support the next gene= ration
> > optical signals (>100Gb/s) that cannot be efficiently acco= mmodated
> > with the current fixed grid.  However, we can expect to = see flexi-
> > grid deployed before these higher bit rate systems.
> >
> > The current fixed grid provides an implicit guard band betwee= n
> > optical channels (and slots can be left unused to allow a gre= ater
> > guard band).  With flexi-grid we will probably need to s= pecify the
> > guard band.  The guard band will probably need to define= d by a PCE
> > application but we will need to define the parameters.  =
> >
> > Given that transiting an OADM narrows the optical bandwidth i= t may
> > be possible to optimize the network by adjusting the requeste= d
> > bandwidth based on the number of OADMs in the path.  How= would we
> > "retain" this information to support restoration. <= /tt>
> >
> > I expect that we will have a concatenation of flexi-grid and = fixed
> > grid links (managed via a PCE) in the network.  How will= we signal
> > for example for a slot to carry 10Gb/s signal across a networ= k that
> > includes the concatenation of fixed grid and flexi-grid segme= nts.  
> > The implication of routing (RWA) may also be interesting.
> >
> > The flexi-grid will result in bandwidth fragmentation as traf= fic is
> > added and removed from links.  We need to consider the n= eed to
> > defragment the link.
> >
> > I think that the implications of flexi-grid go beyond signall= ing
> > into routing (RWA).
> >
> > The SG 15 will be meeting in December and will hold discussio= n on
> > the use of the flexi-grid.  It would be useful to provid= e, either
> > formally or informally a set of questions.
> >
> > Regards,
> >
> > Malcolm
> >
>
> >
> > "Adrian Farrel" <adrian@olddog.co.uk>
> > Sent by: ccamp-boun= ces@ietf.org
> > 12/11/2011 05:29 PM
> >
> > Please respond to
> > adrian@olddog.co.uk
> >
> > To
> >
> > <ccamp@ietf.org> =
> >
> > cc
> >
> > Subject
> >
> > [CCAMP] Trying to resolve flexi-grid issue 1
> >
> >  
> >
> >
> >
> >
> > Hi,
> >
> > I wanted to see whether we can prime the discussions of flexi= -gridlabels in
> > advance of the WG meetings this week.
> >
> > It looks like we have successfully agreed that there are two = significant
> > differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-<= br> > lambda-label
> > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid- > > rsvp-te-ext
> >
> > The first point seems relatively minor:
> >
> > Should we use a new value for the Grid field or should we con= tinueto use the
> > value that indicates DWDM.
> >
> > In favor of continuing to use the DWDM value is the fact that= the
> > ITU-T has not
> > defined a new grid for flexible wavelength assignments. In fa= ct,
> theITU-T says
> > that flexible assignments should be made from the DWDM grid.<= /tt>
> >
> > On the other hand we need to understand that the fields in GM= PLS
> objects exist
> > to make implementation easier and to convey information. Ther= e is
> noneed for a
> > direct mapping to ITU-T grids.
> >
> > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM= ) it is
> correct that
> > the flexible grid wavelengths will be suggested from the ITU-= T DWDM
> > grid, but it
> > is not being as helpful as it could be.
> >
> > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex)= it is not implying
> > that there is a new and different grid defined by the ITU-T. = What
> itis saying
> > is that the label is a flexi-grid label selected from the gri= d
> defined by the
> > ITU-T for that purpose (i.e., the DWDM grid).
> >
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work
> > just as well if we decide to use Grid=3D=3D1. however, I thin= k it is
> > marginally more
> > helpful and useful to be able to recognise the different labe= l use
> > cases (fixed
> > grid / flexible grid) by looking at a field early in the Labe= l object.
> > Conversely, I don't believe that draft-zhang would be broken = by
> using Grid=3D=3D3.
> >
> > So my compromise proposal is that both I-Ds use Grid=3D=3D3. = Then we can
> > concentrate
> > on the more significant second issue (see separate email).
> >
> > What do folk think?
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https= ://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https= ://www.ietf.org/mailman/listinfo/ccamp

--_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3AE87SVEXDBPROD1infi_-- From huawei.danli@huawei.com Sun Nov 13 21:13:18 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFE511E8134; Sun, 13 Nov 2011 21:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-3.782, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-WNfBEN8IxB; Sun, 13 Nov 2011 21:13:17 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3096F11E81DF; Sun, 13 Nov 2011 21:13:17 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM00MXZX62L5@szxga05-in.huawei.com>; Mon, 14 Nov 2011 13:13:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUM005LCX61BV@szxga05-in.huawei.com>; Mon, 14 Nov 2011 13:13:14 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY79372; Mon, 14 Nov 2011 13:13:12 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 13:13:10 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 13:13:03 +0800 Date: Mon, 14 Nov 2011 05:13:03 +0000 From: Huawei danli In-reply-to: X-Originating-IP: [172.24.2.41] To: Iftekhar Hussain , "li.yao3@zte.com.cn" Message-id: <92A1F6CF27D54D4DA5364E59D892A02A0C804CF3@szxeml526-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h3taoPjX1AeKHCcbodpoRQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] Trying to resolve flexi-grid issue 1 Thread-index: AQHMon8GAFOjkk0W4EKoD4wNx1gg2JWrPaKAgACUGM4= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Marco Sosa , Abinder Dhillon , "ccamp@ietf.org" , "ccamp-bounces@ietf.org" , Vinayak Dangui Subject: [CCAMP] =?gb2312?b?tPC4tDogIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdy?= =?gb2312?b?aWQgaXNzdWUgMQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 05:13:19 -0000 --Boundary_(ID_h3taoPjX1AeKHCcbodpoRQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 TWF5YmUgYSBzdGF0ZWZ1bCBQQ0UgaXMgbmVlZGVkLiBBY3R1YWxseSB0aGUgZGVmcmFnbWVudGF0 aW9uIG1heSBjYXVzZSB0aGUgbGluayByZXNvdXJjZSBhZGp1c3RtZW50LCBhbmQgdGhlbiB0cmln Z2VyIHRoZSBsaW5rIGJlIG1vdmVkIGZyb20gb25lIGxhYmVsIHRvIGFub3RoZXIgbGFiZWwuDQoN CkRhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBjY2FtcC1i b3VuY2VzQGlldGYub3JnIFtjY2FtcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIElmdGVraGFyIEh1 c3NhaW4gW0lIdXNzYWluQGluZmluZXJhLmNvbV0NCreiy83KsbzkOiAyMDExxOoxMdTCMTTI1SAx MjoxNw0Ktb06IGxpLnlhbzNAenRlLmNvbS5jbg0KQ2M6IE1hcmNvIFNvc2E7IEFiaW5kZXIgRGhp bGxvbjsgY2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc7IFZpbmF5YWsgRGFu Z3VpDQrW98ziOiBSZTogW0NDQU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3Vl IDENCg0KUGxlYXNlIHNlZSBpbi1saW5lDQoNCkZyb206IGxpLnlhbzNAenRlLmNvbS5jbiBbbWFp bHRvOmxpLnlhbzNAenRlLmNvbS5jbl0NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTMsIDIwMTEg Nzo0MCBQTQ0KVG86IElmdGVraGFyIEh1c3NhaW4NCkNjOiBBYmluZGVyIERoaWxsb247IGNjYW1w QGlldGYub3JnOyBjY2FtcC1ib3VuY2VzQGlldGYub3JnOyBNYXJjbyBTb3NhOyBWaW5heWFrIERh bmd1aQ0KU3ViamVjdDogUkU6IFtDQ0FNUF0gVHJ5aW5nIHRvIHJlc29sdmUgZmxleGktZ3JpZCBp c3N1ZSAxDQoNCg0KIEhpIElmdGVraGFyOg0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KPiBjY2Ft cC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPiDQtNPaIDIw MTEtMTEtMTQgMTA6NDg6Mzg6DQo+DQo+ID4gSGkgTWFsY29sbSwNCj4gPg0KPiA+IEFncmVlZCB3 aXRoIHlvdXIgb2JzZXJ2YXRpb24gYWJvdXQgZnJhZ21lbnRhdGlvbiBpbiBmbGV4aWJsZSBncmlk Lg0KPiA+IEJUVywgdGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgdG8gY29u c2lkZXIgZmxleGlibGUNCj4gPiBhcHByb2FjaCBmb3IgbGFiZWwgZGVmaW5pdGlvbiB0aGF0IGFs bG93cyBkZWZyYWdtZW50YXRpb24gKGUuZy4sIHNlZQ0KPiA+IHNwbGl0LXNwZWN0cnVtICBzdXBl ci1jaGFubmVsIG9wdGlvbiBpbiAgaHR0cDovL3Rvb2xzLmlldGYuDQo+ID4gb3JnL2h0bWwvZHJh ZnQtaHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVsLTAyKS4NCj4NCj4gPFlhbz5BY3R1 YWxseSwgZnJhZ21lbnRhdGlvbiB3aWxsIGFwcGVhciBhcyB0cmFmZmljIGlzDQo+IGFkZGVkIGFu ZCByZW1vdmVkIGZyb20gbGlua3MuIFRoZSB3b3JrIG9mIGRlZnJhZ21lbnRhdGlvbiBzaG91bGQg YmUNCj4gbGVmdCB0byBjb21wdXRhdGlvbiBlbnRpdHkgbGlrZSBQQ0UuDQo+IEhvd2V2ZXIsIHdo ZXRoZXIgdGhlIHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGggY29udGludW91cyBmb3JtIGlz bm90IGNsZWFyLg0KDQo+IFtJZnRla2hhcl0gWWVzLCB0cnVlLCBmcmFnbWVudGF0aW9uIHdpbGwg b2NjdXIgYXMgYSByZXN1bHQgb2YNCj4gYWRkaW5nL3JlbW92aW5nIG9wdGljYWwgTFNQcy4gIEkg YW0gbm90IHN1cmUgd2hhdCB5b3UgbWVhbg0KPiChsGRlZnJhZ21lbnRhdGlvbiBzaG91bGQgYmUg bGVmdCB0byBjb21wdXRhdGlvbiBlbnRpdHmhsS4gV2h5PyBIb3cNCj4gd2lsbCBQQ0UgaGVscCBp biB0aGlzIHJlZ2FyZCCoQyBjYW4geW91IHBsZWFzZSBlbGFib3JhdGUuDQoNCg0KPFlhbz4gSG93 IHRvIG9yZ2FuaXplIHRoZSBmcmFnbWVudGFsIHNsaWNlcyBpbnRvIGNvbnRpbnVvdXMgb25lcyBp cyBzb21ldGhpbmcgbGlrZSByZXNvdXJjZXMgb3B0aW1pemF0aW9uLg0KVGhpcyBjYW4gYmUgZG9u ZSB3aXRoIFBDRS4gV2hpbGUgaG93IHRvIGRvIGl0IGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmlj Lg0KDQpbSWZ0ZWtoYXJdIEkgYW0gbm90IHN1cmUgaG93IGRlZnJhZ21lbnRhdGlvbiBjYW4gYmUg YWNoaWV2ZWQgd2l0aCBQQ0UgYWxvbmUuDQoNClRoYW5rcywNCklmdGVraGFyDQoNClRoYW5rcywN CllhbyBMaQ0KDQoNCj4gPiBSZWdhcmRpbmcgY29uc2lkZXJhdGlvbiBhYm91dCBndWFyZC1iYW5k LCBJIHRoaW5rLCBpdCBjYW4gYmUNCj4gPiBjb25zaWRlcmVkIGFzIGEgcGFydCBvZiBwYXRoIGNv bXB1dGF0aW9uIGNvbnN0cmFpbnQgLSBkb2VzIG5vdA0KPiA+IG5lY2Vzc2FyaWx5IG5lZWQgdG8g YWR2ZXJ0aXNlIHRoaXMgYXMgYSBwYXJ0IG9mIHJvdXRpbmcuDQo+DQo+DQo+IDxZYW8+IEFncmVl Lg0KPg0KPg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBJZnRla2hhcg0KPiA+DQo+ID4gRnJvbTog TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuPG1haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+ IFttYWlsdG86TWFsY29sbS5CRVRUU0B6dGUuY29tLmNuXTxtYWlsdG86W21haWx0bzpNYWxjb2xt LkJFVFRTQHp0ZS5jb20uY25dPg0KPiA+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTMsIDIwMTEg NjoxMSBQTQ0KPiA+IFRvOiBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9n LmNvLnVrPg0KPiA+IENjOiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBj Y2FtcC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KPiA+ IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUg MQ0KPiA+DQo+ID4gSGkgQWRyaWFuLA0KPiA+DQo+ID4gSW50ZXJlc3RpbmcgcXVlc3Rpb25zLCBi dXQgSSB0aGluayB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBiaWdnZXINCj4gPiBwaWN0dXJlIGZp cnN0LiAgQSBmZXcgcXVpY2sgdGhvdWdodHM6DQo+ID4NCj4gPiBPbmUgbW90aXZhdGlvbiBmb3Ig dGhlIGZsZXhpLWdyaWQgaXMgdG8gc3VwcG9ydCB0aGUgbmV4dCBnZW5lcmF0aW9uDQo+ID4gb3B0 aWNhbCBzaWduYWxzICg+MTAwR2IvcykgdGhhdCBjYW5ub3QgYmUgZWZmaWNpZW50bHkgYWNjb21t b2RhdGVkDQo+ID4gd2l0aCB0aGUgY3VycmVudCBmaXhlZCBncmlkLiAgSG93ZXZlciwgd2UgY2Fu IGV4cGVjdCB0byBzZWUgZmxleGktDQo+ID4gZ3JpZCBkZXBsb3llZCBiZWZvcmUgdGhlc2UgaGln aGVyIGJpdCByYXRlIHN5c3RlbXMuDQo+ID4NCj4gPiBUaGUgY3VycmVudCBmaXhlZCBncmlkIHBy b3ZpZGVzIGFuIGltcGxpY2l0IGd1YXJkIGJhbmQgYmV0d2Vlbg0KPiA+IG9wdGljYWwgY2hhbm5l bHMgKGFuZCBzbG90cyBjYW4gYmUgbGVmdCB1bnVzZWQgdG8gYWxsb3cgYSBncmVhdGVyDQo+ID4g Z3VhcmQgYmFuZCkuICBXaXRoIGZsZXhpLWdyaWQgd2Ugd2lsbCBwcm9iYWJseSBuZWVkIHRvIHNw ZWNpZnkgdGhlDQo+ID4gZ3VhcmQgYmFuZC4gIFRoZSBndWFyZCBiYW5kIHdpbGwgcHJvYmFibHkg bmVlZCB0byBkZWZpbmVkIGJ5IGEgUENFDQo+ID4gYXBwbGljYXRpb24gYnV0IHdlIHdpbGwgbmVl ZCB0byBkZWZpbmUgdGhlIHBhcmFtZXRlcnMuDQo+ID4NCj4gPiBHaXZlbiB0aGF0IHRyYW5zaXRp bmcgYW4gT0FETSBuYXJyb3dzIHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdCBtYXkNCj4gPiBiZSBw b3NzaWJsZSB0byBvcHRpbWl6ZSB0aGUgbmV0d29yayBieSBhZGp1c3RpbmcgdGhlIHJlcXVlc3Rl ZA0KPiA+IGJhbmR3aWR0aCBiYXNlZCBvbiB0aGUgbnVtYmVyIG9mIE9BRE1zIGluIHRoZSBwYXRo LiAgSG93IHdvdWxkIHdlDQo+ID4gInJldGFpbiIgdGhpcyBpbmZvcm1hdGlvbiB0byBzdXBwb3J0 IHJlc3RvcmF0aW9uLg0KPiA+DQo+ID4gSSBleHBlY3QgdGhhdCB3ZSB3aWxsIGhhdmUgYSBjb25j YXRlbmF0aW9uIG9mIGZsZXhpLWdyaWQgYW5kIGZpeGVkDQo+ID4gZ3JpZCBsaW5rcyAobWFuYWdl ZCB2aWEgYSBQQ0UpIGluIHRoZSBuZXR3b3JrLiAgSG93IHdpbGwgd2Ugc2lnbmFsDQo+ID4gZm9y IGV4YW1wbGUgZm9yIGEgc2xvdCB0byBjYXJyeSAxMEdiL3Mgc2lnbmFsIGFjcm9zcyBhIG5ldHdv cmsgdGhhdA0KPiA+IGluY2x1ZGVzIHRoZSBjb25jYXRlbmF0aW9uIG9mIGZpeGVkIGdyaWQgYW5k IGZsZXhpLWdyaWQgc2VnbWVudHMuDQo+ID4gVGhlIGltcGxpY2F0aW9uIG9mIHJvdXRpbmcgKFJX QSkgbWF5IGFsc28gYmUgaW50ZXJlc3RpbmcuDQo+ID4NCj4gPiBUaGUgZmxleGktZ3JpZCB3aWxs IHJlc3VsdCBpbiBiYW5kd2lkdGggZnJhZ21lbnRhdGlvbiBhcyB0cmFmZmljIGlzDQo+ID4gYWRk ZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gIFdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIG5lZWQg dG8NCj4gPiBkZWZyYWdtZW50IHRoZSBsaW5rLg0KPiA+DQo+ID4gSSB0aGluayB0aGF0IHRoZSBp bXBsaWNhdGlvbnMgb2YgZmxleGktZ3JpZCBnbyBiZXlvbmQgc2lnbmFsbGluZw0KPiA+IGludG8g cm91dGluZyAoUldBKS4NCj4gPg0KPiA+IFRoZSBTRyAxNSB3aWxsIGJlIG1lZXRpbmcgaW4gRGVj ZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uIG9uDQo+ID4gdGhlIHVzZSBvZiB0aGUgZmxl eGktZ3JpZC4gIEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwcm92aWRlLCBlaXRoZXINCj4gPiBmb3Jt YWxseSBvciBpbmZvcm1hbGx5IGEgc2V0IG9mIHF1ZXN0aW9ucy4NCj4gPg0KPiA+IFJlZ2FyZHMs DQo+ID4NCj4gPiBNYWxjb2xtDQo+ID4NCj4NCj4gPg0KPiA+ICJBZHJpYW4gRmFycmVsIiA8YWRy aWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+DQo+ID4gU2VudCBi eTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4N Cj4gPiAxMi8xMS8yMDExIDA1OjI5IFBNDQo+ID4NCj4gPiBQbGVhc2UgcmVzcG9uZCB0bw0KPiA+ IGFkcmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+DQo+ID4NCj4g PiBUbw0KPiA+DQo+ID4gPGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+DQo+ ID4NCj4gPiBjYw0KPiA+DQo+ID4gU3ViamVjdA0KPiA+DQo+ID4gW0NDQU1QXSBUcnlpbmcgdG8g cmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDENCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPiBIaSwNCj4gPg0KPiA+IEkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNhbiBwcmltZSB0 aGUgZGlzY3Vzc2lvbnMgb2YgZmxleGktZ3JpZGxhYmVscyBpbg0KPiA+IGFkdmFuY2Ugb2YgdGhl IFdHIG1lZXRpbmdzIHRoaXMgd2Vlay4NCj4gPg0KPiA+IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBz dWNjZXNzZnVsbHkgYWdyZWVkIHRoYXQgdGhlcmUgYXJlIHR3byBzaWduaWZpY2FudA0KPiA+IGRp ZmZlcmVuY2VzIGJldHdlZW4gdGhlIGxhYmVsIGZvcm1hdHMgZGVmaW5lZCBpbg0KPiA+IGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFycmtpbmdlbC1jY2FtcC1mbGV4aWdy aWQtDQo+IGxhbWJkYS1sYWJlbA0KPiA+IGFuZCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXpoYW5nLWNjYW1wLWZsZXhpYmxlLWdyaWQtDQo+ID4gcnN2cC10ZS1leHQNCj4g Pg0KPiA+IFRoZSBmaXJzdCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5IG1pbm9yOg0KPiA+DQo+ID4g U2hvdWxkIHdlIHVzZSBhIG5ldyB2YWx1ZSBmb3IgdGhlIEdyaWQgZmllbGQgb3Igc2hvdWxkIHdl IGNvbnRpbnVldG8gdXNlIHRoZQ0KPiA+IHZhbHVlIHRoYXQgaW5kaWNhdGVzIERXRE0uDQo+ID4N Cj4gPiBJbiBmYXZvciBvZiBjb250aW51aW5nIHRvIHVzZSB0aGUgRFdETSB2YWx1ZSBpcyB0aGUg ZmFjdCB0aGF0IHRoZQ0KPiA+IElUVS1UIGhhcyBub3QNCj4gPiBkZWZpbmVkIGEgbmV3IGdyaWQg Zm9yIGZsZXhpYmxlIHdhdmVsZW5ndGggYXNzaWdubWVudHMuIEluIGZhY3QsDQo+IHRoZUlUVS1U IHNheXMNCj4gPiB0aGF0IGZsZXhpYmxlIGFzc2lnbm1lbnRzIHNob3VsZCBiZSBtYWRlIGZyb20g dGhlIERXRE0gZ3JpZC4NCj4gPg0KPiA+IE9uIHRoZSBvdGhlciBoYW5kIHdlIG5lZWQgdG8gdW5k ZXJzdGFuZCB0aGF0IHRoZSBmaWVsZHMgaW4gR01QTFMNCj4gb2JqZWN0cyBleGlzdA0KPiA+IHRv IG1ha2UgaW1wbGVtZW50YXRpb24gZWFzaWVyIGFuZCB0byBjb252ZXkgaW5mb3JtYXRpb24uIFRo ZXJlIGlzDQo+IG5vbmVlZCBmb3IgYQ0KPiA+IGRpcmVjdCBtYXBwaW5nIHRvIElUVS1UIGdyaWRz Lg0KPiA+DQo+ID4gVGh1cywgd2hlbiBkcmFmdC16aGFuZyBzdWdnZXN0cyB1c2luZyBHcmlkPT0x IChJVFUtVCBEV0RNKSBpdCBpcw0KPiBjb3JyZWN0IHRoYXQNCj4gPiB0aGUgZmxleGlibGUgZ3Jp ZCB3YXZlbGVuZ3RocyB3aWxsIGJlIHN1Z2dlc3RlZCBmcm9tIHRoZSBJVFUtVCBEV0RNDQo+ID4g Z3JpZCwgYnV0IGl0DQo+ID4gaXMgbm90IGJlaW5nIGFzIGhlbHBmdWwgYXMgaXQgY291bGQgYmUu DQo+ID4NCj4gPiBXaGVuIGRyYWZ0LWZhcnJraW5nZWwgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MyAo SVRVLVQgRmxleCkgaXQgaXMgbm90IGltcGx5aW5nDQo+ID4gdGhhdCB0aGVyZSBpcyBhIG5ldyBh bmQgZGlmZmVyZW50IGdyaWQgZGVmaW5lZCBieSB0aGUgSVRVLVQuIFdoYXQNCj4gaXRpcyBzYXlp bmcNCj4gPiBpcyB0aGF0IHRoZSBsYWJlbCBpcyBhIGZsZXhpLWdyaWQgbGFiZWwgc2VsZWN0ZWQg ZnJvbSB0aGUgZ3JpZA0KPiBkZWZpbmVkIGJ5IHRoZQ0KPiA+IElUVS1UIGZvciB0aGF0IHB1cnBv c2UgKGkuZS4sIHRoZSBEV0RNIGdyaWQpLg0KPiA+DQo+ID4gUGVyc29uYWxseSwgaSBkb24ndCBz ZWUgdGhpcyBhcyBhIHZlcnkgbGFyZ2UgaXNzdWUuIGRyYWZ0LQ0KPiBmYXJya2luZ2Vsd291bGQg d29yaw0KPiA+IGp1c3QgYXMgd2VsbCBpZiB3ZSBkZWNpZGUgdG8gdXNlIEdyaWQ9PTEuIGhvd2V2 ZXIsIEkgdGhpbmsgaXQgaXMNCj4gPiBtYXJnaW5hbGx5IG1vcmUNCj4gPiBoZWxwZnVsIGFuZCB1 c2VmdWwgdG8gYmUgYWJsZSB0byByZWNvZ25pc2UgdGhlIGRpZmZlcmVudCBsYWJlbCB1c2UNCj4g PiBjYXNlcyAoZml4ZWQNCj4gPiBncmlkIC8gZmxleGlibGUgZ3JpZCkgYnkgbG9va2luZyBhdCBh IGZpZWxkIGVhcmx5IGluIHRoZSBMYWJlbCBvYmplY3QuDQo+ID4gQ29udmVyc2VseSwgSSBkb24n dCBiZWxpZXZlIHRoYXQgZHJhZnQtemhhbmcgd291bGQgYmUgYnJva2VuIGJ5DQo+IHVzaW5nIEdy aWQ9PTMuDQo+ID4NCj4gPiBTbyBteSBjb21wcm9taXNlIHByb3Bvc2FsIGlzIHRoYXQgYm90aCBJ LURzIHVzZSBHcmlkPT0zLiBUaGVuIHdlIGNhbg0KPiA+IGNvbmNlbnRyYXRlDQo+ID4gb24gdGhl IG1vcmUgc2lnbmlmaWNhbnQgc2Vjb25kIGlzc3VlIChzZWUgc2VwYXJhdGUgZW1haWwpLg0KPiA+ DQo+ID4gV2hhdCBkbyBmb2xrIHRoaW5rPw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IEFkcmlhbg0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gPiBDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NBTVBA aWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4gQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGll dGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAN Cg== --Boundary_(ID_h3taoPjX1AeKHCcbodpoRQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Maybe a stateful PCE is needed. Actually the defragmentation may caus= e the link resource adjustment, and then trigger the link be moved from one= label to another label.

Dan

=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.or= g [ccamp-bounces@ietf.org] =B4=FA=B1=ED Iftekhar Hussain [IHussain@infinera= .com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 12:17
=B5=BD: li.yao3@zte.com.cn
Cc: Marco Sosa; Abinder Dhillon; ccamp@ietf.org; ccamp-bounces@ietf.= org; Vinayak Dangui
=D6=F7=CC=E2: Re: [CCAMP] Trying to resolve flexi-grid issue 1

Please see in-line

 

From: li.yao= 3@zte.com.cn [mailto:li.yao3@zte.com.cn]
Sent: Sunday, November 13, 2011 7:40 PM
To: Iftekhar Hussain
Cc: Abinder Dhillon; ccamp@ietf.org; ccamp-bounces@ietf.org; Marco S= osa; Vinayak Dangui
Subject: RE: [CCAMP] Trying to resolve flexi-grid issue 1

 


 Hi Iftekhar:

Please see inline.

> ccamp-= bounces@ietf.org =D0=B4=D3=DA 2011-11-14 10:48:38:
>
> > Hi Malcolm,
> >  
> > Agreed with your observation about fragmentation in flexible = grid.
> > BTW, this is one of the reasons why we need to consider flexi= ble
> > approach for label definition that allows defragmentation (e.= g., see
> > split-spectrum  super-channel option in  http://tools.ietf.
> > org/html/draft-hussain-ccamp-super-channel-label-02). >
> <Yao>Actually, fragmentation will appear as traffic is =
> added and removed from links. The work of defragmentation should b= e
> left to computation entity like PCE.
> However, whether the slices will be switched with continuous form = isnot clear.

> [Iftekhar] Yes, true, fragmentati= on will occur as a result of
> adding/removing optical LSPs.  I am not sure what you mean
> =A1=B0defragmentation should be left to computation entity=A1=B1. = Why? How
> will PCE help in this regard =A8C can you please elaborate.


<Yao> How to organize the fragme= ntal slices into continuous ones is something like resources optimization.
This can be done with PCE. While how t= o do it is implementation specific.

[Iftekhar] I am not= sure how defragmentation can be achieved with PCE alone.

 <= /p>

Thanks,=

Iftekhar


Thanks,
Yao Li
 
 
> > Regarding consideration about guard-band, I think, it can be =
> > considered as a part of path computation constraint - does no= t
> > necessarily need to advertise this as a part of routing.
>
>
> <Yao> Agree.
>
>
> >  
> > Regards,
> > Iftekhar
> >  
> > From: Malcolm.BETTS@zte.com.cn [mai= lto:Malcolm.BETTS@zte.com.cn]
> > Sent: Sunday, November 13, 2011 6:11 PM
> > To: = adrian@olddog.co.uk
> > Cc: ccamp= @ietf.org; ccamp-bounces@ietf.org
> > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
> >  
> > Hi Adrian,
> >
> > Interesting questions, but I think we need to consider the bi= gger
> > picture first.  A few quick thoughts:
> >
> > One motivation for the flexi-grid is to support the next gene= ration
> > optical signals (>100Gb/s) that cannot be efficiently acco= mmodated
> > with the current fixed grid.  However, we can expect to = see flexi-
> > grid deployed before these higher bit rate systems.
> >
> > The current fixed grid provides an implicit guard band betwee= n
> > optical channels (and slots can be left unused to allow a gre= ater
> > guard band).  With flexi-grid we will probably need to s= pecify the
> > guard band.  The guard band will probably need to define= d by a PCE
> > application but we will need to define the parameters.  =
> >
> > Given that transiting an OADM narrows the optical bandwidth i= t may
> > be possible to optimize the network by adjusting the requeste= d
> > bandwidth based on the number of OADMs in the path.  How= would we
> > "retain" this information to support restoration. <= /tt>
> >
> > I expect that we will have a concatenation of flexi-grid and = fixed
> > grid links (managed via a PCE) in the network.  How will= we signal
> > for example for a slot to carry 10Gb/s signal across a networ= k that
> > includes the concatenation of fixed grid and flexi-grid segme= nts.  
> > The implication of routing (RWA) may also be interesting.
> >
> > The flexi-grid will result in bandwidth fragmentation as traf= fic is
> > added and removed from links.  We need to consider the n= eed to
> > defragment the link.
> >
> > I think that the implications of flexi-grid go beyond signall= ing
> > into routing (RWA).
> >
> > The SG 15 will be meeting in December and will hold discussio= n on
> > the use of the flexi-grid.  It would be useful to provid= e, either
> > formally or informally a set of questions.
> >
> > Regards,
> >
> > Malcolm
> >
>
> >
> > "Adrian Farrel" <adrian@olddog.co.uk>
> > Sent by: ccamp-bounces@ietf.org
> > 12/11/2011 05:29 PM
> >
> > Please respond to
> > adri= an@olddog.co.uk
> >
> > To
> >
> > <ccamp= @ietf.org>
> >
> > cc
> >
> > Subject
> >
> > [CCAMP] Trying to resolve flexi-grid issue 1
> >
> >  
> >
> >
> >
> >
> > Hi,
> >
> > I wanted to see whether we can prime the discussions of flexi= -gridlabels in
> > advance of the WG meetings this week.
> >
> > It looks like we have successfully agreed that there are two = significant
> > differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-<= br> > lambda-label
> > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid- > > rsvp-te-ext
> >
> > The first point seems relatively minor:
> >
> > Should we use a new value for the Grid field or should we con= tinueto use the
> > value that indicates DWDM.
> >
> > In favor of continuing to use the DWDM value is the fact that= the
> > ITU-T has not
> > defined a new grid for flexible wavelength assignments. In fa= ct,
> theITU-T says
> > that flexible assignments should be made from the DWDM grid.<= /tt>
> >
> > On the other hand we need to understand that the fields in GM= PLS
> objects exist
> > to make implementation easier and to convey information. Ther= e is
> noneed for a
> > direct mapping to ITU-T grids.
> >
> > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM= ) it is
> correct that
> > the flexible grid wavelengths will be suggested from the ITU-= T DWDM
> > grid, but it
> > is not being as helpful as it could be.
> >
> > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex)= it is not implying
> > that there is a new and different grid defined by the ITU-T. = What
> itis saying
> > is that the label is a flexi-grid label selected from the gri= d
> defined by the
> > ITU-T for that purpose (i.e., the DWDM grid).
> >
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work
> > just as well if we decide to use Grid=3D=3D1. however, I thin= k it is
> > marginally more
> > helpful and useful to be able to recognise the different labe= l use
> > cases (fixed
> > grid / flexible grid) by looking at a field early in the Labe= l object.
> > Conversely, I don't believe that draft-zhang would be broken = by
> using Grid=3D=3D3.
> >
> > So my compromise proposal is that both I-Ds use Grid=3D=3D3. = Then we can
> > concentrate
> > on the more significant second issue (see separate email).
> >
> > What do folk think?
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@iet= f.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@iet= f.org
> > https://www.ietf.org/mailman/listinfo/ccamp

--Boundary_(ID_h3taoPjX1AeKHCcbodpoRQ)-- From zhangfatai@huawei.com Sun Nov 13 22:15:33 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654611E8218; Sun, 13 Nov 2011 22:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=-3.632, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzfYrHvPk+vC; Sun, 13 Nov 2011 22:15:32 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F316511E8211; Sun, 13 Nov 2011 22:15:31 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN006CD01DN4@szxga03-in.huawei.com>; Mon, 14 Nov 2011 14:15:13 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN00DGU01BZM@szxga03-in.huawei.com>; Mon, 14 Nov 2011 14:15:13 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA38488; Mon, 14 Nov 2011 14:14:50 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 14:14:49 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.92]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 14:14:41 +0800 Date: Mon, 14 Nov 2011 06:14:40 +0000 From: Zhangfatai In-reply-to: X-Originating-IP: [172.24.2.40] To: "li.yao3@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_M5cblAi9Nop1vf5DjE/zDw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgtPC4tDogUmU6ICBUcnlpbmcgdG8gcmVzb2x2ZSBm?= =?gb2312?Q?lexi-grid_issue_1?= Thread-index: AQHMonx7v0rhO1MVikCbqNINcNiKZJWr41R4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Abinder Dhillon , "ccamp@ietf.org" , Iftekhar Hussain , "ccamp-bounces@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICC08Li0OiBSZTogIFRyeWluZyB0?= =?gb2312?b?byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:15:34 -0000 --Boundary_(ID_M5cblAi9Nop1vf5DjE/zDw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgWWFvLA0KDQoNCg0KQWdyZWUgd2l0aCB5b3UuDQoNCg0KDQpJIHdvdWxkIGxpa2UgdG8gZGVz Y3JpYmUgd2hhdCB5b3Ugc2FpZCBpbiBhbm90aGVyIHdheToNCg0KDQoNClVuY29udGludW91cyB1 c2FnZSBmb3IgdGhlIGZyZXF1ZW5jaWVzIGhhcyBub3QgYmVlbiBkZWZpbmVkIChldmVuIG1lbnRp b25lZCkgaW4gSVRVLVQgZGF0YSBwbGFuZS4NCg0KDQoNClRoYW5rcw0KDQoNCg0KRmF0YWkNCg0K DQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6 IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gbGku eWFvM0B6dGUuY29tLmNuIFtsaS55YW8zQHp0ZS5jb20uY25dDQq3osvNyrG85DogMjAxMcTqMTHU wjE0yNUgMTE6MjINCrW9OiBsaS55YW8zQHp0ZS5jb20uY24NCkNjOiBBYmluZGVyIERoaWxsb247 IGNjYW1wQGlldGYub3JnOyBJZnRla2hhciBIdXNzYWluOyBjY2FtcC1ib3VuY2VzQGlldGYub3Jn DQrW98ziOiBbQ0NBTVBdILTwuLQ6ILTwuLQ6IFJlOiBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1n cmlkIGlzc3VlIDENCg0KDQpIaSBBTEw6DQoNCkNvcnJlY3QgbXkgbWlzdGFrZS4id2hldGhlciB0 aGUgc2xpY2VzIHdpbGwgYmUgc3dpdGNoZWQgd2l0aCBjb250aW51b3VzIGZvcm0gaXMgbm90IGNs ZWFyLiIgc2hvdWxkIGJlDQoid2hldGhlciB0aGUgc2xpY2VzIHdpbGwgYmUgc3dpdGNoZWQgd2l0 aCB1bmNvbnRpbnVvdXMgZm9ybSBpcyBub3QgY2xlYXIuIg0KDQpjY2FtcC1ib3VuY2VzQGlldGYu b3JnINC009ogMjAxMS0xMS0xNCAxMToxMzowNDoNCg0KPg0KPiBIaSBJZnRla2hhcjoNCj4NCj4g UGxlYXNlIHNlZSBiZWxvdy4NCj4NCj4gY2NhbXAtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEt MTEtMTQgMTA6NDg6Mzg6DQo+DQo+ID4gSGkgTWFsY29sbSwNCj4gPg0KPiA+IEFncmVlZCB3aXRo IHlvdXIgb2JzZXJ2YXRpb24gYWJvdXQgZnJhZ21lbnRhdGlvbiBpbiBmbGV4aWJsZSBncmlkLg0K PiA+IEJUVywgdGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgd2h5IHdlIG5lZWQgdG8gY29uc2lk ZXIgZmxleGlibGUNCj4gPiBhcHByb2FjaCBmb3IgbGFiZWwgZGVmaW5pdGlvbiB0aGF0IGFsbG93 cyBkZWZyYWdtZW50YXRpb24gKGUuZy4sIHNlZQ0KPiA+IHNwbGl0LXNwZWN0cnVtICBzdXBlci1j aGFubmVsIG9wdGlvbiBpbiAgaHR0cDovL3Rvb2xzLmlldGYuDQo+ID4gb3JnL2h0bWwvZHJhZnQt aHVzc2Fpbi1jY2FtcC1zdXBlci1jaGFubmVsLWxhYmVsLTAyKS4NCj4NCj4gPFlhbz5BY3R1YWxs eSwgZnJhZ21lbnRhdGlvbiB3aWxsIGFwcGVhciBhcyB0cmFmZmljIGlzDQo+IGFkZGVkIGFuZCBy ZW1vdmVkIGZyb20gbGlua3MuIFRoZSB3b3JrIG9mIGRlZnJhZ21lbnRhdGlvbiBzaG91bGQgYmUN Cj4gbGVmdCB0byBjb21wdXRhdGlvbiBlbnRpdHkgbGlrZSBQQ0UuDQo+IEhvd2V2ZXIsIHdoZXRo ZXIgdGhlIHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGggY29udGludW91cyBmb3JtIGlzbm90 IGNsZWFyLg0KPg0KPg0KPiA+DQo+ID4gUmVnYXJkaW5nIGNvbnNpZGVyYXRpb24gYWJvdXQgZ3Vh cmQtYmFuZCwgSSB0aGluaywgaXQgY2FuIGJlDQo+ID4gY29uc2lkZXJlZCBhcyBhIHBhcnQgb2Yg cGF0aCBjb21wdXRhdGlvbiBjb25zdHJhaW50IC0gZG9lcyBub3QNCj4gPiBuZWNlc3NhcmlseSBu ZWVkIHRvIGFkdmVydGlzZSB0aGlzIGFzIGEgcGFydCBvZiByb3V0aW5nLg0KPg0KPg0KPiA8WWFv PiBBZ3JlZS4NCj4NCj4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gSWZ0ZWtoYXINCj4gPg0KPiA+ IEZyb206IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbiBbbWFpbHRvOk1hbGNvbG0uQkVUVFNAenRl LmNvbS5jbl0NCj4gPiBTZW50OiBTdW5kYXksIE5vdmVtYmVyIDEzLCAyMDExIDY6MTEgUE0NCj4g PiBUbzogYWRyaWFuQG9sZGRvZy5jby51aw0KPiA+IENjOiBjY2FtcEBpZXRmLm9yZzsgY2NhbXAt Ym91bmNlc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIFRyeWluZyB0byByZXNv bHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KPiA+DQo+ID4gSGkgQWRyaWFuLA0KPiA+DQo+ID4gSW50 ZXJlc3RpbmcgcXVlc3Rpb25zLCBidXQgSSB0aGluayB3ZSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBi aWdnZXINCj4gPiBwaWN0dXJlIGZpcnN0LiAgQSBmZXcgcXVpY2sgdGhvdWdodHM6DQo+ID4NCj4g PiBPbmUgbW90aXZhdGlvbiBmb3IgdGhlIGZsZXhpLWdyaWQgaXMgdG8gc3VwcG9ydCB0aGUgbmV4 dCBnZW5lcmF0aW9uDQo+ID4gb3B0aWNhbCBzaWduYWxzICg+MTAwR2IvcykgdGhhdCBjYW5ub3Qg YmUgZWZmaWNpZW50bHkgYWNjb21tb2RhdGVkDQo+ID4gd2l0aCB0aGUgY3VycmVudCBmaXhlZCBn cmlkLiAgSG93ZXZlciwgd2UgY2FuIGV4cGVjdCB0byBzZWUgZmxleGktDQo+ID4gZ3JpZCBkZXBs b3llZCBiZWZvcmUgdGhlc2UgaGlnaGVyIGJpdCByYXRlIHN5c3RlbXMuDQo+ID4NCj4gPiBUaGUg Y3VycmVudCBmaXhlZCBncmlkIHByb3ZpZGVzIGFuIGltcGxpY2l0IGd1YXJkIGJhbmQgYmV0d2Vl bg0KPiA+IG9wdGljYWwgY2hhbm5lbHMgKGFuZCBzbG90cyBjYW4gYmUgbGVmdCB1bnVzZWQgdG8g YWxsb3cgYSBncmVhdGVyDQo+ID4gZ3VhcmQgYmFuZCkuICBXaXRoIGZsZXhpLWdyaWQgd2Ugd2ls bCBwcm9iYWJseSBuZWVkIHRvIHNwZWNpZnkgdGhlDQo+ID4gZ3VhcmQgYmFuZC4gIFRoZSBndWFy ZCBiYW5kIHdpbGwgcHJvYmFibHkgbmVlZCB0byBkZWZpbmVkIGJ5IGEgUENFDQo+ID4gYXBwbGlj YXRpb24gYnV0IHdlIHdpbGwgbmVlZCB0byBkZWZpbmUgdGhlIHBhcmFtZXRlcnMuDQo+ID4NCj4g PiBHaXZlbiB0aGF0IHRyYW5zaXRpbmcgYW4gT0FETSBuYXJyb3dzIHRoZSBvcHRpY2FsIGJhbmR3 aWR0aCBpdCBtYXkNCj4gPiBiZSBwb3NzaWJsZSB0byBvcHRpbWl6ZSB0aGUgbmV0d29yayBieSBh ZGp1c3RpbmcgdGhlIHJlcXVlc3RlZA0KPiA+IGJhbmR3aWR0aCBiYXNlZCBvbiB0aGUgbnVtYmVy IG9mIE9BRE1zIGluIHRoZSBwYXRoLiAgSG93IHdvdWxkIHdlDQo+ID4gInJldGFpbiIgdGhpcyBp bmZvcm1hdGlvbiB0byBzdXBwb3J0IHJlc3RvcmF0aW9uLg0KPiA+DQo+ID4gSSBleHBlY3QgdGhh dCB3ZSB3aWxsIGhhdmUgYSBjb25jYXRlbmF0aW9uIG9mIGZsZXhpLWdyaWQgYW5kIGZpeGVkDQo+ ID4gZ3JpZCBsaW5rcyAobWFuYWdlZCB2aWEgYSBQQ0UpIGluIHRoZSBuZXR3b3JrLiAgSG93IHdp bGwgd2Ugc2lnbmFsDQo+ID4gZm9yIGV4YW1wbGUgZm9yIGEgc2xvdCB0byBjYXJyeSAxMEdiL3Mg c2lnbmFsIGFjcm9zcyBhIG5ldHdvcmsgdGhhdA0KPiA+IGluY2x1ZGVzIHRoZSBjb25jYXRlbmF0 aW9uIG9mIGZpeGVkIGdyaWQgYW5kIGZsZXhpLWdyaWQgc2VnbWVudHMuDQo+ID4gVGhlIGltcGxp Y2F0aW9uIG9mIHJvdXRpbmcgKFJXQSkgbWF5IGFsc28gYmUgaW50ZXJlc3RpbmcuDQo+ID4NCj4g PiBUaGUgZmxleGktZ3JpZCB3aWxsIHJlc3VsdCBpbiBiYW5kd2lkdGggZnJhZ21lbnRhdGlvbiBh cyB0cmFmZmljIGlzDQo+ID4gYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gIFdlIG5lZWQg dG8gY29uc2lkZXIgdGhlIG5lZWQgdG8NCj4gPiBkZWZyYWdtZW50IHRoZSBsaW5rLg0KPiA+DQo+ ID4gSSB0aGluayB0aGF0IHRoZSBpbXBsaWNhdGlvbnMgb2YgZmxleGktZ3JpZCBnbyBiZXlvbmQg c2lnbmFsbGluZw0KPiA+IGludG8gcm91dGluZyAoUldBKS4NCj4gPg0KPiA+IFRoZSBTRyAxNSB3 aWxsIGJlIG1lZXRpbmcgaW4gRGVjZW1iZXIgYW5kIHdpbGwgaG9sZCBkaXNjdXNzaW9uIG9uDQo+ ID4gdGhlIHVzZSBvZiB0aGUgZmxleGktZ3JpZC4gIEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwcm92 aWRlLCBlaXRoZXINCj4gPiBmb3JtYWxseSBvciBpbmZvcm1hbGx5IGEgc2V0IG9mIHF1ZXN0aW9u cy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBNYWxjb2xtDQo+ID4NCj4NCj4gPg0KPiA+ ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51az4NCj4gPiBTZW50IGJ5OiBjY2Ft cC1ib3VuY2VzQGlldGYub3JnDQo+ID4gMTIvMTEvMjAxMSAwNToyOSBQTQ0KPiA+DQo+ID4gUGxl YXNlIHJlc3BvbmQgdG8NCj4gPiBhZHJpYW5Ab2xkZG9nLmNvLnVrDQo+ID4NCj4gPiBUbw0KPiA+ DQo+ID4gPGNjYW1wQGlldGYub3JnPg0KPiA+DQo+ID4gY2MNCj4gPg0KPiA+IFN1YmplY3QNCj4g Pg0KPiA+IFtDQ0FNUF0gVHJ5aW5nIHRvIHJlc29sdmUgZmxleGktZ3JpZCBpc3N1ZSAxDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJIHdhbnRlZCB0byBz ZWUgd2hldGhlciB3ZSBjYW4gcHJpbWUgdGhlIGRpc2N1c3Npb25zIG9mIGZsZXhpLWdyaWRsYWJl bHMgaW4NCj4gPiBhZHZhbmNlIG9mIHRoZSBXRyBtZWV0aW5ncyB0aGlzIHdlZWsuDQo+ID4NCj4g PiBJdCBsb29rcyBsaWtlIHdlIGhhdmUgc3VjY2Vzc2Z1bGx5IGFncmVlZCB0aGF0IHRoZXJlIGFy ZSB0d28gc2lnbmlmaWNhbnQNCj4gPiBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBsYWJlbCBmb3Jt YXRzIGRlZmluZWQgaW4NCj4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZhcnJraW5nZWwtY2NhbXAtZmxleGlncmlkLQ0KPiBsYW1iZGEtbGFiZWwNCj4gPiBhbmQgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1jY2FtcC1mbGV4aWJsZS1n cmlkLQ0KPiA+IHJzdnAtdGUtZXh0DQo+ID4NCj4gPiBUaGUgZmlyc3QgcG9pbnQgc2VlbXMgcmVs YXRpdmVseSBtaW5vcjoNCj4gPg0KPiA+IFNob3VsZCB3ZSB1c2UgYSBuZXcgdmFsdWUgZm9yIHRo ZSBHcmlkIGZpZWxkIG9yIHNob3VsZCB3ZSBjb250aW51ZXRvIHVzZSB0aGUNCj4gPiB2YWx1ZSB0 aGF0IGluZGljYXRlcyBEV0RNLg0KPiA+DQo+ID4gSW4gZmF2b3Igb2YgY29udGludWluZyB0byB1 c2UgdGhlIERXRE0gdmFsdWUgaXMgdGhlIGZhY3QgdGhhdCB0aGUNCj4gPiBJVFUtVCBoYXMgbm90 DQo+ID4gZGVmaW5lZCBhIG5ldyBncmlkIGZvciBmbGV4aWJsZSB3YXZlbGVuZ3RoIGFzc2lnbm1l bnRzLiBJbiBmYWN0LA0KPiB0aGVJVFUtVCBzYXlzDQo+ID4gdGhhdCBmbGV4aWJsZSBhc3NpZ25t ZW50cyBzaG91bGQgYmUgbWFkZSBmcm9tIHRoZSBEV0RNIGdyaWQuDQo+ID4NCj4gPiBPbiB0aGUg b3RoZXIgaGFuZCB3ZSBuZWVkIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUgZmllbGRzIGluIEdNUExT DQo+IG9iamVjdHMgZXhpc3QNCj4gPiB0byBtYWtlIGltcGxlbWVudGF0aW9uIGVhc2llciBhbmQg dG8gY29udmV5IGluZm9ybWF0aW9uLiBUaGVyZSBpcw0KPiBub25lZWQgZm9yIGENCj4gPiBkaXJl Y3QgbWFwcGluZyB0byBJVFUtVCBncmlkcy4NCj4gPg0KPiA+IFRodXMsIHdoZW4gZHJhZnQtemhh bmcgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MSAoSVRVLVQgRFdETSkgaXQgaXMNCj4gY29ycmVjdCB0 aGF0DQo+ID4gdGhlIGZsZXhpYmxlIGdyaWQgd2F2ZWxlbmd0aHMgd2lsbCBiZSBzdWdnZXN0ZWQg ZnJvbSB0aGUgSVRVLVQgRFdETQ0KPiA+IGdyaWQsIGJ1dCBpdA0KPiA+IGlzIG5vdCBiZWluZyBh cyBoZWxwZnVsIGFzIGl0IGNvdWxkIGJlLg0KPiA+DQo+ID4gV2hlbiBkcmFmdC1mYXJya2luZ2Vs IHN1Z2dlc3RzIHVzaW5nIEdyaWQ9PTMgKElUVS1UIEZsZXgpIGl0IGlzIG5vdCBpbXBseWluZw0K PiA+IHRoYXQgdGhlcmUgaXMgYSBuZXcgYW5kIGRpZmZlcmVudCBncmlkIGRlZmluZWQgYnkgdGhl IElUVS1ULiBXaGF0DQo+IGl0aXMgc2F5aW5nDQo+ID4gaXMgdGhhdCB0aGUgbGFiZWwgaXMgYSBm bGV4aS1ncmlkIGxhYmVsIHNlbGVjdGVkIGZyb20gdGhlIGdyaWQNCj4gZGVmaW5lZCBieSB0aGUN Cj4gPiBJVFUtVCBmb3IgdGhhdCBwdXJwb3NlIChpLmUuLCB0aGUgRFdETSBncmlkKS4NCj4gPg0K PiA+IFBlcnNvbmFsbHksIGkgZG9uJ3Qgc2VlIHRoaXMgYXMgYSB2ZXJ5IGxhcmdlIGlzc3VlLiBk cmFmdC0NCj4gZmFycmtpbmdlbHdvdWxkIHdvcmsNCj4gPiBqdXN0IGFzIHdlbGwgaWYgd2UgZGVj aWRlIHRvIHVzZSBHcmlkPT0xLiBob3dldmVyLCBJIHRoaW5rIGl0IGlzDQo+ID4gbWFyZ2luYWxs eSBtb3JlDQo+ID4gaGVscGZ1bCBhbmQgdXNlZnVsIHRvIGJlIGFibGUgdG8gcmVjb2duaXNlIHRo ZSBkaWZmZXJlbnQgbGFiZWwgdXNlDQo+ID4gY2FzZXMgKGZpeGVkDQo+ID4gZ3JpZCAvIGZsZXhp YmxlIGdyaWQpIGJ5IGxvb2tpbmcgYXQgYSBmaWVsZCBlYXJseSBpbiB0aGUgTGFiZWwgb2JqZWN0 Lg0KPiA+IENvbnZlcnNlbHksIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGRyYWZ0LXpoYW5nIHdvdWxk IGJlIGJyb2tlbiBieQ0KPiB1c2luZyBHcmlkPT0zLg0KPiA+DQo+ID4gU28gbXkgY29tcHJvbWlz ZSBwcm9wb3NhbCBpcyB0aGF0IGJvdGggSS1EcyB1c2UgR3JpZD09My4gVGhlbiB3ZSBjYW4NCj4g PiBjb25jZW50cmF0ZQ0KPiA+IG9uIHRoZSBtb3JlIHNpZ25pZmljYW50IHNlY29uZCBpc3N1ZSAo c2VlIHNlcGFyYXRlIGVtYWlsKS4NCj4gPg0KPiA+IFdoYXQgZG8gZm9sayB0aGluaz8NCj4gPg0K PiA+IENoZWVycywNCj4gPiBBZHJpYW4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4gQ0NB TVBAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gPiBDQ0FNUEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IEND QU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXANCg== --Boundary_(ID_M5cblAi9Nop1vf5DjE/zDw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Yao,

 

Agree with you.

 

I would like to describe what you said in another way:

 

Uncontinuous usage for the frequencies has not been defined (even m= entioned) in ITU-T data plane.

 

Thanks

 

Fatai

 

 

 

 

=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org= [ccamp-bounces@ietf.org] =B4=FA=B1=ED li.yao3@zte.com.cn [li.yao3@zte.com.= cn]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 11:22
=B5=BD: li.yao3@zte.com.cn
Cc: Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; ccamp-bounces= @ietf.org
=D6=F7=CC=E2: [CCAMP] =B4=F0=B8=B4: =B4=F0=B8=B4: Re: Trying to reso= lve flexi-grid issue 1


Hi ALL:

Correct my mistake."whether the slices will be switched with continuous form is not clear." should be
"whether the slices will be switched with = uncontinuous= form is not clear."

ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 11:13:0= 4:

>
> Hi Iftekhar:
>
> Please see below.
>
> ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 10:48:38:
>
> > Hi Malcolm,
> >  
> > Agreed with your observation about fragmentation in flexible grid= .
> > BTW, this is one of the reasons why we need to consider flexible =
> > approach for label definition that allows defragmentation (e.g., = see
> > split-spectrum  super-channel option in  http://tools.i= etf.
> > org/html/draft-hussain-ccamp-super-channel-label-02).
>
> <Yao>Actually, fragmentation will appear as traffic is
> added and removed from links. The work of defragmentation should be > left to computation entity like PCE.
> However, whether the slices will be switched with continuous fo= rm isnot clear.
>
>
> >  
> > Regarding consideration about guard-band, I think, it can be
> > considered as a part of path computation constraint - does not > > necessarily need to advertise this as a part of routing.
>
>
> <Yao> Agree.
>
>
> >  
> > Regards,
> > Iftekhar
> >  
> > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] =
> > Sent: Sunday, November 13, 2011 6:11 PM
> > To: adrian@olddog.co.uk
> > Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
> > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
> >  
> > Hi Adrian,
> >
> > Interesting questions, but I think we need to consider the bigger=
> > picture first.  A few quick thoughts:
> >
> > One motivation for the flexi-grid is to support the next generati= on
> > optical signals (>100Gb/s) that cannot be efficiently accommod= ated
> > with the current fixed grid.  However, we can expect to see = flexi-
> > grid deployed before these higher bit rate systems.
> >
> > The current fixed grid provides an implicit guard band between > > optical channels (and slots can be left unused to allow a greater=
> > guard band).  With flexi-grid we will probably need to speci= fy the
> > guard band.  The guard band will probably need to defined by= a PCE
> > application but we will need to define the parameters.   > >
> > Given that transiting an OADM narrows the optical bandwidth it ma= y
> > be possible to optimize the network by adjusting the requested > > bandwidth based on the number of OADMs in the path.  How wou= ld we
> > "retain" this information to support restoration.
> >
> > I expect that we will have a concatenation of flexi-grid and fixe= d
> > grid links (managed via a PCE) in the network.  How will we = signal
> > for example for a slot to carry 10Gb/s signal across a network th= at
> > includes the concatenation of fixed grid and flexi-grid segments.=  
> > The implication of routing (RWA) may also be interesting.
> >
> > The flexi-grid will result in bandwidth fragmentation as traffic = is
> > added and removed from links.  We need to consider the need = to
> > defragment the link.
> >
> > I think that the implications of flexi-grid go beyond signalling =
> > into routing (RWA).
> >
> > The SG 15 will be meeting in December and will hold discussion on=
> > the use of the flexi-grid.  It would be useful to provide, e= ither
> > formally or informally a set of questions.
> >
> > Regards,
> >
> > Malcolm
> >
>
> >
> > "Adrian Farrel" <adrian@olddog.co.uk>
> > Sent by: ccamp-bounces@ietf.org
> > 12/11/2011 05:29 PM
> >
> > Please respond to
> > adrian@olddog.co.uk
> >
> > To
> >
> > <ccamp@ietf.org>
> >
> > cc
> >
> > Subject
> >
> > [CCAMP] Trying to resolve flexi-grid issue 1
> >
> >  
> >
> >
> >
> >
> > Hi,
> >
> > I wanted to see whether we can prime the discussions of flexi-gri= dlabels in
> > advance of the WG meetings this week.
> >
> > It looks like we have successfully agreed that there are two sign= ificant
> > differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-=
> lambda-label
> > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-gr= id-
> > rsvp-te-ext
> >
> > The first point seems relatively minor:
> >
> > Should we use a new value for the Grid field or should we continu= eto use the
> > value that indicates DWDM.
> >
> > In favor of continuing to use the DWDM value is the fact that the=
> > ITU-T has not
> > defined a new grid for flexible wavelength assignments. In fact, =
> theITU-T says
> > that flexible assignments should be made from the DWDM grid.
> >
> > On the other hand we need to understand that the fields in GMPLS =
> objects exist
> > to make implementation easier and to convey information. There is=
> noneed for a
> > direct mapping to ITU-T grids.
> >
> > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it= is
> correct that
> > the flexible grid wavelengths will be suggested from the ITU-T DW= DM
> > grid, but it
> > is not being as helpful as it could be.
> >
> > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it = is not implying
> > that there is a new and different grid defined by the ITU-T. What=
> itis saying
> > is that the label is a flexi-grid label selected from the grid > defined by the
> > ITU-T for that purpose (i.e., the DWDM grid).
> >
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work
> > just as well if we decide to use Grid=3D=3D1. however, I think it= is
> > marginally more
> > helpful and useful to be able to recognise the different label us= e
> > cases (fixed
> > grid / flexible grid) by looking at a field early in the Label ob= ject.
> > Conversely, I don't believe that draft-zhang would be broken by <= br> > using Grid=3D=3D3.
> >
> > So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then= we can
> > concentrate
> > on the more significant second issue (see separate email).
> >
> > What do folk think?
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
--Boundary_(ID_M5cblAi9Nop1vf5DjE/zDw)-- From zhangfatai@huawei.com Sun Nov 13 22:25:22 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB61A11E815A; Sun, 13 Nov 2011 22:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-3.467, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEbGGnZrMJoL; Sun, 13 Nov 2011 22:25:21 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 441D611E80BE; Sun, 13 Nov 2011 22:25:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN0081U0HMCL@szxga05-in.huawei.com>; Mon, 14 Nov 2011 14:24:58 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUN00DGP0HKRV@szxga05-in.huawei.com>; Mon, 14 Nov 2011 14:24:58 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY84701; Mon, 14 Nov 2011 14:24:50 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 14:24:47 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.92]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 14:24:41 +0800 Date: Mon, 14 Nov 2011 06:24:40 +0000 From: Zhangfatai In-reply-to: X-Originating-IP: [172.24.2.40] To: "li.yao3@zte.com.cn" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bvQYuJ1orNRQXN1TWgvsqw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgtPC4tDogUmU6ICBUcnlpbmcgdG8gcmVzb2x2ZSBm?= =?gb2312?Q?lexi-grid_issue_1?= Thread-index: AQHMonx7v0rhO1MVikCbqNINcNiKZJWr41R4gAADrQ8= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: Abinder Dhillon , "ccamp@ietf.org" , Iftekhar Hussain , "ccamp-bounces@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICC08Li0OiBSZTogIFRyeWluZyB0?= =?gb2312?b?byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:25:23 -0000 --Boundary_(ID_bvQYuJ1orNRQXN1TWgvsqw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCkhpIFlhbywNCg0KDQoNCkFncmVlIHdpdGggeW91Lg0KDQoNCg0KSSB3b3VsZCBsaWtlIHRv IGRlc2NyaWJlIHdoYXQgeW91IHNhaWQgaW4gYW5vdGhlciB3YXk6DQoNCg0KDQpVbmNvbnRpbnVv dXMgdXNhZ2UgZm9yIHRoZSBmcmVxdWVuY2llcyBpcyBub3QgZGVmaW5lZCAoZXZlbiBtZW50aW9u ZWQpIGluIElUVS1UIGRhdGEgcGxhbmUuDQoNCg0KDQpUaGFua3MNCg0KDQoNCkZhdGFpDQoNCg0K DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBj Y2FtcC1ib3VuY2VzQGlldGYub3JnIFtjY2FtcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIGxpLnlh bzNAenRlLmNvbS5jbiBbbGkueWFvM0B6dGUuY29tLmNuXQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MIx NMjVIDExOjIyDQq1vTogbGkueWFvM0B6dGUuY29tLmNuDQpDYzogQWJpbmRlciBEaGlsbG9uOyBj Y2FtcEBpZXRmLm9yZzsgSWZ0ZWtoYXIgSHVzc2FpbjsgY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0K 1vfM4jogW0NDQU1QXSC08Li0OiC08Li0OiBSZTogVHJ5aW5nIHRvIHJlc29sdmUgZmxleGktZ3Jp ZCBpc3N1ZSAxDQoNCg0KSGkgQUxMOg0KDQpDb3JyZWN0IG15IG1pc3Rha2UuIndoZXRoZXIgdGhl IHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGggY29udGludW91cyBmb3JtIGlzIG5vdCBjbGVh ci4iIHNob3VsZCBiZQ0KIndoZXRoZXIgdGhlIHNsaWNlcyB3aWxsIGJlIHN3aXRjaGVkIHdpdGgg dW5jb250aW51b3VzIGZvcm0gaXMgbm90IGNsZWFyLiINCg0KY2NhbXAtYm91bmNlc0BpZXRmLm9y ZyDQtNPaIDIwMTEtMTEtMTQgMTE6MTM6MDQ6DQoNCj4NCj4gSGkgSWZ0ZWtoYXI6DQo+DQo+IFBs ZWFzZSBzZWUgYmVsb3cuDQo+DQo+IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDExLTEx LTE0IDEwOjQ4OjM4Og0KPg0KPiA+IEhpIE1hbGNvbG0sDQo+ID4NCj4gPiBBZ3JlZWQgd2l0aCB5 b3VyIG9ic2VydmF0aW9uIGFib3V0IGZyYWdtZW50YXRpb24gaW4gZmxleGlibGUgZ3JpZC4NCj4g PiBCVFcsIHRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIHdoeSB3ZSBuZWVkIHRvIGNvbnNpZGVy IGZsZXhpYmxlDQo+ID4gYXBwcm9hY2ggZm9yIGxhYmVsIGRlZmluaXRpb24gdGhhdCBhbGxvd3Mg ZGVmcmFnbWVudGF0aW9uIChlLmcuLCBzZWUNCj4gPiBzcGxpdC1zcGVjdHJ1bSAgc3VwZXItY2hh bm5lbCBvcHRpb24gaW4gIGh0dHA6Ly90b29scy5pZXRmLg0KPiA+IG9yZy9odG1sL2RyYWZ0LWh1 c3NhaW4tY2NhbXAtc3VwZXItY2hhbm5lbC1sYWJlbC0wMikuDQo+DQo+IDxZYW8+QWN0dWFsbHks IGZyYWdtZW50YXRpb24gd2lsbCBhcHBlYXIgYXMgdHJhZmZpYyBpcw0KPiBhZGRlZCBhbmQgcmVt b3ZlZCBmcm9tIGxpbmtzLiBUaGUgd29yayBvZiBkZWZyYWdtZW50YXRpb24gc2hvdWxkIGJlDQo+ IGxlZnQgdG8gY29tcHV0YXRpb24gZW50aXR5IGxpa2UgUENFLg0KPiBIb3dldmVyLCB3aGV0aGVy IHRoZSBzbGljZXMgd2lsbCBiZSBzd2l0Y2hlZCB3aXRoIGNvbnRpbnVvdXMgZm9ybSBpc25vdCBj bGVhci4NCj4NCj4NCj4gPg0KPiA+IFJlZ2FyZGluZyBjb25zaWRlcmF0aW9uIGFib3V0IGd1YXJk LWJhbmQsIEkgdGhpbmssIGl0IGNhbiBiZQ0KPiA+IGNvbnNpZGVyZWQgYXMgYSBwYXJ0IG9mIHBh dGggY29tcHV0YXRpb24gY29uc3RyYWludCAtIGRvZXMgbm90DQo+ID4gbmVjZXNzYXJpbHkgbmVl ZCB0byBhZHZlcnRpc2UgdGhpcyBhcyBhIHBhcnQgb2Ygcm91dGluZy4NCj4NCj4NCj4gPFlhbz4g QWdyZWUuDQo+DQo+DQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IElmdGVraGFyDQo+ID4NCj4gPiBG cm9tOiBNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24gW21haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5j b20uY25dDQo+ID4gU2VudDogU3VuZGF5LCBOb3ZlbWJlciAxMywgMjAxMSA2OjExIFBNDQo+ID4g VG86IGFkcmlhbkBvbGRkb2cuY28udWsNCj4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IGNjYW1wLWJv dW5jZXNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBUcnlpbmcgdG8gcmVzb2x2 ZSBmbGV4aS1ncmlkIGlzc3VlIDENCj4gPg0KPiA+IEhpIEFkcmlhbiwNCj4gPg0KPiA+IEludGVy ZXN0aW5nIHF1ZXN0aW9ucywgYnV0IEkgdGhpbmsgd2UgbmVlZCB0byBjb25zaWRlciB0aGUgYmln Z2VyDQo+ID4gcGljdHVyZSBmaXJzdC4gIEEgZmV3IHF1aWNrIHRob3VnaHRzOg0KPiA+DQo+ID4g T25lIG1vdGl2YXRpb24gZm9yIHRoZSBmbGV4aS1ncmlkIGlzIHRvIHN1cHBvcnQgdGhlIG5leHQg Z2VuZXJhdGlvbg0KPiA+IG9wdGljYWwgc2lnbmFscyAoPjEwMEdiL3MpIHRoYXQgY2Fubm90IGJl IGVmZmljaWVudGx5IGFjY29tbW9kYXRlZA0KPiA+IHdpdGggdGhlIGN1cnJlbnQgZml4ZWQgZ3Jp ZC4gIEhvd2V2ZXIsIHdlIGNhbiBleHBlY3QgdG8gc2VlIGZsZXhpLQ0KPiA+IGdyaWQgZGVwbG95 ZWQgYmVmb3JlIHRoZXNlIGhpZ2hlciBiaXQgcmF0ZSBzeXN0ZW1zLg0KPiA+DQo+ID4gVGhlIGN1 cnJlbnQgZml4ZWQgZ3JpZCBwcm92aWRlcyBhbiBpbXBsaWNpdCBndWFyZCBiYW5kIGJldHdlZW4N Cj4gPiBvcHRpY2FsIGNoYW5uZWxzIChhbmQgc2xvdHMgY2FuIGJlIGxlZnQgdW51c2VkIHRvIGFs bG93IGEgZ3JlYXRlcg0KPiA+IGd1YXJkIGJhbmQpLiAgV2l0aCBmbGV4aS1ncmlkIHdlIHdpbGwg cHJvYmFibHkgbmVlZCB0byBzcGVjaWZ5IHRoZQ0KPiA+IGd1YXJkIGJhbmQuICBUaGUgZ3VhcmQg YmFuZCB3aWxsIHByb2JhYmx5IG5lZWQgdG8gZGVmaW5lZCBieSBhIFBDRQ0KPiA+IGFwcGxpY2F0 aW9uIGJ1dCB3ZSB3aWxsIG5lZWQgdG8gZGVmaW5lIHRoZSBwYXJhbWV0ZXJzLg0KPiA+DQo+ID4g R2l2ZW4gdGhhdCB0cmFuc2l0aW5nIGFuIE9BRE0gbmFycm93cyB0aGUgb3B0aWNhbCBiYW5kd2lk dGggaXQgbWF5DQo+ID4gYmUgcG9zc2libGUgdG8gb3B0aW1pemUgdGhlIG5ldHdvcmsgYnkgYWRq dXN0aW5nIHRoZSByZXF1ZXN0ZWQNCj4gPiBiYW5kd2lkdGggYmFzZWQgb24gdGhlIG51bWJlciBv ZiBPQURNcyBpbiB0aGUgcGF0aC4gIEhvdyB3b3VsZCB3ZQ0KPiA+ICJyZXRhaW4iIHRoaXMgaW5m b3JtYXRpb24gdG8gc3VwcG9ydCByZXN0b3JhdGlvbi4NCj4gPg0KPiA+IEkgZXhwZWN0IHRoYXQg d2Ugd2lsbCBoYXZlIGEgY29uY2F0ZW5hdGlvbiBvZiBmbGV4aS1ncmlkIGFuZCBmaXhlZA0KPiA+ IGdyaWQgbGlua3MgKG1hbmFnZWQgdmlhIGEgUENFKSBpbiB0aGUgbmV0d29yay4gIEhvdyB3aWxs IHdlIHNpZ25hbA0KPiA+IGZvciBleGFtcGxlIGZvciBhIHNsb3QgdG8gY2FycnkgMTBHYi9zIHNp Z25hbCBhY3Jvc3MgYSBuZXR3b3JrIHRoYXQNCj4gPiBpbmNsdWRlcyB0aGUgY29uY2F0ZW5hdGlv biBvZiBmaXhlZCBncmlkIGFuZCBmbGV4aS1ncmlkIHNlZ21lbnRzLg0KPiA+IFRoZSBpbXBsaWNh dGlvbiBvZiByb3V0aW5nIChSV0EpIG1heSBhbHNvIGJlIGludGVyZXN0aW5nLg0KPiA+DQo+ID4g VGhlIGZsZXhpLWdyaWQgd2lsbCByZXN1bHQgaW4gYmFuZHdpZHRoIGZyYWdtZW50YXRpb24gYXMg dHJhZmZpYyBpcw0KPiA+IGFkZGVkIGFuZCByZW1vdmVkIGZyb20gbGlua3MuICBXZSBuZWVkIHRv IGNvbnNpZGVyIHRoZSBuZWVkIHRvDQo+ID4gZGVmcmFnbWVudCB0aGUgbGluay4NCj4gPg0KPiA+ IEkgdGhpbmsgdGhhdCB0aGUgaW1wbGljYXRpb25zIG9mIGZsZXhpLWdyaWQgZ28gYmV5b25kIHNp Z25hbGxpbmcNCj4gPiBpbnRvIHJvdXRpbmcgKFJXQSkuDQo+ID4NCj4gPiBUaGUgU0cgMTUgd2ls bCBiZSBtZWV0aW5nIGluIERlY2VtYmVyIGFuZCB3aWxsIGhvbGQgZGlzY3Vzc2lvbiBvbg0KPiA+ IHRoZSB1c2Ugb2YgdGhlIGZsZXhpLWdyaWQuICBJdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlk ZSwgZWl0aGVyDQo+ID4gZm9ybWFsbHkgb3IgaW5mb3JtYWxseSBhIHNldCBvZiBxdWVzdGlvbnMu DQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+DQo+ID4gTWFsY29sbQ0KPiA+DQo+DQo+ID4NCj4gPiAi QWRyaWFuIEZhcnJlbCIgPGFkcmlhbkBvbGRkb2cuY28udWs+DQo+ID4gU2VudCBieTogY2NhbXAt Ym91bmNlc0BpZXRmLm9yZw0KPiA+IDEyLzExLzIwMTEgMDU6MjkgUE0NCj4gPg0KPiA+IFBsZWFz ZSByZXNwb25kIHRvDQo+ID4gYWRyaWFuQG9sZGRvZy5jby51aw0KPiA+DQo+ID4gVG8NCj4gPg0K PiA+IDxjY2FtcEBpZXRmLm9yZz4NCj4gPg0KPiA+IGNjDQo+ID4NCj4gPiBTdWJqZWN0DQo+ID4N Cj4gPiBbQ0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gSSB3YW50ZWQgdG8gc2Vl IHdoZXRoZXIgd2UgY2FuIHByaW1lIHRoZSBkaXNjdXNzaW9ucyBvZiBmbGV4aS1ncmlkbGFiZWxz IGluDQo+ID4gYWR2YW5jZSBvZiB0aGUgV0cgbWVldGluZ3MgdGhpcyB3ZWVrLg0KPiA+DQo+ID4g SXQgbG9va3MgbGlrZSB3ZSBoYXZlIHN1Y2Nlc3NmdWxseSBhZ3JlZWQgdGhhdCB0aGVyZSBhcmUg dHdvIHNpZ25pZmljYW50DQo+ID4gZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgbGFiZWwgZm9ybWF0 cyBkZWZpbmVkIGluDQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m YXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC0NCj4gbGFtYmRhLWxhYmVsDQo+ID4gYW5kIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctY2NhbXAtZmxleGlibGUtZ3Jp ZC0NCj4gPiByc3ZwLXRlLWV4dA0KPiA+DQo+ID4gVGhlIGZpcnN0IHBvaW50IHNlZW1zIHJlbGF0 aXZlbHkgbWlub3I6DQo+ID4NCj4gPiBTaG91bGQgd2UgdXNlIGEgbmV3IHZhbHVlIGZvciB0aGUg R3JpZCBmaWVsZCBvciBzaG91bGQgd2UgY29udGludWV0byB1c2UgdGhlDQo+ID4gdmFsdWUgdGhh dCBpbmRpY2F0ZXMgRFdETS4NCj4gPg0KPiA+IEluIGZhdm9yIG9mIGNvbnRpbnVpbmcgdG8gdXNl IHRoZSBEV0RNIHZhbHVlIGlzIHRoZSBmYWN0IHRoYXQgdGhlDQo+ID4gSVRVLVQgaGFzIG5vdA0K PiA+IGRlZmluZWQgYSBuZXcgZ3JpZCBmb3IgZmxleGlibGUgd2F2ZWxlbmd0aCBhc3NpZ25tZW50 cy4gSW4gZmFjdCwNCj4gdGhlSVRVLVQgc2F5cw0KPiA+IHRoYXQgZmxleGlibGUgYXNzaWdubWVu dHMgc2hvdWxkIGJlIG1hZGUgZnJvbSB0aGUgRFdETSBncmlkLg0KPiA+DQo+ID4gT24gdGhlIG90 aGVyIGhhbmQgd2UgbmVlZCB0byB1bmRlcnN0YW5kIHRoYXQgdGhlIGZpZWxkcyBpbiBHTVBMUw0K PiBvYmplY3RzIGV4aXN0DQo+ID4gdG8gbWFrZSBpbXBsZW1lbnRhdGlvbiBlYXNpZXIgYW5kIHRv IGNvbnZleSBpbmZvcm1hdGlvbi4gVGhlcmUgaXMNCj4gbm9uZWVkIGZvciBhDQo+ID4gZGlyZWN0 IG1hcHBpbmcgdG8gSVRVLVQgZ3JpZHMuDQo+ID4NCj4gPiBUaHVzLCB3aGVuIGRyYWZ0LXpoYW5n IHN1Z2dlc3RzIHVzaW5nIEdyaWQ9PTEgKElUVS1UIERXRE0pIGl0IGlzDQo+IGNvcnJlY3QgdGhh dA0KPiA+IHRoZSBmbGV4aWJsZSBncmlkIHdhdmVsZW5ndGhzIHdpbGwgYmUgc3VnZ2VzdGVkIGZy b20gdGhlIElUVS1UIERXRE0NCj4gPiBncmlkLCBidXQgaXQNCj4gPiBpcyBub3QgYmVpbmcgYXMg aGVscGZ1bCBhcyBpdCBjb3VsZCBiZS4NCj4gPg0KPiA+IFdoZW4gZHJhZnQtZmFycmtpbmdlbCBz dWdnZXN0cyB1c2luZyBHcmlkPT0zIChJVFUtVCBGbGV4KSBpdCBpcyBub3QgaW1wbHlpbmcNCj4g PiB0aGF0IHRoZXJlIGlzIGEgbmV3IGFuZCBkaWZmZXJlbnQgZ3JpZCBkZWZpbmVkIGJ5IHRoZSBJ VFUtVC4gV2hhdA0KPiBpdGlzIHNheWluZw0KPiA+IGlzIHRoYXQgdGhlIGxhYmVsIGlzIGEgZmxl eGktZ3JpZCBsYWJlbCBzZWxlY3RlZCBmcm9tIHRoZSBncmlkDQo+IGRlZmluZWQgYnkgdGhlDQo+ ID4gSVRVLVQgZm9yIHRoYXQgcHVycG9zZSAoaS5lLiwgdGhlIERXRE0gZ3JpZCkuDQo+ID4NCj4g PiBQZXJzb25hbGx5LCBpIGRvbid0IHNlZSB0aGlzIGFzIGEgdmVyeSBsYXJnZSBpc3N1ZS4gZHJh ZnQtDQo+IGZhcnJraW5nZWx3b3VsZCB3b3JrDQo+ID4ganVzdCBhcyB3ZWxsIGlmIHdlIGRlY2lk ZSB0byB1c2UgR3JpZD09MS4gaG93ZXZlciwgSSB0aGluayBpdCBpcw0KPiA+IG1hcmdpbmFsbHkg bW9yZQ0KPiA+IGhlbHBmdWwgYW5kIHVzZWZ1bCB0byBiZSBhYmxlIHRvIHJlY29nbmlzZSB0aGUg ZGlmZmVyZW50IGxhYmVsIHVzZQ0KPiA+IGNhc2VzIChmaXhlZA0KPiA+IGdyaWQgLyBmbGV4aWJs ZSBncmlkKSBieSBsb29raW5nIGF0IGEgZmllbGQgZWFybHkgaW4gdGhlIExhYmVsIG9iamVjdC4N Cj4gPiBDb252ZXJzZWx5LCBJIGRvbid0IGJlbGlldmUgdGhhdCBkcmFmdC16aGFuZyB3b3VsZCBi ZSBicm9rZW4gYnkNCj4gdXNpbmcgR3JpZD09My4NCj4gPg0KPiA+IFNvIG15IGNvbXByb21pc2Ug cHJvcG9zYWwgaXMgdGhhdCBib3RoIEktRHMgdXNlIEdyaWQ9PTMuIFRoZW4gd2UgY2FuDQo+ID4g Y29uY2VudHJhdGUNCj4gPiBvbiB0aGUgbW9yZSBzaWduaWZpY2FudCBzZWNvbmQgaXNzdWUgKHNl ZSBzZXBhcmF0ZSBlbWFpbCkuDQo+ID4NCj4gPiBXaGF0IGRvIGZvbGsgdGhpbms/DQo+ID4NCj4g PiBDaGVlcnMsDQo+ID4gQWRyaWFuDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+IENDQU1Q QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+ID4gQ0NBTVBAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FN UEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w DQo= --Boundary_(ID_bvQYuJ1orNRQXN1TWgvsqw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 

Hi Yao,

 

Agree with you.

 

I would like to describe what you said in another way:

 

Uncontinuous usage for the frequencies is not defined (ev= en mentioned) in ITU-T data plane.

 

Thanks

 

Fatai

 

 

 

 

=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org= [ccamp-bounces@ietf.org] =B4=FA=B1=ED li.yao3@zte.com.cn [li.yao3@zte.com.= cn]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 11:22
=B5=BD: li.yao3@zte.com.cn
Cc: Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; ccamp-bounces= @ietf.org
=D6=F7=CC=E2: [CCAMP] =B4=F0=B8=B4: =B4=F0=B8=B4: Re: Trying to reso= lve flexi-grid issue 1


Hi ALL:

Correct my mistake."whether the slices will be switched with continuous form is not clear." should be
"whether the slices will be switched with = uncontinuous= form is not clear."

ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 11:13:0= 4:

>
> Hi Iftekhar:
>
> Please see below.
>
> ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 10:48:38:
>
> > Hi Malcolm,
> >  
> > Agreed with your observation about fragmentation in flexible grid= .
> > BTW, this is one of the reasons why we need to consider flexible =
> > approach for label definition that allows defragmentation (e.g., = see
> > split-spectrum  super-channel option in  http://tools.i= etf.
> > org/html/draft-hussain-ccamp-super-channel-label-02).
>
> <Yao>Actually, fragmentation will appear as traffic is
> added and removed from links. The work of defragmentation should be > left to computation entity like PCE.
> However, whether the slices will be switched with continuous fo= rm isnot clear.
>
>
> >  
> > Regarding consideration about guard-band, I think, it can be
> > considered as a part of path computation constraint - does not > > necessarily need to advertise this as a part of routing.
>
>
> <Yao> Agree.
>
>
> >  
> > Regards,
> > Iftekhar
> >  
> > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn] =
> > Sent: Sunday, November 13, 2011 6:11 PM
> > To: adrian@olddog.co.uk
> > Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
> > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
> >  
> > Hi Adrian,
> >
> > Interesting questions, but I think we need to consider the bigger=
> > picture first.  A few quick thoughts:
> >
> > One motivation for the flexi-grid is to support the next generati= on
> > optical signals (>100Gb/s) that cannot be efficiently accommod= ated
> > with the current fixed grid.  However, we can expect to see = flexi-
> > grid deployed before these higher bit rate systems.
> >
> > The current fixed grid provides an implicit guard band between > > optical channels (and slots can be left unused to allow a greater=
> > guard band).  With flexi-grid we will probably need to speci= fy the
> > guard band.  The guard band will probably need to defined by= a PCE
> > application but we will need to define the parameters.   > >
> > Given that transiting an OADM narrows the optical bandwidth it ma= y
> > be possible to optimize the network by adjusting the requested > > bandwidth based on the number of OADMs in the path.  How wou= ld we
> > "retain" this information to support restoration.
> >
> > I expect that we will have a concatenation of flexi-grid and fixe= d
> > grid links (managed via a PCE) in the network.  How will we = signal
> > for example for a slot to carry 10Gb/s signal across a network th= at
> > includes the concatenation of fixed grid and flexi-grid segments.=  
> > The implication of routing (RWA) may also be interesting.
> >
> > The flexi-grid will result in bandwidth fragmentation as traffic = is
> > added and removed from links.  We need to consider the need = to
> > defragment the link.
> >
> > I think that the implications of flexi-grid go beyond signalling =
> > into routing (RWA).
> >
> > The SG 15 will be meeting in December and will hold discussion on=
> > the use of the flexi-grid.  It would be useful to provide, e= ither
> > formally or informally a set of questions.
> >
> > Regards,
> >
> > Malcolm
> >
>
> >
> > "Adrian Farrel" <adrian@olddog.co.uk>
> > Sent by: ccamp-bounces@ietf.org
> > 12/11/2011 05:29 PM
> >
> > Please respond to
> > adrian@olddog.co.uk
> >
> > To
> >
> > <ccamp@ietf.org>
> >
> > cc
> >
> > Subject
> >
> > [CCAMP] Trying to resolve flexi-grid issue 1
> >
> >  
> >
> >
> >
> >
> > Hi,
> >
> > I wanted to see whether we can prime the discussions of flexi-gri= dlabels in
> > advance of the WG meetings this week.
> >
> > It looks like we have successfully agreed that there are two sign= ificant
> > differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-=
> lambda-label
> > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-gr= id-
> > rsvp-te-ext
> >
> > The first point seems relatively minor:
> >
> > Should we use a new value for the Grid field or should we continu= eto use the
> > value that indicates DWDM.
> >
> > In favor of continuing to use the DWDM value is the fact that the=
> > ITU-T has not
> > defined a new grid for flexible wavelength assignments. In fact, =
> theITU-T says
> > that flexible assignments should be made from the DWDM grid.
> >
> > On the other hand we need to understand that the fields in GMPLS =
> objects exist
> > to make implementation easier and to convey information. There is=
> noneed for a
> > direct mapping to ITU-T grids.
> >
> > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM) it= is
> correct that
> > the flexible grid wavelengths will be suggested from the ITU-T DW= DM
> > grid, but it
> > is not being as helpful as it could be.
> >
> > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex) it = is not implying
> > that there is a new and different grid defined by the ITU-T. What=
> itis saying
> > is that the label is a flexi-grid label selected from the grid > defined by the
> > ITU-T for that purpose (i.e., the DWDM grid).
> >
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work
> > just as well if we decide to use Grid=3D=3D1. however, I think it= is
> > marginally more
> > helpful and useful to be able to recognise the different label us= e
> > cases (fixed
> > grid / flexible grid) by looking at a field early in the Label ob= ject.
> > Conversely, I don't believe that draft-zhang would be broken by <= br> > using Grid=3D=3D3.
> >
> > So my compromise proposal is that both I-Ds use Grid=3D=3D3. Then= we can
> > concentrate
> > on the more significant second issue (see separate email).
> >
> > What do folk think?
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
--Boundary_(ID_bvQYuJ1orNRQXN1TWgvsqw)-- From IHussain@infinera.com Mon Nov 14 10:06:38 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D031F0CF5; Mon, 14 Nov 2011 10:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.831 X-Spam-Level: ** X-Spam-Status: No, score=2.831 tagged_above=-999 required=5 tests=[AWL=-3.619, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxh0-mB7exy2; Mon, 14 Nov 2011 10:06:37 -0800 (PST) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A13A1F0CCE; Mon, 14 Nov 2011 10:06:37 -0800 (PST) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 10:06:37 -0800 From: Iftekhar Hussain To: Zhangfatai , "li.yao3@zte.com.cn" Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgtPC4tDogUmU6ICBUcnlpbmcgdG8gcmVzb2x2ZSBm?= =?gb2312?Q?lexi-grid_issue_1?= Thread-Index: AQHMopTQdT5WYivvr0a8eC2a+djaWJWsqe+g Date: Mon, 14 Nov 2011 18:06:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3BF95SVEXDBPROD1infi_" MIME-Version: 1.0 Cc: Marco Sosa , Abinder Dhillon , "ccamp@ietf.org" , "ccamp-bounces@ietf.org" Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6IFJlOiAgVHJ5aW5nIHRvIHJlc29s?= =?gb2312?b?dmUgZmxleGktZ3JpZCBpc3N1ZSAx?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:06:39 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3BF95SVEXDBPROD1infi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RmF0YWksDQoNCklUVSBpcyBkZWZpbmluZyB0aGUgZ3JpZCAoZnJlcXVlbmNpZXMpLiBUaGUgYWxs b2NhdGlvbiBvZiBmcmVxdWVuY2llcyBpcyBsZWZ0IHRvIHNwZWNpZmljIGltcGxlbWVudGF0aW9u cyBhbmQgdXNlIGNhc2VzLiBIb3cgZGlkIHlvdSBpbmZlciB0aGF0IGl0IHByZWNsdWRlcyB0aGUg dXNlIG9mIHNwbGl0LXNwZWN0cnVtIHVzZSBjYXNlcy4gV2h5IG9uZSBzaG91bGQgaW1wb3NlIGFy dGlmaWNpYWwgcmVzdHJpY3Rpb25zPw0KDQoNCg0KSWZ0ZWtoYXINCg0KRnJvbTogWmhhbmdmYXRh aSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIg MTMsIDIwMTEgMTA6MTUgUE0NClRvOiBsaS55YW8zQHp0ZS5jb20uY24NCkNjOiBBYmluZGVyIERo aWxsb247IGNjYW1wQGlldGYub3JnOyBJZnRla2hhciBIdXNzYWluOyBjY2FtcC1ib3VuY2VzQGll dGYub3JnDQpTdWJqZWN0OiC08Li0OiBbQ0NBTVBdILTwuLQ6ILTwuLQ6IFJlOiBUcnlpbmcgdG8g cmVzb2x2ZSBmbGV4aS1ncmlkIGlzc3VlIDENCg0KDQpIaSBZYW8sDQoNCg0KDQpBZ3JlZSB3aXRo IHlvdS4NCg0KDQoNCkkgd291bGQgbGlrZSB0byBkZXNjcmliZSB3aGF0IHlvdSBzYWlkIGluIGFu b3RoZXIgd2F5Og0KDQoNCg0KVW5jb250aW51b3VzIHVzYWdlIGZvciB0aGUgZnJlcXVlbmNpZXMg aGFzIG5vdCBiZWVuIGRlZmluZWQgKGV2ZW4gbWVudGlvbmVkKSBpbiBJVFUtVCBkYXRhIHBsYW5l Lg0KDQoNCg0KVGhhbmtzDQoNCg0KDQpGYXRhaQ0KDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBb Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBsaS55YW8zQHp0ZS5jb20uY24gW2xpLnlhbzNA enRlLmNvbS5jbl0NCreiy83KsbzkOiAyMDExxOoxMdTCMTTI1SAxMToyMg0Ktb06IGxpLnlhbzNA enRlLmNvbS5jbg0KQ2M6IEFiaW5kZXIgRGhpbGxvbjsgY2NhbXBAaWV0Zi5vcmc7IElmdGVraGFy IEh1c3NhaW47IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCtb3zOI6IFtDQ0FNUF0gtPC4tDogtPC4 tDogUmU6IFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KDQpIaSBBTEw6DQoN CkNvcnJlY3QgbXkgbWlzdGFrZS4id2hldGhlciB0aGUgc2xpY2VzIHdpbGwgYmUgc3dpdGNoZWQg d2l0aCBjb250aW51b3VzIGZvcm0gaXMgbm90IGNsZWFyLiIgc2hvdWxkIGJlDQoid2hldGhlciB0 aGUgc2xpY2VzIHdpbGwgYmUgc3dpdGNoZWQgd2l0aCB1bmNvbnRpbnVvdXMgZm9ybSBpcyBub3Qg Y2xlYXIuIg0KDQpjY2FtcC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGll dGYub3JnPiDQtNPaIDIwMTEtMTEtMTQgMTE6MTM6MDQ6DQoNCj4NCj4gSGkgSWZ0ZWtoYXI6DQo+ DQo+IFBsZWFzZSBzZWUgYmVsb3cuDQo+DQo+IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAxMS0xMS0xNCAxMDo0ODozODoNCj4NCj4g PiBIaSBNYWxjb2xtLA0KPiA+DQo+ID4gQWdyZWVkIHdpdGggeW91ciBvYnNlcnZhdGlvbiBhYm91 dCBmcmFnbWVudGF0aW9uIGluIGZsZXhpYmxlIGdyaWQuDQo+ID4gQlRXLCB0aGlzIGlzIG9uZSBv ZiB0aGUgcmVhc29ucyB3aHkgd2UgbmVlZCB0byBjb25zaWRlciBmbGV4aWJsZQ0KPiA+IGFwcHJv YWNoIGZvciBsYWJlbCBkZWZpbml0aW9uIHRoYXQgYWxsb3dzIGRlZnJhZ21lbnRhdGlvbiAoZS5n Liwgc2VlDQo+ID4gc3BsaXQtc3BlY3RydW0gIHN1cGVyLWNoYW5uZWwgb3B0aW9uIGluICBodHRw Oi8vdG9vbHMuaWV0Zi4NCj4gPiBvcmcvaHRtbC9kcmFmdC1odXNzYWluLWNjYW1wLXN1cGVyLWNo YW5uZWwtbGFiZWwtMDIpLg0KPg0KPiA8WWFvPkFjdHVhbGx5LCBmcmFnbWVudGF0aW9uIHdpbGwg YXBwZWFyIGFzIHRyYWZmaWMgaXMNCj4gYWRkZWQgYW5kIHJlbW92ZWQgZnJvbSBsaW5rcy4gVGhl IHdvcmsgb2YgZGVmcmFnbWVudGF0aW9uIHNob3VsZCBiZQ0KPiBsZWZ0IHRvIGNvbXB1dGF0aW9u IGVudGl0eSBsaWtlIFBDRS4NCj4gSG93ZXZlciwgd2hldGhlciB0aGUgc2xpY2VzIHdpbGwgYmUg c3dpdGNoZWQgd2l0aCBjb250aW51b3VzIGZvcm0gaXNub3QgY2xlYXIuDQo+DQo+DQo+ID4NCj4g PiBSZWdhcmRpbmcgY29uc2lkZXJhdGlvbiBhYm91dCBndWFyZC1iYW5kLCBJIHRoaW5rLCBpdCBj YW4gYmUNCj4gPiBjb25zaWRlcmVkIGFzIGEgcGFydCBvZiBwYXRoIGNvbXB1dGF0aW9uIGNvbnN0 cmFpbnQgLSBkb2VzIG5vdA0KPiA+IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYWR2ZXJ0aXNlIHRoaXMg YXMgYSBwYXJ0IG9mIHJvdXRpbmcuDQo+DQo+DQo+IDxZYW8+IEFncmVlLg0KPg0KPg0KPiA+DQo+ ID4gUmVnYXJkcywNCj4gPiBJZnRla2hhcg0KPiA+DQo+ID4gRnJvbTogTWFsY29sbS5CRVRUU0B6 dGUuY29tLmNuPG1haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20uY24+IFttYWlsdG86TWFsY29s bS5CRVRUU0B6dGUuY29tLmNuXTxtYWlsdG86W21haWx0bzpNYWxjb2xtLkJFVFRTQHp0ZS5jb20u Y25dPg0KPiA+IFNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTMsIDIwMTEgNjoxMSBQTQ0KPiA+IFRv OiBhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPg0KPiA+IENj OiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBjY2FtcC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBb Q0NBTVBdIFRyeWluZyB0byByZXNvbHZlIGZsZXhpLWdyaWQgaXNzdWUgMQ0KPiA+DQo+ID4gSGkg QWRyaWFuLA0KPiA+DQo+ID4gSW50ZXJlc3RpbmcgcXVlc3Rpb25zLCBidXQgSSB0aGluayB3ZSBu ZWVkIHRvIGNvbnNpZGVyIHRoZSBiaWdnZXINCj4gPiBwaWN0dXJlIGZpcnN0LiAgQSBmZXcgcXVp Y2sgdGhvdWdodHM6DQo+ID4NCj4gPiBPbmUgbW90aXZhdGlvbiBmb3IgdGhlIGZsZXhpLWdyaWQg aXMgdG8gc3VwcG9ydCB0aGUgbmV4dCBnZW5lcmF0aW9uDQo+ID4gb3B0aWNhbCBzaWduYWxzICg+ MTAwR2IvcykgdGhhdCBjYW5ub3QgYmUgZWZmaWNpZW50bHkgYWNjb21tb2RhdGVkDQo+ID4gd2l0 aCB0aGUgY3VycmVudCBmaXhlZCBncmlkLiAgSG93ZXZlciwgd2UgY2FuIGV4cGVjdCB0byBzZWUg ZmxleGktDQo+ID4gZ3JpZCBkZXBsb3llZCBiZWZvcmUgdGhlc2UgaGlnaGVyIGJpdCByYXRlIHN5 c3RlbXMuDQo+ID4NCj4gPiBUaGUgY3VycmVudCBmaXhlZCBncmlkIHByb3ZpZGVzIGFuIGltcGxp Y2l0IGd1YXJkIGJhbmQgYmV0d2Vlbg0KPiA+IG9wdGljYWwgY2hhbm5lbHMgKGFuZCBzbG90cyBj YW4gYmUgbGVmdCB1bnVzZWQgdG8gYWxsb3cgYSBncmVhdGVyDQo+ID4gZ3VhcmQgYmFuZCkuICBX aXRoIGZsZXhpLWdyaWQgd2Ugd2lsbCBwcm9iYWJseSBuZWVkIHRvIHNwZWNpZnkgdGhlDQo+ID4g Z3VhcmQgYmFuZC4gIFRoZSBndWFyZCBiYW5kIHdpbGwgcHJvYmFibHkgbmVlZCB0byBkZWZpbmVk IGJ5IGEgUENFDQo+ID4gYXBwbGljYXRpb24gYnV0IHdlIHdpbGwgbmVlZCB0byBkZWZpbmUgdGhl IHBhcmFtZXRlcnMuDQo+ID4NCj4gPiBHaXZlbiB0aGF0IHRyYW5zaXRpbmcgYW4gT0FETSBuYXJy b3dzIHRoZSBvcHRpY2FsIGJhbmR3aWR0aCBpdCBtYXkNCj4gPiBiZSBwb3NzaWJsZSB0byBvcHRp bWl6ZSB0aGUgbmV0d29yayBieSBhZGp1c3RpbmcgdGhlIHJlcXVlc3RlZA0KPiA+IGJhbmR3aWR0 aCBiYXNlZCBvbiB0aGUgbnVtYmVyIG9mIE9BRE1zIGluIHRoZSBwYXRoLiAgSG93IHdvdWxkIHdl DQo+ID4gInJldGFpbiIgdGhpcyBpbmZvcm1hdGlvbiB0byBzdXBwb3J0IHJlc3RvcmF0aW9uLg0K PiA+DQo+ID4gSSBleHBlY3QgdGhhdCB3ZSB3aWxsIGhhdmUgYSBjb25jYXRlbmF0aW9uIG9mIGZs ZXhpLWdyaWQgYW5kIGZpeGVkDQo+ID4gZ3JpZCBsaW5rcyAobWFuYWdlZCB2aWEgYSBQQ0UpIGlu IHRoZSBuZXR3b3JrLiAgSG93IHdpbGwgd2Ugc2lnbmFsDQo+ID4gZm9yIGV4YW1wbGUgZm9yIGEg c2xvdCB0byBjYXJyeSAxMEdiL3Mgc2lnbmFsIGFjcm9zcyBhIG5ldHdvcmsgdGhhdA0KPiA+IGlu Y2x1ZGVzIHRoZSBjb25jYXRlbmF0aW9uIG9mIGZpeGVkIGdyaWQgYW5kIGZsZXhpLWdyaWQgc2Vn bWVudHMuDQo+ID4gVGhlIGltcGxpY2F0aW9uIG9mIHJvdXRpbmcgKFJXQSkgbWF5IGFsc28gYmUg aW50ZXJlc3RpbmcuDQo+ID4NCj4gPiBUaGUgZmxleGktZ3JpZCB3aWxsIHJlc3VsdCBpbiBiYW5k d2lkdGggZnJhZ21lbnRhdGlvbiBhcyB0cmFmZmljIGlzDQo+ID4gYWRkZWQgYW5kIHJlbW92ZWQg ZnJvbSBsaW5rcy4gIFdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIG5lZWQgdG8NCj4gPiBkZWZyYWdt ZW50IHRoZSBsaW5rLg0KPiA+DQo+ID4gSSB0aGluayB0aGF0IHRoZSBpbXBsaWNhdGlvbnMgb2Yg ZmxleGktZ3JpZCBnbyBiZXlvbmQgc2lnbmFsbGluZw0KPiA+IGludG8gcm91dGluZyAoUldBKS4N Cj4gPg0KPiA+IFRoZSBTRyAxNSB3aWxsIGJlIG1lZXRpbmcgaW4gRGVjZW1iZXIgYW5kIHdpbGwg aG9sZCBkaXNjdXNzaW9uIG9uDQo+ID4gdGhlIHVzZSBvZiB0aGUgZmxleGktZ3JpZC4gIEl0IHdv dWxkIGJlIHVzZWZ1bCB0byBwcm92aWRlLCBlaXRoZXINCj4gPiBmb3JtYWxseSBvciBpbmZvcm1h bGx5IGEgc2V0IG9mIHF1ZXN0aW9ucy4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBNYWxj b2xtDQo+ID4NCj4NCj4gPg0KPiA+ICJBZHJpYW4gRmFycmVsIiA8YWRyaWFuQG9sZGRvZy5jby51 azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+DQo+ID4gU2VudCBieTogY2NhbXAtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4NCj4gPiAxMi8xMS8yMDEx IDA1OjI5IFBNDQo+ID4NCj4gPiBQbGVhc2UgcmVzcG9uZCB0bw0KPiA+IGFkcmlhbkBvbGRkb2cu Y28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+DQo+ID4NCj4gPiBUbw0KPiA+DQo+ID4g PGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+DQo+ID4NCj4gPiBjYw0KPiA+ DQo+ID4gU3ViamVjdA0KPiA+DQo+ID4gW0NDQU1QXSBUcnlpbmcgdG8gcmVzb2x2ZSBmbGV4aS1n cmlkIGlzc3VlIDENCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBIaSwNCj4gPg0K PiA+IEkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHdlIGNhbiBwcmltZSB0aGUgZGlzY3Vzc2lvbnMg b2YgZmxleGktZ3JpZGxhYmVscyBpbg0KPiA+IGFkdmFuY2Ugb2YgdGhlIFdHIG1lZXRpbmdzIHRo aXMgd2Vlay4NCj4gPg0KPiA+IEl0IGxvb2tzIGxpa2Ugd2UgaGF2ZSBzdWNjZXNzZnVsbHkgYWdy ZWVkIHRoYXQgdGhlcmUgYXJlIHR3byBzaWduaWZpY2FudA0KPiA+IGRpZmZlcmVuY2VzIGJldHdl ZW4gdGhlIGxhYmVsIGZvcm1hdHMgZGVmaW5lZCBpbg0KPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmFycmtpbmdlbC1jY2FtcC1mbGV4aWdyaWQtDQo+IGxhbWJkYS1s YWJlbA0KPiA+IGFuZCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5n LWNjYW1wLWZsZXhpYmxlLWdyaWQtDQo+ID4gcnN2cC10ZS1leHQNCj4gPg0KPiA+IFRoZSBmaXJz dCBwb2ludCBzZWVtcyByZWxhdGl2ZWx5IG1pbm9yOg0KPiA+DQo+ID4gU2hvdWxkIHdlIHVzZSBh IG5ldyB2YWx1ZSBmb3IgdGhlIEdyaWQgZmllbGQgb3Igc2hvdWxkIHdlIGNvbnRpbnVldG8gdXNl IHRoZQ0KPiA+IHZhbHVlIHRoYXQgaW5kaWNhdGVzIERXRE0uDQo+ID4NCj4gPiBJbiBmYXZvciBv ZiBjb250aW51aW5nIHRvIHVzZSB0aGUgRFdETSB2YWx1ZSBpcyB0aGUgZmFjdCB0aGF0IHRoZQ0K PiA+IElUVS1UIGhhcyBub3QNCj4gPiBkZWZpbmVkIGEgbmV3IGdyaWQgZm9yIGZsZXhpYmxlIHdh dmVsZW5ndGggYXNzaWdubWVudHMuIEluIGZhY3QsDQo+IHRoZUlUVS1UIHNheXMNCj4gPiB0aGF0 IGZsZXhpYmxlIGFzc2lnbm1lbnRzIHNob3VsZCBiZSBtYWRlIGZyb20gdGhlIERXRE0gZ3JpZC4N Cj4gPg0KPiA+IE9uIHRoZSBvdGhlciBoYW5kIHdlIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGF0IHRo ZSBmaWVsZHMgaW4gR01QTFMNCj4gb2JqZWN0cyBleGlzdA0KPiA+IHRvIG1ha2UgaW1wbGVtZW50 YXRpb24gZWFzaWVyIGFuZCB0byBjb252ZXkgaW5mb3JtYXRpb24uIFRoZXJlIGlzDQo+IG5vbmVl ZCBmb3IgYQ0KPiA+IGRpcmVjdCBtYXBwaW5nIHRvIElUVS1UIGdyaWRzLg0KPiA+DQo+ID4gVGh1 cywgd2hlbiBkcmFmdC16aGFuZyBzdWdnZXN0cyB1c2luZyBHcmlkPT0xIChJVFUtVCBEV0RNKSBp dCBpcw0KPiBjb3JyZWN0IHRoYXQNCj4gPiB0aGUgZmxleGlibGUgZ3JpZCB3YXZlbGVuZ3RocyB3 aWxsIGJlIHN1Z2dlc3RlZCBmcm9tIHRoZSBJVFUtVCBEV0RNDQo+ID4gZ3JpZCwgYnV0IGl0DQo+ ID4gaXMgbm90IGJlaW5nIGFzIGhlbHBmdWwgYXMgaXQgY291bGQgYmUuDQo+ID4NCj4gPiBXaGVu IGRyYWZ0LWZhcnJraW5nZWwgc3VnZ2VzdHMgdXNpbmcgR3JpZD09MyAoSVRVLVQgRmxleCkgaXQg aXMgbm90IGltcGx5aW5nDQo+ID4gdGhhdCB0aGVyZSBpcyBhIG5ldyBhbmQgZGlmZmVyZW50IGdy aWQgZGVmaW5lZCBieSB0aGUgSVRVLVQuIFdoYXQNCj4gaXRpcyBzYXlpbmcNCj4gPiBpcyB0aGF0 IHRoZSBsYWJlbCBpcyBhIGZsZXhpLWdyaWQgbGFiZWwgc2VsZWN0ZWQgZnJvbSB0aGUgZ3JpZA0K PiBkZWZpbmVkIGJ5IHRoZQ0KPiA+IElUVS1UIGZvciB0aGF0IHB1cnBvc2UgKGkuZS4sIHRoZSBE V0RNIGdyaWQpLg0KPiA+DQo+ID4gUGVyc29uYWxseSwgaSBkb24ndCBzZWUgdGhpcyBhcyBhIHZl cnkgbGFyZ2UgaXNzdWUuIGRyYWZ0LQ0KPiBmYXJya2luZ2Vsd291bGQgd29yaw0KPiA+IGp1c3Qg YXMgd2VsbCBpZiB3ZSBkZWNpZGUgdG8gdXNlIEdyaWQ9PTEuIGhvd2V2ZXIsIEkgdGhpbmsgaXQg aXMNCj4gPiBtYXJnaW5hbGx5IG1vcmUNCj4gPiBoZWxwZnVsIGFuZCB1c2VmdWwgdG8gYmUgYWJs ZSB0byByZWNvZ25pc2UgdGhlIGRpZmZlcmVudCBsYWJlbCB1c2UNCj4gPiBjYXNlcyAoZml4ZWQN Cj4gPiBncmlkIC8gZmxleGlibGUgZ3JpZCkgYnkgbG9va2luZyBhdCBhIGZpZWxkIGVhcmx5IGlu IHRoZSBMYWJlbCBvYmplY3QuDQo+ID4gQ29udmVyc2VseSwgSSBkb24ndCBiZWxpZXZlIHRoYXQg ZHJhZnQtemhhbmcgd291bGQgYmUgYnJva2VuIGJ5DQo+IHVzaW5nIEdyaWQ9PTMuDQo+ID4NCj4g PiBTbyBteSBjb21wcm9taXNlIHByb3Bvc2FsIGlzIHRoYXQgYm90aCBJLURzIHVzZSBHcmlkPT0z LiBUaGVuIHdlIGNhbg0KPiA+IGNvbmNlbnRyYXRlDQo+ID4gb24gdGhlIG1vcmUgc2lnbmlmaWNh bnQgc2Vjb25kIGlzc3VlIChzZWUgc2VwYXJhdGUgZW1haWwpLg0KPiA+DQo+ID4gV2hhdCBkbyBm b2xrIHRoaW5rPw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IEFkcmlhbg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBDQ0FNUCBtYWls aW5nIGxpc3QNCj4gPiBDQ0FNUEBpZXRmLm9yZzxtYWlsdG86Q0NBTVBAaWV0Zi5vcmc+DQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQ0NBTVAgbWFpbGlu ZyBsaXN0DQo+ID4gQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0 DQo+IENDQU1QQGlldGYub3JnPG1haWx0bzpDQ0FNUEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0K --_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3BF95SVEXDBPROD1infi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Fatai,<= /p>

 <= /p>

ITU is defining the grid = (frequencies). The allocation of frequencies is left to specific implementa= tions and use cases. How did you infer that it precludes the use of split-spectrum use cases. Why one should impose artificial rest= rictions?

 <= /p>

 <= /p>

 <= /p>

Iftekhar

 <= /p>

From: Zhangfat= ai [mailto:zhangfatai@huawei.com]
Sent: Sunday, November 13, 2011 10:15 PM
To: li.yao3@zte.com.cn
Cc: Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; ccamp-bounces= @ietf.org
Subject: =B4= =F0=B8=B4: [CCAMP] =B4=F0=B8=B4<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">: =B4=F0=B8=B4<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">: Re: Trying to resolve flexi-grid issue 1

 

Hi Yao,

 

Agree with you.

 

I would like to describe what you said in anothe= r way:

 

Uncontinuous usage for the frequencies has not b= een defined (even mentioned) in ITU-T data plane.

 

Thanks

 

Fatai

 

 

 

 

=B7=A2=BC=FE=C8=CB<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif";color:black">: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] =B4=FA=B1=ED li.yao3@zte.com.cn [li.yao3@zte.com.cn]
=B7= =A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C214=C8=D5 11:22
=B5= =BD:=D6= =F7=CC=E2: [CCAMP] =B4=F0= =B8=B4: =B4=F0= =B8=B4: Re: Trying to resolve flexi-grid iss= ue 1


Hi ALL:

Correct my mistake."whether the slices will be switched wit= h continuous form is not clear." should be
"whether the s= lices will be switched with uncontinuous= form is n= ot clear."

ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 11:13:04:

>
> Hi Iftekhar:
>
> Please see below.
>
> ccamp-bounces@ietf.org =D0=B4=D3=DA 2011-11-14 10:48:38:
>
> > Hi Malcolm,
> >  
> > Agreed with your observation about fragmentation in flexible = grid.
> > BTW, this is one of the reasons why we need to consider flexi= ble
> > approach for label definition that allows defragmentation (e.= g., see
> > split-spectrum  super-channel option in  http://tools.ietf.
> > org/html/draft-hussain-ccamp-super-channel-label-02). >
> <Yao>Actually, fragmentation will appear as traffic is =
> added and removed from links. The work of defragmentation should b= e
> left to computation entity like PCE.
> However, whether the slices will be switched with continuous form isnot clear.
>
>
> >  
> > Regarding consideration about guard-band, I think, it can be =
> > considered as a part of path computation constraint - does no= t
> > necessarily need to advertise this as a part of routing.
>
>
> <Yao> Agree.
>
>
> >  
> > Regards,
> > Iftekhar
> >  
> > From: Malcolm.BET= TS@zte.com.cn [mailto:Malcolm.BETTS@= zte.com.cn]
> > Sent: Sunday, November 13, 2011 6:11 PM
> > To: adrian@olddog.co.u= k
> > Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
> > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
> >  
> > Hi Adrian,
> >
> > Interesting questions, but I think we need to consider the bi= gger
> > picture first.  A few quick thoughts:
> >
> > One motivation for the flexi-grid is to support the next gene= ration
> > optical signals (>100Gb/s) that cannot be efficiently acco= mmodated
> > with the current fixed grid.  However, we can expect to = see flexi-
> > grid deployed before these higher bit rate systems.
> >
> > The current fixed grid provides an implicit guard band betwee= n
> > optical channels (and slots can be left unused to allow a gre= ater
> > guard band).  With flexi-grid we will probably need to s= pecify the
> > guard band.  The guard band will probably need to define= d by a PCE
> > application but we will need to define the parameters.  =
> >
> > Given that transiting an OADM narrows the optical bandwidth i= t may
> > be possible to optimize the network by adjusting the requeste= d
> > bandwidth based on the number of OADMs in the path.  How= would we
> > "retain" this information to support restoration. <= /tt>
> >
> > I expect that we will have a concatenation of flexi-grid and = fixed
> > grid links (managed via a PCE) in the network.  How will= we signal
> > for example for a slot to carry 10Gb/s signal across a networ= k that
> > includes the concatenation of fixed grid and flexi-grid segme= nts.  
> > The implication of routing (RWA) may also be interesting.
> >
> > The flexi-grid will result in bandwidth fragmentation as traf= fic is
> > added and removed from links.  We need to consider the n= eed to
> > defragment the link.
> >
> > I think that the implications of flexi-grid go beyond signall= ing
> > into routing (RWA).
> >
> > The SG 15 will be meeting in December and will hold discussio= n on
> > the use of the flexi-grid.  It would be useful to provid= e, either
> > formally or informally a set of questions.
> >
> > Regards,
> >
> > Malcolm
> >
>
> >
> > "Adrian Farrel" <adrian@olddog.co.uk>
> > Sent by: ccamp-boun= ces@ietf.org
> > 12/11/2011 05:29 PM
> >
> > Please respond to
> > adrian@olddog.co.uk
> >
> > To
> >
> > <ccamp@ietf.org> =
> >
> > cc
> >
> > Subject
> >
> > [CCAMP] Trying to resolve flexi-grid issue 1
> >
> >  
> >
> >
> >
> >
> > Hi,
> >
> > I wanted to see whether we can prime the discussions of flexi= -gridlabels in
> > advance of the WG meetings this week.
> >
> > It looks like we have successfully agreed that there are two = significant
> > differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-<= br> > lambda-label
> > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid- > > rsvp-te-ext
> >
> > The first point seems relatively minor:
> >
> > Should we use a new value for the Grid field or should we con= tinueto use the
> > value that indicates DWDM.
> >
> > In favor of continuing to use the DWDM value is the fact that= the
> > ITU-T has not
> > defined a new grid for flexible wavelength assignments. In fa= ct,
> theITU-T says
> > that flexible assignments should be made from the DWDM grid.<= /tt>
> >
> > On the other hand we need to understand that the fields in GM= PLS
> objects exist
> > to make implementation easier and to convey information. Ther= e is
> noneed for a
> > direct mapping to ITU-T grids.
> >
> > Thus, when draft-zhang suggests using Grid=3D=3D1 (ITU-T DWDM= ) it is
> correct that
> > the flexible grid wavelengths will be suggested from the ITU-= T DWDM
> > grid, but it
> > is not being as helpful as it could be.
> >
> > When draft-farrkingel suggests using Grid=3D=3D3 (ITU-T Flex)= it is not implying
> > that there is a new and different grid defined by the ITU-T. = What
> itis saying
> > is that the label is a flexi-grid label selected from the gri= d
> defined by the
> > ITU-T for that purpose (i.e., the DWDM grid).
> >
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work
> > just as well if we decide to use Grid=3D=3D1. however, I thin= k it is
> > marginally more
> > helpful and useful to be able to recognise the different labe= l use
> > cases (fixed
> > grid / flexible grid) by looking at a field early in the Labe= l object.
> > Conversely, I don't believe that draft-zhang would be broken = by
> using Grid=3D=3D3.
> >
> > So my compromise proposal is that both I-Ds use Grid=3D=3D3. = Then we can
> > concentrate
> > on the more significant second issue (see separate email).
> >
> > What do folk think?
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https= ://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https= ://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/ccamp

--_000_D7D7AB44C06A2440B716F1F1F5E70AE50AB3BF95SVEXDBPROD1infi_-- From giomarti@cisco.com Mon Nov 14 13:33:04 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D569921F8F4E for ; Mon, 14 Nov 2011 13:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw-bloiorjCo for ; Mon, 14 Nov 2011 13:33:04 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id C7A8F21F8F4D for ; Mon, 14 Nov 2011 13:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=1627; q=dns/txt; s=iport; t=1321306383; x=1322515983; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KsKyiulPfxl1jY7/1IQM7sCeRzXcCFG23oBYWvUzA8k=; b=DCSOj9NuO3cLMcfJmHJqzsaX1Hyoi5OA/J1uyn6v1cpWNrHZ+PzUBMCH k48uXtmjA4xNKGJzgRVOuRvvmrcZehhyz8EIz/a3AwWEkhMvYt8B0bxvo Q9Y8qrBbP0RymDnOmC7QGViiNQCHnO6rpqSXVbYYgykRpPMXOz5MgcPsT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJaIwU6Q/khM/2dsb2JhbABDqWeBBYFyAQEBBAEBAQsEASUtCQoBEAsOCgkWDwkDAgECARUwBg0BBQIBAR6HaJoWAZ5yBIl/BJQukXo X-IronPort-AV: E=Sophos;i="4.69,511,1315180800"; d="scan'208";a="3055670" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 14 Nov 2011 21:33:02 +0000 Received: from ams3-vpn-dhcp4706.cisco.com (ams3-vpn-dhcp4706.cisco.com [10.61.82.97]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAELX2tx021456; Mon, 14 Nov 2011 21:33:02 GMT Message-ID: <4EC18919.2090405@cisco.com> Date: Mon, 14 Nov 2011 22:33:13 +0100 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Lou Berger References: <4EBF1FEE.6020904@labn.net> In-Reply-To: <4EBF1FEE.6020904@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] request to WG authors/editors who are not presenting this week X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:33:04 -0000 Lou, ccamp-ers, here some update on draft-ietf-ccamp-wson-signaling-02, since we got some intra-author discussion but not significant updates. Unfortunately I'm not able to attend this ietf I leave some notes that represent my view since there's no finalization among co-authors yet (so co-authors/editors please feel free to comment). 1. Bidirectionality. There was a request from WG chair to clarify bidirectionality extensions (compared to rfc 3471/3473) currently written within the draft. In my opinion RFC3471/3473 is enough for current wson signaling , I see room for optimization but not have clear balance in mind (effort in extention vs benefit). 2. Signal Attribute and Processing The main editing that has to be done is a reconciliation with latest versions of draft-ietf-ccamp-rwa-info/draft-ietf-ccamp-rwa-wson-encode, specific rsvp [R]BNF needs to be written as well. This will clarify the a new object required to carry signal compatibility information. 3. Some editing around (at least the distributed wavelenght assignment section). Cheers G On 11/13/11 2:39 AM, Lou Berger wrote: > Authors of WG documents, > If you are *not* presenting a WG document that you edit/author this > week, please be prepared to say a few words on document > status/progress/planned revisions in our first session. Alternatively, > you can send this information to the WG mail list prior to Tuesday's > meeting. > > Much thanks. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From giomarti@cisco.com Mon Nov 14 13:47:04 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD73A21F8E38 for ; Mon, 14 Nov 2011 13:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0odShNXk6HUa for ; Mon, 14 Nov 2011 13:47:04 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0158321F8E2E for ; Mon, 14 Nov 2011 13:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=788; q=dns/txt; s=iport; t=1321307224; x=1322516824; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=RAknYWxsTOTwPDG4Xq0WKBnwRQFL3xBEJXOJZ87k9P8=; b=AvkDYhrwN8p6RwmoM9lBco4JushHBnHkCz+DA7jfy2be5cKG7iMgDEFG RKRotlPAY7YmYEx0wZkuFkbAVPwuZE8gtWUrqb1PRbNZwc95ShMeQl/3K PjR9/9UHxyibL3YUNF3cPT6ULTRjbP0uPJKMGFse/27wVERwhZT2Od2xd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPKLwU6Q/khR/2dsb2JhbABDqWiBBYILASVAPRYYAwIBAgFLDQgBARcHh2iZBoEmAZ52iX8ElC6Reg X-IronPort-AV: E=Sophos;i="4.69,511,1315180800"; d="scan'208";a="121586606" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 14 Nov 2011 21:46:54 +0000 Received: from ams3-vpn-dhcp4706.cisco.com (ams3-vpn-dhcp4706.cisco.com [10.61.82.97]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAELks8r011488 for ; Mon, 14 Nov 2011 21:46:54 GMT Message-ID: <4EC18C58.1020806@cisco.com> Date: Mon, 14 Nov 2011 22:47:04 +0100 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] WSON signal compatibility & interface class X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 21:47:04 -0000 Dear WG, related to WSON discussion and in particular the signal compatibility issue, we update the following draft: http://tools.ietf.org/html/draft-martinelli-wson-interface-class-01 During ietf81 in Quebec there was some interesting questions we try to address in this version. The main advantages of this solution would be: a. to get rid of some specific optical knowledge currently defined in the wson drafts keeping protocols independent from future modulation formats/FEC standardizations b. being compatible with the ITU application code For sure this will require some updates to several WSON drafts under discussion but we believe will provide a real benefit to current and future wson protocol extensions around. comments/thoughts? Cheers G From giomarti@cisco.com Mon Nov 14 15:43:25 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2041F0C7D; Mon, 14 Nov 2011 15:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.372 X-Spam-Level: X-Spam-Status: No, score=-9.372 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXc6AH7-rQcy; Mon, 14 Nov 2011 15:43:24 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7A1F0C64; Mon, 14 Nov 2011 15:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=40448; q=dns/txt; s=iport; t=1321314202; x=1322523802; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=jhyeZhzvjtfYVLLYplccxt9p/lL42vg+iwgS/FZht9o=; b=XL83HfgKmHLnh473Z3DUP0/emOm45TGp/naj5haL1e1iYVedm35M0JqF y4YIrNPZgny31dISC6Qb2riuChS1riS7wqNoIyjSe0aTP6Z9skOMvEUMB z43fxYcp0H6noAGckQGDu0UoTKaH4QxeUpeXEHxUX/8q52CL+xmS+MX3J 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AAHqmwU6Q/khM/2dsb2JhbABCgk2CNJRjjj2BSIEFgXIBAQEDAQEBAQ8BEApBCxAJAg4DBAEBAQkXAQYDAgIPAhYfBgMIBg0BBQIBAR6HYAibCgGMWZIaiGmBFgSULpF6 X-IronPort-AV: E=Sophos;i="4.69,511,1315180800"; d="scan'208,217";a="59840436" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Nov 2011 23:43:20 +0000 Received: from ams3-vpn-dhcp4706.cisco.com (ams3-vpn-dhcp4706.cisco.com [10.61.82.97]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAENhJOk009811; Mon, 14 Nov 2011 23:43:19 GMT Message-ID: <4EC1A7A2.90302@cisco.com> Date: Tue, 15 Nov 2011 00:43:30 +0100 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Iftekhar Hussain References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090106040800030809060001" Cc: "ccamp@ietf.org" , Marco Sosa , Abinder Dhillon , "ccamp-bounces@ietf.org" Subject: Re: [CCAMP] =?utf-8?b?562U5aSNOiAg562U5aSNOiBSZTogIFRyeWluZyB0byBy?= =?utf-8?q?esolve_flexi-grid_issue_1?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:43:25 -0000 This is a multi-part message in MIME format. --------------090106040800030809060001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/14/11 7:06 PM, Iftekhar Hussain wrote: > > Fatai, > > ITU is defining the grid (frequencies). The allocation of frequencies > is left to specific implementations and use cases. How did you infer > that it precludes the use of split-spectrum use cases. Why one should > impose artificial restrictions? > +1 G > > Iftekhar > > *From:*Zhangfatai [mailto:zhangfatai@huawei.com] > *Sent:* Sunday, November 13, 2011 10:15 PM > *To:* li.yao3@zte.com.cn > *Cc:* Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; > ccamp-bounces@ietf.org > *Subject:* ç­”å¤: [CCAMP] ç­”å¤: ç­”å¤: Re: Trying to resolve flexi-grid > issue 1 > > Hi Yao, > > Agree with you. > > I would like to describe what you said in another way: > > Uncontinuous usage for the frequencies has not been defined (even > mentioned) in ITU-T data plane. > > Thanks > > Fatai > > ------------------------------------------------------------------------ > > *å‘件 人**:*ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] 代表 > li.yao3@zte.com.cn [li.yao3@zte.com.cn] > *å‘é€æ—¶é—´**:*2011å¹´11月14æ—¥11:22 > *到**:*li.yao3@zte.com.cn > *Cc:* Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; > ccamp-bounces@ietf.org > *主题**:*[CCAMP] ç­”å¤: ç­”å¤: Re: Trying to resolve flexi-grid issue 1 > > > Hi ALL: > > Correct my mistake."whether the slices will be switched with > /continuous/ form is not clear." should be > "whether the slices will be switched with /uncontinuous/form is not > clear." > > ccamp-bounces@ietf.org 写于 2011-11-14 > 11:13:04: > > > > > Hi Iftekhar: > > > > Please see below. > > > > ccamp-bounces@ietf.org 写于 > 2011-11-14 10:48:38: > > > > > Hi Malcolm, > > > > > > Agreed with your observation about fragmentation in flexible grid. > > > BTW, this is one of the reasons why we need to consider flexible > > > approach for label definition that allows defragmentation (e.g., see > > > split-spectrum super-channel option in http://tools.ietf. > > > org/html/draft-hussain-ccamp-super-channel-label-02). > > > > Actually, fragmentation will appear as traffic is > > added and removed from links. The work of defragmentation should be > > left to computation entity like PCE. > > However, whether the slices will be switched with /continuous/ form > isnot clear. > > > > > > > > > > Regarding consideration about guard-band, I think, it can be > > > considered as a part of path computation constraint - does not > > > necessarily need to advertise this as a part of routing. > > > > > > Agree. > > > > > > > > > > Regards, > > > Iftekhar > > > > > > From: Malcolm.BETTS@zte.com.cn > [mailto:Malcolm.BETTS@zte.com.cn] > > > > Sent: Sunday, November 13, 2011 6:11 PM > > > To: adrian@olddog.co.uk > > > Cc: ccamp@ietf.org ; ccamp-bounces@ietf.org > > > > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1 > > > > > > Hi Adrian, > > > > > > Interesting questions, but I think we need to consider the bigger > > > picture first. A few quick thoughts: > > > > > > One motivation for the flexi-grid is to support the next generation > > > optical signals (>100Gb/s) that cannot be efficiently accommodated > > > with the current fixed grid. However, we can expect to see flexi- > > > grid deployed before these higher bit rate systems. > > > > > > The current fixed grid provides an implicit guard band between > > > optical channels (and slots can be left unused to allow a greater > > > guard band). With flexi-grid we will probably need to specify the > > > guard band. The guard band will probably need to defined by a PCE > > > application but we will need to define the parameters. > > > > > > Given that transiting an OADM narrows the optical bandwidth it may > > > be possible to optimize the network by adjusting the requested > > > bandwidth based on the number of OADMs in the path. How would we > > > "retain" this information to support restoration. > > > > > > I expect that we will have a concatenation of flexi-grid and fixed > > > grid links (managed via a PCE) in the network. How will we signal > > > for example for a slot to carry 10Gb/s signal across a network that > > > includes the concatenation of fixed grid and flexi-grid segments. > > > The implication of routing (RWA) may also be interesting. > > > > > > The flexi-grid will result in bandwidth fragmentation as traffic is > > > added and removed from links. We need to consider the need to > > > defragment the link. > > > > > > I think that the implications of flexi-grid go beyond signalling > > > into routing (RWA). > > > > > > The SG 15 will be meeting in December and will hold discussion on > > > the use of the flexi-grid. It would be useful to provide, either > > > formally or informally a set of questions. > > > > > > Regards, > > > > > > Malcolm > > > > > > > > > > > "Adrian Farrel" > > > > Sent by: ccamp-bounces@ietf.org > > > 12/11/2011 05:29 PM > > > > > > Please respond to > > > adrian@olddog.co.uk > > > > > > To > > > > > > > > > > > > > cc > > > > > > Subject > > > > > > [CCAMP] Trying to resolve flexi-grid issue 1 > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > I wanted to see whether we can prime the discussions of > flexi-gridlabels in > > > advance of the WG meetings this week. > > > > > > It looks like we have successfully agreed that there are two > significant > > > differences between the label formats defined in > > > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid- > > lambda-label > > > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid- > > > rsvp-te-ext > > > > > > The first point seems relatively minor: > > > > > > Should we use a new value for the Grid field or should we > continueto use the > > > value that indicates DWDM. > > > > > > In favor of continuing to use the DWDM value is the fact that the > > > ITU-T has not > > > defined a new grid for flexible wavelength assignments. In fact, > > theITU-T says > > > that flexible assignments should be made from the DWDM grid. > > > > > > On the other hand we need to understand that the fields in GMPLS > > objects exist > > > to make implementation easier and to convey information. There is > > noneed for a > > > direct mapping to ITU-T grids. > > > > > > Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is > > correct that > > > the flexible grid wavelengths will be suggested from the ITU-T DWDM > > > grid, but it > > > is not being as helpful as it could be. > > > > > > When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not > implying > > > that there is a new and different grid defined by the ITU-T. What > > itis saying > > > is that the label is a flexi-grid label selected from the grid > > defined by the > > > ITU-T for that purpose (i.e., the DWDM grid). > > > > > > Personally, i don't see this as a very large issue. draft- > > farrkingelwould work > > > just as well if we decide to use Grid==1. however, I think it is > > > marginally more > > > helpful and useful to be able to recognise the different label use > > > cases (fixed > > > grid / flexible grid) by looking at a field early in the Label object. > > > Conversely, I don't believe that draft-zhang would be broken by > > using Grid==3. > > > > > > So my compromise proposal is that both I-Ds use Grid==3. Then we can > > > concentrate > > > on the more significant second issue (see separate email). > > > > > > What do folk think? > > > > > > Cheers, > > > Adrian > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp --------------090106040800030809060001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 11/14/11 7:06 PM, Iftekhar Hussain wrote:

Fatai,

 

ITU is defining the grid (frequencies). The allocation of frequencies is left to specific implementations and use cases. How did you infer that it precludes the use of split-spectrum use cases. Why one should impose artificial restrictions?

 

+1
G

 

 

Iftekhar

 

From: Zhangfatai [mailto:zhangfatai@huawei.com]
Sent: Sunday, November 13, 2011 10:15 PM
To: li.yao3@zte.com.cn
Cc: Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; ccamp-bounces@ietf.org
Subject: ç­”å¤: [CCAMP] ç­”å¤: ç­”å¤: Re: Trying to resolve flexi-grid issue 1

 

Hi Yao,

 

Agree with you.

 

I would like to describe what you said in another way:

 

Uncontinuous usage for the frequencies has not been defined (even mentioned) in ITU-T data plane.

 

Thanks

 

Fatai

 

 

 

 

å‘件 人: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] 代表 li.yao3@zte.com.cn [li.yao3@zte.com.cn]
å‘é€æ—¶é—´: 2011å¹´11月14æ—¥ 11:22
到: li.yao3@zte.com.cn
Cc: Abinder Dhillon; ccamp@ietf.org; Iftekhar Hussain; ccamp-bounces@ietf.org
主题: [CCAMP] ç­”å¤: ç­”å¤: Re: Trying to resolve flexi-grid issue 1


Hi ALL:

Correct my mistake."whether the slices will be switched with continuous form is not clear." should be
"whether the slices will be switched with uncontinuous form is not clear."

ccamp-bounces@ietf.org 写于 2011-11-14 11:13:04:

>
> Hi Iftekhar:
>
> Please see below.
>
> ccamp-bounces@ietf.org 写于 2011-11-14 10:48:38:
>
> > Hi Malcolm,
> >  
> > Agreed with your observation about fragmentation in flexible grid.
> > BTW, this is one of the reasons why we need to consider flexible
> > approach for label definition that allows defragmentation (e.g., see
> > split-spectrum  super-channel option in  http://tools.ietf.
> > org/html/draft-hussain-ccamp-super-channel-label-02).
>
> <Yao>Actually, fragmentation will appear as traffic is
> added and removed from links. The work of defragmentation should be
> left to computation entity like PCE.
> However, whether the slices will be switched with continuous form isnot clear.
>
>
> >  
> > Regarding consideration about guard-band, I think, it can be
> > considered as a part of path computation constraint - does not
> > necessarily need to advertise this as a part of routing.
>
>
> <Yao> Agree.
>
>
> >  
> > Regards,
> > Iftekhar
> >  
> > From: Malcolm.BETTS@zte.com.cn [mailto:Malcolm.BETTS@zte.com.cn]
> > Sent: Sunday, November 13, 2011 6:11 PM
> > To: adrian@olddog.co.uk
> > Cc: ccamp@ietf.org; ccamp-bounces@ietf.org
> > Subject: Re: [CCAMP] Trying to resolve flexi-grid issue 1
> >  
> > Hi Adrian,
> >
> > Interesting questions, but I think we need to consider the bigger
> > picture first.  A few quick thoughts:
> >
> > One motivation for the flexi-grid is to support the next generation
> > optical signals (>100Gb/s) that cannot be efficiently accommodated
> > with the current fixed grid.  However, we can expect to see flexi-
> > grid deployed before these higher bit rate systems.
> >
> > The current fixed grid provides an implicit guard band between
> > optical channels (and slots can be left unused to allow a greater
> > guard band).  With flexi-grid we will probably need to specify the
> > guard band.  The guard band will probably need to defined by a PCE
> > application but we will need to define the parameters.  
> >
> > Given that transiting an OADM narrows the optical bandwidth it may
> > be possible to optimize the network by adjusting the requested
> > bandwidth based on the number of OADMs in the path.  How would we
> > "retain" this information to support restoration.
> >
> > I expect that we will have a concatenation of flexi-grid and fixed
> > grid links (managed via a PCE) in the network.  How will we signal
> > for example for a slot to carry 10Gb/s signal across a network that
> > includes the concatenation of fixed grid and flexi-grid segments.  
> > The implication of routing (RWA) may also be interesting.
> >
> > The flexi-grid will result in bandwidth fragmentation as traffic is
> > added and removed from links.  We need to consider the need to
> > defragment the link.
> >
> > I think that the implications of flexi-grid go beyond signalling
> > into routing (RWA).
> >
> > The SG 15 will be meeting in December and will hold discussion on
> > the use of the flexi-grid.  It would be useful to provide, either
> > formally or informally a set of questions.
> >
> > Regards,
> >
> > Malcolm
> >
>
> >
> > "Adrian Farrel" <adrian@olddog.co.uk>
> > Sent by: ccamp-bounces@ietf.org
> > 12/11/2011 05:29 PM
> >
> > Please respond to
> > adrian@olddog.co.uk
> >
> > To
> >
> > <ccamp@ietf.org>
> >
> > cc
> >
> > Subject
> >
> > [CCAMP] Trying to resolve flexi-grid issue 1
> >
> >  
> >
> >
> >
> >
> > Hi,
> >
> > I wanted to see whether we can prime the discussions of flexi-gridlabels in
> > advance of the WG meetings this week.
> >
> > It looks like we have successfully agreed that there are two significant
> > differences between the label formats defined in
> > http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-
> lambda-label
> > and http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-
> > rsvp-te-ext
> >
> > The first point seems relatively minor:
> >
> > Should we use a new value for the Grid field or should we continueto use the
> > value that indicates DWDM.
> >
> > In favor of continuing to use the DWDM value is the fact that the
> > ITU-T has not
> > defined a new grid for flexible wavelength assignments. In fact,
> theITU-T says
> > that flexible assignments should be made from the DWDM grid.
> >
> > On the other hand we need to understand that the fields in GMPLS
> objects exist
> > to make implementation easier and to convey information. There is
> noneed for a
> > direct mapping to ITU-T grids.
> >
> > Thus, when draft-zhang suggests using Grid==1 (ITU-T DWDM) it is
> correct that
> > the flexible grid wavelengths will be suggested from the ITU-T DWDM
> > grid, but it
> > is not being as helpful as it could be.
> >
> > When draft-farrkingel suggests using Grid==3 (ITU-T Flex) it is not implying
> > that there is a new and different grid defined by the ITU-T. What
> itis saying
> > is that the label is a flexi-grid label selected from the grid
> defined by the
> > ITU-T for that purpose (i.e., the DWDM grid).
> >
> > Personally, i don't see this as a very large issue. draft-
> farrkingelwould work
> > just as well if we decide to use Grid==1. however, I think it is
> > marginally more
> > helpful and useful to be able to recognise the different label use
> > cases (fixed
> > grid / flexible grid) by looking at a field early in the Label object.
> > Conversely, I don't believe that draft-zhang would be broken by
> using Grid==3.
> >
> > So my compromise proposal is that both I-Ds use Grid==3. Then we can
> > concentrate
> > on the more significant second issue (see separate email).
> >
> > What do folk think?
> >
> > Cheers,
> > Adrian
> >
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> > _______________________________________________
> > CCAMP mailing list
> > CCAMP@ietf.org
> > https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp



_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--------------090106040800030809060001-- From giomarti@cisco.com Mon Nov 14 15:50:15 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C730821F8DDF for ; Mon, 14 Nov 2011 15:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-2.483, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpWBEljS2haL for ; Mon, 14 Nov 2011 15:50:15 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A243221F8B03 for ; Mon, 14 Nov 2011 15:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=3950; q=dns/txt; s=iport; t=1321314614; x=1322524214; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/ZkOvyJQcJx/tawzbqvaindAazF+Kg8dOnOi38VgC4g=; b=F2xgOQJNPChry5rXI2rez2qrGMhODTJAWaIWLOPPVDBPFqpgQgjvQUwk lR98KcvgiqtIvPqtVJXXNzg8EyWVIhl3OtR6TeAu9vrXCQydlrESEDhmS WDBc+RarMqOEgZf9/pZxPe81MZayl/SCv3UX+nCx3KIDXaSkfL0o8RXZd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP+owU6Q/khR/2dsb2JhbABDhQGkaIEFgXIBAQEEAQEBDwEfATsKAQwECQIRBAEBAQQFFggFAgkDAgECARUfCQgTAQUCAQEeh2iafAGMUwiSHIEshzmBGgSHZIxKkXo X-IronPort-AV: E=Sophos;i="4.69,511,1315180800"; d="scan'208";a="3063033" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 14 Nov 2011 23:50:04 +0000 Received: from ams3-vpn-dhcp4706.cisco.com (ams3-vpn-dhcp4706.cisco.com [10.61.82.97]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAENo3bx032167; Mon, 14 Nov 2011 23:50:03 GMT Message-ID: <4EC1A936.5000608@cisco.com> Date: Tue, 15 Nov 2011 00:50:14 +0100 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <022e01cca1a4$61f50da0$25df28e0$@olddog.co.uk> <03d001cca278$c41f69b0$4c5e3d10$@olddog.co.uk> In-Reply-To: <03d001cca278$c41f69b0$4c5e3d10$@olddog.co.uk> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:50:15 -0000 probably worth to remind that current wson signaling draft (draft-ietf-ccamp-wson-signaling) does not extend traffic parameters but needs an additional tlv (still TBD) to carry wson information required for xc programming. Well, still a live document and looks probably time to review that choice but this is the current status. Cheers G On 11/14/11 3:54 AM, Adrian Farrel wrote: > Hi, > > I've not spent a lot of time looking at the traffic parameters, but yes. It > seems to me that part of requesting the LSP could include specifying a number of > parameters related to capacity and construction. That would mean that "m" might > reasonably be in the traffic parameters (or maybe there would be a choice of > values of m) and the final chosen value of m would then be placed in the label. > > You are, of course, right that issues like interface ID and component interface > ID are also necessary for XC programming. > > A > >> -----Original Message----- >> From: Zhangfatai [mailto:zhangfatai@huawei.com] >> Sent: 14 November 2011 02:20 >> To: adrian@olddog.co.uk; ccamp@ietf.org >> Subject: ´ð¸´: [CCAMP] Flexi-grid issue 2 >> >> Hi Adrian, >> >> Do you agree that "m" should also be put into Traffic Parameters object, which >> indicates how much resource should be reserved before we decide whethere we >> should put "m" in the Label? >> >> Talking about the Label definition from RFC3471, the Label defined in [draft- >> zhang] contains "enough information" to allow the receiving node to program > its >> cross connect, ie., nothing is missed from my understanding. >> >> We know that the reciveing node cannot program its cross connect correctly by >> using only the information contained in the "Label", because it also needs to > get >> some other information (e.g., TE link or component link information) from > other >> RSVP objects such as ERO or RSVP-HOP. >> >> Please correct me if I have any misunderstanding. >> >> Fatai >> >> Thanks >> >> >> ________________________________________ >> ·¢¼þÈË: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] ´ú±í Adrian Farrel >> [adrian@olddog.co.uk] >> ·¢ËÍʱ¼ä: 2011Äê11ÔÂ13ÈÕ 9:34 >> µ½: ccamp@ietf.org >> Ö÷Ìâ: [CCAMP] Flexi-grid issue 2 >> >> Hi, >> >> Second email on the differences between the label formats defined in >> http://datatracker.ietf.org/doc/draft-farrkingel-ccamp-flexigrid-lambda-label >> and > http://datatracker.ietf.org/doc/draft-zhang-ccamp-flexible-grid-rsvp-te-ext >> This issue is more complicated than the first issue. This question has two >> sub-points: >> a. where do we carry the flexi-grid m parameter? >> b. where do we carry traffic parameters for flexi-grid? >> >> draft-zhang is a more comprehensive document that draft-farrkingel because it >> aims to cover a number of significant signaling parameters for RSVP-TE. >> draft-farrkingel only attempts to define a label structure. >> >> Thus, the question we need to resolve is not where to carry the traffic >> parameters for flexi-grid, but what constitutes a label in flexi-grid? >> >> Maybe we should start this with the question: what is a label? RFC 3471 says: >> >> A generalized label contains enough information to allow the receiving >> node to program its cross connect, regardless of the type of this >> cross connect, such that the ingress segments of the path are >> properly joined. >> >> So, what information do we need to carry in a label to satisfy that? I think > it >> is a full description of the channel, and AFAICS for flexi-grid this includes >> the m parameter. >> >> Thanks, >> Adrian >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Mon Nov 14 17:19:17 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362541F0CD7 for ; Mon, 14 Nov 2011 17:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.966 X-Spam-Level: X-Spam-Status: No, score=-99.966 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4xb+281tii6 for ; Mon, 14 Nov 2011 17:19:16 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id A44D81F0CD2 for ; Mon, 14 Nov 2011 17:19:16 -0800 (PST) Received: (qmail 27384 invoked by uid 0); 15 Nov 2011 01:19:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 15 Nov 2011 01:19:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=u0f0ilI4e1nSgR/0/vXURfiCnUzUVfg2i8FgKCY7xn4=; b=C+s0B+rUP1nXnZebya2Svv67rZz8/FKEyNXU/Twq+pbVp76PLK/fXrMXztkhvG4qq8YUBz1emfhRz1DZyRsSD6flEoYZbdyXKCZGiaXxAohUlHSVjjA55JZtQgpl5nF2; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RQ7gB-00087e-T0; Mon, 14 Nov 2011 18:19:16 -0700 Message-ID: <4EC1BE12.2090304@labn.net> Date: Tue, 15 Nov 2011 09:19:14 +0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Giovanni Martinelli References: <4EBF1FEE.6020904@labn.net> <4EC18919.2090405@cisco.com> In-Reply-To: <4EC18919.2090405@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] request to WG authors/editors who are not presenting this week X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:19:17 -0000 Thank you for the update! Lou On 11/15/2011 5:33 AM, Giovanni Martinelli wrote: > Lou, ccamp-ers, > > here some update on draft-ietf-ccamp-wson-signaling-02, since we got > some intra-author discussion but not significant updates. > Unfortunately I'm not able to attend this ietf I leave some notes that > represent my view since there's no finalization among co-authors yet (so > co-authors/editors please feel free to comment). > > 1. Bidirectionality. There was a request from WG chair to clarify > bidirectionality extensions (compared to rfc 3471/3473) currently > written within the draft. In my opinion RFC3471/3473 is enough for > current wson signaling , I see room for optimization but not have clear > balance in mind (effort in extention vs benefit). > > 2. Signal Attribute and Processing > The main editing that has to be done is a reconciliation with latest > versions of draft-ietf-ccamp-rwa-info/draft-ietf-ccamp-rwa-wson-encode, > specific rsvp [R]BNF needs to be written as well. > This will clarify the a new object required to carry signal > compatibility information. > > 3. Some editing around (at least the distributed wavelenght assignment > section). > > Cheers > G > > > > > On 11/13/11 2:39 AM, Lou Berger wrote: >> Authors of WG documents, >> If you are *not* presenting a WG document that you edit/author this >> week, please be prepared to say a few words on document >> status/progress/planned revisions in our first session. Alternatively, >> you can send this information to the WG mail list prior to Tuesday's >> meeting. >> >> Much thanks. >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > From leeyoung@huawei.com Mon Nov 14 17:45:07 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC6811E8134 for ; Mon, 14 Nov 2011 17:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQC-++QwO9eg for ; Mon, 14 Nov 2011 17:45:06 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCDB11E80CC for ; Mon, 14 Nov 2011 17:45:06 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUO00AO5I74M6@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 14 Nov 2011 19:45:05 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUO004LSI6T6T@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 14 Nov 2011 19:45:04 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 14 Nov 2011 17:44:54 -0800 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Mon, 14 Nov 2011 17:44:36 -0800 Date: Tue, 15 Nov 2011 01:44:34 +0000 From: Leeyoung X-Originating-IP: [10.47.137.170] To: "ccamp@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718192704@dfweml501-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_XANxIO4c305UGyiHNajeog)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Update on General Information Thread-index: AcyjOB+jxlaTpLCBSG6duPMutSp3Sw== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "Brungard, Deborah A, ALABS" Subject: [CCAMP] Update on General Information X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:45:07 -0000 --Boundary_(ID_XANxIO4c305UGyiHNajeog) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Lou, This is to give you the status of the following WG drafts that will not be presented in Taipei meeting. - draft-ietf-ccamp-general-constraint-encode-05.txt (General Network Element Constraint Encoding for GMPLS Controlled Networks). o Some clarifying texts (from Jonathan Harrison on label-range) will be added in the revision as follows: "This constraint was motivated a type of tunable wave band add/drop multi-plexer. The device can add/drop wavelengths within fixed range from its tuning center. So we need three pieces of information: (a) the total set of wavelengths that could possibly be reached (the labels in the label set field), (b) the range of wavelengths that the device can process at once (MaxLabelRange), (c) the current wavelengths (available labels sub-TLV) in use (tells us constraints on tuning the devices up or down to incorporate more wavelengths)." o Issues on the multiple ISCD capability is addressed by Cyril/Fatai have been discussed in the corresponding OSPF extension; once the solution is settled, encoding will be included if changes are needed. - draft-ietf-ccamp-rwa-info-13.txt (Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks) o There are some clarifying texts (from Cyril) that are needed to be updated on the revision, which we will do shortly after the Taipei meeting. Thanks, Young --Boundary_(ID_XANxIO4c305UGyiHNajeog) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Lou,

 

This is to give you the status of the following WG drafts that will not be presented in Taipei meeting.

 

-          draft-ietf-ccamp-general-constraint-encode-05.txt (General Network Element Constraint Encoding for GMPLS Controlled Networks).

o    Some clarifying texts (from Jonathan Harrison on label-range) will be added in the revision as follows:

“This constraint was motivated a type of  tunable wave band add/drop multi-plexer. The device can add/drop wavelengths within fixed range from its tuning center. So we need three pieces of information: (a) the total set of wavelengths that could possibly be reached (the labels in the label set field), (b) the range of wavelengths that the device can process at once (MaxLabelRange), (c) the current wavelengths (available labels sub-TLV) in use  (tells us constraints on tuning the devices up or down to incorporate more wavelengths).”

 

o   Issues on the multiple ISCD capability is addressed by Cyril/Fatai have been discussed in the corresponding OSPF extension; once the solution is settled, encoding will be included if changes are needed.

 

-          draft-ietf-ccamp-rwa-info-13.txt (Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks)

o    There are some clarifying texts (from Cyril) that are needed to be updated on the revision, which we will do shortly after the Taipei meeting.

 

Thanks,

Young  

 

            

 

--Boundary_(ID_XANxIO4c305UGyiHNajeog)-- From zhang.fei3@zte.com.cn Mon Nov 14 17:55:15 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981A11E8271; Mon, 14 Nov 2011 17:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.051 X-Spam-Level: X-Spam-Status: No, score=-98.051 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYeWqPHmjqxH; Mon, 14 Nov 2011 17:55:14 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0211E8275; Mon, 14 Nov 2011 17:55:13 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901461793122; Tue, 15 Nov 2011 09:43:41 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 18185.1797504140; Tue, 15 Nov 2011 09:54:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAF1snpJ074968; Tue, 15 Nov 2011 09:54:49 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4EC1A936.5000608@cisco.com> To: Giovanni Martinelli , adrian@olddog.co.uk MIME-Version: 1.0 X-KeepSent: BD994C32:1A227706-48257949:0008D358; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 15 Nov 2011 09:54:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-15 09:54:50, Serialize complete at 2011-11-15 09:54:50 Content-Type: multipart/alternative; boundary="=_alternative 000A81F548257949_=" X-MAIL: mse02.zte.com.cn pAF1snpJ074968 Cc: ccamp@ietf.org, ccamp-bounces@ietf.org Subject: Re: [CCAMP] Flexi-grid issue 2 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:55:15 -0000 This is a multipart message in MIME format. --=_alternative 000A81F548257949_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U29tZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uDQoNCkFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRp b24gaW4gUkZDMjIxMCBzZWN0aW9uIDI6DQoNCiJJbmZvcm1hdGlvbiBnZW5lcmF0ZWQgYXQgZWFj aCBzZW5kZXIgZGVzY3JpYmluZyB0aGUgZGF0YSB0cmFmZmljIA0KZ2VuZXJhdGVkIGJ5IHRoYXQg c2VuZGVyICh0aGUgU2VuZGVyIFRTcGVjKS4gVGhpcyBpbmZvcm1hdGlvbiBpcyBjYXJyaWVkIA0K ZnJvbSB0aGUgc2VuZGVyIHRvIGludGVybWVkaWF0ZSBuZXR3b3JrIGVsZW1lbnRzIGFuZCB0aGUg cmVjZWl2ZXIocykgYnkgDQpSU1ZQLCBidXQgaXMgbmV2ZXIgbW9kaWZpZWQgYnkgaW50ZXJtZWRp YXRlIGVsZW1lbnRzIHdpdGhpbiB0aGUgbmV0d29yay4gDQpUaGlzIGluZm9ybWF0aW9uIGlzIGNh cnJpZWQgaW4gUlNWUCBTRU5ERVJfVFNQRUMgb2JqZWN0cyIuDQoNCkJ1dCBpZiB0aGUgTy1FLU8g c2NlbmFyaW8gc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW4gZmxleGlibGUgZ3JpZCBzY2VuYXJpbywg DQp0aGUgIm0iIHZhbHVlIG1heSBiZSBjaGFuZ2VkLiBNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRo YXQgaXQgTVVTVCBiZSANCmNvbnNpZGVyZWQuDQoNCkp1c3QgbXkgdHdvIGNlbnRzLCBJIGRvIG5v dCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBwdXQgIm0iIGluIHRoZSANClNFTkRFUl9UU1BF QyBvYmplY3QsIHdoaWNoIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlOyBldmVuIHRoYXQgaXQg bWF5IGJlIA0KY2FycmllZCBleGNlcHQgaW4gdGhlIGxhYmVsIG9iamVjdCwgaXQgc2hvdWxkIGJl IHRyZWF0ZWQgaW4gYW5vdGhlciB3YXkgb3IgDQpsaWtlIEdpb3Zhbm5pIHNhaWQgLGFuIGFkZGl0 aW9uYWwgVExWLg0KDQpCZXN0LA0KDQpGZWkNCg0KDQoNCkdpb3Zhbm5pIE1hcnRpbmVsbGkgPGdp b21hcnRpQGNpc2NvLmNvbT4gDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3JnDQoyMDEx LTExLTE1IDA3OjUwDQoNCsrVvP7Iyw0KYWRyaWFuQG9sZGRvZy5jby51aw0Ks63LzQ0KY2NhbXBA aWV0Zi5vcmcNCtb3zOINClJlOiBbQ0NBTVBdIEZsZXhpLWdyaWQgaXNzdWUgMg0KDQoNCg0KDQoN Cg0KcHJvYmFibHkgd29ydGggdG8gcmVtaW5kIHRoYXQgY3VycmVudCB3c29uIHNpZ25hbGluZyBk cmFmdA0KKGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWxpbmcpIGRvZXMgbm90IGV4dGVuZCB0 cmFmZmljIHBhcmFtZXRlcnMgYnV0DQpuZWVkcyBhbiBhZGRpdGlvbmFsIHRsdiAoc3RpbGwgVEJE KSB0byBjYXJyeSB3c29uIGluZm9ybWF0aW9uIHJlcXVpcmVkDQpmb3IgeGMgcHJvZ3JhbW1pbmcu DQoNCldlbGwsIHN0aWxsIGEgbGl2ZSBkb2N1bWVudCBhbmQgbG9va3MgcHJvYmFibHkgdGltZSB0 byByZXZpZXcgdGhhdA0KY2hvaWNlIGJ1dCB0aGlzIGlzIHRoZSBjdXJyZW50IHN0YXR1cy4NCg0K Q2hlZXJzDQpHDQoNCg0KT24gMTEvMTQvMTEgMzo1NCBBTSwgQWRyaWFuIEZhcnJlbCB3cm90ZToN Cj4gSGksDQo+DQo+IEkndmUgbm90IHNwZW50IGEgbG90IG9mIHRpbWUgbG9va2luZyBhdCB0aGUg dHJhZmZpYyBwYXJhbWV0ZXJzLCBidXQgeWVzLiANCkl0DQo+IHNlZW1zIHRvIG1lIHRoYXQgcGFy dCBvZiByZXF1ZXN0aW5nIHRoZSBMU1AgY291bGQgaW5jbHVkZSBzcGVjaWZ5aW5nIGEgDQpudW1i ZXIgb2YNCj4gcGFyYW1ldGVycyByZWxhdGVkIHRvIGNhcGFjaXR5IGFuZCBjb25zdHJ1Y3Rpb24u IFRoYXQgd291bGQgbWVhbiB0aGF0IA0KIm0iIG1pZ2h0DQo+IHJlYXNvbmFibHkgYmUgaW4gdGhl IHRyYWZmaWMgcGFyYW1ldGVycyAob3IgbWF5YmUgdGhlcmUgd291bGQgYmUgYSANCmNob2ljZSBv Zg0KPiB2YWx1ZXMgb2YgbSkgYW5kIHRoZSBmaW5hbCBjaG9zZW4gdmFsdWUgb2YgbSB3b3VsZCB0 aGVuIGJlIHBsYWNlZCBpbiB0aGUgDQpsYWJlbC4NCj4NCj4gWW91IGFyZSwgb2YgY291cnNlLCBy aWdodCB0aGF0IGlzc3VlcyBsaWtlIGludGVyZmFjZSBJRCBhbmQgY29tcG9uZW50IA0KaW50ZXJm YWNlDQo+IElEIGFyZSBhbHNvIG5lY2Vzc2FyeSBmb3IgWEMgcHJvZ3JhbW1pbmcuDQo+DQo+IEEN Cj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBaaGFuZ2ZhdGFpIFtt YWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tXQ0KPj4gU2VudDogMTQgTm92ZW1iZXIgMjAxMSAw MjoyMA0KPj4gVG86IGFkcmlhbkBvbGRkb2cuY28udWs7IGNjYW1wQGlldGYub3JnDQo+PiBTdWJq ZWN0OiC08Li0OiBbQ0NBTVBdIEZsZXhpLWdyaWQgaXNzdWUgMg0KPj4NCj4+IEhpIEFkcmlhbiwN Cj4+DQo+PiBEbyB5b3UgYWdyZWUgdGhhdCAibSIgc2hvdWxkIGFsc28gYmUgcHV0IGludG8gVHJh ZmZpYyBQYXJhbWV0ZXJzIA0Kb2JqZWN0LCB3aGljaA0KPj4gaW5kaWNhdGVzIGhvdyBtdWNoIHJl c291cmNlIHNob3VsZCBiZSByZXNlcnZlZCBiZWZvcmUgd2UgZGVjaWRlIA0Kd2hldGhlcmUgd2UN Cj4+IHNob3VsZCBwdXQgIm0iIGluIHRoZSBMYWJlbD8NCj4+DQo+PiBUYWxraW5nIGFib3V0IHRo ZSBMYWJlbCBkZWZpbml0aW9uIGZyb20gUkZDMzQ3MSwgdGhlIExhYmVsIGRlZmluZWQgaW4gDQpb ZHJhZnQtDQo+PiB6aGFuZ10gY29udGFpbnMgImVub3VnaCBpbmZvcm1hdGlvbiIgdG8gYWxsb3cg dGhlIHJlY2VpdmluZyBub2RlIHRvIA0KcHJvZ3JhbQ0KPiBpdHMNCj4+IGNyb3NzIGNvbm5lY3Qs IGllLiwgbm90aGluZyBpcyBtaXNzZWQgZnJvbSBteSB1bmRlcnN0YW5kaW5nLg0KPj4NCj4+IFdl IGtub3cgdGhhdCB0aGUgcmVjaXZlaW5nIG5vZGUgY2Fubm90IHByb2dyYW0gaXRzIGNyb3NzIGNv bm5lY3QgDQpjb3JyZWN0bHkgYnkNCj4+IHVzaW5nIG9ubHkgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGUgIkxhYmVsIiwgYmVjYXVzZSBpdCBhbHNvIA0KbmVlZHMgdG8NCj4gZ2V0DQo+ PiBzb21lIG90aGVyIGluZm9ybWF0aW9uIChlLmcuLCBURSBsaW5rIG9yIGNvbXBvbmVudCBsaW5r IGluZm9ybWF0aW9uKSANCmZyb20NCj4gb3RoZXINCj4+IFJTVlAgb2JqZWN0cyBzdWNoIGFzIEVS TyBvciBSU1ZQLUhPUC4NCj4+DQo+PiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGhhdmUgYW55IG1p c3VuZGVyc3RhbmRpbmcuDQo+Pg0KPj4gRmF0YWkNCj4+DQo+PiBUaGFua3MNCj4+DQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gt6K8/sjLOiBjY2Ft cC1ib3VuY2VzQGlldGYub3JnIFtjY2FtcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEFkcmlhbiAN CkZhcnJlbA0KPj4gW2FkcmlhbkBvbGRkb2cuY28udWtdDQo+PiC3osvNyrG85DogMjAxMcTqMTHU wjEzyNUgOTozNA0KPj4gtb06IGNjYW1wQGlldGYub3JnDQo+PiDW98ziOiBbQ0NBTVBdIEZsZXhp LWdyaWQgaXNzdWUgMg0KPj4NCj4+IEhpLA0KPj4NCj4+IFNlY29uZCBlbWFpbCBvbiB0aGUgZGlm ZmVyZW5jZXMgYmV0d2VlbiB0aGUgbGFiZWwgZm9ybWF0cyBkZWZpbmVkIGluDQo+PiANCmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFycmtpbmdlbC1jY2FtcC1mbGV4aWdy aWQtbGFtYmRhLWxhYmVsDQoNCj4+IGFuZA0KPiANCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtemhhbmctY2NhbXAtZmxleGlibGUtZ3JpZC1yc3ZwLXRlLWV4dA0KDQo+PiBU aGlzIGlzc3VlIGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGUgZmlyc3QgaXNzdWUuIFRoaXMg cXVlc3Rpb24gaGFzIA0KdHdvDQo+PiBzdWItcG9pbnRzOg0KPj4gYS4gd2hlcmUgZG8gd2UgY2Fy cnkgdGhlIGZsZXhpLWdyaWQgbSBwYXJhbWV0ZXI/DQo+PiBiLiB3aGVyZSBkbyB3ZSBjYXJyeSB0 cmFmZmljIHBhcmFtZXRlcnMgZm9yIGZsZXhpLWdyaWQ/DQo+Pg0KPj4gZHJhZnQtemhhbmcgaXMg YSBtb3JlIGNvbXByZWhlbnNpdmUgZG9jdW1lbnQgdGhhdCBkcmFmdC1mYXJya2luZ2VsIA0KYmVj YXVzZSBpdA0KPj4gYWltcyB0byBjb3ZlciBhIG51bWJlciBvZiBzaWduaWZpY2FudCBzaWduYWxp bmcgcGFyYW1ldGVycyBmb3IgUlNWUC1URS4NCj4+IGRyYWZ0LWZhcnJraW5nZWwgb25seSBhdHRl bXB0cyB0byBkZWZpbmUgYSBsYWJlbCBzdHJ1Y3R1cmUuDQo+Pg0KPj4gVGh1cywgdGhlIHF1ZXN0 aW9uIHdlIG5lZWQgdG8gcmVzb2x2ZSBpcyBub3Qgd2hlcmUgdG8gY2FycnkgdGhlIHRyYWZmaWMN Cj4+IHBhcmFtZXRlcnMgZm9yIGZsZXhpLWdyaWQsIGJ1dCB3aGF0IGNvbnN0aXR1dGVzIGEgbGFi ZWwgaW4gZmxleGktZ3JpZD8NCj4+DQo+PiBNYXliZSB3ZSBzaG91bGQgc3RhcnQgdGhpcyB3aXRo IHRoZSBxdWVzdGlvbjogd2hhdCBpcyBhIGxhYmVsPyBSRkMgMzQ3MSANCnNheXM6DQo+Pg0KPj4g ICAgQSBnZW5lcmFsaXplZCBsYWJlbCBjb250YWlucyBlbm91Z2ggaW5mb3JtYXRpb24gdG8gYWxs b3cgdGhlIA0KcmVjZWl2aW5nDQo+PiAgICBub2RlIHRvIHByb2dyYW0gaXRzIGNyb3NzIGNvbm5l Y3QsIHJlZ2FyZGxlc3Mgb2YgdGhlIHR5cGUgb2YgdGhpcw0KPj4gICAgY3Jvc3MgY29ubmVjdCwg c3VjaCB0aGF0IHRoZSBpbmdyZXNzIHNlZ21lbnRzIG9mIHRoZSBwYXRoIGFyZQ0KPj4gICAgcHJv cGVybHkgam9pbmVkLg0KPj4NCj4+IFNvLCB3aGF0IGluZm9ybWF0aW9uIGRvIHdlIG5lZWQgdG8g Y2FycnkgaW4gYSBsYWJlbCB0byBzYXRpc2Z5IHRoYXQ/IEkgDQp0aGluaw0KPiBpdA0KPj4gaXMg YSBmdWxsIGRlc2NyaXB0aW9uIG9mIHRoZSBjaGFubmVsLCBhbmQgQUZBSUNTIGZvciBmbGV4aS1n cmlkIHRoaXMgDQppbmNsdWRlcw0KPj4gdGhlIG0gcGFyYW1ldGVyLg0KPj4NCj4+IFRoYW5rcywN Cj4+IEFkcmlhbg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+IENDQU1QQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlz dA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NjYW1wDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg== --=_alternative 000A81F548257949_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlNvbWUgYWRkaXRpb25hbCBpbmZv cm1hdGlvbjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ QWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlvbiBpbiBSRkMyMjEwDQpzZWN0aW9uIDI6PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtJbmZvcm1h dGlvbiBnZW5lcmF0ZWQgYXQgZWFjaA0Kc2VuZGVyIGRlc2NyaWJpbmcgdGhlIGRhdGEgdHJhZmZp YyBnZW5lcmF0ZWQgYnkgdGhhdCBzZW5kZXIgKHRoZSBTZW5kZXINClRTcGVjKS4gVGhpcyBpbmZv cm1hdGlvbiBpcyBjYXJyaWVkIGZyb20gdGhlIHNlbmRlciB0byBpbnRlcm1lZGlhdGUgbmV0d29y aw0KZWxlbWVudHMgYW5kIHRoZSByZWNlaXZlcihzKSBieSBSU1ZQLCBidXQgaXMgbmV2ZXIgbW9k aWZpZWQgYnkgaW50ZXJtZWRpYXRlDQplbGVtZW50cyB3aXRoaW4gdGhlIG5ldHdvcmsuIFRoaXMg aW5mb3JtYXRpb24gaXMgY2FycmllZCBpbiBSU1ZQIFNFTkRFUl9UU1BFQw0Kb2JqZWN0cyZxdW90 Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBp ZiB0aGUgTy1FLU8gc2NlbmFyaW8gc2hvdWxkIGJlDQpjb25zaWRlcmVkIGluIGZsZXhpYmxlIGdy aWQgc2NlbmFyaW8sIHRoZSAmcXVvdDttJnF1b3Q7IHZhbHVlIG1heSBiZSBjaGFuZ2VkLg0KTXkg cGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IGl0IE1VU1QgYmUgY29uc2lkZXJlZC48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkp1c3QgbXkgdHdvIGNlbnRz LCBJIGRvIG5vdCB0aGluayBpdA0KaXMgYSBnb29kIGlkZWEgdG8gcHV0ICZxdW90O20mcXVvdDsg aW4gdGhlIFNFTkRFUl9UU1BFQyBvYmplY3QsIHdoaWNoIGlzDQpub3QgYmFja3dhcmQgY29tcGF0 aWJsZTsgZXZlbiB0aGF0IGl0IG1heSBiZSBjYXJyaWVkIGV4Y2VwdCBpbiB0aGUgbGFiZWwNCm9i amVjdCwgaXQgc2hvdWxkIGJlIHRyZWF0ZWQgaW4gYW5vdGhlciB3YXkgb3IgbGlrZSBHaW92YW5u aSBzYWlkICxhbiBhZGRpdGlvbmFsDQpUTFYuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0LDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjxiPkdpb3Zhbm5pIE1hcnRpbmVsbGkgJmx0O2dpb21hcnRpQGNpc2Nv LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PreivP7IyzogJm5ic3A7Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDExLTExLTE1IDA3OjUwPC9mb250Pg0KPHRkIHdpZHRo PTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmFkcmlhbkBvbGRkb2cuY28u dWs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW0NDQU1QXSBGbGV4aS1ncmlkIGlzc3VlIDI8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJs ZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxi cj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnByb2JhYmx5IHdvcnRoIHRvIHJlbWluZCB0 aGF0IGN1cnJlbnQgd3NvbiBzaWduYWxpbmcNCmRyYWZ0PGJyPg0KKGRyYWZ0LWlldGYtY2NhbXAt d3Nvbi1zaWduYWxpbmcpIGRvZXMgbm90IGV4dGVuZCB0cmFmZmljIHBhcmFtZXRlcnMgYnV0PGJy Pg0KbmVlZHMgYW4gYWRkaXRpb25hbCB0bHYgKHN0aWxsIFRCRCkgdG8gY2Fycnkgd3NvbiBpbmZv cm1hdGlvbiByZXF1aXJlZDxicj4NCmZvciB4YyBwcm9ncmFtbWluZy48YnI+DQo8YnI+DQpXZWxs LCBzdGlsbCBhIGxpdmUgZG9jdW1lbnQgYW5kIGxvb2tzIHByb2JhYmx5IHRpbWUgdG8gcmV2aWV3 IHRoYXQ8YnI+DQpjaG9pY2UgYnV0IHRoaXMgaXMgdGhlIGN1cnJlbnQgc3RhdHVzLjxicj4NCjxi cj4NCkNoZWVyczxicj4NCkc8YnI+DQo8YnI+DQo8YnI+DQpPbiAxMS8xNC8xMSAzOjU0IEFNLCBB ZHJpYW4gRmFycmVsIHdyb3RlOjxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZndDsgSSd2 ZSBub3Qgc3BlbnQgYSBsb3Qgb2YgdGltZSBsb29raW5nIGF0IHRoZSB0cmFmZmljIHBhcmFtZXRl cnMsIGJ1dA0KeWVzLiBJdDxicj4NCiZndDsgc2VlbXMgdG8gbWUgdGhhdCBwYXJ0IG9mIHJlcXVl c3RpbmcgdGhlIExTUCBjb3VsZCBpbmNsdWRlIHNwZWNpZnlpbmcNCmEgbnVtYmVyIG9mPGJyPg0K Jmd0OyBwYXJhbWV0ZXJzIHJlbGF0ZWQgdG8gY2FwYWNpdHkgYW5kIGNvbnN0cnVjdGlvbi4gVGhh dCB3b3VsZCBtZWFuIHRoYXQNCiZxdW90O20mcXVvdDsgbWlnaHQ8YnI+DQomZ3Q7IHJlYXNvbmFi bHkgYmUgaW4gdGhlIHRyYWZmaWMgcGFyYW1ldGVycyAob3IgbWF5YmUgdGhlcmUgd291bGQgYmUg YQ0KY2hvaWNlIG9mPGJyPg0KJmd0OyB2YWx1ZXMgb2YgbSkgYW5kIHRoZSBmaW5hbCBjaG9zZW4g dmFsdWUgb2YgbSB3b3VsZCB0aGVuIGJlIHBsYWNlZA0KaW4gdGhlIGxhYmVsLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFlvdSBhcmUsIG9mIGNvdXJzZSwgcmlnaHQgdGhhdCBpc3N1ZXMgbGlrZSBpbnRl cmZhY2UgSUQgYW5kIGNvbXBvbmVudA0KaW50ZXJmYWNlPGJyPg0KJmd0OyBJRCBhcmUgYWxzbyBu ZWNlc3NhcnkgZm9yIFhDIHByb2dyYW1taW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IEE8YnI+DQom Z3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0 OyBGcm9tOiBaaGFuZ2ZhdGFpIFttYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tXTxicj4NCiZn dDsmZ3Q7IFNlbnQ6IDE0IE5vdmVtYmVyIDIwMTEgMDI6MjA8YnI+DQomZ3Q7Jmd0OyBUbzogYWRy aWFuQG9sZGRvZy5jby51azsgY2NhbXBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiC0 8Li0OiBbQ0NBTVBdIEZsZXhpLWdyaWQgaXNzdWUgMjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgSGkgQWRyaWFuLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRG8geW91IGFncmVlIHRo YXQgJnF1b3Q7bSZxdW90OyBzaG91bGQgYWxzbyBiZSBwdXQgaW50byBUcmFmZmljDQpQYXJhbWV0 ZXJzIG9iamVjdCwgd2hpY2g8YnI+DQomZ3Q7Jmd0OyBpbmRpY2F0ZXMgaG93IG11Y2ggcmVzb3Vy Y2Ugc2hvdWxkIGJlIHJlc2VydmVkIGJlZm9yZSB3ZSBkZWNpZGUNCndoZXRoZXJlIHdlPGJyPg0K Jmd0OyZndDsgc2hvdWxkIHB1dCAmcXVvdDttJnF1b3Q7IGluIHRoZSBMYWJlbD88YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IFRhbGtpbmcgYWJvdXQgdGhlIExhYmVsIGRlZmluaXRpb24gZnJv bSBSRkMzNDcxLCB0aGUgTGFiZWwgZGVmaW5lZA0KaW4gW2RyYWZ0LTxicj4NCiZndDsmZ3Q7IHpo YW5nXSBjb250YWlucyAmcXVvdDtlbm91Z2ggaW5mb3JtYXRpb24mcXVvdDsgdG8gYWxsb3cgdGhl IHJlY2VpdmluZw0Kbm9kZSB0byBwcm9ncmFtPGJyPg0KJmd0OyBpdHM8YnI+DQomZ3Q7Jmd0OyBj cm9zcyBjb25uZWN0LCBpZS4sIG5vdGhpbmcgaXMgbWlzc2VkIGZyb20gbXkgdW5kZXJzdGFuZGlu Zy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIGtub3cgdGhhdCB0aGUgcmVjaXZlaW5n IG5vZGUgY2Fubm90IHByb2dyYW0gaXRzIGNyb3NzIGNvbm5lY3QNCmNvcnJlY3RseSBieTxicj4N CiZndDsmZ3Q7IHVzaW5nIG9ubHkgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGUgJnF1 b3Q7TGFiZWwmcXVvdDssDQpiZWNhdXNlIGl0IGFsc28gbmVlZHMgdG88YnI+DQomZ3Q7IGdldDxi cj4NCiZndDsmZ3Q7IHNvbWUgb3RoZXIgaW5mb3JtYXRpb24gKGUuZy4sIFRFIGxpbmsgb3IgY29t cG9uZW50IGxpbmsgaW5mb3JtYXRpb24pDQpmcm9tPGJyPg0KJmd0OyBvdGhlcjxicj4NCiZndDsm Z3Q7IFJTVlAgb2JqZWN0cyBzdWNoIGFzIEVSTyBvciBSU1ZQLUhPUC48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgaGF2ZSBhbnkgbWlzdW5kZXJzdGFu ZGluZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZhdGFpPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBUaGFua3M8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7 ILeivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbY2NhbXAtYm91bmNlc0BpZXRmLm9yZ10g tPqx7Q0KQWRyaWFuIEZhcnJlbDxicj4NCiZndDsmZ3Q7IFthZHJpYW5Ab2xkZG9nLmNvLnVrXTxi cj4NCiZndDsmZ3Q7ILeiy83KsbzkOiAyMDExxOoxMdTCMTPI1SA5OjM0PGJyPg0KJmd0OyZndDsg tb06IGNjYW1wQGlldGYub3JnPGJyPg0KJmd0OyZndDsg1vfM4jogW0NDQU1QXSBGbGV4aS1ncmlk IGlzc3VlIDI8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgU2Vjb25kIGVtYWlsIG9uIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBs YWJlbCBmb3JtYXRzIGRlZmluZWQNCmluPGJyPg0KJmd0OyZndDsgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1mYXJya2luZ2VsLWNjYW1wLWZsZXhpZ3JpZC1sYW1iZGEtbGFi ZWw8YnI+DQomZ3Q7Jmd0OyBhbmQ8YnI+DQomZ3Q7IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtemhhbmctY2NhbXAtZmxleGlibGUtZ3JpZC1yc3ZwLXRlLWV4dDxicj4NCiZn dDsmZ3Q7IFRoaXMgaXNzdWUgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoZSBmaXJzdCBpc3N1 ZS4gVGhpcyBxdWVzdGlvbg0KaGFzIHR3bzxicj4NCiZndDsmZ3Q7IHN1Yi1wb2ludHM6PGJyPg0K Jmd0OyZndDsgYS4gd2hlcmUgZG8gd2UgY2FycnkgdGhlIGZsZXhpLWdyaWQgbSBwYXJhbWV0ZXI/ PGJyPg0KJmd0OyZndDsgYi4gd2hlcmUgZG8gd2UgY2FycnkgdHJhZmZpYyBwYXJhbWV0ZXJzIGZv ciBmbGV4aS1ncmlkPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgZHJhZnQtemhhbmcgaXMg YSBtb3JlIGNvbXByZWhlbnNpdmUgZG9jdW1lbnQgdGhhdCBkcmFmdC1mYXJya2luZ2VsDQpiZWNh dXNlIGl0PGJyPg0KJmd0OyZndDsgYWltcyB0byBjb3ZlciBhIG51bWJlciBvZiBzaWduaWZpY2Fu dCBzaWduYWxpbmcgcGFyYW1ldGVycyBmb3INClJTVlAtVEUuPGJyPg0KJmd0OyZndDsgZHJhZnQt ZmFycmtpbmdlbCBvbmx5IGF0dGVtcHRzIHRvIGRlZmluZSBhIGxhYmVsIHN0cnVjdHVyZS48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRodXMsIHRoZSBxdWVzdGlvbiB3ZSBuZWVkIHRvIHJl c29sdmUgaXMgbm90IHdoZXJlIHRvIGNhcnJ5IHRoZQ0KdHJhZmZpYzxicj4NCiZndDsmZ3Q7IHBh cmFtZXRlcnMgZm9yIGZsZXhpLWdyaWQsIGJ1dCB3aGF0IGNvbnN0aXR1dGVzIGEgbGFiZWwgaW4g ZmxleGktZ3JpZD88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1heWJlIHdlIHNob3VsZCBz dGFydCB0aGlzIHdpdGggdGhlIHF1ZXN0aW9uOiB3aGF0IGlzIGEgbGFiZWw/DQpSRkMgMzQ3MSBz YXlzOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO0EgZ2VuZXJhbGl6 ZWQgbGFiZWwgY29udGFpbnMgZW5vdWdoIGluZm9ybWF0aW9uIHRvDQphbGxvdyB0aGUgcmVjZWl2 aW5nPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO25vZGUgdG8gcHJvZ3JhbSBpdHMgY3Jvc3Mg Y29ubmVjdCwgcmVnYXJkbGVzcyBvZg0KdGhlIHR5cGUgb2YgdGhpczxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDtjcm9zcyBjb25uZWN0LCBzdWNoIHRoYXQgdGhlIGluZ3Jlc3Mgc2VnbWVudHMg b2YNCnRoZSBwYXRoIGFyZTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtwcm9wZXJseSBqb2lu ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTbywgd2hhdCBpbmZvcm1hdGlvbiBkbyB3 ZSBuZWVkIHRvIGNhcnJ5IGluIGEgbGFiZWwgdG8gc2F0aXNmeQ0KdGhhdD8gSSB0aGluazxicj4N CiZndDsgaXQ8YnI+DQomZ3Q7Jmd0OyBpcyBhIGZ1bGwgZGVzY3JpcHRpb24gb2YgdGhlIGNoYW5u ZWwsIGFuZCBBRkFJQ1MgZm9yIGZsZXhpLWdyaWQNCnRoaXMgaW5jbHVkZXM8YnI+DQomZ3Q7Jmd0 OyB0aGUgbSBwYXJhbWV0ZXIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MsPGJy Pg0KJmd0OyZndDsgQWRyaWFuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IENDQU1Q IG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0OyZndDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEND QU1QIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNDQU1QIG1haWxpbmcgbGlz dDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jY2FtcDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 000A81F548257949_=-- From lberger@labn.net Mon Nov 14 18:45:55 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172EE1F0D41 for ; Mon, 14 Nov 2011 18:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.971 X-Spam-Level: X-Spam-Status: No, score=-99.971 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C3c9O53PyZK for ; Mon, 14 Nov 2011 18:45:54 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 6961B1F0C69 for ; Mon, 14 Nov 2011 18:45:54 -0800 (PST) Received: (qmail 21204 invoked by uid 0); 15 Nov 2011 02:45:54 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 15 Nov 2011 02:45:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=lucByU0N6LI1KAaX8jJAmgjShvzlhmBj6P6P1OZRN2o=; b=J3IQcmgWxtMkdwfOo+fVTDt+xcZw8PP68u8Ek7byvSClVoQsNQJiW+SFeRXksC8PiZADC8s+pSDFUS7eYYyLMGPapLdPBSWMWG/8p+tO+WpCY2fSUO782MMWB7Cg9iH0; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RQ921-0002Lv-LJ; Mon, 14 Nov 2011 19:45:54 -0700 Message-ID: <4EC1D260.4090802@labn.net> Date: Tue, 15 Nov 2011 10:45:52 +0800 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E1718192704@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718192704@dfweml501-mbx> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" , "Brungard, Deborah A, ALABS" Subject: Re: [CCAMP] Update on General Information X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:45:55 -0000 Young, Thank you for the update. We should have time in today's meeting to discuss the open issues. Lou On 11/15/2011 9:44 AM, Leeyoung wrote: > Hi Lou, > > > > This is to give you the status of the following WG drafts that will not > be presented in Taipei meeting. > > > > - draft-ietf-ccamp-general-constraint-encode-05.txt (General > Network Element Constraint Encoding for GMPLS Controlled Networks). > > o Some clarifying texts (from Jonathan Harrison on label-range) will > be added in the revision as follows: > > “This constraint was motivated a type of tunable wave band add/drop > multi-plexer. The device can add/drop wavelengths within fixed range > from its tuning center. So we need three pieces of information: (a) the > total set of wavelengths that could possibly be reached (the labels in > the label set field), (b) the range of wavelengths that the device can > process at once (MaxLabelRange), (c) the current wavelengths (available > labels sub-TLV) in use (tells us constraints on tuning the devices up > or down to incorporate more wavelengths).” > > > > o Issues on the multiple ISCD capability is addressed by Cyril/Fatai > have been discussed in the corresponding OSPF extension; once the > solution is settled, encoding will be included if changes are needed. > > > > - draft-ietf-ccamp-rwa-info-13.txt (Routing and Wavelength > Assignment Information Model for Wavelength Switched Optical Networks) > > o There are some clarifying texts (from Cyril) that are needed to be > updated on the revision, which we will do shortly after the Taipei meeting. > > > > Thanks, > > Young > > > > > > > From zhang.fei3@zte.com.cn Tue Nov 15 04:30:25 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A761A11E80D2; Tue, 15 Nov 2011 04:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.999 X-Spam-Level: X-Spam-Status: No, score=-97.999 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJicLnUD-VmU; Tue, 15 Nov 2011 04:30:25 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E681B1F0C51; Tue, 15 Nov 2011 04:30:22 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901279682118; Tue, 15 Nov 2011 20:18:53 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 91000.1279682118; Tue, 15 Nov 2011 20:30:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAFCU0kd020424; Tue, 15 Nov 2011 20:30:00 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <20111114043335.8397.79549.idtracker@ietfa.amsl.com> To: "ccamp@ietf.org" , "mpls@ietf.org" MIME-Version: 1.0 X-KeepSent: 0BFF2B07:F4D9FF08-48257949:0042D5E6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 15 Nov 2011 20:30:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-15 20:30:03, Serialize complete at 2011-11-15 20:30:03 Content-Type: multipart/alternative; boundary="=_alternative 0044A9CE48257949_=" X-MAIL: mse02.zte.com.cn pAFCU0kd020424 Subject: Re: [CCAMP] New Version Notification for draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 12:30:25 -0000 This is a multipart message in MIME format. --=_alternative 0044A9CE48257949_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkFjY29yZGluZyB0byB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZ2xpc3Qs IHdlIGhhdmUgdXBkYXRlZCB0aGlzIGRyYWZ0IA0KYW5kIHByZXNlbnRlZCB0aGVzZSBjaGFuZ2Vz IG9uIHRoZSBDQ0FNUCBzZXNzaW9uDQoNCkJlbG93IGlzIHRoZSBkcmFmdCBsaW5rDQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bS0wMQ0KDQpXZSBkZWZpbmVkIGEgYml0IGluIHRoZSBMU1AgQXR0cmlidXRlIEZs YWdzIFRMViB0byBpbmRpY2F0ZSBjYXJyeWluZyB0aGUgDQpMU1AgaWRlbnRpZmVyLiAgVHdvIG5l dyBUTFZzIGFyZSBhbHNvIGRlZmluZWQgaW4gdGhlIExTUCBBVFRSSUJVVEVTIA0Kb2JqZWN0LCBv bmUgaXMgdGhlIENvbm5lY3Rpb24gVExWIHdoaWNoIGlzIHVzZWQgdG8gY2FycnkgdGhlIGxvY2Fs IHR1bm5lbCANCm51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlIChvbmx5IHVzZWQgZm9yIGNvcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQKTsgdGhlIA0Kb3RoZXIgaXMgdGhlIEdsb2JhbF9JRCBUTFYs IHVzZWQgdG8gY2FycnkgdGhlIGdsb2JhbCBJRCAoYXBwbHlpbmcgdG8gdGhlIA0KY29yb3V0ZWQg YW5kIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1BzKS4NCg0KWW91IGNhbiBhbHNvIGZpbmQg dGhlIHByZXNlbnRhdGlvbiBtYXRlcmlhbCBpbiB0aGUgZm9sbG93aW5nIGxpbmsNCg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL3dnL2NjYW1wL2FnZW5kYSwgdGhlIDExIG9uZS4NCg0KQW55IGNvbW1l bnRzIG9yIGNvbnRyaWJ1dGlvbnMgYXJlIHdlbGNvbWUNCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2Fy ZHMNCg0KRmVpDQoNCg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQoyMDExLTExLTE0IDEy OjMzDQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQqzrcvNDQp6aGFuZy5mZWkzQHp0 ZS5jb20uY24NCtb3zOINCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16aGFu Zy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMS50eHQNCg0KDQoNCg0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCANCmRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC10dW5uZWwtbnVtLTAxLnR4dCBoYXMgYmVlbiANCnN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgRmVpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6ICAgICAgICAgICAgICAgICBkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bQ0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJTVlAtVEUgRXh0ZW5zaW9ucyB0byBFeGNoYW5nZSBNUExTLVRQ IA0KTFNQIElkZW50aWZpZXJzDQpDcmVhdGlvbiBkYXRlOiAgICAgICAgICAgIDIwMTEtMTEtMTMN CldHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogOA0KDQpBYnN0cmFjdDoNCiAgIFRoZSBNUExTIFRyYW5zcG9ydCBQ cm9maWxlIChNUExTLVRQKSBpZGVudGlmaWVycyBkb2N1bWVudCBbUkZDNjM3MF0NCiAgIHNwZWNp ZmllcyBhIGluaXRpYWwgc2V0IG9mIGlkZW50aWZpZXJzLCBzdWNoIGFzIGxvY2FsIGFzc2lnbmVk IHR1bm5lbA0KICAgbnVtYmVyIGFuZCBHbG9iYWxfSUQsIHdoaWNoIGNhbiBiZSB1c2VkIHRvIGZv cm0gTWFpbnRlbmFuY2UgRW50aXR5DQogICBQb2ludCBJZGVudGlmaWVyIChNRVBfSUQpLiAgQXMg dG8gc29tZSBPcGVyYXRpb24sIEFkbWluaXN0cmF0aW9uIGFuZA0KICAgTWFpbnRlbmFuY2UgKE9B TSkgZnVuY3Rpb25zLCBzdWNoIGFzIENvbm5lY3Rpdml0eSBWZXJpZmljYXRpb24gKENWKQ0KICAg W0ktRC5pZXRmLW1wbHMtdHAtY2MtY3YtcmRpXSwgc291cmNlIE1FUF9JRCBtdXN0IGJlIGluc2Vy dGVkIGluIHRoZQ0KICAgT0FNIHBhY2tldHMsIHNvIHRoYXQgdGhlIHBlZXIgZW5kcG9pbnQgY2Fu IGNvbXBhcmUgdGhlIHJlY2VpdmVkIGFuZA0KICAgZXhwZWN0ZWQgTUVQX0lEcyB0byBqdWRnZSB3 aGV0aGVyIHRoZXJlIGlzIGEgbWlzbWF0Y2ggW1JGQzYzNzFdLA0KICAgd2hpY2ggbWVhbnMgdGhh dCB0aGUgdHdvIE1FUCBub2RlcyBuZWVkIHRvIHByZS1zdG9yZSBlYWNoIG90aGVyJiMzOTtzDQog ICBNRVBfSURzLg0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHNpZ25hbGluZyBleHRl bnNpb25zIHRvIGV4Y2hhbmdlIHRoZSBMYWJlbA0KICAgU3dpdGNoZWQgUGF0aCAoTFNQKSBpZGVu dGlmaWVycy4NCg0KICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K --=_alternative 0044A9CE48257949_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIHRoZSBkaXNj dXNzaW9uIG9uIHRoZSBtYWlsaW5nbGlzdCwNCndlIGhhdmUgdXBkYXRlZCB0aGlzIGRyYWZ0IGFu ZCBwcmVzZW50ZWQgdGhlc2UgY2hhbmdlcyBvbiB0aGUgQ0NBTVAgc2Vzc2lvbjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVsb3cgaXMgdGhlIGRyYWZ0 IGxpbms8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10 dW5uZWwtbnVtLTAxPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5XZSBkZWZpbmVkIGEgYml0IGluIHRoZSBMU1AgQXR0cmlidXRlDQpGbGFncyBUTFYgdG8g aW5kaWNhdGUgY2FycnlpbmcgdGhlIExTUCBpZGVudGlmZXIuICZuYnNwO1R3byBuZXcgVExWcyBh cmUNCmFsc28gZGVmaW5lZCBpbiB0aGUgTFNQIEFUVFJJQlVURVMgb2JqZWN0LCBvbmUgaXMgdGhl IENvbm5lY3Rpb24gVExWIHdoaWNoDQppcyB1c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5uZWwg bnVtYmVyIGFzc2lnbmVkIGF0IFo5IG5vZGUgKG9ubHkgdXNlZA0KZm9yIGNvcm91dGVkIGJpZGly ZWN0aW9uYWwgTFNQKTsgdGhlIG90aGVyIGlzIHRoZSBHbG9iYWxfSUQgVExWLCB1c2VkIHRvDQpj YXJyeSB0aGUgZ2xvYmFsIElEIChhcHBseWluZyB0byB0aGUgY29yb3V0ZWQgYW5kIGFzc29jaWF0 ZWQgYmlkaXJlY3Rpb25hbA0KTFNQcykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5Zb3UgY2FuIGFsc28gZmluZCB0aGUgcHJlc2VudGF0aW9uIG1hdGVy aWFsDQppbiB0aGUgZm9sbG93aW5nIGxpbms8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9jY2FtcC9hZ2VuZGEs DQp0aGUgMTEgb25lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+QW55IGNvbW1lbnRzIG9yIGNvbnRyaWJ1dGlvbnMgYXJlIHdlbGNvbWU8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBhbmQgYmVzdCBy ZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5G ZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTEtMTEtMTQgMTI6MzM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw O2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxLnR4dDwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC10dW5uZWwtbnVtLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBG ZWkgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCkZp bGVuYW1lOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDtkcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVs LW51bTxicj4NClJldmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDswMTxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KUlNWUC1URSBF eHRlbnNpb25zIHRvIEV4Y2hhbmdlIE1QTFMtVFAgTFNQIElkZW50aWZpZXJzPGJyPg0KQ3JlYXRp b24gZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7MjAxMS0xMS0xMzxicj4NCldHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KSW5kaXZpZHVhbCBT dWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiA4PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJy Pg0KICZuYnNwOyBUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkgaWRlbnRpZmll cnMgZG9jdW1lbnQgW1JGQzYzNzBdPGJyPg0KICZuYnNwOyBzcGVjaWZpZXMgYSBpbml0aWFsIHNl dCBvZiBpZGVudGlmaWVycywgc3VjaCBhcyBsb2NhbCBhc3NpZ25lZA0KdHVubmVsPGJyPg0KICZu YnNwOyBudW1iZXIgYW5kIEdsb2JhbF9JRCwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gZm9ybSBNYWlu dGVuYW5jZSBFbnRpdHk8YnI+DQogJm5ic3A7IFBvaW50IElkZW50aWZpZXIgKE1FUF9JRCkuICZu YnNwO0FzIHRvIHNvbWUgT3BlcmF0aW9uLCBBZG1pbmlzdHJhdGlvbg0KYW5kPGJyPg0KICZuYnNw OyBNYWludGVuYW5jZSAoT0FNKSBmdW5jdGlvbnMsIHN1Y2ggYXMgQ29ubmVjdGl2aXR5IFZlcmlm aWNhdGlvbg0KKENWKTxicj4NCiAmbmJzcDsgW0ktRC5pZXRmLW1wbHMtdHAtY2MtY3YtcmRpXSwg c291cmNlIE1FUF9JRCBtdXN0IGJlIGluc2VydGVkIGluDQp0aGU8YnI+DQogJm5ic3A7IE9BTSBw YWNrZXRzLCBzbyB0aGF0IHRoZSBwZWVyIGVuZHBvaW50IGNhbiBjb21wYXJlIHRoZSByZWNlaXZl ZA0KYW5kPGJyPg0KICZuYnNwOyBleHBlY3RlZCBNRVBfSURzIHRvIGp1ZGdlIHdoZXRoZXIgdGhl cmUgaXMgYSBtaXNtYXRjaCBbUkZDNjM3MV0sPGJyPg0KICZuYnNwOyB3aGljaCBtZWFucyB0aGF0 IHRoZSB0d28gTUVQIG5vZGVzIG5lZWQgdG8gcHJlLXN0b3JlIGVhY2ggb3RoZXImYW1wOyMzOTtz PGJyPg0KICZuYnNwOyBNRVBfSURzLjxicj4NCjxicj4NCiAmbmJzcDsgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIHRoZSBzaWduYWxpbmcgZXh0ZW5zaW9ucyB0byBleGNoYW5nZSB0aGUNCkxhYmVsPGJy Pg0KICZuYnNwOyBTd2l0Y2hlZCBQYXRoIChMU1ApIGlkZW50aWZpZXJzLjxicj4NCjxicj4NCiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj4NCg== --=_alternative 0044A9CE48257949_=-- From leeyoung@huawei.com Tue Nov 15 18:00:57 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D2C11E815B for ; Tue, 15 Nov 2011 18:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UM2FA5U+TKrk for ; Tue, 15 Nov 2011 18:00:53 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0042F11E817B for ; Tue, 15 Nov 2011 18:00:53 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ003VMDEIGC@usaga02-in.huawei.com> for ccamp@ietf.org; Tue, 15 Nov 2011 19:56:43 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUQ006CTDEIJF@usaga02-in.huawei.com> for ccamp@ietf.org; Tue, 15 Nov 2011 19:56:42 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 17:56:43 -0800 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 17:56:00 -0800 Date: Wed, 16 Nov 2011 01:56:33 +0000 From: Leeyoung In-reply-to: <24F96376-DCCF-49F3-A06B-48D1841427F4@ericsson.com> X-Originating-IP: [10.47.142.116] To: Acee Lindem Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718192CB8@dfweml501-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Thread-index: AQHMgdbfKpRl3bOBbUOtD09rA557ZpVq9kGggAG6D4CAADBlgIAAIZkAgAkeIYCAGi/wgIACj6sAgBwax+A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817E6BF@DFWEML501-MBX.china.huawei.com> <4E89C332.6020005@create-net.org> <7AEB3D6833318045B4AE71C2C87E8E171817E996@DFWEML501-MBX.china.huawei.com> <4E8B13C1.9030606@create-net.org> <2A9BEA32-6464-4FCE-BD30-3C8B2ECBB5C6@ericsson.com> <4E8B5888.70903@create-net.org> <0A1ED180-1DE9-4192-A90A-A9F492C02B52@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E17181832B9@DFWEML501-MBX.china.huawei.com> <24F96376-DCCF-49F3-A06B-48D1841427F4@ericsson.com> Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:00:58 -0000 Hi, After talking to Lou and based on Acee's previous email on the issue on how= resolve if the Optical Node Property TLV exceeds the IP MTU fragmentation = limit (1500 bytes), I have the following suggestion. If this is reasonable,= we will update the draft; otherwise, please voice out in the list.=20 - I suggest the rule specified (using multiple TE LSA's into which sub-TLV'= s are broken) in the current draft (Section 3) to be removed.=20 Current rule specifies in a rare case where the TE-LSA containing the Optic= al Node Property TLV (in which we specified 5 sub-TLVs) exceeds the IP MTU = fragmentation limit, then it will be broken into five multiple TE-LSA's in = which each TE-LSA contains a sub-TLV (See Section 3.1 for this in the curre= nt draft).=20 Instead of breaking up, what Acee suggested in the attached previous email = was: we can rely on IP fragmentation/reassembly capability in case the LSA = needs to be broken up.=20 The rational for this suggestion is four folds: - Optical Node Property TLV will not exceed the IP MTU limit in a normal no= de configuration. - Splitting information across multiple LSAs will result in some added comp= lexity. - IP fragmentation/reassembly can be used as a last resort, which is an acc= eptable method.=20 - This is consistent with the resolution made in the parallel draft (OPSF e= xtension for general constraint, Fatai's). Thanks. Young -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Friday, October 28, 2011 4:19 PM To: Leeyoung Cc: Andrea Zanardi; ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility= -ospf-06.txt Hi Young, On Oct 27, 2011, at 9:46 AM, Leeyoung wrote: > Hi Andrea and Acee, > > What I am proposing is this: > > In Section 2, we have the following statement: > > All sub-TLVs defined here may occur at most once in any given Optical > Node TLV. These restrictions need not apply to future sub-TLVs. > Unrecognized sub-TLVs are ignored. > > I will change the above statement to the following: > > All sub-TLVs defined here may occur at most once in any given Optical > Node TLV. "At most once" means that if there is sub-TLV related informa= tion, > it will be always included. These restrictions need not apply to future > sub-TLVs. Unrecognized sub-TLVs are ignored. > > This statement assures that all the related sub-TLVs are always included = in any given > Optical Node TLV leaving no room not to include such sub-TLVs in the Opti= cal > Node TLV. > > In Section 3.2, we have the following statement: > > In the highly unlikely event that a WSON sub-TLV by itself would > result in an LSA exceeding the MTU, all five WSON specific sub-TLVs > in this document provide mechanisms that allow them to be subdivided > into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. > > I will change the above statement to the following: > > In the highly unlikely event that a WSON sub-TLV by itself would > result in an LSA exceeding the MTU, all five WSON specific sub-TLVs > in this document provide mechanisms that allow them to be subdivided > into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. > > What is suggested as below is the only option allowed when dividing up > the current set of sub-TLVs into separate OSPF TE LSAs. This means > each sub-TLV will be packaged as the sole element in an OSPF TE LSA > with a unique LSA instance number. When such division is implemented, t= hen > the source node must flush the existing LSA (i.e., the original OSPF > TE LSA with all sub-TLV's packaged together as described in Section 2). > This will avoid duplicating the same information being advertised acros= s > multiple LSAs. s/LSA instance number/Link State ID/ So, it is not expected that a sub-TLV will exceed the IP MTU and, if it doe= s, we simply rely on IP fragmentation/reassembly as we do in situations whe= re the Router-LSAs and many interfaces in a single area. Correct? Thanks, Acee > > Please let me know if these texts will remove any ambiguity of the curren= t > Texts. > > Best Regards, > Young > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Monday, October 10, 2011 9:18 AM > To: Andrea Zanardi > Cc: Leeyoung; ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibili= ty-ospf-06.txt > > Hi Andrea, > On Oct 4, 2011, at 3:03 PM, Andrea Zanardi wrote: > >> Hi Acee, >> >> On 10/04/2011 07:03 PM, Acee Lindem wrote: >>> Hi Andrea, >>> >>> On Oct 4, 2011, at 10:10 AM, Andrea Zanardi wrote: >> .... >>> >>>> >>>> My point is in avoiding ambiguities: if the support for multiple LSA i= nstances for the >>>> same entity top TLV is requested, it should be explicitly stated as ma= ndatory >>>> (possibly providing explicit rules for the subdivision, as in Chap. 3 = of the draft). >>> >>> There are not multiple instances of the same LSA. Rather they are uniqu= e LSAs, >>> as identified by the (Type, Link State ID, Advertising Router) tuple. >>> In this case, they have different Link State IDs. >>> One thing that is confusing is that RFC 3630 refers to the portion of t= he Link State ID >>> providing uniqueness as "Instance". >>> Also note that draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt d= oesn't include any >>> additions to the Link TLV so I'm not sure why you are citing it in disc= ussions of the new top-level TLVs. >> >> I was replying to Young email providing the Link TLV and >> RFC 3630 as an example of the usage of multiple LSAs and of >> sending LSA updates with missing sub-TLVs; >> I was discussing about the correctness of the example, >> that's why I was citing the Link TLV. > > Ok. > >> >> The usage of the word "instance" is probably not correct. >> >> What I meant by "multiple LSA instances" was different LSAs (with distin= ct LS ID >> and both present in the TE DB at the same time) describing the same enti= ty >> (e.g. the same link by including the same Link Type / Link ID sub-TLVs) >> each one providing a subset of the information (e.g. a subset of the oth= er sub-TLVs). >> >> Considering the draft TLVs, this should be the case of Chap. 3.2.1 "Sub-= Division by Options", e.g.: >> two LSAs with a Resource Block Information sub-TLV with the same RB Set = Field >> and different sub-sets of optional sub-sub-TLVs. >> >> To avoid ambiguities, it should be clear that the options described in C= hap. 3 >> are the only options and that, even if they "can" be used when generatin= g >> the LSAs, they "must" all be supported when receiving and 'using' the LS= As. > > Agreed. Splitting information across multiple LSAs will result in some ad= ded complexity. > For TLVs or sub-TLVs that are required for a single WSON computation, the= WSON path computation must concatenate them when doing that computation. > Today, multiple OSPFv3 Router-LSAs may be originated and implementation M= UST use the concatenation when doing the OSPFv3 SPF computation. > > Thanks, > Acee > >> >> >> Regards, >> Andrea >> >>> Thanks, >>> Acee >>> >>> >>> >>>> >>>> >>>> Regards, >>>> Andrea >>>> >>>> On 10/03/2011 09:34 PM, Leeyoung wrote: >>>>> Hi Andrea, >>>>> >>>>> Thanks for your interest and input to this issue. >>>>> >>>>> My overall point was that the current GMPLS TE LSA (per RFC 3630) doe= s not specify detail implementations as to how to divide up the TE Link TLV= s into static vs. dynamic nor how to use multiple TE LSAs. The current WSON= document follows a similar document philosophy with the GMPLS predecessor. >>>>> >>>>> Regarding your point on how the TE DB works in regard to missing sub-= TLVs are deleted seems to me a particular implementation, which is most sim= plistic in nature. >>>>> >>>>> Best Regards, >>>>> Young >>>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behal= f Of Andrea Zanardi >>>>> Sent: Monday, October 03, 2011 9:14 AM >>>>> To: Leeyoung >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compati= bility-ospf-06.txt >>>>> >>>>> Hi Young, >>>>> >>>>> I was following the discussion and I have a doubt about >>>>> your example related to the TE Link TLV. >>>>> >>>>> It's true that the attributes sub-TLV are not mandatory per RFC 3630, >>>>> but I don't think that means that they can be not included in an LSA = update >>>>> if unchanged (implying that the previous value persists). >>>>> >>>>> As for my understanding of how OSPF-TE works, the managed TE DB entit= y is the LSA. >>>>> When an LSA update is processed, the previous version is deleted from= the TE DB >>>>> and it is replaced by the new one: link attributes related to missing= sub-TLV are >>>>> deleted, so they must be present even if unchanged. >>>>> >>>>> In theory, the set of link attributes could be statically divided >>>>> in two different LSAs instances (updated independently), >>>>> but I don't think current implementations handle this scenario >>>>> (also because, in my opinion, it's not suggested by RFC 3630 and >>>>> it gives no rule on how to divide them). >>>>> >>>>> But I ask to the mailing list if this is the correct interpretation. >>>>> >>>>> Regards, >>>>> Andrea >>>>> >>>>> On 09/30/2011 11:16 PM, Leeyoung wrote: >>>>>> Hi Pierre, >>>>>> >>>>>> I got your point. Let me ask you this question. In the current GMPLS= OSPF TE Link TLV are defined under Opaque TE LSA with the following attrib= utes: >>>>>> >>>>>> - TE Metric >>>>>> - max B/W >>>>>> - max reservable b/w >>>>>> - unreserved b/w >>>>>> - Admin Group >>>>>> - Link Protection Type >>>>>> - SRLG >>>>>> - ISCD >>>>>> - etc. >>>>>> >>>>>> And these are a mixture of static and dynamic information and yet th= ey are assembled together as one TE Link TLV. For instance the ISCD is quit= e similar to Resource Block Info in that it does not change often unless th= ere are new elements added in the node or configuration changes and yet it = is packaged together with other dynamic information. >>>>>> >>>>>> Why? >>>>>> >>>>>> There are many ways to keep static/unchanged information from being = flooded. Only the Link Type and Link ID which are mandatory in the TE Link = TLV per RFC3630. All other sub-TLV are optional and may occur at most once = (when there are enough changes from the previous period that deserve an upd= ate) and need not be included in the TE Link TLV when there is no need for = updating. >>>>>> >>>>>> I really don't see the need for a separate top-level TLV and/or a se= parate LSA for the Resource Block information. >>>>>> >>>>>> Regards, >>>>>> Young >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: PELOSO, PIERRE (PIERRE) [mailto:pierre.peloso@alcatel-lucent.c= om] >>>>>> Sent: Friday, September 30, 2011 9:39 AM >>>>>> To: Leeyoung; ccamp@ietf.org >>>>>> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compat= ibility-ospf-06.txt >>>>>> >>>>>> Hi Young, >>>>>> >>>>>> I understand the content of your answer, but I'm not satisfied with = it. >>>>>> My concern deals with providing a unique reading/interpretation of t= he OSPF-TE extensions. >>>>>> We would like to make sure that any implementation complying to the = drafts would provide the same LSAs when applied to the same network. >>>>>> With this perspective in mind, we wish to get drafts with sufficient= documentation to make sure the LSA design process to be depicted, by desig= n rules. >>>>>> >>>>>> Hence the content of your answer leaving me the "opportunity to do a= s I wish", is not pleasing me, I would rather have strict rules, and discus= sions with the WG on the design of those. >>>>>> That is why a first design rule, we could agree on is: to gather the= Resource Block Information TLVs inside a dedicated LSA, possibly with a de= dicated top-level TLV (which in my mind allows to enforce this design rule)= . >>>>>> >>>>>> Regards, >>>>>> >>>>>> - Pierre >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Leeyoung [mailto:leeyoung@huawei.com] >>>>>> Envoy=E9 : mercredi 28 septembre 2011 00:06 >>>>>> =C0 : PELOSO, PIERRE (PIERRE); ccamp@ietf.org >>>>>> Objet : RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compati= bility-ospf-06.txt >>>>>> >>>>>> Hi Pierre, >>>>>> >>>>>> Please see-inline for my reply to your first point. >>>>>> >>>>>> Regards, >>>>>> Young >>>>>> >>>>>> -----Original Message----- >>>>>> From: PELOSO, PIERRE (PIERRE) [mailto:pierre.peloso@alcatel-lucent.c= om] >>>>>> Sent: Tuesday, September 27, 2011 3:28 AM >>>>>> To: Leeyoung; ccamp@ietf.org >>>>>> Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compat= ibility-ospf-06.txt >>>>>> >>>>>> Hi Young, and CCAMPers, >>>>>> >>>>>> I was off the mailing lists for the last two weeks and being back I = notice a lot of exchanges, which I'm very glad of. >>>>>> I've also noticed many drafts have been updated. >>>>>> Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-= ospf-06, I wanted to comment section 3. >>>>>> Back in Quebec, I expressed my point of view (shared with Cyril, Jul= ien and Giovanni) that current drafts were lacking guidance regarding the w= ay to design LSAs that were to depict an WSON node with OEOs. >>>>>> This section 3 provides additional material to help designing the LS= A. >>>>>> I would like to know whether authors are willing to pursue further i= n this direction, which is to my mind a real corner stone, that would help = everyone agree on a solution. >>>>>> A first point could concern the Resource Block Information (reminder= : ::=3D ([] ): >>>>>> We all agree that these information are static, that we should = not replicate this TLV whatever the number not the layout of OEO boards of = a given type. >>>>>> Then, we could dedicate a specific independant flooding entity. This= would be defined once for all, and that would not leave room to different = interpretations. >>>>>> What about this first point? >>>>>> >>>>>> YOUNG>> If I understand you correctly, what you are saying is sin= ce the Resource Block Info sub-TLV is very static in nature, advertisement = of this sub-TLV should be treated differently from the rest of static-TLVs = (which may change over time). Is this what you are saying? >>>>>> >>>>>> If my interpretation of your comment is correct, >>>>>> >>>>>> - The current mechanism allows what you want: Please see the first p= aragraph in Section 3.2 >>>>>> "In the highly unlikely event that a WSON sub-TLV by itself would >>>>>> result in an LSA exceeding the MTU, all five WSON specific sub-TL= Vs >>>>>> in this document provide mechanisms that allow them to be subdivi= ded >>>>>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs." >>>>>> >>>>>> According to this clause, you can separate the Resource Block Info S= ub-TLV as the sole entry defined in the Optical Node property TLV in a sepa= rate TE LSA from the rest if you will. Nothing prevents this particular way= of packaging. (Isn't this what you meant "a specific independent flooding = entity"?) >>>>>> >>>>>> - Please let me know if this explanation satisfies you. Thanks --- Y= oung >>>>>> >>>>>> Regards, >>>>>> >>>>>> Pierre >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la pa= rt de Leeyoung Envoy=E9 : jeudi 15 septembre 2011 21:59 =C0 : ccamp@ietf.or= g Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibilit= y-ospf-06.txt >>>>>> >>>>>> Hi all, >>>>>> >>>>>> After 05 version publication, Acee provided a number of valuable com= ments and suggestions. This revision (06) reflects those changes. Please no= te the following updates: >>>>>> >>>>>> - Change the title of the draft to "GMPLS OSPF Enhancement..." from = "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF rath= er than the base OSPF. >>>>>> >>>>>> - Add specific OSPF procedures on how sub-TLVs are packaged per [RFC= 3630] and editorial change including avoiding "multiple instances of TE LSA= " to "multiple TE LSAs". >>>>>> >>>>>> Your comments are always appreciated. Thanks. >>>>>> >>>>>> Best Regards. >>>>>> Young >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Beha= lf Of internet-drafts@ietf.org >>>>>> Sent: Thursday, September 15, 2011 2:48 PM >>>>>> To: i-d-announce@ietf.org >>>>>> Cc: ccamp@ietf.org >>>>>> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibil= ity-ospf-06.txt >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. This draft is a work item of the Common Control and Measurement= Plane Working Group of the IETF. >>>>>> >>>>>> Title : GMPLS OSPF Enhancement for Signal and Network E= lement Compatibility for Wavelength Switched Optical Networks >>>>>> Author(s) : Young Lee >>>>>> Greg M. Bernstein >>>>>> Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf= -06.txt >>>>>> Pages : 14 >>>>>> Date : 2011-09-15 >>>>>> >>>>>> This document provides GMPLS OSPF routing enhancements to support >>>>>> signal compatibility constraints associated with WSON network >>>>>> elements. These routing enhancements are required in common optic= al >>>>>> or hybrid electro-optical networks where not all of the optical >>>>>> signals in the network are compatible with all network elements >>>>>> participating in the network. >>>>>> >>>>>> This compatibility constraint model is applicable to common optic= al >>>>>> or hybrid electro optical systems such as OEO switches, regenerat= ors, >>>>>> and wavelength converters since such systems can be limited to >>>>>> processing only certain types of WSON signals. >>>>>> >>>>>> >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-com= patibility-ospf-06.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> This Internet-Draft can be retrieved at: >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-comp= atibility-ospf-06.txt >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> -------------------------------------------------------- >>>> Andrea Zanardi >>>> CREATE-NET >>>> Engineering& Fast Prototyping (ENGINE) Area >>>> Senior Engineer >>>> Via alla Cascata 56/D - 38123 Povo Trento (Italy) >>>> e-mail: andrea.zanardi@create-net.org >>>> Tel: (+39) 0461 408400 - interno/extension 1407 >>>> Mobile: (+39) 340 0011837 >>>> Fax: (+39) 0461 421157 >>>> Skype: zanardi_andrea >>>> www.create-net.org >>>> -------------------------------------------------------- >>>> >>>> The information transmitted is intended only for the person or entity = to >>>> which it is addressed and may contain confidential and/or privileged >>>> material. Any review, retransmission, dissemination or other use of, o= r >>>> taking of any action in reliance upon, this information by persons or >>>> entities other than the intended recipient is prohibited according to = the >>>> Italian Law 196/2003 of the Legislature. If you received this in error= , >>>> please contact the sender and delete the material from any computer. >>>> >>>> Le informazioni contenute in questo messaggio di posta elettronica e n= ei >>>> file allegati sono da considerarsi strettamente riservate. Il loro uti= lizzo >>>> e' consentito esclusivamente al destinatario del messaggio, per le fin= alita' >>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio senz= a >>>> esserne il destinatario, Vi preghiamo cortesemente di darcene notizia = via >>>> e-mail e di procedere alla cancellazione del messaggio stesso dal Vost= ro >>>> sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, >>>> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita' >>>> diverse, costituisce comportamento contrario ai principi dettati dal D= . Lgs. >>>> 196/2003. >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >> >> >> -- >> -------------------------------------------------------- >> Andrea Zanardi >> CREATE-NET >> Engineering & Fast Prototyping (ENGINE) Area >> Senior Engineer >> Via alla Cascata 56/D - 38123 Povo Trento (Italy) >> e-mail: andrea.zanardi@create-net.org >> Tel: (+39) 0461 408400 - interno/extension 1407 >> Mobile: (+39) 340 0011837 >> Fax: (+39) 0461 421157 >> Skype: zanardi_andrea >> www.create-net.org >> -------------------------------------------------------- >> >> The information transmitted is intended only for the person or entity to >> which it is addressed and may contain confidential and/or privileged >> material. Any review, retransmission, dissemination or other use of, or >> taking of any action in reliance upon, this information by persons or >> entities other than the intended recipient is prohibited according to th= e >> Italian Law 196/2003 of the Legislature. If you received this in error, >> please contact the sender and delete the material from any computer. >> >> Le informazioni contenute in questo messaggio di posta elettronica e nei >> file allegati sono da considerarsi strettamente riservate. Il loro utili= zzo >> e' consentito esclusivamente al destinatario del messaggio, per le final= ita' >> indicate nel messaggio stesso. Qualora riceveste questo messaggio senza >> esserne il destinatario, Vi preghiamo cortesemente di darcene notizia vi= a >> e-mail e di procedere alla cancellazione del messaggio stesso dal Vostro >> sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, >> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita' >> diverse, costituisce comportamento contrario ai principi dettati dal D. = Lgs. >> 196/2003. >> > From Dirk.Schroetter@ecitele.com Tue Nov 15 21:03:32 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9A81F0CDC for ; Tue, 15 Nov 2011 21:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.651 X-Spam-Level: X-Spam-Status: No, score=-3.651 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZXxDuFpgLZW for ; Tue, 15 Nov 2011 21:03:28 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 7ADDA1F0CD7 for ; Tue, 15 Nov 2011 21:03:27 -0800 (PST) X-Env-Sender: Dirk.Schroetter@ecitele.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1321419804!3678115!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.1; banners=-,-,- Received: (qmail 16300 invoked from network); 16 Nov 2011 05:03:24 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-3.tower-216.messagelabs.com with SMTP; 16 Nov 2011 05:03:24 -0000 X-AuditID: 93eaf2e7-b7f496d000000e76-d4-4ec3520735bc Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 87.88.03702.70253CE4; Wed, 16 Nov 2011 08:02:48 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Wed, 16 Nov 2011 07:03:23 +0200 From: Dirk Schroetter To: Leeyoung Date: Wed, 16 Nov 2011 07:03:21 +0200 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Thread-Index: AcykHRCg6rl3d77mQwWc6wtyQKeYSg== Message-ID: <9C659714-D3B5-4EAC-B5B7-24823253FFBA@ecitele.com> References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817E6BF@DFWEML501-MBX.china.huawei.com> <4E89C332.6020005@create-net.org> <7AEB3D6833318045B4AE71C2C87E8E171817E996@DFWEML501-MBX.china.huawei.com> <4E8B13C1.9030606@create-net.org> <2A9BEA32-6464-4FCE-BD30-3C8B2ECBB5C6@ericsson.com> <4E8B5888.70903@create-net.org> <0A1ED180-1DE9-4192-A90A-A9F492C02B52@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E17181832B9@DFWEML501-MBX.china.huawei.com> <24F96376-DCCF-49F3-A06B-48D1841427F4@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E1718192CB8@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718192CB8@dfweml501-mbx> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0zTbBj1XbtRkJo6nHtZvNTXKybDLVMzL+PTzxBBIxD1j/7B2r1ujVs3 24rOmDgF0Ywfn8oXotMgJGiIKEtIvMSYKMN4v/0AXaIxEAUDYjTfpyIYxZYq4r/T55zzntP2 eSnC/L/JRgmigiWRCyBTBlnd999HO7W+rcjx5PM0d+WHTqP79akU6a6pzV9BFAx96jAVVNx8 ZyxoaBg0lBCbo2A5J4ohhVMw68Uy70ElklDG8RHECl4PciI2HOB4HMSi4kFcOIxFL8rLWK4O BZHFIh/yCqLPgwo3FNvd7kVL7E6UN2em07UsY6NfkFlsD3JCgA1iWeZ8mFUnWlXRi73stpDE Kn7MSluqCX/XiTum8K1vYPfpjoNpUVAxAGIgnYLMQtjeGTPqeDJ88jJhioEMysxcB7AqVUdo hJmpAfBiZ34MUJSJccHe+pXaeBKDYM2VUyYNE8w6eLaiZgSTzGxY93GY1HAWswme/Fpp0vWb 4cBgZ5qOc+HVyv0GDdNMHoyWtxn13EQa7Dl2Z6RcOpMPH96uHcFALTdw77xBD7PClp6Bn6UZ 2HDtMaFjC+x99d2o6y3wxaEE0DoTTA5MXF2gW2fAf6u60vTcifDuidekbs2GrY0p8giwxsck xH+742Pc8THuOkCeAxYhEFa2Bn0OZy7mBQUHcC4fCrYAfVneXAFDp2clAUMBlEkPnksWmY1c mRwJJkE2ZUAWmvy7rcg8YWvIG/Fzsr9U2hnAchJAikCT6GS9Kqe9XGQPlkK/KLf6kY8StvF8 SPvXSqnL4fjjAVnpbr5/nZnxqUu3HeMwln5Zp1AUgrR7lZo4UcI+vHubEFB+0wYqXUvOVJPn ahpaDnNBWfDp/D3goprby+8D6mCq8j4wk2JIxDYrvUqTMprUv1McPU27K/uGh4f7gFV98yza paky1fUcPa9PjTKoURdab2hR6hUZpWxRMH/qU8valbsOtVwMm4vH846e+Lz+2KMvdzf8tZcb 92Bo9Y4L/NKOSIQ6fGZmTnNd1dp+fvpgU2bZpdr3VYEDiws9B+yp7vI1he7EDQNraM/6lHO8 +02r2Bht4rqmH9tz2TJhyqWS7++Nz+bdLr1ejWKLz7xt+ie7aNPzxv0Ftt70+kJEyn7OOZ+Q ZO4Hmyj2QAYEAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:03:32 -0000 SGkgWW91bmcsDQoNCldoaWxlIG5vdCBvcHBvc2VkIHRvIHRoZSBpZGVhLCB3b3VsZG4ndCB0 aGF0IGdpdmUgcmFpc2UgdG8gc2VjdXJpdHkgY29uY2VybnMgZm9yIElQdjQgYW5kIGEgZGVw ZW5kZW5jeSBvbiB0aGUgb3BlcmF0aW9uIG9mIElDTVB2NiBmb3IgSVB2NiBuZXR3b3JrcyA/ IEkgYW0gbm90IGEgc2VjdXJpdHkgZXhwZXJ0LCBidXQgSSB0aGluayB3ZSBzaG91bGQgZ2V0 IGEgdmlldyBmcm9tIHRoZSBzZWN1cml0eSBleHBlcnRzIG9uIHRoYXQgbWF0dGVyLg0KDQpD aGVlcnMsDQoNCi9EaXJrDQoNClNlbnQgZnJvbSBhIG1vYmlsZSBkZXZpY2UuIFBsZWFzZSBl eGN1c2UgYW55IHNwZWxsaW5nIGVycm9ycy4NCg0KQW0gMTYuMTEuMjAxMSB1bSAxMDowMSBz Y2hyaWViICJMZWV5b3VuZyIgPGxlZXlvdW5nQGh1YXdlaS5jb20+Og0KDQo+IEhpLA0KPg0K PiBBZnRlciB0YWxraW5nIHRvIExvdSBhbmQgYmFzZWQgb24gQWNlZSdzIHByZXZpb3VzIGVt YWlsIG9uIHRoZSBpc3N1ZSBvbiBob3cgcmVzb2x2ZSBpZiB0aGUgT3B0aWNhbCBOb2RlIFBy b3BlcnR5IFRMViBleGNlZWRzIHRoZSBJUCBNVFUgZnJhZ21lbnRhdGlvbiBsaW1pdCAoMTUw MCBieXRlcyksIEkgaGF2ZSB0aGUgZm9sbG93aW5nIHN1Z2dlc3Rpb24uIElmIHRoaXMgaXMg cmVhc29uYWJsZSwgd2Ugd2lsbCB1cGRhdGUgdGhlIGRyYWZ0OyBvdGhlcndpc2UsIHBsZWFz ZSB2b2ljZSBvdXQgaW4gdGhlIGxpc3QuDQo+DQo+IC0gSSBzdWdnZXN0IHRoZSBydWxlIHNw ZWNpZmllZCAodXNpbmcgbXVsdGlwbGUgVEUgTFNBJ3MgaW50byB3aGljaCBzdWItVExWJ3Mg YXJlIGJyb2tlbikgaW4gdGhlIGN1cnJlbnQgZHJhZnQgKFNlY3Rpb24gMykgdG8gYmUgcmVt b3ZlZC4NCj4NCj4gQ3VycmVudCBydWxlIHNwZWNpZmllcyBpbiBhIHJhcmUgY2FzZSB3aGVy ZSB0aGUgVEUtTFNBIGNvbnRhaW5pbmcgdGhlIE9wdGljYWwgTm9kZSBQcm9wZXJ0eSBUTFYg KGluIHdoaWNoIHdlIHNwZWNpZmllZCA1IHN1Yi1UTFZzKSBleGNlZWRzIHRoZSBJUCBNVFUg ZnJhZ21lbnRhdGlvbiBsaW1pdCwgdGhlbiBpdCB3aWxsIGJlIGJyb2tlbiBpbnRvIGZpdmUg bXVsdGlwbGUgVEUtTFNBJ3MgaW4gd2hpY2ggZWFjaCBURS1MU0EgY29udGFpbnMgYSBzdWIt VExWIChTZWUgU2VjdGlvbiAzLjEgZm9yIHRoaXMgaW4gdGhlIGN1cnJlbnQgZHJhZnQpLg0K Pg0KPiBJbnN0ZWFkIG9mIGJyZWFraW5nIHVwLCB3aGF0IEFjZWUgc3VnZ2VzdGVkIGluIHRo ZSBhdHRhY2hlZCBwcmV2aW91cyBlbWFpbCB3YXM6IHdlIGNhbiByZWx5IG9uIElQIGZyYWdt ZW50YXRpb24vcmVhc3NlbWJseSBjYXBhYmlsaXR5IGluIGNhc2UgdGhlIExTQSBuZWVkcyB0 byBiZSBicm9rZW4gdXAuDQo+DQo+IFRoZSByYXRpb25hbCBmb3IgdGhpcyBzdWdnZXN0aW9u IGlzIGZvdXIgZm9sZHM6DQo+IC0gT3B0aWNhbCBOb2RlIFByb3BlcnR5IFRMViB3aWxsIG5v dCBleGNlZWQgdGhlIElQIE1UVSBsaW1pdCBpbiBhIG5vcm1hbCBub2RlIGNvbmZpZ3VyYXRp b24uDQo+IC0gU3BsaXR0aW5nIGluZm9ybWF0aW9uIGFjcm9zcyBtdWx0aXBsZSBMU0FzIHdp bGwgcmVzdWx0IGluIHNvbWUgYWRkZWQgY29tcGxleGl0eS4NCj4gLSBJUCBmcmFnbWVudGF0 aW9uL3JlYXNzZW1ibHkgY2FuIGJlIHVzZWQgYXMgYSBsYXN0IHJlc29ydCwgd2hpY2ggaXMg YW4gYWNjZXB0YWJsZSBtZXRob2QuDQo+IC0gVGhpcyBpcyBjb25zaXN0ZW50IHdpdGggdGhl IHJlc29sdXRpb24gbWFkZSBpbiB0aGUgcGFyYWxsZWwgZHJhZnQgKE9QU0YgZXh0ZW5zaW9u IGZvciBnZW5lcmFsIGNvbnN0cmFpbnQsIEZhdGFpJ3MpLg0KPg0KPiBUaGFua3MuDQo+DQo+ IFlvdW5nDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFjZWUg TGluZGVtIFttYWlsdG86YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBGcmlk YXksIE9jdG9iZXIgMjgsIDIwMTEgNDoxOSBQTQ0KPiBUbzogTGVleW91bmcNCj4gQ2M6IEFu ZHJlYSBaYW5hcmRpOyBjY2FtcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHkt b3NwZi0wNi50eHQNCj4NCj4gSGkgWW91bmcsDQo+DQo+IE9uIE9jdCAyNywgMjAxMSwgYXQg OTo0NiBBTSwgTGVleW91bmcgd3JvdGU6DQo+DQo+PiBIaSBBbmRyZWEgYW5kIEFjZWUsDQo+ Pg0KPj4gV2hhdCBJIGFtIHByb3Bvc2luZyBpcyB0aGlzOg0KPj4NCj4+IEluIFNlY3Rpb24g Miwgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIHN0YXRlbWVudDoNCj4+DQo+PiAgQWxsIHN1Yi1U TFZzIGRlZmluZWQgaGVyZSBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlIGluIGFueSBnaXZlbiBP cHRpY2FsDQo+PiAgTm9kZSBUTFYuIFRoZXNlIHJlc3RyaWN0aW9ucyBuZWVkIG5vdCBhcHBs eSB0byBmdXR1cmUgc3ViLVRMVnMuDQo+PiAgVW5yZWNvZ25pemVkIHN1Yi1UTFZzIGFyZSBp Z25vcmVkLg0KPj4NCj4+IEkgd2lsbCBjaGFuZ2UgdGhlIGFib3ZlIHN0YXRlbWVudCB0byB0 aGUgZm9sbG93aW5nOg0KPj4NCj4+ICBBbGwgc3ViLVRMVnMgZGVmaW5lZCBoZXJlIG1heSBv Y2N1ciBhdCBtb3N0IG9uY2UgaW4gYW55IGdpdmVuIE9wdGljYWwNCj4+ICBOb2RlIFRMVi4g IkF0IG1vc3Qgb25jZSIgbWVhbnMgdGhhdCBpZiB0aGVyZSBpcyBzdWItVExWIHJlbGF0ZWQg aW5mb3JtYXRpb24sDQo+PiAgaXQgd2lsbCBiZSBhbHdheXMgaW5jbHVkZWQuIFRoZXNlIHJl c3RyaWN0aW9ucyBuZWVkIG5vdCBhcHBseSB0byBmdXR1cmUNCj4+ICBzdWItVExWcy4gVW5y ZWNvZ25pemVkIHN1Yi1UTFZzIGFyZSBpZ25vcmVkLg0KPj4NCj4+IFRoaXMgc3RhdGVtZW50 IGFzc3VyZXMgdGhhdCBhbGwgdGhlIHJlbGF0ZWQgc3ViLVRMVnMgYXJlIGFsd2F5cyBpbmNs dWRlZCBpbiBhbnkgZ2l2ZW4NCj4+IE9wdGljYWwgTm9kZSBUTFYgbGVhdmluZyBubyByb29t IG5vdCB0byBpbmNsdWRlIHN1Y2ggc3ViLVRMVnMgaW4gdGhlIE9wdGljYWwNCj4+IE5vZGUg VExWLg0KPj4NCj4+IEluIFNlY3Rpb24gMy4yLCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgc3Rh dGVtZW50Og0KPj4NCj4+ICBJbiB0aGUgaGlnaGx5IHVubGlrZWx5IGV2ZW50IHRoYXQgYSBX U09OIHN1Yi1UTFYgYnkgaXRzZWxmIHdvdWxkDQo+PiAgcmVzdWx0IGluIGFuIExTQSBleGNl ZWRpbmcgdGhlIE1UVSwgYWxsIGZpdmUgV1NPTiBzcGVjaWZpYyBzdWItVExWcw0KPj4gIGlu IHRoaXMgZG9jdW1lbnQgcHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgYWxsb3cgdGhlbSB0byBi ZSBzdWJkaXZpZGVkDQo+PiAgaW50byBzbWFsbGVyIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNl bnQgaW4gc2VwYXJhdGUgT1NQRiBURSBMU0FzLg0KPj4NCj4+IEkgd2lsbCBjaGFuZ2UgdGhl IGFib3ZlIHN0YXRlbWVudCB0byB0aGUgZm9sbG93aW5nOg0KPj4NCj4+ICBJbiB0aGUgaGln aGx5IHVubGlrZWx5IGV2ZW50IHRoYXQgYSBXU09OIHN1Yi1UTFYgYnkgaXRzZWxmIHdvdWxk DQo+PiAgcmVzdWx0IGluIGFuIExTQSBleGNlZWRpbmcgdGhlIE1UVSwgYWxsIGZpdmUgV1NP TiBzcGVjaWZpYyBzdWItVExWcw0KPj4gIGluIHRoaXMgZG9jdW1lbnQgcHJvdmlkZSBtZWNo YW5pc21zIHRoYXQgYWxsb3cgdGhlbSB0byBiZSBzdWJkaXZpZGVkDQo+PiAgaW50byBzbWFs bGVyIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQgaW4gc2VwYXJhdGUgT1NQRiBURSBMU0Fz Lg0KPj4NCj4+ICBXaGF0IGlzIHN1Z2dlc3RlZCBhcyBiZWxvdyBpcyB0aGUgb25seSBvcHRp b24gYWxsb3dlZCB3aGVuIGRpdmlkaW5nIHVwDQo+PiAgdGhlIGN1cnJlbnQgc2V0IG9mIHN1 Yi1UTFZzIGludG8gc2VwYXJhdGUgT1NQRiBURSBMU0FzLiBUaGlzIG1lYW5zDQo+PiAgZWFj aCBzdWItVExWIHdpbGwgYmUgcGFja2FnZWQgYXMgdGhlIHNvbGUgZWxlbWVudCBpbiBhbiBP U1BGIFRFIExTQQ0KPj4gIHdpdGggYSB1bmlxdWUgTFNBIGluc3RhbmNlIG51bWJlci4gV2hl biBzdWNoIGRpdmlzaW9uIGlzIGltcGxlbWVudGVkLCB0aGVuDQo+PiAgdGhlIHNvdXJjZSBu b2RlIG11c3QgZmx1c2ggdGhlIGV4aXN0aW5nIExTQSAoaS5lLiwgdGhlIG9yaWdpbmFsIE9T UEYNCj4+ICBURSBMU0Egd2l0aCBhbGwgc3ViLVRMVidzIHBhY2thZ2VkIHRvZ2V0aGVyIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIpLg0KPj4gIFRoaXMgd2lsbCBhdm9pZCBkdXBsaWNh dGluZyB0aGUgc2FtZSBpbmZvcm1hdGlvbiBiZWluZyBhZHZlcnRpc2VkIGFjcm9zcw0KPj4g IG11bHRpcGxlIExTQXMuDQo+DQo+IHMvTFNBIGluc3RhbmNlIG51bWJlci9MaW5rIFN0YXRl IElELw0KPg0KPiBTbywgaXQgaXMgbm90IGV4cGVjdGVkIHRoYXQgYSBzdWItVExWIHdpbGwg ZXhjZWVkIHRoZSBJUCBNVFUgYW5kLCBpZiBpdCBkb2VzLCB3ZSBzaW1wbHkgcmVseSBvbiBJ UCBmcmFnbWVudGF0aW9uL3JlYXNzZW1ibHkgYXMgd2UgZG8gaW4gc2l0dWF0aW9ucyB3aGVy ZSB0aGUgUm91dGVyLUxTQXMgYW5kIG1hbnkgaW50ZXJmYWNlcyBpbiBhIHNpbmdsZSBhcmVh LiBDb3JyZWN0Pw0KPg0KPiBUaGFua3MsDQo+IEFjZWUNCj4NCj4+DQo+PiBQbGVhc2UgbGV0 IG1lIGtub3cgaWYgdGhlc2UgdGV4dHMgd2lsbCByZW1vdmUgYW55IGFtYmlndWl0eSBvZiB0 aGUgY3VycmVudA0KPj4gVGV4dHMuDQo+Pg0KPj4gQmVzdCBSZWdhcmRzLA0KPj4gWW91bmcN Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBBY2VlIExpbmRlbSBb bWFpbHRvOmFjZWUubGluZGVtQGVyaWNzc29uLmNvbV0NCj4+IFNlbnQ6IE1vbmRheSwgT2N0 b2JlciAxMCwgMjAxMSA5OjE4IEFNDQo+PiBUbzogQW5kcmVhIFphbmFyZGkNCj4+IENjOiBM ZWV5b3VuZzsgY2NhbXBAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3Bm LTA2LnR4dA0KPj4NCj4+IEhpIEFuZHJlYSwNCj4+IE9uIE9jdCA0LCAyMDExLCBhdCAzOjAz IFBNLCBBbmRyZWEgWmFuYXJkaSB3cm90ZToNCj4+DQo+Pj4gSGkgQWNlZSwNCj4+Pg0KPj4+ IE9uIDEwLzA0LzIwMTEgMDc6MDMgUE0sIEFjZWUgTGluZGVtIHdyb3RlOg0KPj4+PiBIaSBB bmRyZWEsDQo+Pj4+DQo+Pj4+IE9uIE9jdCA0LCAyMDExLCBhdCAxMDoxMCBBTSwgQW5kcmVh IFphbmFyZGkgd3JvdGU6DQo+Pj4gLi4uLg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IE15IHBvaW50 IGlzIGluIGF2b2lkaW5nIGFtYmlndWl0aWVzOiBpZiB0aGUgc3VwcG9ydCBmb3IgbXVsdGlw bGUgTFNBIGluc3RhbmNlcyBmb3IgdGhlDQo+Pj4+PiBzYW1lIGVudGl0eSB0b3AgVExWIGlz IHJlcXVlc3RlZCwgaXQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgc3RhdGVkIGFzIG1hbmRhdG9y eQ0KPj4+Pj4gKHBvc3NpYmx5IHByb3ZpZGluZyBleHBsaWNpdCBydWxlcyBmb3IgdGhlIHN1 YmRpdmlzaW9uLCBhcyBpbiBDaGFwLiAzIG9mIHRoZSBkcmFmdCkuDQo+Pj4+DQo+Pj4+IFRo ZXJlIGFyZSBub3QgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIExTQS4gUmF0aGVy IHRoZXkgYXJlIHVuaXF1ZSBMU0FzLA0KPj4+PiBhcyBpZGVudGlmaWVkIGJ5IHRoZSAoVHlw ZSwgTGluayBTdGF0ZSBJRCwgQWR2ZXJ0aXNpbmcgUm91dGVyKSB0dXBsZS4NCj4+Pj4gSW4g dGhpcyBjYXNlLCB0aGV5IGhhdmUgZGlmZmVyZW50IExpbmsgU3RhdGUgSURzLg0KPj4+PiBP bmUgdGhpbmcgdGhhdCBpcyBjb25mdXNpbmcgaXMgdGhhdCBSRkMgMzYzMCByZWZlcnMgdG8g dGhlIHBvcnRpb24gb2YgdGhlIExpbmsgU3RhdGUgSUQNCj4+Pj4gcHJvdmlkaW5nIHVuaXF1 ZW5lc3MgYXMgIkluc3RhbmNlIi4NCj4+Pj4gQWxzbyBub3RlIHRoYXQgZHJhZnQtaWV0Zi1j Y2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0IGRvZXNuJ3QgaW5j bHVkZSBhbnkNCj4+Pj4gYWRkaXRpb25zIHRvIHRoZSBMaW5rIFRMViBzbyBJJ20gbm90IHN1 cmUgd2h5IHlvdSBhcmUgY2l0aW5nIGl0IGluIGRpc2N1c3Npb25zIG9mIHRoZSBuZXcgdG9w LWxldmVsIFRMVnMuDQo+Pj4NCj4+PiBJIHdhcyByZXBseWluZyB0byBZb3VuZyBlbWFpbCBw cm92aWRpbmcgdGhlIExpbmsgVExWIGFuZA0KPj4+IFJGQyAzNjMwIGFzIGFuIGV4YW1wbGUg b2YgdGhlIHVzYWdlIG9mIG11bHRpcGxlIExTQXMgYW5kIG9mDQo+Pj4gc2VuZGluZyBMU0Eg dXBkYXRlcyB3aXRoIG1pc3Npbmcgc3ViLVRMVnM7DQo+Pj4gSSB3YXMgZGlzY3Vzc2luZyBh Ym91dCB0aGUgY29ycmVjdG5lc3Mgb2YgdGhlIGV4YW1wbGUsDQo+Pj4gdGhhdCdzIHdoeSBJ IHdhcyBjaXRpbmcgdGhlIExpbmsgVExWLg0KPj4NCj4+IE9rLg0KPj4NCj4+Pg0KPj4+IFRo ZSB1c2FnZSBvZiB0aGUgd29yZCAiaW5zdGFuY2UiIGlzIHByb2JhYmx5IG5vdCBjb3JyZWN0 Lg0KPj4+DQo+Pj4gV2hhdCBJIG1lYW50IGJ5ICJtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIiB3 YXMgZGlmZmVyZW50IExTQXMgKHdpdGggZGlzdGluY3QgTFMgSUQNCj4+PiBhbmQgYm90aCBw cmVzZW50IGluIHRoZSBURSBEQiBhdCB0aGUgc2FtZSB0aW1lKSBkZXNjcmliaW5nIHRoZSBz YW1lIGVudGl0eQ0KPj4+IChlLmcuIHRoZSBzYW1lIGxpbmsgYnkgaW5jbHVkaW5nIHRoZSBz YW1lIExpbmsgVHlwZSAvIExpbmsgSUQgc3ViLVRMVnMpDQo+Pj4gZWFjaCBvbmUgcHJvdmlk aW5nIGEgc3Vic2V0IG9mIHRoZSBpbmZvcm1hdGlvbiAoZS5nLiBhIHN1YnNldCBvZiB0aGUg b3RoZXIgc3ViLVRMVnMpLg0KPj4+DQo+Pj4gQ29uc2lkZXJpbmcgdGhlIGRyYWZ0IFRMVnMs IHRoaXMgc2hvdWxkIGJlIHRoZSBjYXNlIG9mIENoYXAuIDMuMi4xICJTdWItRGl2aXNpb24g YnkgT3B0aW9ucyIsIGUuZy46DQo+Pj4gdHdvIExTQXMgd2l0aCBhIFJlc291cmNlIEJsb2Nr IEluZm9ybWF0aW9uIHN1Yi1UTFYgd2l0aCB0aGUgc2FtZSBSQiBTZXQgRmllbGQNCj4+PiBh bmQgZGlmZmVyZW50IHN1Yi1zZXRzIG9mIG9wdGlvbmFsIHN1Yi1zdWItVExWcy4NCj4+Pg0K Pj4+IFRvIGF2b2lkIGFtYmlndWl0aWVzLCBpdCBzaG91bGQgYmUgY2xlYXIgdGhhdCB0aGUg b3B0aW9ucyBkZXNjcmliZWQgaW4gQ2hhcC4gMw0KPj4+IGFyZSB0aGUgb25seSBvcHRpb25z IGFuZCB0aGF0LCBldmVuIGlmIHRoZXkgImNhbiIgYmUgdXNlZCB3aGVuIGdlbmVyYXRpbmcN Cj4+PiB0aGUgTFNBcywgdGhleSAibXVzdCIgYWxsIGJlIHN1cHBvcnRlZCB3aGVuIHJlY2Vp dmluZyBhbmQgJ3VzaW5nJyB0aGUgTFNBcy4NCj4+DQo+PiBBZ3JlZWQuIFNwbGl0dGluZyBp bmZvcm1hdGlvbiBhY3Jvc3MgbXVsdGlwbGUgTFNBcyB3aWxsIHJlc3VsdCBpbiBzb21lIGFk ZGVkIGNvbXBsZXhpdHkuDQo+PiBGb3IgVExWcyBvciBzdWItVExWcyB0aGF0IGFyZSByZXF1 aXJlZCBmb3IgYSBzaW5nbGUgV1NPTiBjb21wdXRhdGlvbiwgdGhlIFdTT04gcGF0aCBjb21w dXRhdGlvbiBtdXN0IGNvbmNhdGVuYXRlIHRoZW0gd2hlbiBkb2luZyB0aGF0IGNvbXB1dGF0 aW9uLg0KPj4gVG9kYXksIG11bHRpcGxlIE9TUEZ2MyBSb3V0ZXItTFNBcyBtYXkgYmUgb3Jp Z2luYXRlZCBhbmQgaW1wbGVtZW50YXRpb24gTVVTVCB1c2UgdGhlIGNvbmNhdGVuYXRpb24g d2hlbiBkb2luZyB0aGUgT1NQRnYzIFNQRiBjb21wdXRhdGlvbi4NCj4+DQo+PiBUaGFua3Ms DQo+PiBBY2VlDQo+Pg0KPj4+DQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+IEFuZHJlYQ0KPj4+ DQo+Pj4+IFRoYW5rcywNCj4+Pj4gQWNlZQ0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4gQW5kcmVhDQo+Pj4+Pg0KPj4+Pj4gT24gMTAv MDMvMjAxMSAwOTozNCBQTSwgTGVleW91bmcgd3JvdGU6DQo+Pj4+Pj4gSGkgQW5kcmVhLA0K Pj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIGludGVyZXN0IGFuZCBpbnB1dCB0byB0 aGlzIGlzc3VlLg0KPj4+Pj4+DQo+Pj4+Pj4gTXkgb3ZlcmFsbCBwb2ludCB3YXMgdGhhdCB0 aGUgY3VycmVudCBHTVBMUyBURSBMU0EgKHBlciBSRkMgMzYzMCkgZG9lcyBub3Qgc3BlY2lm eSBkZXRhaWwgaW1wbGVtZW50YXRpb25zIGFzIHRvIGhvdyB0byBkaXZpZGUgdXAgdGhlIFRF IExpbmsgVExWcyBpbnRvIHN0YXRpYyB2cy4gZHluYW1pYyBub3IgaG93IHRvIHVzZSBtdWx0 aXBsZSBURSBMU0FzLiBUaGUgY3VycmVudCBXU09OIGRvY3VtZW50IGZvbGxvd3MgYSBzaW1p bGFyIGRvY3VtZW50IHBoaWxvc29waHkgd2l0aCB0aGUgR01QTFMgcHJlZGVjZXNzb3IuDQo+ Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRpbmcgeW91ciBwb2ludCBvbiBob3cgdGhlIFRFIERCIHdv cmtzIGluIHJlZ2FyZCB0byBtaXNzaW5nIHN1Yi1UTFZzIGFyZSBkZWxldGVkIHNlZW1zIHRv IG1lIGEgcGFydGljdWxhciBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggaXMgbW9zdCBzaW1wbGlz dGljIGluIG5hdHVyZS4NCj4+Pj4+Pg0KPj4+Pj4+IEJlc3QgUmVnYXJkcywNCj4+Pj4+PiBZ b3VuZw0KPj4+Pj4+DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+ PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJlYSBaYW5hcmRpDQo+Pj4+Pj4gU2VudDogTW9u ZGF5LCBPY3RvYmVyIDAzLCAyMDExIDk6MTQgQU0NCj4+Pj4+PiBUbzogTGVleW91bmcNCj4+ Pj4+PiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW0NDQU1QXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHkt b3NwZi0wNi50eHQNCj4+Pj4+Pg0KPj4+Pj4+IEhpIFlvdW5nLA0KPj4+Pj4+DQo+Pj4+Pj4g SSB3YXMgZm9sbG93aW5nIHRoZSBkaXNjdXNzaW9uIGFuZCBJIGhhdmUgYSBkb3VidCBhYm91 dA0KPj4+Pj4+IHlvdXIgZXhhbXBsZSByZWxhdGVkIHRvIHRoZSBURSBMaW5rIFRMVi4NCj4+ Pj4+Pg0KPj4+Pj4+IEl0J3MgdHJ1ZSB0aGF0IHRoZSBhdHRyaWJ1dGVzIHN1Yi1UTFYgYXJl IG5vdCBtYW5kYXRvcnkgcGVyIFJGQyAzNjMwLA0KPj4+Pj4+IGJ1dCBJIGRvbid0IHRoaW5r IHRoYXQgbWVhbnMgdGhhdCB0aGV5IGNhbiBiZSBub3QgaW5jbHVkZWQgaW4gYW4gTFNBIHVw ZGF0ZQ0KPj4+Pj4+IGlmIHVuY2hhbmdlZCAoaW1wbHlpbmcgdGhhdCB0aGUgcHJldmlvdXMg dmFsdWUgcGVyc2lzdHMpLg0KPj4+Pj4+DQo+Pj4+Pj4gQXMgZm9yIG15IHVuZGVyc3RhbmRp bmcgb2YgaG93IE9TUEYtVEUgd29ya3MsIHRoZSBtYW5hZ2VkIFRFIERCIGVudGl0eSBpcyB0 aGUgTFNBLg0KPj4+Pj4+IFdoZW4gYW4gTFNBIHVwZGF0ZSBpcyBwcm9jZXNzZWQsIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGRlbGV0ZWQgZnJvbSB0aGUgVEUgREINCj4+Pj4+PiBhbmQg aXQgaXMgcmVwbGFjZWQgYnkgdGhlIG5ldyBvbmU6IGxpbmsgYXR0cmlidXRlcyByZWxhdGVk IHRvIG1pc3Npbmcgc3ViLVRMViBhcmUNCj4+Pj4+PiBkZWxldGVkLCBzbyB0aGV5IG11c3Qg YmUgcHJlc2VudCBldmVuIGlmIHVuY2hhbmdlZC4NCj4+Pj4+Pg0KPj4+Pj4+IEluIHRoZW9y eSwgdGhlIHNldCBvZiBsaW5rIGF0dHJpYnV0ZXMgY291bGQgYmUgc3RhdGljYWxseSBkaXZp ZGVkDQo+Pj4+Pj4gaW4gdHdvIGRpZmZlcmVudCBMU0FzIGluc3RhbmNlcyAodXBkYXRlZCBp bmRlcGVuZGVudGx5KSwNCj4+Pj4+PiBidXQgSSBkb24ndCB0aGluayBjdXJyZW50IGltcGxl bWVudGF0aW9ucyBoYW5kbGUgdGhpcyBzY2VuYXJpbw0KPj4+Pj4+IChhbHNvIGJlY2F1c2Us IGluIG15IG9waW5pb24sIGl0J3Mgbm90IHN1Z2dlc3RlZCBieSBSRkMgMzYzMCBhbmQNCj4+ Pj4+PiBpdCBnaXZlcyBubyBydWxlIG9uIGhvdyB0byBkaXZpZGUgdGhlbSkuDQo+Pj4+Pj4N Cj4+Pj4+PiBCdXQgSSBhc2sgdG8gdGhlIG1haWxpbmcgbGlzdCBpZiB0aGlzIGlzIHRoZSBj b3JyZWN0IGludGVycHJldGF0aW9uLg0KPj4+Pj4+DQo+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+ PiBBbmRyZWENCj4+Pj4+Pg0KPj4+Pj4+IE9uIDA5LzMwLzIwMTEgMTE6MTYgUE0sIExlZXlv dW5nIHdyb3RlOg0KPj4+Pj4+PiBIaSBQaWVycmUsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgZ290 IHlvdXIgcG9pbnQuIExldCBtZSBhc2sgeW91IHRoaXMgcXVlc3Rpb24uIEluIHRoZSBjdXJy ZW50IEdNUExTIE9TUEYgVEUgTGluayBUTFYgYXJlIGRlZmluZWQgdW5kZXIgT3BhcXVlIFRF IExTQSB3aXRoIHRoZSBmb2xsb3dpbmcgYXR0cmlidXRlczoNCj4+Pj4+Pj4NCj4+Pj4+Pj4g LSBURSBNZXRyaWMNCj4+Pj4+Pj4gLSBtYXggQi9XDQo+Pj4+Pj4+IC0gbWF4IHJlc2VydmFi bGUgYi93DQo+Pj4+Pj4+IC0gdW5yZXNlcnZlZCBiL3cNCj4+Pj4+Pj4gLSBBZG1pbiBHcm91 cA0KPj4+Pj4+PiAtIExpbmsgUHJvdGVjdGlvbiBUeXBlDQo+Pj4+Pj4+IC0gU1JMRw0KPj4+ Pj4+PiAtIElTQ0QNCj4+Pj4+Pj4gLSBldGMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEFuZCB0aGVz ZSBhcmUgYSBtaXh0dXJlIG9mIHN0YXRpYyBhbmQgZHluYW1pYyBpbmZvcm1hdGlvbiBhbmQg eWV0IHRoZXkgYXJlIGFzc2VtYmxlZCB0b2dldGhlciBhcyBvbmUgVEUgTGluayBUTFYuIEZv ciBpbnN0YW5jZSB0aGUgSVNDRCBpcyBxdWl0ZSBzaW1pbGFyIHRvIFJlc291cmNlIEJsb2Nr IEluZm8gaW4gdGhhdCBpdCBkb2VzIG5vdCBjaGFuZ2Ugb2Z0ZW4gdW5sZXNzIHRoZXJlIGFy ZSBuZXcgZWxlbWVudHMgYWRkZWQgaW4gdGhlIG5vZGUgb3IgY29uZmlndXJhdGlvbiBjaGFu Z2VzIGFuZCB5ZXQgaXQgaXMgcGFja2FnZWQgdG9nZXRoZXIgd2l0aCBvdGhlciBkeW5hbWlj IGluZm9ybWF0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXaHk/DQo+Pj4+Pj4+DQo+Pj4+Pj4+ IFRoZXJlIGFyZSBtYW55IHdheXMgdG8ga2VlcCBzdGF0aWMvdW5jaGFuZ2VkIGluZm9ybWF0 aW9uIGZyb20gYmVpbmcgZmxvb2RlZC4gT25seSB0aGUgTGluayBUeXBlIGFuZCBMaW5rIElE IHdoaWNoIGFyZSBtYW5kYXRvcnkgaW4gdGhlIFRFIExpbmsgVExWIHBlciBSRkMzNjMwLiBB bGwgb3RoZXIgc3ViLVRMViBhcmUgb3B0aW9uYWwgYW5kIG1heSBvY2N1ciBhdCBtb3N0IG9u Y2UgKHdoZW4gdGhlcmUgYXJlIGVub3VnaCBjaGFuZ2VzIGZyb20gdGhlIHByZXZpb3VzIHBl cmlvZCB0aGF0IGRlc2VydmUgYW4gdXBkYXRlKSBhbmQgbmVlZCBub3QgYmUgaW5jbHVkZWQg aW4gdGhlIFRFIExpbmsgVExWIHdoZW4gdGhlcmUgaXMgbm8gbmVlZCBmb3IgdXBkYXRpbmcu DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgcmVhbGx5IGRvbid0IHNlZSB0aGUgbmVlZCBmb3IgYSBz ZXBhcmF0ZSB0b3AtbGV2ZWwgVExWIGFuZC9vciBhIHNlcGFyYXRlIExTQSBmb3IgdGhlIFJl c291cmNlIEJsb2NrIGluZm9ybWF0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSZWdhcmRzLA0K Pj4+Pj4+PiBZb3VuZw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBQRUxPU08sIFBJRVJSRSAo UElFUlJFKSBbbWFpbHRvOnBpZXJyZS5wZWxvc29AYWxjYXRlbC1sdWNlbnQuY29tXQ0KPj4+ Pj4+PiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAzMCwgMjAxMSA5OjM5IEFNDQo+Pj4+Pj4+ IFRvOiBMZWV5b3VuZzsgY2NhbXBAaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtD Q0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRp YmlsaXR5LW9zcGYtMDYudHh0DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhpIFlvdW5nLA0KPj4+Pj4+ Pg0KPj4+Pj4+PiBJIHVuZGVyc3RhbmQgdGhlIGNvbnRlbnQgb2YgeW91ciBhbnN3ZXIsIGJ1 dCBJJ20gbm90IHNhdGlzZmllZCB3aXRoIGl0Lg0KPj4+Pj4+PiBNeSBjb25jZXJuIGRlYWxz IHdpdGggcHJvdmlkaW5nIGEgdW5pcXVlIHJlYWRpbmcvaW50ZXJwcmV0YXRpb24gb2YgdGhl IE9TUEYtVEUgZXh0ZW5zaW9ucy4NCj4+Pj4+Pj4gV2Ugd291bGQgbGlrZSB0byBtYWtlIHN1 cmUgdGhhdCBhbnkgaW1wbGVtZW50YXRpb24gY29tcGx5aW5nIHRvIHRoZSBkcmFmdHMgd291 bGQgcHJvdmlkZSB0aGUgc2FtZSBMU0FzIHdoZW4gYXBwbGllZCB0byB0aGUgc2FtZSBuZXR3 b3JrLg0KPj4+Pj4+PiBXaXRoIHRoaXMgcGVyc3BlY3RpdmUgaW4gbWluZCwgd2Ugd2lzaCB0 byBnZXQgZHJhZnRzIHdpdGggc3VmZmljaWVudCBkb2N1bWVudGF0aW9uIHRvIG1ha2Ugc3Vy ZSB0aGUgTFNBIGRlc2lnbiBwcm9jZXNzIHRvIGJlIGRlcGljdGVkLCBieSBkZXNpZ24gcnVs ZXMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhlbmNlIHRoZSBjb250ZW50IG9mIHlvdXIgYW5zd2Vy IGxlYXZpbmcgbWUgdGhlICJvcHBvcnR1bml0eSB0byBkbyBhcyBJIHdpc2giLCBpcyBub3Qg cGxlYXNpbmcgbWUsIEkgd291bGQgcmF0aGVyIGhhdmUgc3RyaWN0IHJ1bGVzLCBhbmQgZGlz Y3Vzc2lvbnMgd2l0aCB0aGUgV0cgb24gdGhlIGRlc2lnbiBvZiB0aG9zZS4NCj4+Pj4+Pj4g VGhhdCBpcyB3aHkgYSBmaXJzdCBkZXNpZ24gcnVsZSwgd2UgY291bGQgYWdyZWUgb24gaXM6 IHRvIGdhdGhlciB0aGUgUmVzb3VyY2UgQmxvY2sgSW5mb3JtYXRpb24gVExWcyBpbnNpZGUg YSBkZWRpY2F0ZWQgTFNBLCBwb3NzaWJseSB3aXRoIGEgZGVkaWNhdGVkIHRvcC1sZXZlbCBU TFYgKHdoaWNoIGluIG15IG1pbmQgYWxsb3dzIHRvIGVuZm9yY2UgdGhpcyBkZXNpZ24gcnVs ZSkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0gUGll cnJlDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+ Pj4+PiBEZSA6IExlZXlvdW5nIFttYWlsdG86bGVleW91bmdAaHVhd2VpLmNvbV0NCj4+Pj4+ Pj4gRW52b3nDqSA6IG1lcmNyZWRpIDI4IHNlcHRlbWJyZSAyMDExIDAwOjA2DQo+Pj4+Pj4+ IMOAIDogUEVMT1NPLCBQSUVSUkUgKFBJRVJSRSk7IGNjYW1wQGlldGYub3JnDQo+Pj4+Pj4+ IE9iamV0IDogUkU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29u LXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhp IFBpZXJyZSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gUGxlYXNlIHNlZS1pbmxpbmUgZm9yIG15IHJl cGx5IHRvIHlvdXIgZmlyc3QgcG9pbnQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+ Pj4+Pj4+IFlvdW5nDQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4+IEZyb206IFBFTE9TTywgUElFUlJFIChQSUVSUkUpIFttYWlsdG86cGll cnJlLnBlbG9zb0BhbGNhdGVsLWx1Y2VudC5jb21dDQo+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXks IFNlcHRlbWJlciAyNywgMjAxMSAzOjI4IEFNDQo+Pj4+Pj4+IFRvOiBMZWV5b3VuZzsgY2Nh bXBAaWV0Zi5vcmcNCj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtDQ0FNUF0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0 DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhpIFlvdW5nLCBhbmQgQ0NBTVBlcnMsDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IEkgd2FzIG9mZiB0aGUgbWFpbGluZyBsaXN0cyBmb3IgdGhlIGxhc3QgdHdvIHdl ZWtzIGFuZCBiZWluZyBiYWNrIEkgbm90aWNlIGEgbG90IG9mIGV4Y2hhbmdlcywgd2hpY2gg SSdtIHZlcnkgZ2xhZCBvZi4NCj4+Pj4+Pj4gSSd2ZSBhbHNvIG5vdGljZWQgbWFueSBkcmFm dHMgaGF2ZSBiZWVuIHVwZGF0ZWQuDQo+Pj4+Pj4+IENvbmNlcm5pbmcgdGhpcyBzcGVjaWZp YyBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNiwg SSB3YW50ZWQgdG8gY29tbWVudCBzZWN0aW9uIDMuDQo+Pj4+Pj4+IEJhY2sgaW4gUXVlYmVj LCBJIGV4cHJlc3NlZCBteSBwb2ludCBvZiB2aWV3IChzaGFyZWQgd2l0aCBDeXJpbCwgSnVs aWVuIGFuZCBHaW92YW5uaSkgdGhhdCBjdXJyZW50IGRyYWZ0cyB3ZXJlIGxhY2tpbmcgZ3Vp ZGFuY2UgcmVnYXJkaW5nIHRoZSB3YXkgdG8gZGVzaWduIExTQXMgdGhhdCB3ZXJlIHRvIGRl cGljdCBhbiBXU09OIG5vZGUgd2l0aCBPRU9zLg0KPj4+Pj4+PiBUaGlzIHNlY3Rpb24gMyBw cm92aWRlcyBhZGRpdGlvbmFsIG1hdGVyaWFsIHRvIGhlbHAgZGVzaWduaW5nIHRoZSBMU0Eu DQo+Pj4+Pj4+IEkgd291bGQgbGlrZSB0byBrbm93IHdoZXRoZXIgYXV0aG9ycyBhcmUgd2ls bGluZyB0byBwdXJzdWUgZnVydGhlciBpbiB0aGlzIGRpcmVjdGlvbiwgd2hpY2ggaXMgdG8g bXkgbWluZCBhIHJlYWwgY29ybmVyIHN0b25lLCB0aGF0IHdvdWxkIGhlbHAgZXZlcnlvbmUg YWdyZWUgb24gYSBzb2x1dGlvbi4NCj4+Pj4+Pj4gQSBmaXJzdCBwb2ludCBjb3VsZCBjb25j ZXJuIHRoZSBSZXNvdXJjZSBCbG9jayBJbmZvcm1hdGlvbiAocmVtaW5kZXI6PFJlc291cmNl QmxvY2tJbmZvPiAgICA6Oj0gKFs8UmVzb3VyY2VTZXQ+XTxJbnB1dENvbnN0cmFpbnRzPiAg ICA8UHJvY2Vzc2luZ0NhcGFiaWxpdGllcz4gICAgPE91dHB1dENvbnN0cmFpbnRzPik6DQo+ Pj4+Pj4+ICAgICBXZSBhbGwgYWdyZWUgdGhhdCB0aGVzZSBpbmZvcm1hdGlvbiBhcmUgc3Rh dGljLCB0aGF0IHdlIHNob3VsZCBub3QgcmVwbGljYXRlIHRoaXMgVExWIHdoYXRldmVyIHRo ZSBudW1iZXIgbm90IHRoZSBsYXlvdXQgb2YgT0VPIGJvYXJkcyBvZiBhIGdpdmVuIHR5cGUu DQo+Pj4+Pj4+IFRoZW4sIHdlIGNvdWxkIGRlZGljYXRlIGEgc3BlY2lmaWMgaW5kZXBlbmRh bnQgZmxvb2RpbmcgZW50aXR5LiBUaGlzIHdvdWxkIGJlIGRlZmluZWQgb25jZSBmb3IgYWxs LCBhbmQgdGhhdCB3b3VsZCBub3QgbGVhdmUgcm9vbSB0byBkaWZmZXJlbnQgaW50ZXJwcmV0 YXRpb25zLg0KPj4+Pj4+PiBXaGF0IGFib3V0IHRoaXMgZmlyc3QgcG9pbnQ/DQo+Pj4+Pj4+ DQo+Pj4+Pj4+IFlPVU5HPj4gICAgSWYgSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHksIHdo YXQgeW91IGFyZSBzYXlpbmcgaXMgc2luY2UgdGhlIFJlc291cmNlIEJsb2NrIEluZm8gc3Vi LVRMViBpcyB2ZXJ5IHN0YXRpYyBpbiBuYXR1cmUsIGFkdmVydGlzZW1lbnQgb2YgdGhpcyBz dWItVExWIHNob3VsZCBiZSB0cmVhdGVkIGRpZmZlcmVudGx5IGZyb20gdGhlIHJlc3Qgb2Yg c3RhdGljLVRMVnMgKHdoaWNoIG1heSBjaGFuZ2Ugb3ZlciB0aW1lKS4gSXMgdGhpcyB3aGF0 IHlvdSBhcmUgc2F5aW5nPw0KPj4+Pj4+Pg0KPj4+Pj4+PiBJZiBteSBpbnRlcnByZXRhdGlv biBvZiB5b3VyIGNvbW1lbnQgaXMgY29ycmVjdCwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gLSBUaGUg Y3VycmVudCBtZWNoYW5pc20gYWxsb3dzIHdoYXQgeW91IHdhbnQ6IFBsZWFzZSBzZWUgdGhl IGZpcnN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDMuMg0KPj4+Pj4+PiAgICJJbiB0aGUgaGln aGx5IHVubGlrZWx5IGV2ZW50IHRoYXQgYSBXU09OIHN1Yi1UTFYgYnkgaXRzZWxmIHdvdWxk DQo+Pj4+Pj4+ICAgcmVzdWx0IGluIGFuIExTQSBleGNlZWRpbmcgdGhlIE1UVSwgYWxsIGZp dmUgV1NPTiBzcGVjaWZpYyBzdWItVExWcw0KPj4+Pj4+PiAgIGluIHRoaXMgZG9jdW1lbnQg cHJvdmlkZSBtZWNoYW5pc21zIHRoYXQgYWxsb3cgdGhlbSB0byBiZSBzdWJkaXZpZGVkDQo+ Pj4+Pj4+ICAgaW50byBzbWFsbGVyIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQgaW4gc2Vw YXJhdGUgT1NQRiBURSBMU0FzLiINCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWNjb3JkaW5nIHRvIHRo aXMgY2xhdXNlLCB5b3UgY2FuIHNlcGFyYXRlIHRoZSBSZXNvdXJjZSBCbG9jayBJbmZvIFN1 Yi1UTFYgYXMgdGhlIHNvbGUgZW50cnkgZGVmaW5lZCBpbiB0aGUgT3B0aWNhbCBOb2RlIHBy b3BlcnR5IFRMViBpbiBhIHNlcGFyYXRlIFRFIExTQSBmcm9tIHRoZSByZXN0IGlmIHlvdSB3 aWxsLiBOb3RoaW5nIHByZXZlbnRzIHRoaXMgcGFydGljdWxhciB3YXkgb2YgcGFja2FnaW5n LiAoSXNuJ3QgdGhpcyB3aGF0IHlvdSBtZWFudCAiYSBzcGVjaWZpYyBpbmRlcGVuZGVudCBm bG9vZGluZyBlbnRpdHkiPykNCj4+Pj4+Pj4NCj4+Pj4+Pj4gLSBQbGVhc2UgbGV0IG1lIGtu b3cgaWYgdGhpcyBleHBsYW5hdGlvbiBzYXRpc2ZpZXMgeW91LiBUaGFua3MgLS0tIFlvdW5n DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFBpZXJyZQ0K Pj4+Pj4+Pg0KPj4+Pj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4+Pj4g RGUgOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRm Lm9yZ10gRGUgbGEgcGFydCBkZSBMZWV5b3VuZyBFbnZvecOpIDogamV1ZGkgMTUgc2VwdGVt YnJlIDIwMTEgMjE6NTkgw4AgOiBjY2FtcEBpZXRmLm9yZyBPYmpldCA6IFJlOiBbQ0NBTVBd IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0 eS1vc3BmLTA2LnR4dA0KPj4+Pj4+Pg0KPj4+Pj4+PiBIaSBhbGwsDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IEFmdGVyIDA1IHZlcnNpb24gcHVibGljYXRpb24sIEFjZWUgcHJvdmlkZWQgYSBudW1i ZXIgb2YgdmFsdWFibGUgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLiBUaGlzIHJldmlzaW9u ICgwNikgcmVmbGVjdHMgdGhvc2UgY2hhbmdlcy4gUGxlYXNlIG5vdGUgdGhlIGZvbGxvd2lu ZyB1cGRhdGVzOg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtIENoYW5nZSB0aGUgdGl0bGUgb2YgdGhl IGRyYWZ0IHRvICJHTVBMUyBPU1BGIEVuaGFuY2VtZW50Li4uIiBmcm9tICJPU1BGIEVuaGFu Y2VtZW50Li4uIiB0byBtYWtlIHN1cmUgdGhlIGNoYW5nZXMgYXBwbHkgdG8gdGhlIEdNUExT IE9TUEYgcmF0aGVyIHRoYW4gdGhlIGJhc2UgT1NQRi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLSBB ZGQgc3BlY2lmaWMgT1NQRiBwcm9jZWR1cmVzIG9uIGhvdyBzdWItVExWcyBhcmUgcGFja2Fn ZWQgcGVyIFtSRkMzNjMwXSBhbmQgZWRpdG9yaWFsIGNoYW5nZSBpbmNsdWRpbmcgYXZvaWRp bmcgIm11bHRpcGxlIGluc3RhbmNlcyBvZiBURSBMU0EiIHRvICJtdWx0aXBsZSBURSBMU0Fz Ii4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gWW91ciBjb21tZW50cyBhcmUgYWx3YXlzIGFwcHJlY2lh dGVkLiBUaGFua3MuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJlc3QgUmVnYXJkcy4NCj4+Pj4+Pj4g WW91bmcNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+Pj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNj YW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcNCj4+Pj4+Pj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxNSwgMjAxMSAyOjQ4 IFBNDQo+Pj4+Pj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+Pj4+Pj4gQ2M6IGNj YW1wQGlldGYub3JnDQo+Pj4+Pj4+IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0DQo+ Pj4+Pj4+DQo+Pj4+Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBs YW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgVGl0 bGUgICAgICAgICAgIDogR01QTFMgT1NQRiBFbmhhbmNlbWVudCBmb3IgU2lnbmFsIGFuZCBO ZXR3b3JrIEVsZW1lbnQgQ29tcGF0aWJpbGl0eSBmb3IgV2F2ZWxlbmd0aCBTd2l0Y2hlZCBP cHRpY2FsIE5ldHdvcmtzDQo+Pj4+Pj4+ICAgQXV0aG9yKHMpICAgICAgIDogWW91bmcgTGVl DQo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIE0uIEJlcm5zdGVpbg0K Pj4+Pj4+PiAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWdu YWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4+PiAgIFBhZ2VzICAgICAgICAg ICA6IDE0DQo+Pj4+Pj4+ICAgRGF0ZSAgICAgICAgICAgIDogMjAxMS0wOS0xNQ0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgR01QTFMgT1NQRiByb3V0aW5n IGVuaGFuY2VtZW50cyB0byBzdXBwb3J0DQo+Pj4+Pj4+ICAgc2lnbmFsIGNvbXBhdGliaWxp dHkgY29uc3RyYWludHMgYXNzb2NpYXRlZCB3aXRoIFdTT04gbmV0d29yaw0KPj4+Pj4+PiAg IGVsZW1lbnRzLiBUaGVzZSByb3V0aW5nIGVuaGFuY2VtZW50cyBhcmUgcmVxdWlyZWQgaW4g Y29tbW9uIG9wdGljYWwNCj4+Pj4+Pj4gICBvciBoeWJyaWQgZWxlY3Ryby1vcHRpY2FsIG5l dHdvcmtzIHdoZXJlIG5vdCBhbGwgb2YgdGhlIG9wdGljYWwNCj4+Pj4+Pj4gICBzaWduYWxz IGluIHRoZSBuZXR3b3JrIGFyZSBjb21wYXRpYmxlIHdpdGggYWxsIG5ldHdvcmsgZWxlbWVu dHMNCj4+Pj4+Pj4gICBwYXJ0aWNpcGF0aW5nIGluIHRoZSBuZXR3b3JrLg0KPj4+Pj4+Pg0K Pj4+Pj4+PiAgIFRoaXMgY29tcGF0aWJpbGl0eSBjb25zdHJhaW50IG1vZGVsIGlzIGFwcGxp Y2FibGUgdG8gY29tbW9uIG9wdGljYWwNCj4+Pj4+Pj4gICBvciBoeWJyaWQgZWxlY3RybyBv cHRpY2FsIHN5c3RlbXMgc3VjaCBhcyBPRU8gc3dpdGNoZXMsIHJlZ2VuZXJhdG9ycywNCj4+ Pj4+Pj4gICBhbmQgd2F2ZWxlbmd0aCBjb252ZXJ0ZXJzIHNpbmNlIHN1Y2ggc3lzdGVtcyBj YW4gYmUgbGltaXRlZCB0bw0KPj4+Pj4+PiAgIHByb2Nlc3Npbmcgb25seSBjZXJ0YWluIHR5 cGVzIG9mIFdTT04gc2lnbmFscy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+Pj4+Pj4+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWdu YWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4+Pg0KPj4+Pj4+PiBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4+ Pj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+Pj4+Pj4+DQo+Pj4+ Pj4+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCj4+Pj4+Pj4g ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLXdz b24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gQ0NBTVAg bWFpbGluZyBsaXN0DQo+Pj4+Pj4+IENDQU1QQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tDQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gQW5kcmVh IFphbmFyZGkNCj4+Pj4+IENSRUFURS1ORVQNCj4+Pj4+IEVuZ2luZWVyaW5nJiAgRmFzdCBQ cm90b3R5cGluZyAoRU5HSU5FKSBBcmVhDQo+Pj4+PiBTZW5pb3IgRW5naW5lZXINCj4+Pj4+ IFZpYSBhbGxhIENhc2NhdGEgNTYvRCAtIDM4MTIzIFBvdm8gVHJlbnRvIChJdGFseSkNCj4+ Pj4+IGUtbWFpbDogYW5kcmVhLnphbmFyZGlAY3JlYXRlLW5ldC5vcmcNCj4+Pj4+IFRlbDog KCszOSkgMDQ2MSA0MDg0MDAgLSBpbnRlcm5vL2V4dGVuc2lvbiAxNDA3DQo+Pj4+PiBNb2Jp bGU6ICgrMzkpIDM0MCAwMDExODM3DQo+Pj4+PiBGYXg6ICgrMzkpIDA0NjEgNDIxMTU3DQo+ Pj4+PiBTa3lwZTogemFuYXJkaV9hbmRyZWENCj4+Pj4+IHd3dy5jcmVhdGUtbmV0Lm9yZw0K Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+Pj4+DQo+Pj4+PiBUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8NCj4+Pj4+IHdoaWNo IGl0IGlzIGFkZHJlc3NlZCBhbmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBw cml2aWxlZ2VkDQo+Pj4+PiBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24s IGRpc3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9mLCBvcg0KPj4+Pj4gdGFraW5nIG9mIGFu eSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiwgdGhpcyBpbmZvcm1hdGlvbiBieSBwZXJzb25z IG9yDQo+Pj4+PiBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQg aXMgcHJvaGliaXRlZCBhY2NvcmRpbmcgdG8gdGhlDQo+Pj4+PiBJdGFsaWFuIExhdyAxOTYv MjAwMyBvZiB0aGUgTGVnaXNsYXR1cmUuIElmIHlvdSByZWNlaXZlZCB0aGlzIGluIGVycm9y LA0KPj4+Pj4gcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBtYXRl cmlhbCBmcm9tIGFueSBjb21wdXRlci4NCj4+Pj4+DQo+Pj4+PiBMZSBpbmZvcm1hemlvbmkg Y29udGVudXRlIGluIHF1ZXN0byBtZXNzYWdnaW8gZGkgcG9zdGEgZWxldHRyb25pY2EgZSBu ZWkNCj4+Pj4+IGZpbGUgYWxsZWdhdGkgc29ubyBkYSBjb25zaWRlcmFyc2kgc3RyZXR0YW1l bnRlIHJpc2VydmF0ZS4gSWwgbG9ybyB1dGlsaXp6bw0KPj4+Pj4gZScgY29uc2VudGl0byBl c2NsdXNpdmFtZW50ZSBhbCBkZXN0aW5hdGFyaW8gZGVsIG1lc3NhZ2dpbywgcGVyIGxlIGZp bmFsaXRhJw0KPj4+Pj4gaW5kaWNhdGUgbmVsIG1lc3NhZ2dpbyBzdGVzc28uIFF1YWxvcmEg cmljZXZlc3RlIHF1ZXN0byBtZXNzYWdnaW8gc2VuemENCj4+Pj4+IGVzc2VybmUgaWwgZGVz dGluYXRhcmlvLCBWaSBwcmVnaGlhbW8gY29ydGVzZW1lbnRlIGRpIGRhcmNlbmUgbm90aXpp YSB2aWENCj4+Pj4+IGUtbWFpbCBlIGRpIHByb2NlZGVyZSBhbGxhIGNhbmNlbGxhemlvbmUg ZGVsIG1lc3NhZ2dpbyBzdGVzc28gZGFsIFZvc3Rybw0KPj4+Pj4gc2lzdGVtYS4gVHJhdHRl bmVyZSBpbCBtZXNzYWdnaW8gc3Rlc3NvLCBkaXZ1bGdhcmxvIGFuY2hlIGluIHBhcnRlLA0K Pj4+Pj4gZGlzdHJpYnVpcmxvIGFkIGFsdHJpIHNvZ2dldHRpLCBjb3BpYXJsbywgb2QgdXRp bGl6emFybG8gcGVyIGZpbmFsaXRhJw0KPj4+Pj4gZGl2ZXJzZSwgY29zdGl0dWlzY2UgY29t cG9ydGFtZW50byBjb250cmFyaW8gYWkgcHJpbmNpcGkgZGV0dGF0aSBkYWwgRC4gTGdzLg0K Pj4+Pj4gMTk2LzIwMDMuDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+ Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2NhbXANCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0NCj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+IEFuZHJlYSBaYW5hcmRpDQo+Pj4gQ1JFQVRFLU5FVA0KPj4+IEVuZ2luZWVyaW5nICYg RmFzdCBQcm90b3R5cGluZyAoRU5HSU5FKSBBcmVhDQo+Pj4gU2VuaW9yIEVuZ2luZWVyDQo+ Pj4gVmlhIGFsbGEgQ2FzY2F0YSA1Ni9EIC0gMzgxMjMgUG92byBUcmVudG8gKEl0YWx5KQ0K Pj4+IGUtbWFpbDogYW5kcmVhLnphbmFyZGlAY3JlYXRlLW5ldC5vcmcNCj4+PiBUZWw6ICgr MzkpIDA0NjEgNDA4NDAwIC0gaW50ZXJuby9leHRlbnNpb24gMTQwNw0KPj4+IE1vYmlsZTog KCszOSkgMzQwIDAwMTE4MzcNCj4+PiBGYXg6ICgrMzkpIDA0NjEgNDIxMTU3DQo+Pj4gU2t5 cGU6IHphbmFyZGlfYW5kcmVhDQo+Pj4gd3d3LmNyZWF0ZS1uZXQub3JnDQo+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ Pg0KPj4+IFRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRlbmRlZCBvbmx5IGZv ciB0aGUgcGVyc29uIG9yIGVudGl0eSB0bw0KPj4+IHdoaWNoIGl0IGlzIGFkZHJlc3NlZCBh bmQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZC9vciBwcml2aWxlZ2VkDQo+Pj4gbWF0 ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uIG9yIG90 aGVyIHVzZSBvZiwgb3INCj4+PiB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1 cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3INCj4+PiBlbnRpdGllcyBvdGhl ciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZCBhY2NvcmRpbmcg dG8gdGhlDQo+Pj4gSXRhbGlhbiBMYXcgMTk2LzIwMDMgb2YgdGhlIExlZ2lzbGF0dXJlLiBJ ZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBlcnJvciwNCj4+PiBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhlIG1hdGVyaWFsIGZyb20gYW55IGNvbXB1dGVyLg0KPj4+ DQo+Pj4gTGUgaW5mb3JtYXppb25pIGNvbnRlbnV0ZSBpbiBxdWVzdG8gbWVzc2FnZ2lvIGRp IHBvc3RhIGVsZXR0cm9uaWNhIGUgbmVpDQo+Pj4gZmlsZSBhbGxlZ2F0aSBzb25vIGRhIGNv bnNpZGVyYXJzaSBzdHJldHRhbWVudGUgcmlzZXJ2YXRlLiBJbCBsb3JvIHV0aWxpenpvDQo+ Pj4gZScgY29uc2VudGl0byBlc2NsdXNpdmFtZW50ZSBhbCBkZXN0aW5hdGFyaW8gZGVsIG1l c3NhZ2dpbywgcGVyIGxlIGZpbmFsaXRhJw0KPj4+IGluZGljYXRlIG5lbCBtZXNzYWdnaW8g c3Rlc3NvLiBRdWFsb3JhIHJpY2V2ZXN0ZSBxdWVzdG8gbWVzc2FnZ2lvIHNlbnphDQo+Pj4g ZXNzZXJuZSBpbCBkZXN0aW5hdGFyaW8sIFZpIHByZWdoaWFtbyBjb3J0ZXNlbWVudGUgZGkg ZGFyY2VuZSBub3RpemlhIHZpYQ0KPj4+IGUtbWFpbCBlIGRpIHByb2NlZGVyZSBhbGxhIGNh bmNlbGxhemlvbmUgZGVsIG1lc3NhZ2dpbyBzdGVzc28gZGFsIFZvc3Rybw0KPj4+IHNpc3Rl bWEuIFRyYXR0ZW5lcmUgaWwgbWVzc2FnZ2lvIHN0ZXNzbywgZGl2dWxnYXJsbyBhbmNoZSBp biBwYXJ0ZSwNCj4+PiBkaXN0cmlidWlybG8gYWQgYWx0cmkgc29nZ2V0dGksIGNvcGlhcmxv LCBvZCB1dGlsaXp6YXJsbyBwZXIgZmluYWxpdGEnDQo+Pj4gZGl2ZXJzZSwgY29zdGl0dWlz Y2UgY29tcG9ydGFtZW50byBjb250cmFyaW8gYWkgcHJpbmNpcGkgZGV0dGF0aSBkYWwgRC4g TGdzLg0KPj4+IDE5Ni8yMDAzLg0KPj4+DQo+Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4g Q0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSBy ZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklE RU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2Ug aW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQoNCg== From leeyoung@huawei.com Tue Nov 15 21:16:05 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24031F0C6F for ; Tue, 15 Nov 2011 21:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgX97GG+8lpx for ; Tue, 15 Nov 2011 21:16:01 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id C91711F0C47 for ; Tue, 15 Nov 2011 21:16:00 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ006MIMMHC0@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 15 Nov 2011 23:15:54 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00110MMHMV@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 15 Nov 2011 23:15:53 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 21:15:54 -0800 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 21:15:46 -0800 Date: Wed, 16 Nov 2011 05:15:45 +0000 From: Leeyoung In-reply-to: <9C659714-D3B5-4EAC-B5B7-24823253FFBA@ecitele.com> X-Originating-IP: [10.47.154.186] To: Dirk Schroetter Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718192DEB@dfweml501-mbx> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Thread-index: AQHMgdbfKpRl3bOBbUOtD09rA557ZpVq9kGggAG6D4CAADBlgIAAIZkAgAkeIYCAGi/wgIACj6sAgBwax+CAAMG8gP//e6wg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817E6BF@DFWEML501-MBX.china.huawei.com> <4E89C332.6020005@create-net.org> <7AEB3D6833318045B4AE71C2C87E8E171817E996@DFWEML501-MBX.china.huawei.com> <4E8B13C1.9030606@create-net.org> <2A9BEA32-6464-4FCE-BD30-3C8B2ECBB5C6@ericsson.com> <4E8B5888.70903@create-net.org> <0A1ED180-1DE9-4192-A90A-A9F492C02B52@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E17181832B9@DFWEML501-MBX.china.huawei.com> <24F96376-DCCF-49F3-A06B-48D1841427F4@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E1718192CB8@dfweml501-mbx> <9C659714-D3B5-4EAC-B5B7-24823253FFBA@ecitele.com> Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:16:06 -0000 SGkgRGlyaywNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGx5LiBJIHRoaW5rIHRoaXMgaXNzdWUgaXMg bm90IHVuaXF1ZSB0byB0aGlzIHBhcnRpY3VsYXIgY2FzZSBhcyB0aGlzIGlzIGEgd2VsbC1rbm93 biB0ZWNobmlxdWUgaW4gT1NQRi4gSWYgdGhlcmUgaXMgbGVnaXRpbWF0ZSBzZWN1cml0eSBpc3N1 ZSBhc3NvY2lhdGVkIHdpdGggSVAgZnJhZ21lbnRhdGlvbi9yZWFzc2VtYmx5LCB0aGlzIG5lZWRz IHRvIGJlIGFkZHJlc3NlZCBpbiBPU1BGIGluIGdlbmVyYWwuDQoNCkhpIEFjZWUsIA0KDQpXaGF0 IGlzIHlvdXIgdGFrZSBvbiB0aGlzIHNlY3VyaXR5IGlzc3VlPw0KDQpUaGFua3MuDQpZb3VuZw0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGlyayBTY2hyb2V0dGVyIFttYWls dG86RGlyay5TY2hyb2V0dGVyQGVjaXRlbGUuY29tXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVy IDE1LCAyMDExIDExOjAzIFBNDQpUbzogTGVleW91bmcNCkNjOiBBY2VlIExpbmRlbTsgY2NhbXBA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh bXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KDQpIaSBZb3VuZywNCg0K V2hpbGUgbm90IG9wcG9zZWQgdG8gdGhlIGlkZWEsIHdvdWxkbid0IHRoYXQgZ2l2ZSByYWlzZSB0 byBzZWN1cml0eSBjb25jZXJucyBmb3IgSVB2NCBhbmQgYSBkZXBlbmRlbmN5IG9uIHRoZSBvcGVy YXRpb24gb2YgSUNNUHY2IGZvciBJUHY2IG5ldHdvcmtzID8gSSBhbSBub3QgYSBzZWN1cml0eSBl eHBlcnQsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZCBnZXQgYSB2aWV3IGZyb20gdGhlIHNlY3VyaXR5 IGV4cGVydHMgb24gdGhhdCBtYXR0ZXIuDQoNCkNoZWVycywNCg0KL0RpcmsNCg0KU2VudCBmcm9t IGEgbW9iaWxlIGRldmljZS4gUGxlYXNlIGV4Y3VzZSBhbnkgc3BlbGxpbmcgZXJyb3JzLg0KDQpB bSAxNi4xMS4yMDExIHVtIDEwOjAxIHNjaHJpZWIgIkxlZXlvdW5nIiA8bGVleW91bmdAaHVhd2Vp LmNvbT46DQoNCj4gSGksDQo+DQo+IEFmdGVyIHRhbGtpbmcgdG8gTG91IGFuZCBiYXNlZCBvbiBB Y2VlJ3MgcHJldmlvdXMgZW1haWwgb24gdGhlIGlzc3VlIG9uIGhvdyByZXNvbHZlIGlmIHRoZSBP cHRpY2FsIE5vZGUgUHJvcGVydHkgVExWIGV4Y2VlZHMgdGhlIElQIE1UVSBmcmFnbWVudGF0aW9u IGxpbWl0ICgxNTAwIGJ5dGVzKSwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgc3VnZ2VzdGlvbi4gSWYg dGhpcyBpcyByZWFzb25hYmxlLCB3ZSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQ7IG90aGVyd2lzZSwg cGxlYXNlIHZvaWNlIG91dCBpbiB0aGUgbGlzdC4NCj4NCj4gLSBJIHN1Z2dlc3QgdGhlIHJ1bGUg c3BlY2lmaWVkICh1c2luZyBtdWx0aXBsZSBURSBMU0EncyBpbnRvIHdoaWNoIHN1Yi1UTFYncyBh cmUgYnJva2VuKSBpbiB0aGUgY3VycmVudCBkcmFmdCAoU2VjdGlvbiAzKSB0byBiZSByZW1vdmVk Lg0KPg0KPiBDdXJyZW50IHJ1bGUgc3BlY2lmaWVzIGluIGEgcmFyZSBjYXNlIHdoZXJlIHRoZSBU RS1MU0EgY29udGFpbmluZyB0aGUgT3B0aWNhbCBOb2RlIFByb3BlcnR5IFRMViAoaW4gd2hpY2gg d2Ugc3BlY2lmaWVkIDUgc3ViLVRMVnMpIGV4Y2VlZHMgdGhlIElQIE1UVSBmcmFnbWVudGF0aW9u IGxpbWl0LCB0aGVuIGl0IHdpbGwgYmUgYnJva2VuIGludG8gZml2ZSBtdWx0aXBsZSBURS1MU0En cyBpbiB3aGljaCBlYWNoIFRFLUxTQSBjb250YWlucyBhIHN1Yi1UTFYgKFNlZSBTZWN0aW9uIDMu MSBmb3IgdGhpcyBpbiB0aGUgY3VycmVudCBkcmFmdCkuDQo+DQo+IEluc3RlYWQgb2YgYnJlYWtp bmcgdXAsIHdoYXQgQWNlZSBzdWdnZXN0ZWQgaW4gdGhlIGF0dGFjaGVkIHByZXZpb3VzIGVtYWls IHdhczogd2UgY2FuIHJlbHkgb24gSVAgZnJhZ21lbnRhdGlvbi9yZWFzc2VtYmx5IGNhcGFiaWxp dHkgaW4gY2FzZSB0aGUgTFNBIG5lZWRzIHRvIGJlIGJyb2tlbiB1cC4NCj4NCj4gVGhlIHJhdGlv bmFsIGZvciB0aGlzIHN1Z2dlc3Rpb24gaXMgZm91ciBmb2xkczoNCj4gLSBPcHRpY2FsIE5vZGUg UHJvcGVydHkgVExWIHdpbGwgbm90IGV4Y2VlZCB0aGUgSVAgTVRVIGxpbWl0IGluIGEgbm9ybWFs IG5vZGUgY29uZmlndXJhdGlvbi4NCj4gLSBTcGxpdHRpbmcgaW5mb3JtYXRpb24gYWNyb3NzIG11 bHRpcGxlIExTQXMgd2lsbCByZXN1bHQgaW4gc29tZSBhZGRlZCBjb21wbGV4aXR5Lg0KPiAtIElQ IGZyYWdtZW50YXRpb24vcmVhc3NlbWJseSBjYW4gYmUgdXNlZCBhcyBhIGxhc3QgcmVzb3J0LCB3 aGljaCBpcyBhbiBhY2NlcHRhYmxlIG1ldGhvZC4NCj4gLSBUaGlzIGlzIGNvbnNpc3RlbnQgd2l0 aCB0aGUgcmVzb2x1dGlvbiBtYWRlIGluIHRoZSBwYXJhbGxlbCBkcmFmdCAoT1BTRiBleHRlbnNp b24gZm9yIGdlbmVyYWwgY29uc3RyYWludCwgRmF0YWkncykuDQo+DQo+IFRoYW5rcy4NCj4NCj4g WW91bmcNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWNlZSBMaW5k ZW0gW21haWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IEZyaWRheSwgT2N0 b2JlciAyOCwgMjAxMSA0OjE5IFBNDQo+IFRvOiBMZWV5b3VuZw0KPiBDYzogQW5kcmVhIFphbmFy ZGk7IGNjYW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPg0K PiBIaSBZb3VuZywNCj4NCj4gT24gT2N0IDI3LCAyMDExLCBhdCA5OjQ2IEFNLCBMZWV5b3VuZyB3 cm90ZToNCj4NCj4+IEhpIEFuZHJlYSBhbmQgQWNlZSwNCj4+DQo+PiBXaGF0IEkgYW0gcHJvcG9z aW5nIGlzIHRoaXM6DQo+Pg0KPj4gSW4gU2VjdGlvbiAyLCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcg c3RhdGVtZW50Og0KPj4NCj4+ICBBbGwgc3ViLVRMVnMgZGVmaW5lZCBoZXJlIG1heSBvY2N1ciBh dCBtb3N0IG9uY2UgaW4gYW55IGdpdmVuIE9wdGljYWwNCj4+ICBOb2RlIFRMVi4gVGhlc2UgcmVz dHJpY3Rpb25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4NCj4+ICBVbnJlY29n bml6ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuDQo+Pg0KPj4gSSB3aWxsIGNoYW5nZSB0aGUgYWJv dmUgc3RhdGVtZW50IHRvIHRoZSBmb2xsb3dpbmc6DQo+Pg0KPj4gIEFsbCBzdWItVExWcyBkZWZp bmVkIGhlcmUgbWF5IG9jY3VyIGF0IG1vc3Qgb25jZSBpbiBhbnkgZ2l2ZW4gT3B0aWNhbA0KPj4g IE5vZGUgVExWLiAiQXQgbW9zdCBvbmNlIiBtZWFucyB0aGF0IGlmIHRoZXJlIGlzIHN1Yi1UTFYg cmVsYXRlZCBpbmZvcm1hdGlvbiwNCj4+ICBpdCB3aWxsIGJlIGFsd2F5cyBpbmNsdWRlZC4gVGhl c2UgcmVzdHJpY3Rpb25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZQ0KPj4gIHN1Yi1UTFZzLiBV bnJlY29nbml6ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuDQo+Pg0KPj4gVGhpcyBzdGF0ZW1lbnQg YXNzdXJlcyB0aGF0IGFsbCB0aGUgcmVsYXRlZCBzdWItVExWcyBhcmUgYWx3YXlzIGluY2x1ZGVk IGluIGFueSBnaXZlbg0KPj4gT3B0aWNhbCBOb2RlIFRMViBsZWF2aW5nIG5vIHJvb20gbm90IHRv IGluY2x1ZGUgc3VjaCBzdWItVExWcyBpbiB0aGUgT3B0aWNhbA0KPj4gTm9kZSBUTFYuDQo+Pg0K Pj4gSW4gU2VjdGlvbiAzLjIsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQ6DQo+Pg0K Pj4gIEluIHRoZSBoaWdobHkgdW5saWtlbHkgZXZlbnQgdGhhdCBhIFdTT04gc3ViLVRMViBieSBp dHNlbGYgd291bGQNCj4+ICByZXN1bHQgaW4gYW4gTFNBIGV4Y2VlZGluZyB0aGUgTVRVLCBhbGwg Zml2ZSBXU09OIHNwZWNpZmljIHN1Yi1UTFZzDQo+PiAgaW4gdGhpcyBkb2N1bWVudCBwcm92aWRl IG1lY2hhbmlzbXMgdGhhdCBhbGxvdyB0aGVtIHRvIGJlIHN1YmRpdmlkZWQNCj4+ICBpbnRvIHNt YWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBzZXBhcmF0ZSBPU1BGIFRFIExTQXMu DQo+Pg0KPj4gSSB3aWxsIGNoYW5nZSB0aGUgYWJvdmUgc3RhdGVtZW50IHRvIHRoZSBmb2xsb3dp bmc6DQo+Pg0KPj4gIEluIHRoZSBoaWdobHkgdW5saWtlbHkgZXZlbnQgdGhhdCBhIFdTT04gc3Vi LVRMViBieSBpdHNlbGYgd291bGQNCj4+ICByZXN1bHQgaW4gYW4gTFNBIGV4Y2VlZGluZyB0aGUg TVRVLCBhbGwgZml2ZSBXU09OIHNwZWNpZmljIHN1Yi1UTFZzDQo+PiAgaW4gdGhpcyBkb2N1bWVu dCBwcm92aWRlIG1lY2hhbmlzbXMgdGhhdCBhbGxvdyB0aGVtIHRvIGJlIHN1YmRpdmlkZWQNCj4+ ICBpbnRvIHNtYWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBzZXBhcmF0ZSBPU1BG IFRFIExTQXMuDQo+Pg0KPj4gIFdoYXQgaXMgc3VnZ2VzdGVkIGFzIGJlbG93IGlzIHRoZSBvbmx5 IG9wdGlvbiBhbGxvd2VkIHdoZW4gZGl2aWRpbmcgdXANCj4+ICB0aGUgY3VycmVudCBzZXQgb2Yg c3ViLVRMVnMgaW50byBzZXBhcmF0ZSBPU1BGIFRFIExTQXMuIFRoaXMgbWVhbnMNCj4+ICBlYWNo IHN1Yi1UTFYgd2lsbCBiZSBwYWNrYWdlZCBhcyB0aGUgc29sZSBlbGVtZW50IGluIGFuIE9TUEYg VEUgTFNBDQo+PiAgd2l0aCBhIHVuaXF1ZSBMU0EgaW5zdGFuY2UgbnVtYmVyLiBXaGVuIHN1Y2gg ZGl2aXNpb24gaXMgaW1wbGVtZW50ZWQsIHRoZW4NCj4+ICB0aGUgc291cmNlIG5vZGUgbXVzdCBm bHVzaCB0aGUgZXhpc3RpbmcgTFNBIChpLmUuLCB0aGUgb3JpZ2luYWwgT1NQRg0KPj4gIFRFIExT QSB3aXRoIGFsbCBzdWItVExWJ3MgcGFja2FnZWQgdG9nZXRoZXIgYXMgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMikuDQo+PiAgVGhpcyB3aWxsIGF2b2lkIGR1cGxpY2F0aW5nIHRoZSBzYW1lIGluZm9y bWF0aW9uIGJlaW5nIGFkdmVydGlzZWQgYWNyb3NzDQo+PiAgbXVsdGlwbGUgTFNBcy4NCj4NCj4g cy9MU0EgaW5zdGFuY2UgbnVtYmVyL0xpbmsgU3RhdGUgSUQvDQo+DQo+IFNvLCBpdCBpcyBub3Qg ZXhwZWN0ZWQgdGhhdCBhIHN1Yi1UTFYgd2lsbCBleGNlZWQgdGhlIElQIE1UVSBhbmQsIGlmIGl0 IGRvZXMsIHdlIHNpbXBseSByZWx5IG9uIElQIGZyYWdtZW50YXRpb24vcmVhc3NlbWJseSBhcyB3 ZSBkbyBpbiBzaXR1YXRpb25zIHdoZXJlIHRoZSBSb3V0ZXItTFNBcyBhbmQgbWFueSBpbnRlcmZh Y2VzIGluIGEgc2luZ2xlIGFyZWEuIENvcnJlY3Q/DQo+DQo+IFRoYW5rcywNCj4gQWNlZQ0KPg0K Pj4NCj4+IFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGVzZSB0ZXh0cyB3aWxsIHJlbW92ZSBhbnkg YW1iaWd1aXR5IG9mIHRoZSBjdXJyZW50DQo+PiBUZXh0cy4NCj4+DQo+PiBCZXN0IFJlZ2FyZHMs DQo+PiBZb3VuZw0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEFjZWUg TGluZGVtIFttYWlsdG86YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tXQ0KPj4gU2VudDogTW9uZGF5 LCBPY3RvYmVyIDEwLCAyMDExIDk6MTggQU0NCj4+IFRvOiBBbmRyZWEgWmFuYXJkaQ0KPj4gQ2M6 IExlZXlvdW5nOyBjY2FtcEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYu dHh0DQo+Pg0KPj4gSGkgQW5kcmVhLA0KPj4gT24gT2N0IDQsIDIwMTEsIGF0IDM6MDMgUE0sIEFu ZHJlYSBaYW5hcmRpIHdyb3RlOg0KPj4NCj4+PiBIaSBBY2VlLA0KPj4+DQo+Pj4gT24gMTAvMDQv MjAxMSAwNzowMyBQTSwgQWNlZSBMaW5kZW0gd3JvdGU6DQo+Pj4+IEhpIEFuZHJlYSwNCj4+Pj4N Cj4+Pj4gT24gT2N0IDQsIDIwMTEsIGF0IDEwOjEwIEFNLCBBbmRyZWEgWmFuYXJkaSB3cm90ZToN Cj4+PiAuLi4uDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gTXkgcG9pbnQgaXMgaW4gYXZvaWRpbmcgYW1i aWd1aXRpZXM6IGlmIHRoZSBzdXBwb3J0IGZvciBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIGZvciB0 aGUNCj4+Pj4+IHNhbWUgZW50aXR5IHRvcCBUTFYgaXMgcmVxdWVzdGVkLCBpdCBzaG91bGQgYmUg ZXhwbGljaXRseSBzdGF0ZWQgYXMgbWFuZGF0b3J5DQo+Pj4+PiAocG9zc2libHkgcHJvdmlkaW5n IGV4cGxpY2l0IHJ1bGVzIGZvciB0aGUgc3ViZGl2aXNpb24sIGFzIGluIENoYXAuIDMgb2YgdGhl IGRyYWZ0KS4NCj4+Pj4NCj4+Pj4gVGhlcmUgYXJlIG5vdCBtdWx0aXBsZSBpbnN0YW5jZXMgb2Yg dGhlIHNhbWUgTFNBLiBSYXRoZXIgdGhleSBhcmUgdW5pcXVlIExTQXMsDQo+Pj4+IGFzIGlkZW50 aWZpZWQgYnkgdGhlIChUeXBlLCBMaW5rIFN0YXRlIElELCBBZHZlcnRpc2luZyBSb3V0ZXIpIHR1 cGxlLg0KPj4+PiBJbiB0aGlzIGNhc2UsIHRoZXkgaGF2ZSBkaWZmZXJlbnQgTGluayBTdGF0ZSBJ RHMuDQo+Pj4+IE9uZSB0aGluZyB0aGF0IGlzIGNvbmZ1c2luZyBpcyB0aGF0IFJGQyAzNjMwIHJl ZmVycyB0byB0aGUgcG9ydGlvbiBvZiB0aGUgTGluayBTdGF0ZSBJRA0KPj4+PiBwcm92aWRpbmcg dW5pcXVlbmVzcyBhcyAiSW5zdGFuY2UiLg0KPj4+PiBBbHNvIG5vdGUgdGhhdCBkcmFmdC1pZXRm LWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQgZG9lc24ndCBpbmNs dWRlIGFueQ0KPj4+PiBhZGRpdGlvbnMgdG8gdGhlIExpbmsgVExWIHNvIEknbSBub3Qgc3VyZSB3 aHkgeW91IGFyZSBjaXRpbmcgaXQgaW4gZGlzY3Vzc2lvbnMgb2YgdGhlIG5ldyB0b3AtbGV2ZWwg VExWcy4NCj4+Pg0KPj4+IEkgd2FzIHJlcGx5aW5nIHRvIFlvdW5nIGVtYWlsIHByb3ZpZGluZyB0 aGUgTGluayBUTFYgYW5kDQo+Pj4gUkZDIDM2MzAgYXMgYW4gZXhhbXBsZSBvZiB0aGUgdXNhZ2Ug b2YgbXVsdGlwbGUgTFNBcyBhbmQgb2YNCj4+PiBzZW5kaW5nIExTQSB1cGRhdGVzIHdpdGggbWlz c2luZyBzdWItVExWczsNCj4+PiBJIHdhcyBkaXNjdXNzaW5nIGFib3V0IHRoZSBjb3JyZWN0bmVz cyBvZiB0aGUgZXhhbXBsZSwNCj4+PiB0aGF0J3Mgd2h5IEkgd2FzIGNpdGluZyB0aGUgTGluayBU TFYuDQo+Pg0KPj4gT2suDQo+Pg0KPj4+DQo+Pj4gVGhlIHVzYWdlIG9mIHRoZSB3b3JkICJpbnN0 YW5jZSIgaXMgcHJvYmFibHkgbm90IGNvcnJlY3QuDQo+Pj4NCj4+PiBXaGF0IEkgbWVhbnQgYnkg Im11bHRpcGxlIExTQSBpbnN0YW5jZXMiIHdhcyBkaWZmZXJlbnQgTFNBcyAod2l0aCBkaXN0aW5j dCBMUyBJRA0KPj4+IGFuZCBib3RoIHByZXNlbnQgaW4gdGhlIFRFIERCIGF0IHRoZSBzYW1lIHRp bWUpIGRlc2NyaWJpbmcgdGhlIHNhbWUgZW50aXR5DQo+Pj4gKGUuZy4gdGhlIHNhbWUgbGluayBi eSBpbmNsdWRpbmcgdGhlIHNhbWUgTGluayBUeXBlIC8gTGluayBJRCBzdWItVExWcykNCj4+PiBl YWNoIG9uZSBwcm92aWRpbmcgYSBzdWJzZXQgb2YgdGhlIGluZm9ybWF0aW9uIChlLmcuIGEgc3Vi c2V0IG9mIHRoZSBvdGhlciBzdWItVExWcykuDQo+Pj4NCj4+PiBDb25zaWRlcmluZyB0aGUgZHJh ZnQgVExWcywgdGhpcyBzaG91bGQgYmUgdGhlIGNhc2Ugb2YgQ2hhcC4gMy4yLjEgIlN1Yi1EaXZp c2lvbiBieSBPcHRpb25zIiwgZS5nLjoNCj4+PiB0d28gTFNBcyB3aXRoIGEgUmVzb3VyY2UgQmxv Y2sgSW5mb3JtYXRpb24gc3ViLVRMViB3aXRoIHRoZSBzYW1lIFJCIFNldCBGaWVsZA0KPj4+IGFu ZCBkaWZmZXJlbnQgc3ViLXNldHMgb2Ygb3B0aW9uYWwgc3ViLXN1Yi1UTFZzLg0KPj4+DQo+Pj4g VG8gYXZvaWQgYW1iaWd1aXRpZXMsIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0IHRoZSBvcHRpb25z IGRlc2NyaWJlZCBpbiBDaGFwLiAzDQo+Pj4gYXJlIHRoZSBvbmx5IG9wdGlvbnMgYW5kIHRoYXQs IGV2ZW4gaWYgdGhleSAiY2FuIiBiZSB1c2VkIHdoZW4gZ2VuZXJhdGluZw0KPj4+IHRoZSBMU0Fz LCB0aGV5ICJtdXN0IiBhbGwgYmUgc3VwcG9ydGVkIHdoZW4gcmVjZWl2aW5nIGFuZCAndXNpbmcn IHRoZSBMU0FzLg0KPj4NCj4+IEFncmVlZC4gU3BsaXR0aW5nIGluZm9ybWF0aW9uIGFjcm9zcyBt dWx0aXBsZSBMU0FzIHdpbGwgcmVzdWx0IGluIHNvbWUgYWRkZWQgY29tcGxleGl0eS4NCj4+IEZv ciBUTFZzIG9yIHN1Yi1UTFZzIHRoYXQgYXJlIHJlcXVpcmVkIGZvciBhIHNpbmdsZSBXU09OIGNv bXB1dGF0aW9uLCB0aGUgV1NPTiBwYXRoIGNvbXB1dGF0aW9uIG11c3QgY29uY2F0ZW5hdGUgdGhl bSB3aGVuIGRvaW5nIHRoYXQgY29tcHV0YXRpb24uDQo+PiBUb2RheSwgbXVsdGlwbGUgT1NQRnYz IFJvdXRlci1MU0FzIG1heSBiZSBvcmlnaW5hdGVkIGFuZCBpbXBsZW1lbnRhdGlvbiBNVVNUIHVz ZSB0aGUgY29uY2F0ZW5hdGlvbiB3aGVuIGRvaW5nIHRoZSBPU1BGdjMgU1BGIGNvbXB1dGF0aW9u Lg0KPj4NCj4+IFRoYW5rcywNCj4+IEFjZWUNCj4+DQo+Pj4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+ Pj4gQW5kcmVhDQo+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBBY2VlDQo+Pj4+DQo+Pj4+DQo+Pj4+ DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+PiBBbmRyZWENCj4+Pj4+DQo+Pj4+ PiBPbiAxMC8wMy8yMDExIDA5OjM0IFBNLCBMZWV5b3VuZyB3cm90ZToNCj4+Pj4+PiBIaSBBbmRy ZWEsDQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MgZm9yIHlvdXIgaW50ZXJlc3QgYW5kIGlucHV0IHRv IHRoaXMgaXNzdWUuDQo+Pj4+Pj4NCj4+Pj4+PiBNeSBvdmVyYWxsIHBvaW50IHdhcyB0aGF0IHRo ZSBjdXJyZW50IEdNUExTIFRFIExTQSAocGVyIFJGQyAzNjMwKSBkb2VzIG5vdCBzcGVjaWZ5IGRl dGFpbCBpbXBsZW1lbnRhdGlvbnMgYXMgdG8gaG93IHRvIGRpdmlkZSB1cCB0aGUgVEUgTGluayBU TFZzIGludG8gc3RhdGljIHZzLiBkeW5hbWljIG5vciBob3cgdG8gdXNlIG11bHRpcGxlIFRFIExT QXMuIFRoZSBjdXJyZW50IFdTT04gZG9jdW1lbnQgZm9sbG93cyBhIHNpbWlsYXIgZG9jdW1lbnQg cGhpbG9zb3BoeSB3aXRoIHRoZSBHTVBMUyBwcmVkZWNlc3Nvci4NCj4+Pj4+Pg0KPj4+Pj4+IFJl Z2FyZGluZyB5b3VyIHBvaW50IG9uIGhvdyB0aGUgVEUgREIgd29ya3MgaW4gcmVnYXJkIHRvIG1p c3Npbmcgc3ViLVRMVnMgYXJlIGRlbGV0ZWQgc2VlbXMgdG8gbWUgYSBwYXJ0aWN1bGFyIGltcGxl bWVudGF0aW9uLCB3aGljaCBpcyBtb3N0IHNpbXBsaXN0aWMgaW4gbmF0dXJlLg0KPj4+Pj4+DQo+ Pj4+Pj4gQmVzdCBSZWdhcmRzLA0KPj4+Pj4+IFlvdW5nDQo+Pj4+Pj4NCj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5kcmVhIFphbmFy ZGkNCj4+Pj4+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMDMsIDIwMTEgOToxNCBBTQ0KPj4+Pj4+ IFRvOiBMZWV5b3VuZw0KPj4+Pj4+IENjOiBjY2FtcEBpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6 IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29t cGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4+DQo+Pj4+Pj4gSGkgWW91bmcsDQo+Pj4+Pj4N Cj4+Pj4+PiBJIHdhcyBmb2xsb3dpbmcgdGhlIGRpc2N1c3Npb24gYW5kIEkgaGF2ZSBhIGRvdWJ0 IGFib3V0DQo+Pj4+Pj4geW91ciBleGFtcGxlIHJlbGF0ZWQgdG8gdGhlIFRFIExpbmsgVExWLg0K Pj4+Pj4+DQo+Pj4+Pj4gSXQncyB0cnVlIHRoYXQgdGhlIGF0dHJpYnV0ZXMgc3ViLVRMViBhcmUg bm90IG1hbmRhdG9yeSBwZXIgUkZDIDM2MzAsDQo+Pj4+Pj4gYnV0IEkgZG9uJ3QgdGhpbmsgdGhh dCBtZWFucyB0aGF0IHRoZXkgY2FuIGJlIG5vdCBpbmNsdWRlZCBpbiBhbiBMU0EgdXBkYXRlDQo+ Pj4+Pj4gaWYgdW5jaGFuZ2VkIChpbXBseWluZyB0aGF0IHRoZSBwcmV2aW91cyB2YWx1ZSBwZXJz aXN0cykuDQo+Pj4+Pj4NCj4+Pj4+PiBBcyBmb3IgbXkgdW5kZXJzdGFuZGluZyBvZiBob3cgT1NQ Ri1URSB3b3JrcywgdGhlIG1hbmFnZWQgVEUgREIgZW50aXR5IGlzIHRoZSBMU0EuDQo+Pj4+Pj4g V2hlbiBhbiBMU0EgdXBkYXRlIGlzIHByb2Nlc3NlZCwgdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg ZGVsZXRlZCBmcm9tIHRoZSBURSBEQg0KPj4+Pj4+IGFuZCBpdCBpcyByZXBsYWNlZCBieSB0aGUg bmV3IG9uZTogbGluayBhdHRyaWJ1dGVzIHJlbGF0ZWQgdG8gbWlzc2luZyBzdWItVExWIGFyZQ0K Pj4+Pj4+IGRlbGV0ZWQsIHNvIHRoZXkgbXVzdCBiZSBwcmVzZW50IGV2ZW4gaWYgdW5jaGFuZ2Vk Lg0KPj4+Pj4+DQo+Pj4+Pj4gSW4gdGhlb3J5LCB0aGUgc2V0IG9mIGxpbmsgYXR0cmlidXRlcyBj b3VsZCBiZSBzdGF0aWNhbGx5IGRpdmlkZWQNCj4+Pj4+PiBpbiB0d28gZGlmZmVyZW50IExTQXMg aW5zdGFuY2VzICh1cGRhdGVkIGluZGVwZW5kZW50bHkpLA0KPj4+Pj4+IGJ1dCBJIGRvbid0IHRo aW5rIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGhhbmRsZSB0aGlzIHNjZW5hcmlvDQo+Pj4+Pj4g KGFsc28gYmVjYXVzZSwgaW4gbXkgb3BpbmlvbiwgaXQncyBub3Qgc3VnZ2VzdGVkIGJ5IFJGQyAz NjMwIGFuZA0KPj4+Pj4+IGl0IGdpdmVzIG5vIHJ1bGUgb24gaG93IHRvIGRpdmlkZSB0aGVtKS4N Cj4+Pj4+Pg0KPj4+Pj4+IEJ1dCBJIGFzayB0byB0aGUgbWFpbGluZyBsaXN0IGlmIHRoaXMgaXMg dGhlIGNvcnJlY3QgaW50ZXJwcmV0YXRpb24uDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+ Pj4+IEFuZHJlYQ0KPj4+Pj4+DQo+Pj4+Pj4gT24gMDkvMzAvMjAxMSAxMToxNiBQTSwgTGVleW91 bmcgd3JvdGU6DQo+Pj4+Pj4+IEhpIFBpZXJyZSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSBnb3QgeW91 ciBwb2ludC4gTGV0IG1lIGFzayB5b3UgdGhpcyBxdWVzdGlvbi4gSW4gdGhlIGN1cnJlbnQgR01Q TFMgT1NQRiBURSBMaW5rIFRMViBhcmUgZGVmaW5lZCB1bmRlciBPcGFxdWUgVEUgTFNBIHdpdGgg dGhlIGZvbGxvd2luZyBhdHRyaWJ1dGVzOg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtIFRFIE1ldHJpYw0K Pj4+Pj4+PiAtIG1heCBCL1cNCj4+Pj4+Pj4gLSBtYXggcmVzZXJ2YWJsZSBiL3cNCj4+Pj4+Pj4g LSB1bnJlc2VydmVkIGIvdw0KPj4+Pj4+PiAtIEFkbWluIEdyb3VwDQo+Pj4+Pj4+IC0gTGluayBQ cm90ZWN0aW9uIFR5cGUNCj4+Pj4+Pj4gLSBTUkxHDQo+Pj4+Pj4+IC0gSVNDRA0KPj4+Pj4+PiAt IGV0Yy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQW5kIHRoZXNlIGFyZSBhIG1peHR1cmUgb2Ygc3RhdGlj IGFuZCBkeW5hbWljIGluZm9ybWF0aW9uIGFuZCB5ZXQgdGhleSBhcmUgYXNzZW1ibGVkIHRvZ2V0 aGVyIGFzIG9uZSBURSBMaW5rIFRMVi4gRm9yIGluc3RhbmNlIHRoZSBJU0NEIGlzIHF1aXRlIHNp bWlsYXIgdG8gUmVzb3VyY2UgQmxvY2sgSW5mbyBpbiB0aGF0IGl0IGRvZXMgbm90IGNoYW5nZSBv ZnRlbiB1bmxlc3MgdGhlcmUgYXJlIG5ldyBlbGVtZW50cyBhZGRlZCBpbiB0aGUgbm9kZSBvciBj b25maWd1cmF0aW9uIGNoYW5nZXMgYW5kIHlldCBpdCBpcyBwYWNrYWdlZCB0b2dldGhlciB3aXRo IG90aGVyIGR5bmFtaWMgaW5mb3JtYXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFdoeT8NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byBrZWVwIHN0YXRpYy91bmNoYW5nZWQg aW5mb3JtYXRpb24gZnJvbSBiZWluZyBmbG9vZGVkLiBPbmx5IHRoZSBMaW5rIFR5cGUgYW5kIExp bmsgSUQgd2hpY2ggYXJlIG1hbmRhdG9yeSBpbiB0aGUgVEUgTGluayBUTFYgcGVyIFJGQzM2MzAu IEFsbCBvdGhlciBzdWItVExWIGFyZSBvcHRpb25hbCBhbmQgbWF5IG9jY3VyIGF0IG1vc3Qgb25j ZSAod2hlbiB0aGVyZSBhcmUgZW5vdWdoIGNoYW5nZXMgZnJvbSB0aGUgcHJldmlvdXMgcGVyaW9k IHRoYXQgZGVzZXJ2ZSBhbiB1cGRhdGUpIGFuZCBuZWVkIG5vdCBiZSBpbmNsdWRlZCBpbiB0aGUg VEUgTGluayBUTFYgd2hlbiB0aGVyZSBpcyBubyBuZWVkIGZvciB1cGRhdGluZy4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gSSByZWFsbHkgZG9uJ3Qgc2VlIHRoZSBuZWVkIGZvciBhIHNlcGFyYXRlIHRvcC1s ZXZlbCBUTFYgYW5kL29yIGEgc2VwYXJhdGUgTFNBIGZvciB0aGUgUmVzb3VyY2UgQmxvY2sgaW5m b3JtYXRpb24uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pj4+IFlvdW5nDQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+Pj4+IEZyb206IFBFTE9TTywgUElFUlJFIChQSUVSUkUpIFttYWlsdG86cGllcnJlLnBl bG9zb0BhbGNhdGVsLWx1Y2VudC5jb21dDQo+Pj4+Pj4+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVy IDMwLCAyMDExIDk6MzkgQU0NCj4+Pj4+Pj4gVG86IExlZXlvdW5nOyBjY2FtcEBpZXRmLm9yZw0K Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1w LXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+Pj4+Pj4NCj4+Pj4+Pj4g SGkgWW91bmcsDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgdW5kZXJzdGFuZCB0aGUgY29udGVudCBvZiB5 b3VyIGFuc3dlciwgYnV0IEknbSBub3Qgc2F0aXNmaWVkIHdpdGggaXQuDQo+Pj4+Pj4+IE15IGNv bmNlcm4gZGVhbHMgd2l0aCBwcm92aWRpbmcgYSB1bmlxdWUgcmVhZGluZy9pbnRlcnByZXRhdGlv biBvZiB0aGUgT1NQRi1URSBleHRlbnNpb25zLg0KPj4+Pj4+PiBXZSB3b3VsZCBsaWtlIHRvIG1h a2Ugc3VyZSB0aGF0IGFueSBpbXBsZW1lbnRhdGlvbiBjb21wbHlpbmcgdG8gdGhlIGRyYWZ0cyB3 b3VsZCBwcm92aWRlIHRoZSBzYW1lIExTQXMgd2hlbiBhcHBsaWVkIHRvIHRoZSBzYW1lIG5ldHdv cmsuDQo+Pj4+Pj4+IFdpdGggdGhpcyBwZXJzcGVjdGl2ZSBpbiBtaW5kLCB3ZSB3aXNoIHRvIGdl dCBkcmFmdHMgd2l0aCBzdWZmaWNpZW50IGRvY3VtZW50YXRpb24gdG8gbWFrZSBzdXJlIHRoZSBM U0EgZGVzaWduIHByb2Nlc3MgdG8gYmUgZGVwaWN0ZWQsIGJ5IGRlc2lnbiBydWxlcy4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gSGVuY2UgdGhlIGNvbnRlbnQgb2YgeW91ciBhbnN3ZXIgbGVhdmluZyBtZSB0 aGUgIm9wcG9ydHVuaXR5IHRvIGRvIGFzIEkgd2lzaCIsIGlzIG5vdCBwbGVhc2luZyBtZSwgSSB3 b3VsZCByYXRoZXIgaGF2ZSBzdHJpY3QgcnVsZXMsIGFuZCBkaXNjdXNzaW9ucyB3aXRoIHRoZSBX RyBvbiB0aGUgZGVzaWduIG9mIHRob3NlLg0KPj4+Pj4+PiBUaGF0IGlzIHdoeSBhIGZpcnN0IGRl c2lnbiBydWxlLCB3ZSBjb3VsZCBhZ3JlZSBvbiBpczogdG8gZ2F0aGVyIHRoZSBSZXNvdXJjZSBC bG9jayBJbmZvcm1hdGlvbiBUTFZzIGluc2lkZSBhIGRlZGljYXRlZCBMU0EsIHBvc3NpYmx5IHdp dGggYSBkZWRpY2F0ZWQgdG9wLWxldmVsIFRMViAod2hpY2ggaW4gbXkgbWluZCBhbGxvd3MgdG8g ZW5mb3JjZSB0aGlzIGRlc2lnbiBydWxlKS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gUmVnYXJkcywNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gLSBQaWVycmUNCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1NZXNzYWdlIGQn b3JpZ2luZS0tLS0tDQo+Pj4+Pj4+IERlIDogTGVleW91bmcgW21haWx0bzpsZWV5b3VuZ0BodWF3 ZWkuY29tXQ0KPj4+Pj4+PiBFbnZvecOpIDogbWVyY3JlZGkgMjggc2VwdGVtYnJlIDIwMTEgMDA6 MDYNCj4+Pj4+Pj4gw4AgOiBQRUxPU08sIFBJRVJSRSAoUElFUlJFKTsgY2NhbXBAaWV0Zi5vcmcN Cj4+Pj4+Pj4gT2JqZXQgOiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1w LXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+Pj4+Pj4NCj4+Pj4+Pj4g SGkgUGllcnJlLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBQbGVhc2Ugc2VlLWlubGluZSBmb3IgbXkgcmVw bHkgdG8geW91ciBmaXJzdCBwb2ludC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+ Pj4gWW91bmcNCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+Pj4gRnJvbTogUEVMT1NPLCBQSUVSUkUgKFBJRVJSRSkgW21haWx0bzpwaWVycmUucGVsb3Nv QGFsY2F0ZWwtbHVjZW50LmNvbV0NCj4+Pj4+Pj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI3 LCAyMDExIDM6MjggQU0NCj4+Pj4+Pj4gVG86IExlZXlvdW5nOyBjY2FtcEBpZXRmLm9yZw0KPj4+ Pj4+PiBTdWJqZWN0OiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdz b24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSGkg WW91bmcsIGFuZCBDQ0FNUGVycywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSSB3YXMgb2ZmIHRoZSBtYWls aW5nIGxpc3RzIGZvciB0aGUgbGFzdCB0d28gd2Vla3MgYW5kIGJlaW5nIGJhY2sgSSBub3RpY2Ug YSBsb3Qgb2YgZXhjaGFuZ2VzLCB3aGljaCBJJ20gdmVyeSBnbGFkIG9mLg0KPj4+Pj4+PiBJJ3Zl IGFsc28gbm90aWNlZCBtYW55IGRyYWZ0cyBoYXZlIGJlZW4gdXBkYXRlZC4NCj4+Pj4+Pj4gQ29u Y2VybmluZyB0aGlzIHNwZWNpZmljIGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0 aWJpbGl0eS1vc3BmLTA2LCBJIHdhbnRlZCB0byBjb21tZW50IHNlY3Rpb24gMy4NCj4+Pj4+Pj4g QmFjayBpbiBRdWViZWMsIEkgZXhwcmVzc2VkIG15IHBvaW50IG9mIHZpZXcgKHNoYXJlZCB3aXRo IEN5cmlsLCBKdWxpZW4gYW5kIEdpb3Zhbm5pKSB0aGF0IGN1cnJlbnQgZHJhZnRzIHdlcmUgbGFj a2luZyBndWlkYW5jZSByZWdhcmRpbmcgdGhlIHdheSB0byBkZXNpZ24gTFNBcyB0aGF0IHdlcmUg dG8gZGVwaWN0IGFuIFdTT04gbm9kZSB3aXRoIE9FT3MuDQo+Pj4+Pj4+IFRoaXMgc2VjdGlvbiAz IHByb3ZpZGVzIGFkZGl0aW9uYWwgbWF0ZXJpYWwgdG8gaGVscCBkZXNpZ25pbmcgdGhlIExTQS4N Cj4+Pj4+Pj4gSSB3b3VsZCBsaWtlIHRvIGtub3cgd2hldGhlciBhdXRob3JzIGFyZSB3aWxsaW5n IHRvIHB1cnN1ZSBmdXJ0aGVyIGluIHRoaXMgZGlyZWN0aW9uLCB3aGljaCBpcyB0byBteSBtaW5k IGEgcmVhbCBjb3JuZXIgc3RvbmUsIHRoYXQgd291bGQgaGVscCBldmVyeW9uZSBhZ3JlZSBvbiBh IHNvbHV0aW9uLg0KPj4+Pj4+PiBBIGZpcnN0IHBvaW50IGNvdWxkIGNvbmNlcm4gdGhlIFJlc291 cmNlIEJsb2NrIEluZm9ybWF0aW9uIChyZW1pbmRlcjo8UmVzb3VyY2VCbG9ja0luZm8+ICAgIDo6 PSAoWzxSZXNvdXJjZVNldD5dPElucHV0Q29uc3RyYWludHM+ICAgIDxQcm9jZXNzaW5nQ2FwYWJp bGl0aWVzPiAgICA8T3V0cHV0Q29uc3RyYWludHM+KToNCj4+Pj4+Pj4gICAgIFdlIGFsbCBhZ3Jl ZSB0aGF0IHRoZXNlIGluZm9ybWF0aW9uIGFyZSBzdGF0aWMsIHRoYXQgd2Ugc2hvdWxkIG5vdCBy ZXBsaWNhdGUgdGhpcyBUTFYgd2hhdGV2ZXIgdGhlIG51bWJlciBub3QgdGhlIGxheW91dCBvZiBP RU8gYm9hcmRzIG9mIGEgZ2l2ZW4gdHlwZS4NCj4+Pj4+Pj4gVGhlbiwgd2UgY291bGQgZGVkaWNh dGUgYSBzcGVjaWZpYyBpbmRlcGVuZGFudCBmbG9vZGluZyBlbnRpdHkuIFRoaXMgd291bGQgYmUg ZGVmaW5lZCBvbmNlIGZvciBhbGwsIGFuZCB0aGF0IHdvdWxkIG5vdCBsZWF2ZSByb29tIHRvIGRp ZmZlcmVudCBpbnRlcnByZXRhdGlvbnMuDQo+Pj4+Pj4+IFdoYXQgYWJvdXQgdGhpcyBmaXJzdCBw b2ludD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gWU9VTkc+PiAgICBJZiBJIHVuZGVyc3RhbmQgeW91IGNv cnJlY3RseSwgd2hhdCB5b3UgYXJlIHNheWluZyBpcyBzaW5jZSB0aGUgUmVzb3VyY2UgQmxvY2sg SW5mbyBzdWItVExWIGlzIHZlcnkgc3RhdGljIGluIG5hdHVyZSwgYWR2ZXJ0aXNlbWVudCBvZiB0 aGlzIHN1Yi1UTFYgc2hvdWxkIGJlIHRyZWF0ZWQgZGlmZmVyZW50bHkgZnJvbSB0aGUgcmVzdCBv ZiBzdGF0aWMtVExWcyAod2hpY2ggbWF5IGNoYW5nZSBvdmVyIHRpbWUpLiBJcyB0aGlzIHdoYXQg eW91IGFyZSBzYXlpbmc/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IElmIG15IGludGVycHJldGF0aW9uIG9m IHlvdXIgY29tbWVudCBpcyBjb3JyZWN0LA0KPj4+Pj4+Pg0KPj4+Pj4+PiAtIFRoZSBjdXJyZW50 IG1lY2hhbmlzbSBhbGxvd3Mgd2hhdCB5b3Ugd2FudDogUGxlYXNlIHNlZSB0aGUgZmlyc3QgcGFy YWdyYXBoIGluIFNlY3Rpb24gMy4yDQo+Pj4+Pj4+ICAgIkluIHRoZSBoaWdobHkgdW5saWtlbHkg ZXZlbnQgdGhhdCBhIFdTT04gc3ViLVRMViBieSBpdHNlbGYgd291bGQNCj4+Pj4+Pj4gICByZXN1 bHQgaW4gYW4gTFNBIGV4Y2VlZGluZyB0aGUgTVRVLCBhbGwgZml2ZSBXU09OIHNwZWNpZmljIHN1 Yi1UTFZzDQo+Pj4+Pj4+ICAgaW4gdGhpcyBkb2N1bWVudCBwcm92aWRlIG1lY2hhbmlzbXMgdGhh dCBhbGxvdyB0aGVtIHRvIGJlIHN1YmRpdmlkZWQNCj4+Pj4+Pj4gICBpbnRvIHNtYWxsZXIgc3Vi LVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBzZXBhcmF0ZSBPU1BGIFRFIExTQXMuIg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBBY2NvcmRpbmcgdG8gdGhpcyBjbGF1c2UsIHlvdSBjYW4gc2VwYXJhdGUgdGhl IFJlc291cmNlIEJsb2NrIEluZm8gU3ViLVRMViBhcyB0aGUgc29sZSBlbnRyeSBkZWZpbmVkIGlu IHRoZSBPcHRpY2FsIE5vZGUgcHJvcGVydHkgVExWIGluIGEgc2VwYXJhdGUgVEUgTFNBIGZyb20g dGhlIHJlc3QgaWYgeW91IHdpbGwuIE5vdGhpbmcgcHJldmVudHMgdGhpcyBwYXJ0aWN1bGFyIHdh eSBvZiBwYWNrYWdpbmcuIChJc24ndCB0aGlzIHdoYXQgeW91IG1lYW50ICJhIHNwZWNpZmljIGlu ZGVwZW5kZW50IGZsb29kaW5nIGVudGl0eSI/KQ0KPj4+Pj4+Pg0KPj4+Pj4+PiAtIFBsZWFzZSBs ZXQgbWUga25vdyBpZiB0aGlzIGV4cGxhbmF0aW9uIHNhdGlzZmllcyB5b3UuIFRoYW5rcyAtLS0g WW91bmcNCj4+Pj4+Pj4NCj4+Pj4+Pj4gUmVnYXJkcywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gUGllcnJl DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+Pj4+PiBE ZSA6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn XSBEZSBsYSBwYXJ0IGRlIExlZXlvdW5nIEVudm95w6kgOiBqZXVkaSAxNSBzZXB0ZW1icmUgMjAx MSAyMTo1OSDDgCA6IGNjYW1wQGlldGYub3JnIE9iamV0IDogUmU6IFtDQ0FNUF0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0 DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhpIGFsbCwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWZ0ZXIgMDUgdmVy c2lvbiBwdWJsaWNhdGlvbiwgQWNlZSBwcm92aWRlZCBhIG51bWJlciBvZiB2YWx1YWJsZSBjb21t ZW50cyBhbmQgc3VnZ2VzdGlvbnMuIFRoaXMgcmV2aXNpb24gKDA2KSByZWZsZWN0cyB0aG9zZSBj aGFuZ2VzLiBQbGVhc2Ugbm90ZSB0aGUgZm9sbG93aW5nIHVwZGF0ZXM6DQo+Pj4+Pj4+DQo+Pj4+ Pj4+IC0gQ2hhbmdlIHRoZSB0aXRsZSBvZiB0aGUgZHJhZnQgdG8gIkdNUExTIE9TUEYgRW5oYW5j ZW1lbnQuLi4iIGZyb20gIk9TUEYgRW5oYW5jZW1lbnQuLi4iIHRvIG1ha2Ugc3VyZSB0aGUgY2hh bmdlcyBhcHBseSB0byB0aGUgR01QTFMgT1NQRiByYXRoZXIgdGhhbiB0aGUgYmFzZSBPU1BGLg0K Pj4+Pj4+Pg0KPj4+Pj4+PiAtIEFkZCBzcGVjaWZpYyBPU1BGIHByb2NlZHVyZXMgb24gaG93IHN1 Yi1UTFZzIGFyZSBwYWNrYWdlZCBwZXIgW1JGQzM2MzBdIGFuZCBlZGl0b3JpYWwgY2hhbmdlIGlu Y2x1ZGluZyBhdm9pZGluZyAibXVsdGlwbGUgaW5zdGFuY2VzIG9mIFRFIExTQSIgdG8gIm11bHRp cGxlIFRFIExTQXMiLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBZb3VyIGNvbW1lbnRzIGFyZSBhbHdheXMg YXBwcmVjaWF0ZWQuIFRoYW5rcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQmVzdCBSZWdhcmRzLg0KPj4+ Pj4+PiBZb3VuZw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zw0KPj4+Pj4+PiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDE1LCAyMDExIDI6NDggUE0NCj4+ Pj4+Pj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPj4+Pj4+PiBDYzogY2NhbXBAaWV0Zi5v cmcNCj4+Pj4+Pj4gU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1w LXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNi50eHQNCj4+Pj4+Pj4NCj4+Pj4+Pj4g QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBD b21tb24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICBUaXRsZSAgICAgICAgICAgOiBHTVBMUyBPU1BGIEVu aGFuY2VtZW50IGZvciBTaWduYWwgYW5kIE5ldHdvcmsgRWxlbWVudCBDb21wYXRpYmlsaXR5IGZv ciBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MNCj4+Pj4+Pj4gICBBdXRob3Io cykgICAgICAgOiBZb3VuZyBMZWUNCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIEdy ZWcgTS4gQmVybnN0ZWluDQo+Pj4+Pj4+ICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1j Y2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0DQo+Pj4+Pj4+ICAgUGFn ZXMgICAgICAgICAgIDogMTQNCj4+Pj4+Pj4gICBEYXRlICAgICAgICAgICAgOiAyMDExLTA5LTE1 DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBHTVBMUyBPU1BGIHJv dXRpbmcgZW5oYW5jZW1lbnRzIHRvIHN1cHBvcnQNCj4+Pj4+Pj4gICBzaWduYWwgY29tcGF0aWJp bGl0eSBjb25zdHJhaW50cyBhc3NvY2lhdGVkIHdpdGggV1NPTiBuZXR3b3JrDQo+Pj4+Pj4+ICAg ZWxlbWVudHMuIFRoZXNlIHJvdXRpbmcgZW5oYW5jZW1lbnRzIGFyZSByZXF1aXJlZCBpbiBjb21t b24gb3B0aWNhbA0KPj4+Pj4+PiAgIG9yIGh5YnJpZCBlbGVjdHJvLW9wdGljYWwgbmV0d29ya3Mg d2hlcmUgbm90IGFsbCBvZiB0aGUgb3B0aWNhbA0KPj4+Pj4+PiAgIHNpZ25hbHMgaW4gdGhlIG5l dHdvcmsgYXJlIGNvbXBhdGlibGUgd2l0aCBhbGwgbmV0d29yayBlbGVtZW50cw0KPj4+Pj4+PiAg IHBhcnRpY2lwYXRpbmcgaW4gdGhlIG5ldHdvcmsuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgVGhpcyBj b21wYXRpYmlsaXR5IGNvbnN0cmFpbnQgbW9kZWwgaXMgYXBwbGljYWJsZSB0byBjb21tb24gb3B0 aWNhbA0KPj4+Pj4+PiAgIG9yIGh5YnJpZCBlbGVjdHJvIG9wdGljYWwgc3lzdGVtcyBzdWNoIGFz IE9FTyBzd2l0Y2hlcywgcmVnZW5lcmF0b3JzLA0KPj4+Pj4+PiAgIGFuZCB3YXZlbGVuZ3RoIGNv bnZlcnRlcnMgc2luY2Ugc3VjaCBzeXN0ZW1zIGNhbiBiZSBsaW1pdGVkIHRvDQo+Pj4+Pj4+ICAg cHJvY2Vzc2luZyBvbmx5IGNlcnRhaW4gdHlwZXMgb2YgV1NPTiBzaWduYWxzLg0KPj4+Pj4+Pg0K Pj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBp czoNCj4+Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDYudHh0DQo+Pj4+Pj4+DQo+ Pj4+Pj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj4+Pj4+Pj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0Og0KPj4+ Pj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAt d3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA2LnR4dA0KPj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBDQ0FNUCBtYWls aW5nIGxpc3QNCj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QN Cj4+Pj4+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4g Q0NBTVBAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jY2FtcA0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4g LS0NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4+PiBBbmRyZWEgWmFuYXJkaQ0KPj4+Pj4gQ1JFQVRFLU5FVA0KPj4+Pj4g RW5naW5lZXJpbmcmICBGYXN0IFByb3RvdHlwaW5nIChFTkdJTkUpIEFyZWENCj4+Pj4+IFNlbmlv ciBFbmdpbmVlcg0KPj4+Pj4gVmlhIGFsbGEgQ2FzY2F0YSA1Ni9EIC0gMzgxMjMgUG92byBUcmVu dG8gKEl0YWx5KQ0KPj4+Pj4gZS1tYWlsOiBhbmRyZWEuemFuYXJkaUBjcmVhdGUtbmV0Lm9yZw0K Pj4+Pj4gVGVsOiAoKzM5KSAwNDYxIDQwODQwMCAtIGludGVybm8vZXh0ZW5zaW9uIDE0MDcNCj4+ Pj4+IE1vYmlsZTogKCszOSkgMzQwIDAwMTE4MzcNCj4+Pj4+IEZheDogKCszOSkgMDQ2MSA0MjEx NTcNCj4+Pj4+IFNreXBlOiB6YW5hcmRpX2FuZHJlYQ0KPj4+Pj4gd3d3LmNyZWF0ZS1uZXQub3Jn DQo+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4+Pj4NCj4+Pj4+IFRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRl bmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0bw0KPj4+Pj4gd2hpY2ggaXQgaXMg YWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQN Cj4+Pj4+IG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlv biBvciBvdGhlciB1c2Ugb2YsIG9yDQo+Pj4+PiB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxp YW5jZSB1cG9uLCB0aGlzIGluZm9ybWF0aW9uIGJ5IHBlcnNvbnMgb3INCj4+Pj4+IGVudGl0aWVz IG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkIGFjY29yZGlu ZyB0byB0aGUNCj4+Pj4+IEl0YWxpYW4gTGF3IDE5Ni8yMDAzIG9mIHRoZSBMZWdpc2xhdHVyZS4g SWYgeW91IHJlY2VpdmVkIHRoaXMgaW4gZXJyb3IsDQo+Pj4+PiBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhlIG1hdGVyaWFsIGZyb20gYW55IGNvbXB1dGVyLg0KPj4+Pj4N Cj4+Pj4+IExlIGluZm9ybWF6aW9uaSBjb250ZW51dGUgaW4gcXVlc3RvIG1lc3NhZ2dpbyBkaSBw b3N0YSBlbGV0dHJvbmljYSBlIG5laQ0KPj4+Pj4gZmlsZSBhbGxlZ2F0aSBzb25vIGRhIGNvbnNp ZGVyYXJzaSBzdHJldHRhbWVudGUgcmlzZXJ2YXRlLiBJbCBsb3JvIHV0aWxpenpvDQo+Pj4+PiBl JyBjb25zZW50aXRvIGVzY2x1c2l2YW1lbnRlIGFsIGRlc3RpbmF0YXJpbyBkZWwgbWVzc2FnZ2lv LCBwZXIgbGUgZmluYWxpdGEnDQo+Pj4+PiBpbmRpY2F0ZSBuZWwgbWVzc2FnZ2lvIHN0ZXNzby4g UXVhbG9yYSByaWNldmVzdGUgcXVlc3RvIG1lc3NhZ2dpbyBzZW56YQ0KPj4+Pj4gZXNzZXJuZSBp bCBkZXN0aW5hdGFyaW8sIFZpIHByZWdoaWFtbyBjb3J0ZXNlbWVudGUgZGkgZGFyY2VuZSBub3Rp emlhIHZpYQ0KPj4+Pj4gZS1tYWlsIGUgZGkgcHJvY2VkZXJlIGFsbGEgY2FuY2VsbGF6aW9uZSBk ZWwgbWVzc2FnZ2lvIHN0ZXNzbyBkYWwgVm9zdHJvDQo+Pj4+PiBzaXN0ZW1hLiBUcmF0dGVuZXJl IGlsIG1lc3NhZ2dpbyBzdGVzc28sIGRpdnVsZ2FybG8gYW5jaGUgaW4gcGFydGUsDQo+Pj4+PiBk aXN0cmlidWlybG8gYWQgYWx0cmkgc29nZ2V0dGksIGNvcGlhcmxvLCBvZCB1dGlsaXp6YXJsbyBw ZXIgZmluYWxpdGEnDQo+Pj4+PiBkaXZlcnNlLCBjb3N0aXR1aXNjZSBjb21wb3J0YW1lbnRvIGNv bnRyYXJpbyBhaSBwcmluY2lwaSBkZXR0YXRpIGRhbCBELiBMZ3MuDQo+Pj4+PiAxOTYvMjAwMy4N Cj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+Pj4+PiBDQ0FNUEBpZXRmLm9yZw0KPj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+Pg0KPj4+ Pg0KPj4+DQo+Pj4NCj4+PiAtLQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4gQW5kcmVhIFphbmFyZGkNCj4+PiBDUkVBVEUt TkVUDQo+Pj4gRW5naW5lZXJpbmcgJiBGYXN0IFByb3RvdHlwaW5nIChFTkdJTkUpIEFyZWENCj4+ PiBTZW5pb3IgRW5naW5lZXINCj4+PiBWaWEgYWxsYSBDYXNjYXRhIDU2L0QgLSAzODEyMyBQb3Zv IFRyZW50byAoSXRhbHkpDQo+Pj4gZS1tYWlsOiBhbmRyZWEuemFuYXJkaUBjcmVhdGUtbmV0Lm9y Zw0KPj4+IFRlbDogKCszOSkgMDQ2MSA0MDg0MDAgLSBpbnRlcm5vL2V4dGVuc2lvbiAxNDA3DQo+ Pj4gTW9iaWxlOiAoKzM5KSAzNDAgMDAxMTgzNw0KPj4+IEZheDogKCszOSkgMDQ2MSA0MjExNTcN Cj4+PiBTa3lwZTogemFuYXJkaV9hbmRyZWENCj4+PiB3d3cuY3JlYXRlLW5ldC5vcmcNCj4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+DQo+Pj4gVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlzIGludGVuZGVkIG9ubHkgZm9y IHRoZSBwZXJzb24gb3IgZW50aXR5IHRvDQo+Pj4gd2hpY2ggaXQgaXMgYWRkcmVzc2VkIGFuZCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQNCj4+PiBtYXRlcmlhbC4g QW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRpb24gb3Igb3RoZXIgdXNlIG9m LCBvcg0KPj4+IHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIHRoaXMgaW5m b3JtYXRpb24gYnkgcGVyc29ucyBvcg0KPj4+IGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGludGVu ZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkIGFjY29yZGluZyB0byB0aGUNCj4+PiBJdGFsaWFu IExhdyAxOTYvMjAwMyBvZiB0aGUgTGVnaXNsYXR1cmUuIElmIHlvdSByZWNlaXZlZCB0aGlzIGlu IGVycm9yLA0KPj4+IHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWF0 ZXJpYWwgZnJvbSBhbnkgY29tcHV0ZXIuDQo+Pj4NCj4+PiBMZSBpbmZvcm1hemlvbmkgY29udGVu dXRlIGluIHF1ZXN0byBtZXNzYWdnaW8gZGkgcG9zdGEgZWxldHRyb25pY2EgZSBuZWkNCj4+PiBm aWxlIGFsbGVnYXRpIHNvbm8gZGEgY29uc2lkZXJhcnNpIHN0cmV0dGFtZW50ZSByaXNlcnZhdGUu IElsIGxvcm8gdXRpbGl6em8NCj4+PiBlJyBjb25zZW50aXRvIGVzY2x1c2l2YW1lbnRlIGFsIGRl c3RpbmF0YXJpbyBkZWwgbWVzc2FnZ2lvLCBwZXIgbGUgZmluYWxpdGEnDQo+Pj4gaW5kaWNhdGUg bmVsIG1lc3NhZ2dpbyBzdGVzc28uIFF1YWxvcmEgcmljZXZlc3RlIHF1ZXN0byBtZXNzYWdnaW8g c2VuemENCj4+PiBlc3Nlcm5lIGlsIGRlc3RpbmF0YXJpbywgVmkgcHJlZ2hpYW1vIGNvcnRlc2Vt ZW50ZSBkaSBkYXJjZW5lIG5vdGl6aWEgdmlhDQo+Pj4gZS1tYWlsIGUgZGkgcHJvY2VkZXJlIGFs bGEgY2FuY2VsbGF6aW9uZSBkZWwgbWVzc2FnZ2lvIHN0ZXNzbyBkYWwgVm9zdHJvDQo+Pj4gc2lz dGVtYS4gVHJhdHRlbmVyZSBpbCBtZXNzYWdnaW8gc3Rlc3NvLCBkaXZ1bGdhcmxvIGFuY2hlIGlu IHBhcnRlLA0KPj4+IGRpc3RyaWJ1aXJsbyBhZCBhbHRyaSBzb2dnZXR0aSwgY29waWFybG8sIG9k IHV0aWxpenphcmxvIHBlciBmaW5hbGl0YScNCj4+PiBkaXZlcnNlLCBjb3N0aXR1aXNjZSBjb21w b3J0YW1lbnRvIGNvbnRyYXJpbyBhaSBwcmluY2lwaSBkZXR0YXRpIGRhbCBELiBMZ3MuDQo+Pj4g MTk2LzIwMDMuDQo+Pj4NCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KVGhpcyBl LW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyBDT05GSURFTlRJQUwgYW5kIHdoaWNoIG1heSBiZSBw cm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFu c21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBm YXgsIGFuZCB0aGVuIGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4N Cg0K From acee.lindem@ericsson.com Wed Nov 16 06:00:53 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266EE21F96BB for ; Wed, 16 Nov 2011 06:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioU5RYobzPjE for ; Wed, 16 Nov 2011 06:00:51 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E60EF21F96B9 for ; Wed, 16 Nov 2011 06:00:50 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAGE0Smm014775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2011 08:00:34 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.218]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 16 Nov 2011 09:00:31 -0500 From: Acee Lindem To: Leeyoung Date: Wed, 16 Nov 2011 09:00:28 -0500 Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Thread-Index: AcykaBo7AIonBMoLSrGPH8883GkyxQ== Message-ID: References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817E6BF@DFWEML501-MBX.china.huawei.com> <4E89C332.6020005@create-net.org> <7AEB3D6833318045B4AE71C2C87E8E171817E996@DFWEML501-MBX.china.huawei.com> <4E8B13C1.9030606@create-net.org> <2A9BEA32-6464-4FCE-BD30-3C8B2ECBB5C6@ericsson.com> <4E8B5888.70903@create-net.org> <0A1ED180-1DE9-4192-A90A-A9F492C02B52@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E17181832B9@DFWEML501-MBX.china.huawei.com> <24F96376-DCCF-49F3-A06B-48D1841427F4@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E1718192CB8@dfweml501-mbx> <9C659714-D3B5-4EAC-B5B7-24823253FFBA@ecitele.com> <7AEB3D6833318045B4AE71C2C87E8E1718192DEB@dfweml501-mbx> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718192DEB@dfweml501-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-79--452555180"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:00:53 -0000 --Apple-Mail-79--452555180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Young, Dirk,=20 On Nov 16, 2011, at 12:15 AM, Leeyoung wrote: > Hi Dirk, >=20 > Thanks for your reply. I think this issue is not unique to this = particular case as this is a well-known technique in OSPF. If there is = legitimate security issue associated with IP fragmentation/reassembly, = this needs to be addressed in OSPF in general. >=20 > Hi Acee, >=20 > What is your take on this security issue? The rumors of OSPF security problems due to LSAs requiring IP = fragmentation/reassembly are greatly exaggerated ;^)=20 On a more serious note, the overhead and likelihood of OSPF = retransmissions is increased when IP fragmentation/reassembly is = necessary. Hence, you want to avoid it in the normal case.=20 Thanks, Acee=20 >=20 > Thanks. > Young >=20 > -----Original Message----- > From: Dirk Schroetter [mailto:Dirk.Schroetter@ecitele.com] > Sent: Tuesday, November 15, 2011 11:03 PM > To: Leeyoung > Cc: Acee Lindem; ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >=20 > Hi Young, >=20 > While not opposed to the idea, wouldn't that give raise to security = concerns for IPv4 and a dependency on the operation of ICMPv6 for IPv6 = networks ? I am not a security expert, but I think we should get a view = from the security experts on that matter. >=20 > Cheers, >=20 > /Dirk >=20 > Sent from a mobile device. Please excuse any spelling errors. >=20 > Am 16.11.2011 um 10:01 schrieb "Leeyoung" : >=20 >> Hi, >>=20 >> After talking to Lou and based on Acee's previous email on the issue = on how resolve if the Optical Node Property TLV exceeds the IP MTU = fragmentation limit (1500 bytes), I have the following suggestion. If = this is reasonable, we will update the draft; otherwise, please voice = out in the list. >>=20 >> - I suggest the rule specified (using multiple TE LSA's into which = sub-TLV's are broken) in the current draft (Section 3) to be removed. >>=20 >> Current rule specifies in a rare case where the TE-LSA containing the = Optical Node Property TLV (in which we specified 5 sub-TLVs) exceeds the = IP MTU fragmentation limit, then it will be broken into five multiple = TE-LSA's in which each TE-LSA contains a sub-TLV (See Section 3.1 for = this in the current draft). >>=20 >> Instead of breaking up, what Acee suggested in the attached previous = email was: we can rely on IP fragmentation/reassembly capability in case = the LSA needs to be broken up. >>=20 >> The rational for this suggestion is four folds: >> - Optical Node Property TLV will not exceed the IP MTU limit in a = normal node configuration. >> - Splitting information across multiple LSAs will result in some = added complexity. >> - IP fragmentation/reassembly can be used as a last resort, which is = an acceptable method. >> - This is consistent with the resolution made in the parallel draft = (OPSF extension for general constraint, Fatai's). >>=20 >> Thanks. >>=20 >> Young >>=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, October 28, 2011 4:19 PM >> To: Leeyoung >> Cc: Andrea Zanardi; ccamp@ietf.org >> Subject: Re: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>=20 >> Hi Young, >>=20 >> On Oct 27, 2011, at 9:46 AM, Leeyoung wrote: >>=20 >>> Hi Andrea and Acee, >>>=20 >>> What I am proposing is this: >>>=20 >>> In Section 2, we have the following statement: >>>=20 >>> All sub-TLVs defined here may occur at most once in any given = Optical >>> Node TLV. These restrictions need not apply to future sub-TLVs. >>> Unrecognized sub-TLVs are ignored. >>>=20 >>> I will change the above statement to the following: >>>=20 >>> All sub-TLVs defined here may occur at most once in any given = Optical >>> Node TLV. "At most once" means that if there is sub-TLV related = information, >>> it will be always included. These restrictions need not apply to = future >>> sub-TLVs. Unrecognized sub-TLVs are ignored. >>>=20 >>> This statement assures that all the related sub-TLVs are always = included in any given >>> Optical Node TLV leaving no room not to include such sub-TLVs in the = Optical >>> Node TLV. >>>=20 >>> In Section 3.2, we have the following statement: >>>=20 >>> In the highly unlikely event that a WSON sub-TLV by itself would >>> result in an LSA exceeding the MTU, all five WSON specific sub-TLVs >>> in this document provide mechanisms that allow them to be subdivided >>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. >>>=20 >>> I will change the above statement to the following: >>>=20 >>> In the highly unlikely event that a WSON sub-TLV by itself would >>> result in an LSA exceeding the MTU, all five WSON specific sub-TLVs >>> in this document provide mechanisms that allow them to be subdivided >>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. >>>=20 >>> What is suggested as below is the only option allowed when dividing = up >>> the current set of sub-TLVs into separate OSPF TE LSAs. This means >>> each sub-TLV will be packaged as the sole element in an OSPF TE LSA >>> with a unique LSA instance number. When such division is = implemented, then >>> the source node must flush the existing LSA (i.e., the original OSPF >>> TE LSA with all sub-TLV's packaged together as described in Section = 2). >>> This will avoid duplicating the same information being advertised = across >>> multiple LSAs. >>=20 >> s/LSA instance number/Link State ID/ >>=20 >> So, it is not expected that a sub-TLV will exceed the IP MTU and, if = it does, we simply rely on IP fragmentation/reassembly as we do in = situations where the Router-LSAs and many interfaces in a single area. = Correct? >>=20 >> Thanks, >> Acee >>=20 >>>=20 >>> Please let me know if these texts will remove any ambiguity of the = current >>> Texts. >>>=20 >>> Best Regards, >>> Young >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Monday, October 10, 2011 9:18 AM >>> To: Andrea Zanardi >>> Cc: Leeyoung; ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>=20 >>> Hi Andrea, >>> On Oct 4, 2011, at 3:03 PM, Andrea Zanardi wrote: >>>=20 >>>> Hi Acee, >>>>=20 >>>> On 10/04/2011 07:03 PM, Acee Lindem wrote: >>>>> Hi Andrea, >>>>>=20 >>>>> On Oct 4, 2011, at 10:10 AM, Andrea Zanardi wrote: >>>> .... >>>>>=20 >>>>>>=20 >>>>>> My point is in avoiding ambiguities: if the support for multiple = LSA instances for the >>>>>> same entity top TLV is requested, it should be explicitly stated = as mandatory >>>>>> (possibly providing explicit rules for the subdivision, as in = Chap. 3 of the draft). >>>>>=20 >>>>> There are not multiple instances of the same LSA. Rather they are = unique LSAs, >>>>> as identified by the (Type, Link State ID, Advertising Router) = tuple. >>>>> In this case, they have different Link State IDs. >>>>> One thing that is confusing is that RFC 3630 refers to the portion = of the Link State ID >>>>> providing uniqueness as "Instance". >>>>> Also note that = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt doesn't include = any >>>>> additions to the Link TLV so I'm not sure why you are citing it in = discussions of the new top-level TLVs. >>>>=20 >>>> I was replying to Young email providing the Link TLV and >>>> RFC 3630 as an example of the usage of multiple LSAs and of >>>> sending LSA updates with missing sub-TLVs; >>>> I was discussing about the correctness of the example, >>>> that's why I was citing the Link TLV. >>>=20 >>> Ok. >>>=20 >>>>=20 >>>> The usage of the word "instance" is probably not correct. >>>>=20 >>>> What I meant by "multiple LSA instances" was different LSAs (with = distinct LS ID >>>> and both present in the TE DB at the same time) describing the same = entity >>>> (e.g. the same link by including the same Link Type / Link ID = sub-TLVs) >>>> each one providing a subset of the information (e.g. a subset of = the other sub-TLVs). >>>>=20 >>>> Considering the draft TLVs, this should be the case of Chap. 3.2.1 = "Sub-Division by Options", e.g.: >>>> two LSAs with a Resource Block Information sub-TLV with the same RB = Set Field >>>> and different sub-sets of optional sub-sub-TLVs. >>>>=20 >>>> To avoid ambiguities, it should be clear that the options described = in Chap. 3 >>>> are the only options and that, even if they "can" be used when = generating >>>> the LSAs, they "must" all be supported when receiving and 'using' = the LSAs. >>>=20 >>> Agreed. Splitting information across multiple LSAs will result in = some added complexity. >>> For TLVs or sub-TLVs that are required for a single WSON = computation, the WSON path computation must concatenate them when doing = that computation. >>> Today, multiple OSPFv3 Router-LSAs may be originated and = implementation MUST use the concatenation when doing the OSPFv3 SPF = computation. >>>=20 >>> Thanks, >>> Acee >>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>> Andrea >>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Andrea >>>>>>=20 >>>>>> On 10/03/2011 09:34 PM, Leeyoung wrote: >>>>>>> Hi Andrea, >>>>>>>=20 >>>>>>> Thanks for your interest and input to this issue. >>>>>>>=20 >>>>>>> My overall point was that the current GMPLS TE LSA (per RFC = 3630) does not specify detail implementations as to how to divide up the = TE Link TLVs into static vs. dynamic nor how to use multiple TE LSAs. = The current WSON document follows a similar document philosophy with the = GMPLS predecessor. >>>>>>>=20 >>>>>>> Regarding your point on how the TE DB works in regard to missing = sub-TLVs are deleted seems to me a particular implementation, which is = most simplistic in nature. >>>>>>>=20 >>>>>>> Best Regards, >>>>>>> Young >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On = Behalf Of Andrea Zanardi >>>>>>> Sent: Monday, October 03, 2011 9:14 AM >>>>>>> To: Leeyoung >>>>>>> Cc: ccamp@ietf.org >>>>>>> Subject: Re: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>=20 >>>>>>> Hi Young, >>>>>>>=20 >>>>>>> I was following the discussion and I have a doubt about >>>>>>> your example related to the TE Link TLV. >>>>>>>=20 >>>>>>> It's true that the attributes sub-TLV are not mandatory per RFC = 3630, >>>>>>> but I don't think that means that they can be not included in an = LSA update >>>>>>> if unchanged (implying that the previous value persists). >>>>>>>=20 >>>>>>> As for my understanding of how OSPF-TE works, the managed TE DB = entity is the LSA. >>>>>>> When an LSA update is processed, the previous version is deleted = from the TE DB >>>>>>> and it is replaced by the new one: link attributes related to = missing sub-TLV are >>>>>>> deleted, so they must be present even if unchanged. >>>>>>>=20 >>>>>>> In theory, the set of link attributes could be statically = divided >>>>>>> in two different LSAs instances (updated independently), >>>>>>> but I don't think current implementations handle this scenario >>>>>>> (also because, in my opinion, it's not suggested by RFC 3630 and >>>>>>> it gives no rule on how to divide them). >>>>>>>=20 >>>>>>> But I ask to the mailing list if this is the correct = interpretation. >>>>>>>=20 >>>>>>> Regards, >>>>>>> Andrea >>>>>>>=20 >>>>>>> On 09/30/2011 11:16 PM, Leeyoung wrote: >>>>>>>> Hi Pierre, >>>>>>>>=20 >>>>>>>> I got your point. Let me ask you this question. In the current = GMPLS OSPF TE Link TLV are defined under Opaque TE LSA with the = following attributes: >>>>>>>>=20 >>>>>>>> - TE Metric >>>>>>>> - max B/W >>>>>>>> - max reservable b/w >>>>>>>> - unreserved b/w >>>>>>>> - Admin Group >>>>>>>> - Link Protection Type >>>>>>>> - SRLG >>>>>>>> - ISCD >>>>>>>> - etc. >>>>>>>>=20 >>>>>>>> And these are a mixture of static and dynamic information and = yet they are assembled together as one TE Link TLV. For instance the = ISCD is quite similar to Resource Block Info in that it does not change = often unless there are new elements added in the node or configuration = changes and yet it is packaged together with other dynamic information. >>>>>>>>=20 >>>>>>>> Why? >>>>>>>>=20 >>>>>>>> There are many ways to keep static/unchanged information from = being flooded. Only the Link Type and Link ID which are mandatory in the = TE Link TLV per RFC3630. All other sub-TLV are optional and may occur at = most once (when there are enough changes from the previous period that = deserve an update) and need not be included in the TE Link TLV when = there is no need for updating. >>>>>>>>=20 >>>>>>>> I really don't see the need for a separate top-level TLV and/or = a separate LSA for the Resource Block information. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Young >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: PELOSO, PIERRE (PIERRE) = [mailto:pierre.peloso@alcatel-lucent.com] >>>>>>>> Sent: Friday, September 30, 2011 9:39 AM >>>>>>>> To: Leeyoung; ccamp@ietf.org >>>>>>>> Subject: RE: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi Young, >>>>>>>>=20 >>>>>>>> I understand the content of your answer, but I'm not satisfied = with it. >>>>>>>> My concern deals with providing a unique reading/interpretation = of the OSPF-TE extensions. >>>>>>>> We would like to make sure that any implementation complying to = the drafts would provide the same LSAs when applied to the same network. >>>>>>>> With this perspective in mind, we wish to get drafts with = sufficient documentation to make sure the LSA design process to be = depicted, by design rules. >>>>>>>>=20 >>>>>>>> Hence the content of your answer leaving me the "opportunity to = do as I wish", is not pleasing me, I would rather have strict rules, and = discussions with the WG on the design of those. >>>>>>>> That is why a first design rule, we could agree on is: to = gather the Resource Block Information TLVs inside a dedicated LSA, = possibly with a dedicated top-level TLV (which in my mind allows to = enforce this design rule). >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> - Pierre >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : Leeyoung [mailto:leeyoung@huawei.com] >>>>>>>> Envoy=E9 : mercredi 28 septembre 2011 00:06 >>>>>>>> =C0 : PELOSO, PIERRE (PIERRE); ccamp@ietf.org >>>>>>>> Objet : RE: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi Pierre, >>>>>>>>=20 >>>>>>>> Please see-inline for my reply to your first point. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Young >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: PELOSO, PIERRE (PIERRE) = [mailto:pierre.peloso@alcatel-lucent.com] >>>>>>>> Sent: Tuesday, September 27, 2011 3:28 AM >>>>>>>> To: Leeyoung; ccamp@ietf.org >>>>>>>> Subject: RE: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi Young, and CCAMPers, >>>>>>>>=20 >>>>>>>> I was off the mailing lists for the last two weeks and being = back I notice a lot of exchanges, which I'm very glad of. >>>>>>>> I've also noticed many drafts have been updated. >>>>>>>> Concerning this specific = draft-ietf-ccamp-wson-signal-compatibility-ospf-06, I wanted to comment = section 3. >>>>>>>> Back in Quebec, I expressed my point of view (shared with = Cyril, Julien and Giovanni) that current drafts were lacking guidance = regarding the way to design LSAs that were to depict an WSON node with = OEOs. >>>>>>>> This section 3 provides additional material to help designing = the LSA. >>>>>>>> I would like to know whether authors are willing to pursue = further in this direction, which is to my mind a real corner stone, that = would help everyone agree on a solution. >>>>>>>> A first point could concern the Resource Block Information = (reminder: ::=3D = ([] = ): >>>>>>>> We all agree that these information are static, that we = should not replicate this TLV whatever the number not the layout of OEO = boards of a given type. >>>>>>>> Then, we could dedicate a specific independant flooding entity. = This would be defined once for all, and that would not leave room to = different interpretations. >>>>>>>> What about this first point? >>>>>>>>=20 >>>>>>>> YOUNG>> If I understand you correctly, what you are saying = is since the Resource Block Info sub-TLV is very static in nature, = advertisement of this sub-TLV should be treated differently from the = rest of static-TLVs (which may change over time). Is this what you are = saying? >>>>>>>>=20 >>>>>>>> If my interpretation of your comment is correct, >>>>>>>>=20 >>>>>>>> - The current mechanism allows what you want: Please see the = first paragraph in Section 3.2 >>>>>>>> "In the highly unlikely event that a WSON sub-TLV by itself = would >>>>>>>> result in an LSA exceeding the MTU, all five WSON specific = sub-TLVs >>>>>>>> in this document provide mechanisms that allow them to be = subdivided >>>>>>>> into smaller sub-TLVs that can be sent in separate OSPF TE = LSAs." >>>>>>>>=20 >>>>>>>> According to this clause, you can separate the Resource Block = Info Sub-TLV as the sole entry defined in the Optical Node property TLV = in a separate TE LSA from the rest if you will. Nothing prevents this = particular way of packaging. (Isn't this what you meant "a specific = independent flooding entity"?) >>>>>>>>=20 >>>>>>>> - Please let me know if this explanation satisfies you. Thanks = --- Young >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Pierre >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De = la part de Leeyoung Envoy=E9 : jeudi 15 septembre 2011 21:59 =C0 : = ccamp@ietf.org Objet : Re: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> After 05 version publication, Acee provided a number of = valuable comments and suggestions. This revision (06) reflects those = changes. Please note the following updates: >>>>>>>>=20 >>>>>>>> - Change the title of the draft to "GMPLS OSPF Enhancement..." = from "OSPF Enhancement..." to make sure the changes apply to the GMPLS = OSPF rather than the base OSPF. >>>>>>>>=20 >>>>>>>> - Add specific OSPF procedures on how sub-TLVs are packaged per = [RFC3630] and editorial change including avoiding "multiple instances of = TE LSA" to "multiple TE LSAs". >>>>>>>>=20 >>>>>>>> Your comments are always appreciated. Thanks. >>>>>>>>=20 >>>>>>>> Best Regards. >>>>>>>> Young >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On = Behalf Of internet-drafts@ietf.org >>>>>>>> Sent: Thursday, September 15, 2011 2:48 PM >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: ccamp@ietf.org >>>>>>>> Subject: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the Common = Control and Measurement Plane Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : GMPLS OSPF Enhancement for Signal and = Network Element Compatibility for Wavelength Switched Optical Networks >>>>>>>> Author(s) : Young Lee >>>>>>>> Greg M. Bernstein >>>>>>>> Filename : = draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>> Pages : 14 >>>>>>>> Date : 2011-09-15 >>>>>>>>=20 >>>>>>>> This document provides GMPLS OSPF routing enhancements to = support >>>>>>>> signal compatibility constraints associated with WSON network >>>>>>>> elements. These routing enhancements are required in common = optical >>>>>>>> or hybrid electro-optical networks where not all of the = optical >>>>>>>> signals in the network are compatible with all network = elements >>>>>>>> participating in the network. >>>>>>>>=20 >>>>>>>> This compatibility constraint model is applicable to common = optical >>>>>>>> or hybrid electro optical systems such as OEO switches, = regenerators, >>>>>>>> and wavelength converters since such systems can be limited to >>>>>>>> processing only certain types of WSON signals. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibi= lity-ospf-06.txt >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil= ity-ospf-06.txt >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> -------------------------------------------------------- >>>>>> Andrea Zanardi >>>>>> CREATE-NET >>>>>> Engineering& Fast Prototyping (ENGINE) Area >>>>>> Senior Engineer >>>>>> Via alla Cascata 56/D - 38123 Povo Trento (Italy) >>>>>> e-mail: andrea.zanardi@create-net.org >>>>>> Tel: (+39) 0461 408400 - interno/extension 1407 >>>>>> Mobile: (+39) 340 0011837 >>>>>> Fax: (+39) 0461 421157 >>>>>> Skype: zanardi_andrea >>>>>> www.create-net.org >>>>>> -------------------------------------------------------- >>>>>>=20 >>>>>> The information transmitted is intended only for the person or = entity to >>>>>> which it is addressed and may contain confidential and/or = privileged >>>>>> material. Any review, retransmission, dissemination or other use = of, or >>>>>> taking of any action in reliance upon, this information by = persons or >>>>>> entities other than the intended recipient is prohibited = according to the >>>>>> Italian Law 196/2003 of the Legislature. If you received this in = error, >>>>>> please contact the sender and delete the material from any = computer. >>>>>>=20 >>>>>> Le informazioni contenute in questo messaggio di posta = elettronica e nei >>>>>> file allegati sono da considerarsi strettamente riservate. Il = loro utilizzo >>>>>> e' consentito esclusivamente al destinatario del messaggio, per = le finalita' >>>>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio = senza >>>>>> esserne il destinatario, Vi preghiamo cortesemente di darcene = notizia via >>>>>> e-mail e di procedere alla cancellazione del messaggio stesso dal = Vostro >>>>>> sistema. Trattenere il messaggio stesso, divulgarlo anche in = parte, >>>>>> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per = finalita' >>>>>> diverse, costituisce comportamento contrario ai principi dettati = dal D. Lgs. >>>>>> 196/2003. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> -------------------------------------------------------- >>>> Andrea Zanardi >>>> CREATE-NET >>>> Engineering & Fast Prototyping (ENGINE) Area >>>> Senior Engineer >>>> Via alla Cascata 56/D - 38123 Povo Trento (Italy) >>>> e-mail: andrea.zanardi@create-net.org >>>> Tel: (+39) 0461 408400 - interno/extension 1407 >>>> Mobile: (+39) 340 0011837 >>>> Fax: (+39) 0461 421157 >>>> Skype: zanardi_andrea >>>> www.create-net.org >>>> -------------------------------------------------------- >>>>=20 >>>> The information transmitted is intended only for the person or = entity to >>>> which it is addressed and may contain confidential and/or = privileged >>>> material. Any review, retransmission, dissemination or other use = of, or >>>> taking of any action in reliance upon, this information by persons = or >>>> entities other than the intended recipient is prohibited according = to the >>>> Italian Law 196/2003 of the Legislature. If you received this in = error, >>>> please contact the sender and delete the material from any = computer. >>>>=20 >>>> Le informazioni contenute in questo messaggio di posta elettronica = e nei >>>> file allegati sono da considerarsi strettamente riservate. Il loro = utilizzo >>>> e' consentito esclusivamente al destinatario del messaggio, per le = finalita' >>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio = senza >>>> esserne il destinatario, Vi preghiamo cortesemente di darcene = notizia via >>>> e-mail e di procedere alla cancellazione del messaggio stesso dal = Vostro >>>> sistema. Trattenere il messaggio stesso, divulgarlo anche in parte, >>>> distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per = finalita' >>>> diverse, costituisce comportamento contrario ai principi dettati = dal D. Lgs. >>>> 196/2003. >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 --Apple-Mail-79--452555180 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTExNjE0MDAyOFowIwYJKoZI hvcNAQkEMRYEFKXtD86tStwzHhRMnl62S6cmnu/cMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgIkGBpF3ScZKtIxiQaMTOThGs36z3oZgIEnZdkSZRg8Yjscw3ZH/hgc0Gi+46eWh iAiDH30YcIgJpRW5OM75dSTNGh/C7vFp6wsqaI/83ECV6Ij0txBUAHDvq01pcDyCGZWWMYd8ISdc BbLcg8m54k9ac+TysJDIuI8mCxqYYl99AAAAAAAA --Apple-Mail-79--452555180-- From leeyoung@huawei.com Wed Nov 16 17:37:36 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4211E8099 for ; Wed, 16 Nov 2011 17:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMD0fr5F9djw for ; Wed, 16 Nov 2011 17:37:34 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 62F0611E8082 for ; Wed, 16 Nov 2011 17:37:34 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS00FXM76IB1@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 16 Nov 2011 19:37:30 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS0052K76HQU@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 16 Nov 2011 19:37:30 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 16 Nov 2011 17:37:24 -0800 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 16 Nov 2011 17:37:20 -0800 Date: Thu, 17 Nov 2011 01:37:19 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.47.131.62] To: Acee Lindem Message-id: <7AEB3D6833318045B4AE71C2C87E8E17181930CF@dfweml501-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Thread-index: AQHMgdbfKpRl3bOBbUOtD09rA557ZpVq9kGggAG6D4CAADBlgIAAIZkAgAkeIYCAGi/wgIACj6sAgBwax+CAAMG8gP//e6wggAEaZgCAADq0cA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817E6BF@DFWEML501-MBX.china.huawei.com> <4E89C332.6020005@create-net.org> <7AEB3D6833318045B4AE71C2C87E8E171817E996@DFWEML501-MBX.china.huawei.com> <4E8B13C1.9030606@create-net.org> <2A9BEA32-6464-4FCE-BD30-3C8B2ECBB5C6@ericsson.com> <4E8B5888.70903@create-net.org> <0A1ED180-1DE9-4192-A90A-A9F492C02B52@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E17181832B9@DFWEML501-MBX.china.huawei.com> <24F96376-DCCF-49F3-A06B-48D1841427F4@ericsson.com> <7AEB3D6833318045B4AE71C2C87E8E1718192CB8@dfweml501-mbx> <9C659714-D3B5-4EAC-B5B7-24823253FFBA@ecitele.com> <7AEB3D6833318045B4AE71C2C87E8E1718192DEB@dfweml501-mbx> Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:37:36 -0000 Hi Acee, Thanks for your input. Regarding your comment on the overhead increase asso= ciated with OSPF retransmission when IP fragmentation/reassembly takes plac= e, we don't foresee the need for IP fragmentation/reassembly in the normal = case.=20 Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= cee Lindem Sent: Wednesday, November 16, 2011 8:00 AM To: Leeyoung Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility= -ospf-06.txt Hi Young, Dirk,=20 On Nov 16, 2011, at 12:15 AM, Leeyoung wrote: > Hi Dirk, >=20 > Thanks for your reply. I think this issue is not unique to this particula= r case as this is a well-known technique in OSPF. If there is legitimate se= curity issue associated with IP fragmentation/reassembly, this needs to be = addressed in OSPF in general. >=20 > Hi Acee, >=20 > What is your take on this security issue? The rumors of OSPF security problems due to LSAs requiring IP fragmentation= /reassembly are greatly exaggerated ;^)=20 On a more serious note, the overhead and likelihood of OSPF retransmissions= is increased when IP fragmentation/reassembly is necessary. Hence, you wan= t to avoid it in the normal case.=20 Thanks, Acee=20 >=20 > Thanks. > Young >=20 > -----Original Message----- > From: Dirk Schroetter [mailto:Dirk.Schroetter@ecitele.com] > Sent: Tuesday, November 15, 2011 11:03 PM > To: Leeyoung > Cc: Acee Lindem; ccamp@ietf.org > Subject: Re: [CCAMP] I-D Action:=20 > draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >=20 > Hi Young, >=20 > While not opposed to the idea, wouldn't that give raise to security conce= rns for IPv4 and a dependency on the operation of ICMPv6 for IPv6 networks = ? I am not a security expert, but I think we should get a view from the sec= urity experts on that matter. >=20 > Cheers, >=20 > /Dirk >=20 > Sent from a mobile device. Please excuse any spelling errors. >=20 > Am 16.11.2011 um 10:01 schrieb "Leeyoung" : >=20 >> Hi, >>=20 >> After talking to Lou and based on Acee's previous email on the issue on = how resolve if the Optical Node Property TLV exceeds the IP MTU fragmentati= on limit (1500 bytes), I have the following suggestion. If this is reasonab= le, we will update the draft; otherwise, please voice out in the list. >>=20 >> - I suggest the rule specified (using multiple TE LSA's into which sub-T= LV's are broken) in the current draft (Section 3) to be removed. >>=20 >> Current rule specifies in a rare case where the TE-LSA containing the Op= tical Node Property TLV (in which we specified 5 sub-TLVs) exceeds the IP M= TU fragmentation limit, then it will be broken into five multiple TE-LSA's = in which each TE-LSA contains a sub-TLV (See Section 3.1 for this in the cu= rrent draft). >>=20 >> Instead of breaking up, what Acee suggested in the attached previous ema= il was: we can rely on IP fragmentation/reassembly capability in case the L= SA needs to be broken up. >>=20 >> The rational for this suggestion is four folds: >> - Optical Node Property TLV will not exceed the IP MTU limit in a normal= node configuration. >> - Splitting information across multiple LSAs will result in some added c= omplexity. >> - IP fragmentation/reassembly can be used as a last resort, which is an = acceptable method. >> - This is consistent with the resolution made in the parallel draft (OPS= F extension for general constraint, Fatai's). >>=20 >> Thanks. >>=20 >> Young >>=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >> Sent: Friday, October 28, 2011 4:19 PM >> To: Leeyoung >> Cc: Andrea Zanardi; ccamp@ietf.org >> Subject: Re: [CCAMP] I-D Action:=20 >> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>=20 >> Hi Young, >>=20 >> On Oct 27, 2011, at 9:46 AM, Leeyoung wrote: >>=20 >>> Hi Andrea and Acee, >>>=20 >>> What I am proposing is this: >>>=20 >>> In Section 2, we have the following statement: >>>=20 >>> All sub-TLVs defined here may occur at most once in any given=20 >>> Optical Node TLV. These restrictions need not apply to future sub-TLVs. >>> Unrecognized sub-TLVs are ignored. >>>=20 >>> I will change the above statement to the following: >>>=20 >>> All sub-TLVs defined here may occur at most once in any given=20 >>> Optical Node TLV. "At most once" means that if there is sub-TLV=20 >>> related information, it will be always included. These restrictions=20 >>> need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored. >>>=20 >>> This statement assures that all the related sub-TLVs are always=20 >>> included in any given Optical Node TLV leaving no room not to=20 >>> include such sub-TLVs in the Optical Node TLV. >>>=20 >>> In Section 3.2, we have the following statement: >>>=20 >>> In the highly unlikely event that a WSON sub-TLV by itself would=20 >>> result in an LSA exceeding the MTU, all five WSON specific sub-TLVs=20 >>> in this document provide mechanisms that allow them to be subdivided=20 >>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. >>>=20 >>> I will change the above statement to the following: >>>=20 >>> In the highly unlikely event that a WSON sub-TLV by itself would=20 >>> result in an LSA exceeding the MTU, all five WSON specific sub-TLVs=20 >>> in this document provide mechanisms that allow them to be subdivided=20 >>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. >>>=20 >>> What is suggested as below is the only option allowed when dividing=20 >>> up the current set of sub-TLVs into separate OSPF TE LSAs. This=20 >>> means each sub-TLV will be packaged as the sole element in an OSPF=20 >>> TE LSA with a unique LSA instance number. When such division is=20 >>> implemented, then the source node must flush the existing LSA (i.e.,=20 >>> the original OSPF TE LSA with all sub-TLV's packaged together as descri= bed in Section 2). >>> This will avoid duplicating the same information being advertised=20 >>> across multiple LSAs. >>=20 >> s/LSA instance number/Link State ID/ >>=20 >> So, it is not expected that a sub-TLV will exceed the IP MTU and, if it = does, we simply rely on IP fragmentation/reassembly as we do in situations = where the Router-LSAs and many interfaces in a single area. Correct? >>=20 >> Thanks, >> Acee >>=20 >>>=20 >>> Please let me know if these texts will remove any ambiguity of the=20 >>> current Texts. >>>=20 >>> Best Regards, >>> Young >>> -----Original Message----- >>> From: Acee Lindem [mailto:acee.lindem@ericsson.com] >>> Sent: Monday, October 10, 2011 9:18 AM >>> To: Andrea Zanardi >>> Cc: Leeyoung; ccamp@ietf.org >>> Subject: Re: [CCAMP] I-D Action:=20 >>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>=20 >>> Hi Andrea, >>> On Oct 4, 2011, at 3:03 PM, Andrea Zanardi wrote: >>>=20 >>>> Hi Acee, >>>>=20 >>>> On 10/04/2011 07:03 PM, Acee Lindem wrote: >>>>> Hi Andrea, >>>>>=20 >>>>> On Oct 4, 2011, at 10:10 AM, Andrea Zanardi wrote: >>>> .... >>>>>=20 >>>>>>=20 >>>>>> My point is in avoiding ambiguities: if the support for multiple=20 >>>>>> LSA instances for the same entity top TLV is requested, it should=20 >>>>>> be explicitly stated as mandatory (possibly providing explicit rules= for the subdivision, as in Chap. 3 of the draft). >>>>>=20 >>>>> There are not multiple instances of the same LSA. Rather they are=20 >>>>> unique LSAs, as identified by the (Type, Link State ID, Advertising R= outer) tuple. >>>>> In this case, they have different Link State IDs. >>>>> One thing that is confusing is that RFC 3630 refers to the portion=20 >>>>> of the Link State ID providing uniqueness as "Instance". >>>>> Also note that=20 >>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt doesn't includ= e any additions to the Link TLV so I'm not sure why you are citing it in di= scussions of the new top-level TLVs. >>>>=20 >>>> I was replying to Young email providing the Link TLV and RFC 3630=20 >>>> as an example of the usage of multiple LSAs and of sending LSA=20 >>>> updates with missing sub-TLVs; I was discussing about the=20 >>>> correctness of the example, that's why I was citing the Link TLV. >>>=20 >>> Ok. >>>=20 >>>>=20 >>>> The usage of the word "instance" is probably not correct. >>>>=20 >>>> What I meant by "multiple LSA instances" was different LSAs (with=20 >>>> distinct LS ID and both present in the TE DB at the same time)=20 >>>> describing the same entity (e.g. the same link by including the=20 >>>> same Link Type / Link ID sub-TLVs) each one providing a subset of the = information (e.g. a subset of the other sub-TLVs). >>>>=20 >>>> Considering the draft TLVs, this should be the case of Chap. 3.2.1 "Su= b-Division by Options", e.g.: >>>> two LSAs with a Resource Block Information sub-TLV with the same RB=20 >>>> Set Field and different sub-sets of optional sub-sub-TLVs. >>>>=20 >>>> To avoid ambiguities, it should be clear that the options described=20 >>>> in Chap. 3 are the only options and that, even if they "can" be=20 >>>> used when generating the LSAs, they "must" all be supported when recei= ving and 'using' the LSAs. >>>=20 >>> Agreed. Splitting information across multiple LSAs will result in some = added complexity. >>> For TLVs or sub-TLVs that are required for a single WSON computation, t= he WSON path computation must concatenate them when doing that computation. >>> Today, multiple OSPFv3 Router-LSAs may be originated and implementation= MUST use the concatenation when doing the OSPFv3 SPF computation. >>>=20 >>> Thanks, >>> Acee >>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>> Andrea >>>>=20 >>>>> Thanks, >>>>> Acee >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, >>>>>> Andrea >>>>>>=20 >>>>>> On 10/03/2011 09:34 PM, Leeyoung wrote: >>>>>>> Hi Andrea, >>>>>>>=20 >>>>>>> Thanks for your interest and input to this issue. >>>>>>>=20 >>>>>>> My overall point was that the current GMPLS TE LSA (per RFC 3630) d= oes not specify detail implementations as to how to divide up the TE Link T= LVs into static vs. dynamic nor how to use multiple TE LSAs. The current WS= ON document follows a similar document philosophy with the GMPLS predecesso= r. >>>>>>>=20 >>>>>>> Regarding your point on how the TE DB works in regard to missing su= b-TLVs are deleted seems to me a particular implementation, which is most s= implistic in nature. >>>>>>>=20 >>>>>>> Best Regards, >>>>>>> Young >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>>>> Behalf Of Andrea Zanardi >>>>>>> Sent: Monday, October 03, 2011 9:14 AM >>>>>>> To: Leeyoung >>>>>>> Cc: ccamp@ietf.org >>>>>>> Subject: Re: [CCAMP] I-D Action:=20 >>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>=20 >>>>>>> Hi Young, >>>>>>>=20 >>>>>>> I was following the discussion and I have a doubt about your=20 >>>>>>> example related to the TE Link TLV. >>>>>>>=20 >>>>>>> It's true that the attributes sub-TLV are not mandatory per RFC=20 >>>>>>> 3630, but I don't think that means that they can be not included=20 >>>>>>> in an LSA update if unchanged (implying that the previous value per= sists). >>>>>>>=20 >>>>>>> As for my understanding of how OSPF-TE works, the managed TE DB ent= ity is the LSA. >>>>>>> When an LSA update is processed, the previous version is deleted=20 >>>>>>> from the TE DB and it is replaced by the new one: link=20 >>>>>>> attributes related to missing sub-TLV are deleted, so they must be = present even if unchanged. >>>>>>>=20 >>>>>>> In theory, the set of link attributes could be statically=20 >>>>>>> divided in two different LSAs instances (updated independently),=20 >>>>>>> but I don't think current implementations handle this scenario=20 >>>>>>> (also because, in my opinion, it's not suggested by RFC 3630 and=20 >>>>>>> it gives no rule on how to divide them). >>>>>>>=20 >>>>>>> But I ask to the mailing list if this is the correct interpretation= . >>>>>>>=20 >>>>>>> Regards, >>>>>>> Andrea >>>>>>>=20 >>>>>>> On 09/30/2011 11:16 PM, Leeyoung wrote: >>>>>>>> Hi Pierre, >>>>>>>>=20 >>>>>>>> I got your point. Let me ask you this question. In the current GMP= LS OSPF TE Link TLV are defined under Opaque TE LSA with the following attr= ibutes: >>>>>>>>=20 >>>>>>>> - TE Metric >>>>>>>> - max B/W >>>>>>>> - max reservable b/w >>>>>>>> - unreserved b/w >>>>>>>> - Admin Group >>>>>>>> - Link Protection Type >>>>>>>> - SRLG >>>>>>>> - ISCD >>>>>>>> - etc. >>>>>>>>=20 >>>>>>>> And these are a mixture of static and dynamic information and yet = they are assembled together as one TE Link TLV. For instance the ISCD is qu= ite similar to Resource Block Info in that it does not change often unless = there are new elements added in the node or configuration changes and yet i= t is packaged together with other dynamic information. >>>>>>>>=20 >>>>>>>> Why? >>>>>>>>=20 >>>>>>>> There are many ways to keep static/unchanged information from bein= g flooded. Only the Link Type and Link ID which are mandatory in the TE Lin= k TLV per RFC3630. All other sub-TLV are optional and may occur at most onc= e (when there are enough changes from the previous period that deserve an u= pdate) and need not be included in the TE Link TLV when there is no need fo= r updating. >>>>>>>>=20 >>>>>>>> I really don't see the need for a separate top-level TLV and/or a = separate LSA for the Resource Block information. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Young >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: PELOSO, PIERRE (PIERRE)=20 >>>>>>>> [mailto:pierre.peloso@alcatel-lucent.com] >>>>>>>> Sent: Friday, September 30, 2011 9:39 AM >>>>>>>> To: Leeyoung; ccamp@ietf.org >>>>>>>> Subject: RE: [CCAMP] I-D Action:=20 >>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi Young, >>>>>>>>=20 >>>>>>>> I understand the content of your answer, but I'm not satisfied wit= h it. >>>>>>>> My concern deals with providing a unique reading/interpretation of= the OSPF-TE extensions. >>>>>>>> We would like to make sure that any implementation complying to th= e drafts would provide the same LSAs when applied to the same network. >>>>>>>> With this perspective in mind, we wish to get drafts with sufficie= nt documentation to make sure the LSA design process to be depicted, by des= ign rules. >>>>>>>>=20 >>>>>>>> Hence the content of your answer leaving me the "opportunity to do= as I wish", is not pleasing me, I would rather have strict rules, and disc= ussions with the WG on the design of those. >>>>>>>> That is why a first design rule, we could agree on is: to gather t= he Resource Block Information TLVs inside a dedicated LSA, possibly with a = dedicated top-level TLV (which in my mind allows to enforce this design rul= e). >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> - Pierre >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : Leeyoung [mailto:leeyoung@huawei.com] Envoy=E9 : mercredi 28= =20 >>>>>>>> septembre 2011 00:06 =C0 : PELOSO, PIERRE (PIERRE);=20 >>>>>>>> ccamp@ietf.org Objet : RE: [CCAMP] I-D Action:=20 >>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi Pierre, >>>>>>>>=20 >>>>>>>> Please see-inline for my reply to your first point. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Young >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: PELOSO, PIERRE (PIERRE)=20 >>>>>>>> [mailto:pierre.peloso@alcatel-lucent.com] >>>>>>>> Sent: Tuesday, September 27, 2011 3:28 AM >>>>>>>> To: Leeyoung; ccamp@ietf.org >>>>>>>> Subject: RE: [CCAMP] I-D Action:=20 >>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi Young, and CCAMPers, >>>>>>>>=20 >>>>>>>> I was off the mailing lists for the last two weeks and being back = I notice a lot of exchanges, which I'm very glad of. >>>>>>>> I've also noticed many drafts have been updated. >>>>>>>> Concerning this specific draft-ietf-ccamp-wson-signal-compatibilit= y-ospf-06, I wanted to comment section 3. >>>>>>>> Back in Quebec, I expressed my point of view (shared with Cyril, J= ulien and Giovanni) that current drafts were lacking guidance regarding the= way to design LSAs that were to depict an WSON node with OEOs. >>>>>>>> This section 3 provides additional material to help designing the = LSA. >>>>>>>> I would like to know whether authors are willing to pursue further= in this direction, which is to my mind a real corner stone, that would hel= p everyone agree on a solution. >>>>>>>> A first point could concern the Resource Block Information (remind= er: ::=3D ([] ): >>>>>>>> We all agree that these information are static, that we should = not replicate this TLV whatever the number not the layout of OEO boards of = a given type. >>>>>>>> Then, we could dedicate a specific independant flooding entity. Th= is would be defined once for all, and that would not leave room to differen= t interpretations. >>>>>>>> What about this first point? >>>>>>>>=20 >>>>>>>> YOUNG>> If I understand you correctly, what you are saying is s= ince the Resource Block Info sub-TLV is very static in nature, advertisemen= t of this sub-TLV should be treated differently from the rest of static-TLV= s (which may change over time). Is this what you are saying? >>>>>>>>=20 >>>>>>>> If my interpretation of your comment is correct, >>>>>>>>=20 >>>>>>>> - The current mechanism allows what you want: Please see the=20 >>>>>>>> first paragraph in Section 3.2 "In the highly unlikely event=20 >>>>>>>> that a WSON sub-TLV by itself would result in an LSA exceeding=20 >>>>>>>> the MTU, all five WSON specific sub-TLVs in this document=20 >>>>>>>> provide mechanisms that allow them to be subdivided into smaller = sub-TLVs that can be sent in separate OSPF TE LSAs." >>>>>>>>=20 >>>>>>>> According to this clause, you can separate the Resource Block=20 >>>>>>>> Info Sub-TLV as the sole entry defined in the Optical Node=20 >>>>>>>> property TLV in a separate TE LSA from the rest if you will.=20 >>>>>>>> Nothing prevents this particular way of packaging. (Isn't this=20 >>>>>>>> what you meant "a specific independent flooding entity"?) >>>>>>>>=20 >>>>>>>> - Please let me know if this explanation satisfies you. Thanks=20 >>>>>>>> --- Young >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Pierre >>>>>>>>=20 >>>>>>>> -----Message d'origine----- >>>>>>>> De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De=20 >>>>>>>> la part de Leeyoung Envoy=E9 : jeudi 15 septembre 2011 21:59 =C0 := =20 >>>>>>>> ccamp@ietf.org Objet : Re: [CCAMP] I-D Action:=20 >>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Hi all, >>>>>>>>=20 >>>>>>>> After 05 version publication, Acee provided a number of valuable c= omments and suggestions. This revision (06) reflects those changes. Please = note the following updates: >>>>>>>>=20 >>>>>>>> - Change the title of the draft to "GMPLS OSPF Enhancement..." fro= m "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF ra= ther than the base OSPF. >>>>>>>>=20 >>>>>>>> - Add specific OSPF procedures on how sub-TLVs are packaged per [R= FC3630] and editorial change including avoiding "multiple instances of TE L= SA" to "multiple TE LSAs". >>>>>>>>=20 >>>>>>>> Your comments are always appreciated. Thanks. >>>>>>>>=20 >>>>>>>> Best Regards. >>>>>>>> Young >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>>>>> Behalf Of internet-drafts@ietf.org >>>>>>>> Sent: Thursday, September 15, 2011 2:48 PM >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> Cc: ccamp@ietf.org >>>>>>>> Subject: [CCAMP] I-D Action:=20 >>>>>>>> draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts= directories. This draft is a work item of the Common Control and Measureme= nt Plane Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : GMPLS OSPF Enhancement for Signal and Network E= lement Compatibility for Wavelength Switched Optical Networks >>>>>>>> Author(s) : Young Lee >>>>>>>> Greg M. Bernstein >>>>>>>> Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf= -06.txt >>>>>>>> Pages : 14 >>>>>>>> Date : 2011-09-15 >>>>>>>>=20 >>>>>>>> This document provides GMPLS OSPF routing enhancements to=20 >>>>>>>> support signal compatibility constraints associated with WSON=20 >>>>>>>> network elements. These routing enhancements are required in=20 >>>>>>>> common optical or hybrid electro-optical networks where not=20 >>>>>>>> all of the optical signals in the network are compatible with=20 >>>>>>>> all network elements participating in the network. >>>>>>>>=20 >>>>>>>> This compatibility constraint model is applicable to common=20 >>>>>>>> optical or hybrid electro optical systems such as OEO=20 >>>>>>>> switches, regenerators, and wavelength converters since such=20 >>>>>>>> systems can be limited to processing only certain types of WSON s= ignals. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signa >>>>>>>> l-compatibility-ospf-06.txt >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal >>>>>>>> -compatibility-ospf-06.txt=20 >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> -------------------------------------------------------- >>>>>> Andrea Zanardi >>>>>> CREATE-NET >>>>>> Engineering& Fast Prototyping (ENGINE) Area Senior Engineer Via=20 >>>>>> alla Cascata 56/D - 38123 Povo Trento (Italy) >>>>>> e-mail: andrea.zanardi@create-net.org >>>>>> Tel: (+39) 0461 408400 - interno/extension 1407 >>>>>> Mobile: (+39) 340 0011837 >>>>>> Fax: (+39) 0461 421157 >>>>>> Skype: zanardi_andrea >>>>>> www.create-net.org >>>>>> -------------------------------------------------------- >>>>>>=20 >>>>>> The information transmitted is intended only for the person or=20 >>>>>> entity to which it is addressed and may contain confidential=20 >>>>>> and/or privileged material. Any review, retransmission,=20 >>>>>> dissemination or other use of, or taking of any action in=20 >>>>>> reliance upon, this information by persons or entities other than=20 >>>>>> the intended recipient is prohibited according to the Italian Law=20 >>>>>> 196/2003 of the Legislature. If you received this in error, please c= ontact the sender and delete the material from any computer. >>>>>>=20 >>>>>> Le informazioni contenute in questo messaggio di posta=20 >>>>>> elettronica e nei file allegati sono da considerarsi strettamente=20 >>>>>> riservate. Il loro utilizzo e' consentito esclusivamente al destinat= ario del messaggio, per le finalita' >>>>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio=20 >>>>>> senza esserne il destinatario, Vi preghiamo cortesemente di=20 >>>>>> darcene notizia via e-mail e di procedere alla cancellazione del=20 >>>>>> messaggio stesso dal Vostro sistema. Trattenere il messaggio=20 >>>>>> stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, c= opiarlo, od utilizzarlo per finalita' >>>>>> diverse, costituisce comportamento contrario ai principi dettati dal= D. Lgs. >>>>>> 196/2003. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> -------------------------------------------------------- >>>> Andrea Zanardi >>>> CREATE-NET >>>> Engineering & Fast Prototyping (ENGINE) Area Senior Engineer Via=20 >>>> alla Cascata 56/D - 38123 Povo Trento (Italy) >>>> e-mail: andrea.zanardi@create-net.org >>>> Tel: (+39) 0461 408400 - interno/extension 1407 >>>> Mobile: (+39) 340 0011837 >>>> Fax: (+39) 0461 421157 >>>> Skype: zanardi_andrea >>>> www.create-net.org >>>> -------------------------------------------------------- >>>>=20 >>>> The information transmitted is intended only for the person or=20 >>>> entity to which it is addressed and may contain confidential and/or=20 >>>> privileged material. Any review, retransmission, dissemination or=20 >>>> other use of, or taking of any action in reliance upon, this=20 >>>> information by persons or entities other than the intended=20 >>>> recipient is prohibited according to the Italian Law 196/2003 of=20 >>>> the Legislature. If you received this in error, please contact the sen= der and delete the material from any computer. >>>>=20 >>>> Le informazioni contenute in questo messaggio di posta elettronica=20 >>>> e nei file allegati sono da considerarsi strettamente riservate. Il=20 >>>> loro utilizzo e' consentito esclusivamente al destinatario del messagg= io, per le finalita' >>>> indicate nel messaggio stesso. Qualora riceveste questo messaggio=20 >>>> senza esserne il destinatario, Vi preghiamo cortesemente di darcene=20 >>>> notizia via e-mail e di procedere alla cancellazione del messaggio=20 >>>> stesso dal Vostro sistema. Trattenere il messaggio stesso,=20 >>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, o= d utilizzarlo per finalita' >>>> diverse, costituisce comportamento contrario ai principi dettati dal D= . Lgs. >>>> 196/2003. >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. >=20 From loa@pi.nu Wed Nov 16 17:54:09 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BCE1F0C88; Wed, 16 Nov 2011 17:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD9PZl558EGP; Wed, 16 Nov 2011 17:54:03 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5C07D21F85AE; Wed, 16 Nov 2011 17:53:11 -0800 (PST) Received: from [130.129.17.40] (dhcp-1128.meeting.ietf.org [130.129.17.40]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id EA9382A8004; Thu, 17 Nov 2011 02:52:58 +0100 (CET) Message-ID: <4EC468F6.7030904@pi.nu> Date: Thu, 17 Nov 2011 09:52:54 +0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" References: <4EB2C05C.5070809@pi.nu> In-Reply-To: <4EB2C05C.5070809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP , MPLS-TP ad hoc team , pwe3@ietf.org Subject: Re: [CCAMP] mpls wg last call on draft-ietf-mpls-tp-security-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:54:09 -0000 Working Group, this last call has ended. There has been comments. Can the authors work with the commenters to resolve the comments and send a mail to the mpls wg mailing list detailing how the comments has been addressed. /Loa for the mpls wg co-chairs On 2011-11-04 00:25, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-security-framework-02.txt. > > Please review the document and send comments to the mpls working > group mailing list (mpls@ietf.org). > > This working group last call ends on November 16th. > > /Loa > for the mpls wg co-charis > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From lufang@cisco.com Fri Nov 18 03:46:04 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C334E21F8AAC; Fri, 18 Nov 2011 03:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmQ0gM7dnchW; Fri, 18 Nov 2011 03:46:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE521F8AAA; Fri, 18 Nov 2011 03:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lufang@cisco.com; l=1437; q=dns/txt; s=iport; t=1321616761; x=1322826361; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=rUKAEFh4jIpFvy8KpGrnZZbuabwpEL+30U2n3583CwU=; b=mj4/1KyDwAURtiovhTjjTsoFiwVxQhWCgKg7X+iXpHup84+06a4mbZlx vHaVYPo13PLB3dG7iYOFsz7LjxfvkoObCtSPU7F3ikF6ezrBwKiOjlK9o m4EgoYIKyNrYgOAx74zAX8wNRnrP/Sny8MK3GmYPdnWxUCj8XQ9cPat8c 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYAALxExk6tJV2c/2dsb2JhbABCmhGQFIEFgXIBAQEEAQEBDwEdPgsMAgQBCBEEAQEBCgYXAQcaDAEeCQgBAQQBEggah2mYCAGeUwQCiTJjBIdmMYoDh2WMWg X-IronPort-AV: E=Sophos;i="4.69,532,1315180800"; d="scan'208";a="37219326" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 18 Nov 2011 11:46:00 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAIBk0en008661; Fri, 18 Nov 2011 11:46:00 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Nov 2011 05:46:00 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2011 05:45:59 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25AE430E@XMB-RCD-201.cisco.com> In-Reply-To: <4EC468F6.7030904@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [CCAMP] mpls wg last call ondraft-ietf-mpls-tp-security-framework Thread-Index: Acyky9CNdb3Csm4kRSmbE1oEU/1xhABG9NOR From: "Luyuan Fang (lufang)" To: , X-OriginalArrivalTime: 18 Nov 2011 11:46:00.0144 (UTC) FILETIME=[A46B8500:01CCA5E7] Cc: ccamp@ietf.org, ahmpls-tp@lists.itu.int, pwe3@ietf.org Subject: Re: [CCAMP] [mpls] mpls wg last call ondraft-ietf-mpls-tp-security-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 11:46:05 -0000 Loa, Will do.=20 Thx, Luyuan ----- Original Message ----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, November 16, 2011 07:52 PM To: mpls@ietf.org Cc: CCAMP ; MPLS-TP ad hoc team = ; pwe3@ietf.org Subject: Re: [mpls] [CCAMP] mpls wg last call = ondraft-ietf-mpls-tp-security-framework Working Group, this last call has ended. There has been comments. Can the authors work with the commenters to resolve the comments and send a mail to the mpls wg mailing list detailing how the comments has been addressed. /Loa for the mpls wg co-chairs On 2011-11-04 00:25, Loa Andersson wrote: > Working Group, > > this is to start a two week working group last call on > draft-ietf-mpls-tp-security-framework-02.txt. > > Please review the document and send comments to the mpls working > group mailing list (mpls@ietf.org). > > This working group last call ends on November 16th. > > /Loa > for the mpls wg co-charis > > --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From daniele.ceccarelli@ericsson.com Wed Nov 23 10:18:37 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448C021F8B3A for ; Wed, 23 Nov 2011 10:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.054 X-Spam-Level: X-Spam-Status: No, score=-5.054 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, MY_CID_AND_ARIAL2=1.46, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqk7-BUQmSbX for ; Wed, 23 Nov 2011 10:18:36 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A62FA21F8B38 for ; Wed, 23 Nov 2011 10:18:35 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-5b-4ecd38f945fc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C0.FE.09514.9F83DCE4; Wed, 23 Nov 2011 19:18:33 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.32]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 23 Nov 2011 19:18:33 +0100 From: Daniele Ceccarelli To: CCAMP Date: Wed, 23 Nov 2011 19:18:31 +0100 Thread-Topic: OSPF OTN considerations post IETF 82 Thread-Index: AcypvXUM4uURSfqEQWyExafq21g2KwAAy7kQABLVdSA= Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: multipart/related; boundary="_005_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [CCAMP] OSPF OTN considerations post IETF 82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 18:18:37 -0000 --_005_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_ Content-Type: multipart/alternative; boundary="_000_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_" --_000_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMP, During the OTN OSPF draft presentation at the IETF meeting in Taipei two co= mments were raised with respect to the following issues: - Issue 1: Using different switching caps for each ODU type - Issue 2: Type 2 (unres bandwidth for variable containers) and Type 3 (MAX= LSP bandwidth foe variable containers always used in tandem? WRT issue 1: the proposal was to indicate the bottom most ODUk of the muxin= g hiearachy in the Switching Capability field of the ISCD. After a quick ta= lk with the other authors of the ID, the idea was to reject the proposal as= it would lead to an overloading of the meaning of the Switching Capability= field. (even if the definition of PSC1-2-3-4 already overloads the meaning= of the switching capability field) WRT issue 2: it is analyzed in section 5.3 of the draft (version -00). I'm = copying it below for your convenience In this example the advertisement of an ODUflex->ODU3 hierarchy is shown. In case of ODUflex advertisement the MAX LSP bandwidth needs to be advertised but in some cases also information about the Unreserved bandwidth could be useful. The amount of Unreserved bandwidth does not give a clear indication of how many ODUflex LSP can be set up either at the MAX LSP Bandwidth or at different rates, as it gives no information about the spatial allocation of the free TSs. An indication of the amount of Unreserved bandwidth could be useful during the path computation process, as shown in the following example. Supposing there are two TE-links (A and B) with MAX LSP Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex LSPs of 10 GBps each, have to be restored, for sure only one can be restored along Link B and it is probable (but not sure) that two of them can be restored along Link A. Early proposal was to have, in the case of variable containers advertisemen= ts (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as a mandatory piece = of information and the Unreserved bandiwdth TLV (Type 2) as an optional pie= ce of information. The comment received is that optional information can lead to interworking = issues and the counter proposal was to have both pieces of information as m= andatory and, as a consequence, merge the two TLVs into a single one. We'd like to hear the opinion of the WG on both issues before proceeding wi= th any modification to the document. Thanks, Daniele DANIELE CECCARELLI System & Technology - DU IP & Broadband Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com [cid:image002.jpg@01CCA9C9.D9A14FD0] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 CCAMP,

 

During the OTN OSPF draft=20 presentation at the IETF meeting in Taipei two comments were raised with re= spect=20 to the following issues:

 

- Issue 1: Using different sw= itching=20 caps for each ODU type

- Issue 2: Type 2 (unres band= width=20 for variable containers) and Type 3 (MAX LSP bandwidth foe variable contain= ers=20 always used in tandem?

 

WR= T issue=20 1: the proposal was to indicate the bottom most ODUk of the muxing hiearach= y in=20 the Switching Capability field of the ISCD. After a quick talk with the oth= er=20 authors of the ID, the idea was to reject the proposal as it would lead to = an=20 overloading of the meaning of the Switching Capability field. (even if the= =20 definition of PSC1-2-3-4 already overloads the meaning of the switching=20 capability field)

 

WRT issue 2: it is analyzed i= n=20 section 5.3 of the draft (version -00). I'm copying it below for your=20 convenience

 

   In this = example=20 the advertisement of an ODUflex->ODU3 hierarchy is

=

   shown.&n= bsp; In=20 case of ODUflex advertisement the MAX LSP bandwidth needs

=

   to be=20 advertised but in some cases also information about the

=

   Unreserv= ed=20 bandwidth could be useful.  The amount of Unreserved

=

   bandwidt= h does=20 not give a clear indication of how many ODUflex LSP

=

   can be s= et up=20 either at the MAX LSP Bandwidth or at different rates,

=

   as it gi= ves no=20 information about the spatial allocation of the free

=

  =20 TSs.

=

 <= FONT=20 face=3DArial size=3D2>

=

   An indic= ation=20 of the amount of Unreserved bandwidth could be useful

=

   during t= he path=20 computation process, as shown in the following

=

   example.=  =20 Supposing there are two TE-links (A and B) with MAX LSP

=

   Bandwidt= h equal=20 to 10 Gbps each.  In case 50Gbps of Unreserved

=

   Bandwidt= h are=20 available on Link A, 10Gbps on Link B and 3 ODUflex

=

   LSPs of = 10 GBps=20 each, have to be restored, for sure only one can be

=

   restored= along=20 Link B and it is probable (but not sure) that two of

=

   them can= be=20 restored along Link A.

=

 <= FONT=20 face=3DArial size=3D2>

=

Early proposal was to have, i= n the=20 case of variable containers advertisements (i.e. ODUflex), the MAX LSP band= width=20 TLV (Type 3) as a mandatory piece of information and the Unreserved bandiwd= th=20 TLV (Type 2) as an optional piece of=20 information.

The comment received is that= =20 optional information can lead to interworking issues and the counter propos= al=20 was to have both pieces of information as mandatory and, as a consequence, = merge=20 the two TLVs into a single one.

 

We'd like to hear the opinion= of the=20 WG on both issues before proceeding with any modification to the=20 document.

 

Thanks,

Daniele

 




DANIELE C= ECCARELLI=20
System=20 & Technology - DU IP & Broadband

=


Via L.Calda,= =20 5
Genova, Italy
Phone +390106002512
Mobile=20 +393346725750
daniele.ceccarelli@ericsson.com
www.ericsson.com

=



=


This=20 Communication is Confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson= .com/email_disclaimer=20

=

 <= SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">

=

 

--_000_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_-- --_005_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=798; creation-date="Wed, 23 Nov 2011 09:22:49 GMT"; modification-date="Wed, 23 Nov 2011 09:22:49 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAADAP8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0DxiM awTzyg7+1cvJRRXwWN/3yp6sxqFaSqslFFa0Tz6hVkqrJRRXp0jgqFaSqzdaKK9OkefUG0UUV30z EWloortpiCloorupiCloortpgRNUL0UVqbwIHqBqKKR2QIGqB6KKR2QIGqFutFFI7KYoqQUUVjI9 XDkgqQUUVzTPaw5ItSLRRXNI9vDki16n8FEB1XVXyciBB9445Y9unb/OaKK5Zm2Z/wC4VPl+aP/Z --_005_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2695; creation-date="Wed, 23 Nov 2011 09:22:49 GMT"; modification-date="Wed, 23 Nov 2011 09:22:49 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABRAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz6TVN QErj7fdfeP8Ay2b/ABpv9q6h/wA/91/3+b/Gq0v+uf8A3jTK96yPLuy5/amof8/91/3+b/Gj+1NR /wCf+6/7/N/jS6XpV9reoxafp1u091Lnai8cDqSewHrXqehfAu5k2y67qawr1MFoNzfQuePyBrOd SnT+IuEJy2PKv7V1DIH2+6yeAPObn9ac2pamjlHvLxGHVWkYEfga+kbXw74J8CWwuXisrRgP+Pi7 cNI30Lc/lXj/AMVPFWjeKdZtJNHUyLbxsklyU2+YSeAM8kDB596zp1lUlaMdO5c6XJG7epxv9qah /wA/91/3+b/Gj+1NQ/5/7r/v83+NVKK6LIxuz638LMz+EdFZmLMbCAkk5JPlrWtWR4V/5E/RP+vC D/0Wta9eHL4menHZBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+NJf9c/+8abTpf9c/8AvGm1755Ru+DdZ1HQfE9reaVafbLo5iFsFJMgbqBjn3z7V7as fxH8TKPMks/DNm3UIPOuCP5CvFfBXiP/AIRXxRb6obU3ShWiaJfvENx8vvXtS+JfHHiRQNB8PJpN qw/4/NVb5seqxjn864sSnzXSXqzqotctrlux+GvhvTZDqGrvLqt0vLXWqTbwPfB4FeU/Fi78NXWu 2v8Awjwti6Rst09qoEZORtHHBI56V6dF8Mv7SlW48W67fa1IOfIL+VAPoq9vyrzD4r6N4d0XW7SD QRFE5iP2m3hfcsZB+U+xPPHtUYdp1NZNv8CqqahtY4Cloor0DjPrbwr/AMifon/XhB/6LWtesjwr /wAifon/AF4Qf+i1rXrwpfEz1I7IKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHxpL/rX/AN402rNvatfarDZxsFe4nESs3QFmwM/nXWTfDe6j1y20dNZs ZbyeZoSqxyARlVLEkkYI+XHHrXuOcY6M8xRb2M7wHrth4b8XWup6jA0tsispKruMZIwHA74/rXp2 ufHPT4A0eh6fLdv2muP3afl94/pXnz/Dm/EsAi1Kxngnt57iOdN4BEON6lSAQeeDVa48EzWVpbfb dX0+31K6jSWHTXLGVgxwoJAwpOehrGcaNSXMzWLqRVkJrnxC8T+INyXWpyQwN/ywtf3S/jjk/ia5 eu2f4bXg15NGj1aykvQjSXCeXIvkKoBJ5HzjkD5e9VLfwT5/224Ou2EOl2jpE9/Kkiq0jdECEbsj IznpmtIzpxXukOM29TlaK7Kb4Z65BY6xcs9uzaWRvjQljKpUNuQ9xtOfwNc/r+iz+HtYl024ljll jRHLx52kMoYdfrVRqRk7JkuElqz6k8K/8ifon/XhB/6LWtesjwr/AMifon/XhB/6LWtevFl8TPSj sgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfHtpdf YdZt7zZv+z3Cy7M43bWzj9K7y6+KMVxr9lqw0/UCba4afyJr/fH8yMuFXbhfvV51L/rn/wB402vc lTjLVnmRm46I7sfEmSZ7W5v7GS5vobS5s2uDMAZElPy5GOq/rVDU/FOk67BBcarosz6vFAkBuoLs okgXozLjg49K5OkpKlBaoftJPc9AuviJaXSabbmy1UQWLvIk51DN0GIwAJMfdA7HOePSk1H4jWmu G+tdX0RptMuWikWOK42yq8YxuL4w24cGuBopexh2H7WR6BJ8VLxrh7iOwWNzfRXCKsmVEKR+X5R4 5yCeffpXMeK9dXxL4judWS2+zLMqKId27aFUDr+FY1FONKMXdITnKSsz628K/wDIn6J/14Qf+i1r XrI8K/8AIn6J/wBeEH/ota168aXxM9GOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQB8aS/65/wDeNNp0v+tf/eNNr3zygooooAKKKKACkpaKAPrbwr/y J+if9eEH/ota16yPCv8AyJ+if9eEH/ota168KXxM9SOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8kyf61/9402iivbPMCiiigAooooAKDRRQB9R+Gf +RU0f/rxh/8AQBWrRRXiy3Z6S2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2Q== --_005_B5630A95D803744A81C51AD4040A6DAA2293E672A9ESESSCMS0360e_-- From internet-drafts@ietf.org Wed Nov 23 11:38:48 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEFD1F0C82; Wed, 23 Nov 2011 11:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csI6IJ7EJbww; Wed, 23 Nov 2011 11:38:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E119C1F0C46; Wed, 23 Nov 2011 11:38:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111123193847.11469.55407.idtracker@ietfa.amsl.com> Date: Wed, 23 Nov 2011 11:38:47 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-impairments-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:38:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : A Framework for the Control of Wavelength Switched Optic= al Networks (WSON) with Impairments Author(s) : Young Lee Greg M. Bernstein Dan Li Giovanni Martinelli Filename : draft-ietf-ccamp-wson-impairments-08.txt Pages : 31 Date : 2011-11-23 As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios and architectural processes: Routing, Wavelength Assignment, and Impairment Validation. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-08.txt From leeyoung@huawei.com Wed Nov 23 11:45:29 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36621F86DD for ; Wed, 23 Nov 2011 11:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VSmBaRKuQe9 for ; Wed, 23 Nov 2011 11:45:28 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57521F85A8 for ; Wed, 23 Nov 2011 11:45:28 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV4008ONPJPNT@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 23 Nov 2011 13:45:25 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV4008IVPJOI2@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 23 Nov 2011 13:45:25 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Nov 2011 11:45:19 -0800 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 23 Nov 2011 11:45:16 -0800 Date: Wed, 23 Nov 2011 19:45:15 +0000 From: Leeyoung X-Originating-IP: [10.192.11.122] To: "ccamp@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E171819643B@dfweml501-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-impairments-08.txt Thread-index: AQHMqhepBY0q2FIVN0upQDHEyCC90JW626fw X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-impairments-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 19:45:29 -0000 This revision concerns IETF Last Call, reflecting security directorate's comments as well as routing directorate's comments. The routing AD asked to publish revision due to significant changes from the previous version. Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, November 23, 2011 1:39 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-impairments-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments Author(s) : Young Lee Greg M. Bernstein Dan Li Giovanni Martinelli Filename : draft-ietf-ccamp-wson-impairments-08.txt Pages : 31 Date : 2011-11-23 As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios and architectural processes: Routing, Wavelength Assignment, and Impairment Validation. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-08.txt _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Fri Nov 25 00:52:54 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0540F21F8C36 for ; Fri, 25 Nov 2011 00:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.12 X-Spam-Level: X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPfGwQzEZRud for ; Fri, 25 Nov 2011 00:52:52 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3E35D21F8C33 for ; Fri, 25 Nov 2011 00:52:51 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAP8poeX000536 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 25 Nov 2011 09:52:50 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.42]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 25 Nov 2011 09:52:32 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: CCAMP Date: Fri, 25 Nov 2011 09:52:31 +0100 Thread-Topic: Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 Thread-Index: AcyrT5Fr8/K9YKXwSVajMEKWu/H2CQ== Message-ID: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F050945A8D8E9A44A71039532BA344D8191305D4FRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 08:52:54 -0000 --_000_F050945A8D8E9A44A71039532BA344D8191305D4FRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMP, as outcome of the Framework and Information model for G.709 Optical Transpo= rt Networks (OTN) presentation, Lou Berger asked co-authors to provide a n= ew section in the framework document dealing with backward compatibility, a= s summary with respect to what is already present/will be present in the e= ncoding documents. In our opinion, the first thing to do is deciding which are the scenarios t= hat have to be taken into account. As hypothesis we would like to consider network element domains composed e= ither of G.709v1 or G709v3 network elements, so without having a mix of network element in the same domains. The motivat= ion for this is that operators would not be happy with the mix because managing control plane versions imp= lementing very different features is not practical from a network operation point of view. Please note that backward compatibility issues are to be considered between= GMPLS versions. So for G.709v1 NE we mean a network element with G.709v1 HW and support of RFC4328 only. The case of a NE with G709v1 HW supporting our GMPLS drafts does not have b= ackward compatibility issues because it can be considered as a new node wi= th limitations. Said this the candidate scenarios may be: 1) Interworking between a G.709v1 domain with a G.709v3 domain (path is te= rminated by one G.709v1 node and G.709v3 node) 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - G709v= 1 domain (G.709v3 domain in the middle of two G.709v1 domains. The path bei= ng terminated on G.709v1 equipment.) We'd like to hear the opinion of the WG whether CCAMP consider exhaustive t= he type of scenarios proposed, before proceeding with any modification to t= he document. Thanks Sergio and co-authors SERGIO BELOTTI ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio Evolution via Trento 30 , Vimercate(MI) Italy T: +39 0396863033 Sergio.Belotti@alcatel-lucent.com --_000_F050945A8D8E9A44A71039532BA344D8191305D4FRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi CCAMP,
 
as outcome of the Framework and Information model for G.709 Optical Tr= ansport Networks (OTN) presentation, Lou Berger asked co-authors to provid= e a new section in the framework document dealing with backward compatibili= ty, as summary with respect to what is already present/will be present in the  encoding documents.
 
In our opinion, the first thing to do is deciding which are the scenar= ios that have to be taken into account.
 
As hypothesis we would like to consider network element domains  = composed either of G.709v1 or G709v3 network elements,
so without having a mix of network element in the same domains. The mo= tivation for this is that operators
would not be happy with the mix because managing control plane version= s implementing very different features
is not practical from a network operation point of view. 
 
Please note that backward compatibility issues are to be considered be= tween GMPLS versions. So for G.709v1 NE we mean
a network element with G.709v1 HW and support of RFC4328 only.
 
The case of a NE with G709v1 HW supporting our GMPLS drafts does not h= ave backward compatibility issues because it can be considered as a new&nbs= p; node with limitations.
 
Said this the candidate scenarios may be:
 
1)  Interworking between a G.709v1 domain with a G.709v3 domain (= path is terminated by one G.709v1 node and G.709v3  node)
 
2) Interworking in the case of  a G.709v1 domain – a G.709v= 3 domain – G709v1 domain (G.709v3 domain in the middle of two G.709v1= domains. The path being terminated on G.709v1 equipment.)
 
We'd like to hear the opinion of the WG whether CCAMP consider exhaust= ive the type of scenarios proposed, before proceeding with any modification= to the document.
 
Thanks
 
Sergio and co-authors
 
 
SERGIO BELOTTI
 
ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution
 
via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
Sergio.Belotti@alcatel-lucent.com
=  
=  
 
 
  --_000_F050945A8D8E9A44A71039532BA344D8191305D4FRMRSSXCHMBSB1d_-- From cathryn@infc.ulst.ac.uk Fri Nov 25 02:49:09 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD78521F8C44 for ; Fri, 25 Nov 2011 02:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdJv2LTpjEL3 for ; Fri, 25 Nov 2011 02:49:09 -0800 (PST) Received: from e4.ulster.ac.uk (e4.ulster.ac.uk [194.80.87.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1B59321F8C34 for ; Fri, 25 Nov 2011 02:49:08 -0800 (PST) Received: from m0.ulster.ac.uk (m0.ulster.ac.uk [194.80.87.153]) by e4.ulster.ac.uk (UU/BC) with ESMTP id pAPA8nLr012896 for ; Fri, 25 Nov 2011 10:08:49 GMT Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by m0.ulster.ac.uk (UU/BC) with ESMTP id pAPA8nlr023604 for ; Fri, 25 Nov 2011 10:08:49 GMT (envelope-from cathryn@infc.ulst.ac.uk) Received: from localhost (localhost.localdomain [127.0.0.1]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 8B9D33D06B2 for ; Fri, 25 Nov 2011 10:08:49 +0000 (GMT) X-Virus-Scanned: amavisd-new at martello.infc.ulst.ac.uk Received: from martello.infc.ulst.ac.uk ([127.0.0.1]) by localhost (martello.infc.ulst.ac.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPcqFN9RPgZm for ; Fri, 25 Nov 2011 10:08:49 +0000 (GMT) Received: from martello.infc.ulst.ac.uk (martello.infc.ulst.ac.uk [193.61.166.223]) by martello.infc.ulst.ac.uk (Postfix) with ESMTP id 4BF1D3D05BC for ; Fri, 25 Nov 2011 10:08:49 +0000 (GMT) Date: Fri, 25 Nov 2011 10:08:49 +0000 (GMT) From: "Peoples, Cathryn" To: CCAMP@ietf.org Message-ID: <924804935.1661322215729274.JavaMail.root@martello.infc.ulst.ac.uk> In-Reply-To: <1499414012.1201322214986625.JavaMail.root@martello.infc.ulst.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [193.61.166.86] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - SAF3 (Win)/5.0.18_GA_3011.RHEL5_64) Subject: [CCAMP] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 10:49:09 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From adrian@olddog.co.uk Fri Nov 25 11:44:01 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4F21F8B4E for ; Fri, 25 Nov 2011 11:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QVeWi4rBNOY for ; Fri, 25 Nov 2011 11:44:00 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DCF5121F8B4D for ; Fri, 25 Nov 2011 11:43:59 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAPJhvu7016413; Fri, 25 Nov 2011 19:43:58 GMT Received: from 950129200 (82-71-74-86.dsl.in-addr.zen.co.uk [82.71.74.86]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pAPJhtDm016403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Nov 2011 19:43:55 GMT From: "Adrian Farrel" To: Date: Fri, 25 Nov 2011 19:43:53 -0000 Message-ID: <00c301ccabaa$9109cb70$b31d6250$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyrqnJqmPiwZ/8tQDWu9V23lkB3Qg== Content-Language: en-gb Cc: draft-ietf-ccamp-rfc5787bis@tools.ietf.org Subject: [CCAMP] draft-ietf-ccamp-rfc5787bis X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 19:44:02 -0000 Hi, I have done my usual AD review prior to putting the draft forward for IETF last call and IESG review. I have a number of questions and issues that I would like you to address in a new revision. Some of these things are questions that can be handled either by discussion or by making changes to the draft. Other issues are more substantive and will need updates to the document. I have move the draft into Revised I-D needed, and will wait for the new revision. Thanks, Adrian --- If I understand correctly, the intention of this document is to entirely replace (i.e. obsolete) RFC 5787. That's OK, but you need to do several things: 1. State in the document header Obsoletes: 5787 (if approved) 2. Remove "Updates to" and "(RFC 5787bis)" from the document title 3. Add a statement to the Abstract (usually the last sentence) to say "This document obsoletes RFC 5787" 4. Add a final paragraph to summarise why this document obsoletes RFC 5787 and to mention the change to standards track. 5. Include a section called "Changes from RFC 5787" --- Section 2 RAs are hierarchically contained: a higher-level (parent) RA contains lower-level (child) RAs that in turn MAY also contain RAs, etc. Why MAY not may? Why "etc." ? --- Please expand acronyms on first use. For example SCN. --- Section 3 In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, this TE Router Address is referred to as the TE Router ID, which is in the ASON transport plane name space. The TE Router ID should not be confused with the OSPF Router ID which uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name space for control plane components. Note: The Router Address top-level TLV definition, processing, and usage are unchanged from [RFC3630]. This TLV specifies a stable OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node. Note that RFC 3630 does not define a "TE Router Address TLV" You seem to recognize this in the second paragraph. You seem to acknowledge that the Router Address TLV contains a stable OSPF TE node IP address that is always reachable when there is IP connectivity to the associated OSPF TE node. As far as I can tell, this means that the address comes from the SCN space not from the transport name space as you have claimed. It may be that you need or desire some overlap of spaces, but you have not made any statement to that effect. In fact I am surprised that you say that there is a 1:1 correspondence between a transport node and an OSPF TE node. This sounds like an implementation detail unless an OSPF TE node is a logical concept. If it is, it would be really useful to explain it. It does not help that you have not defined "OSPF TE node" and you freely mix that term with the term "OSPF router". It should be clear to you that there are OSPF protocol speakers and there are transport nodes on behalf of which the protocol speakers distribute information. Please have another attempt at this section making clear what the OSPF entities are and how they map to actual things. You obviously did not like the content of Section 5.1 of RFC 5787, but you seem to have thrown out the baby with the bathwater. Furthermore, in Section 6 you have Hence, a single OSPF router (i.e., the PC) MUST be able to advertise on behalf of multiple transport layer nodes. The OSPF routers are identified by OSPF Router ID and the transport nodes are identified by TE Router ID. which is very good, but appear to contradict In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. Probably you intend to say that an ASON transport node is represented by a single OSPF TE node and that an OSPF TE node may represent more than one ASON transport node. You haven't actually excluded that in what you write, but it is not very clear. --- Section 4 Reachability in ASON refers to the set of endpoints reachable in the transport plane by a node or the reachable endpoints of a level N. Can you please rewrite this for clarity. "Reachability" cannot refer to a set of anything per se; it is a quality. The definition also seems circular since you do not define what reachable means. --- Section 4 "(ASON SNPP name space)" What is this? You have already told us that ASON has just three name spaces and this was not one of them. What is SNPP? --- Section 4 You say: The data plane node is identified in the control plane by its TE Router ID, as discussed in section 6. This contradicts what you say in Section 3 where the TE Router ID is an IP reachable address and so is an SCN identifier not a control plane identifier. --- Section 4 As a consequence, it MUST be possible for the router to originate more than one TE LSA containing the Node Attribute TLV when used for ASON reachability advertisement. Hence, the Node Attribute TLV [RFC5786] advertisement rules must be relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE LSA originated by the RC when the RC is advertising reachability information for a different transport node identified by the Local TE Router Sub-TLV (refer to section 6.1). This looks like you are updating RFC 5786. You will need to make this explicit and to assure me that the OSPF working group has signed off on this change. Since you are making the relaxation specific to ASON (or are you making it general?) you will need to explain how a node receiving a second TE LSA containing a node attribute TLV will know that it is an ASON advertisement. --- Section 5.2 GMPLS routing defines an Interface Switching Capability Descriptor (ISCD) that provides, among other things, the available (maximum/minimum) bandwidth per priority available for Label Switched Path (LSPs). - Too many instances of "available" - The ISCD doesn't provide the bandwidth, only the information about the bandwidth --- Section 6 For ASON routing, the control plane component routing adjacency topology (i.e., the associated Protocol Controller (PC) connectivity) and the transport topology are NOT assumed to be congruent [RFC4258]. Lower case "not" please. --- Section 6 The Router Address TLV [RFC3630] is used to advertise the TE Router ID associated with the advertising Routing Controller. TE Router IDs for additional transport nodes are advertised through specification of the Local TE Router Identifier in the Local and Remote TE Router TE sub-TLV and the Local TE Router Identifier sub-TLV described in the sections below. These Local TE Router Identifiers are typically used as the local endpoints for TE Label Switched Paths (LSPs) terminating on the associated transport node. I found this a bit odd. Previously you have said that a TE Router ID is associated with a transport node that it identifies. Now you seem to be saying that a TE Router ID is associated with an RC, and implying that an RC is a transport node (since you say "for additional transport nodes"). --- Section 6 It MAY be feasible for multiple OSPF Routers to advertise TE information for the same transport node. However, this is not considered a required use case and is not discussed further. The use of "MAY" is in the wrong scope. How about... The use of multiple OSPF Routers to advertise TE information for the same transport node is not considered a required use case and is not discussed further in this document. --- Section 6.1 An OSPF router advertising on behalf of multiple transport nodes will require additional information to distinguish the link endpoints amongst the subsumed transport nodes. In order to unambiguously specify the transport topology, the local and remote transport nodes MUST be identified by TE router ID. "subsumed" seems a bit dramatic! How about... When an OSPF Router advertises on behalf of multiple transport nodes, the link end points cannot be automatically assigned to a single transport node associated with the advertising router. In this case, the link advertisement also includes identifiers of the link end points. --- Section 6.1 The Type field of the Local and Remote TE Router ID sub-TLV is assigned the value 26 (see Section 10). AFAICS, no early allocation was performed. Therefore, please replace "26" with TBDx. Similarly in 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (26) | Length (8) | --- Section 6.1 The value of the Local and Remote TE Router Identifier SHOULD NOT be set to 0. This use of "SHOULD NOT" implies that a value of 0 MAY be used for some reason. Please clarify. --- Section 6.1 This section reminds me to ask what plans the WG has to support IPv6. --- Section 6.1 This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV if the OSPF router is advertising on behalf of one or more transport nodes having TE Router IDs different from the TE Router ID advertised in the Router Address TLV. Therefore, it MUST be included if the OSPF router is advertising on behalf of multiple transport nodes. Note: The Link ID sub-TLV identifies the other end of the link (i.e., Router ID of the neighbor for point-to-point links) [RFC3630]. When the Local and Remote TE Router ID Sub-TLV is present, it MUST be used to identify local and remote transport node endpoints for the link and the Link-ID sub-TLV MUST be ignored. The Local and Remote ID sub- TLV, if specified, MUST only be specified once. A lot of "MUST" without explaining what the process is if not. A receiver getting no sub-TLV assumes what? A router advertising on behalf of the transport node with the same TE Router ID MAY / MUST NOT include sub-TLVs. If there is more than one sub-TLV present the receiver should do what? Does "Therefore, it MUST be included if the OSPF router is advertising on behalf of multiple transport nodes" imply the sub-TLV must be included even when the advertisement is for the transport node with the same TE Router ID? --- Section 6.2 Per previous comments on IANA Please change "5" to TBDy in... The Type field of the Local TE Router ID sub-TLV is assigned the value 5 (see Section 10). The Length field takes the value 4. The ...and... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Type (5) | Length (4) | --- Section 6.2 This sub-TLV MUST be included as a sub-TLV of the top-level Node Attribute TLV if the OSPF router is advertising on behalf of one or more transport nodes having TE Router IDs different from the TE Router ID advertised in the Router Address TLV. Therefore, it MUST be included if the OSPF router is advertising on behalf of multiple transport nodes. Similar questions as per 6.1. What can a receiver assume if the sub-TLV is not present? Does the final sentence mean that the sub-TLV must be included even in the case where the advertisement is for the same TE Router ID? Can the sender include the sub-TLV when it only advertises for a single transport node? What if there is more than one sub-TLV present? --- Section 7 An ASON routing area (RA) represents a partition of the data plane, and its identifier is used within the control plane as the representation of this partition. An RA may contain smaller RAs inter-connected by links. ASON RA levels do not map directly to OSPF areas. Rather, hierarchical levels of RAs are represented by separate OSPF protocol instances. It would be interesting to add a statement about the correspondence between RAs and OSPF areas (per section 2). --- Section 7 It isn't clear to me reading this section and the subsections whether export happens at a single node that is present in both parent and child RA, or whether there is an "export interface" between nodes. I would assume that an implementation could place the export within a box, but that there is no architectural constraint. That means that the export function is an exposed function. If so, where is the protocol definition? --- Section 7.2.1 IANA stuff again Please replace: 27 as TBDz1 28 as TBDz2 in... The type value 28 (see Section 10) will indicate that the associated routing information has been exported downward. The type value 27 (see Section 10) will indicate that the associated routing information has been exported upward. and in... The Type field of the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs are respectively assigned the values 27 and 28 (see Section 10). and... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upward/Downward Type (27/28) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- Section 7.2.2 When exporting routing information upward in the ASON routing hierarchy, any information received from a level above, i.e., tagged with an Inter-RA Export Downward Sub-TLV, MUST NOT be exported upward. Since an RA at level N is contained by a single RA at level N+1, this is the only checking that is necessary and the associated RA ID is used solely for informational purposes. Agreed. And what should the receiver do if it receives such an export? Ditto for In order words, routing information MUST NOT be exported downward into the RA from which it was received. --- Section 8 The extensions described herein are only applicable to ASON routing domains and it is not expected that the attendant reachability (see Section 4) and link information will ever be mixed with global or local IP routing information. I am not quite sure what you mean by "mixed" or by "local IP routing information". You may be saying that you expect (require?) that TE information s exchanged in a separate instance of OSPF than is used for exchanging SCN routing information. If that is what you are hoping for, I expect you will be sadly disappointed by the entire deployed GMPLS base. For a single RA it makes complete sense to run just one instance of OSPF that exchanges information about SCN IP reachability and also transport plane TE info. It gets more complicated with a multi-RA system, and you need to address that. --- Section 8 You give some good advice, but you do it with nested 2119 language. I don't know how to interpret "You SHOULD apply a MUST". Additionally, since you say "SHOULD", you need to explain what the associated MAY condition is. --- Section 9 Here is an attack vector... Suppose a small child RA is infiltrated. A very large (unmanageably large) number of LSAs are exported to the parent. This may swamp the parent making it impossible for it to function. Additionally, the parent may export all the LSAs to another child (which being a child) has less processing capabilities. The implication is that the policy points at import/export need to be capable of providing policing and maybe able to throttle import volume. --- Section 10 As previously discussed, there was no early allocation. Please delete This draft requests early allocation of IANA code points in accordance with [RFC4020]. [NOTE TO RFC Editor: this paragraph and the RFC 4020 reference can be removed during RFC editing]. --- Section 10.1 OLD - Local and Remote TE Router ID sub-TLV (26) - Inter-RA Export Upward sub-TLV (27) - Inter-RA Export Downward sub-TLV (28) NEW - Local and Remote TE Router ID sub-TLV (TBDx) - Inter-RA Export Upward sub-TLV (TBDz1) - Inter-RA Export Downward sub-TLV (TBDz2) END --- Section 10.2 OLD - Local TE Router ID sub-TLV (5) - Inter-RA Export Upward sub-TLV (27) - Inter-RA Export Downward sub-TLV (28) NEW - Local TE Router ID sub-TLV (TBDy) - Inter-RA Export Upward sub-TLV (TBDz1) - Inter-RA Export Downward sub-TLV (TBDz2) END --- Section 10.3 OLD - Inter-RA Export Upward sub-TLV (27) - Inter-RA Export Downward sub-TLV (28) NEW - Inter-RA Export Upward sub-TLV (TBDz1) - Inter-RA Export Downward sub-TLV (TBDz2) END --- Section 12 The following table shows how this draft complies with the s/draft/document/ to that requirement, and the fourth column lists the relevant section in draft, and/or another RFC that already satisfies the requirement. s/in draft/in this document/ --- Section 12 | 3.1 (3) | Prior to establishing | Yes when RA |Section 11.1 | | | communications, RCs MUST | maps to OSPF | | | |verify that they are bound | Area ID. | | | | to the same parent RA. | | | But you only recommend that correspondence. So what happens to this requirement if RA does not map to OSPF Area? Should you address this case, or should you require the correspondence? --- Section 12 | 3.2 (8) | Routing Information | No - Not | | | |exchanged between levels N | described. | | | | and N+1 via external link | | | | | (inter-RA links). | | | and | 3.2 (15) | The Level N routing | Not described | N/A | | | function is on a separate | but possible. | | | | system the Level N+1 | | | | | routing function. | | | I think this ties to my question on section 7. I think you should make clearer in the preamble that you are only addressing the case where the level boundary occurs within an RC. Since you are doing this work to address a need from the OIF where layer boundaries have typically been exposed through an external protocol interface, I am a little puzzled by your choice to limit your work. Maybe a figure in an early section would show how RAs and RCs are presented in the part of the problem you are solving. --- Section 12 | 3.3 (16) |The RC MUST support static | Yes - | Sections 2 | | | (i.e., operator assisted) | automation |and 3. Config| | | and MAY support automated |requirement is | is product | | | configuration of the | ambiguous. | specific. | | |information describing its | | | | |relationship to its parent | | | | | and its child within the | | | | | hierarchical structure | | | | | (including RA ID and RC | | | | | ID). | | | Does "automation requirement is ambiguous" mean "automation not supported"? --- Section 12 | 5 (29) | In order to support |Partial - OSPF |RFC 2328 and | | | operator-assisted changes | supports the | RFC 5250 | | | in the containment | purging of | | | | relationships of RAs, the | stale | | | | routing protocol SHALL |advertisements | | | |support evolution in terms |and origination| | | | of the number of | of new. The | | | |hierarchical levels of RAs.|non-disruptive | | | | For example: support of | behavior is | | | | non-disruptive operations |implementation | | | |such as adding and removing| specific. | | | | RAs at the top/bottom of | | | | | the hierarchy, adding or | | | | | removing a hierarchical | | | | |level of RAs in or from the| | | | |middle of the hierarchy, as| | | | | well as aggregation and | | | | | segmentation of RAs. | | | Surely this requirement demands a section explaining how the function is achieved. --- Section 14 It is usual to inherit acknowledgements from the obsoleted RFC where there is a lot of shared text. You should also thank any external SDO that was consulted through a liaison process. --- Appendix A Management domain Text format problem From agmalis@gmail.com Sun Nov 27 15:10:41 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2370D21F8BD7 for ; Sun, 27 Nov 2011 15:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oeh3lT0Lq9XE for ; Sun, 27 Nov 2011 15:10:39 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA0F121F8BC4 for ; Sun, 27 Nov 2011 15:10:38 -0800 (PST) Received: by qadb14 with SMTP id b14so901648qad.10 for ; Sun, 27 Nov 2011 15:10:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CWdX/KiGjqCC0AQAYzRTytzoQz3JQ/RCLeyKpqUG/KU=; b=TxELby9fx79cxNYoGlLdDblzh9h+QAPKXi4H9ktp7FwH0RVpVqXusr2y9OmDB9r5mK Zp37wnQgQWfIin5e5RMEmEgTqIFPGNNSUcHECvnwg2ZW4RmdzW3oj2GK2Kt3qJLBL8B1 vUpR5CLxw7+DfGtICzAbPo4CIGYagvQM6usyo= Received: by 10.224.195.10 with SMTP id ea10mr10518463qab.16.1322435415222; Sun, 27 Nov 2011 15:10:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.189.197 with HTTP; Sun, 27 Nov 2011 15:09:54 -0800 (PST) In-Reply-To: <00c301ccabaa$9109cb70$b31d6250$@olddog.co.uk> References: <00c301ccabaa$9109cb70$b31d6250$@olddog.co.uk> From: "Andrew G. Malis" Date: Sun, 27 Nov 2011 15:09:54 -0800 Message-ID: To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org, draft-ietf-ccamp-rfc5787bis@tools.ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-rfc5787bis X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2011 23:10:41 -0000 Adrian, Thanks! The authors are reviewing your comments now. We'll let you know if we have any questions or concerns. Cheers, Andy On Fri, Nov 25, 2011 at 11:43 AM, Adrian Farrel wrote= : > Hi, > > I have done my usual AD review prior to putting the draft forward for > IETF last call and IESG review. I have a number of questions and issues > that I would like you to address in a new revision. Some of these things > are questions that can be handled either by discussion or by making > changes to the draft. Other issues are more substantive and will need > updates =A0to the document. > > I have move the draft into Revised I-D needed, and will wait for the > new revision. > > Thanks, > > Adrian > > --- > > If I understand correctly, the intention of this document is to entirely > replace (i.e. obsolete) RFC 5787. That's OK, but you need to do several > things: > > 1. State in the document header > Obsoletes: 5787 (if approved) > > 2. Remove "Updates to" and "(RFC 5787bis)" from the document title > > 3. Add a statement to the Abstract (usually the last sentence) to say > "This document obsoletes RFC 5787" > > 4. Add a final paragraph to summarise why this document obsoletes > =A0RFC 5787 and to mention the change to standards track. > > 5. Include a section called "Changes from RFC 5787" > > --- > > Section 2 > > =A0 RAs are hierarchically contained: a higher-level (parent) RA contains > =A0 lower-level (child) RAs that in turn MAY also contain RAs, etc. > > Why MAY not may? > Why "etc." ? > > --- > > Please expand acronyms on first use. For example SCN. > > --- > > Section 3 > > =A0 In the context of OSPF Traffic Engineering (TE), an ASON transport > =A0 node corresponds to a unique OSPF TE node. =A0An OSPF TE node is > =A0 uniquely identified by the TE Router Address TLV [RFC3630]. In this > =A0 document, this TE Router Address is referred to as the TE Router ID, > =A0 which is in the ASON transport plane name space. =A0The TE Router ID > =A0 should not be confused with the OSPF Router ID which uniquely > =A0 identifies an OSPF router within an OSPF routing domain [RFC2328] and > =A0 is in a name space for control plane components. > > =A0 Note: The Router Address top-level TLV definition, processing, and > =A0 usage are unchanged from [RFC3630]. =A0This TLV specifies a stable OS= PF > =A0 TE node IP address, i.e., the IP address is always reachable when > =A0 there is IP connectivity to the associated OSPF TE node. > > Note that RFC 3630 does not define a "TE Router Address TLV" You seem to > recognize this in the second paragraph. > > You seem to acknowledge that the Router Address TLV contains a stable > OSPF TE node IP address that is always reachable when there is IP > connectivity to the associated OSPF TE node. As far as I can tell, this > means that the address comes from the SCN space not from the transport > name space as you have claimed. > > It may be that you need or desire some overlap of spaces, but you have > > not made any statement to that effect. > > In fact I am surprised that you say that there is a 1:1 correspondence > between a transport node and an OSPF TE node. This sounds like an > implementation detail unless an OSPF TE node is a logical concept. If it > is, it would be really =A0useful to explain it. > > It does not help that you have not defined "OSPF TE node" and you freely > mix that term with the term "OSPF router". It should be clear to you > that there are OSPF protocol speakers and there are transport nodes on > behalf of which the protocol speakers distribute information. > > Please have another attempt at this section making clear what the OSPF > entities are and how they map to actual things. You obviously did not > like the content of Section 5.1 of RFC 5787, but you seem to have thrown > out the baby with the bathwater. > > Furthermore, in Section 6 you have > > =A0 Hence, a single OSPF router (i.e., the PC) MUST be able to advertise > =A0 on behalf of multiple transport layer nodes. The OSPF routers are > =A0 identified by OSPF Router ID and the transport nodes are identified > =A0 by TE Router ID. > > > which is very good, but appear to contradict > > =A0 In the context of OSPF Traffic Engineering (TE), an ASON transport > =A0 node corresponds to a unique OSPF TE node. > > Probably you intend to say that an ASON transport node is represented by > a single OSPF TE node and that an OSPF TE node may represent more than > one ASON transport node. You haven't actually excluded that in what you > write, but it is not very clear. > > --- > > Section 4 > > =A0 Reachability in ASON refers to the set of endpoints reachable in the > =A0 transport plane by a node or the reachable endpoints of a level N. > > Can you please rewrite this for clarity. "Reachability" cannot refer to > a set of anything per se; it is a quality. The definition also seems > > circular since you do not define what reachable means. > > --- > > Section 4 > > "(ASON SNPP name space)" > > What is this? You have already told us that ASON has just three name > spaces and this was not one of them. > > What is SNPP? > > --- > > Section 4 > > You say: > > =A0 The data plane node is > =A0 identified in the control plane by its TE Router ID, as discussed in > =A0 section 6. > > This contradicts what you say in Section 3 where the TE Router ID is an > IP reachable address and so is an SCN identifier not a control plane > identifier. > > --- > > Section 4 > > =A0 As a consequence, it MUST > =A0 be possible for the router to originate more than one TE LSA > =A0 containing the Node Attribute TLV when used for ASON reachability > =A0 advertisement. > > =A0 Hence, the Node Attribute TLV [RFC5786] advertisement rules must be > =A0 relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE > =A0 LSA originated by the RC when the RC is advertising reachability > =A0 information for a different transport node identified by the Local TE > =A0 Router Sub-TLV (refer to section 6.1). > > This looks like you are updating RFC 5786. > > You will need to make this explicit and to assure me that the OSPF > working group has signed off on this change. > > Since you are making the relaxation specific to ASON (or are you making > it general?) you will need to explain how a node receiving a second TE > LSA containing a node attribute TLV will know that it is an ASON > advertisement. > > --- > > Section 5.2 > > =A0 GMPLS routing defines an Interface Switching Capability Descriptor > =A0 (ISCD) that provides, among other things, the available > =A0 (maximum/minimum) bandwidth per priority available for Label Switched > =A0 Path (LSPs). > > - Too many instances of "available" > - The ISCD doesn't provide the bandwidth, only the information about the > =A0bandwidth > > --- > > Section 6 > > =A0 For ASON routing, the control plane component routing adjacency > =A0 topology (i.e., the associated Protocol Controller (PC) connectivity) > =A0 and the transport topology are NOT assumed to be congruent [RFC4258]. > > Lower case "not" please. > > --- > > Section 6 > > =A0 The Router Address TLV [RFC3630] is used to advertise the TE Router > =A0 ID associated with the advertising Routing Controller. TE Router IDs > =A0 for additional transport nodes are advertised through specification > =A0 of the Local TE Router Identifier in the Local and Remote TE Router > =A0 TE sub-TLV and the Local TE Router Identifier sub-TLV described in > =A0 the sections below. These Local TE Router Identifiers are typically > =A0 used as the local endpoints for TE Label Switched Paths (LSPs) > =A0 terminating on the associated transport node. > > I found this a bit odd. Previously you have said that a TE Router ID is > associated with a transport node that it identifies. Now you seem to be > saying that a TE Router ID is associated with an RC, and implying that > an RC is a transport node (since you say "for additional transport > nodes"). > > --- > > Section 6 > > =A0 It MAY be feasible for multiple OSPF Routers to advertise TE > =A0 information for the same transport node. However, this is not > =A0 considered a required use case and is not discussed further. > > The use of "MAY" is in the wrong scope. How about... > > =A0 The use of multiple OSPF Routers to advertise TE information for the > =A0 same transport node is not considered a required use case and is not > =A0 discussed further in this document. > > --- > > Section 6.1 > > =A0 An OSPF router advertising on behalf of multiple transport nodes will > =A0 require additional information to distinguish the link endpoints > > =A0 amongst the subsumed transport nodes. In order to unambiguously > =A0 specify the transport topology, the local and remote transport nodes > =A0 MUST be identified by TE router ID. > > "subsumed" seems a bit dramatic! > How about... > > =A0 When an OSPF Router advertises on behalf of multiple transport nodes, > =A0 the link end points cannot be automatically assigned to a single > =A0 transport node associated with the advertising router. In this case, > =A0 the link advertisement also includes identifiers of the link end > =A0 points. > > --- > > Section 6.1 > > =A0 The Type field of the Local and Remote TE Router ID sub-TLV is > =A0 assigned the value 26 (see Section 10). > > AFAICS, no early allocation was performed. Therefore, please replace > "26" with TBDx. > > Similarly in > > =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 > =A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 | =A0 =A0 =A0 =A0 =A0 =A0Type (26) =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0Length (8) =A0 =A0 =A0 =A0 =A0 | > > --- > > Section 6.1 > > =A0 The value of the Local and Remote TE Router > =A0 Identifier SHOULD NOT be set to 0. > > This use of "SHOULD NOT" implies that a value of 0 MAY be used for some > reason. Please clarify. > > --- > > Section 6.1 > > This section reminds me to ask what plans the WG has to support IPv6. > > --- > > Section 6.1 > > =A0 This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV > =A0 if the OSPF router is advertising on behalf of one or more transport > =A0 nodes having TE Router IDs different from the TE Router ID advertised > =A0 in the Router Address TLV. =A0Therefore, it MUST be included if the > =A0 OSPF router is advertising on behalf of multiple transport nodes. > > =A0 Note: The Link ID sub-TLV identifies the other end of the link (i.e., > =A0 Router ID of the neighbor for point-to-point links) [RFC3630]. When > =A0 the Local and Remote TE Router ID Sub-TLV is present, it MUST be used > =A0 to identify local and remote transport node endpoints for the link > =A0 and the Link-ID sub-TLV MUST be ignored. The Local and Remote ID sub- > =A0 TLV, if specified, MUST only be specified once. > > A lot of "MUST" without explaining what the process is if not. > > A receiver getting no sub-TLV assumes what? > A router advertising on behalf of the transport node with the same TE > Router ID MAY / MUST NOT include sub-TLVs. > If there is more than one sub-TLV present the receiver should do what? > Does "Therefore, it MUST be included if the OSPF router is advertising > =A0on behalf of multiple transport nodes" imply the sub-TLV must be > =A0included even when the advertisement is for the transport node with > =A0the same TE Router ID? > > --- > > Section 6.2 > > Per previous comments on IANA > > Please change "5" to TBDy in... > > =A0 The Type field of the Local TE Router ID sub-TLV is assigned the > =A0 value 5 (see Section 10). =A0The Length field takes the value 4. =A0T= he > > ...and... > > =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 > =A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ... > =A0 | =A0 =A0 =A0 =A0 =A0 =A0 Type (5) =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 = =A0 =A0Length (4) =A0 =A0 =A0 =A0 =A0 | > > --- > > Section 6.2 > > =A0 This sub-TLV MUST be included as a sub-TLV of the top-level Node > =A0 Attribute TLV if the OSPF router is advertising on behalf of one or > =A0 more transport nodes having TE Router IDs different from the TE > =A0 Router ID advertised in the Router Address TLV. =A0Therefore, it MUST > =A0 be included if the OSPF router is advertising on behalf of multiple > =A0 transport nodes. > > Similar questions as per 6.1. > > What can a receiver assume if the sub-TLV is not present? > Does the final sentence mean that the sub-TLV must be included even in > =A0the case where the advertisement is for the same TE Router ID? > Can the sender include the sub-TLV when it only advertises for a single > =A0transport node? > What if there is more than one sub-TLV present? > > --- > > Section 7 > > =A0 An ASON routing area (RA) represents a partition of the data plane, > =A0 and its identifier is used within the control plane as the > =A0 representation of this partition. =A0An RA may contain smaller RAs > =A0 inter-connected by links. =A0ASON RA levels do not map directly to OS= PF > =A0 areas. Rather, hierarchical levels of RAs are represented by separate > =A0 OSPF protocol instances. > > It would be interesting to add a statement about the correspondence > between RAs and OSPF areas (per section 2). > > --- > > Section 7 > > It isn't clear to me reading this section and the subsections whether > export happens at a single node that is present in both parent and child > RA, or whether there is an "export interface" between nodes. I would > assume that an implementation could place the export within a box, but > that there is no architectural constraint. That means that the export > function is an exposed function. If so, where is the protocol > definition? > > --- > > Section 7.2.1 > > IANA stuff again > > Please replace: > 27 as TBDz1 > 28 as TBDz2 > > in... > =A0 The type value 28 (see > =A0 Section 10) will indicate that the associated routing information has > =A0 been exported downward. The type value 27 (see Section 10) will > =A0 indicate that the associated routing information has been exported > =A0 upward. > and in... > =A0 The Type field of the Inter-RA Export Upward and Inter-RA Export > =A0 Downward sub-TLVs are respectively assigned the values 27 and 28 (see > =A0 Section 10). > > and... > =A0 =A00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3 > =A0 =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =A0 | Upward/Downward Type (27/28) =A0| =A0 =A0 =A0 =A0 =A0 Length (4) = =A0 =A0 =A0 =A0 =A0| > =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > --- > > Section 7.2.2 > > =A0 When exporting routing information upward in the ASON routing > =A0 hierarchy, any information received from a level above, i.e., tagged > =A0 with an Inter-RA Export Downward Sub-TLV, MUST NOT be exported > =A0 upward. Since an RA at level N is contained by a single RA at level > =A0 N+1, this is the only checking that is necessary and the associated > =A0 RA ID is used solely for informational purposes. > > Agreed. > And what should the receiver do if it receives such an export? > > Ditto for > > =A0 In > =A0 order words, routing information MUST NOT be exported downward into > =A0 the RA from which it was received. > > --- > > Section 8 > > =A0 The extensions described herein are only applicable to ASON routing > =A0 domains and it is not expected that the attendant reachability (see > =A0 Section 4) and link information will ever be mixed with global or > =A0 local IP routing information. > > I am not quite sure what you mean by "mixed" or by "local IP routing > information". You may be saying that you expect (require?) that TE > information s exchanged in a separate instance of OSPF than is used > for exchanging SCN routing information. > > If that is what you are hoping for, I expect you will be sadly > disappointed by the entire deployed GMPLS base. For a single RA it > makes complete sense to run just one instance of OSPF that exchanges > information about SCN IP reachability and also transport plane TE info. > > It gets more complicated with a multi-RA system, and you need to address > that. > > --- > > Section 8 > > You give some good advice, but you do it with nested 2119 language. I > don't know how to interpret "You SHOULD apply a MUST". > > Additionally, since you say "SHOULD", you need to explain what the > associated MAY condition is. > > --- > > Section 9 > > Here is an attack vector... > > Suppose a small child RA is infiltrated. A very large (unmanageably > large) number of LSAs are exported to the parent. This may swamp the > parent making it impossible for it to function. Additionally, the > parent may export all the LSAs to another child (which being a child) > has less processing capabilities. > > The implication is that the policy points at import/export need to be > capable of providing policing and maybe able to throttle import volume. > > --- > > Section 10 > > As previously discussed, there was no early allocation. > > Please delete > > =A0 This draft requests early allocation of IANA code points in > =A0 accordance with [RFC4020]. [NOTE TO RFC Editor: this paragraph and > =A0 the RFC 4020 reference can be removed during RFC editing]. > > --- > > Section 10.1 > > OLD > =A0 - Local and Remote TE Router ID sub-TLV (26) > =A0 - Inter-RA Export Upward sub-TLV (27) > =A0 - Inter-RA Export Downward sub-TLV (28) > NEW > =A0 - Local and Remote TE Router ID sub-TLV (TBDx) > =A0 - Inter-RA Export Upward sub-TLV (TBDz1) > =A0 - Inter-RA Export Downward sub-TLV (TBDz2) > END > > --- > > Section 10.2 > > OLD > =A0 =A0 =A0- Local TE Router ID sub-TLV (5) > =A0 =A0 =A0- Inter-RA Export Upward sub-TLV (27) > =A0 =A0 =A0- Inter-RA Export Downward sub-TLV (28) > NEW > =A0 =A0 =A0- Local TE Router ID sub-TLV (TBDy) > =A0 =A0 =A0- Inter-RA Export Upward sub-TLV (TBDz1) > =A0 =A0 =A0- Inter-RA Export Downward sub-TLV (TBDz2) > END > > --- > > Section 10.3 > > OLD > =A0 =A0 =A0- Inter-RA Export Upward sub-TLV (27) > =A0 =A0 =A0- Inter-RA Export Downward sub-TLV (28) > NEW > =A0 =A0 =A0- Inter-RA Export Upward sub-TLV (TBDz1) > =A0 =A0 =A0- Inter-RA Export Downward sub-TLV (TBDz2) > END > > --- > > Section 12 > > =A0 The following table shows how this draft complies with the > > s/draft/document/ > > =A0 to that requirement, and the fourth column lists the relevant section > =A0 in draft, and/or another RFC that already satisfies the requirement. > > s/in draft/in this document/ > > --- > > Section 12 > > =A0| 3.1 (3) =A0| =A0 Prior to establishing =A0 | =A0Yes when RA =A0|Sect= ion 11.1 | > =A0| =A0 =A0 =A0 =A0 =A0| communications, RCs MUST =A0| maps to OSPF =A0|= =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|verify that they are bound | =A0 Area ID. =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0to the same parent RA. =A0 | =A0 =A0 =A0 =A0= =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > > But you only recommend that correspondence. So what happens to this > requirement if RA does not map to OSPF Area? Should you address this > case, or should you require the correspondence? > > --- > > Section 12 > > =A0| 3.2 (8) =A0| =A0 =A0Routing Information =A0 =A0| =A0 No - Not =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|exchanged between levels N | =A0described. =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| and N+1 via external link | =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 =A0 (inter-RA links). =A0 =A0 | =A0 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > > and > > =A0| 3.2 (15) | =A0 =A0The Level N routing =A0 =A0| Not described | =A0 = =A0 N/A =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| function is on a separate | but possible. | =A0= =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 system the Level N+1 =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 =A0 routing function. =A0 =A0 | =A0 =A0 =A0= =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > > I think this ties to my question on section 7. > I think you should make clearer in the preamble that you are only > addressing the case where the level boundary occurs within an RC. > Since you are doing this work to address a need from the OIF where layer > boundaries have typically been exposed through an external protocol > interface, I am a little puzzled by your choice to limit your work. > Maybe a figure in an early section would show how RAs and RCs are > presented in the part of the problem you are solving. > > --- > > Section 12 > > =A0| 3.3 (16) |The RC MUST support static | =A0 =A0 Yes - =A0 =A0 | Secti= ons 2 =A0| > =A0| =A0 =A0 =A0 =A0 =A0| (i.e., operator assisted) | =A0automation =A0 |= and 3. Config| > =A0| =A0 =A0 =A0 =A0 =A0| and MAY support automated |requirement is | is = product =A0| > =A0| =A0 =A0 =A0 =A0 =A0| =A0 configuration of the =A0 =A0| =A0ambiguous.= =A0 | =A0specific. =A0| > =A0| =A0 =A0 =A0 =A0 =A0|information describing its | =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|relationship to its parent | =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| and its child within the =A0| =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0hierarchical structure =A0 | =A0 =A0 =A0 =A0= =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0(including RA ID and RC =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 ID). =A0 =A0 =A0 =A0 =A0 = =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > > Does "automation requirement is ambiguous" mean "automation not > supported"? > > --- > > Section 12 > > =A0| =A05 (29) =A0| =A0 =A0In order to support =A0 =A0|Partial - OSPF |RF= C 2328 and | > =A0| =A0 =A0 =A0 =A0 =A0| operator-assisted changes | supports the =A0| = =A0RFC 5250 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 =A0in the containment =A0 =A0 | =A0purging = of =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| relationships of RAs, the | =A0 =A0 stale =A0 = =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0routing protocol SHALL =A0 |advertisements |= =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|support evolution in terms |and origination| =A0= =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 =A0 of the number of =A0 =A0 =A0| =A0of new= . The =A0| =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|hierarchical levels of RAs.|non-disruptive | =A0= =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0For example: support of =A0| =A0behavior is = =A0| =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| non-disruptive operations |implementation | =A0= =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|such as adding and removing| =A0 specific. =A0 |= =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| RAs at the top/bottom of =A0| =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| the hierarchy, adding or =A0| =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0removing a hierarchical =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|level of RAs in or from the| =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0|middle of the hierarchy, as| =A0 =A0 =A0 =A0 =A0= =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0well as aggregation and =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > =A0| =A0 =A0 =A0 =A0 =A0| =A0 segmentation of RAs. =A0 =A0| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 | > > Surely this requirement demands a section explaining how the function is > achieved. > > --- > > Section 14 > > It is usual to inherit acknowledgements from the obsoleted RFC where > there is a lot of shared text. > > You should also thank any external SDO that was consulted through a > liaison process. > > --- > > Appendix A Management domain > > Text format problem > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Sun Nov 27 17:14:27 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8305921F8B21; Sun, 27 Nov 2011 17:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMybtCXp5JYy; Sun, 27 Nov 2011 17:14:26 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 91C2B21F86DD; Sun, 27 Nov 2011 17:14:26 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAS1EN5Q011546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 27 Nov 2011 19:14:26 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 27 Nov 2011 20:14:22 -0500 From: Acee Lindem To: "ospf@ietf.org List" Date: Sun, 27 Nov 2011 20:14:20 -0500 Thread-Topic: Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 Thread-Index: Acytaw+ihOhqfR1kRDeLmnkxcFk2Ow== Message-ID: <6343326C-9EFD-4F25-BBE4-E5001887A794@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-10-538276506"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 01:14:27 -0000 --Apple-Mail-10-538276506 Content-Type: multipart/alternative; boundary=Apple-Mail-9-538276492 --Apple-Mail-9-538276492 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please note that this document relaxes the RFC 5786 restriction that a = Node Attribute TLV may only appear in a single OSPF TE LSA. Here is the = text:=20 In order to support ASON reachability advertisement, the Node Attribute TLV defined in [RFC5786] is used to advertise the combination of a TE Router ID and its set of associated reachable address prefixes. The Node Attribute TLV can contain the following sub-TLVs: - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] A router may support multiple transport nodes as discussed in section 6, and, as a result, may be required to advertise reachability (ASON SNPPs) separately for each transport node. As a consequence, it MUST be possible for the router to originate more than one TE LSA containing the Node Attribute TLV when used for ASON reachability advertisement. Hence, the Node Attribute TLV [RFC5786] advertisement rules must be relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE LSA originated by the RC when the RC is advertising reachability information for a different transport node identified by the Local TE Router Sub-TLV (refer to section 6.1). Here is a link to the document: = http://www.ietf.org/id/draft-ietf-ccamp-rfc5787bis-03.txt If you have any concerns with this change, please send them to this list = with the CCAMP list copied.=20 Thanks, Acee=20 --Apple-Mail-9-538276492 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Node Attribute TLV = may only appear in a single OSPF TE LSA. Here is the text: = 

   In order to support ASON reachability advertisement, the =
Node
   Attribute TLV defined in [RFC5786] is used to advertise the
   combination of a TE Router ID and its set of associated reachable
   address prefixes. The Node Attribute TLV can contain the following
   sub-TLVs:

      - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2
      - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786]
      - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786]

   A router may support multiple transport nodes as discussed in section
   6, and, as a result, may be required to advertise reachability (ASON
   SNPPs) separately for each transport node. As a consequence, it MUST
   be possible for the router to originate more than one TE LSA
   containing the Node Attribute TLV when used for ASON reachability
   advertisement.

   Hence, the Node Attribute TLV [RFC5786] advertisement rules must be
   relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE
   LSA originated by the RC when the RC is advertising reachability
   information for a different transport node identified by the Local TE
   Router Sub-TLV (refer to section 6.1).
Here is a link to = the document: http://= www.ietf.org/id/draft-ietf-ccamp-rfc5787bis-03.txt

If you have any concerns with this change, please send them to = this list with the CCAMP list = copied. 

Thanks,
Acee
X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5E21F8593; Sun, 27 Nov 2011 19:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.527 X-Spam-Level: X-Spam-Status: No, score=-4.527 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wngOyf5rHg9h; Sun, 27 Nov 2011 19:13:18 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2C74B21F858D; Sun, 27 Nov 2011 19:13:18 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVC00DNKOV92G@szxga03-in.huawei.com>; Mon, 28 Nov 2011 11:11:34 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVC00LBSOV9PE@szxga03-in.huawei.com>; Mon, 28 Nov 2011 11:11:33 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFI34485; Mon, 28 Nov 2011 11:11:33 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 Nov 2011 11:11:32 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.92]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0270.001; Mon, 28 Nov 2011 11:11:25 +0800 Date: Mon, 28 Nov 2011 03:11:25 +0000 From: Zhangfatai In-reply-to: <6343326C-9EFD-4F25-BBE4-E5001887A794@ericsson.com> X-Originating-IP: [10.70.76.157] To: Acee Lindem , "ospf@ietf.org List" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_iv8CvaF1os4wM40rv2/vnQ)" Content-language: en-US Accept-Language: zh-CN, en-US Thread-topic: [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 Thread-index: Acytaw+ihOhqfR1kRDeLmnkxcFk2OwAD+J0Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6343326C-9EFD-4F25-BBE4-E5001887A794@ericsson.com> Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 03:13:19 -0000 --Boundary_(ID_iv8CvaF1os4wM40rv2/vnQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgYWxsLA0KDQpDYW4gdGhpcyByZWxheGF0aW9uIGJlIGFwcGxpY2FibGUgdG8gYWxsIHRoZSBm dXR1cmUgT1NGUHYyIGRvY3VtZW50cyA/DQoNCg0KDQoNClRoYW5rcw0KDQpGYXRhaQ0KDQpGcm9t OiBvc3BmLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBBY2VlIExpbmRlbQ0KU2VudDogMjAxMcTqMTHUwjI4yNUgOToxNA0KVG86IG9z cGZAaWV0Zi5vcmcgTGlzdA0KQ2M6IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBbT1NQRl0gVXBk YXRlcyB0byBBU09OIFJvdXRpbmcgZm9yIE9TUEZ2MiBQcm90b2NvbHMgKFJGQyA1Nzg3YmlzKSB3 aWxsIFVwZGF0ZSBSRkMgNTc4Ng0KDQpQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgcmVs YXhlcyB0aGUgUkZDIDU3ODYgIHJlc3RyaWN0aW9uIHRoYXQgYSBOb2RlIEF0dHJpYnV0ZSBUTFYg bWF5IG9ubHkgYXBwZWFyIGluIGEgc2luZ2xlIE9TUEYgVEUgTFNBLiBIZXJlIGlzIHRoZSB0ZXh0 Og0KDQoNCiAgIEluIG9yZGVyIHRvIHN1cHBvcnQgQVNPTiByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNl bWVudCwgdGhlIE5vZGUNCg0KICAgQXR0cmlidXRlIFRMViBkZWZpbmVkIGluIFtSRkM1Nzg2XSBp cyB1c2VkIHRvIGFkdmVydGlzZSB0aGUNCg0KICAgY29tYmluYXRpb24gb2YgYSBURSBSb3V0ZXIg SUQgYW5kIGl0cyBzZXQgb2YgYXNzb2NpYXRlZCByZWFjaGFibGUNCg0KICAgYWRkcmVzcyBwcmVm aXhlcy4gVGhlIE5vZGUgQXR0cmlidXRlIFRMViBjYW4gY29udGFpbiB0aGUgZm9sbG93aW5nDQoN CiAgIHN1Yi1UTFZzOg0KDQoNCg0KICAgICAgLSBURSBSb3V0ZXIgSUQgc3ViLVRMVjogTGVuZ3Ro OiA0OyBEZWZpbmVkIGluIFNlY3Rpb24gNi4yDQoNCiAgICAgIC0gTm9kZSBJUHY0IExvY2FsIEFk ZHJlc3Mgc3ViLVRMVjogTGVuZ3RoOiB2YXJpYWJsZTsgW1JGQzU3ODZdDQoNCiAgICAgIC0gTm9k ZSBJUHY2IExvY2FsIEFkZHJlc3Mgc3ViLVRMVjogTGVuZ3RoOiB2YXJpYWJsZTsgW1JGQzU3ODZd DQoNCg0KDQogICBBIHJvdXRlciBtYXkgc3VwcG9ydCBtdWx0aXBsZSB0cmFuc3BvcnQgbm9kZXMg YXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24NCg0KICAgNiwgYW5kLCBhcyBhIHJlc3VsdCwgbWF5IGJl IHJlcXVpcmVkIHRvIGFkdmVydGlzZSByZWFjaGFiaWxpdHkgKEFTT04NCg0KICAgU05QUHMpIHNl cGFyYXRlbHkgZm9yIGVhY2ggdHJhbnNwb3J0IG5vZGUuIEFzIGEgY29uc2VxdWVuY2UsIGl0IE1V U1QNCg0KICAgYmUgcG9zc2libGUgZm9yIHRoZSByb3V0ZXIgdG8gb3JpZ2luYXRlIG1vcmUgdGhh biBvbmUgVEUgTFNBDQoNCiAgIGNvbnRhaW5pbmcgdGhlIE5vZGUgQXR0cmlidXRlIFRMViB3aGVu IHVzZWQgZm9yIEFTT04gcmVhY2hhYmlsaXR5DQoNCiAgIGFkdmVydGlzZW1lbnQuDQoNCg0KDQog ICBIZW5jZSwgdGhlIE5vZGUgQXR0cmlidXRlIFRMViBbUkZDNTc4Nl0gYWR2ZXJ0aXNlbWVudCBy dWxlcyBtdXN0IGJlDQoNCiAgIHJlbGF4ZWQgZm9yIEFTT04uIEEgTm9kZSBBdHRyaWJ1dGUgVExW IE1BWSBhcHBlYXIgaW4gbW9yZSB0aGFuIG9uZSBURQ0KDQogICBMU0Egb3JpZ2luYXRlZCBieSB0 aGUgUkMgd2hlbiB0aGUgUkMgaXMgYWR2ZXJ0aXNpbmcgcmVhY2hhYmlsaXR5DQoNCiAgIGluZm9y bWF0aW9uIGZvciBhIGRpZmZlcmVudCB0cmFuc3BvcnQgbm9kZSBpZGVudGlmaWVkIGJ5IHRoZSBM b2NhbCBURQ0KDQogICBSb3V0ZXIgU3ViLVRMViAocmVmZXIgdG8gc2VjdGlvbiA2LjEpLg0KSGVy ZSBpcyBhIGxpbmsgdG8gdGhlIGRvY3VtZW50OiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0 LWlldGYtY2NhbXAtcmZjNTc4N2Jpcy0wMy50eHQNCg0KSWYgeW91IGhhdmUgYW55IGNvbmNlcm5z IHdpdGggdGhpcyBjaGFuZ2UsIHBsZWFzZSBzZW5kIHRoZW0gdG8gdGhpcyBsaXN0IHdpdGggdGhl IENDQU1QIGxpc3QgY29waWVkLg0KDQpUaGFua3MsDQpBY2VlDQoNCg== --Boundary_(ID_iv8CvaF1os4wM40rv2/vnQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi all,

 

Can this relaxation be applicable to all = the future OSFPv2 documents ?

 

 

 

 

Thanks
 
Fatai

 

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: 2011=C4=EA11=D4=C228=C8=D5 9:14
To: ospf@ietf.org List
Cc: ccamp@ietf.org
Subject: [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 57= 87bis) will Update RFC 5786

 

Please note that this document = relaxes the RFC 5786  restriction that a Node Attribute TLV may only appear in a single OSPF TE LSA. Here is the text:

 

   In order to support ASON reachabilit=
y advertisement, the Node
   Attribute TLV defined in [RFC5786] i=
s used to advertise the
   combination of a TE Router ID and it=
s set of associated reachable
   address prefixes. The Node Attribute=
 TLV can contain the following
   sub-TLVs:
 
      - TE Router ID sub=
-TLV: Length: 4; Defined in Section 6.2
      - Node IPv4 Local =
Address sub-TLV: Length: variable; [RFC5786]
      - Node IPv6 Local =
Address sub-TLV: Length: variable; [RFC5786]
 
   A router may support multiple transp=
ort nodes as discussed in section
   6, and, as a result, may be required=
 to advertise reachability (ASON
   SNPPs) separately for each transport=
 node. As a consequence, it MUST
   be possible for the router to origin=
ate more than one TE LSA
   containing the Node Attribute TLV wh=
en used for ASON reachability
   advertisement.

 


   Hence, the Node Attribute TLV [RFC57=
86] advertisement rules must be


   relaxed for ASON. A Node Attribute T=
LV MAY appear in more than one TE


   LSA originated by the RC when the RC=
 is advertising reachability


   information for a different transpor=
t node identified by the Local TE


   Router Sub-TLV (refer to section 6.1=
).


Here is a link to the document:=
 http://www.ietf.org/id/draft-ietf-ccamp-rf=
c5787bis-03.txt

 

If you have any concerns wi= th this change, please send them to this list with the CCAMP list copied.&n= bsp;

 

Thanks,

Acee

 

--Boundary_(ID_iv8CvaF1os4wM40rv2/vnQ)-- From acee.lindem@ericsson.com Mon Nov 28 06:59:20 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F0E21F87D9; Mon, 28 Nov 2011 06:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Nc5XqiqSgGS; Mon, 28 Nov 2011 06:59:16 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 452C021F8610; Mon, 28 Nov 2011 06:59:16 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pASEwM2r007277; Mon, 28 Nov 2011 08:58:43 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 28 Nov 2011 09:58:24 -0500 From: Acee Lindem To: Zhangfatai Date: Mon, 28 Nov 2011 09:58:22 -0500 Thread-Topic: [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 Thread-Index: Acyt3i1szvC4SHppT32/3b3HyAchOQ== Message-ID: <2D6BCF8B-F6AF-40C0-8E63-5AEB29B8D02A@ericsson.com> References: <6343326C-9EFD-4F25-BBE4-E5001887A794@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-17-587718983"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org List" , "ccamp@ietf.org" Subject: Re: [CCAMP] [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 14:59:20 -0000 --Apple-Mail-17-587718983 Content-Type: multipart/alternative; boundary=Apple-Mail-16-587718967 --Apple-Mail-16-587718967 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Fatai, We have two separate requirements here. The ASON requirement is to be = able to advertise reachability information for multiple ASON transport = nodes. As you've noted, there has been an independent requirement to = advertise more information than will fit in a single LSA. Our draft only = addresses the first. However, we'll consider this when addressing = Adrian's comments. Much of this depends on whether or not we do a second = review and WG last call.=20 Thanks, Acee On Nov 27, 2011, at 10:11 PM, Zhangfatai wrote: > Hi all, > =20 > Can this relaxation be applicable to all the future OSFPv2 documents ? > =20 > =20 > =20 > =20 > Thanks > =20 > Fatai > =20 > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf = Of Acee Lindem > Sent: 2011=C4=EA11=D4=C228=C8=D5 9:14 > To: ospf@ietf.org List > Cc: ccamp@ietf.org > Subject: [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC = 5787bis) will Update RFC 5786 > =20 > Please note that this document relaxes the RFC 5786 restriction that = a Node Attribute TLV may only appear in a single OSPF TE LSA. Here is = the text: > =20 > In order to support ASON reachability advertisement, the Node > Attribute TLV defined in [RFC5786] is used to advertise the > combination of a TE Router ID and its set of associated reachable > address prefixes. The Node Attribute TLV can contain the following > sub-TLVs: > =20 > - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 > - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] > - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] > =20 > A router may support multiple transport nodes as discussed in = section > 6, and, as a result, may be required to advertise reachability = (ASON > SNPPs) separately for each transport node. As a consequence, it = MUST > be possible for the router to originate more than one TE LSA > containing the Node Attribute TLV when used for ASON reachability > advertisement. > =20 > Hence, the Node Attribute TLV [RFC5786] advertisement rules must be > relaxed for ASON. A Node Attribute TLV MAY appear in more than one = TE > LSA originated by the RC when the RC is advertising reachability > information for a different transport node identified by the Local = TE > Router Sub-TLV (refer to section 6.1). > Here is a link to the document: = http://www.ietf.org/id/draft-ietf-ccamp-rfc5787bis-03.txt > =20 > If you have any concerns with this change, please send them to this = list with the CCAMP list copied.=20 > =20 > Thanks, > Acee > =20 --Apple-Mail-16-587718967 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Fatai,
We have two separate requirements = here. The ASON requirement is to be able to advertise reachability = information for multiple ASON transport nodes. As you've noted, there = has been an independent requirement to advertise more information than = will fit in a single LSA. Our draft only addresses the first. However, = we'll consider this when addressing Adrian's comments. Much of this = depends on whether or not we do a second review and WG last = call. 
Thanks,
Acee

On Nov 27, 2011, at 10:11 PM, Zhangfatai wrote:

Hi all,
 
Can this = relaxation be applicable to all the future OSFPv2 documents = ?
From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org= ] On Behalf Of Acee = Lindem
Sent: 2011=C4=EA11=D4=C228=C8=D5 9:14
To: ospf@ietf.org List
Cc: ccamp@ietf.org
Subject: [OSPF] Updates to ASON = Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC = 5786
 
Please note that this document = relaxes the RFC 5786  restriction that a Node Attribute TLV may only appear in a single OSPF TE = LSA. Here is the text:
 
   In order to support ASON =
reachability advertisement, the Node
   Attribute TLV defined in [RFC5786] =
is used to advertise the
   combination of a TE Router ID and its set of =
associated reachable
   address prefixes. The Node Attribute TLV can =
contain the following
   sub-TLVs:
 
      - TE Router ID =
sub-TLV: Length: 4; Defined in Section 6.2
      - Node IPv4 Local =
Address sub-TLV: Length: variable; [RFC5786]
      - Node IPv6 Local =
Address sub-TLV: Length: variable; [RFC5786]
 
   A router may support multiple =
transport nodes as discussed in section
   6, and, as a result, may be required =
to advertise reachability (ASON
   SNPPs) separately for each transport =
node. As a consequence, it MUST
   be possible for the router to =
originate more than one TE LSA
   containing the Node Attribute TLV =
when used for ASON reachability
   =
advertisement.
 
   Hence, the Node Attribute TLV [RFC5786] =
advertisement rules must be
   relaxed for ASON. A Node Attribute =
TLV MAY appear in more than one TE
   LSA originated by the RC when the RC =
is advertising reachability
   information for a different =
transport node identified by the Local TE
   Router Sub-TLV (refer to section =
6.1).
Here = is a link to the document: 

= --Apple-Mail-16-587718967-- --Apple-Mail-17-587718983 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTEyODE0NTgyMlowIwYJKoZI hvcNAQkEMRYEFC8Gf7HDHQlUp7kecv/IgypPBjs6MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgB1OAEAy9f85MxEszdHdAzF8TjrsdQJgIr1qZwKYR5ZoZYFcdbjfjVMRZvNwD+1N h3q1BPad2LWrAtDVSO6nq1+Q2aBugJyc4mNE3aMvwSdv7C+vjTEyDFnjG1x2lcsH/FoMBjEqGovr bOlh0oVp3ZGM0h48E8aCHdtDc/ho9QdtAAAAAAAA --Apple-Mail-17-587718983-- From jdrake@juniper.net Mon Nov 28 08:48:07 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE8621F8B5A for ; Mon, 28 Nov 2011 08:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POmnrxKD1eqG for ; Mon, 28 Nov 2011 08:48:06 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9D921F8B59 for ; Mon, 28 Nov 2011 08:48:06 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTtO7QW/0y6jNQoYO9cffc3yR9MkcymOD@postini.com; Mon, 28 Nov 2011 08:48:06 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 28 Nov 2011 08:45:03 -0800 From: John E Drake To: Daniele Ceccarelli , CCAMP Date: Mon, 28 Nov 2011 08:45:03 -0800 Thread-Topic: OSPF OTN considerations post IETF 82 Thread-Index: AcypvXUM4uURSfqEQWyExafq21g2KwAAy7kQABLVdSAA+DFBkA== Message-ID: <5E893DB832F57341992548CDBB333163A4B531CFE6@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_005_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:48:07 -0000 --_005_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_ Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_" --_000_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Daniele, A single switching capability value and advertise both Unreserved and Max = LSP bandwidth. Thanks, John From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, November 23, 2011 10:19 AM To: CCAMP Subject: [CCAMP] OSPF OTN considerations post IETF 82 Hi CCAMP, During the OTN OSPF draft presentation at the IETF meeting in Taipei two co= mments were raised with respect to the following issues: - Issue 1: Using different switching caps for each ODU type - Issue 2: Type 2 (unres bandwidth for variable containers) and Type 3 (MAX= LSP bandwidth foe variable containers always used in tandem? WRT issue 1: the proposal was to indicate the bottom most ODUk of the muxin= g hiearachy in the Switching Capability field of the ISCD. After a quick ta= lk with the other authors of the ID, the idea was to reject the proposal as= it would lead to an overloading of the meaning of the Switching Capability= field. (even if the definition of PSC1-2-3-4 already overloads the meaning= of the switching capability field) WRT issue 2: it is analyzed in section 5.3 of the draft (version -00). I'm = copying it below for your convenience In this example the advertisement of an ODUflex->ODU3 hierarchy is shown. In case of ODUflex advertisement the MAX LSP bandwidth needs to be advertised but in some cases also information about the Unreserved bandwidth could be useful. The amount of Unreserved bandwidth does not give a clear indication of how many ODUflex LSP can be set up either at the MAX LSP Bandwidth or at different rates, as it gives no information about the spatial allocation of the free TSs. An indication of the amount of Unreserved bandwidth could be useful during the path computation process, as shown in the following example. Supposing there are two TE-links (A and B) with MAX LSP Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex LSPs of 10 GBps each, have to be restored, for sure only one can be restored along Link B and it is probable (but not sure) that two of them can be restored along Link A. Early proposal was to have, in the case of variable containers advertisemen= ts (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as a mandatory piece = of information and the Unreserved bandiwdth TLV (Type 2) as an optional pie= ce of information. The comment received is that optional information can lead to interworking = issues and the counter proposal was to have both pieces of information as m= andatory and, as a consequence, merge the two TLVs into a single one. We'd like to hear the opinion of the WG on both issues before proceeding wi= th any modification to the document. Thanks, Daniele DANIELE CECCARELLI System & Technology - DU IP & Broadband Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com [cid:image002.jpg@01CCADAA.05A88EC0] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Daniele,

 

=

A single switching capability value and  a= dvertise both Unreserved and Max LSP bandwidth.

 

Thanks,

 

John

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] <= b>On Behalf Of Daniele Ceccarelli
Sent: Wednesday, November 2= 3, 2011 10:19 AM
To: CCAMP
Subject: [CCAMP] OSPF OTN co= nsiderations post IETF 82

 

Hi CCAMP,=

 

During the OTN OSPF draft presentation at the IETF meeting= in Taipei two comments were raised with respect to the following issues:

 

- Issue 1: Using different switchi= ng caps for each ODU type

- Issue 2: Type 2 (unres bandwidth for variable containers) and Type 3= (MAX LSP bandwidth foe variable containers always used in tandem?

 

<= /div>

WRT issue 1: the proposal was to indicate t= he bottom most ODUk of the muxing hiearachy in the Switching Capability fie= ld of the ISCD. After a quick talk with the other authors of the ID, the id= ea was to reject the proposal as it would lead to an overloading of the mea= ning of the Switching Capability field. (even if the definition of PSC1-2-3= -4 already overloads the meaning of the switching capability field)

 

=

WRT issue 2: it is analyzed in section 5.3= of the draft (version -00). I'm copying it below for your convenience=

 <= /p>

   In this example the advertisement= of an ODUflex->ODU3 hierarchy is

   shown.  In case of ODUflex advertisement= the MAX LSP bandwidth needs

   to be advertised but in some cases also information a= bout the

  = ; Unreserved bandwidth could be useful.  The amount of Unreserved

   bandwidth d= oes not give a clear indication of how many ODUflex LSP<= /span>

   can be set up either at th= e MAX LSP Bandwidth or at different rates,

   as it gives no information about the sp= atial allocation of the free

   TSs.

 

=  =   An indication of the amount of Unreserved bandwidth could be useful<= /span>

   during = the path computation process, as shown in the following<= /span>

   example.  Supposing t= here are two TE-links (A and B) with MAX LSP

<= /div>

   Bandwidth equal to 10 Gbps each. = ; In case 50Gbps of Unreserved

   Bandwidth are available on Link A, 10Gbps on Link B= and 3 ODUflex

 = ;  LSPs of 10 GBps each, have to be restored, for sure only one can be=

   restor= ed along Link B and it is probable (but not sure) that two of<= /o:p>

   them can be restored= along Link A.

 = ;

Early pro= posal was to have, in the case of variable containers advertisements (i.e. = ODUflex), the MAX LSP bandwidth TLV (Type 3) as a mandatory piece of inform= ation and the Unreserved bandiwdth TLV (Type 2) as an optional piece of inf= ormation.

The comme= nt received is that optional information can lead to interworking issues an= d the counter proposal was to have both pieces of information as mandatory = and, as a consequence, merge the two TLVs into a single one.

 

<= div>

We'd like to hear the opinion of the WG on both i= ssues before proceeding with any modification to the document.

= --_000_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_-- --_005_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=798; creation-date="Mon, 28 Nov 2011 16:45:01 GMT"; modification-date="Mon, 28 Nov 2011 16:45:01 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAADAP8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0DxiM awTzyg7+1cvJRRXwWN/3yp6sxqFaSqslFFa0Tz6hVkqrJRRXp0jgqFaSqzdaKK9OkefUG0UUV30z EWloortpiCloorupiCloortpgRNUL0UVqbwIHqBqKKR2QIGqB6KKR2QIGqFutFFI7KYoqQUUVjI9 XDkgqQUUVzTPaw5ItSLRRXNI9vDki16n8FEB1XVXyciBB9445Y9unb/OaKK5Zm2Z/wC4VPl+aP/Z --_005_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2695; creation-date="Mon, 28 Nov 2011 16:45:02 GMT"; modification-date="Mon, 28 Nov 2011 16:45:02 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABRAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz6TVN QErj7fdfeP8Ay2b/ABpv9q6h/wA/91/3+b/Gq0v+uf8A3jTK96yPLuy5/amof8/91/3+b/Gj+1NR /wCf+6/7/N/jS6XpV9reoxafp1u091Lnai8cDqSewHrXqehfAu5k2y67qawr1MFoNzfQuePyBrOd SnT+IuEJy2PKv7V1DIH2+6yeAPObn9ac2pamjlHvLxGHVWkYEfga+kbXw74J8CWwuXisrRgP+Pi7 cNI30Lc/lXj/AMVPFWjeKdZtJNHUyLbxsklyU2+YSeAM8kDB596zp1lUlaMdO5c6XJG7epxv9qah /wA/91/3+b/Gj+1NQ/5/7r/v83+NVKK6LIxuz638LMz+EdFZmLMbCAkk5JPlrWtWR4V/5E/RP+vC D/0Wta9eHL4menHZBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+NJf9c/+8abTpf9c/8AvGm1755Ru+DdZ1HQfE9reaVafbLo5iFsFJMgbqBjn3z7V7as fxH8TKPMks/DNm3UIPOuCP5CvFfBXiP/AIRXxRb6obU3ShWiaJfvENx8vvXtS+JfHHiRQNB8PJpN qw/4/NVb5seqxjn864sSnzXSXqzqotctrlux+GvhvTZDqGrvLqt0vLXWqTbwPfB4FeU/Fi78NXWu 2v8Awjwti6Rst09qoEZORtHHBI56V6dF8Mv7SlW48W67fa1IOfIL+VAPoq9vyrzD4r6N4d0XW7SD QRFE5iP2m3hfcsZB+U+xPPHtUYdp1NZNv8CqqahtY4Cloor0DjPrbwr/AMifon/XhB/6LWtesjwr /wAifon/AF4Qf+i1rXrwpfEz1I7IKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHxpL/rX/AN402rNvatfarDZxsFe4nESs3QFmwM/nXWTfDe6j1y20dNZs ZbyeZoSqxyARlVLEkkYI+XHHrXuOcY6M8xRb2M7wHrth4b8XWup6jA0tsispKruMZIwHA74/rXp2 ufHPT4A0eh6fLdv2muP3afl94/pXnz/Dm/EsAi1Kxngnt57iOdN4BEON6lSAQeeDVa48EzWVpbfb dX0+31K6jSWHTXLGVgxwoJAwpOehrGcaNSXMzWLqRVkJrnxC8T+INyXWpyQwN/ywtf3S/jjk/ia5 eu2f4bXg15NGj1aykvQjSXCeXIvkKoBJ5HzjkD5e9VLfwT5/224Ou2EOl2jpE9/Kkiq0jdECEbsj IznpmtIzpxXukOM29TlaK7Kb4Z65BY6xcs9uzaWRvjQljKpUNuQ9xtOfwNc/r+iz+HtYl024ljll jRHLx52kMoYdfrVRqRk7JkuElqz6k8K/8ifon/XhB/6LWtesjwr/AMifon/XhB/6LWtevFl8TPSj sgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfHtpdf YdZt7zZv+z3Cy7M43bWzj9K7y6+KMVxr9lqw0/UCba4afyJr/fH8yMuFXbhfvV51L/rn/wB402vc lTjLVnmRm46I7sfEmSZ7W5v7GS5vobS5s2uDMAZElPy5GOq/rVDU/FOk67BBcarosz6vFAkBuoLs okgXozLjg49K5OkpKlBaoftJPc9AuviJaXSabbmy1UQWLvIk51DN0GIwAJMfdA7HOePSk1H4jWmu G+tdX0RptMuWikWOK42yq8YxuL4w24cGuBopexh2H7WR6BJ8VLxrh7iOwWNzfRXCKsmVEKR+X5R4 5yCeffpXMeK9dXxL4judWS2+zLMqKId27aFUDr+FY1FONKMXdITnKSsz628K/wDIn6J/14Qf+i1r XrI8K/8AIn6J/wBeEH/ota168aXxM9GOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQB8aS/65/wDeNNp0v+tf/eNNr3zygooooAKKKKACkpaKAPrbwr/y J+if9eEH/ota16yPCv8AyJ+if9eEH/ota168KXxM9SOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8kyf61/9402iivbPMCiiigAooooAKDRRQB9R+Gf +RU0f/rxh/8AQBWrRRXiy3Z6S2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2Q== --_005_5E893DB832F57341992548CDBB333163A4B531CFE6EMBX01HQjnprn_-- From jdrake@juniper.net Mon Nov 28 08:55:01 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F321F8CBD for ; Mon, 28 Nov 2011 08:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSRm7iQDpP40 for ; Mon, 28 Nov 2011 08:54:59 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 95F3221F8531 for ; Mon, 28 Nov 2011 08:54:59 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTtO82ssFbP/ovSZgeUS6eACHTYzdGvnr@postini.com; Mon, 28 Nov 2011 08:54:59 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 28 Nov 2011 08:53:18 -0800 From: John E Drake To: "BELOTTI, SERGIO (SERGIO)" , CCAMP Date: Mon, 28 Nov 2011 08:53:19 -0800 Thread-Topic: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 Thread-Index: AcyrT5Fr8/K9YKXwSVajMEKWu/H2CQCnmHnQ Message-ID: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A4B531CFFCEMBX01HQjnprn_" MIME-Version: 1.0 Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 16:55:01 -0000 --_000_5E893DB832F57341992548CDBB333163A4B531CFFCEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would suggest that those folks with deployed G.709v1 networks write an I-= D detailing their requirements for an interworking function. From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B= ELOTTI, SERGIO (SERGIO) Sent: Friday, November 25, 2011 12:53 AM To: CCAMP Subject: [CCAMP] Framework and Information model for G.709 Optical Transpor= t Networks (OTN) consideration post-IETF82 Hi CCAMP, as outcome of the Framework and Information model for G.709 Optical Transpo= rt Networks (OTN) presentation, Lou Berger asked co-authors to provide a ne= w section in the framework document dealing with backward compatibility, as= summary with respect to what is already present/will be present in the en= coding documents. In our opinion, the first thing to do is deciding which are the scenarios t= hat have to be taken into account. As hypothesis we would like to consider network element domains composed e= ither of G.709v1 or G709v3 network elements, so without having a mix of network element in the same domains. The motivat= ion for this is that operators would not be happy with the mix because managing control plane versions imp= lementing very different features is not practical from a network operation point of view. Please note that backward compatibility issues are to be considered between= GMPLS versions. So for G.709v1 NE we mean a network element with G.709v1 HW and support of RFC4328 only. The case of a NE with G709v1 HW supporting our GMPLS drafts does not have b= ackward compatibility issues because it can be considered as a new node wi= th limitations. Said this the candidate scenarios may be: 1) Interworking between a G.709v1 domain with a G.709v3 domain (path is te= rminated by one G.709v1 node and G.709v3 node) 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - G709v= 1 domain (G.709v3 domain in the middle of two G.709v1 domains. The path bei= ng terminated on G.709v1 equipment.) We'd like to hear the opinion of the WG whether CCAMP consider exhaustive t= he type of scenarios proposed, before proceeding with any modification to t= he document. Thanks Sergio and co-authors SERGIO BELOTTI ALCATEL-LUCENT Terrestrial System Architect Optics Portfolio Evolution via Trento 30 , Vimercate(MI) Italy T: +39 0396863033 Sergio.Belotti@alcatel-lucent.com --_000_5E893DB832F57341992548CDBB333163A4B531CFFCEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would s= uggest that those folks with deployed G.709v1 networks write an I-D detaili= ng their requirements for an interworking function.

 

=

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.= org] On Behalf Of BELOTTI, SERGIO (SERGIO)
Sent: Friday, N= ovember 25, 2011 12:53 AM
To: CCAMP
Subject: [CCAMP] Fr= amework and Information model for G.709 Optical Transport Networks (OTN) co= nsideration post-IETF82

 

Hi CCAMP,

 

a= s outcome of the Framework and Information model for G.709 Optical Transpor= t Networks (OTN) presentation, Lou Berger asked co-authors to provide a new= section in the framework document dealing with backward compatibility, as = summary with respect to what is already present/will be present in the = ; encoding documents.

=  

In our opinion, the first thing= to do is deciding which are the scenarios that have to be taken into accou= nt.

 

As hypothesis we would like to consider network e= lement domains  composed either of G.709v1 or G709v3 network elements,=

so without having a mix of ne= twork element in the same domains. The motivation for this is that operator= s

would not be happy with the = mix because managing control plane versions implementing very different fea= tures

is not practical from a = network operation point of view. 

 

Please note t= hat backward compatibility issues are to be considered between GMPLS versio= ns. So for G.709v1 NE we mean

= a network element with G.709v1 HW and support of RFC4328 only. <= /span>

 

The case of a NE with G709v1 HW supporting our GMPLS drafts does= not have backward compatibility issues because it can be considered as a n= ew  node with limitations.

 

Said this the candi= date scenarios may be:

 <= o:p>

1)  Interworking between = a G.709v1 domain with a G.709v3 domain (path is terminated by one G.709v1 n= ode and G.709v3  node)

&n= bsp;

2) Interworking in the ca= se of  a G.709v1 domain – a G.709v3 domain – G709v1 domain= (G.709v3 domain in the middle of two G.709v1 domains. The path being termi= nated on G.709v1 equipment.)

&n= bsp;

We'd like to hear the opin= ion of the WG whether CCAMP consider exhaustive the type of scenarios propo= sed, before proceeding with any modification to the document.

 

Thanks

 <= /span>

Sergio and co-authors

 

=  

SERGIO BELOTTI

 

ALCATEL-LUCENT

=

Terrestrial System Architect

Optics Portfolio Evolution=

 <= /p>

via Trento 30 , Vimercate(MI) = Italy

T: +39 0396= 863033

Sergio= .Belotti@alcatel-lucent.com

 

 

 <= /p>

 

 

= --_000_5E893DB832F57341992548CDBB333163A4B531CFFCEMBX01HQjnprn_-- From prvs=5313044d90=lyong@ciena.com Mon Nov 28 10:04:50 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC73E21F8D28 for ; Mon, 28 Nov 2011 10:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.844 X-Spam-Level: X-Spam-Status: No, score=-100.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTP7H5hkb3+F for ; Mon, 28 Nov 2011 10:04:49 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8704821F8B95 for ; Mon, 28 Nov 2011 10:04:49 -0800 (PST) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id pASHxhgG018596; Mon, 28 Nov 2011 13:04:45 -0500 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 11cd0tgdy8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Nov 2011 13:04:44 -0500 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Mon, 28 Nov 2011 13:04:42 -0500 From: "Ong, Lyndon" To: John E Drake , Daniele Ceccarelli , CCAMP Content-Class: urn:content-classes:message Date: Mon, 28 Nov 2011 13:04:45 -0500 Thread-Topic: OSPF OTN considerations post IETF 82 Thread-Index: AcypvXUM4uURSfqEQWyExafq21g2KwAAy7kQABLVdSAA+DFBkAAC1yZg Message-ID: References: <5E893DB832F57341992548CDBB333163A4B531CFE6@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B531CFE6@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18548.001 x-tm-as-result: No--62.252100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_006_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_"; type="multipart/alternative" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2011-11-28_06:2011-11-28, 2011-11-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1111280171 Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:04:50 -0000 --_006_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_ Content-Type: multipart/alternative; boundary="_000_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_" --_000_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this also. Cheers, Lyndon [cid:image83b7f5.gif@c7a64d04.53b446a2] From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Monday, November 28, 2011 8:45 AM To: Daniele Ceccarelli; CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 Daniele, A single switching capability value and advertise both Unreserved and Max = LSP bandwidth. Thanks, John From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of D= aniele Ceccarelli Sent: Wednesday, November 23, 2011 10:19 AM To: CCAMP Subject: [CCAMP] OSPF OTN considerations post IETF 82 Hi CCAMP, During the OTN OSPF draft presentation at the IETF meeting in Taipei two co= mments were raised with respect to the following issues: - Issue 1: Using different switching caps for each ODU type - Issue 2: Type 2 (unres bandwidth for variable containers) and Type 3 (MAX= LSP bandwidth foe variable containers always used in tandem? WRT issue 1: the proposal was to indicate the bottom most ODUk of the muxin= g hiearachy in the Switching Capability field of the ISCD. After a quick ta= lk with the other authors of the ID, the idea was to reject the proposal as= it would lead to an overloading of the meaning of the Switching Capability= field. (even if the definition of PSC1-2-3-4 already overloads the meaning= of the switching capability field) WRT issue 2: it is analyzed in section 5.3 of the draft (version -00). I'm = copying it below for your convenience In this example the advertisement of an ODUflex->ODU3 hierarchy is shown. In case of ODUflex advertisement the MAX LSP bandwidth needs to be advertised but in some cases also information about the Unreserved bandwidth could be useful. The amount of Unreserved bandwidth does not give a clear indication of how many ODUflex LSP can be set up either at the MAX LSP Bandwidth or at different rates, as it gives no information about the spatial allocation of the free TSs. An indication of the amount of Unreserved bandwidth could be useful during the path computation process, as shown in the following example. Supposing there are two TE-links (A and B) with MAX LSP Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex LSPs of 10 GBps each, have to be restored, for sure only one can be restored along Link B and it is probable (but not sure) that two of them can be restored along Link A. Early proposal was to have, in the case of variable containers advertisemen= ts (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as a mandatory piece = of information and the Unreserved bandiwdth TLV (Type 2) as an optional pie= ce of information. The comment received is that optional information can lead to interworking = issues and the counter proposal was to have both pieces of information as m= andatory and, as a consequence, merge the two TLVs into a single one. We'd like to hear the opinion of the WG on both issues before proceeding wi= th any modification to the document. Thanks, Daniele DANIELE CECCARELLI System & Technology - DU IP & Broadband Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com [cid:image002.jpg@01CCADB5.27DB96D0] This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I support this also.

 

Cheers,

 

Lyndon

 


3D"ciena

From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sent= : Monday, November 28, 2011 8:45 AM
To: Daniele Ceccarelli; C= CAMP
Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82

 

Daniele,

 

A single s= witching capability value and  advertise both Unreserved and Max LSP b= andwidth.

 

Thanks,

 

John

 <= /span>

From: ccamp-bounces@ietf= .org [mailto:ccamp-bounces@ietf.org] On Behalf Of Daniele Ceccarelli=
Sent: Wednesday, November 23, 2011 10:19 AM
To: CCAMP<= br>Subject: [CCAMP] OSPF OTN considerations post IETF 82<= /span>

 

Hi CCAMP,

 =

During the OTN OSPF = draft presentation at the IETF meeting in Taipei two comments were raised w= ith respect to the following issues:

 

- Issue 1: Using different switching caps for each ODU type

- Issue 2: Type 2 (unres bandwidth= for variable containers) and Type 3 (MAX LSP bandwidth foe variable contai= ners always used in tandem?

 

WRT iss= ue 1: the proposal was to indicate the bottom most ODUk of the muxing hiear= achy in the Switching Capability field of the ISCD. After a quick talk with= the other authors of the ID, the idea was to reject the proposal as it wou= ld lead to an overloading of the meaning of the Switching Capability field.= (even if the definition of PSC1-2-3-4 already overloads the meaning of the= switching capability field)

 

WRT is= sue 2: it is analyzed in section 5.3 of the draft (version -00). I'm copyin= g it below for your convenience

 

 &nbs= p; In this example the advertisement of an ODUflex->ODU3 hierarchy is

   shown.&nb= sp; In case of ODUflex advertisement the MAX LSP bandwidth needs

   to be advertised = but in some cases also information about the

<= /div>

   Unreserved bandwidth could be useful.=   The amount of Unreserved

   bandwidth does not give a clear indication of how = many ODUflex LSP

&nb= sp;  can be set up either at the MAX LSP Bandwidth or at different rat= es,

   as = it gives no information about the spatial allocation of the free

   TSs.=

 =

   An indication of the amount of U= nreserved bandwidth could be useful

   during the path computation process, as shown = in the following

&nb= sp;  example.  Supposing there are two TE-links (A and B) with MA= X LSP

   B= andwidth equal to 10 Gbps each.  In case 50Gbps of Unreserved<= o:p>

   Bandwidth are = available on Link A, 10Gbps on Link B and 3 ODUflex

   LSPs of 10 GBps each, have to = be restored, for sure only one can be

   restored along Link B and it is probable (bu= t not sure) that two of

   them can be restored along Link A.

 

<= div>

Early proposal was to have, in the case of variab= le containers advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Typ= e 3) as a mandatory piece of information and the Unreserved bandiwdth TLV (= Type 2) as an optional piece of information.

The comment received is that optional information c= an lead to interworking issues and the counter proposal was to have both pi= eces of information as mandatory and, as a consequence, merge the two TLVs = into a single one.

&n= bsp;

We'd like to hea= r the opinion of the WG on both issues before proceeding with any modificat= ion to the document.

<= span lang=3DIT style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>=  

Thanks,

Daniele

 

<= p class=3DMsoNormal>


DANIELE CECCARELLI
System & Technology - DU IP &= Broadband =


Via L.Calda, 5
Genova, Italy
= Phone +390106002512
Mobile +393346725750
daniele.ceccarelli@ericsson.= com
w= ww.ericsson.com =




= This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer

 


= --_000_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_-- --_006_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=798; creation-date="Mon, 28 Nov 2011 13:04:41 GMT"; modification-date="Mon, 28 Nov 2011 13:04:41 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAADAP8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0DxiM awTzyg7+1cvJRRXwWN/3yp6sxqFaSqslFFa0Tz6hVkqrJRRXp0jgqFaSqzdaKK9OkefUG0UUV30z EWloortpiCloorupiCloortpgRNUL0UVqbwIHqBqKKR2QIGqB6KKR2QIGqFutFFI7KYoqQUUVjI9 XDkgqQUUVzTPaw5ItSLRRXNI9vDki16n8FEB1XVXyciBB9445Y9unb/OaKK5Zm2Z/wC4VPl+aP/Z --_006_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2695; creation-date="Mon, 28 Nov 2011 13:04:41 GMT"; modification-date="Mon, 28 Nov 2011 13:04:41 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABRAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz6TVN QErj7fdfeP8Ay2b/ABpv9q6h/wA/91/3+b/Gq0v+uf8A3jTK96yPLuy5/amof8/91/3+b/Gj+1NR /wCf+6/7/N/jS6XpV9reoxafp1u091Lnai8cDqSewHrXqehfAu5k2y67qawr1MFoNzfQuePyBrOd SnT+IuEJy2PKv7V1DIH2+6yeAPObn9ac2pamjlHvLxGHVWkYEfga+kbXw74J8CWwuXisrRgP+Pi7 cNI30Lc/lXj/AMVPFWjeKdZtJNHUyLbxsklyU2+YSeAM8kDB596zp1lUlaMdO5c6XJG7epxv9qah /wA/91/3+b/Gj+1NQ/5/7r/v83+NVKK6LIxuz638LMz+EdFZmLMbCAkk5JPlrWtWR4V/5E/RP+vC D/0Wta9eHL4menHZBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+NJf9c/+8abTpf9c/8AvGm1755Ru+DdZ1HQfE9reaVafbLo5iFsFJMgbqBjn3z7V7as fxH8TKPMks/DNm3UIPOuCP5CvFfBXiP/AIRXxRb6obU3ShWiaJfvENx8vvXtS+JfHHiRQNB8PJpN qw/4/NVb5seqxjn864sSnzXSXqzqotctrlux+GvhvTZDqGrvLqt0vLXWqTbwPfB4FeU/Fi78NXWu 2v8Awjwti6Rst09qoEZORtHHBI56V6dF8Mv7SlW48W67fa1IOfIL+VAPoq9vyrzD4r6N4d0XW7SD QRFE5iP2m3hfcsZB+U+xPPHtUYdp1NZNv8CqqahtY4Cloor0DjPrbwr/AMifon/XhB/6LWtesjwr /wAifon/AF4Qf+i1rXrwpfEz1I7IKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHxpL/rX/AN402rNvatfarDZxsFe4nESs3QFmwM/nXWTfDe6j1y20dNZs ZbyeZoSqxyARlVLEkkYI+XHHrXuOcY6M8xRb2M7wHrth4b8XWup6jA0tsispKruMZIwHA74/rXp2 ufHPT4A0eh6fLdv2muP3afl94/pXnz/Dm/EsAi1Kxngnt57iOdN4BEON6lSAQeeDVa48EzWVpbfb dX0+31K6jSWHTXLGVgxwoJAwpOehrGcaNSXMzWLqRVkJrnxC8T+INyXWpyQwN/ywtf3S/jjk/ia5 eu2f4bXg15NGj1aykvQjSXCeXIvkKoBJ5HzjkD5e9VLfwT5/224Ou2EOl2jpE9/Kkiq0jdECEbsj IznpmtIzpxXukOM29TlaK7Kb4Z65BY6xcs9uzaWRvjQljKpUNuQ9xtOfwNc/r+iz+HtYl024ljll jRHLx52kMoYdfrVRqRk7JkuElqz6k8K/8ifon/XhB/6LWtesjwr/AMifon/XhB/6LWtevFl8TPSj sgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfHtpdf YdZt7zZv+z3Cy7M43bWzj9K7y6+KMVxr9lqw0/UCba4afyJr/fH8yMuFXbhfvV51L/rn/wB402vc lTjLVnmRm46I7sfEmSZ7W5v7GS5vobS5s2uDMAZElPy5GOq/rVDU/FOk67BBcarosz6vFAkBuoLs okgXozLjg49K5OkpKlBaoftJPc9AuviJaXSabbmy1UQWLvIk51DN0GIwAJMfdA7HOePSk1H4jWmu G+tdX0RptMuWikWOK42yq8YxuL4w24cGuBopexh2H7WR6BJ8VLxrh7iOwWNzfRXCKsmVEKR+X5R4 5yCeffpXMeK9dXxL4judWS2+zLMqKId27aFUDr+FY1FONKMXdITnKSsz628K/wDIn6J/14Qf+i1r XrI8K/8AIn6J/wBeEH/ota168aXxM9GOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQB8aS/65/wDeNNp0v+tf/eNNr3zygooooAKKKKACkpaKAPrbwr/y J+if9eEH/ota16yPCv8AyJ+if9eEH/ota168KXxM9SOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8kyf61/9402iivbPMCiiigAooooAKDRRQB9R+Gf +RU0f/rxh/8AQBWrRRXiy3Z6S2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2Q== --_006_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_ Content-Type: image/gif; name="image83b7f5.gif@c7a64d04.53b446a2" Content-Description: image83b7f5.gif@c7a64d04.53b446a2 Content-Disposition: inline; filename="image83b7f5.gif@c7a64d04.53b446a2"; size=3410; creation-date="Mon, 28 Nov 2011 13:04:42 GMT"; modification-date="Mon, 28 Nov 2011 13:04:42 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlh3AAeAPcAANINQfb29uiCnuqVq9AALPXb4vLBzCopFcsAGbOyq+dmc8nJxeJig8gAB/3/ //TS2/r2+Pr5+eydsuZ8mauqo++0w2JiVBgXAuVyke6qvGtqXdMSRru6s/z///np7dEIPtrZ1vG9 y4yLgfru8dXU0kxKOtEANfz5+kNCMdMQRNLRzuFVeu2htFpaTPfh6NAAMdw6ZfLE0fjl6umNps8A LeTk4tQUSVNSQzw7Kfr19u6luc4AKfTO2fC1xPGqspyblIWEeuHh3s0AJdoyWc7OytosWd5BbPLx 8ZaVjHZ1aXt6bvn39+FZfunq6dglU6alnuHh4MXGwds0YYKBdvz8/NIFPDUzIc8AMPGzus0AIOh+ mtAAA9IKQAMCAMLCvfTK1d5JcuFSdNUEF9orVeno5umFoPTM1pSUitgeUOqKpPry9u7u7L6+uPnx 8vXW36KhmXJxZSMiDn18cd7d2ubm5N9SedUNQt/f3Od5l/fe5Pfi5uNmiMTEvuNqidEAOO+jqvz+ /JKRiNUbR+JdgdMRRe3s65iXjtIUNaCfl9IEOueAnOVWZeRpivff5dcbTdckTdjX0/PI0+VvjdMO Q7e1sNYYTNIAOJGQhtrb2I+OhdQKQGZlWOzr6nh3a9YSQuqKo9ECOmBfUKWjneRpjP39/szMxjk5 J9ICOPT08/Dw7/Xz9eRwj4mJfz8+LcDAutMSRdMQRjIxH9MQQW5tX4iGe9DPy2loW0JAMP36/OBO dOqPp6ion6Sim/PM18jHwt09Z5mZj15dTtMUR9ICO9ACOVhXSNMEPEdFNh4dCcwAHy8uGzc2JcTD vvz19//9/4B/dNzb2ZSTidIBO/f39rCvqdYYQ1BPP++xwPv7/NQANueMo8/RzdfY1Ofo5Orn50lI OdEDO+yYr/C4xlBOP7i3sfz9/FdZSFpXR/Cuwf78/dAEMdIHNhAOAOLk4P7//uPj4NggUfDv7tkn V+qRqO6dpfv7+pOUi8jIxOZ3lN9IbqOjm+6uv8vKxudwhKmooP///yH5BAAAAAAALAAAAADcAB4A AAj/AP8JHEiw4MAObUgZXMiwocOHECNKnEixosWLGDO6YSRlRYyMIEOKHEmypEmLjdAkI5CsiriT MGPKnEkzpDtFLTcQQpDPQc2fQIMKJemuDoFXr2zsKAJhqNOnUKP+u4mgig1YCHL5lMq1q9eRMuQh GAvg49ezaNM+dIEnzJ5IauPKjeqg7taK7to84MHDxV2I7upCtOvA3dzDQiOEmMGI0Z49M67JmCpj RLMRMk4sjMHEBpdJmiaBMUDQRYwvZr4Y8PDPATp8DBjNK1DQHSAZPebh2zOKkRYWehALj+lAghQT O2hcoUFjBwJJ/x7Iq1QEnqMKBTvgeyHkhZ/vJrqH/xs4IZudFKcIXHO3gkByAkI0jReYLlw+eC+S X1nunhCepsMFGBI2gwixAzgATDJJCilMggAT//QCH3JCsECQA0xkYcIkGwhDyAYbyJKFHW4IhAEB JoDywgur1CGEHwpOAkByGQjkQiUImPBBggvKyAUNCPyihoBEWtQBEzl+COIkXHCRQjJ9RGeHHxt8 YEmNArmDRxangEgIOMpxUaUQihimhSWEpLmBDcN8kIIwOoEohDxDuiCPCQBwUUUibU4C5wbEIDBK kYRKJEEWoAjzygaTmHDFii80sIKUVFqJ5T8GmPDCoim8oMkKYFQxCSHJ1GEmmmoCoOkVfnxIiDCg mP8Qwj8u2JAMcx94AksiL4j5KgGy0FbosAudMIQQHm7wIzwT6KDDDGNA9wAAlV6ZJRNCpKATDWjM +g8DeJZ6apqEpGCCI3sw4sgLrnJxhS7/5FHEL5/sE8MDDxgArpgbVPGChcQGPFAMO8Dy4SQvMMHa QJf9w8OUVVqyj0AyVPMCiCac8pJA87C6QxnjEvKKH5WQ9k8kaJiQ5iQ0aPFPOY0wNAgNIAJAgACG CRzwADt4SMgVUkTAkBkQc2ECwNeYAA6jNICx1QnH0eCJsGeKDAANqxA0wQ5isqzIQA7EUAYDKzDw SS8CvMDhjDjrHPAeJix69QQNEU3lJASUIVAaBHD/IQwAV2Q9FSMvIKe3QFUrS8AABM3DNdNf/xMD DCvusIOB0mzA4AY2t+32sODK/QK8Q0/5yiRXHC7ADgCcvsOk/2BQuBAr3JU4FwTMkPM/aQjRNQ0C /POFMS8m+AIN8F2RbOe7w9T85yetcvHpNEBXuh+np87xFb6+4IQ4DBDwQhYwAIg4morrPlDvXef+ jxFZaEuIJVIoopsUxmjLPEYj/IFFOQypxSZqwRV+2OIeJinFEwJQEF50ggxe4MBEJICsD5nABl8o 3SnStAPrheAUidBJCmDxgUfRIBdtKMjtcrc79nGOBhIYgSbiRgg/yGNh/9DBDtZ2s+dJpB6L2MIW /+hBkHiIoBT/oEYXKCESciDBhxHxRxcQYZJNsIMEBQnGBXzxjVYohCBP8MdCeNA3nRDiBfDYh2am wpd/mEETrdqACYqQg38AoghXUFMKuGAMG2iDIF8AmQDQhzv17c13jLoCC3phDGmU6wV7IMge8si5 Hl4kD2LYQgMWcRdqsCMJ/2ADMngBgiYIZAnMIGARydAEftBBIJxgwxz+sYRxIKMUR4AGLv4BhRr8 IwCYEEgp+CC0I9BhDZj4ATIS8A9MQAMbA1lCFBaQDlV0owlReMdAVOCFIwxkAQtI4hSgyQ9XLOEf cDjAO/xhiKkwgx//IMMylgEJZxSkHDDIApweaf+CX/ShDwxQx6T0YAOVpckEdQjBPqSAPTPWEAYe 6IAHQqAFddDgBGkgJAvXh0jUseABxhjGK+ZXBBe0RgJ+WFolPVcRB/RjC2LwwUDucIw4KMMebDhA Kw5wA1TEwwKtwEE7ByKKW5TgANaYBhGsgYJvsEEfB4hDKEQQCwr8owQl+McZSgCCKcQBGcFYQwJu cYxxKOEWXkhAHH6QsxrYYhlW4AMFjvGNOJhiG/9AwjFuYQFUOGMWF0DGG5CggWkYogStCAUqgKCM d0QDCAFIZwmoAYSoctUgGcgCDWwQpw/QIAvJEEIDGPCPDsBgBx96BQAKlz/NyY9BhBCEEx6RiCv/ NOAQvDuF3Da6N64Jg2USyIEmXuAhczmBEXX4zgZ2GzyMUCESZiDINAJxAA2AwAsXSIISLiAKVrBD CSjogisGcokuaCAJyDDEJuLAijgcwBehiEUCIHGAYnDgqxz4hgUygYwpKFMOP+jCDdiAiFaYIxab WMNAdtEFFDxjGmfIrj6kSok4FGMWXWDFJdgxBWDUwhZxwIYontEJdlCDFVaYQwvGkQB2WEEENSDC LW5BgVQYxB0TQMAO3iSMHtvABpUQAmn/EY4ssKvHwvhAFT6Qnx184FV/MwENXnAFEzRgCA4oAyF3 YMh/fMLJL0zDP+qAgA/0+IzweZHmKqm3POgA/4cgaccy/8GHC2jTFEAIxQFYkQQckGMg9rhADZqA Alsc4xhIaMEN/kGLWwgECQfAgQVacAtTEGEWyxBIKMYRjVjMkhmxCCw0CNKNJBSjGFFAAg4K8Y9O WEEDB7AFEIoBBMQORAmtuAMQkiCCZeiDFqaAwixCEYBnWOMcEmzBJhriDgGoYyVKA0UiTmHlMBjG AYMI7aM0RQMhVCEXv8iCEFhVhSr4gTvrGMQD/iGJZOwAPg1orkAm0IBkXEG0GPiHHpygYxNUARQ7 yII88vlu0eLhH/gwAekmEgH//UUF7DgGCJR4D1RcgBW0YIcInpEJBgpEDl24QxDikIT1vqETT//4 hwa6YIgIkAEZXUhAILqgjH8Ygh1AQAIy5CACdnDjH0/gcAmUgUWBHOEHnehCC0SgDCVQIA4WuG8o gPEMMoigC0D4gQosYApDdCEJwGAHEpSADBLcwNG8wHAr/nEDZOiDEw2JxCAEkQ0/WMISeBrDpTow DynIQhMAEMQvJhADdzRDF373gwnMU4RVwEUg4ZCCEYwAgyLoYHc6kMcvjPCLIkjARgwQBLUtUQ0m NCIE86K85XNohI1J5AQKEOIfdneETXTBFuRQxj28YQUKTCMUprBCIAgSCGVAAwQoeMIdvoGDW0hw F4Hlwz82cQBO0LcT/4iABpBxgWAEwB/KwCv/NYjuiu8OpBTHwMEBKPEDK7QCGcpQgc1NkdhzWoAd 7EDEFG6ggmJ8QwPLsAuZcAvcAAebQALWEAuxQEU3Fwfyx2y44Sw6cA1uoAbPowYF8AV9YT4C0Qxu UAEskAEPMAIFcQJtAAFLkAMjsEsDcQIjkAMQAAEjsEatIQMGwAIVkAeG4Q4jgIIqqBmAMAJQ1BCY JEScRBCqsAAgQArtoBBBMA2/NE02NhBHEARTUQNQyAleoAJC4w4g4Auo8A/GJBA14HHlUAv8AIXT AAVU8A/TYIX/cAd38EXTQAJeMEuBEAscAA1w+A8kwAe+9A9UsABEMA2o0A1ieA930AT1oAqvL7QG hUAF3OAKsySIKsAPQgM9J+EAsRdTOkMLB0AEmjgsJ4AFITCERAIJlGBKThEQADs= --_006_A0B4FC0A5EFBD44585414760DB4FD2743350851AMDWEXGMB02ciena_-- From lberger@labn.net Tue Nov 29 03:50:19 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E0621F85B9 for ; Tue, 29 Nov 2011 03:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWRu9dRfgXHv for ; Tue, 29 Nov 2011 03:50:19 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 0CB9121F8557 for ; Tue, 29 Nov 2011 03:50:18 -0800 (PST) Received: (qmail 19882 invoked by uid 0); 29 Nov 2011 11:50:18 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 29 Nov 2011 11:50:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BVwM90c20D44lOS9WnLUenNteAfFZh3ZMowKQWgKkpo=; b=anAn22Vg90YbpeLTVD02TYinZmbWdLLP2sp/uFj/fvFQaXbwRhm0k/3mHrELclnBgCxmfI+cPr1RUbXyRUGOfTjZ74FLv5n6tH6jybZxz3XVNaLN/nXE5RwaUWIcA0EC; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVMCY-0006WG-Ev; Tue, 29 Nov 2011 04:50:18 -0700 Message-ID: <4ED4C6FE.4040505@labn.net> Date: Tue, 29 Nov 2011 06:50:22 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Acee Lindem References: <6343326C-9EFD-4F25-BBE4-E5001887A794@ericsson.com> <2D6BCF8B-F6AF-40C0-8E63-5AEB29B8D02A@ericsson.com> In-Reply-To: <2D6BCF8B-F6AF-40C0-8E63-5AEB29B8D02A@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ospf@ietf.org List" , "ccamp@ietf.org" Subject: Re: [CCAMP] [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 11:50:19 -0000 Acee, Don't you think that addressing the second is a major change enough change that it should be done in a standalone draft? Lou On 11/28/2011 9:58 AM, Acee Lindem wrote: > Hi Fatai, > We have two separate requirements here. The ASON requirement is to be > able to advertise reachability information for multiple ASON transport > nodes. As you've noted, there has been an independent requirement to > advertise more information than will fit in a single LSA. Our draft only > addresses the first. However, we'll consider this when addressing > Adrian's comments. Much of this depends on whether or not we do a second > review and WG last call. > Thanks, > Acee > > On Nov 27, 2011, at 10:11 PM, Zhangfatai wrote: > >> Hi all, >> >> Can this relaxation be applicable to all the future OSFPv2 documents ? >> >> >> >> >> Thanks >> >> Fatai >> >> *From:* ospf-bounces@ietf.org >> [mailto:ospf-bounces@ietf.org] *On >> Behalf Of *Acee Lindem >> *Sent:* 2011Äê11ÔÂ28ÈÕ 9:14 >> *To:* ospf@ietf.org List >> *Cc:* ccamp@ietf.org >> *Subject:* [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC >> 5787bis) will Update RFC 5786 >> >> Please note that this document relaxes the RFC 5786 restriction that >> a Node Attribute TLV may only appear in a single OSPF TE LSA. Here is >> the text: >> >> In order to support ASON reachability advertisement, the Node >> Attribute TLV defined in [RFC5786] is used to advertise the >> combination of a TE Router ID and its set of associated reachable >> address prefixes. The Node Attribute TLV can contain the following >> sub-TLVs: >> >> - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 >> - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] >> - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] >> >> A router may support multiple transport nodes as discussed in section >> 6, and, as a result, may be required to advertise reachability (ASON >> SNPPs) separately for each transport node. As a consequence, it MUST >> be possible for the router to originate more than one TE LSA >> containing the Node Attribute TLV when used for ASON reachability >> advertisement. >> >> Hence, the Node Attribute TLV [RFC5786] advertisement rules must be >> relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE >> LSA originated by the RC when the RC is advertising reachability >> information for a different transport node identified by the Local TE >> Router Sub-TLV (refer to section 6.1). >> Here is a link to the >> document: http://www.ietf.org/id/draft-ietf-ccamp-rfc5787bis-03.txt >> >> If you have any concerns with this change, please send them to this >> list with the CCAMP list copied. >> >> Thanks, >> Acee >> > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Tue Nov 29 04:01:45 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0779321F8C14 for ; Tue, 29 Nov 2011 04:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR4UCLkeY2hR for ; Tue, 29 Nov 2011 04:01:44 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 7F28021F8C1F for ; Tue, 29 Nov 2011 04:01:43 -0800 (PST) Received: (qmail 24559 invoked by uid 0); 29 Nov 2011 12:01:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 29 Nov 2011 12:01:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Uwywc1LEUfA/98YZXidPExC9AXzkGc7kqOy4gg15BzI=; b=S0roONpr5tw91R69/d+VDBePKAYBUXe/Dl3v2L8Zz7g+QHArPedqbxWKp+WROHr75aPpR5ajSZlipgN4aN1VocDWzOo6rWSXEIKKCWIKbZOKdckPF/4GXEzMr5Okdcau; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVMNb-0001Fx-3C; Tue, 29 Nov 2011 05:01:43 -0700 Message-ID: <4ED4C9A9.90809@labn.net> Date: Tue, 29 Nov 2011 07:01:45 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 12:01:45 -0000 Sergio, My comment actually comes from two meetings ago and was based on the routing and signaling drafts each having their own compatibility sections (sections 6 and 6.5, respectively), and the framework not having one at all. As you note, control plane compatibility is something typically addressed in GMPLS. I think the framework needs to cover what approach is being taken to ensure *control plane* operation when a pre-G709v3 GMPLS node exchanges CP messages with a G709v3 GMPLS node. In short, the framework should say *what* is being done with respect to CP compatibility, the routing and signaling documents should say *how* CP compatibility is supported. Note that my request was not about data plane compatibility. Lou On 11/25/2011 3:52 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi CCAMP, > > as outcome of the Framework and Information model for G.709 Optical > Transport Networks (OTN) presentation, Lou Berger asked co-authors to > provide a new section in the framework document dealing with backward > compatibility, as summary with respect to what is already present/will > be present in the encoding documents. > > In our opinion, the first thing to do is deciding which are the > scenarios that have to be taken into account. > > As hypothesis we would like to consider network element domains > composed either of G.709v1 or G709v3 network elements, > so without having a mix of network element in the same domains. The > motivation for this is that operators > would not be happy with the mix because managing control plane versions > implementing very different features > is not practical from a network operation point of view. > > Please note that backward compatibility issues are to be considered > between GMPLS versions. So for G.709v1 NE we mean > a network element with G.709v1 HW and support of RFC4328 only. > > The case of a NE with G709v1 HW supporting our GMPLS drafts does not > have backward compatibility issues because it can be considered as a > new node with limitations. > > Said this the candidate scenarios may be: > > 1) Interworking between a G.709v1 domain with a G.709v3 domain (path is > terminated by one G.709v1 node and G.709v3 node) > > 2) Interworking in the case of a G.709v1 domain – a G.709v3 domain – > G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. The > path being terminated on G.709v1 equipment.) > > We'd like to hear the opinion of the WG whether CCAMP consider > exhaustive the type of scenarios proposed, before proceeding with any > modification to the document. > > Thanks > > Sergio and co-authors > > > *SERGIO BELOTTI* > > ALCATEL-LUCENT > Terrestrial System Architect > Optics Portfolio Evolution > > via Trento 30 , Vimercate(MI) Italy > T: +39 0396863033 > *Sergio.Belotti@alcatel-lucent.com* > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Tue Nov 29 04:04:31 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E929F21F8A7E for ; Tue, 29 Nov 2011 04:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAZpbOhiZOfE for ; Tue, 29 Nov 2011 04:04:31 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 1FD2821F8A71 for ; Tue, 29 Nov 2011 04:04:31 -0800 (PST) Received: (qmail 27603 invoked by uid 0); 29 Nov 2011 12:04:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 29 Nov 2011 12:04:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=NI0VVlqHJ6Z6g3AdECWFESYzCdgx5nwGllzQSu2OgZM=; b=ocKkiGuX/OQHgM8YoBTXQA21vmFAd5yHLZNDrukHXNnvERWpzskYue88PYL2bRXwTaeg6/eGrPq1MxOMx89cMzUFHsWNaEI9F/wNGNNXiBBdewSgrh8JxfXweb4ChFsg; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVMQI-0001yY-Kc; Tue, 29 Nov 2011 05:04:30 -0700 Message-ID: <4ED4CA52.5060008@labn.net> Date: Tue, 29 Nov 2011 07:04:34 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 12:04:32 -0000 John, I think the gist of my comment (from 2 meetings ago) got lost. The WG needs to ensure that any changes / additions to GMPLS don't break existing GMPLS implementations. Please see the message I just sent to Sergio. Lou On 11/28/2011 11:53 AM, John E Drake wrote: > I would suggest that those folks with deployed G.709v1 networks write an > I-D detailing their requirements for an interworking function. > > > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > Behalf Of *BELOTTI, SERGIO (SERGIO) > *Sent:* Friday, November 25, 2011 12:53 AM > *To:* CCAMP > *Subject:* [CCAMP] Framework and Information model for G.709 Optical > Transport Networks (OTN) consideration post-IETF82 > > > > Hi CCAMP, > > > > as outcome of the Framework and Information model for G.709 Optical > Transport Networks (OTN) presentation, Lou Berger asked co-authors to > provide a new section in the framework document dealing with backward > compatibility, as summary with respect to what is already present/will > be present in the encoding documents. > > > > In our opinion, the first thing to do is deciding which are the > scenarios that have to be taken into account. > > > > As hypothesis we would like to consider network element domains > composed either of G.709v1 or G709v3 network elements, > > so without having a mix of network element in the same domains. The > motivation for this is that operators > > would not be happy with the mix because managing control plane versions > implementing very different features > > is not practical from a network operation point of view. > > > > Please note that backward compatibility issues are to be considered > between GMPLS versions. So for G.709v1 NE we mean > > a network element with G.709v1 HW and support of RFC4328 only. > > > > The case of a NE with G709v1 HW supporting our GMPLS drafts does not > have backward compatibility issues because it can be considered as a > new node with limitations. > > > > Said this the candidate scenarios may be: > > > > 1) Interworking between a G.709v1 domain with a G.709v3 domain (path is > terminated by one G.709v1 node and G.709v3 node) > > > > 2) Interworking in the case of a G.709v1 domain – a G.709v3 domain – > G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. The > path being terminated on G.709v1 equipment.) > > > > We'd like to hear the opinion of the WG whether CCAMP consider > exhaustive the type of scenarios proposed, before proceeding with any > modification to the document. > > > > Thanks > > > > Sergio and co-authors > > > > > > *SERGIO BELOTTI* > > > > ALCATEL-LUCENT > > Terrestrial System Architect > > Optics Portfolio Evolution > > > > via Trento 30 , Vimercate(MI) Italy > > T: +39 0396863033 > > *Sergio.Belotti@alcatel-lucent.com* > > > > > > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Tue Nov 29 05:27:00 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9E721F8BF9 for ; Tue, 29 Nov 2011 05:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K7SL0BoKyWT for ; Tue, 29 Nov 2011 05:27:00 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2777E21F8BF4 for ; Tue, 29 Nov 2011 05:27:00 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTtTdobwjlWuMfgY3DpqXiTWxHcPUL1Cj@postini.com; Tue, 29 Nov 2011 05:27:00 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 29 Nov 2011 05:24:11 -0800 From: John E Drake To: Lou Berger Date: Tue, 29 Nov 2011 05:24:10 -0800 Thread-Topic: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 Thread-Index: AcyujzKsPlqtBeaeRwyptSR9i+TJmwABQbBg Message-ID: <5E893DB832F57341992548CDBB333163A4B531D9F6@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> <4ED4CA52.5060008@labn.net> In-Reply-To: <4ED4CA52.5060008@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 13:27:01 -0000 Lou, My point was that control plane interoperability with G.709v1 is non-trivia= l and before we start working on it we should know whether anyone wants it. Thanks, John=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, November 29, 2011 4:05 AM > To: John E Drake > Cc: BELOTTI, SERGIO (SERGIO); CCAMP > Subject: Re: [CCAMP] Framework and Information model for G.709 Optical > Transport Networks (OTN) consideration post-IETF82 >=20 > John, > I think the gist of my comment (from 2 meetings ago) got lost. > The WG > needs to ensure that any changes / additions to GMPLS don't break > existing GMPLS implementations. Please see the message I just sent to > Sergio. >=20 > Lou >=20 > On 11/28/2011 11:53 AM, John E Drake wrote: > > I would suggest that those folks with deployed G.709v1 networks write > an > > I-D detailing their requirements for an interworking function. > > > > > > > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > > Behalf Of *BELOTTI, SERGIO (SERGIO) > > *Sent:* Friday, November 25, 2011 12:53 AM > > *To:* CCAMP > > *Subject:* [CCAMP] Framework and Information model for G.709 Optical > > Transport Networks (OTN) consideration post-IETF82 > > > > > > > > Hi CCAMP, > > > > > > > > as outcome of the Framework and Information model for G.709 Optical > > Transport Networks (OTN) presentation, Lou Berger asked co-authors to > > provide a new section in the framework document dealing with backward > > compatibility, as summary with respect to what is already > present/will > > be present in the encoding documents. > > > > > > > > In our opinion, the first thing to do is deciding which are the > > scenarios that have to be taken into account. > > > > > > > > As hypothesis we would like to consider network element domains > > composed either of G.709v1 or G709v3 network elements, > > > > so without having a mix of network element in the same domains. The > > motivation for this is that operators > > > > would not be happy with the mix because managing control plane > versions > > implementing very different features > > > > is not practical from a network operation point of view. > > > > > > > > Please note that backward compatibility issues are to be considered > > between GMPLS versions. So for G.709v1 NE we mean > > > > a network element with G.709v1 HW and support of RFC4328 only. > > > > > > > > The case of a NE with G709v1 HW supporting our GMPLS drafts does not > > have backward compatibility issues because it can be considered as a > > new node with limitations. > > > > > > > > Said this the candidate scenarios may be: > > > > > > > > 1) Interworking between a G.709v1 domain with a G.709v3 domain (path > is > > terminated by one G.709v1 node and G.709v3 node) > > > > > > > > 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - > > G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. > The > > path being terminated on G.709v1 equipment.) > > > > > > > > We'd like to hear the opinion of the WG whether CCAMP consider > > exhaustive the type of scenarios proposed, before proceeding with any > > modification to the document. > > > > > > > > Thanks > > > > > > > > Sergio and co-authors > > > > > > > > > > > > *SERGIO BELOTTI* > > > > > > > > ALCATEL-LUCENT > > > > Terrestrial System Architect > > > > Optics Portfolio Evolution > > > > > > > > via Trento 30 , Vimercate(MI) Italy > > > > T: +39 0396863033 > > > > *Sergio.Belotti@alcatel-lucent.com* > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Tue Nov 29 05:35:42 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE7921F8C11; Tue, 29 Nov 2011 05:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyJ1KqsFtJsG; Tue, 29 Nov 2011 05:35:42 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 184B821F8B48; Tue, 29 Nov 2011 05:35:42 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pATDV7OC012309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Nov 2011 07:31:08 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 29 Nov 2011 08:31:06 -0500 From: Acee Lindem To: Lou Berger Date: Tue, 29 Nov 2011 08:31:05 -0500 Thread-Topic: [CCAMP] [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 Thread-Index: AcyumyW5lCpm7XUQR1u8neylrlRWWQ== Message-ID: <6890EFB5-B7A9-4A8E-AA2A-2A4CF3F197E0@ericsson.com> References: <6343326C-9EFD-4F25-BBE4-E5001887A794@ericsson.com> <2D6BCF8B-F6AF-40C0-8E63-5AEB29B8D02A@ericsson.com> <4ED4C6FE.4040505@labn.net> In-Reply-To: <4ED4C6FE.4040505@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-50-668882166"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ospf@ietf.org List" , "ccamp@ietf.org" Subject: Re: [CCAMP] [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) will Update RFC 5786 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 13:35:42 -0000 --Apple-Mail-50-668882166 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Lou,=20 I think that would be my preference given that it would be a change to = base OSPF TE.=20 Thanks, Acee=20 On Nov 29, 2011, at 6:50 AM, Lou Berger wrote: > Acee, > Don't you think that addressing the second is a major change = enough > change that it should be done in a standalone draft? >=20 > Lou >=20 > On 11/28/2011 9:58 AM, Acee Lindem wrote: >> Hi Fatai, >> We have two separate requirements here. The ASON requirement is to be >> able to advertise reachability information for multiple ASON = transport >> nodes. As you've noted, there has been an independent requirement to >> advertise more information than will fit in a single LSA. Our draft = only >> addresses the first. However, we'll consider this when addressing >> Adrian's comments. Much of this depends on whether or not we do a = second >> review and WG last call.=20 >> Thanks, >> Acee >>=20 >> On Nov 27, 2011, at 10:11 PM, Zhangfatai wrote: >>=20 >>> Hi all, >>>=20 >>> Can this relaxation be applicable to all the future OSFPv2 documents = ? >>>=20 >>>=20 >>>=20 >>>=20 >>> Thanks >>>=20 >>> Fatai >>>=20 >>> *From:* ospf-bounces@ietf.org >>> [mailto:ospf-bounces@ietf.org] *On >>> Behalf Of *Acee Lindem >>> *Sent:* 2011=C4=EA11=D4=C228=C8=D5 9:14 >>> *To:* ospf@ietf.org List >>> *Cc:* ccamp@ietf.org >>> *Subject:* [OSPF] Updates to ASON Routing for OSPFv2 Protocols (RFC >>> 5787bis) will Update RFC 5786 >>>=20 >>> Please note that this document relaxes the RFC 5786 restriction = that >>> a Node Attribute TLV may only appear in a single OSPF TE LSA. Here = is >>> the text: >>>=20 >>> In order to support ASON reachability advertisement, the Node >>> Attribute TLV defined in [RFC5786] is used to advertise the >>> combination of a TE Router ID and its set of associated reachable >>> address prefixes. The Node Attribute TLV can contain the following >>> sub-TLVs: >>>=20 >>> - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 >>> - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] >>> - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] >>>=20 >>> A router may support multiple transport nodes as discussed in = section >>> 6, and, as a result, may be required to advertise reachability = (ASON >>> SNPPs) separately for each transport node. As a consequence, it = MUST >>> be possible for the router to originate more than one TE LSA >>> containing the Node Attribute TLV when used for ASON reachability >>> advertisement. >>>=20 >>> Hence, the Node Attribute TLV [RFC5786] advertisement rules must = be >>> relaxed for ASON. A Node Attribute TLV MAY appear in more than one = TE >>> LSA originated by the RC when the RC is advertising reachability >>> information for a different transport node identified by the Local = TE >>> Router Sub-TLV (refer to section 6.1). >>> Here is a link to the >>> document: http://www.ietf.org/id/draft-ietf-ccamp-rfc5787bis-03.txt >>>=20 >>> If you have any concerns with this change, please send them to this >>> list with the CCAMP list copied.=20 >>>=20 >>> Thanks, >>> Acee >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp --Apple-Mail-50-668882166 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTEyOTEzMzEwNlowIwYJKoZI hvcNAQkEMRYEFDaW7yOvLIjtF7kMlnuK3zblK/aiMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgG15QTVZv9cSSNNPsdhvBELpUkbsNifN9xbdBHg9J26XNdeU3GfDDWsHi+wQSlQZ iyUXNgw0zptV8WkyE0doTDtY3yRCgp5KitIvF1BoBfkecVzf44tnA7TQyWxwyhefeUYP1Cs3/j1G 455WbnTrhgWSfWgXJMXM2zMOXkUIpGzMAAAAAAAA --Apple-Mail-50-668882166-- From lberger@labn.net Tue Nov 29 06:15:47 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FF721F8C1F for ; Tue, 29 Nov 2011 06:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtUCbXcw8jGi for ; Tue, 29 Nov 2011 06:15:45 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 2C0D821F8C1E for ; Tue, 29 Nov 2011 06:15:45 -0800 (PST) Received: (qmail 10633 invoked by uid 0); 29 Nov 2011 14:15:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 29 Nov 2011 14:15:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=aNTkLNRkRCWt3EguCSbW2jrV9Om65oQNwpbNgo406u4=; b=JzZABz7WsjZoWks9POhKKN7FZNzYABYEnTYpJcJNSK29OsHSgjWPv/rplyWRwNDD7pu+7GpQ5Ls83aS5dNOqYJ2Cx21QCKqx7myywsH2p8uXi3qvsUJWp4XGu/IYc964; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVOTI-0000e8-Lo; Tue, 29 Nov 2011 07:15:44 -0700 Message-ID: <4ED4E914.1070709@labn.net> Date: Tue, 29 Nov 2011 09:15:48 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> <4ED4CA52.5060008@labn.net> <5E893DB832F57341992548CDBB333163A4B531D9F6@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B531D9F6@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 14:15:47 -0000 John, Sure, and CP compatibility doesn't need to imply interoperability, and certainly wasn't intended in the original comment. Lou On 11/29/2011 8:24 AM, John E Drake wrote: > Lou, > > My point was that control plane interoperability with G.709v1 is non-trivial and before we start working on it we should know whether anyone wants it. > > Thanks, > > John > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Tuesday, November 29, 2011 4:05 AM >> To: John E Drake >> Cc: BELOTTI, SERGIO (SERGIO); CCAMP >> Subject: Re: [CCAMP] Framework and Information model for G.709 Optical >> Transport Networks (OTN) consideration post-IETF82 >> >> John, >> I think the gist of my comment (from 2 meetings ago) got lost. >> The WG >> needs to ensure that any changes / additions to GMPLS don't break >> existing GMPLS implementations. Please see the message I just sent to >> Sergio. >> >> Lou >> >> On 11/28/2011 11:53 AM, John E Drake wrote: >>> I would suggest that those folks with deployed G.709v1 networks write >> an >>> I-D detailing their requirements for an interworking function. >>> >>> >>> >>> *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On >>> Behalf Of *BELOTTI, SERGIO (SERGIO) >>> *Sent:* Friday, November 25, 2011 12:53 AM >>> *To:* CCAMP >>> *Subject:* [CCAMP] Framework and Information model for G.709 Optical >>> Transport Networks (OTN) consideration post-IETF82 >>> >>> >>> >>> Hi CCAMP, >>> >>> >>> >>> as outcome of the Framework and Information model for G.709 Optical >>> Transport Networks (OTN) presentation, Lou Berger asked co-authors to >>> provide a new section in the framework document dealing with backward >>> compatibility, as summary with respect to what is already >> present/will >>> be present in the encoding documents. >>> >>> >>> >>> In our opinion, the first thing to do is deciding which are the >>> scenarios that have to be taken into account. >>> >>> >>> >>> As hypothesis we would like to consider network element domains >>> composed either of G.709v1 or G709v3 network elements, >>> >>> so without having a mix of network element in the same domains. The >>> motivation for this is that operators >>> >>> would not be happy with the mix because managing control plane >> versions >>> implementing very different features >>> >>> is not practical from a network operation point of view. >>> >>> >>> >>> Please note that backward compatibility issues are to be considered >>> between GMPLS versions. So for G.709v1 NE we mean >>> >>> a network element with G.709v1 HW and support of RFC4328 only. >>> >>> >>> >>> The case of a NE with G709v1 HW supporting our GMPLS drafts does not >>> have backward compatibility issues because it can be considered as a >>> new node with limitations. >>> >>> >>> >>> Said this the candidate scenarios may be: >>> >>> >>> >>> 1) Interworking between a G.709v1 domain with a G.709v3 domain (path >> is >>> terminated by one G.709v1 node and G.709v3 node) >>> >>> >>> >>> 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - >>> G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. >> The >>> path being terminated on G.709v1 equipment.) >>> >>> >>> >>> We'd like to hear the opinion of the WG whether CCAMP consider >>> exhaustive the type of scenarios proposed, before proceeding with any >>> modification to the document. >>> >>> >>> >>> Thanks >>> >>> >>> >>> Sergio and co-authors >>> >>> >>> >>> >>> >>> *SERGIO BELOTTI* >>> >>> >>> >>> ALCATEL-LUCENT >>> >>> Terrestrial System Architect >>> >>> Optics Portfolio Evolution >>> >>> >>> >>> via Trento 30 , Vimercate(MI) Italy >>> >>> T: +39 0396863033 >>> >>> *Sergio.Belotti@alcatel-lucent.com* >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp > > > > From db3546@att.com Tue Nov 29 13:52:18 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019D511E80D2 for ; Tue, 29 Nov 2011 13:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoW-4ncylPdQ for ; Tue, 29 Nov 2011 13:52:17 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56511E80B3 for ; Tue, 29 Nov 2011 13:52:13 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1322603531!51406423!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13019 invoked from network); 29 Nov 2011 21:52:12 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Nov 2011 21:52:12 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pATLqcBX017962; Tue, 29 Nov 2011 16:52:40 -0500 Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pATLqaq8017917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Nov 2011 16:52:36 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.112]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Tue, 29 Nov 2011 16:52:07 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: Proposed ITU-T Liaison on Flexible Grids Thread-Index: Acyu4SWZ7PUx8X6WQcOjOxrn484NXw== Date: Tue, 29 Nov 2011 21:52:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lear@cisco.com" Subject: [CCAMP] Proposed ITU-T Liaison on Flexible Grids X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 21:52:18 -0000 CCAMP, As discussed during the meeting, we will send a liaison to ITU-T SG15 infor= ming of our beginning work on Flexible Grids. Let us know if any comments. = We will send it by end-of-the-week. Thanks, Deborah (and Lou) ---------------------------------------------------------------------------= ----- To: Q6/15, Q12/15 Subject: Communication to ITU-T Q6/15 and Q12/15 from IETF's CCAMP Working Group on Flexible Grids Purpose: For Information The CCAMP Working Group of IETF would like to inform you of our beginning work on enhancing GMPLS's support for Wavelength Switched Optical Network (WSON) equipment to support Flexible Grids. With the recent progress on optical network technology regarding Flexible Grids, CCAMP participants are interested in investigating these new applications to ensure the applicability of GMPLS protocols for connection setup and path computation. We would appreciate if you would keep us informed of your progress in this area. In CCAMP, this work is in a very early phase of development, as we progress our work, we will communicate progress in this area. Best regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From sergio.belotti@alcatel-lucent.com Wed Nov 30 01:29:52 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5FD21F86A6 for ; Wed, 30 Nov 2011 01:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIMvADoI3PY0 for ; Wed, 30 Nov 2011 01:29:51 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 61FAD21F86A1 for ; Wed, 30 Nov 2011 01:29:50 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAU9TN2P030231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Nov 2011 10:29:49 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.42]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Nov 2011 10:29:41 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: Lou Berger Date: Wed, 30 Nov 2011 10:29:40 +0100 Thread-Topic: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 Thread-Index: AcyujrFDf7Rs/WTnQbymfedYVFizRAAsluVw Message-ID: References: <4ED4C9A9.90809@labn.net> In-Reply-To: <4ED4C9A9.90809@labn.net> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: CCAMP Subject: [CCAMP] R: Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 09:29:52 -0000 Lou, Thanks for clarification , I understood during my presentation that the com= ment was a remind referred to another past meeting (in which I was not pres= ent). The aim of the mail is trying to understand how to address the "what is bei= ng done" that cannot be independent of the type of possible network scenari= os.=20 We need to understand , particularly from company-people with per-G.709.v3 = implementation(John has perfectly pointed out the issue), what could be the= typical scenarios to be addressed. We have tried to set the focus on two out of them, and we'd like to hear fr= om WG the approval or not to work on them. We cannot start to work before an agreement on that. Sergio =20 -----Messaggio originale----- Da: Lou Berger [mailto:lberger@labn.net]=20 Inviato: marted=EC 29 novembre 2011 13.02 A: BELOTTI, SERGIO (SERGIO) Cc: CCAMP Oggetto: Re: [CCAMP] Framework and Information model for G.709 Optical Tran= sport Networks (OTN) consideration post-IETF82 Sergio, My comment actually comes from two meetings ago and was based on the routing and signaling drafts each having their own compatibility sections (sections 6 and 6.5, respectively), and the framework not having one at all. As you note, control plane compatibility is something typically addressed in GMPLS. I think the framework needs to cover what approach is being taken to ensure *control plane* operation when a pre-G709v3 GMPLS node exchanges CP messages with a G709v3 GMPLS node. In short, the framework should say *what* is being done with respect to CP compatibility, the routing and signaling documents should say *how* CP compatibility is supported. Note that my request was not about data plane compatibility. Lou On 11/25/2011 3:52 AM, BELOTTI, SERGIO (SERGIO) wrote: > Hi CCAMP, > =20 > as outcome of the Framework and Information model for G.709 Optical > Transport Networks (OTN) presentation, Lou Berger asked co-authors to > provide a new section in the framework document dealing with backward > compatibility, as summary with respect to what is already present/will > be present in the encoding documents. > =20 > In our opinion, the first thing to do is deciding which are the > scenarios that have to be taken into account. > =20 > As hypothesis we would like to consider network element domains=20 > composed either of G.709v1 or G709v3 network elements, > so without having a mix of network element in the same domains. The > motivation for this is that operators > would not be happy with the mix because managing control plane versions > implementing very different features > is not practical from a network operation point of view.=20 > =20 > Please note that backward compatibility issues are to be considered > between GMPLS versions. So for G.709v1 NE we mean > a network element with G.709v1 HW and support of RFC4328 only. > =20 > The case of a NE with G709v1 HW supporting our GMPLS drafts does not > have backward compatibility issues because it can be considered as a > new node with limitations. > =20 > Said this the candidate scenarios may be: > =20 > 1) Interworking between a G.709v1 domain with a G.709v3 domain (path is > terminated by one G.709v1 node and G.709v3 node) > =20 > 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - > G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. The > path being terminated on G.709v1 equipment.) > =20 > We'd like to hear the opinion of the WG whether CCAMP consider > exhaustive the type of scenarios proposed, before proceeding with any > modification to the document. > =20 > Thanks > =20 > Sergio and co-authors > =20 > =20 > *SERGIO BELOTTI* > =20 > ALCATEL-LUCENT > Terrestrial System Architect > Optics Portfolio Evolution > =20 > via Trento 30 , Vimercate(MI) Italy > T: +39 0396863033 > *Sergio.Belotti@alcatel-lucent.com* > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From sergio.belotti@alcatel-lucent.com Wed Nov 30 01:32:34 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF321F863E for ; Wed, 30 Nov 2011 01:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsn7+4r8frST for ; Wed, 30 Nov 2011 01:32:33 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 59C5021F861E for ; Wed, 30 Nov 2011 01:32:33 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pAU9UxAS002985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Nov 2011 10:32:29 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.42]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Nov 2011 10:32:13 +0100 From: "BELOTTI, SERGIO (SERGIO)" To: John E Drake Date: Wed, 30 Nov 2011 10:32:11 +0100 Thread-Topic: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 Thread-Index: AcyujzKsPlqtBeaeRwyptSR9i+TJmwABQbBgACuokGA= Message-ID: References: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> <4ED4CA52.5060008@labn.net> <5E893DB832F57341992548CDBB333163A4B531D9F6@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B531D9F6@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: CCAMP Subject: [CCAMP] R: Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 09:32:34 -0000 Thanks John, You got perfectly the point. Sergio -----Messaggio originale----- Da: John E Drake [mailto:jdrake@juniper.net]=20 Inviato: marted=EC 29 novembre 2011 14.24 A: Lou Berger Cc: BELOTTI, SERGIO (SERGIO); CCAMP Oggetto: RE: [CCAMP] Framework and Information model for G.709 Optical Tran= sport Networks (OTN) consideration post-IETF82 Lou, My point was that control plane interoperability with G.709v1 is non-trivia= l and before we start working on it we should know whether anyone wants it. Thanks, John=20 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, November 29, 2011 4:05 AM > To: John E Drake > Cc: BELOTTI, SERGIO (SERGIO); CCAMP > Subject: Re: [CCAMP] Framework and Information model for G.709 Optical > Transport Networks (OTN) consideration post-IETF82 >=20 > John, > I think the gist of my comment (from 2 meetings ago) got lost. > The WG > needs to ensure that any changes / additions to GMPLS don't break > existing GMPLS implementations. Please see the message I just sent to > Sergio. >=20 > Lou >=20 > On 11/28/2011 11:53 AM, John E Drake wrote: > > I would suggest that those folks with deployed G.709v1 networks write > an > > I-D detailing their requirements for an interworking function. > > > > > > > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > > Behalf Of *BELOTTI, SERGIO (SERGIO) > > *Sent:* Friday, November 25, 2011 12:53 AM > > *To:* CCAMP > > *Subject:* [CCAMP] Framework and Information model for G.709 Optical > > Transport Networks (OTN) consideration post-IETF82 > > > > > > > > Hi CCAMP, > > > > > > > > as outcome of the Framework and Information model for G.709 Optical > > Transport Networks (OTN) presentation, Lou Berger asked co-authors to > > provide a new section in the framework document dealing with backward > > compatibility, as summary with respect to what is already > present/will > > be present in the encoding documents. > > > > > > > > In our opinion, the first thing to do is deciding which are the > > scenarios that have to be taken into account. > > > > > > > > As hypothesis we would like to consider network element domains > > composed either of G.709v1 or G709v3 network elements, > > > > so without having a mix of network element in the same domains. The > > motivation for this is that operators > > > > would not be happy with the mix because managing control plane > versions > > implementing very different features > > > > is not practical from a network operation point of view. > > > > > > > > Please note that backward compatibility issues are to be considered > > between GMPLS versions. So for G.709v1 NE we mean > > > > a network element with G.709v1 HW and support of RFC4328 only. > > > > > > > > The case of a NE with G709v1 HW supporting our GMPLS drafts does not > > have backward compatibility issues because it can be considered as a > > new node with limitations. > > > > > > > > Said this the candidate scenarios may be: > > > > > > > > 1) Interworking between a G.709v1 domain with a G.709v3 domain (path > is > > terminated by one G.709v1 node and G.709v3 node) > > > > > > > > 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - > > G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. > The > > path being terminated on G.709v1 equipment.) > > > > > > > > We'd like to hear the opinion of the WG whether CCAMP consider > > exhaustive the type of scenarios proposed, before proceeding with any > > modification to the document. > > > > > > > > Thanks > > > > > > > > Sergio and co-authors > > > > > > > > > > > > *SERGIO BELOTTI* > > > > > > > > ALCATEL-LUCENT > > > > Terrestrial System Architect > > > > Optics Portfolio Evolution > > > > > > > > via Trento 30 , Vimercate(MI) Italy > > > > T: +39 0396863033 > > > > *Sergio.Belotti@alcatel-lucent.com* > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Wed Nov 30 04:03:13 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC29D21F8AF1 for ; Wed, 30 Nov 2011 04:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXDrYfshJzdj for ; Wed, 30 Nov 2011 04:03:12 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7237E21F8AF5 for ; Wed, 30 Nov 2011 04:03:11 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTtYbd0urX7P2rYa/rp3Y/4r28tXa6P6q@postini.com; Wed, 30 Nov 2011 04:03:12 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 30 Nov 2011 04:00:11 -0800 From: John E Drake To: "BELOTTI, SERGIO (SERGIO)" Date: Wed, 30 Nov 2011 04:00:08 -0800 Thread-Topic: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 Thread-Index: AcyujzKsPlqtBeaeRwyptSR9i+TJmwABQbBgACuokGAABS6agA== Message-ID: <5E893DB832F57341992548CDBB333163A4B54CA8CE@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A4B531CFFC@EMBX01-HQ.jnpr.net> <4ED4CA52.5060008@labn.net> <5E893DB832F57341992548CDBB333163A4B531D9F6@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 12:03:13 -0000 You're welcome. > -----Original Message----- > From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel- > lucent.com] > Sent: Wednesday, November 30, 2011 1:32 AM > To: John E Drake > Cc: CCAMP; Lou Berger > Subject: R: [CCAMP] Framework and Information model for G.709 Optical > Transport Networks (OTN) consideration post-IETF82 >=20 > Thanks John, > You got perfectly the point. >=20 > Sergio >=20 >=20 >=20 >=20 >=20 > -----Messaggio originale----- > Da: John E Drake [mailto:jdrake@juniper.net] > Inviato: marted=EC 29 novembre 2011 14.24 > A: Lou Berger > Cc: BELOTTI, SERGIO (SERGIO); CCAMP > Oggetto: RE: [CCAMP] Framework and Information model for G.709 Optical > Transport Networks (OTN) consideration post-IETF82 >=20 > Lou, >=20 > My point was that control plane interoperability with G.709v1 is non- > trivial and before we start working on it we should know whether anyone > wants it. >=20 > Thanks, >=20 > John >=20 > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Tuesday, November 29, 2011 4:05 AM > > To: John E Drake > > Cc: BELOTTI, SERGIO (SERGIO); CCAMP > > Subject: Re: [CCAMP] Framework and Information model for G.709 > Optical > > Transport Networks (OTN) consideration post-IETF82 > > > > John, > > I think the gist of my comment (from 2 meetings ago) got lost. > > The WG > > needs to ensure that any changes / additions to GMPLS don't break > > existing GMPLS implementations. Please see the message I just sent > to > > Sergio. > > > > Lou > > > > On 11/28/2011 11:53 AM, John E Drake wrote: > > > I would suggest that those folks with deployed G.709v1 networks > write > > an > > > I-D detailing their requirements for an interworking function. > > > > > > > > > > > > *From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On > > > Behalf Of *BELOTTI, SERGIO (SERGIO) > > > *Sent:* Friday, November 25, 2011 12:53 AM > > > *To:* CCAMP > > > *Subject:* [CCAMP] Framework and Information model for G.709 > Optical > > > Transport Networks (OTN) consideration post-IETF82 > > > > > > > > > > > > Hi CCAMP, > > > > > > > > > > > > as outcome of the Framework and Information model for G.709 Optical > > > Transport Networks (OTN) presentation, Lou Berger asked co-authors > to > > > provide a new section in the framework document dealing with > backward > > > compatibility, as summary with respect to what is already > > present/will > > > be present in the encoding documents. > > > > > > > > > > > > In our opinion, the first thing to do is deciding which are the > > > scenarios that have to be taken into account. > > > > > > > > > > > > As hypothesis we would like to consider network element domains > > > composed either of G.709v1 or G709v3 network elements, > > > > > > so without having a mix of network element in the same domains. The > > > motivation for this is that operators > > > > > > would not be happy with the mix because managing control plane > > versions > > > implementing very different features > > > > > > is not practical from a network operation point of view. > > > > > > > > > > > > Please note that backward compatibility issues are to be considered > > > between GMPLS versions. So for G.709v1 NE we mean > > > > > > a network element with G.709v1 HW and support of RFC4328 only. > > > > > > > > > > > > The case of a NE with G709v1 HW supporting our GMPLS drafts does > not > > > have backward compatibility issues because it can be considered as > a > > > new node with limitations. > > > > > > > > > > > > Said this the candidate scenarios may be: > > > > > > > > > > > > 1) Interworking between a G.709v1 domain with a G.709v3 domain > (path > > is > > > terminated by one G.709v1 node and G.709v3 node) > > > > > > > > > > > > 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain > - > > > G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. > > The > > > path being terminated on G.709v1 equipment.) > > > > > > > > > > > > We'd like to hear the opinion of the WG whether CCAMP consider > > > exhaustive the type of scenarios proposed, before proceeding with > any > > > modification to the document. > > > > > > > > > > > > Thanks > > > > > > > > > > > > Sergio and co-authors > > > > > > > > > > > > > > > > > > *SERGIO BELOTTI* > > > > > > > > > > > > ALCATEL-LUCENT > > > > > > Terrestrial System Architect > > > > > > Optics Portfolio Evolution > > > > > > > > > > > > via Trento 30 , Vimercate(MI) Italy > > > > > > T: +39 0396863033 > > > > > > *Sergio.Belotti@alcatel-lucent.com* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Wed Nov 30 04:35:01 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D08E21F8B08 for ; Wed, 30 Nov 2011 04:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[AWL=1.219, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2jQzvXsqa67 for ; Wed, 30 Nov 2011 04:34:58 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 53CEB21F8B07 for ; Wed, 30 Nov 2011 04:34:38 -0800 (PST) Received: (qmail 27670 invoked by uid 0); 30 Nov 2011 12:34:12 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 30 Nov 2011 12:34:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=nv8baB3RjB6wha7LsL7zGFyc64nE5jH3iev++ldlVho=; b=DNVp85PoetToKTdI4Pendx1+n0kCONOZgnU0GJIAJuaPqy/WHliC8py0PlNeIz132YeK/h73I8N0nyyPicbVIEOUaQbWSbnQRpQ66d8jglDijeV8x0Tjnj3VmPg/c1d7; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVjMa-0007Wj-0R; Wed, 30 Nov 2011 05:34:12 -0700 Message-ID: <4ED622BE.4060203@labn.net> Date: Wed, 30 Nov 2011 07:34:06 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "BELOTTI, SERGIO (SERGIO)" References: <4ED4C9A9.90809@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] R: Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 12:35:01 -0000 Sergio, At a minimum, the solutions draft MUST cover what happens when a pre-G709v3 (or non-G709v3) GMPLS node exchanges CP messages with a G709v3 GMPLS node. For example, what happens when a G709v3 GMPLS node exchanges messages with a node supporting only LSC or ethernet. You can even just state something as simple as what's in rfc6002 section 2.1. This is just a matter of correct protocol behavior and should not be a "big" deal or discussion. You seem to also want to cover G.709v1 and G709v3 interoperability. This is a fine thing to consider, but has nothing to do with the comment. Lou On 11/30/2011 4:29 AM, BELOTTI, SERGIO (SERGIO) wrote: > Lou, > Thanks for clarification , I understood during my presentation that the comment was a remind referred to another past meeting (in which I was not present). > The aim of the mail is trying to understand how to address the "what is being done" that cannot be independent of the type of possible network scenarios. > We need to understand , particularly from company-people with per-G.709.v3 implementation(John has perfectly pointed out the issue), what could be the typical scenarios to be addressed. > We have tried to set the focus on two out of them, and we'd like to hear from WG the approval or not to work on them. > We cannot start to work before an agreement on that. > > Sergio > > > > > > -----Messaggio originale----- > Da: Lou Berger [mailto:lberger@labn.net] > Inviato: martedì 29 novembre 2011 13.02 > A: BELOTTI, SERGIO (SERGIO) > Cc: CCAMP > Oggetto: Re: [CCAMP] Framework and Information model for G.709 Optical Transport Networks (OTN) consideration post-IETF82 > > Sergio, > My comment actually comes from two meetings ago and was based on the > routing and signaling drafts each having their own compatibility > sections (sections 6 and 6.5, respectively), and the framework not > having one at all. As you note, control plane compatibility is > something typically addressed in GMPLS. I think the framework needs to > cover what approach is being taken to ensure *control plane* operation > when a pre-G709v3 GMPLS node exchanges CP messages with a G709v3 GMPLS > node. In short, the framework should say *what* is being done with > respect to CP compatibility, the routing and signaling documents should > say *how* CP compatibility is supported. > > Note that my request was not about data plane compatibility. > > Lou > > On 11/25/2011 3:52 AM, BELOTTI, SERGIO (SERGIO) wrote: >> Hi CCAMP, >> >> as outcome of the Framework and Information model for G.709 Optical >> Transport Networks (OTN) presentation, Lou Berger asked co-authors to >> provide a new section in the framework document dealing with backward >> compatibility, as summary with respect to what is already present/will >> be present in the encoding documents. >> >> In our opinion, the first thing to do is deciding which are the >> scenarios that have to be taken into account. >> >> As hypothesis we would like to consider network element domains >> composed either of G.709v1 or G709v3 network elements, >> so without having a mix of network element in the same domains. The >> motivation for this is that operators >> would not be happy with the mix because managing control plane versions >> implementing very different features >> is not practical from a network operation point of view. >> >> Please note that backward compatibility issues are to be considered >> between GMPLS versions. So for G.709v1 NE we mean >> a network element with G.709v1 HW and support of RFC4328 only. >> >> The case of a NE with G709v1 HW supporting our GMPLS drafts does not >> have backward compatibility issues because it can be considered as a >> new node with limitations. >> >> Said this the candidate scenarios may be: >> >> 1) Interworking between a G.709v1 domain with a G.709v3 domain (path is >> terminated by one G.709v1 node and G.709v3 node) >> >> 2) Interworking in the case of a G.709v1 domain - a G.709v3 domain - >> G709v1 domain (G.709v3 domain in the middle of two G.709v1 domains. The >> path being terminated on G.709v1 equipment.) >> >> We'd like to hear the opinion of the WG whether CCAMP consider >> exhaustive the type of scenarios proposed, before proceeding with any >> modification to the document. >> >> Thanks >> >> Sergio and co-authors >> >> >> *SERGIO BELOTTI* >> >> ALCATEL-LUCENT >> Terrestrial System Architect >> Optics Portfolio Evolution >> >> via Trento 30 , Vimercate(MI) Italy >> T: +39 0396863033 >> *Sergio.Belotti@alcatel-lucent.com* >> >> >> >> >> >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > From lberger@labn.net Wed Nov 30 07:22:53 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E78921F87D6 for ; Wed, 30 Nov 2011 07:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.416 X-Spam-Level: X-Spam-Status: No, score=-101.416 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYbxooAoUUX3 for ; Wed, 30 Nov 2011 07:22:45 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by ietfa.amsl.com (Postfix) with SMTP id 171F821F8B48 for ; Wed, 30 Nov 2011 07:22:45 -0800 (PST) Received: (qmail 16399 invoked by uid 0); 30 Nov 2011 15:22:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 30 Nov 2011 15:22:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=IO0CZ55MgT6Mv/4/6ugCjhqJArs3w5JsacTbAjXIHgQ=; b=iNSD7RChEzLBQsdkA0hudzL55laMNWs39WU9+EEDA2VmsKUxGQ3KGCgMrk0yahXG3xjrEKV84QALaJOnDFT1c1hWAxFffuXaoWIwf9dXoHu6QKZzNmuWaCWx7E5FVQRC; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVlzL-0001at-F9; Wed, 30 Nov 2011 08:22:23 -0700 Message-ID: <4ED64A32.8060707@labn.net> Date: Wed, 30 Nov 2011 10:22:26 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Daniele Ceccarelli References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 15:22:53 -0000 Hi Daniele, Since I raised the point, I guess I need to champion it! (With chair hat off.) All, Daniele said: > WRT issue 1: the proposal was to indicate the bottom most ODUk of the > muxing hiearachy in the Switching Capability field of the ISCD. After > a quick talk with the other authors of the ID, the idea was to reject > the proposal as it would lead to an overloading of the meaning of the > Switching Capability field. (even if the definition of PSC1-2-3-4 > already overloads the meaning of the switching capability field) This really goes to the interpretation of the intent of Switching Capability Types. So we have a few definitions: 3471 says "the type of switching that should be performed", 4202 says "describes switching capability of an interface." 3945 doesn't really define the term (it just references 4202), but does equate it with a "layer". While it allows for hierarchy within a "layer" it also says hierarchy occurs "between interface types". So I interpret Switching Capability Types to represent (a) different switching/technology layers and (b) different levels of hierarchy -- even within a layer. I think (a) is identifiable in the definition of the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC, and FSC), and (b) is identifiable in the original types plus the definition of PSC-1 through PSC-4. So how does this apply to our current OTN work? To me, the first question to ask relates to (a), and is should each ODUk be modeled as a separate layer? I know this has been a much debated point, and it seems to me that they are, but more for the perspective of switching layers than technology layers (i.e., they are clearly the same technology but are different granularity of swicthing.) So this is a yes for me. I think the second question to ask relates to (b), and is does each ODUk represent a different level of hierarchy? I see this as simply yes, and no different than what has been done more recently with Ethernet or, even if we do continue to model OTN as a single layer, no different than PSC-1 -> PSC-4. There's also a minor processing efficiency gained by this approach for nodes that support a smaller set of ODUks than are advertised within an IGP. Based on all this, I believe different ODUk's should use different Switching Types. In particular, I'm proposing: (1) that either the framework or info documents identify that a per-OTUk Switching Capability Types will be used to support G.709v3. (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different Switching Cap field value for each ODUk, and that it state that the value corresponding to the signal type identified in the #stages=0 of the ISCP be set. (Without any other changes to the current definition of ISCD.) (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to match above. To keep thinks generic, we probably should use TDM-1 through TDM-n as the new Switching Capability Types, but this is a secondary discussion. Comments? Lou PS While the above is an important change, it doesn't significantly impact encoding and won't take much text to make the actual change, so this is a discussion that can continue until Paris if we really need a face to face to resolve the discussion. On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > Hi CCAMP, > > > > During the OTN OSPF draft presentation at the IETF meeting in Taipei two > comments were raised with respect to the following issues: > > > > - Issue 1: Using different switching caps for each ODU type > > - Issue 2: Type 2 (unres bandwidth for variable containers) and Type 3 > (MAX LSP bandwidth foe variable containers always used in tandem? > > > > WRT issue 1: the proposal was to indicate the bottom most ODUk of the > muxing hiearachy in the Switching Capability field of the ISCD. After a > quick talk with the other authors of the ID, the idea was to reject the > proposal as it would lead to an overloading of the meaning of the > Switching Capability field. (even if the definition of PSC1-2-3-4 > already overloads the meaning of the switching capability field) > > > > WRT issue 2: it is analyzed in section 5.3 of the draft (version -00). > I'm copying it below for your convenience > > > > In this example the advertisement of an ODUflex->ODU3 hierarchy is > > shown. In case of ODUflex advertisement the MAX LSP bandwidth needs > > to be advertised but in some cases also information about the > > Unreserved bandwidth could be useful. The amount of Unreserved > > bandwidth does not give a clear indication of how many ODUflex LSP > > can be set up either at the MAX LSP Bandwidth or at different rates, > > as it gives no information about the spatial allocation of the free > > TSs. > > > > An indication of the amount of Unreserved bandwidth could be useful > > during the path computation process, as shown in the following > > example. Supposing there are two TE-links (A and B) with MAX LSP > > Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved > > Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex > > LSPs of 10 GBps each, have to be restored, for sure only one can be > > restored along Link B and it is probable (but not sure) that two of > > them can be restored along Link A. > > > > Early proposal was to have, in the case of variable containers > advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as a > mandatory piece of information and the Unreserved bandiwdth TLV (Type 2) > as an optional piece of information. > > The comment received is that optional information can lead to > interworking issues and the counter proposal was to have both pieces of > information as mandatory and, as a consequence, merge the two TLVs into > a single one. > > > > We'd like to hear the opinion of the WG on both issues before proceeding > with any modification to the document. > > > > Thanks, > > Daniele > > > > > > > *DANIELE CECCARELLI * > *System & Technology - DU IP & Broadband* > > > Via L.Calda, 5 > Genova, Italy > Phone +390106002512 > Mobile +393346725750 > daniele.ceccarelli@ericsson.com > www.ericsson.com > > > > > > > This Communication is Confidential. We only send and receive email on > the basis of the term set out at www.ericsson.com/email_disclaimer > > > > > > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From jdrake@juniper.net Wed Nov 30 08:17:30 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0155321F8B5E for ; Wed, 30 Nov 2011 08:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-Y1VXorqKvo for ; Wed, 30 Nov 2011 08:17:29 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B734421F8B24 for ; Wed, 30 Nov 2011 08:17:28 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTtZXFD4WrOMNtMKyccX3J9vjp5F7KTQ+@postini.com; Wed, 30 Nov 2011 08:17:28 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 30 Nov 2011 08:14:20 -0800 From: John E Drake To: Lou Berger , Daniele Ceccarelli Date: Wed, 30 Nov 2011 08:14:17 -0800 Thread-Topic: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) Thread-Index: Acyvc/MM3IkrJu43TYyuORneWTHGSwAByJkg Message-ID: <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> References: <4ED64A32.8060707@labn.net> In-Reply-To: <4ED64A32.8060707@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:17:30 -0000 I completely disagree. > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Wednesday, November 30, 2011 7:22 AM > To: Daniele Ceccarelli > Cc: CCAMP > Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >=20 > Hi Daniele, > Since I raised the point, I guess I need to champion it! (With > chair > hat off.) >=20 > All, >=20 > Daniele said: > > WRT issue 1: the proposal was to indicate the bottom most ODUk of the > > muxing hiearachy in the Switching Capability field of the ISCD. After > > a quick talk with the other authors of the ID, the idea was to reject > > the proposal as it would lead to an overloading of the meaning of the > > Switching Capability field. (even if the definition of PSC1-2-3-4 > > already overloads the meaning of the switching capability field) >=20 > This really goes to the interpretation of the intent of Switching > Capability Types. So we have a few definitions: 3471 says "the type of > switching that should be performed", 4202 says "describes switching > capability of an interface." 3945 doesn't really define the term (it > just references 4202), but does equate it with a "layer". While it > allows for hierarchy within a "layer" it also says hierarchy occurs > "between interface types". >=20 > So I interpret Switching Capability Types to represent (a) different > switching/technology layers and (b) different levels of hierarchy -- > even within a layer. I think (a) is identifiable in the definition of > the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC, > and > FSC), and (b) is identifiable in the original types plus the definition > of PSC-1 through PSC-4. >=20 > So how does this apply to our current OTN work? >=20 > To me, the first question to ask relates to (a), and is should each > ODUk > be modeled as a separate layer? >=20 > I know this has been a much debated point, and it seems to me that they > are, but more for the perspective of switching layers than technology > layers (i.e., they are clearly the same technology but are different > granularity of swicthing.) So this is a yes for me. >=20 > I think the second question to ask relates to (b), and is does each > ODUk > represent a different level of hierarchy? >=20 > I see this as simply yes, and no different than what has been done more > recently with Ethernet or, even if we do continue to model OTN as a > single layer, no different than PSC-1 -> PSC-4. >=20 > There's also a minor processing efficiency gained by this approach for > nodes that support a smaller set of ODUks than are advertised within an > IGP. >=20 > Based on all this, I believe different ODUk's should use different > Switching Types. In particular, I'm proposing: > (1) that either the framework or info documents identify that > a per-OTUk Switching Capability Types will be used to support > G.709v3. > (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different > Switching Cap field value for each ODUk, and that it state > that the value corresponding to the signal type identified in > the #stages=3D0 of the ISCP be set. (Without any other changes > to the current definition of ISCD.) > (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to > match above. >=20 > To keep thinks generic, we probably should use TDM-1 through TDM-n as > the new Switching Capability Types, but this is a secondary discussion. >=20 > Comments? >=20 > Lou >=20 > PS While the above is an important change, it doesn't significantly > impact encoding and won't take much text to make the actual change, so > this is a discussion that can continue until Paris if we really need a > face to face to resolve the discussion. >=20 > On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > > Hi CCAMP, > > > > > > > > During the OTN OSPF draft presentation at the IETF meeting in Taipei > two > > comments were raised with respect to the following issues: > > > > > > > > - Issue 1: Using different switching caps for each ODU type > > > > - Issue 2: Type 2 (unres bandwidth for variable containers) and Type > 3 > > (MAX LSP bandwidth foe variable containers always used in tandem? > > > > > > > > WRT issue 1: the proposal was to indicate the bottom most ODUk of the > > muxing hiearachy in the Switching Capability field of the ISCD. After > a > > quick talk with the other authors of the ID, the idea was to reject > the > > proposal as it would lead to an overloading of the meaning of the > > Switching Capability field. (even if the definition of PSC1-2-3-4 > > already overloads the meaning of the switching capability field) > > > > > > > > WRT issue 2: it is analyzed in section 5.3 of the draft (version - > 00). > > I'm copying it below for your convenience > > > > > > > > In this example the advertisement of an ODUflex->ODU3 hierarchy is > > > > shown. In case of ODUflex advertisement the MAX LSP bandwidth > needs > > > > to be advertised but in some cases also information about the > > > > Unreserved bandwidth could be useful. The amount of Unreserved > > > > bandwidth does not give a clear indication of how many ODUflex LSP > > > > can be set up either at the MAX LSP Bandwidth or at different > rates, > > > > as it gives no information about the spatial allocation of the > free > > > > TSs. > > > > > > > > An indication of the amount of Unreserved bandwidth could be > useful > > > > during the path computation process, as shown in the following > > > > example. Supposing there are two TE-links (A and B) with MAX LSP > > > > Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved > > > > Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex > > > > LSPs of 10 GBps each, have to be restored, for sure only one can > be > > > > restored along Link B and it is probable (but not sure) that two > of > > > > them can be restored along Link A. > > > > > > > > Early proposal was to have, in the case of variable containers > > advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as > a > > mandatory piece of information and the Unreserved bandiwdth TLV (Type > 2) > > as an optional piece of information. > > > > The comment received is that optional information can lead to > > interworking issues and the counter proposal was to have both pieces > of > > information as mandatory and, as a consequence, merge the two TLVs > into > > a single one. > > > > > > > > We'd like to hear the opinion of the WG on both issues before > proceeding > > with any modification to the document. > > > > > > > > Thanks, > > > > Daniele > > > > > > > > > > > > > > *DANIELE CECCARELLI * > > *System & Technology - DU IP & Broadband* > > > > > > Via L.Calda, 5 > > Genova, Italy > > Phone +390106002512 > > Mobile +393346725750 > > daniele.ceccarelli@ericsson.com > > www.ericsson.com > > > > > > > > > > > > > > This Communication is Confidential. We only send and receive email on > > the basis of the term set out at www.ericsson.com/email_disclaimer > > > > > > > > > > > > > > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Wed Nov 30 08:43:47 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673FF21F8B94 for ; Wed, 30 Nov 2011 08:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.537 X-Spam-Level: X-Spam-Status: No, score=-101.537 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFVUjn19JjYU for ; Wed, 30 Nov 2011 08:43:46 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 73C7B21F8B86 for ; Wed, 30 Nov 2011 08:43:46 -0800 (PST) Received: (qmail 16364 invoked by uid 0); 30 Nov 2011 16:43:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 30 Nov 2011 16:43:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=u+r5bRR5m0pjHCvA/S+uF5e3HzFW2mMIWsytlMQSU50=; b=bqV/WXY2d0dsfSB5DSr+6fqhpHou/uJwAV4Huh4X7SQbh3NwtFnnIyYLs2lp7F1uF+oWMNKND/cZXLSKjAPAhwret66UVUNwI567dCWdUAyab2LoxqSFneVY2Qqgfeso; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVnFi-0006GW-SC; Wed, 30 Nov 2011 09:43:23 -0700 Message-ID: <4ED65D2D.2040400@labn.net> Date: Wed, 30 Nov 2011 11:43:25 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:43:47 -0000 Great. Care to substantiate your point? On 11/30/2011 11:14 AM, John E Drake wrote: > I completely disagree. > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >> Of Lou Berger >> Sent: Wednesday, November 30, 2011 7:22 AM >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >> >> Hi Daniele, >> Since I raised the point, I guess I need to champion it! (With >> chair >> hat off.) >> >> All, >> >> Daniele said: >>> WRT issue 1: the proposal was to indicate the bottom most ODUk of the >>> muxing hiearachy in the Switching Capability field of the ISCD. After >>> a quick talk with the other authors of the ID, the idea was to reject >>> the proposal as it would lead to an overloading of the meaning of the >>> Switching Capability field. (even if the definition of PSC1-2-3-4 >>> already overloads the meaning of the switching capability field) >> >> This really goes to the interpretation of the intent of Switching >> Capability Types. So we have a few definitions: 3471 says "the type of >> switching that should be performed", 4202 says "describes switching >> capability of an interface." 3945 doesn't really define the term (it >> just references 4202), but does equate it with a "layer". While it >> allows for hierarchy within a "layer" it also says hierarchy occurs >> "between interface types". >> >> So I interpret Switching Capability Types to represent (a) different >> switching/technology layers and (b) different levels of hierarchy -- >> even within a layer. I think (a) is identifiable in the definition of >> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC, >> and >> FSC), and (b) is identifiable in the original types plus the definition >> of PSC-1 through PSC-4. >> >> So how does this apply to our current OTN work? >> >> To me, the first question to ask relates to (a), and is should each >> ODUk >> be modeled as a separate layer? >> >> I know this has been a much debated point, and it seems to me that they >> are, but more for the perspective of switching layers than technology >> layers (i.e., they are clearly the same technology but are different >> granularity of swicthing.) So this is a yes for me. >> >> I think the second question to ask relates to (b), and is does each >> ODUk >> represent a different level of hierarchy? >> >> I see this as simply yes, and no different than what has been done more >> recently with Ethernet or, even if we do continue to model OTN as a >> single layer, no different than PSC-1 -> PSC-4. >> >> There's also a minor processing efficiency gained by this approach for >> nodes that support a smaller set of ODUks than are advertised within an >> IGP. >> >> Based on all this, I believe different ODUk's should use different >> Switching Types. In particular, I'm proposing: >> (1) that either the framework or info documents identify that >> a per-OTUk Switching Capability Types will be used to support >> G.709v3. >> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different >> Switching Cap field value for each ODUk, and that it state >> that the value corresponding to the signal type identified in >> the #stages=0 of the ISCP be set. (Without any other changes >> to the current definition of ISCD.) >> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to >> match above. >> >> To keep thinks generic, we probably should use TDM-1 through TDM-n as >> the new Switching Capability Types, but this is a secondary discussion. >> >> Comments? >> >> Lou >> >> PS While the above is an important change, it doesn't significantly >> impact encoding and won't take much text to make the actual change, so >> this is a discussion that can continue until Paris if we really need a >> face to face to resolve the discussion. >> >> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: >>> Hi CCAMP, >>> >>> >>> >>> During the OTN OSPF draft presentation at the IETF meeting in Taipei >> two >>> comments were raised with respect to the following issues: >>> >>> >>> >>> - Issue 1: Using different switching caps for each ODU type >>> >>> - Issue 2: Type 2 (unres bandwidth for variable containers) and Type >> 3 >>> (MAX LSP bandwidth foe variable containers always used in tandem? >>> >>> >>> >>> WRT issue 1: the proposal was to indicate the bottom most ODUk of the >>> muxing hiearachy in the Switching Capability field of the ISCD. After >> a >>> quick talk with the other authors of the ID, the idea was to reject >> the >>> proposal as it would lead to an overloading of the meaning of the >>> Switching Capability field. (even if the definition of PSC1-2-3-4 >>> already overloads the meaning of the switching capability field) >>> >>> >>> >>> WRT issue 2: it is analyzed in section 5.3 of the draft (version - >> 00). >>> I'm copying it below for your convenience >>> >>> >>> >>> In this example the advertisement of an ODUflex->ODU3 hierarchy is >>> >>> shown. In case of ODUflex advertisement the MAX LSP bandwidth >> needs >>> >>> to be advertised but in some cases also information about the >>> >>> Unreserved bandwidth could be useful. The amount of Unreserved >>> >>> bandwidth does not give a clear indication of how many ODUflex LSP >>> >>> can be set up either at the MAX LSP Bandwidth or at different >> rates, >>> >>> as it gives no information about the spatial allocation of the >> free >>> >>> TSs. >>> >>> >>> >>> An indication of the amount of Unreserved bandwidth could be >> useful >>> >>> during the path computation process, as shown in the following >>> >>> example. Supposing there are two TE-links (A and B) with MAX LSP >>> >>> Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved >>> >>> Bandwidth are available on Link A, 10Gbps on Link B and 3 ODUflex >>> >>> LSPs of 10 GBps each, have to be restored, for sure only one can >> be >>> >>> restored along Link B and it is probable (but not sure) that two >> of >>> >>> them can be restored along Link A. >>> >>> >>> >>> Early proposal was to have, in the case of variable containers >>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) as >> a >>> mandatory piece of information and the Unreserved bandiwdth TLV (Type >> 2) >>> as an optional piece of information. >>> >>> The comment received is that optional information can lead to >>> interworking issues and the counter proposal was to have both pieces >> of >>> information as mandatory and, as a consequence, merge the two TLVs >> into >>> a single one. >>> >>> >>> >>> We'd like to hear the opinion of the WG on both issues before >> proceeding >>> with any modification to the document. >>> >>> >>> >>> Thanks, >>> >>> Daniele >>> >>> >>> >>> >>> >>> >>> *DANIELE CECCARELLI * >>> *System & Technology - DU IP & Broadband* >>> >>> >>> Via L.Calda, 5 >>> Genova, Italy >>> Phone +390106002512 >>> Mobile +393346725750 >>> daniele.ceccarelli@ericsson.com >>> www.ericsson.com >>> >>> >>> >>> >>> >>> >>> This Communication is Confidential. We only send and receive email on >>> the basis of the term set out at www.ericsson.com/email_disclaimer >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > > > From jdrake@juniper.net Wed Nov 30 12:01:08 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A90921F84AF for ; Wed, 30 Nov 2011 12:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Caa+jN1l9wSS for ; Wed, 30 Nov 2011 12:01:07 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF041F0C5C for ; Wed, 30 Nov 2011 12:00:57 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTtaLb5A793ymtU0N0xkzkmH6Llt3vVjb@postini.com; Wed, 30 Nov 2011 12:00:57 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 30 Nov 2011 11:59:51 -0800 From: John E Drake To: Lou Berger Date: Wed, 30 Nov 2011 11:59:49 -0800 Thread-Topic: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) Thread-Index: Acyvfy3OHELEI/kxQNCYLrvojmo6JgAGOh8Q Message-ID: <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> In-Reply-To: <4ED65D2D.2040400@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:01:08 -0000 Using Switching Capability to indicate link bandwidth seems ill-considered = at best, especially since this information is carried in other fields, and = as Daniele noted, it significantly overloads to intended meaning of Switchi= ng Capability. It also is inconsistent with the usage of Switching Capabil= ity in SDH/SONET. A more extensive quote from RFC4202 is the following, which seems clear eno= ugh to me: "In the context of this document we say that a link is connected to a node = by an interface. In the context of GMPLS interfaces may have different swi= tching capabilities. For example an interface that connects a given link t= o a node may not be able to switch individual packets, but it may be able t= o switch channels within an SDH payload. Interfaces at each end of a link = need not have the same switching capabilities. Interfaces on the same node= need not have the same switching capabilities." > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, November 30, 2011 8:43 AM > To: John E Drake > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >=20 > Great. Care to substantiate your point? >=20 > On 11/30/2011 11:14 AM, John E Drake wrote: > > I completely disagree. > > > >> -----Original Message----- > >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > Behalf > >> Of Lou Berger > >> Sent: Wednesday, November 30, 2011 7:22 AM > >> To: Daniele Ceccarelli > >> Cc: CCAMP > >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > 1/2) > >> > >> Hi Daniele, > >> Since I raised the point, I guess I need to champion it! (With > >> chair > >> hat off.) > >> > >> All, > >> > >> Daniele said: > >>> WRT issue 1: the proposal was to indicate the bottom most ODUk of > the > >>> muxing hiearachy in the Switching Capability field of the ISCD. > After > >>> a quick talk with the other authors of the ID, the idea was to > reject > >>> the proposal as it would lead to an overloading of the meaning of > the > >>> Switching Capability field. (even if the definition of PSC1-2-3-4 > >>> already overloads the meaning of the switching capability field) > >> > >> This really goes to the interpretation of the intent of Switching > >> Capability Types. So we have a few definitions: 3471 says "the type > of > >> switching that should be performed", 4202 says "describes switching > >> capability of an interface." 3945 doesn't really define the term (it > >> just references 4202), but does equate it with a "layer". While it > >> allows for hierarchy within a "layer" it also says hierarchy occurs > >> "between interface types". > >> > >> So I interpret Switching Capability Types to represent (a) different > >> switching/technology layers and (b) different levels of hierarchy -- > >> even within a layer. I think (a) is identifiable in the definition > of > >> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC, > >> and > >> FSC), and (b) is identifiable in the original types plus the > definition > >> of PSC-1 through PSC-4. > >> > >> So how does this apply to our current OTN work? > >> > >> To me, the first question to ask relates to (a), and is should each > >> ODUk > >> be modeled as a separate layer? > >> > >> I know this has been a much debated point, and it seems to me that > they > >> are, but more for the perspective of switching layers than > technology > >> layers (i.e., they are clearly the same technology but are different > >> granularity of swicthing.) So this is a yes for me. > >> > >> I think the second question to ask relates to (b), and is does each > >> ODUk > >> represent a different level of hierarchy? > >> > >> I see this as simply yes, and no different than what has been done > more > >> recently with Ethernet or, even if we do continue to model OTN as a > >> single layer, no different than PSC-1 -> PSC-4. > >> > >> There's also a minor processing efficiency gained by this approach > for > >> nodes that support a smaller set of ODUks than are advertised within > an > >> IGP. > >> > >> Based on all this, I believe different ODUk's should use different > >> Switching Types. In particular, I'm proposing: > >> (1) that either the framework or info documents identify that > >> a per-OTUk Switching Capability Types will be used to support > >> G.709v3. > >> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different > >> Switching Cap field value for each ODUk, and that it state > >> that the value corresponding to the signal type identified in > >> the #stages=3D0 of the ISCP be set. (Without any other changes > >> to the current definition of ISCD.) > >> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to > >> match above. > >> > >> To keep thinks generic, we probably should use TDM-1 through TDM-n > as > >> the new Switching Capability Types, but this is a secondary > discussion. > >> > >> Comments? > >> > >> Lou > >> > >> PS While the above is an important change, it doesn't significantly > >> impact encoding and won't take much text to make the actual change, > so > >> this is a discussion that can continue until Paris if we really need > a > >> face to face to resolve the discussion. > >> > >> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > >>> Hi CCAMP, > >>> > >>> > >>> > >>> During the OTN OSPF draft presentation at the IETF meeting in > Taipei > >> two > >>> comments were raised with respect to the following issues: > >>> > >>> > >>> > >>> - Issue 1: Using different switching caps for each ODU type > >>> > >>> - Issue 2: Type 2 (unres bandwidth for variable containers) and > Type > >> 3 > >>> (MAX LSP bandwidth foe variable containers always used in tandem? > >>> > >>> > >>> > >>> WRT issue 1: the proposal was to indicate the bottom most ODUk of > the > >>> muxing hiearachy in the Switching Capability field of the ISCD. > After > >> a > >>> quick talk with the other authors of the ID, the idea was to reject > >> the > >>> proposal as it would lead to an overloading of the meaning of the > >>> Switching Capability field. (even if the definition of PSC1-2-3-4 > >>> already overloads the meaning of the switching capability field) > >>> > >>> > >>> > >>> WRT issue 2: it is analyzed in section 5.3 of the draft (version - > >> 00). > >>> I'm copying it below for your convenience > >>> > >>> > >>> > >>> In this example the advertisement of an ODUflex->ODU3 hierarchy > is > >>> > >>> shown. In case of ODUflex advertisement the MAX LSP bandwidth > >> needs > >>> > >>> to be advertised but in some cases also information about the > >>> > >>> Unreserved bandwidth could be useful. The amount of Unreserved > >>> > >>> bandwidth does not give a clear indication of how many ODUflex > LSP > >>> > >>> can be set up either at the MAX LSP Bandwidth or at different > >> rates, > >>> > >>> as it gives no information about the spatial allocation of the > >> free > >>> > >>> TSs. > >>> > >>> > >>> > >>> An indication of the amount of Unreserved bandwidth could be > >> useful > >>> > >>> during the path computation process, as shown in the following > >>> > >>> example. Supposing there are two TE-links (A and B) with MAX > LSP > >>> > >>> Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved > >>> > >>> Bandwidth are available on Link A, 10Gbps on Link B and 3 > ODUflex > >>> > >>> LSPs of 10 GBps each, have to be restored, for sure only one can > >> be > >>> > >>> restored along Link B and it is probable (but not sure) that two > >> of > >>> > >>> them can be restored along Link A. > >>> > >>> > >>> > >>> Early proposal was to have, in the case of variable containers > >>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) > as > >> a > >>> mandatory piece of information and the Unreserved bandiwdth TLV > (Type > >> 2) > >>> as an optional piece of information. > >>> > >>> The comment received is that optional information can lead to > >>> interworking issues and the counter proposal was to have both > pieces > >> of > >>> information as mandatory and, as a consequence, merge the two TLVs > >> into > >>> a single one. > >>> > >>> > >>> > >>> We'd like to hear the opinion of the WG on both issues before > >> proceeding > >>> with any modification to the document. > >>> > >>> > >>> > >>> Thanks, > >>> > >>> Daniele > >>> > >>> > >>> > >>> > >>> > >>> > >>> *DANIELE CECCARELLI * > >>> *System & Technology - DU IP & Broadband* > >>> > >>> > >>> Via L.Calda, 5 > >>> Genova, Italy > >>> Phone +390106002512 > >>> Mobile +393346725750 > >>> daniele.ceccarelli@ericsson.com > >>> www.ericsson.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> This Communication is Confidential. We only send and receive email > on > >>> the basis of the term set out at www.ericsson.com/email_disclaimer > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > > > > > > > > From lberger@labn.net Wed Nov 30 13:09:37 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB89A21F84F5 for ; Wed, 30 Nov 2011 13:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.628 X-Spam-Level: X-Spam-Status: No, score=-101.628 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgkQkmbwF3K0 for ; Wed, 30 Nov 2011 13:09:36 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id B72ED21F84ED for ; Wed, 30 Nov 2011 13:09:36 -0800 (PST) Received: (qmail 11368 invoked by uid 0); 30 Nov 2011 21:09:15 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 30 Nov 2011 21:09:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=sLhtLGUUIkvZ5fYoPQgSEif72CPcAz8Y1cnDJlUkfr8=; b=mCwt1+Axfp4JF+qflZxGwfhtqBwRntoEslJfH8zYz5ObDz00yv4vI9qY+OBVafxNoD0xKoWbNCtFjFeJt8PLLP7kW6wgV7HdHk8KVufu/qegFoYWTELkiwUz/uUY8jCM; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVrP1-0006s5-39; Wed, 30 Nov 2011 14:09:15 -0700 Message-ID: <4ED69B7D.409@labn.net> Date: Wed, 30 Nov 2011 16:09:17 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:09:38 -0000 John, see below On 11/30/2011 2:59 PM, John E Drake wrote: > Using Switching Capability to indicate link bandwidth seems > ill-considered at best, especially since this information is carried > in other fields, and as Daniele noted, it significantly overloads to > intended meaning of Switching Capability. I agree with the point on BW, but my point was related to the layer&hierarchy implications of the different ODUk values. I'd think that using values that are TDM-1 -> TDM-n should make this clear and remove any ambiguity related to bandwidth. It is also completely consistent with the base GMPLS definition, i.e., PSC-1 -> PSC-n. > It also is inconsistent > with the usage of Switching Capability in SDH/SONET. Well hopefully we have a better understanding of the technologies involved than we had in the past. > > A more extensive quote from RFC4202 is the following, which seems > clear enough to me: > > "In the context of this document we say that a link is connected to a > node by an interface. In the context of GMPLS interfaces may have > different switching capabilities. For example an interface that > connects a given link to a node may not be able to switch individual > packets, but it may be able to switch channels within an SDH payload. > Interfaces at each end of a link need not have the same switching > capabilities. Interfaces on the same node need not have the same > switching capabilities." Not sure how this helps clarify anything... Lou > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, November 30, 2011 8:43 AM >> To: John E Drake >> Cc: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >> >> Great. Care to substantiate your point? >> >> On 11/30/2011 11:14 AM, John E Drake wrote: >>> I completely disagree. >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >> Behalf >>>> Of Lou Berger >>>> Sent: Wednesday, November 30, 2011 7:22 AM >>>> To: Daniele Ceccarelli >>>> Cc: CCAMP >>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue >> 1/2) >>>> >>>> Hi Daniele, >>>> Since I raised the point, I guess I need to champion it! (With >>>> chair >>>> hat off.) >>>> >>>> All, >>>> >>>> Daniele said: >>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of >> the >>>>> muxing hiearachy in the Switching Capability field of the ISCD. >> After >>>>> a quick talk with the other authors of the ID, the idea was to >> reject >>>>> the proposal as it would lead to an overloading of the meaning of >> the >>>>> Switching Capability field. (even if the definition of PSC1-2-3-4 >>>>> already overloads the meaning of the switching capability field) >>>> >>>> This really goes to the interpretation of the intent of Switching >>>> Capability Types. So we have a few definitions: 3471 says "the type >> of >>>> switching that should be performed", 4202 says "describes switching >>>> capability of an interface." 3945 doesn't really define the term (it >>>> just references 4202), but does equate it with a "layer". While it >>>> allows for hierarchy within a "layer" it also says hierarchy occurs >>>> "between interface types". >>>> >>>> So I interpret Switching Capability Types to represent (a) different >>>> switching/technology layers and (b) different levels of hierarchy -- >>>> even within a layer. I think (a) is identifiable in the definition >> of >>>> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC, >>>> and >>>> FSC), and (b) is identifiable in the original types plus the >> definition >>>> of PSC-1 through PSC-4. >>>> >>>> So how does this apply to our current OTN work? >>>> >>>> To me, the first question to ask relates to (a), and is should each >>>> ODUk >>>> be modeled as a separate layer? >>>> >>>> I know this has been a much debated point, and it seems to me that >> they >>>> are, but more for the perspective of switching layers than >> technology >>>> layers (i.e., they are clearly the same technology but are different >>>> granularity of swicthing.) So this is a yes for me. >>>> >>>> I think the second question to ask relates to (b), and is does each >>>> ODUk >>>> represent a different level of hierarchy? >>>> >>>> I see this as simply yes, and no different than what has been done >> more >>>> recently with Ethernet or, even if we do continue to model OTN as a >>>> single layer, no different than PSC-1 -> PSC-4. >>>> >>>> There's also a minor processing efficiency gained by this approach >> for >>>> nodes that support a smaller set of ODUks than are advertised within >> an >>>> IGP. >>>> >>>> Based on all this, I believe different ODUk's should use different >>>> Switching Types. In particular, I'm proposing: >>>> (1) that either the framework or info documents identify that >>>> a per-OTUk Switching Capability Types will be used to support >>>> G.709v3. >>>> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different >>>> Switching Cap field value for each ODUk, and that it state >>>> that the value corresponding to the signal type identified in >>>> the #stages=0 of the ISCP be set. (Without any other changes >>>> to the current definition of ISCD.) >>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to >>>> match above. >>>> >>>> To keep thinks generic, we probably should use TDM-1 through TDM-n >> as >>>> the new Switching Capability Types, but this is a secondary >> discussion. >>>> >>>> Comments? >>>> >>>> Lou >>>> >>>> PS While the above is an important change, it doesn't significantly >>>> impact encoding and won't take much text to make the actual change, >> so >>>> this is a discussion that can continue until Paris if we really need >> a >>>> face to face to resolve the discussion. >>>> >>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: >>>>> Hi CCAMP, >>>>> >>>>> >>>>> >>>>> During the OTN OSPF draft presentation at the IETF meeting in >> Taipei >>>> two >>>>> comments were raised with respect to the following issues: >>>>> >>>>> >>>>> >>>>> - Issue 1: Using different switching caps for each ODU type >>>>> >>>>> - Issue 2: Type 2 (unres bandwidth for variable containers) and >> Type >>>> 3 >>>>> (MAX LSP bandwidth foe variable containers always used in tandem? >>>>> >>>>> >>>>> >>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of >> the >>>>> muxing hiearachy in the Switching Capability field of the ISCD. >> After >>>> a >>>>> quick talk with the other authors of the ID, the idea was to reject >>>> the >>>>> proposal as it would lead to an overloading of the meaning of the >>>>> Switching Capability field. (even if the definition of PSC1-2-3-4 >>>>> already overloads the meaning of the switching capability field) >>>>> >>>>> >>>>> >>>>> WRT issue 2: it is analyzed in section 5.3 of the draft (version - >>>> 00). >>>>> I'm copying it below for your convenience >>>>> >>>>> >>>>> >>>>> In this example the advertisement of an ODUflex->ODU3 hierarchy >> is >>>>> >>>>> shown. In case of ODUflex advertisement the MAX LSP bandwidth >>>> needs >>>>> >>>>> to be advertised but in some cases also information about the >>>>> >>>>> Unreserved bandwidth could be useful. The amount of Unreserved >>>>> >>>>> bandwidth does not give a clear indication of how many ODUflex >> LSP >>>>> >>>>> can be set up either at the MAX LSP Bandwidth or at different >>>> rates, >>>>> >>>>> as it gives no information about the spatial allocation of the >>>> free >>>>> >>>>> TSs. >>>>> >>>>> >>>>> >>>>> An indication of the amount of Unreserved bandwidth could be >>>> useful >>>>> >>>>> during the path computation process, as shown in the following >>>>> >>>>> example. Supposing there are two TE-links (A and B) with MAX >> LSP >>>>> >>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved >>>>> >>>>> Bandwidth are available on Link A, 10Gbps on Link B and 3 >> ODUflex >>>>> >>>>> LSPs of 10 GBps each, have to be restored, for sure only one can >>>> be >>>>> >>>>> restored along Link B and it is probable (but not sure) that two >>>> of >>>>> >>>>> them can be restored along Link A. >>>>> >>>>> >>>>> >>>>> Early proposal was to have, in the case of variable containers >>>>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) >> as >>>> a >>>>> mandatory piece of information and the Unreserved bandiwdth TLV >> (Type >>>> 2) >>>>> as an optional piece of information. >>>>> >>>>> The comment received is that optional information can lead to >>>>> interworking issues and the counter proposal was to have both >> pieces >>>> of >>>>> information as mandatory and, as a consequence, merge the two TLVs >>>> into >>>>> a single one. >>>>> >>>>> >>>>> >>>>> We'd like to hear the opinion of the WG on both issues before >>>> proceeding >>>>> with any modification to the document. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Daniele >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *DANIELE CECCARELLI * >>>>> *System & Technology - DU IP & Broadband* >>>>> >>>>> >>>>> Via L.Calda, 5 >>>>> Genova, Italy >>>>> Phone +390106002512 >>>>> Mobile +393346725750 >>>>> daniele.ceccarelli@ericsson.com >>>>> www.ericsson.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This Communication is Confidential. We only send and receive email >> on >>>>> the basis of the term set out at www.ericsson.com/email_disclaimer >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >>> > > > > From jdrake@juniper.net Wed Nov 30 13:38:47 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515CD1F0C89 for ; Wed, 30 Nov 2011 13:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 350v0gsh48rm for ; Wed, 30 Nov 2011 13:38:46 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id DFE561F0C88 for ; Wed, 30 Nov 2011 13:38:45 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTtaiWVjKOcpfF/sPawNT5gtykzl0Zqsp@postini.com; Wed, 30 Nov 2011 13:38:45 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 30 Nov 2011 13:37:20 -0800 From: John E Drake To: Lou Berger Date: Wed, 30 Nov 2011 13:37:17 -0800 Thread-Topic: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) Thread-Index: AcyvpFYZoNatGn3JRiaThEtYl5pAcwAALi+w Message-ID: <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> In-Reply-To: <4ED69B7D.409@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:38:47 -0000 Comments inline. I still think this is a terrible idea and I would like to= see what the rest of the WG thinks. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, November 30, 2011 1:09 PM > To: John E Drake > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >=20 >=20 > John, >=20 > see below >=20 >=20 > On 11/30/2011 2:59 PM, John E Drake wrote: > > Using Switching Capability to indicate link bandwidth seems > > ill-considered at best, especially since this information is carried > > in other fields, and as Daniele noted, it significantly overloads to > > intended meaning of Switching Capability. >=20 > I agree with the point on BW, but my point was related to the > layer&hierarchy implications of the different ODUk values. I'd think > that using values that are TDM-1 -> TDM-n should make this clear and > remove any ambiguity related to bandwidth. It is also completely > consistent with the base GMPLS definition, i.e., PSC-1 -> PSC-n. [JD] You are simply asserting that this is a good idea and further asserti= ng that there is "ambiguity related to bandwidth', without providing any ev= idence. =20 To the best of my knowledge no one ever implemented or deployed the PSC-1 -= > PSC-4 hierarchy, simply because no one could figure out what it meant. T= o quote from you, below, "Well hopefully we have a better understanding of = the technologies involved than we had in the past.". I.e., we should all u= nderstand that PSC-1 -> PSC-4 was a bad idea (tm) and move on. =20 >=20 > > It also is inconsistent > > with the usage of Switching Capability in SDH/SONET. >=20 > Well hopefully we have a better understanding of the technologies > involved than we had in the past. [JD] I think we had a very good understanding of SDH/SONET then and we have= a very good understanding of OTN now, and in both cases the authors saw no= requirement to overload switching capability in the manner you are suggest= ing. >=20 > > > > A more extensive quote from RFC4202 is the following, which seems > > clear enough to me: > > > > "In the context of this document we say that a link is connected to a > > node by an interface. In the context of GMPLS interfaces may have > > different switching capabilities. For example an interface that > > connects a given link to a node may not be able to switch individual > > packets, but it may be able to switch channels within an SDH payload. > > Interfaces at each end of a link need not have the same switching > > capabilities. Interfaces on the same node need not have the same > > switching capabilities." >=20 > Not sure how this helps clarify anything... [JD] I think it clarifies that switching capabilities is meant to describe= how a given interface switches the information with which it is provided. = This has nothing to do with the interface's bandwidth. >=20 > Lou > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Wednesday, November 30, 2011 8:43 AM > >> To: John E Drake > >> Cc: Daniele Ceccarelli; CCAMP > >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > 1/2) > >> > >> Great. Care to substantiate your point? > >> > >> On 11/30/2011 11:14 AM, John E Drake wrote: > >>> I completely disagree. > >>> > >>>> -----Original Message----- > >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >> Behalf > >>>> Of Lou Berger > >>>> Sent: Wednesday, November 30, 2011 7:22 AM > >>>> To: Daniele Ceccarelli > >>>> Cc: CCAMP > >>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > >> 1/2) > >>>> > >>>> Hi Daniele, > >>>> Since I raised the point, I guess I need to champion it! (With > >>>> chair > >>>> hat off.) > >>>> > >>>> All, > >>>> > >>>> Daniele said: > >>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of > >> the > >>>>> muxing hiearachy in the Switching Capability field of the ISCD. > >> After > >>>>> a quick talk with the other authors of the ID, the idea was to > >> reject > >>>>> the proposal as it would lead to an overloading of the meaning of > >> the > >>>>> Switching Capability field. (even if the definition of PSC1-2-3-4 > >>>>> already overloads the meaning of the switching capability field) > >>>> > >>>> This really goes to the interpretation of the intent of Switching > >>>> Capability Types. So we have a few definitions: 3471 says "the > type > >> of > >>>> switching that should be performed", 4202 says "describes > switching > >>>> capability of an interface." 3945 doesn't really define the term > (it > >>>> just references 4202), but does equate it with a "layer". While it > >>>> allows for hierarchy within a "layer" it also says hierarchy > occurs > >>>> "between interface types". > >>>> > >>>> So I interpret Switching Capability Types to represent (a) > different > >>>> switching/technology layers and (b) different levels of hierarchy > -- > >>>> even within a layer. I think (a) is identifiable in the > definition > >> of > >>>> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM > LSC, > >>>> and > >>>> FSC), and (b) is identifiable in the original types plus the > >> definition > >>>> of PSC-1 through PSC-4. > >>>> > >>>> So how does this apply to our current OTN work? > >>>> > >>>> To me, the first question to ask relates to (a), and is should > each > >>>> ODUk > >>>> be modeled as a separate layer? > >>>> > >>>> I know this has been a much debated point, and it seems to me that > >> they > >>>> are, but more for the perspective of switching layers than > >> technology > >>>> layers (i.e., they are clearly the same technology but are > different > >>>> granularity of swicthing.) So this is a yes for me. > >>>> > >>>> I think the second question to ask relates to (b), and is does > each > >>>> ODUk > >>>> represent a different level of hierarchy? > >>>> > >>>> I see this as simply yes, and no different than what has been done > >> more > >>>> recently with Ethernet or, even if we do continue to model OTN as > a > >>>> single layer, no different than PSC-1 -> PSC-4. > >>>> > >>>> There's also a minor processing efficiency gained by this approach > >> for > >>>> nodes that support a smaller set of ODUks than are advertised > within > >> an > >>>> IGP. > >>>> > >>>> Based on all this, I believe different ODUk's should use different > >>>> Switching Types. In particular, I'm proposing: > >>>> (1) that either the framework or info documents identify that > >>>> a per-OTUk Switching Capability Types will be used to support > >>>> G.709v3. > >>>> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different > >>>> Switching Cap field value for each ODUk, and that it state > >>>> that the value corresponding to the signal type identified in > >>>> the #stages=3D0 of the ISCP be set. (Without any other changes > >>>> to the current definition of ISCD.) > >>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to > >>>> match above. > >>>> > >>>> To keep thinks generic, we probably should use TDM-1 through TDM-n > >> as > >>>> the new Switching Capability Types, but this is a secondary > >> discussion. > >>>> > >>>> Comments? > >>>> > >>>> Lou > >>>> > >>>> PS While the above is an important change, it doesn't > significantly > >>>> impact encoding and won't take much text to make the actual > change, > >> so > >>>> this is a discussion that can continue until Paris if we really > need > >> a > >>>> face to face to resolve the discussion. > >>>> > >>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > >>>>> Hi CCAMP, > >>>>> > >>>>> > >>>>> > >>>>> During the OTN OSPF draft presentation at the IETF meeting in > >> Taipei > >>>> two > >>>>> comments were raised with respect to the following issues: > >>>>> > >>>>> > >>>>> > >>>>> - Issue 1: Using different switching caps for each ODU type > >>>>> > >>>>> - Issue 2: Type 2 (unres bandwidth for variable containers) and > >> Type > >>>> 3 > >>>>> (MAX LSP bandwidth foe variable containers always used in tandem? > >>>>> > >>>>> > >>>>> > >>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of > >> the > >>>>> muxing hiearachy in the Switching Capability field of the ISCD. > >> After > >>>> a > >>>>> quick talk with the other authors of the ID, the idea was to > reject > >>>> the > >>>>> proposal as it would lead to an overloading of the meaning of the > >>>>> Switching Capability field. (even if the definition of PSC1-2-3-4 > >>>>> already overloads the meaning of the switching capability field) > >>>>> > >>>>> > >>>>> > >>>>> WRT issue 2: it is analyzed in section 5.3 of the draft (version > - > >>>> 00). > >>>>> I'm copying it below for your convenience > >>>>> > >>>>> > >>>>> > >>>>> In this example the advertisement of an ODUflex->ODU3 > hierarchy > >> is > >>>>> > >>>>> shown. In case of ODUflex advertisement the MAX LSP bandwidth > >>>> needs > >>>>> > >>>>> to be advertised but in some cases also information about the > >>>>> > >>>>> Unreserved bandwidth could be useful. The amount of > Unreserved > >>>>> > >>>>> bandwidth does not give a clear indication of how many ODUflex > >> LSP > >>>>> > >>>>> can be set up either at the MAX LSP Bandwidth or at different > >>>> rates, > >>>>> > >>>>> as it gives no information about the spatial allocation of the > >>>> free > >>>>> > >>>>> TSs. > >>>>> > >>>>> > >>>>> > >>>>> An indication of the amount of Unreserved bandwidth could be > >>>> useful > >>>>> > >>>>> during the path computation process, as shown in the following > >>>>> > >>>>> example. Supposing there are two TE-links (A and B) with MAX > >> LSP > >>>>> > >>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved > >>>>> > >>>>> Bandwidth are available on Link A, 10Gbps on Link B and 3 > >> ODUflex > >>>>> > >>>>> LSPs of 10 GBps each, have to be restored, for sure only one > can > >>>> be > >>>>> > >>>>> restored along Link B and it is probable (but not sure) that > two > >>>> of > >>>>> > >>>>> them can be restored along Link A. > >>>>> > >>>>> > >>>>> > >>>>> Early proposal was to have, in the case of variable containers > >>>>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) > >> as > >>>> a > >>>>> mandatory piece of information and the Unreserved bandiwdth TLV > >> (Type > >>>> 2) > >>>>> as an optional piece of information. > >>>>> > >>>>> The comment received is that optional information can lead to > >>>>> interworking issues and the counter proposal was to have both > >> pieces > >>>> of > >>>>> information as mandatory and, as a consequence, merge the two > TLVs > >>>> into > >>>>> a single one. > >>>>> > >>>>> > >>>>> > >>>>> We'd like to hear the opinion of the WG on both issues before > >>>> proceeding > >>>>> with any modification to the document. > >>>>> > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Daniele > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> *DANIELE CECCARELLI * > >>>>> *System & Technology - DU IP & Broadband* > >>>>> > >>>>> > >>>>> Via L.Calda, 5 > >>>>> Genova, Italy > >>>>> Phone +390106002512 > >>>>> Mobile +393346725750 > >>>>> daniele.ceccarelli@ericsson.com > >>>>> www.ericsson.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> This Communication is Confidential. We only send and receive > email > >> on > >>>>> the basis of the term set out at > www.ericsson.com/email_disclaimer > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> CCAMP mailing list > >>>>> CCAMP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>> _______________________________________________ > >>>> CCAMP mailing list > >>>> CCAMP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ccamp > >>> > >>> > >>> > >>> > > > > > > > > From lberger@labn.net Wed Nov 30 13:51:38 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200A911E8081 for ; Wed, 30 Nov 2011 13:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4oeGImbuAGE for ; Wed, 30 Nov 2011 13:51:36 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id C9F7211E80BC for ; Wed, 30 Nov 2011 13:51:36 -0800 (PST) Received: (qmail 10056 invoked by uid 0); 30 Nov 2011 21:51:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 30 Nov 2011 21:51:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=TAXMU47rODiTVOEbsYkvipEE2z1gtoioWjip0qsHVs0=; b=CSBu+jbn8uuXY19pK/Br8iO9zUb9+asKWc/tOJZSe6Gm035m7wRGm/bb9X2diUG4SqVIAuV3sRzzOxH327uX91iBUW1E9+o0ku9B2ZdoM5Hcwy0M6UxbgS52Vw+9m7/v; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVs3d-0004Pm-Pv; Wed, 30 Nov 2011 14:51:14 -0700 Message-ID: <4ED6A555.1000706@labn.net> Date: Wed, 30 Nov 2011 16:51:17 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:51:38 -0000 So you're basically arguing that SC shouldn't be used to indicate different levels of hierarchy, i.e., usage (b) in my earlier message, and that the definition of PSC-1 -> n was flawed. Right? Which then reduces the meaning of SC to simply and indicator of label type and ISCD format indicator. Is this your position? Lou On 11/30/2011 4:37 PM, John E Drake wrote: > Comments inline. I still think this is a terrible idea and I would like to see what the rest of the WG thinks. > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, November 30, 2011 1:09 PM >> To: John E Drake >> Cc: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >> >> >> John, >> >> see below >> >> >> On 11/30/2011 2:59 PM, John E Drake wrote: >>> Using Switching Capability to indicate link bandwidth seems >>> ill-considered at best, especially since this information is carried >>> in other fields, and as Daniele noted, it significantly overloads to >>> intended meaning of Switching Capability. >> >> I agree with the point on BW, but my point was related to the >> layer&hierarchy implications of the different ODUk values. I'd think >> that using values that are TDM-1 -> TDM-n should make this clear and >> remove any ambiguity related to bandwidth. It is also completely >> consistent with the base GMPLS definition, i.e., PSC-1 -> PSC-n. > > [JD] You are simply asserting that this is a good idea and further asserting that there is "ambiguity related to bandwidth', without providing any evidence. > > To the best of my knowledge no one ever implemented or deployed the PSC-1 -> PSC-4 hierarchy, simply because no one could figure out what it meant. To quote from you, below, "Well hopefully we have a better understanding of the technologies involved than we had in the past.". I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea (tm) and move on. > >> >>> It also is inconsistent >>> with the usage of Switching Capability in SDH/SONET. >> >> Well hopefully we have a better understanding of the technologies >> involved than we had in the past. > > [JD] I think we had a very good understanding of SDH/SONET then and we have a very good understanding of OTN now, and in both cases the authors saw no requirement to overload switching capability in the manner you are suggesting. > >> >>> >>> A more extensive quote from RFC4202 is the following, which seems >>> clear enough to me: >>> >>> "In the context of this document we say that a link is connected to a >>> node by an interface. In the context of GMPLS interfaces may have >>> different switching capabilities. For example an interface that >>> connects a given link to a node may not be able to switch individual >>> packets, but it may be able to switch channels within an SDH payload. >>> Interfaces at each end of a link need not have the same switching >>> capabilities. Interfaces on the same node need not have the same >>> switching capabilities." >> >> Not sure how this helps clarify anything... > > [JD] I think it clarifies that switching capabilities is meant to describe how a given interface switches the information with which it is provided. This has nothing to do with the interface's bandwidth. > >> >> Lou >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, November 30, 2011 8:43 AM >>>> To: John E Drake >>>> Cc: Daniele Ceccarelli; CCAMP >>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue >> 1/2) >>>> >>>> Great. Care to substantiate your point? >>>> >>>> On 11/30/2011 11:14 AM, John E Drake wrote: >>>>> I completely disagree. >>>>> >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf >>>>>> Of Lou Berger >>>>>> Sent: Wednesday, November 30, 2011 7:22 AM >>>>>> To: Daniele Ceccarelli >>>>>> Cc: CCAMP >>>>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue >>>> 1/2) >>>>>> >>>>>> Hi Daniele, >>>>>> Since I raised the point, I guess I need to champion it! (With >>>>>> chair >>>>>> hat off.) >>>>>> >>>>>> All, >>>>>> >>>>>> Daniele said: >>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of >>>> the >>>>>>> muxing hiearachy in the Switching Capability field of the ISCD. >>>> After >>>>>>> a quick talk with the other authors of the ID, the idea was to >>>> reject >>>>>>> the proposal as it would lead to an overloading of the meaning of >>>> the >>>>>>> Switching Capability field. (even if the definition of PSC1-2-3-4 >>>>>>> already overloads the meaning of the switching capability field) >>>>>> >>>>>> This really goes to the interpretation of the intent of Switching >>>>>> Capability Types. So we have a few definitions: 3471 says "the >> type >>>> of >>>>>> switching that should be performed", 4202 says "describes >> switching >>>>>> capability of an interface." 3945 doesn't really define the term >> (it >>>>>> just references 4202), but does equate it with a "layer". While it >>>>>> allows for hierarchy within a "layer" it also says hierarchy >> occurs >>>>>> "between interface types". >>>>>> >>>>>> So I interpret Switching Capability Types to represent (a) >> different >>>>>> switching/technology layers and (b) different levels of hierarchy >> -- >>>>>> even within a layer. I think (a) is identifiable in the >> definition >>>> of >>>>>> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM >> LSC, >>>>>> and >>>>>> FSC), and (b) is identifiable in the original types plus the >>>> definition >>>>>> of PSC-1 through PSC-4. >>>>>> >>>>>> So how does this apply to our current OTN work? >>>>>> >>>>>> To me, the first question to ask relates to (a), and is should >> each >>>>>> ODUk >>>>>> be modeled as a separate layer? >>>>>> >>>>>> I know this has been a much debated point, and it seems to me that >>>> they >>>>>> are, but more for the perspective of switching layers than >>>> technology >>>>>> layers (i.e., they are clearly the same technology but are >> different >>>>>> granularity of swicthing.) So this is a yes for me. >>>>>> >>>>>> I think the second question to ask relates to (b), and is does >> each >>>>>> ODUk >>>>>> represent a different level of hierarchy? >>>>>> >>>>>> I see this as simply yes, and no different than what has been done >>>> more >>>>>> recently with Ethernet or, even if we do continue to model OTN as >> a >>>>>> single layer, no different than PSC-1 -> PSC-4. >>>>>> >>>>>> There's also a minor processing efficiency gained by this approach >>>> for >>>>>> nodes that support a smaller set of ODUks than are advertised >> within >>>> an >>>>>> IGP. >>>>>> >>>>>> Based on all this, I believe different ODUk's should use different >>>>>> Switching Types. In particular, I'm proposing: >>>>>> (1) that either the framework or info documents identify that >>>>>> a per-OTUk Switching Capability Types will be used to support >>>>>> G.709v3. >>>>>> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different >>>>>> Switching Cap field value for each ODUk, and that it state >>>>>> that the value corresponding to the signal type identified in >>>>>> the #stages=0 of the ISCP be set. (Without any other changes >>>>>> to the current definition of ISCD.) >>>>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to >>>>>> match above. >>>>>> >>>>>> To keep thinks generic, we probably should use TDM-1 through TDM-n >>>> as >>>>>> the new Switching Capability Types, but this is a secondary >>>> discussion. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Lou >>>>>> >>>>>> PS While the above is an important change, it doesn't >> significantly >>>>>> impact encoding and won't take much text to make the actual >> change, >>>> so >>>>>> this is a discussion that can continue until Paris if we really >> need >>>> a >>>>>> face to face to resolve the discussion. >>>>>> >>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: >>>>>>> Hi CCAMP, >>>>>>> >>>>>>> >>>>>>> >>>>>>> During the OTN OSPF draft presentation at the IETF meeting in >>>> Taipei >>>>>> two >>>>>>> comments were raised with respect to the following issues: >>>>>>> >>>>>>> >>>>>>> >>>>>>> - Issue 1: Using different switching caps for each ODU type >>>>>>> >>>>>>> - Issue 2: Type 2 (unres bandwidth for variable containers) and >>>> Type >>>>>> 3 >>>>>>> (MAX LSP bandwidth foe variable containers always used in tandem? >>>>>>> >>>>>>> >>>>>>> >>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk of >>>> the >>>>>>> muxing hiearachy in the Switching Capability field of the ISCD. >>>> After >>>>>> a >>>>>>> quick talk with the other authors of the ID, the idea was to >> reject >>>>>> the >>>>>>> proposal as it would lead to an overloading of the meaning of the >>>>>>> Switching Capability field. (even if the definition of PSC1-2-3-4 >>>>>>> already overloads the meaning of the switching capability field) >>>>>>> >>>>>>> >>>>>>> >>>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft (version >> - >>>>>> 00). >>>>>>> I'm copying it below for your convenience >>>>>>> >>>>>>> >>>>>>> >>>>>>> In this example the advertisement of an ODUflex->ODU3 >> hierarchy >>>> is >>>>>>> >>>>>>> shown. In case of ODUflex advertisement the MAX LSP bandwidth >>>>>> needs >>>>>>> >>>>>>> to be advertised but in some cases also information about the >>>>>>> >>>>>>> Unreserved bandwidth could be useful. The amount of >> Unreserved >>>>>>> >>>>>>> bandwidth does not give a clear indication of how many ODUflex >>>> LSP >>>>>>> >>>>>>> can be set up either at the MAX LSP Bandwidth or at different >>>>>> rates, >>>>>>> >>>>>>> as it gives no information about the spatial allocation of the >>>>>> free >>>>>>> >>>>>>> TSs. >>>>>>> >>>>>>> >>>>>>> >>>>>>> An indication of the amount of Unreserved bandwidth could be >>>>>> useful >>>>>>> >>>>>>> during the path computation process, as shown in the following >>>>>>> >>>>>>> example. Supposing there are two TE-links (A and B) with MAX >>>> LSP >>>>>>> >>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved >>>>>>> >>>>>>> Bandwidth are available on Link A, 10Gbps on Link B and 3 >>>> ODUflex >>>>>>> >>>>>>> LSPs of 10 GBps each, have to be restored, for sure only one >> can >>>>>> be >>>>>>> >>>>>>> restored along Link B and it is probable (but not sure) that >> two >>>>>> of >>>>>>> >>>>>>> them can be restored along Link A. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Early proposal was to have, in the case of variable containers >>>>>>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type 3) >>>> as >>>>>> a >>>>>>> mandatory piece of information and the Unreserved bandiwdth TLV >>>> (Type >>>>>> 2) >>>>>>> as an optional piece of information. >>>>>>> >>>>>>> The comment received is that optional information can lead to >>>>>>> interworking issues and the counter proposal was to have both >>>> pieces >>>>>> of >>>>>>> information as mandatory and, as a consequence, merge the two >> TLVs >>>>>> into >>>>>>> a single one. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We'd like to hear the opinion of the WG on both issues before >>>>>> proceeding >>>>>>> with any modification to the document. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Daniele >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *DANIELE CECCARELLI * >>>>>>> *System & Technology - DU IP & Broadband* >>>>>>> >>>>>>> >>>>>>> Via L.Calda, 5 >>>>>>> Genova, Italy >>>>>>> Phone +390106002512 >>>>>>> Mobile +393346725750 >>>>>>> daniele.ceccarelli@ericsson.com >>>>>>> www.ericsson.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This Communication is Confidential. We only send and receive >> email >>>> on >>>>>>> the basis of the term set out at >> www.ericsson.com/email_disclaimer >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > > > From jdrake@juniper.net Wed Nov 30 14:25:32 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663BC21F8BF7 for ; Wed, 30 Nov 2011 14:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U01d5JoomR5U for ; Wed, 30 Nov 2011 14:25:31 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B283521F8BEB for ; Wed, 30 Nov 2011 14:25:30 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTtatV1cb3P10O9x6VCQuNH+Q5naIrQQH@postini.com; Wed, 30 Nov 2011 14:25:30 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 30 Nov 2011 14:23:17 -0800 From: John E Drake To: Lou Berger Date: Wed, 30 Nov 2011 14:23:15 -0800 Thread-Topic: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) Thread-Index: AcyvqjbdnceMmVcwSVe5xfY2d7//SAABGX6w Message-ID: <5E893DB832F57341992548CDBB333163A4B54CAFA4@EMBX01-HQ.jnpr.net> References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> <4ED6A555.1000706@labn.net> In-Reply-To: <4ED6A555.1000706@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:25:32 -0000 Yes, I think that's fair. > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, November 30, 2011 1:51 PM > To: John E Drake > Cc: Daniele Ceccarelli; CCAMP > Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >=20 > So you're basically arguing that SC shouldn't be used to indicate > different levels of hierarchy, i.e., usage (b) in my earlier message, > and that the definition of PSC-1 -> n was flawed. Right? >=20 > Which then reduces the meaning of SC to simply and indicator of label > type and ISCD format indicator. >=20 > Is this your position? >=20 > Lou >=20 > On 11/30/2011 4:37 PM, John E Drake wrote: > > Comments inline. I still think this is a terrible idea and I would > like to see what the rest of the WG thinks. > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Wednesday, November 30, 2011 1:09 PM > >> To: John E Drake > >> Cc: Daniele Ceccarelli; CCAMP > >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > 1/2) > >> > >> > >> John, > >> > >> see below > >> > >> > >> On 11/30/2011 2:59 PM, John E Drake wrote: > >>> Using Switching Capability to indicate link bandwidth seems > >>> ill-considered at best, especially since this information is > carried > >>> in other fields, and as Daniele noted, it significantly overloads > to > >>> intended meaning of Switching Capability. > >> > >> I agree with the point on BW, but my point was related to the > >> layer&hierarchy implications of the different ODUk values. I'd > think > >> that using values that are TDM-1 -> TDM-n should make this clear and > >> remove any ambiguity related to bandwidth. It is also completely > >> consistent with the base GMPLS definition, i.e., PSC-1 -> PSC-n. > > > > [JD] You are simply asserting that this is a good idea and further > asserting that there is "ambiguity related to bandwidth', without > providing any evidence. > > > > To the best of my knowledge no one ever implemented or deployed the > PSC-1 -> PSC-4 hierarchy, simply because no one could figure out what > it meant. To quote from you, below, "Well hopefully we have a better > understanding of the technologies involved than we had in the past.". > I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea (tm) > and move on. > > > >> > >>> It also is inconsistent > >>> with the usage of Switching Capability in SDH/SONET. > >> > >> Well hopefully we have a better understanding of the technologies > >> involved than we had in the past. > > > > [JD] I think we had a very good understanding of SDH/SONET then and > we have a very good understanding of OTN now, and in both cases the > authors saw no requirement to overload switching capability in the > manner you are suggesting. > > > >> > >>> > >>> A more extensive quote from RFC4202 is the following, which seems > >>> clear enough to me: > >>> > >>> "In the context of this document we say that a link is connected to > a > >>> node by an interface. In the context of GMPLS interfaces may have > >>> different switching capabilities. For example an interface that > >>> connects a given link to a node may not be able to switch > individual > >>> packets, but it may be able to switch channels within an SDH > payload. > >>> Interfaces at each end of a link need not have the same switching > >>> capabilities. Interfaces on the same node need not have the same > >>> switching capabilities." > >> > >> Not sure how this helps clarify anything... > > > > [JD] I think it clarifies that switching capabilities is meant to > describe how a given interface switches the information with which it > is provided. This has nothing to do with the interface's bandwidth. > > > >> > >> Lou > >>> > >>>> -----Original Message----- > >>>> From: Lou Berger [mailto:lberger@labn.net] > >>>> Sent: Wednesday, November 30, 2011 8:43 AM > >>>> To: John E Drake > >>>> Cc: Daniele Ceccarelli; CCAMP > >>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > >> 1/2) > >>>> > >>>> Great. Care to substantiate your point? > >>>> > >>>> On 11/30/2011 11:14 AM, John E Drake wrote: > >>>>> I completely disagree. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On > >>>> Behalf > >>>>>> Of Lou Berger > >>>>>> Sent: Wednesday, November 30, 2011 7:22 AM > >>>>>> To: Daniele Ceccarelli > >>>>>> Cc: CCAMP > >>>>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue > >>>> 1/2) > >>>>>> > >>>>>> Hi Daniele, > >>>>>> Since I raised the point, I guess I need to champion it! > (With > >>>>>> chair > >>>>>> hat off.) > >>>>>> > >>>>>> All, > >>>>>> > >>>>>> Daniele said: > >>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk > of > >>>> the > >>>>>>> muxing hiearachy in the Switching Capability field of the ISCD. > >>>> After > >>>>>>> a quick talk with the other authors of the ID, the idea was to > >>>> reject > >>>>>>> the proposal as it would lead to an overloading of the meaning > of > >>>> the > >>>>>>> Switching Capability field. (even if the definition of PSC1-2- > 3-4 > >>>>>>> already overloads the meaning of the switching capability > field) > >>>>>> > >>>>>> This really goes to the interpretation of the intent of > Switching > >>>>>> Capability Types. So we have a few definitions: 3471 says "the > >> type > >>>> of > >>>>>> switching that should be performed", 4202 says "describes > >> switching > >>>>>> capability of an interface." 3945 doesn't really define the term > >> (it > >>>>>> just references 4202), but does equate it with a "layer". While > it > >>>>>> allows for hierarchy within a "layer" it also says hierarchy > >> occurs > >>>>>> "between interface types". > >>>>>> > >>>>>> So I interpret Switching Capability Types to represent (a) > >> different > >>>>>> switching/technology layers and (b) different levels of > hierarchy > >> -- > >>>>>> even within a layer. I think (a) is identifiable in the > >> definition > >>>> of > >>>>>> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM > >> LSC, > >>>>>> and > >>>>>> FSC), and (b) is identifiable in the original types plus the > >>>> definition > >>>>>> of PSC-1 through PSC-4. > >>>>>> > >>>>>> So how does this apply to our current OTN work? > >>>>>> > >>>>>> To me, the first question to ask relates to (a), and is should > >> each > >>>>>> ODUk > >>>>>> be modeled as a separate layer? > >>>>>> > >>>>>> I know this has been a much debated point, and it seems to me > that > >>>> they > >>>>>> are, but more for the perspective of switching layers than > >>>> technology > >>>>>> layers (i.e., they are clearly the same technology but are > >> different > >>>>>> granularity of swicthing.) So this is a yes for me. > >>>>>> > >>>>>> I think the second question to ask relates to (b), and is does > >> each > >>>>>> ODUk > >>>>>> represent a different level of hierarchy? > >>>>>> > >>>>>> I see this as simply yes, and no different than what has been > done > >>>> more > >>>>>> recently with Ethernet or, even if we do continue to model OTN > as > >> a > >>>>>> single layer, no different than PSC-1 -> PSC-4. > >>>>>> > >>>>>> There's also a minor processing efficiency gained by this > approach > >>>> for > >>>>>> nodes that support a smaller set of ODUks than are advertised > >> within > >>>> an > >>>>>> IGP. > >>>>>> > >>>>>> Based on all this, I believe different ODUk's should use > different > >>>>>> Switching Types. In particular, I'm proposing: > >>>>>> (1) that either the framework or info documents identify that > >>>>>> a per-OTUk Switching Capability Types will be used to > support > >>>>>> G.709v3. > >>>>>> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different > >>>>>> Switching Cap field value for each ODUk, and that it state > >>>>>> that the value corresponding to the signal type identified > in > >>>>>> the #stages=3D0 of the ISCP be set. (Without any other > changes > >>>>>> to the current definition of ISCD.) > >>>>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to > >>>>>> match above. > >>>>>> > >>>>>> To keep thinks generic, we probably should use TDM-1 through > TDM-n > >>>> as > >>>>>> the new Switching Capability Types, but this is a secondary > >>>> discussion. > >>>>>> > >>>>>> Comments? > >>>>>> > >>>>>> Lou > >>>>>> > >>>>>> PS While the above is an important change, it doesn't > >> significantly > >>>>>> impact encoding and won't take much text to make the actual > >> change, > >>>> so > >>>>>> this is a discussion that can continue until Paris if we really > >> need > >>>> a > >>>>>> face to face to resolve the discussion. > >>>>>> > >>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: > >>>>>>> Hi CCAMP, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> During the OTN OSPF draft presentation at the IETF meeting in > >>>> Taipei > >>>>>> two > >>>>>>> comments were raised with respect to the following issues: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> - Issue 1: Using different switching caps for each ODU type > >>>>>>> > >>>>>>> - Issue 2: Type 2 (unres bandwidth for variable containers) and > >>>> Type > >>>>>> 3 > >>>>>>> (MAX LSP bandwidth foe variable containers always used in > tandem? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk > of > >>>> the > >>>>>>> muxing hiearachy in the Switching Capability field of the ISCD. > >>>> After > >>>>>> a > >>>>>>> quick talk with the other authors of the ID, the idea was to > >> reject > >>>>>> the > >>>>>>> proposal as it would lead to an overloading of the meaning of > the > >>>>>>> Switching Capability field. (even if the definition of PSC1-2- > 3-4 > >>>>>>> already overloads the meaning of the switching capability > field) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft > (version > >> - > >>>>>> 00). > >>>>>>> I'm copying it below for your convenience > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In this example the advertisement of an ODUflex->ODU3 > >> hierarchy > >>>> is > >>>>>>> > >>>>>>> shown. In case of ODUflex advertisement the MAX LSP > bandwidth > >>>>>> needs > >>>>>>> > >>>>>>> to be advertised but in some cases also information about > the > >>>>>>> > >>>>>>> Unreserved bandwidth could be useful. The amount of > >> Unreserved > >>>>>>> > >>>>>>> bandwidth does not give a clear indication of how many > ODUflex > >>>> LSP > >>>>>>> > >>>>>>> can be set up either at the MAX LSP Bandwidth or at > different > >>>>>> rates, > >>>>>>> > >>>>>>> as it gives no information about the spatial allocation of > the > >>>>>> free > >>>>>>> > >>>>>>> TSs. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> An indication of the amount of Unreserved bandwidth could be > >>>>>> useful > >>>>>>> > >>>>>>> during the path computation process, as shown in the > following > >>>>>>> > >>>>>>> example. Supposing there are two TE-links (A and B) with > MAX > >>>> LSP > >>>>>>> > >>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of > Unreserved > >>>>>>> > >>>>>>> Bandwidth are available on Link A, 10Gbps on Link B and 3 > >>>> ODUflex > >>>>>>> > >>>>>>> LSPs of 10 GBps each, have to be restored, for sure only one > >> can > >>>>>> be > >>>>>>> > >>>>>>> restored along Link B and it is probable (but not sure) that > >> two > >>>>>> of > >>>>>>> > >>>>>>> them can be restored along Link A. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Early proposal was to have, in the case of variable containers > >>>>>>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type > 3) > >>>> as > >>>>>> a > >>>>>>> mandatory piece of information and the Unreserved bandiwdth TLV > >>>> (Type > >>>>>> 2) > >>>>>>> as an optional piece of information. > >>>>>>> > >>>>>>> The comment received is that optional information can lead to > >>>>>>> interworking issues and the counter proposal was to have both > >>>> pieces > >>>>>> of > >>>>>>> information as mandatory and, as a consequence, merge the two > >> TLVs > >>>>>> into > >>>>>>> a single one. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> We'd like to hear the opinion of the WG on both issues before > >>>>>> proceeding > >>>>>>> with any modification to the document. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Daniele > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *DANIELE CECCARELLI * > >>>>>>> *System & Technology - DU IP & Broadband* > >>>>>>> > >>>>>>> > >>>>>>> Via L.Calda, 5 > >>>>>>> Genova, Italy > >>>>>>> Phone +390106002512 > >>>>>>> Mobile +393346725750 > >>>>>>> daniele.ceccarelli@ericsson.com > >>>>>>> www.ericsson.com > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> This Communication is Confidential. We only send and receive > >> email > >>>> on > >>>>>>> the basis of the term set out at > >> www.ericsson.com/email_disclaimer > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> CCAMP mailing list > >>>>>>> CCAMP@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>> _______________________________________________ > >>>>>> CCAMP mailing list > >>>>>> CCAMP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >>> > > > > > > > > From lberger@labn.net Wed Nov 30 14:54:10 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB69921F8B4C for ; Wed, 30 Nov 2011 14:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isVkJW-Pvzl2 for ; Wed, 30 Nov 2011 14:54:09 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 823DB21F8B49 for ; Wed, 30 Nov 2011 14:54:09 -0800 (PST) Received: (qmail 14228 invoked by uid 0); 30 Nov 2011 22:53:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 30 Nov 2011 22:53:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=q6j1FPmWOy8AdO04tGGKYzho2YpzSecUaTInXMJ6xvQ=; b=CU1U/YVFmfebNIbWgGQAC6rjlwz+QeYB6Bc5FSTrP7eYbwr9N1xuexyHQ2255+AI2DWUHv6piMglU4tdfXt2dduDHR33NvvaN0ohMc0hPJbTMFdengqns0M/wDk9/NRe; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RVt2B-0007m0-So; Wed, 30 Nov 2011 15:53:48 -0700 Message-ID: <4ED6B3FF.4000907@labn.net> Date: Wed, 30 Nov 2011 17:53:51 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: John E Drake References: <4ED64A32.8060707@labn.net> <5E893DB832F57341992548CDBB333163A4B54CA99D@EMBX01-HQ.jnpr.net> <4ED65D2D.2040400@labn.net> <5E893DB832F57341992548CDBB333163A4B54CADAB@EMBX01-HQ.jnpr.net> <4ED69B7D.409@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAEE5@EMBX01-HQ.jnpr.net> <4ED6A555.1000706@labn.net> <5E893DB832F57341992548CDBB333163A4B54CAFA4@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A4B54CAFA4@EMBX01-HQ.jnpr.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:54:10 -0000 Okay, it's good to understand each other. Referring back to my earlier mail: > ... Switching Capability Types represent (a) different > switching/technology layers and (b) different levels of hierarchy -- > even within a layer. I think (a) is identifiable in the definition of > the original GMPLS supported technologies (i.e., PSC, L2SC, TDM LSC, > and FSC), and (b) is identifiable in the original types plus the > definition of PSC-1 through PSC-4. And you're proposing invalidating usage (b). My proposal is based on (b) being valid. (I was, of course, operating on the premise of today's current RFCs ;-) I agree that if usage (b) is invalidated, my proposal makes no sense. I'm a bit ambivalent on invalidating usage (b). On one hand, I like the simplicity implied by the change (and of saying the SC is just is an indicator of label type and ISCD format). On the other hand, I've always found some, albeit not significant, processing value in constructing SC/layer specific topologies (and even policies.) -- I also need some time to digest this proposal in the context of MLN/MRN. Clearly invalidating (b) and deprecating PSC-2->n, is a notable change to GMPLS and one that we will need to be discussed agreed to in both CCAMP and PCE. Although, if your assertion on how most use PSC and SC holds, it shouldn't be too contentious a discussion. Are you willing to put together a draft with your proposed changes to Switching Capability Types so that we can codify consensus on the topic? Lou On 11/30/2011 5:23 PM, John E Drake wrote: > Yes, I think that's fair. > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, November 30, 2011 1:51 PM >> To: John E Drake >> Cc: Daniele Ceccarelli; CCAMP >> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue 1/2) >> >> So you're basically arguing that SC shouldn't be used to indicate >> different levels of hierarchy, i.e., usage (b) in my earlier message, >> and that the definition of PSC-1 -> n was flawed. Right? >> >> Which then reduces the meaning of SC to simply and indicator of label >> type and ISCD format indicator. >> >> Is this your position? >> >> Lou >> >> On 11/30/2011 4:37 PM, John E Drake wrote: >>> Comments inline. I still think this is a terrible idea and I would >> like to see what the rest of the WG thinks. >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Wednesday, November 30, 2011 1:09 PM >>>> To: John E Drake >>>> Cc: Daniele Ceccarelli; CCAMP >>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue >> 1/2) >>>> >>>> >>>> John, >>>> >>>> see below >>>> >>>> >>>> On 11/30/2011 2:59 PM, John E Drake wrote: >>>>> Using Switching Capability to indicate link bandwidth seems >>>>> ill-considered at best, especially since this information is >> carried >>>>> in other fields, and as Daniele noted, it significantly overloads >> to >>>>> intended meaning of Switching Capability. >>>> >>>> I agree with the point on BW, but my point was related to the >>>> layer&hierarchy implications of the different ODUk values. I'd >> think >>>> that using values that are TDM-1 -> TDM-n should make this clear and >>>> remove any ambiguity related to bandwidth. It is also completely >>>> consistent with the base GMPLS definition, i.e., PSC-1 -> PSC-n. >>> >>> [JD] You are simply asserting that this is a good idea and further >> asserting that there is "ambiguity related to bandwidth', without >> providing any evidence. >>> >>> To the best of my knowledge no one ever implemented or deployed the >> PSC-1 -> PSC-4 hierarchy, simply because no one could figure out what >> it meant. To quote from you, below, "Well hopefully we have a better >> understanding of the technologies involved than we had in the past.". >> I.e., we should all understand that PSC-1 -> PSC-4 was a bad idea (tm) >> and move on. >>> >>>> >>>>> It also is inconsistent >>>>> with the usage of Switching Capability in SDH/SONET. >>>> >>>> Well hopefully we have a better understanding of the technologies >>>> involved than we had in the past. >>> >>> [JD] I think we had a very good understanding of SDH/SONET then and >> we have a very good understanding of OTN now, and in both cases the >> authors saw no requirement to overload switching capability in the >> manner you are suggesting. >>> >>>> >>>>> >>>>> A more extensive quote from RFC4202 is the following, which seems >>>>> clear enough to me: >>>>> >>>>> "In the context of this document we say that a link is connected to >> a >>>>> node by an interface. In the context of GMPLS interfaces may have >>>>> different switching capabilities. For example an interface that >>>>> connects a given link to a node may not be able to switch >> individual >>>>> packets, but it may be able to switch channels within an SDH >> payload. >>>>> Interfaces at each end of a link need not have the same switching >>>>> capabilities. Interfaces on the same node need not have the same >>>>> switching capabilities." >>>> >>>> Not sure how this helps clarify anything... >>> >>> [JD] I think it clarifies that switching capabilities is meant to >> describe how a given interface switches the information with which it >> is provided. This has nothing to do with the interface's bandwidth. >>> >>>> >>>> Lou >>>>> >>>>>> -----Original Message----- >>>>>> From: Lou Berger [mailto:lberger@labn.net] >>>>>> Sent: Wednesday, November 30, 2011 8:43 AM >>>>>> To: John E Drake >>>>>> Cc: Daniele Ceccarelli; CCAMP >>>>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue >>>> 1/2) >>>>>> >>>>>> Great. Care to substantiate your point? >>>>>> >>>>>> On 11/30/2011 11:14 AM, John E Drake wrote: >>>>>>> I completely disagree. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>>> Behalf >>>>>>>> Of Lou Berger >>>>>>>> Sent: Wednesday, November 30, 2011 7:22 AM >>>>>>>> To: Daniele Ceccarelli >>>>>>>> Cc: CCAMP >>>>>>>> Subject: Re: [CCAMP] OSPF OTN considerations post IETF 82 (Issue >>>>>> 1/2) >>>>>>>> >>>>>>>> Hi Daniele, >>>>>>>> Since I raised the point, I guess I need to champion it! >> (With >>>>>>>> chair >>>>>>>> hat off.) >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> Daniele said: >>>>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk >> of >>>>>> the >>>>>>>>> muxing hiearachy in the Switching Capability field of the ISCD. >>>>>> After >>>>>>>>> a quick talk with the other authors of the ID, the idea was to >>>>>> reject >>>>>>>>> the proposal as it would lead to an overloading of the meaning >> of >>>>>> the >>>>>>>>> Switching Capability field. (even if the definition of PSC1-2- >> 3-4 >>>>>>>>> already overloads the meaning of the switching capability >> field) >>>>>>>> >>>>>>>> This really goes to the interpretation of the intent of >> Switching >>>>>>>> Capability Types. So we have a few definitions: 3471 says "the >>>> type >>>>>> of >>>>>>>> switching that should be performed", 4202 says "describes >>>> switching >>>>>>>> capability of an interface." 3945 doesn't really define the term >>>> (it >>>>>>>> just references 4202), but does equate it with a "layer". While >> it >>>>>>>> allows for hierarchy within a "layer" it also says hierarchy >>>> occurs >>>>>>>> "between interface types". >>>>>>>> >>>>>>>> So I interpret Switching Capability Types to represent (a) >>>> different >>>>>>>> switching/technology layers and (b) different levels of >> hierarchy >>>> -- >>>>>>>> even within a layer. I think (a) is identifiable in the >>>> definition >>>>>> of >>>>>>>> the original GMPLS supported technologies (i.e., PSC, L2SC, TDM >>>> LSC, >>>>>>>> and >>>>>>>> FSC), and (b) is identifiable in the original types plus the >>>>>> definition >>>>>>>> of PSC-1 through PSC-4. >>>>>>>> >>>>>>>> So how does this apply to our current OTN work? >>>>>>>> >>>>>>>> To me, the first question to ask relates to (a), and is should >>>> each >>>>>>>> ODUk >>>>>>>> be modeled as a separate layer? >>>>>>>> >>>>>>>> I know this has been a much debated point, and it seems to me >> that >>>>>> they >>>>>>>> are, but more for the perspective of switching layers than >>>>>> technology >>>>>>>> layers (i.e., they are clearly the same technology but are >>>> different >>>>>>>> granularity of swicthing.) So this is a yes for me. >>>>>>>> >>>>>>>> I think the second question to ask relates to (b), and is does >>>> each >>>>>>>> ODUk >>>>>>>> represent a different level of hierarchy? >>>>>>>> >>>>>>>> I see this as simply yes, and no different than what has been >> done >>>>>> more >>>>>>>> recently with Ethernet or, even if we do continue to model OTN >> as >>>> a >>>>>>>> single layer, no different than PSC-1 -> PSC-4. >>>>>>>> >>>>>>>> There's also a minor processing efficiency gained by this >> approach >>>>>> for >>>>>>>> nodes that support a smaller set of ODUks than are advertised >>>> within >>>>>> an >>>>>>>> IGP. >>>>>>>> >>>>>>>> Based on all this, I believe different ODUk's should use >> different >>>>>>>> Switching Types. In particular, I'm proposing: >>>>>>>> (1) that either the framework or info documents identify that >>>>>>>> a per-OTUk Switching Capability Types will be used to >> support >>>>>>>> G.709v3. >>>>>>>> (2) that draft-ietf-ccamp-gmpls-ospf-g709v3 define a different >>>>>>>> Switching Cap field value for each ODUk, and that it state >>>>>>>> that the value corresponding to the signal type identified >> in >>>>>>>> the #stages=0 of the ISCP be set. (Without any other >> changes >>>>>>>> to the current definition of ISCD.) >>>>>>>> (3) that draft-ietf-ccamp-gmpls-signaling-g709v3 be updated to >>>>>>>> match above. >>>>>>>> >>>>>>>> To keep thinks generic, we probably should use TDM-1 through >> TDM-n >>>>>> as >>>>>>>> the new Switching Capability Types, but this is a secondary >>>>>> discussion. >>>>>>>> >>>>>>>> Comments? >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> PS While the above is an important change, it doesn't >>>> significantly >>>>>>>> impact encoding and won't take much text to make the actual >>>> change, >>>>>> so >>>>>>>> this is a discussion that can continue until Paris if we really >>>> need >>>>>> a >>>>>>>> face to face to resolve the discussion. >>>>>>>> >>>>>>>> On 11/23/2011 1:18 PM, Daniele Ceccarelli wrote: >>>>>>>>> Hi CCAMP, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> During the OTN OSPF draft presentation at the IETF meeting in >>>>>> Taipei >>>>>>>> two >>>>>>>>> comments were raised with respect to the following issues: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - Issue 1: Using different switching caps for each ODU type >>>>>>>>> >>>>>>>>> - Issue 2: Type 2 (unres bandwidth for variable containers) and >>>>>> Type >>>>>>>> 3 >>>>>>>>> (MAX LSP bandwidth foe variable containers always used in >> tandem? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> WRT issue 1: the proposal was to indicate the bottom most ODUk >> of >>>>>> the >>>>>>>>> muxing hiearachy in the Switching Capability field of the ISCD. >>>>>> After >>>>>>>> a >>>>>>>>> quick talk with the other authors of the ID, the idea was to >>>> reject >>>>>>>> the >>>>>>>>> proposal as it would lead to an overloading of the meaning of >> the >>>>>>>>> Switching Capability field. (even if the definition of PSC1-2- >> 3-4 >>>>>>>>> already overloads the meaning of the switching capability >> field) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> WRT issue 2: it is analyzed in section 5.3 of the draft >> (version >>>> - >>>>>>>> 00). >>>>>>>>> I'm copying it below for your convenience >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> In this example the advertisement of an ODUflex->ODU3 >>>> hierarchy >>>>>> is >>>>>>>>> >>>>>>>>> shown. In case of ODUflex advertisement the MAX LSP >> bandwidth >>>>>>>> needs >>>>>>>>> >>>>>>>>> to be advertised but in some cases also information about >> the >>>>>>>>> >>>>>>>>> Unreserved bandwidth could be useful. The amount of >>>> Unreserved >>>>>>>>> >>>>>>>>> bandwidth does not give a clear indication of how many >> ODUflex >>>>>> LSP >>>>>>>>> >>>>>>>>> can be set up either at the MAX LSP Bandwidth or at >> different >>>>>>>> rates, >>>>>>>>> >>>>>>>>> as it gives no information about the spatial allocation of >> the >>>>>>>> free >>>>>>>>> >>>>>>>>> TSs. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> An indication of the amount of Unreserved bandwidth could be >>>>>>>> useful >>>>>>>>> >>>>>>>>> during the path computation process, as shown in the >> following >>>>>>>>> >>>>>>>>> example. Supposing there are two TE-links (A and B) with >> MAX >>>>>> LSP >>>>>>>>> >>>>>>>>> Bandwidth equal to 10 Gbps each. In case 50Gbps of >> Unreserved >>>>>>>>> >>>>>>>>> Bandwidth are available on Link A, 10Gbps on Link B and 3 >>>>>> ODUflex >>>>>>>>> >>>>>>>>> LSPs of 10 GBps each, have to be restored, for sure only one >>>> can >>>>>>>> be >>>>>>>>> >>>>>>>>> restored along Link B and it is probable (but not sure) that >>>> two >>>>>>>> of >>>>>>>>> >>>>>>>>> them can be restored along Link A. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Early proposal was to have, in the case of variable containers >>>>>>>>> advertisements (i.e. ODUflex), the MAX LSP bandwidth TLV (Type >> 3) >>>>>> as >>>>>>>> a >>>>>>>>> mandatory piece of information and the Unreserved bandiwdth TLV >>>>>> (Type >>>>>>>> 2) >>>>>>>>> as an optional piece of information. >>>>>>>>> >>>>>>>>> The comment received is that optional information can lead to >>>>>>>>> interworking issues and the counter proposal was to have both >>>>>> pieces >>>>>>>> of >>>>>>>>> information as mandatory and, as a consequence, merge the two >>>> TLVs >>>>>>>> into >>>>>>>>> a single one. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> We'd like to hear the opinion of the WG on both issues before >>>>>>>> proceeding >>>>>>>>> with any modification to the document. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Daniele >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *DANIELE CECCARELLI * >>>>>>>>> *System & Technology - DU IP & Broadband* >>>>>>>>> >>>>>>>>> >>>>>>>>> Via L.Calda, 5 >>>>>>>>> Genova, Italy >>>>>>>>> Phone +390106002512 >>>>>>>>> Mobile +393346725750 >>>>>>>>> daniele.ceccarelli@ericsson.com >>>>>>>>> www.ericsson.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This Communication is Confidential. We only send and receive >>>> email >>>>>> on >>>>>>>>> the basis of the term set out at >>>> www.ericsson.com/email_disclaimer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> CCAMP mailing list >>>>>>>>> CCAMP@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > > > From gregory.mirsky@ericsson.com Wed Nov 30 17:17:47 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AAB21F8B39 for ; Wed, 30 Nov 2011 17:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCilvnfz7qkr for ; Wed, 30 Nov 2011 17:17:46 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2221F8B36 for ; Wed, 30 Nov 2011 17:17:46 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pB11HM7Z024194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Nov 2011 19:17:22 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 30 Nov 2011 20:17:21 -0500 From: Gregory Mirsky To: Attila Takacs , "donald.fedyk@alcatel-lucent.com" , "hejia@huawei.com" , "ccamp@ietf.org" Date: Wed, 30 Nov 2011 20:17:20 -0500 Thread-Topic: Comments to draft-ietf-ccamp-oam-configuration-fwk Thread-Index: Acyvxvj5Qp/kavLxQ3y6Nqi5MQWefA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF132293B45F0EUSAACMS0715e_" MIME-Version: 1.0 Subject: [CCAMP] Comments to draft-ietf-ccamp-oam-configuration-fwk X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 01:17:47 -0000 --_000_FE60A4E52763E84B935532D7D9294FF132293B45F0EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., Please find my comments to the document below. Your kind consideration is a= ppreciated. * General comment - combining OAM for SONET/SDH, Ethernet, and MPLS(= -TP) creates terminology problem. Perhaps a section can be added to map ITU= , IEEE, and IETF terms and set some common understanding for Maintenance-Fo= o terms. * Section 3 "MEPs reside at the ends of an LSP ..." It is not the ca= se for SONET/SDH and Ethernet. AFAIK, it is only the case for MPLS-TP. Perh= aps the following wording would be accurate without going into too much spe= cifics: "MEPs define scope of actively managed and monitored element of mai= ntenance ..." * Section 3 "Maintenance Entity (ME) refers to an association of MEP= s and MIPs that are provisioned to monitor an LSP." Association MEPs and MI= Ps are not always referred as ME. In CFM MPs on the same ME Level referred = as Maintenance Association. Maintenance Entity, in CFM, is p2p relationship= between MA. Even more, CFM MPs configured on all MD levels represent Maint= enance Domain. * Section 3.1 "When the Path message arrives at the receiver, the rem= ote end MUST establish and configure OAM entities according to the OAM info= rmation provided in the Path message". I'm concerned that "the remote end" = implies far end LER and thus process excludes configuration of MIPs, enclos= ed MD Levels and MEPs and MIPS per MD Level. I'd suggest to remove "the rem= ote end" replacing it with less specific "it" "When the Path message arrive= s at the receiver, it MUST ..." * Section 4.1, fourth para "This bit (OAM MIP entities desired) can o= nly be set if the "OAM MEP entities desired" bit is set in." I believe that= this is too restrictive as a MIP might be added on after an LSP and MEPs b= een configured. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF132293B45F0EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
Please find my comments to the document below. Your kind consideration= is appreciated.
 
  • General comment - combining OAM for SONET/SDH, Ethernet, and MPLS(-TP)= creates terminology problem. Perhaps a section can be added to map ITU, IE= EE, and IETF terms and set some common understanding for Maintenance-Foo te= rms.
  • Section 3 "MEPs reside at the ends of an LSP ..." I= t is not the case for SONET/SDH and Ethernet. AFAIK, it is only the case fo= r MPLS-TP. Perhaps the following wording would be accurate without going in= to too much specifics: "MEPs define scope of actively managed and monitored element of maintenance ..."
  • Section 3 &= quot;Maintenance Entity (ME) refers to an association of MEPs and MIPs that= are provisioned to monitor an LSP." Association MEPs and MIPs are not= always referred as ME. In CFM MPs on the same ME Level referred as Mainten= ance Association. Maintenance Entity, in CFM, is p2p relationship between MA. Even more, CFM MPs configur= ed on all MD levels represent Maintenance Domain.
  • Section 3.1 "= ;When the Path message arrives at the receiver, the remote end MUST establi= sh and configure OAM entities according to the OAM information provided in = the Path message". I'm concerned that "the remote end" impli= es far end LER and thus process excludes configuration of MIPs, enclosed MD Levels and MEPs and MIPS per MD= Level. I'd suggest to remove "the remote end" replacing it with = less specific "it" "When the Path message arrives at the rec= eiver, it MUST ..."
  • Section 4.1, fourth para "This bit (O= AM MIP entities desired) can only be set if the "OAM MEP entities desi= red" bit is set in." I believe that this is too restrictive as a = MIP might be added on after an LSP and MEPs been configured.
 
Regards,
 
Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF132293B45F0EUSAACMS0715e_--