From lberger@labn.net Thu Feb 2 06:29:48 2012 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 A6C4C21F84DD for ; Thu, 2 Feb 2012 06:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.286 X-Spam-Level: X-Spam-Status: No, score=-98.286 tagged_above=-999 required=5 tests=[AWL=1.875, 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 AJqhRXQkfGCp for ; Thu, 2 Feb 2012 06:29:48 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 761C521F8467 for ; Thu, 2 Feb 2012 06:29:47 -0800 (PST) Received: (qmail 9913 invoked by uid 0); 2 Feb 2012 14:29:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 2 Feb 2012 14:29:46 -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=5UX/Cv7MmdnxnWquK+R73/VcG1vBMgykOWbOg3zO1rI=; b=cuSPlojM7Grlz0e+ofyvfUG+oUNtt76IBLzGofT/cGAJlPwjQl0IeACCpLDw/O+FDmY2nz94sMaQUnTOwNO4+dkM9peMH339SXZVNqIeXwDS/8PRKQo57/aqHKdnSOla; 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 1RsxfW-0001BL-D7; Thu, 02 Feb 2012 07:29:46 -0700 Message-ID: <4F2A9DDB.3040700@labn.net> Date: Thu, 02 Feb 2012 09:29: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: zhang.fei3@zte.com.cn 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@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 02 Feb 2012 14:29:48 -0000 Fei, see below for responses in-line. On 1/29/2012 4:49 AM, zhang.fei3@zte.com.cn wrote: > > Hi CCAMPers > > As discussed in the last IETF meeting and mailinglist, the Global_ID > should be carried in the signaling messages. One reason is that the > judgement of a mis-connectivity defect needs the A1/Z9 nodes to > pre-store each other's MEP_ID, whose format is: > Gobal_ID+Node_ID+Tunnel_num+LSP_num. > > Fortunately, there are several drafts related to this topic now, > > 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. > > The Globa_ID is incorporated into the ASSOCIATION object in the current > version, which guarantees that the association is global unique. Since > the ASSOCIATION object is used across different LSPs, just my2cents, the > defined format is deficient to handle more scenarios. For example: > > (1) Considering a corouted bidirectional LSP, which is not protected > by other LSPs through control plane and/or does not share the same > resoures with other LSPs. > In these cases, the ASSOCIATION object will > not be carried in the sigaling messages. Why not? One of the purposes of this draft is to support non-recovery uses of the association object. Note the name of section 2. > > (2) Considering an associated bidirectional LSP, although the > ASSOCIATION object is carried in the sigaling messages, the global_ID > incorporated in the ASSOCIATION object only > indicates the global prefix of the A1 or Z9 nodes. If this LSP is across > different domains, I think the current format is also deficient (A1 does > not know the gobal ID of Z9 node or Z9 nodes does not know the global ID > of A1 ). It's not clear to me what problem you're trying to solve. Can you rephrase? Also keep in mind that multiple association objects have always been supported and this ability is not modified by the draft. > > 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 > > The Global_ID Object and the ICC_Operator_ID Object are defined in this > draft, which describes the procedure of corouted bidirectional LSP > (associated bidirectional LSP is not covered in the current version) and > requires that the same format( Global_ID or ICC_Operator_ID)is used > along the LSP. Yes. This was discussed at the last IETF. The WG previously had a solution to this based on the association object, see rev 00 of the WG document. I removed it from the document based on discussion in Quebec. As discussed in Taipei the current rev can still be used to carry the ITU-T identifiers (yes, the parts that were in -00 need to be separately published to document this.) > > 3. > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 > > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which > will appear in the Path/Resv message of corouted bidrectional LSP and > only appear in the Path message of associated bidirectional LSP. > Furthermore, this draft defined a Connection TLV used to carry the local > tunnel number assigned at Z9 nodes in the scenario of corouted > bidirectional LSP. Is there a question here? Lou (as contributor) > > > The above materials only provide the rough background. > > > Hope to hear the opinions from the WG that how to carry the Global_ID, > then move the work forward. > > > Best regards > > ;) > > Fei > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From zhang.fei3@zte.com.cn Thu Feb 2 17:37:54 2012 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 E9C9D21F85BB for ; Thu, 2 Feb 2012 17:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.875 X-Spam-Level: X-Spam-Status: No, score=-97.875 tagged_above=-999 required=5 tests=[AWL=-1.998, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 LaWkD-5TrGb8 for ; Thu, 2 Feb 2012 17:37:54 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2E25211E8071 for ; Thu, 2 Feb 2012 17:37:53 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Fri, 3 Feb 2012 09:11:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.984958751; Fri, 3 Feb 2012 09:37:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q131bYtJ083068; Fri, 3 Feb 2012 09:37:34 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4F2A9DDB.3040700@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: 687803D2:1CA4F5BB-48257999:00043E59; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 3 Feb 2012 09:37:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-03 09:37:34, Serialize complete at 2012-02-03 09:37:34 Content-Type: multipart/alternative; boundary="=_alternative 0008EA7948257999_=" X-MAIL: mse01.zte.com.cn q131bYtJ083068 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 03 Feb 2012 01:37:55 -0000 This is a multipart message in MIME format. --=_alternative 0008EA7948257999_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZSwgcGxlYXNlIHNlZSB0aGUgcmVwb25zZXMg aW4tbGluZSB3aXRoIDxmZWk+PC9mZWk+IA0KdG8gY2hlY2sgd2hldGhlciBJIG1ha2UgYSBtaXN0 YWtlLg0KDQpCZXN0IHJlZ2FyZHMgDQoNCkZlaQ0KDQoNCg0KTG91IEJlcmdlciA8bGJlcmdlckBs YWJuLm5ldD4gDQoyMDEyLTAyLTAyIDIyOjI5DQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29t LmNuDQqzrcvNDQoiY2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCtb3zOINClJlOiBb Q0NBTVBdIERpc2N1c3Npb24gb24gaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQNCg0KDQoNCg0K DQoNCkZlaSwNCiAgICAgICAgICAgICAgICAgc2VlIGJlbG93IGZvciByZXNwb25zZXMgaW4tbGlu ZS4NCg0KT24gMS8yOS8yMDEyIDQ6NDkgQU0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3cm90ZToN Cj4gDQo+IEhpIENDQU1QZXJzDQo+IA0KPiBBcyBkaXNjdXNzZWQgaW4gdGhlIGxhc3QgSUVURiBt ZWV0aW5nIGFuZCBtYWlsaW5nbGlzdCwgdGhlIEdsb2JhbF9JRA0KPiBzaG91bGQgYmUgY2Fycmll ZCBpbiB0aGUgc2lnbmFsaW5nIG1lc3NhZ2VzLiBPbmUgcmVhc29uIGlzIHRoYXQgdGhlDQo+IGp1 ZGdlbWVudCBvZiBhIG1pcy1jb25uZWN0aXZpdHkgZGVmZWN0IG5lZWRzIHRoZSBBMS9aOSBub2Rl cyB0bw0KPiBwcmUtc3RvcmUgZWFjaCBvdGhlcidzIE1FUF9JRCwgd2hvc2UgZm9ybWF0IGlzOg0K PiBHb2JhbF9JRCtOb2RlX0lEK1R1bm5lbF9udW0rTFNQX251bS4NCj4gDQo+IEZvcnR1bmF0ZWx5 LCB0aGVyZSBhcmUgc2V2ZXJhbCBkcmFmdHMgcmVsYXRlZCB0byB0aGlzIHRvcGljIG5vdywNCj4g DQo+IDEuICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWFzc29j LWV4dC0wMS4NCj4gDQo+IFRoZSBHbG9iYV9JRCBpcyBpbmNvcnBvcmF0ZWQgaW50byB0aGUgQVNT T0NJQVRJT04gb2JqZWN0IGluIHRoZSBjdXJyZW50DQo+IHZlcnNpb24sIHdoaWNoIGd1YXJhbnRl ZXMgdGhhdCB0aGUgYXNzb2NpYXRpb24gaXMgZ2xvYmFsIHVuaXF1ZS4gU2luY2UNCj4gdGhlIEFT U09DSUFUSU9OIG9iamVjdCBpcyB1c2VkIGFjcm9zcyBkaWZmZXJlbnQgTFNQcywganVzdCBteTJj ZW50cywgdGhlDQo+IGRlZmluZWQgZm9ybWF0IGlzIGRlZmljaWVudCB0byBoYW5kbGUgbW9yZSBz Y2VuYXJpb3MuIEZvciBleGFtcGxlOg0KPiANCj4gICAgICgxKSBDb25zaWRlcmluZyBhIGNvcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB3aGljaCBpcyBub3QgcHJvdGVjdGVkDQo+IGJ5IG90aGVy IExTUHMgdGhyb3VnaCBjb250cm9sIHBsYW5lIGFuZC9vciBkb2VzIG5vdCBzaGFyZSB0aGUgc2Ft ZQ0KPiByZXNvdXJlcyB3aXRoIG90aGVyIExTUHMuIA0KDQoNCj4gSW4gdGhlc2UgY2FzZXMsIHRo ZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2lsbA0KPiBub3QgYmUgY2FycmllZCBpbiB0aGUgc2lnYWxp bmcgbWVzc2FnZXMuDQoNCldoeSBub3Q/ICBPbmUgb2YgdGhlIHB1cnBvc2VzIG9mIHRoaXMgZHJh ZnQgaXMgdG8gc3VwcG9ydCBub24tcmVjb3ZlcnkNCnVzZXMgb2YgdGhlIGFzc29jaWF0aW9uIG9i amVjdC4gIE5vdGUgdGhlIG5hbWUgb2Ygc2VjdGlvbiAyLg0KDQo8RmVpPiANCg0KQWNjb3JkaW5n IHRvIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBhc3NvY2lhdGlvbiBvYmplY3QgaXMgdXNlZCB0bw0K YXNzb2NpYXRlIGRpZmZlcmVudCBMU1BzLiBTZWUgdGhlIGRlc2NyaXB0aW9ucyBpbiBzZWN0aW9u IDI6DQoiQXMgZGVzY3JpYmVkIGJlbG93LGFzc29jaWF0aW9uIGlzIGFsd2F5cyBkb25lIGJhc2Vk IG9uIG1hdGNoaW5nIA0KZWl0aGVyIFBhdGggc3RhdGUgdG8gUGF0aCBzdGF0ZSwgb3IgUmVzdiBz dGF0ZSB0byBSZXN2IHN0YXRlIiANCg0KQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBzY2VuYWlyb3M6 DQoNCiAgICAgICAgICAgICAgIExTUDENCkEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tWg0KDQpOb2RlIEEgaXMgbG9jYXRlZCBpbiBBUzEgYW5kIG5vZGUgWiBpcyBs b2NhdGVkIGluIEFTMiwgd2hlbiB0aGUgUGF0aA0KbWVzc2FnZSBmb3IgTFNQMSAoY28tcm91dGVk IGJpZGlyZWN0aW5hbCBMU1ApIHdpdGggRXh0ZW5kZWQgQXNzb2NpYXRpb24NCk9iamVjdCBpbnNl cnRlZCBpcyBpbml0aWF0ZWQgYXQgbm9kZSBBLCB0aHJlZSBpc3N1ZXM6DQoNCkkxOiB3aGF0IGtp bmQgb2YgYXNzb2NpYXRpb24gdHlwZSBpcyB1c2VkIGhlcmU/DQoNCkkyOiBhc3NvY2lhdGlvbiBv YmplY3QgaXMgdXNlZCBhY3Jvc3MgZGlmZmVyZW50IHBhdGggc3RhdGVzLCBidXQgTFNQMQ0KaXMg bm90IGFzc29jaWF0ZWQgd2l0aCBhbnkgb3RoZXIgTFNQUyBpbiB0aGlzIGNhc2UuDQoNCkkzOiBO b2RlIEEgc3RpbGwgZG9lcyBrbm93IHRoZSBnbG9iYWwgSUQgb2Ygbm9kZSBaDQoNCklmIHRoZXNl IGlzc3VlcyBhcmUgcmVhbGx5IGV4aXN0ZWQsIHRoZSBjdXJyZW50IHVzYWdlIG9mIGFzc29jaWF0 aW9uIA0Kb2JqZWN0DQpzaG91bGQgYmUgcmV2aXNlZCwgZm9yIGV4YW1wbGUsIGxpa2UgdGhpczoN Cg0KUjE6IEl0IGNhbiBiZSB1c2VkIG5vdCB0byBtYXRoIHBhdGggc3RhdGUsIGluIG90aGVyIHdv cmRzLCBpdCBjYW4gYXBwZWFyIA0Kb25seQ0KaW4gb25lIExTUCdzIHBhdGggbWVzc2FnZSAobm8g bmVlZCB0byBiZSBwYWlyKQ0KDQpSMjogSXQgY2FuIGJlIHVzZWQgYWNyb3NzIFBhdGggYW5kIFJF U1Ygc3RhdGUsIGluIHRoaXMgd2F5LCBhbiBhc3NvY2lhdGlvbiANCm9iamVjdA0KY2FuIGJlIGlu c2VydGVkIGF0IG5vZGUgWiBpbiB0aGUgUkVTViBtZXNzYWdlLCB3aXRoIHRoZSBnbG9iYWwgSUQg b2Ygbm9kZSANCloNCg0KUjM6IElmIGlzc3VlIDIgaXMgYWdyZWVlZCwgYSBuZXcgYXNzb2NpYXRp b24gdHlwZSBuZWVkcyB0byBiZSBkZWZpbmVkIA0KaGVyZT8NCg0KPC9GZWk+DQoNCiANCj4gDQo+ ICAgICAoMikgQ29uc2lkZXJpbmcgYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgYWx0 aG91Z2ggdGhlDQo+IEFTU09DSUFUSU9OIG9iamVjdCBpcyBjYXJyaWVkIGluIHRoZSBzaWdhbGlu ZyBtZXNzYWdlcywgdGhlIGdsb2JhbF9JRA0KPiBpbmNvcnBvcmF0ZWQgaW4gdGhlIEFTU09DSUFU SU9OIG9iamVjdCBvbmx5DQo+IGluZGljYXRlcyB0aGUgZ2xvYmFsIHByZWZpeCBvZiB0aGUgQTEg b3IgWjkgbm9kZXMuIElmIHRoaXMgTFNQIGlzIGFjcm9zcw0KPiBkaWZmZXJlbnQgZG9tYWlucywg SSB0aGluayB0aGUgY3VycmVudCBmb3JtYXQgaXMgYWxzbyBkZWZpY2llbnQgKEExIGRvZXMNCj4g bm90IGtub3cgdGhlIGdvYmFsIElEIG9mIFo5IG5vZGUgb3IgWjkgbm9kZXMgZG9lcyBub3Qga25v dyB0aGUgZ2xvYmFsIElEDQo+IG9mIEExICkuDQoNCkl0J3Mgbm90IGNsZWFyIHRvIG1lIHdoYXQg cHJvYmxlbSB5b3UncmUgdHJ5aW5nIHRvIHNvbHZlLiAgQ2FuIHlvdSANCnJlcGhyYXNlPw0KDQo8 ZmVpPg0KDQpTaW1pbGFybHkgd2l0aCB0aGUgaXNzdWUgMiBwcm92aWRlZCBhYm92ZSwgd2hlbiBM U1AxIGFuZCBMU1AyIGFyZSBib3VuZCANCnRvZ2V0aGVyDQp0byBiZSBhbiBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQLCB0aGUgZ2xvYmFsIElEIGNhcnJpZWQgaW4gdGhlIExTUDEncyANCmFu ZA0KTFNQMidzIFBhdGggbWVzc2FnZXMgYXJlIG5vZGUgQSdzIG9yIG5vZGUgWidzLCBpZiBpdCBp cyB0aGUgZ2xvYmFsIElEIG9mIA0Kbm9kZSBBLA0Kbm9kZSBBIHN0aWxsIGRvZXMga25vdyB0aGUg Z2xvYmFsIElEIG9mIG5vZGUgWi4NCg0KICAgICAgICAgICAgICAgTFNQMQ0KQS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1aDQogICAgICAgICAgICAgICBMU1AyIA0K SG9wZSBJIGNsYXJpZnkgaXQgY2xlYXJseS4gIDopDQoNCjwvZmVpPg0KDQoNCkFsc28ga2VlcCBp biBtaW5kIHRoYXQgbXVsdGlwbGUgYXNzb2NpYXRpb24gb2JqZWN0cyBoYXZlIGFsd2F5cyBiZWVu DQpzdXBwb3J0ZWQgYW5kIHRoaXMgYWJpbGl0eSBpcyBub3QgbW9kaWZpZWQgYnkgdGhlIGRyYWZ0 Lg0KDQo8ZmVpPiANCkkgYWdyZWUNCjwvZmVpPg0KDQo+IA0KPiAyLiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMtdHAtb2lvLTAxDQo+IA0KPiBUaGUgR2xv YmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19PcGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQg aW4gdGhpcw0KPiBkcmFmdCwgIHdoaWNoIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlIG9mIGNvcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQo+IChhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlz IG5vdCBjb3ZlcmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24pIGFuZA0KPiByZXF1aXJlcyB0aGF0 IHRoZSBzYW1lIGZvcm1hdCggR2xvYmFsX0lEIG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkDQo+ IGFsb25nIHRoZSBMU1AuDQoNClllcy4gIFRoaXMgd2FzIGRpc2N1c3NlZCBhdCB0aGUgbGFzdCBJ RVRGLiAgVGhlIFdHIHByZXZpb3VzbHkgaGFkIGENCnNvbHV0aW9uIHRvIHRoaXMgYmFzZWQgb24g dGhlIGFzc29jaWF0aW9uIG9iamVjdCwgc2VlIHJldiAwMCBvZiB0aGUgV0cNCmRvY3VtZW50LiAg SSByZW1vdmVkIGl0IGZyb20gdGhlIGRvY3VtZW50IGJhc2VkIG9uIGRpc2N1c3Npb24gaW4gUXVl YmVjLg0KIEFzIGRpc2N1c3NlZCBpbiBUYWlwZWkgdGhlIGN1cnJlbnQgcmV2IGNhbiBzdGlsbCBi ZSB1c2VkIHRvIGNhcnJ5IHRoZQ0KSVRVLVQgaWRlbnRpZmllcnMgKHllcywgdGhlIHBhcnRzIHRo YXQgd2VyZSBpbiAtMDAgbmVlZCB0byBiZSBzZXBhcmF0ZWx5DQpwdWJsaXNoZWQgdG8gZG9jdW1l bnQgdGhpcy4pDQoNCjxmZWk+DQpJIGFncmVlLCBubyBwcm9ibGVtIGhlcmUNCjwvZmVpPg0KDQo+ IA0KPiAzLg0KPiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1w LW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxDQoNCj4gDQo+IA0KPiBUaGUgR2xvYmFs X0lEIGlzIGNhcnJpZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGlj aA0KPiB3aWxsIGFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlk cmVjdGlvbmFsIExTUCBhbmQNCj4gb25seSBhcHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPiBGdXJ0aGVybW9yZSwgdGhpcyBkcmFmdCBk ZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUgbG9jYWwNCj4gdHVubmVs IG51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFyaW8gb2YgY29yb3V0ZWQN Cj4gYmlkaXJlY3Rpb25hbCBMU1AuDQoNCklzIHRoZXJlIGEgcXVlc3Rpb24gaGVyZT8NCg0KPGZl aT4NCg0KSWYgd2hhdCBJIGRlc2NyaWJlZCBpbiBwYXJ0IDEgaXMgcmVhc29uYWJsZSwgYW5kIHRo ZSB1c2FnZSBvZiBhc3NvY2lhdGlvbg0Kb2JqZWN0IGNhbiBiZSBtb2RpZmllZCB0byBjb3ZlciB0 aGVzZSBpc3N1ZXMsIHRoZXJlIGFyZSBubyBwcm9ibGVtIGhlcmUNCmFsc28uDQoNCjwvZmVpPg0K DQpMb3UgKGFzIGNvbnRyaWJ1dG9yKQ0KDQo+IA0KPiANCj4gVGhlIGFib3ZlIG1hdGVyaWFscyBv bmx5IHByb3ZpZGUgdGhlIHJvdWdoIGJhY2tncm91bmQuDQo+IA0KPiANCj4gSG9wZSB0byBoZWFy IHRoZSBvcGluaW9ucyBmcm9tIHRoZSBXRyB0aGF0IGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lE LA0KPiB0aGVuIG1vdmUgdGhlIHdvcmsgZm9yd2FyZC4NCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMN Cj4gDQo+IDspDQo+IA0KPiBGZWkNCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1Q QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAN Cg0KDQoNCg== --=_alternative 0008EA7948257999_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIHJlc3BvbnNl LCBwbGVhc2Ugc2VlDQp0aGUgcmVwb25zZXMgaW4tbGluZSB3aXRoICZsdDtmZWkmZ3Q7Jmx0Oy9m ZWkmZ3Q7IHRvIGNoZWNrIHdoZXRoZXIgSSBtYWtlDQphIG1pc3Rha2UuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IHJlZ2FyZHMgPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+TG91IEJlcmdlciAmbHQ7 bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMi0wMi0wMiAyMjoyOTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9y ZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbQ0NBTVBdIERpc2N1c3Npb24gb24gaG93IHRv IGNhcnJ5DQp0aGUgR2xvYmFsX0lEPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5GZWksPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnNlZSBiZWxvdyBmb3IgcmVzcG9uc2Vz IGluLWxpbmUuPGJyPg0KPGJyPg0KT24gMS8yOS8yMDEyIDQ6NDkgQU0sIHpoYW5nLmZlaTNAenRl LmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgQ0NBTVBlcnM8YnI+DQomZ3Q7 IDxicj4NCiZndDsgQXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IElFVEYgbWVldGluZyBhbmQgbWFp bGluZ2xpc3QsIHRoZSBHbG9iYWxfSUQ8YnI+DQomZ3Q7IHNob3VsZCBiZSBjYXJyaWVkIGluIHRo ZSBzaWduYWxpbmcgbWVzc2FnZXMuIE9uZSByZWFzb24gaXMgdGhhdCB0aGU8YnI+DQomZ3Q7IGp1 ZGdlbWVudCBvZiBhIG1pcy1jb25uZWN0aXZpdHkgZGVmZWN0IG5lZWRzIHRoZSBBMS9aOSBub2Rl cyB0bzxicj4NCiZndDsgcHJlLXN0b3JlIGVhY2ggb3RoZXIncyBNRVBfSUQsIHdob3NlIGZvcm1h dCBpczo8YnI+DQomZ3Q7IEdvYmFsX0lEK05vZGVfSUQrVHVubmVsX251bStMU1BfbnVtLjxicj4N CiZndDsgPGJyPg0KJmd0OyBGb3J0dW5hdGVseSwgdGhlcmUgYXJlIHNldmVyYWwgZHJhZnRzIHJl bGF0ZWQgdG8gdGhpcyB0b3BpYyBub3csPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuICZuYnNwO2h0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAxLjxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgVGhlIEdsb2JhX0lEIGlzIGluY29ycG9y YXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaW4gdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7 IHZlcnNpb24sIHdoaWNoIGd1YXJhbnRlZXMgdGhhdCB0aGUgYXNzb2NpYXRpb24gaXMgZ2xvYmFs IHVuaXF1ZS4gU2luY2U8YnI+DQomZ3Q7IHRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaXMgdXNlZCBh Y3Jvc3MgZGlmZmVyZW50IExTUHMsIGp1c3QgbXkyY2VudHMsDQp0aGU8YnI+DQomZ3Q7IGRlZmlu ZWQgZm9ybWF0IGlzIGRlZmljaWVudCB0byBoYW5kbGUgbW9yZSBzY2VuYXJpb3MuIEZvciBleGFt cGxlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICgxKSBDb25zaWRlcmluZyBh IGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB3aGljaA0KaXMgbm90IHByb3RlY3RlZDxicj4N CiZndDsgYnkgb3RoZXIgTFNQcyB0aHJvdWdoIGNvbnRyb2wgcGxhbmUgYW5kL29yIGRvZXMgbm90 IHNoYXJlIHRoZSBzYW1lPGJyPg0KJmd0OyByZXNvdXJlcyB3aXRoIG90aGVyIExTUHMuIDxicj4N Cjxicj4NCjxicj4NCiZndDsgSW4gdGhlc2UgY2FzZXMsIHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qg d2lsbDxicj4NCiZndDsgbm90IGJlIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLjxi cj4NCjxicj4NCldoeSBub3Q/ICZuYnNwO09uZSBvZiB0aGUgcHVycG9zZXMgb2YgdGhpcyBkcmFm dCBpcyB0byBzdXBwb3J0IG5vbi1yZWNvdmVyeTxicj4NCnVzZXMgb2YgdGhlIGFzc29jaWF0aW9u IG9iamVjdC4gJm5ic3A7Tm90ZSB0aGUgbmFtZSBvZiBzZWN0aW9uIDIuPGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7RmVpJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPkFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nLCB0aGUg YXNzb2NpYXRpb24gb2JqZWN0DQppcyB1c2VkIHRvPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5hc3NvY2lhdGUgZGlmZmVyZW50IExTUHMuIFNlZSB0aGUgZGVzY3JpcHRpb25zIGlu DQpzZWN0aW9uIDI6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtBcyBk ZXNjcmliZWQgYmVsb3csYXNzb2NpYXRpb24gaXMgYWx3YXlzIGRvbmUNCmJhc2VkIG9uIG1hdGNo aW5nIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ZWl0aGVyIFBhdGggc3RhdGUg dG8gUGF0aCBzdGF0ZSwgb3IgUmVzdiBzdGF0ZSB0bw0KUmVzdiBzdGF0ZSZxdW90OyA8L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg c2NlbmFpcm9zOjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0xTUDE8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tWjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Tm9kZSBBIGlzIGxvY2F0ZWQgaW4gQVMxIGFuZCBub2RlIFogaXMgbG9jYXRlZCBpbg0KQVMy LCB3aGVuIHRoZSBQYXRoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5tZXNzYWdl IGZvciBMU1AxIChjby1yb3V0ZWQgYmlkaXJlY3RpbmFsIExTUCkgd2l0aA0KRXh0ZW5kZWQgQXNz b2NpYXRpb248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPk9iamVjdCBpbnNlcnRl ZCBpcyBpbml0aWF0ZWQgYXQgbm9kZSBBLCB0aHJlZSBpc3N1ZXM6PC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JMTogd2hhdCBraW5kIG9mIGFzc29jaWF0aW9uIHR5cGUg aXMgdXNlZCBoZXJlPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+STI6 IGFzc29jaWF0aW9uIG9iamVjdCBpcyB1c2VkIGFjcm9zcyBkaWZmZXJlbnQgcGF0aA0Kc3RhdGVz LCBidXQgTFNQMTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+aXMgbm90IGFzc29j aWF0ZWQgd2l0aCBhbnkgb3RoZXIgTFNQUyBpbiB0aGlzIGNhc2UuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JMzogTm9kZSBBIHN0aWxsIGRvZXMga25vdyB0aGUgZ2xv YmFsIElEIG9mIG5vZGUgWjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ SWYgdGhlc2UgaXNzdWVzIGFyZSByZWFsbHkgZXhpc3RlZCwgdGhlIGN1cnJlbnQgdXNhZ2UNCm9m IGFzc29jaWF0aW9uIG9iamVjdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+c2hv dWxkIGJlIHJldmlzZWQsIGZvciBleGFtcGxlLCBsaWtlIHRoaXM6PC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5SMTogSXQgY2FuIGJlIHVzZWQgbm90IHRvIG1hdGggcGF0 aCBzdGF0ZSwgaW4gb3RoZXINCndvcmRzLCBpdCBjYW4gYXBwZWFyIG9ubHk8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPmluIG9uZSBMU1AncyBwYXRoIG1lc3NhZ2UgKG5vIG5lZWQg dG8gYmUgcGFpcik8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlIyOiBJ dCBjYW4gYmUgdXNlZCBhY3Jvc3MgUGF0aCBhbmQgUkVTViBzdGF0ZSwgaW4NCnRoaXMgd2F5LCBh biBhc3NvY2lhdGlvbiBvYmplY3Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmNh biBiZSBpbnNlcnRlZCBhdCBub2RlIFogaW4gdGhlIFJFU1YgbWVzc2FnZSwgd2l0aA0KdGhlIGds b2JhbCBJRCBvZiBub2RlIFo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PlIzOiBJZiBpc3N1ZSAyIGlzIGFncmVlZWQsIGEgbmV3IGFzc29jaWF0aW9uIHR5cGUNCm5lZWRz IHRvIGJlIGRlZmluZWQgaGVyZT88L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZsdDsvRmVpJmd0OzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgKDIpIENvbnNpZGVyaW5n IGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIGFsdGhvdWdoDQp0aGU8YnI+DQomZ3Q7 IEFTU09DSUFUSU9OIG9iamVjdCBpcyBjYXJyaWVkIGluIHRoZSBzaWdhbGluZyBtZXNzYWdlcywg dGhlIGdsb2JhbF9JRDxicj4NCiZndDsgaW5jb3Jwb3JhdGVkIGluIHRoZSBBU1NPQ0lBVElPTiBv YmplY3Qgb25seTxicj4NCiZndDsgaW5kaWNhdGVzIHRoZSBnbG9iYWwgcHJlZml4IG9mIHRoZSBB MSBvciBaOSBub2Rlcy4gSWYgdGhpcyBMU1AgaXMNCmFjcm9zczxicj4NCiZndDsgZGlmZmVyZW50 IGRvbWFpbnMsIEkgdGhpbmsgdGhlIGN1cnJlbnQgZm9ybWF0IGlzIGFsc28gZGVmaWNpZW50IChB MQ0KZG9lczxicj4NCiZndDsgbm90IGtub3cgdGhlIGdvYmFsIElEIG9mIFo5IG5vZGUgb3IgWjkg bm9kZXMgZG9lcyBub3Qga25vdyB0aGUgZ2xvYmFsDQpJRDxicj4NCiZndDsgb2YgQTEgKS48YnI+ DQo8YnI+DQpJdCdzIG5vdCBjbGVhciB0byBtZSB3aGF0IHByb2JsZW0geW91J3JlIHRyeWluZyB0 byBzb2x2ZS4gJm5ic3A7Q2FuIHlvdQ0KcmVwaHJhc2U/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mbHQ7ZmVpJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+PGJyPg0KU2ltaWxhcmx5IHdpdGggdGhlIGlzc3VlIDIgcHJvdmlkZWQgYWJvdmUsIHdo ZW4gTFNQMSBhbmQgTFNQMiBhcmUgYm91bmQNCnRvZ2V0aGVyPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj50byBiZSBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB0aGUg Z2xvYmFsDQpJRCBjYXJyaWVkIGluIHRoZSBMU1AxJ3MgYW5kPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5MU1AyJ3MgUGF0aCBtZXNzYWdlcyBhcmUgbm9kZSBBJ3Mgb3Igbm9kZSBa J3MsIGlmDQppdCBpcyB0aGUgZ2xvYmFsIElEIG9mIG5vZGUgQSw8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPm5vZGUgQSBzdGlsbCBkb2VzIGtub3cgdGhlIGdsb2JhbCBJRCBvZiBu b2RlIFouPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TFNQMTwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1aPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TFNQMg0KPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Ib3BlIEkgY2xhcmlmeSBpdCBjbGVhcmx5 LiAmbmJzcDs6KTwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmx0Oy9m ZWkmZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpBbHNv IGtlZXAgaW4gbWluZCB0aGF0IG11bHRpcGxlIGFzc29jaWF0aW9uIG9iamVjdHMgaGF2ZSBhbHdh eXMgYmVlbjxicj4NCnN1cHBvcnRlZCBhbmQgdGhpcyBhYmlsaXR5IGlzIG5vdCBtb2RpZmllZCBi eSB0aGUgZHJhZnQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7 ZmVpJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgYWdyZWU8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZsdDsvZmVpJmd0OzwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIuIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBscy10cC1vaW8tMDE8YnI+DQomZ3Q7IDxi cj4NCiZndDsgVGhlIEdsb2JhbF9JRCBPYmplY3QgYW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2Jq ZWN0IGFyZSBkZWZpbmVkIGluDQp0aGlzPGJyPg0KJmd0OyBkcmFmdCwgJm5ic3A7d2hpY2ggZGVz Y3JpYmVzIHRoZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQPGJyPg0K Jmd0OyAoYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBub3QgY292ZXJlZCBpbiB0aGUg Y3VycmVudCB2ZXJzaW9uKQ0KYW5kPGJyPg0KJmd0OyByZXF1aXJlcyB0aGF0IHRoZSBzYW1lIGZv cm1hdCggR2xvYmFsX0lEIG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkPGJyPg0KJmd0OyBhbG9u ZyB0aGUgTFNQLjxicj4NCjxicj4NClllcy4gJm5ic3A7VGhpcyB3YXMgZGlzY3Vzc2VkIGF0IHRo ZSBsYXN0IElFVEYuICZuYnNwO1RoZSBXRyBwcmV2aW91c2x5DQpoYWQgYTxicj4NCnNvbHV0aW9u IHRvIHRoaXMgYmFzZWQgb24gdGhlIGFzc29jaWF0aW9uIG9iamVjdCwgc2VlIHJldiAwMCBvZiB0 aGUgV0c8YnI+DQpkb2N1bWVudC4gJm5ic3A7SSByZW1vdmVkIGl0IGZyb20gdGhlIGRvY3VtZW50 IGJhc2VkIG9uIGRpc2N1c3Npb24gaW4gUXVlYmVjLjxicj4NCiBBcyBkaXNjdXNzZWQgaW4gVGFp cGVpIHRoZSBjdXJyZW50IHJldiBjYW4gc3RpbGwgYmUgdXNlZCB0byBjYXJyeSB0aGU8YnI+DQpJ VFUtVCBpZGVudGlmaWVycyAoeWVzLCB0aGUgcGFydHMgdGhhdCB3ZXJlIGluIC0wMCBuZWVkIHRv IGJlIHNlcGFyYXRlbHk8YnI+DQpwdWJsaXNoZWQgdG8gZG9jdW1lbnQgdGhpcy4pPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7ZmVpJmd0OzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SSBhZ3JlZSwgbm8gcHJvYmxlbSBoZXJlPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7L2ZlaSZndDs8YnI+DQo8YnI+DQomZ3Q7IDxicj4N CiZndDsgMy48YnI+DQomZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxPGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZuYnNwOzxicj4NCiZndDsgVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFzIGEgVExWIG9m IHRoZSBMU1BfQVRUUklCVVRFIG9iamVjdCwgd2hpY2g8YnI+DQomZ3Q7IHdpbGwgYXBwZWFyIGlu IHRoZSBQYXRoL1Jlc3YgbWVzc2FnZSBvZiBjb3JvdXRlZCBiaWRyZWN0aW9uYWwgTFNQDQphbmQ8 YnI+DQomZ3Q7IG9ubHkgYXBwZWFyIGluIHRoZSBQYXRoIG1lc3NhZ2Ugb2YgYXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIExTUC48YnI+DQomZ3Q7IEZ1cnRoZXJtb3JlLCB0aGlzIGRyYWZ0IGRlZmlu ZWQgYSBDb25uZWN0aW9uIFRMViB1c2VkIHRvIGNhcnJ5IHRoZQ0KbG9jYWw8YnI+DQomZ3Q7IHR1 bm5lbCBudW1iZXIgYXNzaWduZWQgYXQgWjkgbm9kZXMgaW4gdGhlIHNjZW5hcmlvIG9mIGNvcm91 dGVkPGJyPg0KJmd0OyBiaWRpcmVjdGlvbmFsIExTUC48YnI+DQo8YnI+DQpJcyB0aGVyZSBhIHF1 ZXN0aW9uIGhlcmU/PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7 ZmVpJmd0OzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SWYgd2hhdCBJ IGRlc2NyaWJlZCBpbiBwYXJ0IDEgaXMgcmVhc29uYWJsZSwgYW5kIHRoZQ0KdXNhZ2Ugb2YgYXNz b2NpYXRpb248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm9iamVjdCBjYW4gYmUg bW9kaWZpZWQgdG8gY292ZXIgdGhlc2UgaXNzdWVzLCB0aGVyZQ0KYXJlIG5vIHByb2JsZW0gaGVy ZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+YWxzby48L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZsdDsvZmVpJmd0Ozxicj4NCjxicj4NCkxvdSAoYXMg Y29udHJpYnV0b3IpPGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGFi b3ZlIG1hdGVyaWFscyBvbmx5IHByb3ZpZGUgdGhlIHJvdWdoIGJhY2tncm91bmQuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSG9wZSB0byBoZWFyIHRoZSBvcGluaW9ucyBmcm9tIHRo ZSBXRyB0aGF0IGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lELDxicj4NCiZndDsgdGhlbiBtb3Zl IHRoZSB3b3JrIGZvcndhcmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCBy ZWdhcmRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDspPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZlaTxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IENDQU1QIG1haWxpbmcg bGlzdDxicj4NCiZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4N Cg== --=_alternative 0008EA7948257999_=-- From vero.zheng@huawei.com Fri Feb 3 02:04:21 2012 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 8D53F21F8652 for ; Fri, 3 Feb 2012 02:04:21 -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=[AWL=-0.001, 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 YAZkk26ApK2R for ; Fri, 3 Feb 2012 02:04:19 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDC321F864C for ; Fri, 3 Feb 2012 02:04: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 <0LYT00A5RAL03A@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 03 Feb 2012 18:03:00 +0800 (CST) Received: from szxrg02-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 <0LYT00IY7AL02Z@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 03 Feb 2012 18:03:00 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGU66597; Fri, 03 Feb 2012 18:02:59 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 03 Feb 2012 18:02:27 +0800 Received: from SZXEML520-MBS.china.huawei.com ([169.254.2.252]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 03 Feb 2012 18:03:21 +0800 Date: Fri, 03 Feb 2012 10:02:50 +0000 From: Vero Zheng In-reply-to: X-Originating-IP: [10.108.4.103] To: "zhang.fei3@zte.com.cn" , "ccamp@ietf.org" Message-id: <2EEA459CD95CCB4988BFAFC0F2287B5C25916F41@SZXEML520-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sd+dwJi00IW6fFd6lFC+5w)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] Discussion on how to carry the Global_ID Thread-index: AQHM3mtgdwQeGuDdLkSXNBeKNfMIpJYq8dIA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 03 Feb 2012 10:04:21 -0000 --Boundary_(ID_sd+dwJi00IW6fFd6lFC+5w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Fei, you wrote: First, "2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP. Which is not true. The Object we defined could be carried in both Path/Resv message, and is not restricted either to co-routed bi-directional LSP or associated bi-directional LSP. Second, 3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP. Why "tunnel number" is carried in the Connection TLV? I don't see its necessary for both co-route/ associated bi-directional LSP. Could you explain? Thanks. Vero From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of zhang.fei3@zte.com.cn Sent: Sunday, January 29, 2012 5:50 PM To: ccamp@ietf.org Subject: [CCAMP] Discussion on how to carry the Global_ID Hi CCAMPers As discussed in the last IETF meeting and mailinglist, the Global_ID should be carried in the signaling messages. One reason is that the judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store each other's MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num. Fortunately, there are several drafts related to this topic now, 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. The Globa_ID is incorporated into the ASSOCIATION object in the current version, which guarantees that the association is global unique. Since the ASSOCIATION object is used across different LSPs, just my2cents, the defined format is deficient to handle more scenarios. For example: (1) Considering a corouted bidirectional LSP, which is not protected by other LSPs through control plane and/or does not share the same resoures with other LSPs. In these cases, the ASSOCIATION object will not be carried in the sigaling messages. (2) Considering an associated bidirectional LSP, although the ASSOCIATION object is carried in the sigaling messages, the global_ID incorporated in the ASSOCIATION object only indicates the global prefix of the A1 or Z9 nodes. If this LSP is across different domains, I think the current format is also deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of A1 ). 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP. 3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP. The above materials only provide the rough background. Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward. Best regards ;) Fei --Boundary_(ID_sd+dwJi00IW6fFd6lFC+5w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Fei,

 

you wrote:

 

First,

“2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft,  which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

Which is not true. The Object we defined could be carried in both Path/Resv message, and is not restricted either to co-routed bi-directional LSP or associated bi-directional LSP.

 

Second,

3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01
 
The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP.

 

Why “tunnel number” is carried in the Connection TLV? I don't see its necessary for both co-route/ associated bi-directional LSP. Could you explain?

 

Thanks.

 

Vero

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of zhang.fei3@zte.com.cn
Sent: Sunday, January 29, 2012 5:50 PM
To: ccamp@ietf.org
Subject: [CCAMP] Discussion on how to carry the Global_ID

 


Hi CCAMPers

As discussed in the last IETF meeting and mailinglist, the Global_ID should be carried in the signaling messages. One reason is that the judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store each other's MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num.

Fortunately, there are several drafts related to this topic now,

1.  http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01.
   
The Globa_ID is incorporated into the ASSOCIATION object in the current version, which guarantees that the association is global unique. Since the ASSOCIATION object is used across different LSPs, just my2cents, the defined format is deficient to handle more scenarios. For example:

    (1) Considering a corouted bidirectional LSP, which is not protected by other LSPs through control plane and/or does not share the same resoures with other LSPs. In these cases, the ASSOCIATION object will not be carried in the sigaling messages.

    (2) Considering an associated bidirectional LSP, although the ASSOCIATION object is carried in the sigaling messages, the global_ID incorporated in the ASSOCIATION object only
indicates the global prefix of the A1 or Z9 nodes. If this LSP is across different domains, I think the current format is also deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of A1 ).

2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft,  which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01
 
The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP.


The above materials only provide the rough background.


Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward.


Best regards

;)

Fei

--Boundary_(ID_sd+dwJi00IW6fFd6lFC+5w)-- From zhang.fei3@zte.com.cn Fri Feb 3 06:36:16 2012 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 5182A21F855B for ; Fri, 3 Feb 2012 06:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.376 X-Spam-Level: X-Spam-Status: No, score=-97.376 tagged_above=-999 required=5 tests=[AWL=-1.499, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 ejnJ9j5-vXxU for ; Fri, 3 Feb 2012 06:36:15 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9B97221F856A for ; Fri, 3 Feb 2012 06:36:14 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Fri, 3 Feb 2012 22:09:36 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 84221.788255148; Fri, 3 Feb 2012 22:35:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q13EZt4d051662; Fri, 3 Feb 2012 22:35:55 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C25916F41@SZXEML520-MBS.china.huawei.com> To: Vero Zheng MIME-Version: 1.0 X-KeepSent: 1704EF1D:4331DC07-48257999:004E3587; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 3 Feb 2012 22:35:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-03 22:35:59, Serialize complete at 2012-02-03 22:35:59 Content-Type: multipart/alternative; boundary="=_alternative 00502E0248257999_=" X-MAIL: mse02.zte.com.cn q13EZt4d051662 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 03 Feb 2012 14:36:16 -0000 This is a multipart message in MIME format. --=_alternative 00502E0248257999_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VmVybw0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UsIHNlZSBpbiBsaW5lIHdpdGggPGZlaT48 L2ZlaT4NCg0KQmVzdCByZWdhcmRzDQoNCkZlaQ0KDQoNCg0KVmVybyBaaGVuZyA8dmVyby56aGVu Z0BodWF3ZWkuY29tPiANCjIwMTItMDItMDMgMTg6MDINCg0KytW8/sjLDQoiemhhbmcuZmVpM0B6 dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPiwgImNjYW1wQGlldGYub3JnIiANCjxj Y2FtcEBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KUkU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBo b3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRA0KDQoNCg0KDQoNCg0KRmVpLA0KIA0KeW91IHdyb3Rl Og0KIA0KRmlyc3QsIA0KobAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVu LWNjYW1wLW1wbHMtdHAtb2lvLTAxIA0KDQpUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhlIElD Q19PcGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQgaW4gdGhpcyANCmRyYWZ0LCAgd2hpY2gg ZGVzY3JpYmVzIHRoZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgDQoo YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBub3QgY292ZXJlZCBpbiB0aGUgY3VycmVu dCB2ZXJzaW9uKSBhbmQgDQpyZXF1aXJlcyB0aGF0IHRoZSBzYW1lIGZvcm1hdCggR2xvYmFsX0lE IG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkIGFsb25nIA0KdGhlIExTUC4gDQoNCldoaWNoIGlz IG5vdCB0cnVlLiBUaGUgT2JqZWN0IHdlIGRlZmluZWQgY291bGQgYmUgY2FycmllZCBpbiBib3Ro IA0KUGF0aC9SZXN2IG1lc3NhZ2UsIGFuZCBpcyBub3QgcmVzdHJpY3RlZCBlaXRoZXIgdG8gY28t cm91dGVkIA0KYmktZGlyZWN0aW9uYWwgTFNQIG9yIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uYWwg TFNQLg0KDQo8ZmVpPg0KQWx0aG91Z2ggZWl0aGVyIGNvLXJvdXRlZCBvciBhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBtZW50aW9uZWQgDQppbiB0aGlzIGRyYWZ0ICwgYWNjb3Jk aW5nIHRvICB0aGUgZGVzY3JpcGl0aW9uIGluIHNlY3Rpb24gMi4zLCAiIElmIHRoZSANCm5vZGUg YWdyZWVzLCBpdCBNVVNUIHVzZSB0aGUgc2FtZSBmb3JtYXQgb2YgT3BlcmF0b3IgSUQuICBUaGUg c2FtZSBDLVR5cGUgDQpvZiBPSU8gTVVTVCBiZSBjYXJyaWVkIGluIHRoZSBSZXN2IG1lc3NhZ2Ui LCB3aGljaCBtZWFucyB0aGF0ICB0aGUgDQpwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJpZHJl Y3Rpb25hbCBMU1AuDQpUaGUgYWJvdmUgaXMganVzdCBteSB1bmRlcnN0YW5kaW5nIGFuZCBwcm92 aWRlZCBmb3IgZGlzY3Vzc2lvbiwgYW5kIGlmIGl0IA0KaXMgd3Jvbmcgb3IgaW5hY2N1cmF0ZSwg cGxlYXNlIGxldCBtZSBrbm93Lg0KPC9mZWk+DQogDQpTZWNvbmQsIA0KMy4gDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVu bmVsLW51bS0wMSANCg0KIA0KVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFzIGEgVExWIG9mIHRo ZSBMU1BfQVRUUklCVVRFIG9iamVjdCwgd2hpY2ggd2lsbCANCmFwcGVhciBpbiB0aGUgUGF0aC9S ZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQgb25seSANCmFwcGVh ciBpbiB0aGUgUGF0aCBtZXNzYWdlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIEZ1 cnRoZXJtb3JlLCANCnRoaXMgZHJhZnQgZGVmaW5lZCBhIENvbm5lY3Rpb24gVExWIHVzZWQgdG8g Y2FycnkgdGhlIGxvY2FsIHR1bm5lbCBudW1iZXIgDQphc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0 aGUgc2NlbmFyaW8gb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuDQogDQpXaHkgobB0dW5u ZWwgbnVtYmVyobEgaXMgY2FycmllZCBpbiB0aGUgQ29ubmVjdGlvbiBUTFY/IEkgZG9uJ3Qgc2Vl IGl0cyANCm5lY2Vzc2FyeSBmb3IgYm90aCBjby1yb3V0ZS8gYXNzb2NpYXRlZCBiaS1kaXJlY3Rp b25hbCBMU1AuIENvdWxkIHlvdSANCmV4cGxhaW4/DQogDQo8ZmVpPg0KQXMgSSBzYWlkLCBpdCBp cyB1c2VmdWwgZm9yIGNvcm91dGVkIChub3QgYXNzb2NpYXRlZCkgYmlkaXJlY3Rpb25hbCBMU1As IA0KY29uc2lkZXIgdGhhdCB0aGVyZSBpcyBvbmUgTFNQIChMU1AxLCBpbml0aWF0ZWQgYXQgbm9k ZSBBKSBiZXR3ZWVuIG5vZGUgDQpBL1ouDQpJZiB0aGUgQ0MtViBwYWtjZXQgaXMgIHNlbnQgZnJv bSAgbm9kZSBaLCB0aGUgTUVQX0lEIG9mIG5vZGUgWiB3aWxsIGJlIA0KaW5zZXJ0ZWQgaW4gdGhl IE9BTSBwYWNrZXRzLCB3aGljaCBpcyBvcmdhbml6ZWQgYnkgDQpub2RlX0lEOjp0dW5uZWxfbnVt OjpMU1BfbnVtIA0KKHNlY3Rpb24gNS4yLjEgb3IgNy4yLjIgb2YgUkZDNjM3MCksIGFuZCBpZiB0 aGlzIE1FUF9JRCBpcyBub3QgcHJlLXN0b3JlZCANCmF0IG5vZGUgQSwgaXQgY2FuIG5vdCBqdWRn ZSB3aGV0aGVyIHRoaXMgTUVQX0lEIGlzIHZhbGlkLiBTZWUgdGhlIA0KZGVzY3JpcHRpb24gaW4g c2VjdGlvbiA1LjEuMS4yDQogKE1pcy1Db25uZWN0aXZpdHkgRGVmZWN0KSBvZiBSRkM2MzcxLg0K ICAgICAgICAgICAgICAgICAgIExTUDENCkEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Wg0KDQoNCjwvZmVpPg0KDQpUaGFua3MuDQogDQpWZXJvDQogDQogDQpGcm9tOiBjY2FtcC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IA0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTIg NTo1MCBQTQ0KVG86IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBbQ0NBTVBdIERpc2N1c3Npb24g b24gaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQNCiANCg0KSGkgQ0NBTVBlcnMgDQoNCkFzIGRp c2N1c3NlZCBpbiB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgYW5kIG1haWxpbmdsaXN0LCB0aGUgR2xv YmFsX0lEIA0Kc2hvdWxkIGJlIGNhcnJpZWQgaW4gdGhlIHNpZ25hbGluZyBtZXNzYWdlcy4gT25l IHJlYXNvbiBpcyB0aGF0IHRoZSANCmp1ZGdlbWVudCBvZiBhIG1pcy1jb25uZWN0aXZpdHkgZGVm ZWN0IG5lZWRzIHRoZSBBMS9aOSBub2RlcyB0byBwcmUtc3RvcmUgDQplYWNoIG90aGVyJ3MgTUVQ X0lELCB3aG9zZSBmb3JtYXQgaXM6IEdvYmFsX0lEK05vZGVfSUQrVHVubmVsX251bStMU1BfbnVt LiANCg0KDQpGb3J0dW5hdGVseSwgdGhlcmUgYXJlIHNldmVyYWwgZHJhZnRzIHJlbGF0ZWQgdG8g dGhpcyB0b3BpYyBub3csIA0KDQoxLiAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1jY2FtcC1hc3NvYy1leHQtMDEuIA0KICAgIA0KVGhlIEdsb2JhX0lEIGlzIGluY29ycG9y YXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaW4gdGhlIGN1cnJlbnQgDQp2ZXJzaW9u LCB3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIGFzc29jaWF0aW9uIGlzIGdsb2JhbCB1bmlxdWUu IFNpbmNlIHRoZSANCkFTU09DSUFUSU9OIG9iamVjdCBpcyB1c2VkIGFjcm9zcyBkaWZmZXJlbnQg TFNQcywganVzdCBteTJjZW50cywgdGhlIA0KZGVmaW5lZCBmb3JtYXQgaXMgZGVmaWNpZW50IHRv IGhhbmRsZSBtb3JlIHNjZW5hcmlvcy4gRm9yIGV4YW1wbGU6IA0KDQogICAgKDEpIENvbnNpZGVy aW5nIGEgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHdoaWNoIGlzIG5vdCBwcm90ZWN0ZWQg DQpieSBvdGhlciBMU1BzIHRocm91Z2ggY29udHJvbCBwbGFuZSBhbmQvb3IgZG9lcyBub3Qgc2hh cmUgdGhlIHNhbWUgDQpyZXNvdXJlcyB3aXRoIG90aGVyIExTUHMuIEluIHRoZXNlIGNhc2VzLCB0 aGUgQVNTT0NJQVRJT04gb2JqZWN0IHdpbGwgbm90IA0KYmUgY2FycmllZCBpbiB0aGUgc2lnYWxp bmcgbWVzc2FnZXMuIA0KDQogICAgKDIpIENvbnNpZGVyaW5nIGFuIGFzc29jaWF0ZWQgYmlkaXJl Y3Rpb25hbCBMU1AsIGFsdGhvdWdoIHRoZSANCkFTU09DSUFUSU9OIG9iamVjdCBpcyBjYXJyaWVk IGluIHRoZSBzaWdhbGluZyBtZXNzYWdlcywgdGhlIGdsb2JhbF9JRCANCmluY29ycG9yYXRlZCBp biB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IG9ubHkgDQppbmRpY2F0ZXMgdGhlIGdsb2JhbCBwcmVm aXggb2YgdGhlIEExIG9yIFo5IG5vZGVzLiBJZiB0aGlzIExTUCBpcyBhY3Jvc3MgDQpkaWZmZXJl bnQgZG9tYWlucywgSSB0aGluayB0aGUgY3VycmVudCBmb3JtYXQgaXMgYWxzbyBkZWZpY2llbnQg KEExIGRvZXMgDQpub3Qga25vdyB0aGUgZ29iYWwgSUQgb2YgWjkgbm9kZSBvciBaOSBub2RlcyBk b2VzIG5vdCBrbm93IHRoZSBnbG9iYWwgSUQgDQpvZiBBMSApLiANCg0KMi4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1jY2FtcC1tcGxzLXRwLW9pby0wMSANCg0KVGhlIEds b2JhbF9JRCBPYmplY3QgYW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0IGFyZSBkZWZpbmVk IGluIHRoaXMgDQpkcmFmdCwgIHdoaWNoIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlIG9mIGNvcm91 dGVkIGJpZGlyZWN0aW9uYWwgTFNQIA0KKGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgaXMg bm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbikgYW5kIA0KcmVxdWlyZXMgdGhhdCB0 aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvciBJQ0NfT3BlcmF0b3JfSUQpaXMgdXNlZCBhbG9u ZyANCnRoZSBMU1AuIA0KDQozLiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxIA0KDQogDQpUaGUgR2xv YmFsX0lEIGlzIGNhcnJpZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3 aGljaCB3aWxsIA0KYXBwZWFyIGluIHRoZSBQYXRoL1Jlc3YgbWVzc2FnZSBvZiBjb3JvdXRlZCBi aWRyZWN0aW9uYWwgTFNQIGFuZCBvbmx5IA0KYXBwZWFyIGluIHRoZSBQYXRoIG1lc3NhZ2Ugb2Yg YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gRnVydGhlcm1vcmUsIA0KdGhpcyBkcmFmdCBk ZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUgbG9jYWwgdHVubmVsIG51 bWJlciANCmFzc2lnbmVkIGF0IFo5IG5vZGVzIGluIHRoZSBzY2VuYXJpbyBvZiBjb3JvdXRlZCBi aWRpcmVjdGlvbmFsIExTUC4gDQoNCg0KVGhlIGFib3ZlIG1hdGVyaWFscyBvbmx5IHByb3ZpZGUg dGhlIHJvdWdoIGJhY2tncm91bmQuIA0KDQoNCkhvcGUgdG8gaGVhciB0aGUgb3BpbmlvbnMgZnJv bSB0aGUgV0cgdGhhdCBob3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRCwgDQp0aGVuIG1vdmUgdGhl IHdvcmsgZm9yd2FyZC4gDQoNCg0KQmVzdCByZWdhcmRzIA0KDQo7KSANCg0KRmVpDQoNCg== --=_alternative 00502E0248257999_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlZlcm88L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciByZXNwb25z ZSwgc2VlIGluIGxpbmUNCndpdGggJmx0O2ZlaSZndDsmbHQ7L2ZlaSZndDs8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkczwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlZlcm8gWmhlbmcgJmx0 O3Zlcm8uemhlbmdAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMi0wMyAxODowMjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt6aGFuZy5mZWkzQHp0ZS5j b20uY24mcXVvdDsgJmx0O3poYW5nLmZlaTNAenRlLmNvbS5jbiZndDssDQomcXVvdDtjY2FtcEBp ZXRmLm9yZyZxdW90OyAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW0NDQU1QXSBEaXNjdXNz aW9uIG9uIGhvdyB0byBjYXJyeQ0KdGhlIEdsb2JhbF9JRDwvZm9udD48L3RhYmxlPg0KPGJyPg0K PHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxl Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGli cmkiPkZlaSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPnlvdSB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPkZpcnN0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj6hsDIuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2Nh bXAtbXBscy10cC1vaW8tMDENCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUaGUgR2xv YmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19PcGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQg aW4gdGhpcw0KZHJhZnQsICZuYnNwO3doaWNoIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlIG9mIGNv cm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQDQooYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBp cyBub3QgY292ZXJlZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uKSBhbmQNCnJlcXVpcmVzIHRoYXQg dGhlIHNhbWUgZm9ybWF0KCBHbG9iYWxfSUQgb3IgSUNDX09wZXJhdG9yX0lEKWlzIHVzZWQgYWxv bmcNCnRoZSBMU1AuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8 YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+V2hpY2ggaXMgbm90IHRydWUuIFRoZSBPYmplY3QNCndlIGRlZmluZWQgY291bGQgYmUgY2Fy cmllZCBpbiBib3RoIFBhdGgvUmVzdiBtZXNzYWdlLCBhbmQgaXMgbm90IHJlc3RyaWN0ZWQNCmVp dGhlciB0byBjby1yb3V0ZWQgYmktZGlyZWN0aW9uYWwgTFNQIG9yIGFzc29jaWF0ZWQgYmktZGly ZWN0aW9uYWwgTFNQLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj4mbHQ7ZmVpJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5BbHRob3VnaCBlaXRoZXIgY28tcm91dGVkDQpvciBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhpcyBkcmFm dCAsIGFjY29yZGluZw0KdG8gJm5ic3A7dGhlIGRlc2NyaXBpdGlvbiBpbiBzZWN0aW9uIDIuMywg JnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4NCklmIHRoZSBub2RlIGFn cmVlcywgaXQgTVVTVCB1c2UgdGhlIHNhbWUgZm9ybWF0IG9mIE9wZXJhdG9yIElELiAmbmJzcDtU aGUNCnNhbWUgQy1UeXBlIG9mIE9JTyBNVVNUIGJlIGNhcnJpZWQgaW4gdGhlIFJlc3YgbWVzc2Fn ZTwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mcXVvdDss DQp3aGljaCBtZWFucyB0aGF0ICZuYnNwO3RoZSBwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJp ZHJlY3Rpb25hbCBMU1AuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPlRoZSBhYm92ZSBpcyBqdXN0IG15IHVuZGVyc3RhbmRpbmcNCmFuZCBwcm92 aWRlZCBmb3IgZGlzY3Vzc2lvbiwgYW5kIGlmIGl0IGlzIHdyb25nIG9yIGluYWNjdXJhdGUsIHBs ZWFzZSBsZXQNCm1lIGtub3cuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPiZsdDsvZmVpJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+U2Vjb25kLCA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj4zLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NCiAmbmJzcDs8YnI+DQpUaGUgR2xvYmFsX0lEIGlzIGNhcnJpZWQgYXMgYSBU TFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaCB3aWxsDQphcHBlYXIgaW4gdGhl IFBhdGgvUmVzdiBtZXNzYWdlIG9mIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AgYW5kIG9ubHkg YXBwZWFyDQppbiB0aGUgUGF0aCBtZXNzYWdlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1AuIEZ1cnRoZXJtb3JlLCB0aGlzDQpkcmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNl ZCB0byBjYXJyeSB0aGUgbG9jYWwgdHVubmVsIG51bWJlciBhc3NpZ25lZA0KYXQgWjkgbm9kZXMg aW4gdGhlIHNjZW5hcmlvIG9mIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+V2h5IKGwdHVu bmVsIG51bWJlcqGxIGlzDQpjYXJyaWVkIGluIHRoZSBDb25uZWN0aW9uIFRMVj8gSSBkb24ndCBz ZWUgaXRzIG5lY2Vzc2FyeSBmb3IgYm90aCBjby1yb3V0ZS8NCmFzc29jaWF0ZWQgYmktZGlyZWN0 aW9uYWwgTFNQLiBDb3VsZCB5b3UgZXhwbGFpbj88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZsdDtmZWkmZ3Q7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPkFzIEkgc2FpZCwgaXQgaXMg dXNlZnVsIGZvcg0KY29yb3V0ZWQgKG5vdCBhc3NvY2lhdGVkKSBiaWRpcmVjdGlvbmFsIExTUCwg Jm5ic3A7Y29uc2lkZXIgdGhhdCB0aGVyZQ0KaXMgb25lIExTUCAoTFNQMSwgaW5pdGlhdGVkIGF0 IG5vZGUgQSkgYmV0d2VlbiBub2RlIEEvWi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+SWYgdGhlIENDLVYgcGFrY2V0IGlzICZuYnNwO3NlbnQN CmZyb20gJm5ic3A7bm9kZSBaLCB0aGUgTUVQX0lEIG9mIG5vZGUgWiB3aWxsIGJlIGluc2VydGVk IGluIHRoZSBPQU0gcGFja2V0cywNCndoaWNoIGlzIG9yZ2FuaXplZCBieSBub2RlX0lEOjp0dW5u ZWxfbnVtOjpMU1BfbnVtIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj4oc2VjdGlvbiA1LjIuMSBvciA3LjIuMiBvZg0KUkZDNjM3MCksIGFuZCBp ZiB0aGlzIE1FUF9JRCBpcyBub3QgcHJlLXN0b3JlZCBhdCBub2RlIEEsIGl0IGNhbiBub3QganVk Z2UNCndoZXRoZXIgdGhpcyBNRVBfSUQgaXMgdmFsaWQuIFNlZSB0aGUgZGVzY3JpcHRpb24gaW4g c2VjdGlvbiA1LjEuMS4yPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh Y2U9IkNhbGlicmkiPiZuYnNwOyg8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxi Pk1pcy1Db25uZWN0aXZpdHkNCkRlZmVjdDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+KSBvZiBSRkM2MzcxLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TFNQMTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5BLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLVo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jmx0Oy9mZWkmZ3Q7PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPlRoYW5rcy48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki PlZlcm88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5G cm9tOjwvYj4gY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPnpoYW5nLmZlaTNAenRlLmNvbS5jbjxiPjxicj4N ClNlbnQ6PC9iPiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTIgNTo1MCBQTTxiPjxicj4NClRvOjwv Yj4gY2NhbXBAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gW0NDQU1QXSBEaXNjdXNzaW9u IG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQXJpYWwiPjxicj4NCkhpIENDQU1QZXJzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpBcyBkaXNjdXNzZWQgaW4gdGhlIGxhc3QgSUVURiBtZWV0aW5nIGFuZCBtYWlsaW5nbGlzdCwg dGhlIEdsb2JhbF9JRCBzaG91bGQNCmJlIGNhcnJpZWQgaW4gdGhlIHNpZ25hbGluZyBtZXNzYWdl cy4gT25lIHJlYXNvbiBpcyB0aGF0IHRoZSBqdWRnZW1lbnQNCm9mIGEgbWlzLWNvbm5lY3Rpdml0 eSBkZWZlY3QgbmVlZHMgdGhlIEExL1o5IG5vZGVzIHRvIHByZS1zdG9yZSBlYWNoIG90aGVyJ3MN Ck1FUF9JRCwgd2hvc2UgZm9ybWF0IGlzOiBHb2JhbF9JRCtOb2RlX0lEK1R1bm5lbF9udW0rTFNQ X251bS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpGb3J0dW5hdGVseSwgdGhlcmUg YXJlIHNldmVyYWwgZHJhZnRzIHJlbGF0ZWQgdG8gdGhpcyB0b3BpYyBub3csPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KMS4gJm5ic3A7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDEuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K ICZuYnNwOyA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIEdsb2JhX0lEIGlzIGlu Y29ycG9yYXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaW4gdGhlIGN1cnJlbnQNCnZl cnNpb24sIHdoaWNoIGd1YXJhbnRlZXMgdGhhdCB0aGUgYXNzb2NpYXRpb24gaXMgZ2xvYmFsIHVu aXF1ZS4gU2luY2UNCnRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaXMgdXNlZCBhY3Jvc3MgZGlmZmVy ZW50IExTUHMsIGp1c3QgbXkyY2VudHMsIHRoZQ0KZGVmaW5lZCBmb3JtYXQgaXMgZGVmaWNpZW50 IHRvIGhhbmRsZSBtb3JlIHNjZW5hcmlvcy4gRm9yIGV4YW1wbGU6PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGJyPg0KICZuYnNwOyAmbmJzcDsoMSkgQ29uc2lkZXJpbmcgYSBjb3JvdXRlZCBi aWRpcmVjdGlvbmFsIExTUCwgd2hpY2ggaXMgbm90DQpwcm90ZWN0ZWQgYnkgb3RoZXIgTFNQcyB0 aHJvdWdoIGNvbnRyb2wgcGxhbmUgYW5kL29yIGRvZXMgbm90IHNoYXJlIHRoZQ0Kc2FtZSByZXNv dXJlcyB3aXRoIG90aGVyIExTUHMuIEluIHRoZXNlIGNhc2VzLCB0aGUgQVNTT0NJQVRJT04gb2Jq ZWN0IHdpbGwNCm5vdCBiZSBjYXJyaWVkIGluIHRoZSBzaWdhbGluZyBtZXNzYWdlcy4gPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiAmbmJzcDsgJm5ic3A7KDIpIENvbnNpZGVyaW5nIGFu IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIGFsdGhvdWdoDQp0aGUgQVNTT0NJQVRJT04g b2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLCB0aGUgZ2xvYmFsX0lE DQppbmNvcnBvcmF0ZWQgaW4gdGhlIEFTU09DSUFUSU9OIG9iamVjdCBvbmx5PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGJyPg0KaW5kaWNhdGVzIHRoZSBnbG9iYWwgcHJlZml4IG9mIHRoZSBBMSBvciBa OSBub2Rlcy4gSWYgdGhpcyBMU1AgaXMgYWNyb3NzDQpkaWZmZXJlbnQgZG9tYWlucywgSSB0aGlu ayB0aGUgY3VycmVudCBmb3JtYXQgaXMgYWxzbyBkZWZpY2llbnQgKEExIGRvZXMNCm5vdCBrbm93 IHRoZSBnb2JhbCBJRCBvZiBaOSBub2RlIG9yIFo5IG5vZGVzIGRvZXMgbm90IGtub3cgdGhlIGds b2JhbCBJRA0Kb2YgQTEgKS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjIuIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBscy10cC1vaW8tMDEgPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZSBHbG9iYWxfSUQgT2JqZWN0IGFuZCB0aGUg SUNDX09wZXJhdG9yX0lEIE9iamVjdCBhcmUgZGVmaW5lZCBpbiB0aGlzDQpkcmFmdCwgJm5ic3A7 d2hpY2ggZGVzY3JpYmVzIHRoZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBM U1ANCihhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGluIHRoZSBj dXJyZW50IHZlcnNpb24pIGFuZA0KcmVxdWlyZXMgdGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2Jh bF9JRCBvciBJQ0NfT3BlcmF0b3JfSUQpaXMgdXNlZCBhbG9uZw0KdGhlIExTUC48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjMuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGJyPg0KICZuYnNwOzxicj4NClRoZSBHbG9iYWxfSUQgaXMgY2FycmllZCBhcyBh IFRMViBvZiB0aGUgTFNQX0FUVFJJQlVURSBvYmplY3QsIHdoaWNoIHdpbGwNCmFwcGVhciBpbiB0 aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQgb25s eSBhcHBlYXINCmluIHRoZSBQYXRoIG1lc3NhZ2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFs IExTUC4gRnVydGhlcm1vcmUsIHRoaXMNCmRyYWZ0IGRlZmluZWQgYSBDb25uZWN0aW9uIFRMViB1 c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5uZWwgbnVtYmVyIGFzc2lnbmVkDQphdCBaOSBub2Rl cyBpbiB0aGUgc2NlbmFyaW8gb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIGFib3ZlIG1hdGVyaWFscyBvbmx5IHBy b3ZpZGUgdGhlIHJvdWdoIGJhY2tncm91bmQuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpIb3BlIHRvIGhlYXIgdGhlIG9waW5pb25zIGZyb20gdGhlIFdHIHRoYXQgaG93IHRv IGNhcnJ5IHRoZSBHbG9iYWxfSUQsDQp0aGVuIG1vdmUgdGhlIHdvcmsgZm9yd2FyZC48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpCZXN0IHJlZ2FyZHM8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCjspPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpGZWk8 L2ZvbnQ+DQo8YnI+DQo= --=_alternative 00502E0248257999_=-- From harai@nict.go.jp Mon Feb 6 03:28:06 2012 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 D861421F85C3; Mon, 6 Feb 2012 03:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.722 X-Spam-Level: **** X-Spam-Status: No, score=4.722 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, MIME_BASE64_TEXT=1.753] 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 LBNPaWdRRPRb; Mon, 6 Feb 2012 03:28:04 -0800 (PST) Received: from mow.securemx.jp (mow300.securemx.jp [210.130.202.48]) by ietfa.amsl.com (Postfix) with ESMTP id EF33221F85B1; Mon, 6 Feb 2012 03:28:03 -0800 (PST) Received: by mow.securemx.jp (mow300) id q16BS2Av020009; Mon, 6 Feb 2012 20:28:02 +0900 X-MXL-Hash: 4f2fb941248945ed-da02098e01249877b6d5fdbe0f7bb19ed94c371e Received: from ns2.nict.go.jp (ns2.nict.go.jp [133.243.3.2]) by relay.securemx.jp (mx-mr302) id q16BS1eN011859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2012 20:28:01 +0900 Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id q16BS0TP026123; Mon, 6 Feb 2012 20:28:01 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id q16BS0ER012352; Mon, 6 Feb 2012 20:28:00 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id q16BS0Gw012348; Mon, 6 Feb 2012 20:28:00 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 64DED169C6; Mon, 6 Feb 2012 20:28:00 +0900 (JST) Received: from localhost (skigoggle.nict.go.jp [133.243.146.51]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 5E79016054; Mon, 6 Feb 2012 20:28:00 +0900 (JST) Date: Mon, 06 Feb 2012 20:27:19 +0900 (JST) Message-Id: <20120206.202719.2135711079242187783.harai@nict.go.jp> To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org From: Hiroaki Harai X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 Cc: iPOP2012-tpc-sec@pilab.jp Subject: [CCAMP] (submission deadline Feb 14) iPOP2012 Call for Presentation 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, 06 Feb 2012 11:28:06 -0000 KEFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZWQgbXVsdGlwbGUgY29waWVzIG9mIHRoaXMgbWVzc2Fn ZS4pDQoNCkRlYXIgQ0NBTVAsIFBDRSBhbmQgTVBMUyBzdWJzY3JpYmVycywNCg0KUGxlYXNlIGZp bmQgaVBPUDIwMTIgQ2FsbCBmb3IgUHJlc2VudGF0aW9uLiAgVGhlIGRlYWRsaW5lIGZvcg0Kc3Vi bWl0dGluZyBwcmVzZW50YXRpb24gcHJvcG9zYWwgKDEtcGFnZSBhYnN0cmFjdCkgaXMgRmVicnVh cnkgMTV0aCwNCjIwMTIuDQoNCkJlc3QgcmVnYXJkcywNCkhpcm9ha2kgSGFyYWkNClRQQyBDby1D aGFpciBmb3IgaVBPUCAyMDEyDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAg ICBDYWxsIGZvciBQcmVzZW50YXRpb24NCg0KOHRoIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBv biBJUCArIE9wdGljYWwgTmV0d29yayAoaVBPUCAyMDEyKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgIE1heSAzMSAtIEp1bmUgMSwgMjAxMg0KICAgICBIaXlvc2hpIENhbXB1cywgS2VpbyBVbml2 ZXJzaXR5LCBZb2tvaGFtYS1zaGksIEthbmFnYXdhLCBKYXBhbg0KICAgICAgICAgICAgICAgICAg aHR0cDovL3d3dy5waWxhYi5qcC9pcG9wMjAxMi8NCg0KVGhlIGNvbmZlcmVuY2UgaXMgaW50ZW5k ZWQgdG8gc2hhcmUgYW1vbmcgdGhlIGluZHVzdHJ5IGFuZCB0aGUgYWNhZGVtaWEsDQp0aGUga25v d2xlZGdlLCBuZXcgZmluZGluZ3MsIGFuZCBleHBlcmllbmNlIG9uIHRoZSBzdGF0ZS1vZi10aGUg YXJ0IG9mDQpJUCBhbmQgb3B0aWNhbCBuZXR3b3JraW5nIHRlY2hub2xvZ2llcy4gSXQgZmVhdHVy ZXMgdGVjaG5pY2FsIHNlc3Npb25zDQphbmQgcGxhbm5lZCBleGhpYml0aW9ucy4gVGhlIG9wcG9y dHVuaXR5IHRvIHBhcnRpY2lwYXRlIGlzIG9wZW4gdG8gYWxsLg0KDQpJbXBvcnRhbnQgRGF0ZXM6 DQpTdWJtaXNzaW9uIGRlYWRsaW5lIG9mIG9uZS1wYWdlIGFic3RyYWN0OiBGZWJydWFyeSAxNSwg MjAxMiANCk5vdGlmaWNhdGlvbiBvZiBhY2NlcHRhbmNlOiBNYXJjaCAzMCwgMjAxMg0KU3VibWlz c2lvbiBkZWFkbGluZSBvZiBmaW5hbCBwcmVzZW50YXRpb24gc2xpZGVzOiBBcHJpbCAyMCwgMjAx Mg0KDQpUaGUgVGVjaG5pY2FsIFByb2dyYW0gQ29tbWl0dGVlIGZvciBpUE9QIDIwMTIgaXMgc29s aWNpdGluZyBwcmVzZW50YXRpb24gDQpwcm9wb3NhbHMgZm9yIHRoaXMgY29uZmVyZW5jZS4gUHJv dG9jb2wgZGVzaWduLCBleHBlcmltZW50LCB0aGVvcnksIA0KaW1wbGVtZW50YXRpb24sIGFuZCBv cGVyYXRpb25hbCBleHBlcmllbmNlcyBhcmUgc29saWNpdGVkLg0KVGhlIHRvcGljcyBvZiB0aGUg Y29uZmVyZW5jZSB3aWxsIGluY2x1ZGUgYnV0IG5vdCBiZSBsaW1pdGVkIHRvIHRoZSBmb2xsb3dp bmc6DQoNCiogUGhvdG9uaWMgTmV0d29yayBmb3IgTnhHTiBhbmQgTndHTg0KKiBNdWx0aS1sYXll ciBuZXR3b3JrIChNTE4pIC8gTXVsdGktcmVnaW9uIG5ldHdvcmsgKE1STikNCiogSW50ZXItYXJl YS9JbnRlci1BUyBuZXR3b3JrDQoqIFdhdmVsZW5ndGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3Jr cyAoV1NPTiksIFJvdXRpbmcgd2F2ZWxlbmd0aCBhc3NpZ25tZW50LA0KICBJbXBhaXJtZW50IG1h bmFnZW1lbnQNCiogR01QTFMvQVNPTiB0ZWNobm9sb2dpZXMNCiogR01QTFMgTmV0d29yayBtYW5h Z2VtZW50LCBPQSZNDQoqIEdNUExTLWNvbnRyb2xsZWQgRXRoZXJuZXQgTGFiZWwgU3dpdGNoaW5n IChHRUxTKSBhbmQgcmVsYXRlZCBFdGhlcm5ldA0KICB0cmFuc3BvcnQgdGVjaG5vbG9naWVzDQoq IFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENFKSwgVHJhZmZpYyBlbmdpbmVlcmluZw0KKiBB cHBsaWNhdGlvbiB3aXRoIGhpZ2gtYmFuZHdpZHRoIGRlbWFuZA0KKiBMMVZQTiwgQmFuZHdpZHRo IG9uIERlbWFuZCwgYW5kIFBob3RvbmljIEdyaWQNCiogTVBMUyBhbmQgRXRoZXJuZXQgbmV0d29y a2luZyBmb3IgSW50ZXItZGF0YSBjZW50ZXIgY29ubmVjdGl2aXR5IGZvciBjbG91ZA0KICBjb21w dXRpbmcNCiogQ2FycmllciBFdGhlcm5ldCBhbmQgTVBMUy1UUCBmb3IgYmFja2hhdWxpbmcNCiog VGVzdGJlZCwgZmllbGQgdHJpYWwNCg0KDQpJZiB5b3Ugd2lzaCB0byBzdWJtaXQgYSB0b3BpYyBm b3IgY29uc2lkZXJhdGlvbiwgcGxlYXNlIHNlbmQgYW4gRXh0ZW5kZWQgDQpBYnN0cmFjdHMgb2Yg NDAwIHdvcmRzIGFuZCBhIG1heGltdW0gb2YgMSBwYWdlLCBpbmNsdWRpbmcgZmlndXJlcyBhbmQg DQpkaWFncmFtcywgc3BlYWtlcqJzIG5hbWUsIGFmZmlsaWF0aW9uLCBhbmQgY29udGFjdCBpbmZv cm1hdGlvbiANCnRvIHRoZSBUZWNobmljYWwgUHJvZ3JhbSBDb21taXR0ZWUgYXQgaXBvcDIwMTIt Q0ZQQHBpbGFiLmpwLg0KUGxlYXNlIHNlZSBodHRwOi8vd3d3LnBpbGFiLmpwL2lwb3AyMDEyLyBm b3IgbW9yZSBkZXRhaWxzLg0KDQpLaW5kIHJlZ2FyZHMsDQpIaXJvYWtpIEhhcmFpLCBKdWxpZW4g TWV1cmljLCBFaWppIE9raQ0KaVBPUCAyMDEyIFRQQyBDby1DaGFpcnMNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KLS0tLS0tLQ0KSGlyb2FraSBIYXJhaSwgUGguRC4gKGh0dHA6Ly93d3cubmljdC5nby5qcC8p DQpEaXJlY3RvciwgTmV0d29yayBBcmNoaXRlY3R1cmUgTGFiLiwgUGhvdG9uaWMgTmV0d29yayBS ZXNlYXJjaCBJbnN0aXR1dGUNClJlc2VhcmNoIE1hbmFnZXIsIE5ldyBHZW5lcmF0aW9uIE5ldHdv cmsgUmVzZWFyY2ggTGFiLg0KTmF0aW9uYWwgSW5zdGl0dXRlIG9mIEluZm9ybWF0aW9uIGFuZCBD b21tdW5pY2F0aW9ucyBUZWNobm9sb2d5IChOSUNUKSwgSkFQQU4uDQpFbWFpbDogaGFyYWlAbmlj dC5nby5qcDsgIFBob25lOiArODEtNDItMzI3LTU0MTg7ICBGQVg6ICs4MS00Mi0zMjctNjY4MA0K From lberger@labn.net Mon Feb 6 07:54:16 2012 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 1D58421F8636 for ; Mon, 6 Feb 2012 07:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.292 X-Spam-Level: X-Spam-Status: No, score=-96.292 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FR_3TAG_3TAG=1.758, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, 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 UWStUJUE1TZs for ; Mon, 6 Feb 2012 07:54:11 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 8162821F862D for ; Mon, 6 Feb 2012 07:54:11 -0800 (PST) Received: (qmail 14633 invoked by uid 0); 6 Feb 2012 15:54:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 6 Feb 2012 15:54: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:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=d+fO8x5G96s6NG6LyxHKpr5oEymFCmd3RZB7lL5zsVI=; b=hI4ynjaxROh4/2HtRrUC+InOzJDOdZxPR1wgFHf7FzOQdXUu4EjTyUrO1Yk/WzSm/Ehc/agXfk/oBklFi6NK4zSiWi/a9QO+/IPNA+lT5HtVBSuavvFnIKqF04EoUAbR; 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 1RuQtN-0003wV-Oa; Mon, 06 Feb 2012 08:54:09 -0700 Message-ID: <4F2FF79F.5010004@labn.net> Date: Mon, 06 Feb 2012 10:54:07 -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: zhang.fei3@zte.com.cn References: In-Reply-To: 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: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 06 Feb 2012 15:54:16 -0000 Fei, See below. On 2/2/2012 8:37 PM, zhang.fei3@zte.com.cn wrote: > > Lou > > Thanks for your response, please see the reponses in-line with > to check whether I make a mistake. > > Best regards > > Fei > > > *Lou Berger * > > 2012-02-02 22:29 > > > 收件人 > zhang.fei3@zte.com.cn > 抄送 > "ccamp@ietf.org" > 主题 > Re: [CCAMP] Discussion on how to carry the Global_ID > > > > > > > > > Fei, > see below for responses in-line. > > On 1/29/2012 4:49 AM, zhang.fei3@zte.com.cn wrote: >> >> Hi CCAMPers >> >> As discussed in the last IETF meeting and mailinglist, the Global_ID >> should be carried in the signaling messages. One reason is that the >> judgement of a mis-connectivity defect needs the A1/Z9 nodes to >> pre-store each other's MEP_ID, whose format is: >> Gobal_ID+Node_ID+Tunnel_num+LSP_num. >> >> Fortunately, there are several drafts related to this topic now, >> >> 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. >> >> The Globa_ID is incorporated into the ASSOCIATION object in the current >> version, which guarantees that the association is global unique. Since >> the ASSOCIATION object is used across different LSPs, just my2cents, the >> defined format is deficient to handle more scenarios. For example: >> >> (1) Considering a corouted bidirectional LSP, which is not protected >> by other LSPs through control plane and/or does not share the same >> resoures with other LSPs. > > >> In these cases, the ASSOCIATION object will >> not be carried in the sigaling messages. > > Why not? One of the purposes of this draft is to support non-recovery > uses of the association object. Note the name of section 2. > > > > According to my understanding, the association object is used to > associate different LSPs. I agree that this is the original motivation for the association object. But if the need information is already defined for this object, why define another object that carries the same information. We certainly can add some text to the draft to highlight this possibility. > See the descriptions in section 2: > "As described below,association is always done based on matching > either Path state to Path state, or Resv state to Resv state" > > Consider the following scenairos: > > LSP1 > A-------------------------------------------Z > > Node A is located in AS1 and node Z is located in AS2, when the Path > message for LSP1 (co-routed bidirectinal LSP) with Extended Association > Object inserted is initiated at node A, three issues: > > I1: what kind of association type is used here? the same as you'd use in an associated by directional. Per your draft this is type 4. Your draft can make this clear; perhaps by renaming the type to something along the lines of "LSP identification", and explicitly covering this case. > > I2: association object is used across different path states, but LSP1 > is not associated with any other LSPS in this case. Strcikly speaking, for co-routed LSPs the association is per standard RSVP and the association object is just carrying the LSP identification information. > > I3: Node A still does know the global ID of node Z > Right, that has always come in the resv. > If these issues are really existed, the current usage of association object > should be revised, for example, like this: > > R1: It can be used not to math path state, in other words, it can appear > only > in one LSP's path message (no need to be pair) > I think this is allowed, but certainly adding a few words to assoc-ext to make this explicit is fine. > R2: It can be used across Path and RESV state, in this way, an > association object > can be inserted at node Z in the RESV message, with the global ID of node Z > Again, in the single LSP case, association is being made per standard RSVP. > R3: If issue 2 is agreeed, a new association type needs to be defined here? > Alternatively, just expand the scope/name of type 4 in your draft. Lou > > > >> >> (2) Considering an associated bidirectional LSP, although the >> ASSOCIATION object is carried in the sigaling messages, the global_ID >> incorporated in the ASSOCIATION object only >> indicates the global prefix of the A1 or Z9 nodes. If this LSP is across >> different domains, I think the current format is also deficient (A1 does >> not know the gobal ID of Z9 node or Z9 nodes does not know the global ID >> of A1 ). > > It's not clear to me what problem you're trying to solve. Can you > rephrase? > > > > Similarly with the issue 2 provided above, when LSP1 and LSP2 are bound > together > to be an associated bidirectional LSP, the global ID carried in the > LSP1's and > LSP2's Path messages are node A's or node Z's, if it is the global ID of > node A, > node A still does know the global ID of node Z. > > LSP1 > A-------------------------------------------Z > LSP2 > Hope I clarify it clearly. :) > > > > > Also keep in mind that multiple association objects have always been > supported and this ability is not modified by the draft. > > > I agree > > >> >> 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 >> >> The Global_ID Object and the ICC_Operator_ID Object are defined in this >> draft, which describes the procedure of corouted bidirectional LSP >> (associated bidirectional LSP is not covered in the current version) and >> requires that the same format( Global_ID or ICC_Operator_ID)is used >> along the LSP. > > Yes. This was discussed at the last IETF. The WG previously had a > solution to this based on the association object, see rev 00 of the WG > document. I removed it from the document based on discussion in Quebec. > As discussed in Taipei the current rev can still be used to carry the > ITU-T identifiers (yes, the parts that were in -00 need to be separately > published to document this.) > > > I agree, no problem here > > >> >> 3. >> > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 >> >> >> The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which >> will appear in the Path/Resv message of corouted bidrectional LSP and >> only appear in the Path message of associated bidirectional LSP. >> Furthermore, this draft defined a Connection TLV used to carry the local >> tunnel number assigned at Z9 nodes in the scenario of corouted >> bidirectional LSP. > > Is there a question here? > > > > If what I described in part 1 is reasonable, and the usage of association > object can be modified to cover these issues, there are no problem here > also. > > > > Lou (as contributor) > >> >> >> The above materials only provide the rough background. >> >> >> Hope to hear the opinions from the WG that how to carry the Global_ID, >> then move the work forward. >> >> >> Best regards >> >> ;) >> >> Fei >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > > From Ben.Wright@metaswitch.com Mon Feb 6 09:05:27 2012 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 103E421F86CE for ; Mon, 6 Feb 2012 09:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 A9eVYsyBFNPb for ; Mon, 6 Feb 2012 09:05:25 -0800 (PST) Received: from ENFICSETS3.metaswitch.com (enficsets3.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5819221F86BE for ; Mon, 6 Feb 2012 09:05:25 -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.2.247.3; Mon, 6 Feb 2012 17:05:17 +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.02.0247.003; Mon, 6 Feb 2012 17:05:22 +0000 From: Ben Wright To: "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Thread-Topic: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01) Thread-Index: Aczk8YJ2S9X0jt8bQEec+MWkSS9DMg== Date: Mon, 6 Feb 2012 17:05:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.102] Content-Type: multipart/alternative; boundary="_000_B3B6FD81D3159A45B5421AF9DD500F8846DE20CEENFICSMBX1datco_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01) 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, 06 Feb 2012 17:05:27 -0000 --_000_B3B6FD81D3159A45B5421AF9DD500F8846DE20CEENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai et al, We have been thinking about function we will need to add to draft-ietf-ccam= p-gmpls-signaling-g709v3-01 to fully support automatically provisioned FA-L= SPs. I wanted to see whether you agree with our analysis. We think that the RSVP-TE signalling should be extended to carry more infor= mation in order to allow other nodes on the signalling path to set up the c= orrect FA-LSP. For example, in the network in http://tools.ietf.org/html= /draft-ietf-ccamp-gmpls-signaling-g709v3-01#section-7, we believe that N1 s= hould be able to prescribe to N2 the set of hops that it should use to set = up the ODU2 FA-LSP, and the signal type of the FA-LSP it should set up, and= (probably) the multiplexing hierarchy to be used at either end. Typicall= y, we'd expect N1 would want to explicitly prevent N2 from querying routing= to set up the FA-LSP - otherwise, a routing calculation triggered by N2 c= ould compute a path for the FA-LSP inconsistent with N1's intentions (e.g. = which could break some SRLG diversity requirement). What do you think? Is this an issue that you anticipate addressing in the= text for section 7.1 (alluded to as being for future study)? Thanks, Ben Wright and Steve Balls --_000_B3B6FD81D3159A45B5421AF9DD500F8846DE20CEENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fatai et al,

 =

We have been thinking ab= out function we will need to add to draft-ietf-ccamp-gmpls-signaling-g709v3= -01 to fully support automatically provisioned FA-LSPs.   I wante= d to see whether you agree with our analysis. 

 =

We think that the RSVP-T= E signalling should be extended to carry more information in order to allow= other nodes on the signalling path to set up the correct FA-LSP. &nbs= p;  For example, in the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmp= ls-signaling-g709v3-01#section-7, we believe that N1 should be a= ble to prescribe to N2 the set of hops that it should use to set up the ODU= 2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be u= sed at either end.   Typically, we’d expect N1 would want t= o explicitly prevent N2 from querying routing to set up the FA-LSP  &#= 8211; otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1’s intentions (e.g= . which could break some SRLG diversity requirement).    &nb= sp; 

 =

What do you think?  = ; Is this an issue that you anticipate addressing in the text for sect= ion 7.1 (alluded to as being for future study)?   

 =

Thanks,

 =

Ben Wright and Steve Bal= ls

 =

--_000_B3B6FD81D3159A45B5421AF9DD500F8846DE20CEENFICSMBX1datco_-- From ietf-ipr@ietf.org Mon Feb 6 14:05:44 2012 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 C29EA11E809C; Mon, 6 Feb 2012 14:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 S2TcjDa2dU-p; Mon, 6 Feb 2012 14:05:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2531821F8599; Mon, 6 Feb 2012 14:05:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: gregb@grotto-networking.com, diego.caviglia@marconi.com, rabbat@alum.mit.edu, hhelvoort@huawei.com, X-Test-IDTracker: no Message-ID: <20120206220544.31318.37978.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 14:05:44 -0800 Cc: ccamp@ietf.org, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6344 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, 06 Feb 2012 22:05:45 -0000 Dear Greg Bernstein, Diego Caviglia, Richard Rabbat, Huub van Helvoort: An IPR disclosure that pertains to your RFC entitled "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)" (RFC6344) was submitted= to the IETF Secretariat on 2012-01-31 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1671/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6344.""); The IETF Secretariat From ietf-ipr@ietf.org Mon Feb 6 14:06:55 2012 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 BDB3111E809C; Mon, 6 Feb 2012 14:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 POzxUWvD0nlc; Mon, 6 Feb 2012 14:06:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BC821F8595; Mon, 6 Feb 2012 14:06:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ylee@huawei.com, gregb@grotto-networking.com, danli@huawei.com, imajuku.wataru@lab.ntt.co.jp, X-Test-IDTracker: no Message-ID: <20120206220655.31615.33390.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 14:06:55 -0800 Cc: ccamp@ietf.org, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ccamp-rwa-info-13 (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, 06 Feb 2012 22:06:56 -0000 Dear Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku: An IPR disclosure that pertains to your Internet-Draft entitled "Routing a= nd Wavelength Assignment Information Model for Wavelength Switched Optical Networks" (draft-ietf-ccamp-rwa-info) was submitted to the IETF Secretariat= on 2012-01-31 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1672/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ccamp-rwa-info-13 (2).""); The IETF Secretariat From zhangfatai@huawei.com Mon Feb 6 17:29:54 2012 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 6354211E80B5 for ; Mon, 6 Feb 2012 17:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 Xnow83z7d2Yb for ; Mon, 6 Feb 2012 17:29:53 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7164911E809D for ; Mon, 6 Feb 2012 17:29:52 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ000FF61HL0T@szxga04-in.huawei.com> for ccamp@ietf.org; Tue, 07 Feb 2012 09:29:46 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ000ATE1GQQI@szxga04-in.huawei.com> for ccamp@ietf.org; Tue, 07 Feb 2012 09:29:45 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW58076; Tue, 07 Feb 2012 09:29:45 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 09:29:06 +0800 Received: from SZXEML520-MBS.china.huawei.com ([169.254.2.252]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Tue, 07 Feb 2012 09:29:38 +0800 Date: Tue, 07 Feb 2012 01:29:36 +0000 From: Zhangfatai In-reply-to: X-Originating-IP: [10.70.76.157] To: Ben Wright , "draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_kXsp6cxyN7CMW7E3IwRZ5Q)" Content-language: en-US Accept-Language: zh-CN, en-US Thread-topic: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01) Thread-index: Aczk8YJ2S9X0jt8bQEec+MWkSS9DMgARXJOQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpls-signaling-g709v3-01) 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, 07 Feb 2012 01:29:54 -0000 --Boundary_(ID_kXsp6cxyN7CMW7E3IwRZ5Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgQmVuLA0KDQpJIGFncmVlZCB3aXRoIHRoZSBzY2VuYXJpbyBhbmQgcmVxdWlyZW1lbnQgeW91 IG1lbnRpb25lZC4NCg0KSG93ZXZlciwgSSB0aGluayBpdCBpcyBhIGtpbmQgb2YgZ2VuZXJpYyBN TE4gc2NlbmFyaW8sIG5vdCBqdXN0IHNwZWNpZmljIHRvIE9UTiBzaWduYWxpbmcsIHNvIEkgd2Fz IHRyeWluZyB0byBjYXB0dXJlIHRoaXMgaW4gYSBnZW5lcmljIHdheSBhbmQgZG9jdW1lbnRlZCB0 aGlzIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1o LWxzcC1tbG4tMDQudHh0Lg0KDQpQbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgKGRyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWgtbHNwLW1sbi0wNC50eHQpIHRvIHNlZSBpZiB0aGlzIGRyYWZ0IGNhbiBh ZGRyZXNzIHlvdXIgY29uY2Vybi4NCg0KTGV0oa9zIGRpc2N1c3MgbW9yZSBvbiB0aGlzIGlzc3Vl Lg0KDQoNCg0KVGhhbmtzDQoNCkZhdGFpDQoNCkZyb206IEJlbiBXcmlnaHQgW21haWx0bzpCZW4u V3JpZ2h0QG1ldGFzd2l0Y2guY29tXQ0KU2VudDogMjAxMsTqMtTCN8jVIDE6MDUNClRvOiBkcmFm dC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmcNCkNjOiBj Y2FtcEBpZXRmLm9yZw0KU3ViamVjdDogU2lnbmFsaW5nIGV4dGVuc2lvbnMgZm9yIEZBLUxTUHMg KGNvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzLTAxKQ0K DQpIaSBGYXRhaSBldCBhbCwNCg0KV2UgaGF2ZSBiZWVuIHRoaW5raW5nIGFib3V0IGZ1bmN0aW9u IHdlIHdpbGwgbmVlZCB0byBhZGQgdG8gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzLTAxIHRvIGZ1bGx5IHN1cHBvcnQgYXV0b21hdGljYWxseSBwcm92aXNpb25lZCBGQS1M U1BzLiAgIEkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHlvdSBhZ3JlZSB3aXRoIG91ciBhbmFseXNp cy4NCg0KV2UgdGhpbmsgdGhhdCB0aGUgUlNWUC1URSBzaWduYWxsaW5nIHNob3VsZCBiZSBleHRl bmRlZCB0byBjYXJyeSBtb3JlIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGFsbG93IG90aGVyIG5v ZGVzIG9uIHRoZSBzaWduYWxsaW5nIHBhdGggdG8gc2V0IHVwIHRoZSBjb3JyZWN0IEZBLUxTUC4g ICAgRm9yIGV4YW1wbGUsIGluIHRoZSBuZXR3b3JrIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wMSNzZWN0aW9uLTcs IHdlIGJlbGlldmUgdGhhdCBOMSBzaG91bGQgYmUgYWJsZSB0byBwcmVzY3JpYmUgdG8gTjIgdGhl IHNldCBvZiBob3BzIHRoYXQgaXQgc2hvdWxkIHVzZSB0byBzZXQgdXAgdGhlIE9EVTIgRkEtTFNQ LCBhbmQgdGhlIHNpZ25hbCB0eXBlIG9mIHRoZSBGQS1MU1AgaXQgc2hvdWxkIHNldCB1cCwgYW5k IChwcm9iYWJseSkgdGhlIG11bHRpcGxleGluZyBoaWVyYXJjaHkgdG8gYmUgdXNlZCBhdCBlaXRo ZXIgZW5kLiAgIFR5cGljYWxseSwgd2Whr2QgZXhwZWN0IE4xIHdvdWxkIHdhbnQgdG8gZXhwbGlj aXRseSBwcmV2ZW50IE4yIGZyb20gcXVlcnlpbmcgcm91dGluZyB0byBzZXQgdXAgdGhlIEZBLUxT UCAgqEMgb3RoZXJ3aXNlLCBhIHJvdXRpbmcgY2FsY3VsYXRpb24gdHJpZ2dlcmVkIGJ5IE4yIGNv dWxkIGNvbXB1dGUgYSBwYXRoIGZvciB0aGUgRkEtTFNQIGluY29uc2lzdGVudCB3aXRoIE4xoa9z IGludGVudGlvbnMgKGUuZy4gd2hpY2ggY291bGQgYnJlYWsgc29tZSBTUkxHIGRpdmVyc2l0eSBy ZXF1aXJlbWVudCkuDQoNCldoYXQgZG8geW91IHRoaW5rPyAgIElzIHRoaXMgYW4gaXNzdWUgdGhh dCB5b3UgYW50aWNpcGF0ZSBhZGRyZXNzaW5nIGluIHRoZSB0ZXh0IGZvciBzZWN0aW9uIDcuMSAo YWxsdWRlZCB0byBhcyBiZWluZyBmb3IgZnV0dXJlIHN0dWR5KT8NCg0KVGhhbmtzLA0KDQpCZW4g V3JpZ2h0IGFuZCBTdGV2ZSBCYWxscw0KDQo= --Boundary_(ID_kXsp6cxyN7CMW7E3IwRZ5Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi B= en,

 

I ag= reed with the scenario and requirement you mentioned.

 

Howe= ver, I think it is a kind of generic MLN scenario, not just specific to OTN= signaling, so I was trying to capture this in a generic way and documented= this in http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt.

 

Plea= se review this draft (draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt) to see if t= his draft can address your concern.

 

Let= =A1=AFs discuss more on this issue.

 

 

 

Thanks
 
Fatai

 

From: Ben Wright [mailto:Ben.Wright@metaswitch.com]
Sent: 2012=C4=EA2=D4=C27=C8= =D5 1:05
To: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Signaling extensions for FA-LSPs (comment on draft-ietf-cca= mp-gmpls-signaling-g709v3-01)

 

Hi Fatai = et al,

&nbs= p;

We have b= een thinking about function we will need to add to draft-ietf-ccamp-gmpls-s= ignaling-g709v3-01 to fully support automatically provisioned FA-LSPs. = ;  I wanted to see whether you agree with our analysis. 

&nbs= p;

We think = that the RSVP-TE signalling should be extended to carry more information in= order to allow other nodes on the signalling path to set up the correct FA= -LSP.    For example, in the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmp= ls-signaling-g709v3-01#section-7, we believe that N1 should be a= ble to prescribe to N2 the set of hops that it should use to set up the ODU= 2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be u= sed at either end.   Typically, we=A1=AFd expect N1 would want to= explicitly prevent N2 from querying routing to set up the FA-LSP  =A8= C otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1=A1=AFs intentions (e.g.= which could break some SRLG diversity requirement).    &nbs= p; 

&nbs= p;

What do y= ou think?   Is this an issue that you anticipate addressing in th= e text for section 7.1 (alluded to as being for future study)?   =

&nbs= p;

Thanks, <= o:p>

&nbs= p;

Ben Wrigh= t and Steve Balls

&nbs= p;

--Boundary_(ID_kXsp6cxyN7CMW7E3IwRZ5Q)-- From zhang.fei3@zte.com.cn Mon Feb 6 18:33:49 2012 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 5830411E80BB for ; Mon, 6 Feb 2012 18:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.806 X-Spam-Level: X-Spam-Status: No, score=-96.806 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 114omw34xTWn for ; Mon, 6 Feb 2012 18:33:48 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8393811E80BE for ; Mon, 6 Feb 2012 18:33:35 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Tue, 7 Feb 2012 10:06:56 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 83373.984958751; Tue, 7 Feb 2012 10:33:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q172XNFw091721; Tue, 7 Feb 2012 10:33:23 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4F2FF79F.5010004@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: D78E7382:AEEC0EC1-4825799D:000D883E; 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, 7 Feb 2012 10:33:21 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 10:33:24, Serialize complete at 2012-02-07 10:33:24 Content-Type: multipart/alternative; boundary="=_alternative 000E0A9F4825799D_=" X-MAIL: mse01.zte.com.cn q172XNFw091721 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 02:33:49 -0000 This is a multipart message in MIME format. --=_alternative 000E0A9F4825799D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNClBlcmZlY3QhIEkgYWdyZWUgd2l0aCB5b3VyIHBsYW4uDQoNCkJlc3QNCg0KRmVpDQoN Cg0KDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiANCjIwMTItMDItMDYgMjM6NTQNCg0K ytW8/sjLDQp6aGFuZy5mZWkzQHp0ZS5jb20uY24NCrOty80NCiJjY2FtcEBpZXRmLm9yZyIgPGNj YW1wQGlldGYub3JnPg0K1vfM4g0KUmU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2Fy cnkgdGhlIEdsb2JhbF9JRA0KDQoNCg0KDQoNCg0KRmVpLA0KICAgICAgICAgICAgICAgICBTZWUg YmVsb3cuDQoNCk9uIDIvMi8yMDEyIDg6MzcgUE0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3cm90 ZToNCj4gDQo+IExvdQ0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLCBwbGVhc2Ugc2Vl IHRoZSByZXBvbnNlcyBpbi1saW5lIHdpdGgNCj4gPGZlaT48L2ZlaT4gdG8gY2hlY2sgd2hldGhl ciBJIG1ha2UgYSBtaXN0YWtlLg0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBGZWkNCj4gDQo+ IA0KPiAqTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+IA0KPiAyMDEyLTAyLTAyIDIy OjI5DQo+IA0KPiANCj4gytW8/sjLDQo+ICAgICAgICAgICAgICAgIHpoYW5nLmZlaTNAenRlLmNv bS5jbg0KPiCzrcvNDQo+ICAgICAgICAgICAgICAgICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGll dGYub3JnPg0KPiDW98ziDQo+ICAgICAgICAgICAgICAgIFJlOiBbQ0NBTVBdIERpc2N1c3Npb24g b24gaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g DQo+IA0KPiBGZWksDQo+ICAgICAgICAgICAgICAgICBzZWUgYmVsb3cgZm9yIHJlc3BvbnNlcyBp bi1saW5lLg0KPiANCj4gT24gMS8yOS8yMDEyIDQ6NDkgQU0sIHpoYW5nLmZlaTNAenRlLmNvbS5j biB3cm90ZToNCj4+DQo+PiBIaSBDQ0FNUGVycw0KPj4NCj4+IEFzIGRpc2N1c3NlZCBpbiB0aGUg bGFzdCBJRVRGIG1lZXRpbmcgYW5kIG1haWxpbmdsaXN0LCB0aGUgR2xvYmFsX0lEDQo+PiBzaG91 bGQgYmUgY2FycmllZCBpbiB0aGUgc2lnbmFsaW5nIG1lc3NhZ2VzLiBPbmUgcmVhc29uIGlzIHRo YXQgdGhlDQo+PiBqdWRnZW1lbnQgb2YgYSBtaXMtY29ubmVjdGl2aXR5IGRlZmVjdCBuZWVkcyB0 aGUgQTEvWjkgbm9kZXMgdG8NCj4+IHByZS1zdG9yZSBlYWNoIG90aGVyJ3MgTUVQX0lELCB3aG9z ZSBmb3JtYXQgaXM6DQo+PiBHb2JhbF9JRCtOb2RlX0lEK1R1bm5lbF9udW0rTFNQX251bS4NCj4+ DQo+PiBGb3J0dW5hdGVseSwgdGhlcmUgYXJlIHNldmVyYWwgZHJhZnRzIHJlbGF0ZWQgdG8gdGhp cyB0b3BpYyBub3csDQo+Pg0KPj4gMS4gIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAxLg0KPj4gDQo+PiBUaGUgR2xvYmFfSUQgaXMgaW5jb3Jw b3JhdGVkIGludG8gdGhlIEFTU09DSUFUSU9OIG9iamVjdCBpbiB0aGUgY3VycmVudA0KPj4gdmVy c2lvbiwgd2hpY2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBhc3NvY2lhdGlvbiBpcyBnbG9iYWwgdW5p cXVlLiBTaW5jZQ0KPj4gdGhlIEFTU09DSUFUSU9OIG9iamVjdCBpcyB1c2VkIGFjcm9zcyBkaWZm ZXJlbnQgTFNQcywganVzdCBteTJjZW50cywgDQp0aGUNCj4+IGRlZmluZWQgZm9ybWF0IGlzIGRl ZmljaWVudCB0byBoYW5kbGUgbW9yZSBzY2VuYXJpb3MuIEZvciBleGFtcGxlOg0KPj4NCj4+ICAg ICAoMSkgQ29uc2lkZXJpbmcgYSBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgd2hpY2ggaXMg bm90IA0KcHJvdGVjdGVkDQo+PiBieSBvdGhlciBMU1BzIHRocm91Z2ggY29udHJvbCBwbGFuZSBh bmQvb3IgZG9lcyBub3Qgc2hhcmUgdGhlIHNhbWUNCj4+IHJlc291cmVzIHdpdGggb3RoZXIgTFNQ cy4NCj4gDQo+IA0KPj4gSW4gdGhlc2UgY2FzZXMsIHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2ls bA0KPj4gbm90IGJlIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLg0KPiANCj4gV2h5 IG5vdD8gIE9uZSBvZiB0aGUgcHVycG9zZXMgb2YgdGhpcyBkcmFmdCBpcyB0byBzdXBwb3J0IG5v bi1yZWNvdmVyeQ0KPiB1c2VzIG9mIHRoZSBhc3NvY2lhdGlvbiBvYmplY3QuICBOb3RlIHRoZSBu YW1lIG9mIHNlY3Rpb24gMi4NCj4gDQo+IDxGZWk+DQo+IA0KPiBBY2NvcmRpbmcgdG8gbXkgdW5k ZXJzdGFuZGluZywgdGhlIGFzc29jaWF0aW9uIG9iamVjdCBpcyB1c2VkIHRvDQo+IGFzc29jaWF0 ZSBkaWZmZXJlbnQgTFNQcy4gDQoNCkkgYWdyZWUgdGhhdCB0aGlzIGlzIHRoZSBvcmlnaW5hbCBt b3RpdmF0aW9uIGZvciB0aGUgYXNzb2NpYXRpb24gb2JqZWN0Lg0KIEJ1dCBpZiB0aGUgbmVlZCBp bmZvcm1hdGlvbiBpcyBhbHJlYWR5IGRlZmluZWQgZm9yIHRoaXMgb2JqZWN0LCB3aHkNCmRlZmlu ZSBhbm90aGVyIG9iamVjdCB0aGF0IGNhcnJpZXMgdGhlIHNhbWUgaW5mb3JtYXRpb24uICBXZSBj ZXJ0YWlubHkNCmNhbiBhZGQgc29tZSB0ZXh0IHRvIHRoZSBkcmFmdCB0byBoaWdobGlnaHQgdGhp cyBwb3NzaWJpbGl0eS4NCg0KPiBTZWUgdGhlIGRlc2NyaXB0aW9ucyBpbiBzZWN0aW9uIDI6DQo+ ICJBcyBkZXNjcmliZWQgYmVsb3csYXNzb2NpYXRpb24gaXMgYWx3YXlzIGRvbmUgYmFzZWQgb24g bWF0Y2hpbmcNCj4gZWl0aGVyIFBhdGggc3RhdGUgdG8gUGF0aCBzdGF0ZSwgb3IgUmVzdiBzdGF0 ZSB0byBSZXN2IHN0YXRlIg0KPiANCj4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBzY2VuYWlyb3M6 DQo+IA0KPiAgICAgICAgICAgICAgICBMU1AxDQo+IEEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tWg0KPiANCj4gTm9kZSBBIGlzIGxvY2F0ZWQgaW4gQVMxIGFuZCBu b2RlIFogaXMgbG9jYXRlZCBpbiBBUzIsIHdoZW4gdGhlIFBhdGgNCj4gbWVzc2FnZSBmb3IgTFNQ MSAoY28tcm91dGVkIGJpZGlyZWN0aW5hbCBMU1ApIHdpdGggRXh0ZW5kZWQgQXNzb2NpYXRpb24N Cj4gT2JqZWN0IGluc2VydGVkIGlzIGluaXRpYXRlZCBhdCBub2RlIEEsIHRocmVlIGlzc3VlczoN Cj4gDQo+IEkxOiB3aGF0IGtpbmQgb2YgYXNzb2NpYXRpb24gdHlwZSBpcyB1c2VkIGhlcmU/DQoN CnRoZSBzYW1lIGFzIHlvdSdkIHVzZSBpbiBhbiBhc3NvY2lhdGVkIGJ5IGRpcmVjdGlvbmFsLiBQ ZXIgeW91ciBkcmFmdA0KdGhpcyBpcyB0eXBlIDQuICBZb3VyIGRyYWZ0IGNhbiBtYWtlIHRoaXMg Y2xlYXI7IHBlcmhhcHMgYnkgcmVuYW1pbmcgdGhlDQp0eXBlIHRvIHNvbWV0aGluZyBhbG9uZyB0 aGUgbGluZXMgb2YgIkxTUCBpZGVudGlmaWNhdGlvbiIsIGFuZA0KZXhwbGljaXRseSBjb3Zlcmlu ZyB0aGlzIGNhc2UuDQoNCj4gDQo+IEkyOiBhc3NvY2lhdGlvbiBvYmplY3QgaXMgdXNlZCBhY3Jv c3MgZGlmZmVyZW50IHBhdGggc3RhdGVzLCBidXQgTFNQMQ0KPiBpcyBub3QgYXNzb2NpYXRlZCB3 aXRoIGFueSBvdGhlciBMU1BTIGluIHRoaXMgY2FzZS4NCg0KU3RyY2lrbHkgc3BlYWtpbmcsIGZv ciBjby1yb3V0ZWQgTFNQcyB0aGUgYXNzb2NpYXRpb24gaXMgcGVyIHN0YW5kYXJkDQpSU1ZQIGFu ZCB0aGUgYXNzb2NpYXRpb24gb2JqZWN0IGlzIGp1c3QgY2FycnlpbmcgdGhlIExTUCBpZGVudGlm aWNhdGlvbg0KaW5mb3JtYXRpb24uDQoNCj4gDQo+IEkzOiBOb2RlIEEgc3RpbGwgZG9lcyBrbm93 IHRoZSBnbG9iYWwgSUQgb2Ygbm9kZSBaDQo+IA0KDQpSaWdodCwgdGhhdCBoYXMgYWx3YXlzIGNv bWUgaW4gdGhlIHJlc3YuDQoNCj4gSWYgdGhlc2UgaXNzdWVzIGFyZSByZWFsbHkgZXhpc3RlZCwg dGhlIGN1cnJlbnQgdXNhZ2Ugb2YgYXNzb2NpYXRpb24gDQpvYmplY3QNCj4gc2hvdWxkIGJlIHJl dmlzZWQsIGZvciBleGFtcGxlLCBsaWtlIHRoaXM6DQo+IA0KPiBSMTogSXQgY2FuIGJlIHVzZWQg bm90IHRvIG1hdGggcGF0aCBzdGF0ZSwgaW4gb3RoZXIgd29yZHMsIGl0IGNhbiBhcHBlYXINCj4g b25seQ0KPiBpbiBvbmUgTFNQJ3MgcGF0aCBtZXNzYWdlIChubyBuZWVkIHRvIGJlIHBhaXIpDQo+ IA0KDQpJIHRoaW5rIHRoaXMgaXMgYWxsb3dlZCwgYnV0IGNlcnRhaW5seSBhZGRpbmcgYSBmZXcg d29yZHMgdG8gYXNzb2MtZXh0DQp0byBtYWtlIHRoaXMgZXhwbGljaXQgaXMgZmluZS4NCg0KPiBS MjogSXQgY2FuIGJlIHVzZWQgYWNyb3NzIFBhdGggYW5kIFJFU1Ygc3RhdGUsIGluIHRoaXMgd2F5 LCBhbg0KPiBhc3NvY2lhdGlvbiBvYmplY3QNCj4gY2FuIGJlIGluc2VydGVkIGF0IG5vZGUgWiBp biB0aGUgUkVTViBtZXNzYWdlLCB3aXRoIHRoZSBnbG9iYWwgSUQgb2YgDQpub2RlIFoNCj4gDQoN CkFnYWluLCBpbiB0aGUgc2luZ2xlIExTUCBjYXNlLCBhc3NvY2lhdGlvbiBpcyBiZWluZyBtYWRl IHBlciBzdGFuZGFyZCANClJTVlAuDQoNCj4gUjM6IElmIGlzc3VlIDIgaXMgYWdyZWVlZCwgYSBu ZXcgYXNzb2NpYXRpb24gdHlwZSBuZWVkcyB0byBiZSBkZWZpbmVkIA0KaGVyZT8NCj4gDQpBbHRl cm5hdGl2ZWx5LCBqdXN0IGV4cGFuZCB0aGUgc2NvcGUvbmFtZSBvZiB0eXBlIDQgaW4geW91ciBk cmFmdC4NCg0KTG91DQoNCj4gPC9GZWk+DQo+IA0KPiANCj4+DQo+PiAgICAgKDIpIENvbnNpZGVy aW5nIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIGFsdGhvdWdoIHRoZQ0KPj4gQVNT T0NJQVRJT04gb2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLCB0aGUg Z2xvYmFsX0lEDQo+PiBpbmNvcnBvcmF0ZWQgaW4gdGhlIEFTU09DSUFUSU9OIG9iamVjdCBvbmx5 DQo+PiBpbmRpY2F0ZXMgdGhlIGdsb2JhbCBwcmVmaXggb2YgdGhlIEExIG9yIFo5IG5vZGVzLiBJ ZiB0aGlzIExTUCBpcyANCmFjcm9zcw0KPj4gZGlmZmVyZW50IGRvbWFpbnMsIEkgdGhpbmsgdGhl IGN1cnJlbnQgZm9ybWF0IGlzIGFsc28gZGVmaWNpZW50IChBMSANCmRvZXMNCj4+IG5vdCBrbm93 IHRoZSBnb2JhbCBJRCBvZiBaOSBub2RlIG9yIFo5IG5vZGVzIGRvZXMgbm90IGtub3cgdGhlIGds b2JhbCANCklEDQo+PiBvZiBBMSApLg0KPiANCj4gSXQncyBub3QgY2xlYXIgdG8gbWUgd2hhdCBw cm9ibGVtIHlvdSdyZSB0cnlpbmcgdG8gc29sdmUuICBDYW4geW91DQo+IHJlcGhyYXNlPw0KPiAN Cj4gPGZlaT4NCj4gDQo+IFNpbWlsYXJseSB3aXRoIHRoZSBpc3N1ZSAyIHByb3ZpZGVkIGFib3Zl LCB3aGVuIExTUDEgYW5kIExTUDIgYXJlIGJvdW5kDQo+IHRvZ2V0aGVyDQo+IHRvIGJlIGFuIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHRoZSBnbG9iYWwgSUQgY2FycmllZCBpbiB0aGUN Cj4gTFNQMSdzIGFuZA0KPiBMU1AyJ3MgUGF0aCBtZXNzYWdlcyBhcmUgbm9kZSBBJ3Mgb3Igbm9k ZSBaJ3MsIGlmIGl0IGlzIHRoZSBnbG9iYWwgSUQgb2YNCj4gbm9kZSBBLA0KPiBub2RlIEEgc3Rp bGwgZG9lcyBrbm93IHRoZSBnbG9iYWwgSUQgb2Ygbm9kZSBaLg0KPiANCj4gICAgICAgICAgICAg ICAgTFNQMQ0KPiBBLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVoN Cj4gICAgICAgICAgICAgICAgTFNQMg0KPiBIb3BlIEkgY2xhcmlmeSBpdCBjbGVhcmx5LiAgOikN Cj4gDQo+IDwvZmVpPg0KPiANCj4gDQo+IEFsc28ga2VlcCBpbiBtaW5kIHRoYXQgbXVsdGlwbGUg YXNzb2NpYXRpb24gb2JqZWN0cyBoYXZlIGFsd2F5cyBiZWVuDQo+IHN1cHBvcnRlZCBhbmQgdGhp cyBhYmlsaXR5IGlzIG5vdCBtb2RpZmllZCBieSB0aGUgZHJhZnQuDQo+IA0KPiA8ZmVpPg0KPiBJ IGFncmVlDQo+IDwvZmVpPg0KPiANCj4+DQo+PiAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMtdHAtb2lvLTAxDQo+Pg0KPj4gVGhlIEdsb2JhbF9JRCBP YmplY3QgYW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0IGFyZSBkZWZpbmVkIGluIHRoaXMN Cj4+IGRyYWZ0LCAgd2hpY2ggZGVzY3JpYmVzIHRoZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlk aXJlY3Rpb25hbCBMU1ANCj4+IChhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBj b3ZlcmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24pIA0KYW5kDQo+PiByZXF1aXJlcyB0aGF0IHRo ZSBzYW1lIGZvcm1hdCggR2xvYmFsX0lEIG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkDQo+PiBh bG9uZyB0aGUgTFNQLg0KPiANCj4gWWVzLiAgVGhpcyB3YXMgZGlzY3Vzc2VkIGF0IHRoZSBsYXN0 IElFVEYuICBUaGUgV0cgcHJldmlvdXNseSBoYWQgYQ0KPiBzb2x1dGlvbiB0byB0aGlzIGJhc2Vk IG9uIHRoZSBhc3NvY2lhdGlvbiBvYmplY3QsIHNlZSByZXYgMDAgb2YgdGhlIFdHDQo+IGRvY3Vt ZW50LiAgSSByZW1vdmVkIGl0IGZyb20gdGhlIGRvY3VtZW50IGJhc2VkIG9uIGRpc2N1c3Npb24g aW4gUXVlYmVjLg0KPiBBcyBkaXNjdXNzZWQgaW4gVGFpcGVpIHRoZSBjdXJyZW50IHJldiBjYW4g c3RpbGwgYmUgdXNlZCB0byBjYXJyeSB0aGUNCj4gSVRVLVQgaWRlbnRpZmllcnMgKHllcywgdGhl IHBhcnRzIHRoYXQgd2VyZSBpbiAtMDAgbmVlZCB0byBiZSBzZXBhcmF0ZWx5DQo+IHB1Ymxpc2hl ZCB0byBkb2N1bWVudCB0aGlzLikNCj4gDQo+IDxmZWk+DQo+IEkgYWdyZWUsIG5vIHByb2JsZW0g aGVyZQ0KPiA8L2ZlaT4NCj4gDQo+Pg0KPj4gMy4NCj4+DQo+IA0KaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0t MDENCg0KPj4NCj4+IA0KPj4gVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFzIGEgVExWIG9mIHRo ZSBMU1BfQVRUUklCVVRFIG9iamVjdCwgd2hpY2gNCj4+IHdpbGwgYXBwZWFyIGluIHRoZSBQYXRo L1Jlc3YgbWVzc2FnZSBvZiBjb3JvdXRlZCBiaWRyZWN0aW9uYWwgTFNQIGFuZA0KPj4gb25seSBh cHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQ Lg0KPj4gRnVydGhlcm1vcmUsIHRoaXMgZHJhZnQgZGVmaW5lZCBhIENvbm5lY3Rpb24gVExWIHVz ZWQgdG8gY2FycnkgdGhlIA0KbG9jYWwNCj4+IHR1bm5lbCBudW1iZXIgYXNzaWduZWQgYXQgWjkg bm9kZXMgaW4gdGhlIHNjZW5hcmlvIG9mIGNvcm91dGVkDQo+PiBiaWRpcmVjdGlvbmFsIExTUC4N Cj4gDQo+IElzIHRoZXJlIGEgcXVlc3Rpb24gaGVyZT8NCj4gDQo+IDxmZWk+DQo+IA0KPiBJZiB3 aGF0IEkgZGVzY3JpYmVkIGluIHBhcnQgMSBpcyByZWFzb25hYmxlLCBhbmQgdGhlIHVzYWdlIG9m IA0KYXNzb2NpYXRpb24NCj4gb2JqZWN0IGNhbiBiZSBtb2RpZmllZCB0byBjb3ZlciB0aGVzZSBp c3N1ZXMsIHRoZXJlIGFyZSBubyBwcm9ibGVtIGhlcmUNCj4gYWxzby4NCj4gDQo+IDwvZmVpPg0K PiANCj4gTG91IChhcyBjb250cmlidXRvcikNCj4gDQo+Pg0KPj4NCj4+IFRoZSBhYm92ZSBtYXRl cmlhbHMgb25seSBwcm92aWRlIHRoZSByb3VnaCBiYWNrZ3JvdW5kLg0KPj4NCj4+DQo+PiBIb3Bl IHRvIGhlYXIgdGhlIG9waW5pb25zIGZyb20gdGhlIFdHIHRoYXQgaG93IHRvIGNhcnJ5IHRoZSBH bG9iYWxfSUQsDQo+PiB0aGVuIG1vdmUgdGhlIHdvcmsgZm9yd2FyZC4NCj4+DQo+Pg0KPj4gQmVz dCByZWdhcmRzDQo+Pg0KPj4gOykNCj4+DQo+PiBGZWkNCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5n IGxpc3QNCj4+IENDQU1QQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NjYW1wDQo+IA0KPiANCg0KDQoNCg== --=_alternative 000E0A9F4825799D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UGVyZmVjdCEgSSBhZ3JlZSB3aXRoIHlv dXIgcGxhbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkJlc3Q8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZl aTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5M b3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTAyLTA2IDIzOjU0PC9mb250Pg0KPHRkIHdp ZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYW5nLmZlaTNAenRl LmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsgJmx0 O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gRGlzY3Vz c2lvbiBvbiBob3cgdG8gY2FycnkNCnRoZSBHbG9iYWxfSUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4N Cjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJs ZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZlaSw8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KU2VlIGJlbG93 Ljxicj4NCjxicj4NCk9uIDIvMi8yMDEyIDg6MzcgUE0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3 cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgTG91PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5r cyBmb3IgeW91ciByZXNwb25zZSwgcGxlYXNlIHNlZSB0aGUgcmVwb25zZXMgaW4tbGluZSB3aXRo PGJyPg0KJmd0OyAmbHQ7ZmVpJmd0OyZsdDsvZmVpJmd0OyB0byBjaGVjayB3aGV0aGVyIEkgbWFr ZSBhIG1pc3Rha2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkczxicj4NCiZndDsg PGJyPg0KJmd0OyBGZWk8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqTG91IEJlcmdl ciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDsqPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIwMTItMDIt MDIgMjI6Mjk8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IMrVvP7Iyzxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt6aGFuZy5mZWkzQHp0ZS5jb20uY248YnI+DQomZ3Q7ILOty808YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JnF1b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsNCiZsdDtjY2FtcEBpZXRmLm9yZyZndDs8 YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmU6DQpbQ0NBTVBdIERpc2N1c3Npb24gb24g aG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEZlaSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VlIGJlbG93DQpmb3IgcmVzcG9uc2VzIGlu LWxpbmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDEvMjkvMjAxMiA0OjQ5IEFNLCB6aGFuZy5m ZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBIaSBDQ0FN UGVyczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0 IElFVEYgbWVldGluZyBhbmQgbWFpbGluZ2xpc3QsIHRoZSBHbG9iYWxfSUQ8YnI+DQomZ3Q7Jmd0 OyBzaG91bGQgYmUgY2FycmllZCBpbiB0aGUgc2lnbmFsaW5nIG1lc3NhZ2VzLiBPbmUgcmVhc29u IGlzIHRoYXQNCnRoZTxicj4NCiZndDsmZ3Q7IGp1ZGdlbWVudCBvZiBhIG1pcy1jb25uZWN0aXZp dHkgZGVmZWN0IG5lZWRzIHRoZSBBMS9aOSBub2RlcyB0bzxicj4NCiZndDsmZ3Q7IHByZS1zdG9y ZSBlYWNoIG90aGVyJ3MgTUVQX0lELCB3aG9zZSBmb3JtYXQgaXM6PGJyPg0KJmd0OyZndDsgR29i YWxfSUQrTm9kZV9JRCtUdW5uZWxfbnVtK0xTUF9udW0uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBGb3J0dW5hdGVseSwgdGhlcmUgYXJlIHNldmVyYWwgZHJhZnRzIHJlbGF0ZWQgdG8gdGhp cyB0b3BpYyBub3csPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAxLiAmbmJzcDtodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wMS48YnI+DQom Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyZndDsgVGhlIEdsb2JhX0lEIGlzIGluY29y cG9yYXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaW4gdGhlDQpjdXJyZW50PGJyPg0K Jmd0OyZndDsgdmVyc2lvbiwgd2hpY2ggZ3VhcmFudGVlcyB0aGF0IHRoZSBhc3NvY2lhdGlvbiBp cyBnbG9iYWwgdW5pcXVlLg0KU2luY2U8YnI+DQomZ3Q7Jmd0OyB0aGUgQVNTT0NJQVRJT04gb2Jq ZWN0IGlzIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBMU1BzLCBqdXN0IG15MmNlbnRzLA0KdGhlPGJy Pg0KJmd0OyZndDsgZGVmaW5lZCBmb3JtYXQgaXMgZGVmaWNpZW50IHRvIGhhbmRsZSBtb3JlIHNj ZW5hcmlvcy4gRm9yIGV4YW1wbGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7ICgxKSBDb25zaWRlcmluZyBhIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB3aGlj aA0KaXMgbm90IHByb3RlY3RlZDxicj4NCiZndDsmZ3Q7IGJ5IG90aGVyIExTUHMgdGhyb3VnaCBj b250cm9sIHBsYW5lIGFuZC9vciBkb2VzIG5vdCBzaGFyZSB0aGUNCnNhbWU8YnI+DQomZ3Q7Jmd0 OyByZXNvdXJlcyB3aXRoIG90aGVyIExTUHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsmZ3Q7IEluIHRoZXNlIGNhc2VzLCB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IHdpbGw8YnI+DQom Z3Q7Jmd0OyBub3QgYmUgY2FycmllZCBpbiB0aGUgc2lnYWxpbmcgbWVzc2FnZXMuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFdoeSBub3Q/ICZuYnNwO09uZSBvZiB0aGUgcHVycG9zZXMgb2YgdGhpcyBk cmFmdCBpcyB0byBzdXBwb3J0IG5vbi1yZWNvdmVyeTxicj4NCiZndDsgdXNlcyBvZiB0aGUgYXNz b2NpYXRpb24gb2JqZWN0LiAmbmJzcDtOb3RlIHRoZSBuYW1lIG9mIHNlY3Rpb24gMi48YnI+DQom Z3Q7IDxicj4NCiZndDsgJmx0O0ZlaSZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWNjb3JkaW5n IHRvIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBhc3NvY2lhdGlvbiBvYmplY3QgaXMgdXNlZCB0bzxi cj4NCiZndDsgYXNzb2NpYXRlIGRpZmZlcmVudCBMU1BzLiA8YnI+DQo8YnI+DQpJIGFncmVlIHRo YXQgdGhpcyBpcyB0aGUgb3JpZ2luYWwgbW90aXZhdGlvbiBmb3IgdGhlIGFzc29jaWF0aW9uIG9i amVjdC48YnI+DQogQnV0IGlmIHRoZSBuZWVkIGluZm9ybWF0aW9uIGlzIGFscmVhZHkgZGVmaW5l ZCBmb3IgdGhpcyBvYmplY3QsIHdoeTxicj4NCmRlZmluZSBhbm90aGVyIG9iamVjdCB0aGF0IGNh cnJpZXMgdGhlIHNhbWUgaW5mb3JtYXRpb24uICZuYnNwO1dlIGNlcnRhaW5seTxicj4NCmNhbiBh ZGQgc29tZSB0ZXh0IHRvIHRoZSBkcmFmdCB0byBoaWdobGlnaHQgdGhpcyBwb3NzaWJpbGl0eS48 YnI+DQo8YnI+DQomZ3Q7IFNlZSB0aGUgZGVzY3JpcHRpb25zIGluIHNlY3Rpb24gMjo8YnI+DQom Z3Q7ICZxdW90O0FzIGRlc2NyaWJlZCBiZWxvdyxhc3NvY2lhdGlvbiBpcyBhbHdheXMgZG9uZSBi YXNlZCBvbiBtYXRjaGluZzxicj4NCiZndDsgZWl0aGVyIFBhdGggc3RhdGUgdG8gUGF0aCBzdGF0 ZSwgb3IgUmVzdiBzdGF0ZSB0byBSZXN2IHN0YXRlJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgc2NlbmFpcm9zOjxicj4NCiZndDsgPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TFNQ MTxicj4NCiZndDsgQS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1a PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vZGUgQSBpcyBsb2NhdGVkIGluIEFTMSBhbmQgbm9kZSBa IGlzIGxvY2F0ZWQgaW4gQVMyLCB3aGVuIHRoZSBQYXRoPGJyPg0KJmd0OyBtZXNzYWdlIGZvciBM U1AxIChjby1yb3V0ZWQgYmlkaXJlY3RpbmFsIExTUCkgd2l0aCBFeHRlbmRlZCBBc3NvY2lhdGlv bjxicj4NCiZndDsgT2JqZWN0IGluc2VydGVkIGlzIGluaXRpYXRlZCBhdCBub2RlIEEsIHRocmVl IGlzc3Vlczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSTE6IHdoYXQga2luZCBvZiBhc3NvY2lhdGlv biB0eXBlIGlzIHVzZWQgaGVyZT88YnI+DQo8YnI+DQp0aGUgc2FtZSBhcyB5b3UnZCB1c2UgaW4g YW4gYXNzb2NpYXRlZCBieSBkaXJlY3Rpb25hbC4gUGVyIHlvdXIgZHJhZnQ8YnI+DQp0aGlzIGlz IHR5cGUgNC4gJm5ic3A7WW91ciBkcmFmdCBjYW4gbWFrZSB0aGlzIGNsZWFyOyBwZXJoYXBzIGJ5 IHJlbmFtaW5nDQp0aGU8YnI+DQp0eXBlIHRvIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Yg JnF1b3Q7TFNQIGlkZW50aWZpY2F0aW9uJnF1b3Q7LCBhbmQ8YnI+DQpleHBsaWNpdGx5IGNvdmVy aW5nIHRoaXMgY2FzZS48YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSTI6IGFzc29jaWF0aW9u IG9iamVjdCBpcyB1c2VkIGFjcm9zcyBkaWZmZXJlbnQgcGF0aCBzdGF0ZXMsIGJ1dCBMU1AxPGJy Pg0KJmd0OyBpcyBub3QgYXNzb2NpYXRlZCB3aXRoIGFueSBvdGhlciBMU1BTIGluIHRoaXMgY2Fz ZS48YnI+DQo8YnI+DQpTdHJjaWtseSBzcGVha2luZywgZm9yIGNvLXJvdXRlZCBMU1BzIHRoZSBh c3NvY2lhdGlvbiBpcyBwZXIgc3RhbmRhcmQ8YnI+DQpSU1ZQIGFuZCB0aGUgYXNzb2NpYXRpb24g b2JqZWN0IGlzIGp1c3QgY2FycnlpbmcgdGhlIExTUCBpZGVudGlmaWNhdGlvbjxicj4NCmluZm9y bWF0aW9uLjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBJMzogTm9kZSBBIHN0aWxsIGRvZXMg a25vdyB0aGUgZ2xvYmFsIElEIG9mIG5vZGUgWjxicj4NCiZndDsgPGJyPg0KPGJyPg0KUmlnaHQs IHRoYXQgaGFzIGFsd2F5cyBjb21lIGluIHRoZSByZXN2Ljxicj4NCjxicj4NCiZndDsgSWYgdGhl c2UgaXNzdWVzIGFyZSByZWFsbHkgZXhpc3RlZCwgdGhlIGN1cnJlbnQgdXNhZ2Ugb2YgYXNzb2Np YXRpb24NCm9iamVjdDxicj4NCiZndDsgc2hvdWxkIGJlIHJldmlzZWQsIGZvciBleGFtcGxlLCBs aWtlIHRoaXM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFIxOiBJdCBjYW4gYmUgdXNlZCBub3QgdG8g bWF0aCBwYXRoIHN0YXRlLCBpbiBvdGhlciB3b3JkcywgaXQgY2FuDQphcHBlYXI8YnI+DQomZ3Q7 IG9ubHk8YnI+DQomZ3Q7IGluIG9uZSBMU1AncyBwYXRoIG1lc3NhZ2UgKG5vIG5lZWQgdG8gYmUg cGFpcik8YnI+DQomZ3Q7IDxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBpcyBhbGxvd2VkLCBidXQg Y2VydGFpbmx5IGFkZGluZyBhIGZldyB3b3JkcyB0byBhc3NvYy1leHQ8YnI+DQp0byBtYWtlIHRo aXMgZXhwbGljaXQgaXMgZmluZS48YnI+DQo8YnI+DQomZ3Q7IFIyOiBJdCBjYW4gYmUgdXNlZCBh Y3Jvc3MgUGF0aCBhbmQgUkVTViBzdGF0ZSwgaW4gdGhpcyB3YXksIGFuPGJyPg0KJmd0OyBhc3Nv Y2lhdGlvbiBvYmplY3Q8YnI+DQomZ3Q7IGNhbiBiZSBpbnNlcnRlZCBhdCBub2RlIFogaW4gdGhl IFJFU1YgbWVzc2FnZSwgd2l0aCB0aGUgZ2xvYmFsIElEDQpvZiBub2RlIFo8YnI+DQomZ3Q7IDxi cj4NCjxicj4NCkFnYWluLCBpbiB0aGUgc2luZ2xlIExTUCBjYXNlLCBhc3NvY2lhdGlvbiBpcyBi ZWluZyBtYWRlIHBlciBzdGFuZGFyZCBSU1ZQLjxicj4NCjxicj4NCiZndDsgUjM6IElmIGlzc3Vl IDIgaXMgYWdyZWVlZCwgYSBuZXcgYXNzb2NpYXRpb24gdHlwZSBuZWVkcyB0byBiZSBkZWZpbmVk DQpoZXJlPzxicj4NCiZndDsgPGJyPg0KQWx0ZXJuYXRpdmVseSwganVzdCBleHBhbmQgdGhlIHNj b3BlL25hbWUgb2YgdHlwZSA0IGluIHlvdXIgZHJhZnQuPGJyPg0KPGJyPg0KTG91PGJyPg0KPGJy Pg0KJmd0OyAmbHQ7L0ZlaSZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICgyKSBDb25zaWRlcmluZyBhbiBhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLA0KYWx0aG91Z2ggdGhlPGJyPg0KJmd0OyZndDsgQVNT T0NJQVRJT04gb2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLCB0aGUg Z2xvYmFsX0lEPGJyPg0KJmd0OyZndDsgaW5jb3Jwb3JhdGVkIGluIHRoZSBBU1NPQ0lBVElPTiBv YmplY3Qgb25seTxicj4NCiZndDsmZ3Q7IGluZGljYXRlcyB0aGUgZ2xvYmFsIHByZWZpeCBvZiB0 aGUgQTEgb3IgWjkgbm9kZXMuIElmIHRoaXMgTFNQDQppcyBhY3Jvc3M8YnI+DQomZ3Q7Jmd0OyBk aWZmZXJlbnQgZG9tYWlucywgSSB0aGluayB0aGUgY3VycmVudCBmb3JtYXQgaXMgYWxzbyBkZWZp Y2llbnQNCihBMSBkb2VzPGJyPg0KJmd0OyZndDsgbm90IGtub3cgdGhlIGdvYmFsIElEIG9mIFo5 IG5vZGUgb3IgWjkgbm9kZXMgZG9lcyBub3Qga25vdyB0aGUNCmdsb2JhbCBJRDxicj4NCiZndDsm Z3Q7IG9mIEExICkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0J3Mgbm90IGNsZWFyIHRvIG1lIHdo YXQgcHJvYmxlbSB5b3UncmUgdHJ5aW5nIHRvIHNvbHZlLiAmbmJzcDtDYW4NCnlvdTxicj4NCiZn dDsgcmVwaHJhc2U/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZsdDtmZWkmZ3Q7PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFNpbWlsYXJseSB3aXRoIHRoZSBpc3N1ZSAyIHByb3ZpZGVkIGFib3ZlLCB3aGVu IExTUDEgYW5kIExTUDIgYXJlDQpib3VuZDxicj4NCiZndDsgdG9nZXRoZXI8YnI+DQomZ3Q7IHRv IGJlIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHRoZSBnbG9iYWwgSUQgY2Fycmll ZCBpbiB0aGU8YnI+DQomZ3Q7IExTUDEncyBhbmQ8YnI+DQomZ3Q7IExTUDIncyBQYXRoIG1lc3Nh Z2VzIGFyZSBub2RlIEEncyBvciBub2RlIFoncywgaWYgaXQgaXMgdGhlIGdsb2JhbA0KSUQgb2Y8 YnI+DQomZ3Q7IG5vZGUgQSw8YnI+DQomZ3Q7IG5vZGUgQSBzdGlsbCBkb2VzIGtub3cgdGhlIGds b2JhbCBJRCBvZiBub2RlIFouPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtMU1AxPGJyPg0KJmd0OyBBLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVo8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtMU1AyPGJy Pg0KJmd0OyBIb3BlIEkgY2xhcmlmeSBpdCBjbGVhcmx5LiAmbmJzcDs6KTxicj4NCiZndDsgPGJy Pg0KJmd0OyAmbHQ7L2ZlaSZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbHNv IGtlZXAgaW4gbWluZCB0aGF0IG11bHRpcGxlIGFzc29jaWF0aW9uIG9iamVjdHMgaGF2ZSBhbHdh eXMgYmVlbjxicj4NCiZndDsgc3VwcG9ydGVkIGFuZCB0aGlzIGFiaWxpdHkgaXMgbm90IG1vZGlm aWVkIGJ5IHRoZSBkcmFmdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmx0O2ZlaSZndDs8YnI+DQom Z3Q7IEkgYWdyZWU8YnI+DQomZ3Q7ICZsdDsvZmVpJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVu LWNjYW1wLW1wbHMtdHAtb2lvLTAxPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgR2xv YmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19PcGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQN CmluIHRoaXM8YnI+DQomZ3Q7Jmd0OyBkcmFmdCwgJm5ic3A7d2hpY2ggZGVzY3JpYmVzIHRoZSBw cm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbA0KTFNQPGJyPg0KJmd0OyZndDsgKGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgaXMgbm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQg dmVyc2lvbikNCmFuZDxicj4NCiZndDsmZ3Q7IHJlcXVpcmVzIHRoYXQgdGhlIHNhbWUgZm9ybWF0 KCBHbG9iYWxfSUQgb3IgSUNDX09wZXJhdG9yX0lEKWlzDQp1c2VkPGJyPg0KJmd0OyZndDsgYWxv bmcgdGhlIExTUC48YnI+DQomZ3Q7IDxicj4NCiZndDsgWWVzLiAmbmJzcDtUaGlzIHdhcyBkaXNj dXNzZWQgYXQgdGhlIGxhc3QgSUVURi4gJm5ic3A7VGhlIFdHIHByZXZpb3VzbHkNCmhhZCBhPGJy Pg0KJmd0OyBzb2x1dGlvbiB0byB0aGlzIGJhc2VkIG9uIHRoZSBhc3NvY2lhdGlvbiBvYmplY3Qs IHNlZSByZXYgMDAgb2YgdGhlDQpXRzxicj4NCiZndDsgZG9jdW1lbnQuICZuYnNwO0kgcmVtb3Zl ZCBpdCBmcm9tIHRoZSBkb2N1bWVudCBiYXNlZCBvbiBkaXNjdXNzaW9uDQppbiBRdWViZWMuPGJy Pg0KJmd0OyBBcyBkaXNjdXNzZWQgaW4gVGFpcGVpIHRoZSBjdXJyZW50IHJldiBjYW4gc3RpbGwg YmUgdXNlZCB0byBjYXJyeQ0KdGhlPGJyPg0KJmd0OyBJVFUtVCBpZGVudGlmaWVycyAoeWVzLCB0 aGUgcGFydHMgdGhhdCB3ZXJlIGluIC0wMCBuZWVkIHRvIGJlIHNlcGFyYXRlbHk8YnI+DQomZ3Q7 IHB1Ymxpc2hlZCB0byBkb2N1bWVudCB0aGlzLik8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmx0O2Zl aSZndDs8YnI+DQomZ3Q7IEkgYWdyZWUsIG5vIHByb2JsZW0gaGVyZTxicj4NCiZndDsgJmx0Oy9m ZWkmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDMuPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNj YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAmbmJzcDs8YnI+DQomZ3Q7Jmd0OyBUaGUgR2xvYmFsX0lEIGlzIGNhcnJpZWQgYXMg YSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LA0Kd2hpY2g8YnI+DQomZ3Q7Jmd0OyB3 aWxsIGFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlv bmFsDQpMU1AgYW5kPGJyPg0KJmd0OyZndDsgb25seSBhcHBlYXIgaW4gdGhlIFBhdGggbWVzc2Fn ZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLjxicj4NCiZndDsmZ3Q7IEZ1cnRoZXJt b3JlLCB0aGlzIGRyYWZ0IGRlZmluZWQgYSBDb25uZWN0aW9uIFRMViB1c2VkIHRvIGNhcnJ5DQp0 aGUgbG9jYWw8YnI+DQomZ3Q7Jmd0OyB0dW5uZWwgbnVtYmVyIGFzc2lnbmVkIGF0IFo5IG5vZGVz IGluIHRoZSBzY2VuYXJpbyBvZiBjb3JvdXRlZDxicj4NCiZndDsmZ3Q7IGJpZGlyZWN0aW9uYWwg TFNQLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJcyB0aGVyZSBhIHF1ZXN0aW9uIGhlcmU/PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZsdDtmZWkmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHdoYXQg SSBkZXNjcmliZWQgaW4gcGFydCAxIGlzIHJlYXNvbmFibGUsIGFuZCB0aGUgdXNhZ2Ugb2YgYXNz b2NpYXRpb248YnI+DQomZ3Q7IG9iamVjdCBjYW4gYmUgbW9kaWZpZWQgdG8gY292ZXIgdGhlc2Ug aXNzdWVzLCB0aGVyZSBhcmUgbm8gcHJvYmxlbQ0KaGVyZTxicj4NCiZndDsgYWxzby48YnI+DQom Z3Q7IDxicj4NCiZndDsgJmx0Oy9mZWkmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExvdSAoYXMg Y29udHJpYnV0b3IpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgVGhlIGFib3ZlIG1hdGVyaWFscyBvbmx5IHByb3ZpZGUgdGhlIHJvdWdoIGJhY2tn cm91bmQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhvcGUgdG8g aGVhciB0aGUgb3BpbmlvbnMgZnJvbSB0aGUgV0cgdGhhdCBob3cgdG8gY2FycnkgdGhlIEdsb2Jh bF9JRCw8YnI+DQomZ3Q7Jmd0OyB0aGVuIG1vdmUgdGhlIHdvcmsgZm9yd2FyZC48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQmVzdCByZWdhcmRzPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyA7KTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRmVpPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBD Q0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsm Z3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 000E0A9F4825799D_=-- From vero.zheng@huawei.com Mon Feb 6 23:34:30 2012 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 C238421F8778 for ; Mon, 6 Feb 2012 23:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 EpJfIAeBwYR1 for ; Mon, 6 Feb 2012 23:34:27 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 06BD121F876C for ; Mon, 6 Feb 2012 23:34:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ0004N3IBCID@szxga04-in.huawei.com> for ccamp@ietf.org; Tue, 07 Feb 2012 15:33:12 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ0003HMIBB1U@szxga04-in.huawei.com> for ccamp@ietf.org; Tue, 07 Feb 2012 15:33:12 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGW99114; Tue, 07 Feb 2012 15:33:12 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 07 Feb 2012 15:32:42 +0800 Received: from SZXEML520-MBS.china.huawei.com ([169.254.2.252]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Tue, 07 Feb 2012 15:33:01 +0800 Date: Tue, 07 Feb 2012 07:33:00 +0000 From: Vero Zheng In-reply-to: X-Originating-IP: [10.108.4.103] To: "zhang.fei3@zte.com.cn" Message-id: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Hqbbv9DYCFbbkXIyMQPXow)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] Discussion on how to carry the Global_ID Thread-index: AQHM3mtgdwQeGuDdLkSXNBeKNfMIpJYq8dIA///NegCABkxR4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2EEA459CD95CCB4988BFAFC0F2287B5C25916F41@SZXEML520-MBS.china.huawei.com> Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 07:34:30 -0000 --Boundary_(ID_Hqbbv9DYCFbbkXIyMQPXow) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Fei, Please see in-line. BR, Vero Fei, you wrote: First, "2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP. Which is not true. The Object we defined could be carried in both Path/Resv message, and is not restricted either to co-routed bi-directional LSP or associated bi-directional LSP. Although either co-routed or associated bidirectional LSP is not mentioned in this draft , according to the descripition in section 2.3, " If the node agrees, it MUST use the same format of Operator ID. The same C-Type of OIO MUST be carried in the Resv message", which means that the procedure is for corouted bidrectional LSP. The above is just my understanding and provided for discussion, and if it is wrong or inaccurate, please let me know. The procedure described above aims to guarantee the sender and the receiver using the same C-Type of the object, i.e. both end using Global_ID or both using ICC_Operator_ID. Second, 3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP. Why "tunnel number" is carried in the Connection TLV? I don't see its necessary for both co-route/ associated bi-directional LSP. Could you explain? As I said, it is useful for corouted (not associated) bidirectional LSP, consider that there is one LSP (LSP1, initiated at node A) between node A/Z. If the CC-V pakcet is sent from node Z, the MEP_ID of node Z will be inserted in the OAM packets, which is organized by node_ID::tunnel_num::LSP_num (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not pre-stored at node A, it can not judge whether this MEP_ID is valid. See the description in section 5.1.1.2 (Mis-Connectivity Defect) of RFC6371. LSP1 A-------------------------------Z Why is tunnel number not known by node A? The tunnel number should has been carried in Session and Sender Template/Filter Spec object and exchanged by node A and node Z during the LSP set-up. Correct me if I am wrong. BR, Vero Thanks. Vero From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of zhang.fei3@zte.com.cn Sent: Sunday, January 29, 2012 5:50 PM To: ccamp@ietf.org Subject: [CCAMP] Discussion on how to carry the Global_ID Hi CCAMPers As discussed in the last IETF meeting and mailinglist, the Global_ID should be carried in the signaling messages. One reason is that the judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store each other's MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num. Fortunately, there are several drafts related to this topic now, 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. The Globa_ID is incorporated into the ASSOCIATION object in the current version, which guarantees that the association is global unique. Since the ASSOCIATION object is used across different LSPs, just my2cents, the defined format is deficient to handle more scenarios. For example: (1) Considering a corouted bidirectional LSP, which is not protected by other LSPs through control plane and/or does not share the same resoures with other LSPs. In these cases, the ASSOCIATION object will not be carried in the sigaling messages. (2) Considering an associated bidirectional LSP, although the ASSOCIATION object is carried in the sigaling messages, the global_ID incorporated in the ASSOCIATION object only indicates the global prefix of the A1 or Z9 nodes. If this LSP is across different domains, I think the current format is also deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of A1 ). 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP. 3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP. The above materials only provide the rough background. Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward. Best regards ;) Fei --Boundary_(ID_Hqbbv9DYCFbbkXIyMQPXow) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Fei,

 

Please see in-line.

 

BR,

Vero

 

Fei,
 
you wrote:
 
First,
“2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft,  which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

Which is not true. The Object we defined could be carried in both Path/Resv message, and is not restricted either to co-routed bi-directional LSP or associated bi-directional LSP.

<fei>
Although either co-routed or associated bidirectional LSP is not mentioned in this draft , according to  the descripition in section 2.3, " If the node agrees, it MUST use the same format of Operator ID.  The same C-Type of OIO MUST be carried in the Resv message", which means that  the procedure is for corouted bidrectional LSP.
The above is just my understanding and provided for discussion, and if it is wrong or inaccurate, please let me know.
</fei>
The procedure described above aims to guarantee the sender and the receiver using the same C-Type of the object, i.e. both end using Global_ID or both using ICC_Operator_ID.

 

Second,
3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01
 
The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP.
 
Why “tunnel number” is carried in the Connection TLV? I don't see its necessary for both co-route/ associated bi-directional LSP. Could you explain?
 
<fei>
As I said, it is useful for corouted (not associated) bidirectional LSP,  consider that there is one LSP (LSP1, initiated at node A) between node A/Z.
If the CC-V pakcet is  sent from  node Z, the MEP_ID of node Z will be inserted in the OAM packets, which is organized by node_ID::tunnel_num::LSP_num
(section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not pre-stored at node A, it can not judge whether this MEP_ID is valid. See the description in section 5.1.1.2
 (Mis-Connectivity Defect) of RFC6371.
                   LSP1
A-------------------------------Z


</fei>
Why is tunnel number not known by node A? The tunnel number should has been carried in Session and Sender Template/Filter Spec object and exchanged by node A and node Z during the LSP set-up. Correct me if I am wrong.

 

BR,

Vero


Thanks.
 
Vero
 
 
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of zhang.fei3@zte.com.cn
Sent: Sunday, January 29, 2012 5:50 PM
To: ccamp@ietf.org
Subject: [CCAMP] Discussion on how to carry the Global_ID
 

Hi CCAMPers

As discussed in the last IETF meeting and mailinglist, the Global_ID should be carried in the signaling messages. One reason is that the judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store each other's MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num.

Fortunately, there are several drafts related to this topic now,

1.  http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01.
   
The Globa_ID is incorporated into the ASSOCIATION object in the current version, which guarantees that the association is global unique. Since the ASSOCIATION object is used across different LSPs, just my2cents, the defined format is deficient to handle more scenarios. For example:

   (1) Considering a corouted bidirectional LSP, which is not protected by other LSPs through control plane and/or does not share the same resoures with other LSPs. In these cases, the ASSOCIATION object will not be carried in the sigaling messages.

   (2) Considering an associated bidirectional LSP, although the ASSOCIATION object is carried in the sigaling messages, the global_ID incorporated in the ASSOCIATION object only
indicates the global prefix of the A1 or Z9 nodes. If this LSP is across different domains, I think the current format is also deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of A1 ).

2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft,  which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01
 
The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appear in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assigned at Z9 nodes in the scenario of corouted bidirectional LSP.


The above materials only provide the rough background.


Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward.


Best regards

;)

Fei

--Boundary_(ID_Hqbbv9DYCFbbkXIyMQPXow)-- From zhang.fei3@zte.com.cn Tue Feb 7 00:31:19 2012 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 44EDB21F8705 for ; Tue, 7 Feb 2012 00:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.552 X-Spam-Level: X-Spam-Status: No, score=-97.552 tagged_above=-999 required=5 tests=[AWL=0.083, 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 4EcoDlF+Ytse for ; Tue, 7 Feb 2012 00:31:18 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 39BC721F858F for ; Tue, 7 Feb 2012 00:31:17 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Tue, 7 Feb 2012 16:04:41 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.788255148; Tue, 7 Feb 2012 16:29:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q178TeHW015964; Tue, 7 Feb 2012 16:29:40 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> To: Vero Zheng MIME-Version: 1.0 X-KeepSent: 8234A400:3AFAFF34-4825799D:002C2EA9; 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, 7 Feb 2012 16:29:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 16:29:42, Serialize complete at 2012-02-07 16:29:42 Content-Type: multipart/alternative; boundary="=_alternative 002EA8F14825799D_=" X-MAIL: mse01.zte.com.cn q178TeHW015964 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 08:31:19 -0000 This is a multipart message in MIME format. --=_alternative 002EA8F14825799D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 VmVybw0KDQpXaHkgaXMgdHVubmVsIG51bWJlciBub3Qga25vd24gYnkgbm9kZSBBPyBUaGUgdHVu bmVsIG51bWJlciBzaG91bGQgaGFzIA0KYmVlbiBjYXJyaWVkIGluIFNlc3Npb24gYW5kIFNlbmRl ciBUZW1wbGF0ZS9GaWx0ZXIgU3BlYyBvYmplY3QgYW5kIA0KZXhjaGFuZ2VkIGJ5IG5vZGUgQSBh bmQgbm9kZSBaIGR1cmluZyB0aGUgTFNQIHNldC11cC4gQ29ycmVjdCBtZSBpZiBJIGFtIA0Kd3Jv bmcuDQoNCkFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb24gb2YgUkZDNjM3MCwgc2VjdGlvbiA1 LjENCiAgIEF0IGVhY2ggZW5kIHBvaW50LCBhIHR1bm5lbCBpcyB1bmlxdWVseSBpZGVudGlmaWVk IGJ5IHRoZSBlbmQgcG9pbnQncw0KICAgTm9kZV9JRCBhbmQgYSBsb2NhbGx5IGFzc2lnbmVkIHR1 bm5lbCBudW1iZXIuICBTcGVjaWZpY2FsbHksIGENCiAgICJUdW5uZWwgTnVtYmVyIiAoVHVubmVs X051bSkgaXMgYSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlciB1bmlxdWUNCiAgIHdpdGhpbiB0aGUg Y29udGV4dCBvZiB0aGUgTm9kZV9JRC4gIFRoZSBtb3RpdmF0aW9uIGZvciBlYWNoIGVuZCBwb2lu dA0KICAgaGF2aW5nIGl0cyBvd24gdHVubmVsIG51bWJlciBpcyB0byBhbGxvdyBhIGNvbXBhY3Qg Zm9ybSBmb3IgdGhlDQogICBNRVBfSUQuIA0KDQpXaGljaCBtZWFucyB0aGF0IGZvciBjby1yb3V0 ZWQgYmlkcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3byB0dW5uZWwgDQpudW1iZXJzLCBvbmUg aXMgbG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIEEgYW5kIHRoZSBvdGhlciBpcyBsb2NhbGx5IA0K YXNzaWduZWQgYXQgbm9kZSBaLg0KSWYgdGhlIHNpZ25hbGluZyBtZXNzYWdlIGlzIGluaXRpYWxp emVkIGF0IG5vZGUgQSwgdGhlIHR1bm5lbCBudW1iZXIgDQpjYXJyaWVkIGluIFNlc3Npb24vU2Vu ZGVyIFRlbXBsYXRlIG9iamVjdHMgaXMgbG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIEEuIA0KT2Yg Y291cnNlLCBhIG5ldw0KQy10eXBlLGxpa2UgdHlwZT04LCBjYW4gYmUgZGVmaW5lZCBpbiB0aGUg Y2xhc3Mgb2YgU0VTU0lPTiB0byBjYXJyeSBiYWNrIA0KdGhlIHR1bm5lbCBudW1iZXIgYXNzaWdu ZWQgYXQgbm9kZSBaOyBidXQgYWNjb3JkaW5nIHRvIHRoZSBkaXNjdXNzaW9uIHdpdGggDQpHZW9y Z2UsIEkgZG8gbm90IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHdoaWNoIGlzIG5vdCBiYWNrd2Fy ZCBjb21wYXRpYmxlLg0KDQpSZWdhcmRzDQoNCkZlaQ0KDQoNCg0KVmVybyBaaGVuZyA8dmVyby56 aGVuZ0BodWF3ZWkuY29tPiANCjIwMTItMDItMDcgMTU6MzMNCg0KytW8/sjLDQoiemhhbmcuZmVp M0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPg0Ks63LzQ0KImNjYW1wQGlldGYu b3JnIiA8Y2NhbXBAaWV0Zi5vcmc+DQrW98ziDQpSRTogW0NDQU1QXSBEaXNjdXNzaW9uIG9uIGhv dyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEDQoNCg0KDQoNCg0KDQpGZWksDQogDQpQbGVhc2Ugc2Vl IGluLWxpbmUuDQogDQpCUiwNClZlcm8NCiANCkZlaSwgDQogIA0KeW91IHdyb3RlOiANCiAgDQpG aXJzdCwgDQqhsDIuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAt bXBscy10cC1vaW8tMDEgDQoNClRoZSBHbG9iYWxfSUQgT2JqZWN0IGFuZCB0aGUgSUNDX09wZXJh dG9yX0lEIE9iamVjdCBhcmUgZGVmaW5lZCBpbiB0aGlzIA0KZHJhZnQsICB3aGljaCBkZXNjcmli ZXMgdGhlIHByb2NlZHVyZSBvZiBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCANCihhc3NvY2lh dGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGluIHRoZSBjdXJyZW50IHZlcnNp b24pIGFuZCANCnJlcXVpcmVzIHRoYXQgdGhlIHNhbWUgZm9ybWF0KCBHbG9iYWxfSUQgb3IgSUND X09wZXJhdG9yX0lEKWlzIHVzZWQgYWxvbmcgDQp0aGUgTFNQLiANCg0KV2hpY2ggaXMgbm90IHRy dWUuIFRoZSBPYmplY3Qgd2UgZGVmaW5lZCBjb3VsZCBiZSBjYXJyaWVkIGluIGJvdGggDQpQYXRo L1Jlc3YgbWVzc2FnZSwgYW5kIGlzIG5vdCByZXN0cmljdGVkIGVpdGhlciB0byBjby1yb3V0ZWQg DQpiaS1kaXJlY3Rpb25hbCBMU1Agb3IgYXNzb2NpYXRlZCBiaS1kaXJlY3Rpb25hbCBMU1AuIA0K DQo8ZmVpPiANCkFsdGhvdWdoIGVpdGhlciBjby1yb3V0ZWQgb3IgYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIExTUCBpcyBub3QgbWVudGlvbmVkIA0KaW4gdGhpcyBkcmFmdCAsIGFjY29yZGluZyB0 byAgdGhlIGRlc2NyaXBpdGlvbiBpbiBzZWN0aW9uIDIuMywgIiBJZiB0aGUgDQpub2RlIGFncmVl cywgaXQgTVVTVCB1c2UgdGhlIHNhbWUgZm9ybWF0IG9mIE9wZXJhdG9yIElELiAgVGhlIHNhbWUg Qy1UeXBlIA0Kb2YgT0lPIE1VU1QgYmUgY2FycmllZCBpbiB0aGUgUmVzdiBtZXNzYWdlIiwgd2hp Y2ggbWVhbnMgdGhhdCAgdGhlIA0KcHJvY2VkdXJlIGlzIGZvciBjb3JvdXRlZCBiaWRyZWN0aW9u YWwgTFNQLiANClRoZSBhYm92ZSBpcyBqdXN0IG15IHVuZGVyc3RhbmRpbmcgYW5kIHByb3ZpZGVk IGZvciBkaXNjdXNzaW9uLCBhbmQgaWYgaXQgDQppcyB3cm9uZyBvciBpbmFjY3VyYXRlLCBwbGVh c2UgbGV0IG1lIGtub3cuIA0KPC9mZWk+IA0KVGhlIHByb2NlZHVyZSBkZXNjcmliZWQgYWJvdmUg YWltcyB0byBndWFyYW50ZWUgdGhlIHNlbmRlciBhbmQgdGhlIA0KcmVjZWl2ZXIgdXNpbmcgdGhl IHNhbWUgQy1UeXBlIG9mIHRoZSBvYmplY3QsIGkuZS4gYm90aCBlbmQgdXNpbmcgDQpHbG9iYWxf SUQgb3IgYm90aCB1c2luZyBJQ0NfT3BlcmF0b3JfSUQuDQogDQpTZWNvbmQsIA0KMy4gDQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l eHQtdHVubmVsLW51bS0wMSANCg0KIA0KVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFzIGEgVExW IG9mIHRoZSBMU1BfQVRUUklCVVRFIG9iamVjdCwgd2hpY2ggd2lsbCANCmFwcGVhciBpbiB0aGUg UGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQgb25seSAN CmFwcGVhciBpbiB0aGUgUGF0aCBtZXNzYWdlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1AuIEZ1cnRoZXJtb3JlLCANCnRoaXMgZHJhZnQgZGVmaW5lZCBhIENvbm5lY3Rpb24gVExWIHVz ZWQgdG8gY2FycnkgdGhlIGxvY2FsIHR1bm5lbCBudW1iZXIgDQphc3NpZ25lZCBhdCBaOSBub2Rl cyBpbiB0aGUgc2NlbmFyaW8gb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIA0KICANCldo eSChsHR1bm5lbCBudW1iZXKhsSBpcyBjYXJyaWVkIGluIHRoZSBDb25uZWN0aW9uIFRMVj8gSSBk b24ndCBzZWUgaXRzIA0KbmVjZXNzYXJ5IGZvciBib3RoIGNvLXJvdXRlLyBhc3NvY2lhdGVkIGJp LWRpcmVjdGlvbmFsIExTUC4gQ291bGQgeW91IA0KZXhwbGFpbj8gDQogIA0KPGZlaT4gDQpBcyBJ IHNhaWQsIGl0IGlzIHVzZWZ1bCBmb3IgY29yb3V0ZWQgKG5vdCBhc3NvY2lhdGVkKSBiaWRpcmVj dGlvbmFsIExTUCwgDQpjb25zaWRlciB0aGF0IHRoZXJlIGlzIG9uZSBMU1AgKExTUDEsIGluaXRp YXRlZCBhdCBub2RlIEEpIGJldHdlZW4gbm9kZSANCkEvWi4gDQpJZiB0aGUgQ0MtViBwYWtjZXQg aXMgIHNlbnQgZnJvbSAgbm9kZSBaLCB0aGUgTUVQX0lEIG9mIG5vZGUgWiB3aWxsIGJlIA0KaW5z ZXJ0ZWQgaW4gdGhlIE9BTSBwYWNrZXRzLCB3aGljaCBpcyBvcmdhbml6ZWQgYnkgDQpub2RlX0lE Ojp0dW5uZWxfbnVtOjpMU1BfbnVtIA0KKHNlY3Rpb24gNS4yLjEgb3IgNy4yLjIgb2YgUkZDNjM3 MCksIGFuZCBpZiB0aGlzIE1FUF9JRCBpcyBub3QgcHJlLXN0b3JlZCANCmF0IG5vZGUgQSwgaXQg Y2FuIG5vdCBqdWRnZSB3aGV0aGVyIHRoaXMgTUVQX0lEIGlzIHZhbGlkLiBTZWUgdGhlIA0KZGVz Y3JpcHRpb24gaW4gc2VjdGlvbiA1LjEuMS4yIA0KIChNaXMtQ29ubmVjdGl2aXR5IERlZmVjdCkg b2YgUkZDNjM3MS4gDQogICAgICAgICAgICAgICAgICAgTFNQMSANCkEtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tWiANCg0KDQo8L2ZlaT4gDQpXaHkgaXMgdHVubmVsIG51bWJlciBub3Qg a25vd24gYnkgbm9kZSBBPyBUaGUgdHVubmVsIG51bWJlciBzaG91bGQgaGFzIA0KYmVlbiBjYXJy aWVkIGluIFNlc3Npb24gYW5kIFNlbmRlciBUZW1wbGF0ZS9GaWx0ZXIgU3BlYyBvYmplY3QgYW5k IA0KZXhjaGFuZ2VkIGJ5IG5vZGUgQSBhbmQgbm9kZSBaIGR1cmluZyB0aGUgTFNQIHNldC11cC4g Q29ycmVjdCBtZSBpZiBJIGFtIA0Kd3JvbmcuDQogDQpCUiwNClZlcm8NCg0KVGhhbmtzLiANCiAg DQpWZXJvIA0KICANCiAgDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KemhhbmcuZmVpM0B6dGUuY29tLmNu DQpTZW50OiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTIgNTo1MCBQTQ0KVG86IGNjYW1wQGlldGYu b3JnDQpTdWJqZWN0OiBbQ0NBTVBdIERpc2N1c3Npb24gb24gaG93IHRvIGNhcnJ5IHRoZSBHbG9i YWxfSUQgDQogIA0KDQpIaSBDQ0FNUGVycyANCg0KQXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IElF VEYgbWVldGluZyBhbmQgbWFpbGluZ2xpc3QsIHRoZSBHbG9iYWxfSUQgDQpzaG91bGQgYmUgY2Fy cmllZCBpbiB0aGUgc2lnbmFsaW5nIG1lc3NhZ2VzLiBPbmUgcmVhc29uIGlzIHRoYXQgdGhlIA0K anVkZ2VtZW50IG9mIGEgbWlzLWNvbm5lY3Rpdml0eSBkZWZlY3QgbmVlZHMgdGhlIEExL1o5IG5v ZGVzIHRvIHByZS1zdG9yZSANCmVhY2ggb3RoZXIncyBNRVBfSUQsIHdob3NlIGZvcm1hdCBpczog R29iYWxfSUQrTm9kZV9JRCtUdW5uZWxfbnVtK0xTUF9udW0uIA0KDQoNCkZvcnR1bmF0ZWx5LCB0 aGVyZSBhcmUgc2V2ZXJhbCBkcmFmdHMgcmVsYXRlZCB0byB0aGlzIHRvcGljIG5vdywgDQoNCjEu ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0w MS4gDQogICANClRoZSBHbG9iYV9JRCBpcyBpbmNvcnBvcmF0ZWQgaW50byB0aGUgQVNTT0NJQVRJ T04gb2JqZWN0IGluIHRoZSBjdXJyZW50IA0KdmVyc2lvbiwgd2hpY2ggZ3VhcmFudGVlcyB0aGF0 IHRoZSBhc3NvY2lhdGlvbiBpcyBnbG9iYWwgdW5pcXVlLiBTaW5jZSB0aGUgDQpBU1NPQ0lBVElP TiBvYmplY3QgaXMgdXNlZCBhY3Jvc3MgZGlmZmVyZW50IExTUHMsIGp1c3QgbXkyY2VudHMsIHRo ZSANCmRlZmluZWQgZm9ybWF0IGlzIGRlZmljaWVudCB0byBoYW5kbGUgbW9yZSBzY2VuYXJpb3Mu IEZvciBleGFtcGxlOiANCg0KICAgKDEpIENvbnNpZGVyaW5nIGEgY29yb3V0ZWQgYmlkaXJlY3Rp b25hbCBMU1AsIHdoaWNoIGlzIG5vdCBwcm90ZWN0ZWQgYnkgDQpvdGhlciBMU1BzIHRocm91Z2gg Y29udHJvbCBwbGFuZSBhbmQvb3IgZG9lcyBub3Qgc2hhcmUgdGhlIHNhbWUgcmVzb3VyZXMgDQp3 aXRoIG90aGVyIExTUHMuIEluIHRoZXNlIGNhc2VzLCB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IHdp bGwgbm90IGJlIA0KY2FycmllZCBpbiB0aGUgc2lnYWxpbmcgbWVzc2FnZXMuIA0KDQogICAoMikg Q29uc2lkZXJpbmcgYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgYWx0aG91Z2ggdGhl IA0KQVNTT0NJQVRJT04gb2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2Vz LCB0aGUgZ2xvYmFsX0lEIA0KaW5jb3Jwb3JhdGVkIGluIHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qg b25seSANCmluZGljYXRlcyB0aGUgZ2xvYmFsIHByZWZpeCBvZiB0aGUgQTEgb3IgWjkgbm9kZXMu IElmIHRoaXMgTFNQIGlzIGFjcm9zcyANCmRpZmZlcmVudCBkb21haW5zLCBJIHRoaW5rIHRoZSBj dXJyZW50IGZvcm1hdCBpcyBhbHNvIGRlZmljaWVudCAoQTEgZG9lcyANCm5vdCBrbm93IHRoZSBn b2JhbCBJRCBvZiBaOSBub2RlIG9yIFo5IG5vZGVzIGRvZXMgbm90IGtub3cgdGhlIGdsb2JhbCBJ RCANCm9mIEExICkuIA0KDQoyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVu LWNjYW1wLW1wbHMtdHAtb2lvLTAxIA0KDQpUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhlIElD Q19PcGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQgaW4gdGhpcyANCmRyYWZ0LCAgd2hpY2gg ZGVzY3JpYmVzIHRoZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgDQoo YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBub3QgY292ZXJlZCBpbiB0aGUgY3VycmVu dCB2ZXJzaW9uKSBhbmQgDQpyZXF1aXJlcyB0aGF0IHRoZSBzYW1lIGZvcm1hdCggR2xvYmFsX0lE IG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkIGFsb25nIA0KdGhlIExTUC4gDQoNCjMuIA0KaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUt ZXh0LXR1bm5lbC1udW0tMDEgDQoNCiANClRoZSBHbG9iYWxfSUQgaXMgY2FycmllZCBhcyBhIFRM ViBvZiB0aGUgTFNQX0FUVFJJQlVURSBvYmplY3QsIHdoaWNoIHdpbGwgDQphcHBlYXIgaW4gdGhl IFBhdGgvUmVzdiBtZXNzYWdlIG9mIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AgYW5kIG9ubHkg DQphcHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg TFNQLiBGdXJ0aGVybW9yZSwgDQp0aGlzIGRyYWZ0IGRlZmluZWQgYSBDb25uZWN0aW9uIFRMViB1 c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5uZWwgbnVtYmVyIA0KYXNzaWduZWQgYXQgWjkgbm9k ZXMgaW4gdGhlIHNjZW5hcmlvIG9mIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLiANCg0KDQpU aGUgYWJvdmUgbWF0ZXJpYWxzIG9ubHkgcHJvdmlkZSB0aGUgcm91Z2ggYmFja2dyb3VuZC4gDQoN Cg0KSG9wZSB0byBoZWFyIHRoZSBvcGluaW9ucyBmcm9tIHRoZSBXRyB0aGF0IGhvdyB0byBjYXJy eSB0aGUgR2xvYmFsX0lELCANCnRoZW4gbW92ZSB0aGUgd29yayBmb3J3YXJkLiANCg0KDQpCZXN0 IHJlZ2FyZHMgDQoNCjspIA0KDQpGZWkgDQoNCg== --=_alternative 002EA8F14825799D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlZlcm88L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNjMDAwMDAgZmFjZT0iQ2FsaWJyaSI+V2h5IGlzIHR1bm5l bCBudW1iZXIgbm90DQprbm93biBieSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZCBo YXMgYmVlbiBjYXJyaWVkIGluIFNlc3Npb24gYW5kDQpTZW5kZXIgVGVtcGxhdGUvRmlsdGVyIFNw ZWMgb2JqZWN0IGFuZCBleGNoYW5nZWQgYnkgbm9kZSBBIGFuZCBub2RlIFogZHVyaW5nDQp0aGUg TFNQIHNldC11cC4gQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlv biBvZiBSRkM2MzcwLA0Kc2VjdGlvbiA1LjE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtBdCBlYWNoIGVuZCBwb2ludCwgYSB0dW5uZWwNCmlz IHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhlIGVuZCBwb2ludCdzPGJyPg0KICZuYnNwOyBOb2Rl X0lEIGFuZCBhIGxvY2FsbHkgYXNzaWduZWQgdHVubmVsIG51bWJlci4gJm5ic3A7U3BlY2lmaWNh bGx5LA0KYTxicj4NCiAmbmJzcDsgJnF1b3Q7VHVubmVsIE51bWJlciZxdW90OyAoVHVubmVsX051 bSkgaXMgYSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlcg0KdW5pcXVlPGJyPg0KICZuYnNwOyB3aXRo aW4gdGhlIGNvbnRleHQgb2YgdGhlIE5vZGVfSUQuICZuYnNwO1RoZSBtb3RpdmF0aW9uIGZvciBl YWNoDQplbmQgcG9pbnQ8YnI+DQogJm5ic3A7IGhhdmluZyBpdHMgb3duIHR1bm5lbCBudW1iZXIg aXMgdG8gYWxsb3cgYSBjb21wYWN0IGZvcm0gZm9yIHRoZTxicj4NCiAmbmJzcDsgTUVQX0lELiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoaWNoIG1l YW5zIHRoYXQgZm9yIGNvLXJvdXRlZCBiaWRyZWN0aW9uYWwNCkxTUCwgdGhlcmUgYXJlIHR3byB0 dW5uZWwgbnVtYmVycywgb25lIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQgbm9kZSBBIGFuZA0KdGhl IG90aGVyIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQgbm9kZSBaLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgdGhlIHNpZ25hbGluZyBtZXNzYWdlIGlzIGluaXRp YWxpemVkDQphdCBub2RlIEEsIHRoZSB0dW5uZWwgbnVtYmVyIGNhcnJpZWQgaW4gU2Vzc2lvbi9T ZW5kZXIgVGVtcGxhdGUgb2JqZWN0cw0KaXMgbG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIEEuIE9m IGNvdXJzZSwgYSBuZXc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkMtdHlwZSxsaWtlIHR5cGU9OCwgY2FuIGJlIGRlZmluZWQgaW4NCnRoZSBjbGFzcyBvZiBTRVNT SU9OIHRvIGNhcnJ5IGJhY2sgdGhlIHR1bm5lbCBudW1iZXIgYXNzaWduZWQgYXQgbm9kZSBaOw0K YnV0IGFjY29yZGluZyB0byB0aGUgZGlzY3Vzc2lvbiB3aXRoIEdlb3JnZSwgSSBkbyBub3QgdGhp bmsgaXQgaXMgYSBnb29kDQppZGVhIHdoaWNoIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkczwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250 Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlZlcm8gWmhl bmcgJmx0O3Zlcm8uemhlbmdAaHVhd2VpLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMi0wNyAxNTozMzwvZm9udD4NCjx0ZCB3aWR0 aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt6aGFuZy5mZWkz QHp0ZS5jb20uY24mcXVvdDsgJmx0O3poYW5nLmZlaTNAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9yZyZn dDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBbQ0NBTVBdIERpc2N1c3Npb24gb24gaG93IHRvIGNh cnJ5DQp0aGUgR2xvYmFsX0lEPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+RmVpLDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+UGxlYXNl IHNlZSBpbi1saW5lLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2Qg ZmFjZT0iQ2FsaWJyaSI+QlIsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPlZlcm88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MWY0OTdkIGZhY2U9IkNhbGlicmkiPkZlaSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZv bnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQp5b3Ugd3JvdGU6PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250 IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+PGZvbnQg c2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQpGaXJzdCwgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K obAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMtdHAt b2lvLTAxIDxicj4NCjxicj4NClRoZSBHbG9iYWxfSUQgT2JqZWN0IGFuZCB0aGUgSUNDX09wZXJh dG9yX0lEIE9iamVjdCBhcmUgZGVmaW5lZCBpbiB0aGlzDQpkcmFmdCwgJm5ic3A7d2hpY2ggZGVz Y3JpYmVzIHRoZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCihhc3Nv Y2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGluIHRoZSBjdXJyZW50IHZl cnNpb24pIGFuZA0KcmVxdWlyZXMgdGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvciBJ Q0NfT3BlcmF0b3JfSUQpaXMgdXNlZCBhbG9uZw0KdGhlIExTUC48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCldoaWNoIGlz IG5vdCB0cnVlLiBUaGUgT2JqZWN0IHdlIGRlZmluZWQgY291bGQgYmUgY2FycmllZCBpbiBib3Ro IFBhdGgvUmVzdg0KbWVzc2FnZSwgYW5kIGlzIG5vdCByZXN0cmljdGVkIGVpdGhlciB0byBjby1y b3V0ZWQgYmktZGlyZWN0aW9uYWwgTFNQIG9yDQphc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExT UC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KJmx0O2ZlaSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K QWx0aG91Z2ggZWl0aGVyIGNvLXJvdXRlZCBvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQ IGlzIG5vdCBtZW50aW9uZWQNCmluIHRoaXMgZHJhZnQgLCBhY2NvcmRpbmcgdG8gJm5ic3A7dGhl IGRlc2NyaXBpdGlvbiBpbiBzZWN0aW9uIDIuMywgJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj4NCklmIHRoZSBub2RlIGFncmVlcywgaXQgTVVTVCB1c2UgdGhlIHNhbWUg Zm9ybWF0IG9mIE9wZXJhdG9yIElELiAmbmJzcDtUaGUNCnNhbWUgQy1UeXBlIG9mIE9JTyBNVVNU IGJlIGNhcnJpZWQgaW4gdGhlIFJlc3YgbWVzc2FnZTwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mcXVvdDssDQp3aGljaCBtZWFucyB0aGF0ICZuYnNwO3Ro ZSBwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AuPC9mb250Pjxmb250 IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQpUaGUgYWJvdmUgaXMganVzdCBteSB1bmRlcnN0YW5kaW5nIGFuZCBwcm92aWRlZCBm b3IgZGlzY3Vzc2lvbiwgYW5kIGlmDQppdCBpcyB3cm9uZyBvciBpbmFjY3VyYXRlLCBwbGVhc2Ug bGV0IG1lIGtub3cuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZsdDsvZmVpJmd0OzwvZm9udD48Zm9udCBz aXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9I2MwMDAwMCBmYWNlPSJDYWxpYnJpIj48 YnI+DQpUaGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBhYm92ZSBhaW1zIHRvIGd1YXJhbnRlZSB0aGUg c2VuZGVyIGFuZCB0aGUgcmVjZWl2ZXINCnVzaW5nIHRoZSBzYW1lIEMtVHlwZSBvZiB0aGUgb2Jq ZWN0LCBpLmUuIGJvdGggZW5kIHVzaW5nIEdsb2JhbF9JRCBvciBib3RoDQp1c2luZyBJQ0NfT3Bl cmF0b3JfSUQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl PSJDYWxpYnJpIj5TZWNvbmQsIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CjMuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAt cnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIDxicj4N ClRoZSBHbG9iYWxfSUQgaXMgY2FycmllZCBhcyBhIFRMViBvZiB0aGUgTFNQX0FUVFJJQlVURSBv YmplY3QsIHdoaWNoIHdpbGwNCmFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29y b3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQgb25seSBhcHBlYXINCmluIHRoZSBQYXRoIG1lc3Nh Z2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gRnVydGhlcm1vcmUsIHRoaXMNCmRy YWZ0IGRlZmluZWQgYSBDb25uZWN0aW9uIFRMViB1c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5u ZWwgbnVtYmVyIGFzc2lnbmVkDQphdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFyaW8gb2YgY29yb3V0 ZWQgYmlkaXJlY3Rpb25hbCBMU1AuPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNp emU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KV2h5IKGwdHVubmVsIG51bWJlcqGxIGlzIGNhcnJpZWQgaW4gdGhlIENvbm5lY3Rp b24gVExWPyBJIGRvbid0IHNlZSBpdHMNCm5lY2Vzc2FyeSBmb3IgYm90aCBjby1yb3V0ZS8gYXNz b2NpYXRlZCBiaS1kaXJlY3Rpb25hbCBMU1AuIENvdWxkIHlvdSBleHBsYWluPzwvZm9udD48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZsdDtmZWkmZ3Q7PC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki Pjxicj4NCkFzIEkgc2FpZCwgaXQgaXMgdXNlZnVsIGZvciBjb3JvdXRlZCAobm90IGFzc29jaWF0 ZWQpIGJpZGlyZWN0aW9uYWwgTFNQLA0KJm5ic3A7Y29uc2lkZXIgdGhhdCB0aGVyZSBpcyBvbmUg TFNQIChMU1AxLCBpbml0aWF0ZWQgYXQgbm9kZSBBKSBiZXR3ZWVuDQpub2RlIEEvWi48L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2Fs aWJyaSI+PGJyPg0KSWYgdGhlIENDLVYgcGFrY2V0IGlzICZuYnNwO3NlbnQgZnJvbSAmbmJzcDtu b2RlIFosIHRoZSBNRVBfSUQgb2Ygbm9kZQ0KWiB3aWxsIGJlIGluc2VydGVkIGluIHRoZSBPQU0g cGFja2V0cywgd2hpY2ggaXMgb3JnYW5pemVkIGJ5IG5vZGVfSUQ6OnR1bm5lbF9udW06OkxTUF9u dW0NCjxicj4NCihzZWN0aW9uIDUuMi4xIG9yIDcuMi4yIG9mIFJGQzYzNzApLCBhbmQgaWYgdGhp cyBNRVBfSUQgaXMgbm90IHByZS1zdG9yZWQNCmF0IG5vZGUgQSwgaXQgY2FuIG5vdCBqdWRnZSB3 aGV0aGVyIHRoaXMgTUVQX0lEIGlzIHZhbGlkLiBTZWUgdGhlIGRlc2NyaXB0aW9uDQppbiBzZWN0 aW9uIDUuMS4xLjI8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KICg8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPjxiPk1pcy1Db25uZWN0aXZpdHkgRGVmZWN0PC9iPjwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4pDQpvZiBSRkM2MzcxLjwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgTFNQMTwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KQS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1aPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPGJyPg0KPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZsdDsvZmVpJmd0 OzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9I2MwMDAwMCBm YWNlPSJDYWxpYnJpIj48YnI+DQpXaHkgaXMgdHVubmVsIG51bWJlciBub3Qga25vd24gYnkgbm9k ZSBBPyBUaGUgdHVubmVsIG51bWJlciBzaG91bGQgaGFzDQpiZWVuIGNhcnJpZWQgaW4gU2Vzc2lv biBhbmQgU2VuZGVyIFRlbXBsYXRlL0ZpbHRlciBTcGVjIG9iamVjdCBhbmQgZXhjaGFuZ2VkDQpi eSBub2RlIEEgYW5kIG5vZGUgWiBkdXJpbmcgdGhlIExTUCBzZXQtdXAuIENvcnJlY3QgbWUgaWYg SSBhbSB3cm9uZy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSNjMDAwMDAgZmFjZT0i Q2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jYzAwMDAwIGZh Y2U9IkNhbGlicmkiPkJSLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9I2MwMDAwMCBm YWNlPSJDYWxpYnJpIj5WZXJvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NClRoYW5rcy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48 Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NClZlcm88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmki Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iVGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uDQpCZWhhbGYgT2YgPC9iPnpoYW5nLmZl aTNAenRlLmNvbS5jbjxiPjxicj4NClNlbnQ6PC9iPiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTIg NTo1MCBQTTxiPjxicj4NClRvOjwvYj4gY2NhbXBAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0Ojwv Yj4gW0NDQU1QXSBEaXNjdXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEPC9mb250 Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48YnI+DQo8YnI+DQpIaSBDQ0FNUGVyczwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KPGJyPg0KQXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IElFVEYgbWVldGluZyBhbmQgbWFpbGlu Z2xpc3QsIHRoZSBHbG9iYWxfSUQgc2hvdWxkDQpiZSBjYXJyaWVkIGluIHRoZSBzaWduYWxpbmcg bWVzc2FnZXMuIE9uZSByZWFzb24gaXMgdGhhdCB0aGUganVkZ2VtZW50DQpvZiBhIG1pcy1jb25u ZWN0aXZpdHkgZGVmZWN0IG5lZWRzIHRoZSBBMS9aOSBub2RlcyB0byBwcmUtc3RvcmUgZWFjaCBv dGhlcidzDQpNRVBfSUQsIHdob3NlIGZvcm1hdCBpczogR29iYWxfSUQrTm9kZV9JRCtUdW5uZWxf bnVtK0xTUF9udW0uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KRm9ydHVuYXRlbHks IHRoZXJlIGFyZSBzZXZlcmFsIGRyYWZ0cyByZWxhdGVkIHRvIHRoaXMgdG9waWMgbm93LDwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjEuICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAxLjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwi Pjxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZSBHbG9iYV9JRCBpcyBp bmNvcnBvcmF0ZWQgaW50byB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGluIHRoZSBjdXJyZW50DQp2 ZXJzaW9uLCB3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIGFzc29jaWF0aW9uIGlzIGdsb2JhbCB1 bmlxdWUuIFNpbmNlDQp0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGlzIHVzZWQgYWNyb3NzIGRpZmZl cmVudCBMU1BzLCBqdXN0IG15MmNlbnRzLCB0aGUNCmRlZmluZWQgZm9ybWF0IGlzIGRlZmljaWVu dCB0byBoYW5kbGUgbW9yZSBzY2VuYXJpb3MuIEZvciBleGFtcGxlOjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCjxicj4NCiAmbmJzcDsgKDEpIENvbnNpZGVyaW5nIGEgY29yb3V0ZWQgYmlkaXJl Y3Rpb25hbCBMU1AsIHdoaWNoIGlzIG5vdCBwcm90ZWN0ZWQNCmJ5IG90aGVyIExTUHMgdGhyb3Vn aCBjb250cm9sIHBsYW5lIGFuZC9vciBkb2VzIG5vdCBzaGFyZSB0aGUgc2FtZSByZXNvdXJlcw0K d2l0aCBvdGhlciBMU1BzLiBJbiB0aGVzZSBjYXNlcywgdGhlIEFTU09DSUFUSU9OIG9iamVjdCB3 aWxsIG5vdCBiZSBjYXJyaWVkDQppbiB0aGUgc2lnYWxpbmcgbWVzc2FnZXMuIDxicj4NCjxicj4N CiAmbmJzcDsgKDIpIENvbnNpZGVyaW5nIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1As IGFsdGhvdWdoIHRoZSBBU1NPQ0lBVElPTg0Kb2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2Fs aW5nIG1lc3NhZ2VzLCB0aGUgZ2xvYmFsX0lEIGluY29ycG9yYXRlZA0KaW4gdGhlIEFTU09DSUFU SU9OIG9iamVjdCBvbmx5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KaW5kaWNhdGVzIHRoZSBn bG9iYWwgcHJlZml4IG9mIHRoZSBBMSBvciBaOSBub2Rlcy4gSWYgdGhpcyBMU1AgaXMgYWNyb3Nz DQpkaWZmZXJlbnQgZG9tYWlucywgSSB0aGluayB0aGUgY3VycmVudCBmb3JtYXQgaXMgYWxzbyBk ZWZpY2llbnQgKEExIGRvZXMNCm5vdCBrbm93IHRoZSBnb2JhbCBJRCBvZiBaOSBub2RlIG9yIFo5 IG5vZGVzIGRvZXMgbm90IGtub3cgdGhlIGdsb2JhbCBJRA0Kb2YgQTEgKS48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i QXJpYWwiPjxicj4NCjxicj4NCjIuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNo ZW4tY2NhbXAtbXBscy10cC1vaW8tMDEgPGJyPg0KPGJyPg0KVGhlIEdsb2JhbF9JRCBPYmplY3Qg YW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0IGFyZSBkZWZpbmVkIGluIHRoaXMNCmRyYWZ0 LCAmbmJzcDt3aGljaCBkZXNjcmliZXMgdGhlIHByb2NlZHVyZSBvZiBjb3JvdXRlZCBiaWRpcmVj dGlvbmFsIExTUA0KKGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgaXMgbm90IGNvdmVyZWQg aW4gdGhlIGN1cnJlbnQgdmVyc2lvbikgYW5kDQpyZXF1aXJlcyB0aGF0IHRoZSBzYW1lIGZvcm1h dCggR2xvYmFsX0lEIG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkIGFsb25nDQp0aGUgTFNQLjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KMy4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDE8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQogPGJyPg0KVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFz IGEgVExWIG9mIHRoZSBMU1BfQVRUUklCVVRFIG9iamVjdCwgd2hpY2ggd2lsbA0KYXBwZWFyIGlu IHRoZSBQYXRoL1Jlc3YgbWVzc2FnZSBvZiBjb3JvdXRlZCBiaWRyZWN0aW9uYWwgTFNQIGFuZCBv bmx5IGFwcGVhcg0KaW4gdGhlIFBhdGggbWVzc2FnZSBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9u YWwgTFNQLiBGdXJ0aGVybW9yZSwgdGhpcw0KZHJhZnQgZGVmaW5lZCBhIENvbm5lY3Rpb24gVExW IHVzZWQgdG8gY2FycnkgdGhlIGxvY2FsIHR1bm5lbCBudW1iZXIgYXNzaWduZWQNCmF0IFo5IG5v ZGVzIGluIHRoZSBzY2VuYXJpbyBvZiBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpUaGUgYWJvdmUgbWF0ZXJpYWxzIG9ubHkg cHJvdmlkZSB0aGUgcm91Z2ggYmFja2dyb3VuZC4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCjxicj4NCkhvcGUgdG8gaGVhciB0aGUgb3BpbmlvbnMgZnJvbSB0aGUgV0cgdGhhdCBob3cg dG8gY2FycnkgdGhlIEdsb2JhbF9JRCwNCnRoZW4gbW92ZSB0aGUgd29yayBmb3J3YXJkLjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkJlc3QgcmVnYXJkczwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJBcmlhbCI+PGJyPg0KPGJyPg0KOyk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkZl aTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD4NCjxicj4NCg== --=_alternative 002EA8F14825799D_=-- From francesco.fondelli@gmail.com Tue Feb 7 00:56:49 2012 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 4979A21F869E for ; Tue, 7 Feb 2012 00:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8TWyAdE2waCH for ; Tue, 7 Feb 2012 00:56:47 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A281121F869C for ; Tue, 7 Feb 2012 00:56:47 -0800 (PST) Received: by yhkk25 with SMTP id k25so3267773yhk.31 for ; Tue, 07 Feb 2012 00:56:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qauclBwyx3U8c0+eCCBc4sJCosBc0/FnqGwKN0Iw204=; b=ckc543iRhJXWMoP19MwV+iO7JhFW1SkcUzGeNuVZwnydYnkT40GrcmMpe0xV64/tCp KmLSzxFuRJvPOBw6eZlhSENq+hHJrhlWFwK6YBPIgFD6e3Qhhf86xV3EvuhkPKO19xT3 GVbSIeOQzEBOBmgsUupZNpFl47CTqdBt1RDJA= MIME-Version: 1.0 Received: by 10.236.175.164 with SMTP id z24mr29735394yhl.84.1328605007149; Tue, 07 Feb 2012 00:56:47 -0800 (PST) Received: by 10.236.155.103 with HTTP; Tue, 7 Feb 2012 00:56:47 -0800 (PST) In-Reply-To: References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> Date: Tue, 7 Feb 2012 09:56:47 +0100 Message-ID: From: Francesco Fondelli To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=20cf303f67c67f79ae04b85bf5ed Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 08:56:49 -0000 --20cf303f67c67f79ae04b85bf5ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am I the only one here that feels "uncomfortable" with this approach and this additional Z9-Tunnel_Num index in GMPLS flying from egress to ingress (for no reason?!?)? It might be naive or even stupid but I'd like to understand why we have to add another index... please shed some light on me= . [I'm talking about co-routed bidi, I don't care about associated] thank you ciao FF 2012/2/7 > > Vero > > Why is tunnel number not known by node A? The tunnel number should has > been carried in Session and Sender Template/Filter Spec object and > exchanged by node A and node Z during the LSP set-up. Correct me if I am > wrong. > > According to the description of RFC6370, section 5.1 > At each end point, a tunnel is uniquely identified by the end point's > Node_ID and a locally assigned tunnel number. Specifically, a > "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique > within the context of the Node_ID. The motivation for each end point > having its own tunnel number is to allow a compact form for the > MEP_ID. > > Which means that for co-routed bidrectional LSP, there are two tunnel > numbers, one is locally assigned at node A and the other is locally > assigned at node Z. > If the signaling message is initialized at node A, the tunnel number > carried in Session/Sender Template objects is locally assigned at node A. > Of course, a new > C-type,like type=3D8, can be defined in the class of SESSION to carry bac= k > the tunnel number assigned at node Z; but according to the discussion wit= h > George, I do not think it is a good idea which is not backward compatible= . > > Regards > > Fei > > > *Vero Zheng * > > 2012-02-07 15:33 > =E6=94=B6=E4=BB=B6=E4=BA=BA > "zhang.fei3@zte.com.cn" > =E6=8A=84=E9=80=81 > "ccamp@ietf.org" > =E4=B8=BB=E9=A2=98 > RE: [CCAMP] Discussion on how to carry the Global_ID > > > > > Fei, > > Please see in-line. > > BR, > Vero > > Fei, > > you wrote: > > First, > =E2=80=9C2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 > > The Global_ID Object and the ICC_Operator_ID Object are defined in this > draft, which describes the procedure of corouted bidirectional LSP > (associated bidirectional LSP is not covered in the current version) and > requires that the same format( Global_ID or ICC_Operator_ID)is used along > the LSP. > > Which is not true. The Object we defined could be carried in both > Path/Resv message, and is not restricted either to co-routed bi-direction= al > LSP or associated bi-directional LSP. > > > Although either co-routed or associated bidirectional LSP is not mentione= d > in this draft , according to the descripition in section 2.3, " If the > node agrees, it MUST use the same format of Operator ID. The same C-Type > of OIO MUST be carried in the Resv message", which means that the > procedure is for corouted bidrectional LSP. > The above is just my understanding and provided for discussion, and if it > is wrong or inaccurate, please let me know. > > The procedure described above aims to guarantee the sender and the > receiver using the same C-Type of the object, i.e. both end using Global_= ID > or both using ICC_Operator_ID. > > Second, > 3. > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-nu= m-01 > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will > appear in the Path/Resv message of corouted bidrectional LSP and only > appear in the Path message of associated bidirectional LSP. Furthermore, > this draft defined a Connection TLV used to carry the local tunnel number > assigned at Z9 nodes in the scenario of corouted bidirectional LSP. > > Why =E2=80=9Ctunnel number=E2=80=9D is carried in the Connection TLV? I d= on't see its > necessary for both co-route/ associated bi-directional LSP. Could you > explain? > > > As I said, it is useful for corouted (not associated) bidirectional LSP, > consider that there is one LSP (LSP1, initiated at node A) between node > A/Z. > If the CC-V pakcet is sent from node Z, the MEP_ID of node Z will be > inserted in the OAM packets, which is organized by > node_ID::tunnel_num::LSP_num > (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not pre-stored > at node A, it can not judge whether this MEP_ID is valid. See the > description in section 5.1.1.2 > (*Mis-Connectivity Defect*) of RFC6371. > LSP1 > A-------------------------------Z > > > > Why is tunnel number not known by node A? The tunnel number should has > been carried in Session and Sender Template/Filter Spec object and > exchanged by node A and node Z during the LSP set-up. Correct me if I am > wrong. > > BR, > Vero > > Thanks. > > Vero > > * > From:* ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On Behalf > Of *zhang.fei3@zte.com.cn* > Sent:* Sunday, January 29, 2012 5:50 PM* > To:* ccamp@ietf.org* > Subject:* [CCAMP] Discussion on how to carry the Global_ID > > > Hi CCAMPers > > As discussed in the last IETF meeting and mailinglist, the Global_ID > should be carried in the signaling messages. One reason is that the > judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store > each other's MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num= . > > Fortunately, there are several drafts related to this topic now, > > 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. > > The Globa_ID is incorporated into the ASSOCIATION object in the current > version, which guarantees that the association is global unique. Since th= e > ASSOCIATION object is used across different LSPs, just my2cents, the > defined format is deficient to handle more scenarios. For example: > > (1) Considering a corouted bidirectional LSP, which is not protected by > other LSPs through control plane and/or does not share the same resoures > with other LSPs. In these cases, the ASSOCIATION object will not be carri= ed > in the sigaling messages. > > (2) Considering an associated bidirectional LSP, although the > ASSOCIATION object is carried in the sigaling messages, the global_ID > incorporated in the ASSOCIATION object only > indicates the global prefix of the A1 or Z9 nodes. If this LSP is across > different domains, I think the current format is also deficient (A1 does > not know the gobal ID of Z9 node or Z9 nodes does not know the global ID = of > A1 ). > > 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 > > The Global_ID Object and the ICC_Operator_ID Object are defined in this > draft, which describes the procedure of corouted bidirectional LSP > (associated bidirectional LSP is not covered in the current version) and > requires that the same format( Global_ID or ICC_Operator_ID)is used along > the LSP. > > 3. > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-nu= m-01 > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will > appear in the Path/Resv message of corouted bidrectional LSP and only > appear in the Path message of associated bidirectional LSP. Furthermore, > this draft defined a Connection TLV used to carry the local tunnel number > assigned at Z9 nodes in the scenario of corouted bidirectional LSP. > > > The above materials only provide the rough background. > > > Hope to hear the opinions from the WG that how to carry the Global_ID, > then move the work forward. > > > Best regards > > ;) > > Fei > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > --20cf303f67c67f79ae04b85bf5ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Am I the only one here that feels "uncomfortable" with this a= pproach and this additional Z9-Tunnel_Num index in GMPLS flying from egress= to ingress (for no reason?!?)? It might be naive or even stupid but I'= d like to understand why we have to add another index... please shed some l= ight on me.

[I'm talking about co-routed bidi, I don't care about associate= d]

thank you
ciao
FF

2012/2/= 7 <zhang.fei= 3@zte.com.cn>

Vero

Why is tunnel number not known by node A? The tunnel number should has been carried in Session and Sender Template/Filter Spec object and exchanged by node A and node Z durin= g the LSP set-up. Correct me if I am wrong.

According to the description of RFC6370, section 5.1
=C2=A0 =C2=A0At each end point, a tunnel is uniquely identified by the end point's
=C2=A0 Node_ID and a locally assigned tunnel number. =C2=A0Specifically, a
=C2=A0 "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
=C2=A0 within the context of the Node_ID. =C2=A0The motivation for each end point
=C2=A0 having its own tunnel number is to allow a compact form for the
=C2=A0 MEP_ID.

Which means that for co-routed bidrectional LSP, there are two tunnel numbers, one is locally assigned at node A and the other is locally assigned at node Z.
If the signaling message is initialized at node A, the tunnel number carried in Session/Sender Template objects is locally assigned at node A. Of course, a new
C-type,like type=3D8, can be defined in the class of SESSION to carry back the tunnel number assigned at node Z; but according to the discussion with George, I do not think it is a good idea which is not backward compatible.

Regards

Fei


Vero Zheng <vero.zheng@huawei.= com>

2012-02-07 15:33

=E6=94=B6=E4=BB= =B6=E4=BA=BA
"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.= cn>
=E6=8A=84=E9=80= =81
"ccamp@ietf.org" <ccamp@ietf.org>
=E4=B8=BB=E9=A2= =98
RE: [CCAMP] Discussion on how= to carry the Global_ID





Fei,
=C2=A0
Please see in-line.
=C2=A0
BR,
Vero
=C2=A0
Fei,
=C2=A0
you wrote:
=C2=A0
First,
=E2=80=9C2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-= tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, =C2=A0which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

Which is not true. The Object we defined could be carried in both Path/Resv message, and is not restricted either to co-routed bi-directional LSP or associated bi-directional LSP.

<fei>
Although either co-routed or associated bidirectional LSP is not mentioned in this draft , according to =C2=A0the descripition in section 2.3, "<= /font> If the node agrees, it MUST use the same format of Operator ID. =C2=A0The same C-Type of OIO MUST be carried in the Resv message", which means that =C2=A0the procedure is for corouted bidrectional LSP.
The above is just my understanding and provided for discussion, and if it is wrong or inaccurate, please let me know.
</fei>
The procedure described above aims to guarantee the sender and the receiver using the same C-Type of the object, i.e. both end using Global_ID or both using ICC_Operator_ID.
=C2=A0
Second,
3. http://tools.ietf.org/html/draft-zhang-= ccamp-mpls-tp-rsvpte-ext-tunnel-num-01

The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appea= r in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assign= ed at Z9 nodes in the scenario of corouted bidirectional LSP.
=C2=A0
Why =E2=80=9Ctunnel number=E2=80=9D is carried in the Connection TLV? I don= 't see its necessary for both co-route/ associated bi-directional LSP. Could you expla= in?
=C2=A0
<fei>
As I said, it is useful for corouted (not associated) bidirectional LSP, =C2=A0consider that there is one LSP (LSP1, initiated at node A) between node A/Z.
If the CC-V pakcet is =C2=A0sent from =C2=A0node Z, the MEP_ID of node Z will be inserted in the OAM packets, which is organized by node_ID::tunne= l_num::LSP_num
(section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not pre-stored at node A, it can not judge whether this MEP_ID is valid. See the descripti= on in section 5.1.1.2
(Mis-Connectivity Defect) of RFC6371.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LSP1=
A-------------------------------Z


</fei>
Why is tunnel number not known by node A? The tunnel number should has been carried in Session and Sender Template/Filter Spec object and exchange= d by node A and node Z during the LSP set-up. Correct me if I am wrong.
=C2=A0
BR,
Vero

Thanks.
=C2=A0
Vero
=C2=A0
=C2=A0
From: ccamp= -bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of zh= ang.fei3@zte.com.cn
Sent: Sunday, January 29, 2012 5:50 PM
To: ccamp@ietf.org<= /a>
Subject: [CCAMP] Discussion on how to carry the Global_ID
=C2=A0

Hi CCAMPers

As discussed in the last IETF meeting and mailinglist, the Global_ID should be carried in the signaling messages. One reason is that the judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store each other&= #39;s MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num.

Fortunately, there are several drafts related to this topic now,

1. =C2=A0http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-= 01.
=C2=A0
The Globa_ID is incorporated into the ASSOCIATION object in the current version, which guarantees that the association is global unique. Since the ASSOCIATION object is used across different LSPs, just my2cents, the defined format is deficient to handle more scenarios. For example:

=C2=A0 (1) Considering a corouted bidirectional LSP, which is not protecte= d by other LSPs through control plane and/or does not share the same resoures with other LSPs. In these cases, the ASSOCIATION object will not be carried in the sigaling messages.

=C2=A0 (2) Considering an associated bidirectional LSP, although the ASSOC= IATION object is carried in the sigaling messages, the global_ID incorporated in the ASSOCIATION object only
indicates the global prefix of the A1 or Z9 nodes. If this LSP is across different domains, I think the current format is also deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of A1 ).

2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01=

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, =C2=A0which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

3. http://tools.ietf.org/html/draft-zhang-= ccamp-mpls-tp-rsvpte-ext-tunnel-num-01

The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appea= r in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assign= ed at Z9 nodes in the scenario of corouted bidirectional LSP.


The above materials only provide the rough background.


Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward.


Best regards

;)

Fei

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


--20cf303f67c67f79ae04b85bf5ed-- From zhang.fei3@zte.com.cn Tue Feb 7 01:29:44 2012 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 8F47D21F862B for ; Tue, 7 Feb 2012 01:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.335 X-Spam-Level: X-Spam-Status: No, score=-98.335 tagged_above=-999 required=5 tests=[AWL=-0.700, 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 2QQjLofPWIB8 for ; Tue, 7 Feb 2012 01:29:43 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7821F8613 for ; Tue, 7 Feb 2012 01:29:42 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 53829473195744; Tue, 7 Feb 2012 17:24:47 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.2878213386; Tue, 7 Feb 2012 17:29:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q179TVma011067; Tue, 7 Feb 2012 17:29:31 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Francesco Fondelli MIME-Version: 1.0 X-KeepSent: 2F286D09:85109DFB-4825799D:003233CB; 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, 7 Feb 2012 17:29:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-07 17:29:33, Serialize complete at 2012-02-07 17:29:33 Content-Type: multipart/alternative; boundary="=_alternative 003423AA4825799D_=" X-MAIL: mse01.zte.com.cn q179TVma011067 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 09:29:44 -0000 This is a multipart message in MIME format. --=_alternative 003423AA4825799D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RnJhbmNlc2NvDQoNCkJlbG93IGlzIG9uZSB1c2VjYXNlIGJhc2VkIG9uIG15IHVuZGVyc3RhbmRp bmcuDQoNCkExLS0tLS0tLS0tLS0tLS0tLVo5IChjby1yb3V0ZWQpDQoNClRoZSBNRVBfSUQgb2Yg QTEgaXMgQTE6R2xvYmFsX0lEOjpOb2RlX0lEOjpUdW5uZWxfTnVtOjpMU1BfTnVtLCBzaW1pbGFy bHkgDQp0aGUgTUVQX0lEIG9mIFo5IGlzIFo5Okdsb2JhbF9JRDo6Tm9kZV9JRDo6VHVubmVsX051 bTo6TFNQX051bS4NCg0KQ29uc2lkZXIgdGhhdCBDQy1WIHBhY2tldHMgYXJlIHNlbnQgZnJvbSBa OSB0byBBMSwgTUVQX0lEIG9mIFo5IGlzIA0KaW5zZXJ0ZWQgaW4gdGhlIENDLVYgcGFja2V0cy4N Cg0KVGhlIE1pcy1Db25uZWN0aXZpdHkgRGVmZWN0IChSRkM2MzcxKSBpcyBkZWNsYXJlZCBiYXNl ZCBvbiB0aGUgY29tcGFyaXNvbiANCm9mIGV4cGVjdGVkIE1FUF9JRCBhbmQgcmVjZWl2ZWQgTUVQ X0lELCBzbyBBMSBuZWVkcyB0byBwcmUtc3RvcmUgdGhlIA0KTUVQX0lEIG9mIFo5Lg0KDQpGb3Ig c3RhdGljIExTUCwgdGhlIGV4Y2hhbmdlcyBvZiBMU1AgaWRlbnRpZmVycyBjYW4gYmUgcmVhbGl6 ZWQgYnkgdGhlIEdBUCANCihHLUFDaCBBZHZlcnRpc2VtZW50IFByb3RvY29sKSBwcm90b2NvbCBk ZWZpbmVkIGluIHRoZSBkcmFmdCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtbXBscy1nYWNoLWFkdi0wMC4gQXMgdG8gZHluYW1pY2FsbHkgDQplc3RhYmxpc2hlZCBMU1As IHdoaWNoIGNhbiBiZSBjYXJyaWVkIGluIHRoZSBzaWduYWxpbmcgbWVzc2FnZS4NCg0KSSBhbSBu b3Qgc3VyZSB3aGV0aGVyIHRoZSBpbnRlcnByZXRhdGlvbiBpcyByZWFzb25hYmxlIHRvIHlvdS4N Cg0KQmVzdCByZWdhcmRzDQoNCkZlaQ0KDQoNCg0KRnJhbmNlc2NvIEZvbmRlbGxpIDxmcmFuY2Vz Y28uZm9uZGVsbGlAZ21haWwuY29tPiANCjIwMTItMDItMDcgMTY6NTYNCg0KytW8/sjLDQp6aGFu Zy5mZWkzQHp0ZS5jb20uY24NCrOty80NClZlcm8gWmhlbmcgPHZlcm8uemhlbmdAaHVhd2VpLmNv bT4sICJjY2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPg0K1vfM4g0KUmU6IFtDQ0FNUF0g RGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRA0KDQoNCg0KDQoNCg0KDQpB bSBJIHRoZSBvbmx5IG9uZSBoZXJlIHRoYXQgZmVlbHMgInVuY29tZm9ydGFibGUiIHdpdGggdGhp cyBhcHByb2FjaCBhbmQgDQp0aGlzIGFkZGl0aW9uYWwgWjktVHVubmVsX051bSBpbmRleCBpbiBH TVBMUyBmbHlpbmcgZnJvbSBlZ3Jlc3MgdG8gaW5ncmVzcyANCihmb3Igbm8gcmVhc29uPyE/KT8g SXQgbWlnaHQgYmUgbmFpdmUgb3IgZXZlbiBzdHVwaWQgYnV0IEknZCBsaWtlIHRvIA0KdW5kZXJz dGFuZCB3aHkgd2UgaGF2ZSB0byBhZGQgYW5vdGhlciBpbmRleC4uLiBwbGVhc2Ugc2hlZCBzb21l IGxpZ2h0IG9uIA0KbWUuDQoNCltJJ20gdGFsa2luZyBhYm91dCBjby1yb3V0ZWQgYmlkaSwgSSBk b24ndCBjYXJlIGFib3V0IGFzc29jaWF0ZWRdDQoNCnRoYW5rIHlvdQ0KY2lhbw0KRkYNCg0KMjAx Mi8yLzcgPHpoYW5nLmZlaTNAenRlLmNvbS5jbj4NCg0KVmVybyANCg0KV2h5IGlzIHR1bm5lbCBu dW1iZXIgbm90IGtub3duIGJ5IG5vZGUgQT8gVGhlIHR1bm5lbCBudW1iZXIgc2hvdWxkIGhhcyAN CmJlZW4gY2FycmllZCBpbiBTZXNzaW9uIGFuZCBTZW5kZXIgVGVtcGxhdGUvRmlsdGVyIFNwZWMg b2JqZWN0IGFuZCANCmV4Y2hhbmdlZCBieSBub2RlIEEgYW5kIG5vZGUgWiBkdXJpbmcgdGhlIExT UCBzZXQtdXAuIENvcnJlY3QgbWUgaWYgSSBhbSANCndyb25nLiANCg0KQWNjb3JkaW5nIHRvIHRo ZSBkZXNjcmlwdGlvbiBvZiBSRkM2MzcwLCBzZWN0aW9uIDUuMSANCiAgIEF0IGVhY2ggZW5kIHBv aW50LCBhIHR1bm5lbCBpcyB1bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSBlbmQgcG9pbnQncw0K ICBOb2RlX0lEIGFuZCBhIGxvY2FsbHkgYXNzaWduZWQgdHVubmVsIG51bWJlci4gIFNwZWNpZmlj YWxseSwgYQ0KICAiVHVubmVsIE51bWJlciIgKFR1bm5lbF9OdW0pIGlzIGEgMTYtYml0IHVuc2ln bmVkIGludGVnZXIgdW5pcXVlDQogIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgTm9kZV9JRC4g IFRoZSBtb3RpdmF0aW9uIGZvciBlYWNoIGVuZCBwb2ludA0KICBoYXZpbmcgaXRzIG93biB0dW5u ZWwgbnVtYmVyIGlzIHRvIGFsbG93IGEgY29tcGFjdCBmb3JtIGZvciB0aGUNCiAgTUVQX0lELiAN Cg0KV2hpY2ggbWVhbnMgdGhhdCBmb3IgY28tcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AsIHRoZXJl IGFyZSB0d28gdHVubmVsIA0KbnVtYmVycywgb25lIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQgbm9k ZSBBIGFuZCB0aGUgb3RoZXIgaXMgbG9jYWxseSANCmFzc2lnbmVkIGF0IG5vZGUgWi4gDQpJZiB0 aGUgc2lnbmFsaW5nIG1lc3NhZ2UgaXMgaW5pdGlhbGl6ZWQgYXQgbm9kZSBBLCB0aGUgdHVubmVs IG51bWJlciANCmNhcnJpZWQgaW4gU2Vzc2lvbi9TZW5kZXIgVGVtcGxhdGUgb2JqZWN0cyBpcyBs b2NhbGx5IGFzc2lnbmVkIGF0IG5vZGUgQS4gDQpPZiBjb3Vyc2UsIGEgbmV3IA0KQy10eXBlLGxp a2UgdHlwZT04LCBjYW4gYmUgZGVmaW5lZCBpbiB0aGUgY2xhc3Mgb2YgU0VTU0lPTiB0byBjYXJy eSBiYWNrIA0KdGhlIHR1bm5lbCBudW1iZXIgYXNzaWduZWQgYXQgbm9kZSBaOyBidXQgYWNjb3Jk aW5nIHRvIHRoZSBkaXNjdXNzaW9uIHdpdGggDQpHZW9yZ2UsIEkgZG8gbm90IHRoaW5rIGl0IGlz IGEgZ29vZCBpZGVhIHdoaWNoIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlLiANCg0KDQpSZWdh cmRzIA0KDQpGZWkgDQoNCg0KDQpWZXJvIFpoZW5nIDx2ZXJvLnpoZW5nQGh1YXdlaS5jb20+IA0K MjAxMi0wMi0wNyAxNTozMyANCg0KDQrK1bz+yMsNCiJ6aGFuZy5mZWkzQHp0ZS5jb20uY24iIDx6 aGFuZy5mZWkzQHp0ZS5jb20uY24+IA0Ks63LzQ0KImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0 Zi5vcmc+IA0K1vfM4g0KUkU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkgdGhl IEdsb2JhbF9JRA0KDQoNCg0KDQoNCg0KDQoNCkZlaSwgDQogIA0KUGxlYXNlIHNlZSBpbi1saW5l LiANCiAgDQpCUiwgDQpWZXJvIA0KICANCkZlaSwgDQogDQp5b3Ugd3JvdGU6IA0KIA0KRmlyc3Qs IA0KobAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMt dHAtb2lvLTAxIA0KDQpUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19PcGVyYXRvcl9J RCBPYmplY3QgYXJlIGRlZmluZWQgaW4gdGhpcyANCmRyYWZ0LCAgd2hpY2ggZGVzY3JpYmVzIHRo ZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgDQooYXNzb2NpYXRlZCBi aWRpcmVjdGlvbmFsIExTUCBpcyBub3QgY292ZXJlZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uKSBh bmQgDQpyZXF1aXJlcyB0aGF0IHRoZSBzYW1lIGZvcm1hdCggR2xvYmFsX0lEIG9yIElDQ19PcGVy YXRvcl9JRClpcyB1c2VkIGFsb25nIA0KdGhlIExTUC4gDQoNCldoaWNoIGlzIG5vdCB0cnVlLiBU aGUgT2JqZWN0IHdlIGRlZmluZWQgY291bGQgYmUgY2FycmllZCBpbiBib3RoIA0KUGF0aC9SZXN2 IG1lc3NhZ2UsIGFuZCBpcyBub3QgcmVzdHJpY3RlZCBlaXRoZXIgdG8gY28tcm91dGVkIA0KYmkt ZGlyZWN0aW9uYWwgTFNQIG9yIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uYWwgTFNQLiANCg0KPGZl aT4gDQpBbHRob3VnaCBlaXRoZXIgY28tcm91dGVkIG9yIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBMU1AgaXMgbm90IG1lbnRpb25lZCANCmluIHRoaXMgZHJhZnQgLCBhY2NvcmRpbmcgdG8gIHRo ZSBkZXNjcmlwaXRpb24gaW4gc2VjdGlvbiAyLjMsICIgSWYgdGhlIA0Kbm9kZSBhZ3JlZXMsIGl0 IE1VU1QgdXNlIHRoZSBzYW1lIGZvcm1hdCBvZiBPcGVyYXRvciBJRC4gIFRoZSBzYW1lIEMtVHlw ZSANCm9mIE9JTyBNVVNUIGJlIGNhcnJpZWQgaW4gdGhlIFJlc3YgbWVzc2FnZSIsIHdoaWNoIG1l YW5zIHRoYXQgIHRoZSANCnByb2NlZHVyZSBpcyBmb3IgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExT UC4gDQpUaGUgYWJvdmUgaXMganVzdCBteSB1bmRlcnN0YW5kaW5nIGFuZCBwcm92aWRlZCBmb3Ig ZGlzY3Vzc2lvbiwgYW5kIGlmIGl0IA0KaXMgd3Jvbmcgb3IgaW5hY2N1cmF0ZSwgcGxlYXNlIGxl dCBtZSBrbm93LiANCjwvZmVpPiANClRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGFib3ZlIGFpbXMg dG8gZ3VhcmFudGVlIHRoZSBzZW5kZXIgYW5kIHRoZSANCnJlY2VpdmVyIHVzaW5nIHRoZSBzYW1l IEMtVHlwZSBvZiB0aGUgb2JqZWN0LCBpLmUuIGJvdGggZW5kIHVzaW5nIA0KR2xvYmFsX0lEIG9y IGJvdGggdXNpbmcgSUNDX09wZXJhdG9yX0lELiANCiAgDQpTZWNvbmQsIA0KMy4gDQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQt dHVubmVsLW51bS0wMSANCg0KDQpUaGUgR2xvYmFsX0lEIGlzIGNhcnJpZWQgYXMgYSBUTFYgb2Yg dGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaCB3aWxsIA0KYXBwZWFyIGluIHRoZSBQYXRo L1Jlc3YgbWVzc2FnZSBvZiBjb3JvdXRlZCBiaWRyZWN0aW9uYWwgTFNQIGFuZCBvbmx5IA0KYXBw ZWFyIGluIHRoZSBQYXRoIG1lc3NhZ2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUC4g RnVydGhlcm1vcmUsIA0KdGhpcyBkcmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0 byBjYXJyeSB0aGUgbG9jYWwgdHVubmVsIG51bWJlciANCmFzc2lnbmVkIGF0IFo5IG5vZGVzIGlu IHRoZSBzY2VuYXJpbyBvZiBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gDQogDQpXaHkgobB0 dW5uZWwgbnVtYmVyobEgaXMgY2FycmllZCBpbiB0aGUgQ29ubmVjdGlvbiBUTFY/IEkgZG9uJ3Qg c2VlIGl0cyANCm5lY2Vzc2FyeSBmb3IgYm90aCBjby1yb3V0ZS8gYXNzb2NpYXRlZCBiaS1kaXJl Y3Rpb25hbCBMU1AuIENvdWxkIHlvdSANCmV4cGxhaW4/IA0KIA0KPGZlaT4gDQpBcyBJIHNhaWQs IGl0IGlzIHVzZWZ1bCBmb3IgY29yb3V0ZWQgKG5vdCBhc3NvY2lhdGVkKSBiaWRpcmVjdGlvbmFs IExTUCwgDQogY29uc2lkZXIgdGhhdCB0aGVyZSBpcyBvbmUgTFNQIChMU1AxLCBpbml0aWF0ZWQg YXQgbm9kZSBBKSBiZXR3ZWVuIG5vZGUgDQpBL1ouIA0KSWYgdGhlIENDLVYgcGFrY2V0IGlzICBz ZW50IGZyb20gIG5vZGUgWiwgdGhlIE1FUF9JRCBvZiBub2RlIFogd2lsbCBiZSANCmluc2VydGVk IGluIHRoZSBPQU0gcGFja2V0cywgd2hpY2ggaXMgb3JnYW5pemVkIGJ5IA0Kbm9kZV9JRDo6dHVu bmVsX251bTo6TFNQX251bSANCihzZWN0aW9uIDUuMi4xIG9yIDcuMi4yIG9mIFJGQzYzNzApLCBh bmQgaWYgdGhpcyBNRVBfSUQgaXMgbm90IHByZS1zdG9yZWQgDQphdCBub2RlIEEsIGl0IGNhbiBu b3QganVkZ2Ugd2hldGhlciB0aGlzIE1FUF9JRCBpcyB2YWxpZC4gU2VlIHRoZSANCmRlc2NyaXB0 aW9uIGluIHNlY3Rpb24gNS4xLjEuMiANCihNaXMtQ29ubmVjdGl2aXR5IERlZmVjdCkgb2YgUkZD NjM3MS4gDQogICAgICAgICAgICAgICAgICBMU1AxIA0KQS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS1aIA0KDQoNCjwvZmVpPiANCldoeSBpcyB0dW5uZWwgbnVtYmVyIG5vdCBrbm93biBi eSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZCBoYXMgDQpiZWVuIGNhcnJpZWQgaW4g U2Vzc2lvbiBhbmQgU2VuZGVyIFRlbXBsYXRlL0ZpbHRlciBTcGVjIG9iamVjdCBhbmQgDQpleGNo YW5nZWQgYnkgbm9kZSBBIGFuZCBub2RlIFogZHVyaW5nIHRoZSBMU1Agc2V0LXVwLiBDb3JyZWN0 IG1lIGlmIEkgYW0gDQp3cm9uZy4gDQogIA0KQlIsIA0KVmVybyANCg0KVGhhbmtzLiANCiANClZl cm8gDQogDQogDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KemhhbmcuZmVpM0B6dGUuY29tLmNuDQpTZW50 OiBTdW5kYXksIEphbnVhcnkgMjksIDIwMTIgNTo1MCBQTQ0KVG86IGNjYW1wQGlldGYub3JnDQpT dWJqZWN0OiBbQ0NBTVBdIERpc2N1c3Npb24gb24gaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQg DQogDQoNCkhpIENDQU1QZXJzIA0KDQpBcyBkaXNjdXNzZWQgaW4gdGhlIGxhc3QgSUVURiBtZWV0 aW5nIGFuZCBtYWlsaW5nbGlzdCwgdGhlIEdsb2JhbF9JRCANCnNob3VsZCBiZSBjYXJyaWVkIGlu IHRoZSBzaWduYWxpbmcgbWVzc2FnZXMuIE9uZSByZWFzb24gaXMgdGhhdCB0aGUgDQpqdWRnZW1l bnQgb2YgYSBtaXMtY29ubmVjdGl2aXR5IGRlZmVjdCBuZWVkcyB0aGUgQTEvWjkgbm9kZXMgdG8g cHJlLXN0b3JlIA0KZWFjaCBvdGhlcidzIE1FUF9JRCwgd2hvc2UgZm9ybWF0IGlzOiBHb2JhbF9J RCtOb2RlX0lEK1R1bm5lbF9udW0rTFNQX251bS4gDQoNCg0KRm9ydHVuYXRlbHksIHRoZXJlIGFy ZSBzZXZlcmFsIGRyYWZ0cyByZWxhdGVkIHRvIHRoaXMgdG9waWMgbm93LCANCg0KMS4gIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAxLiANCiAg DQpUaGUgR2xvYmFfSUQgaXMgaW5jb3Jwb3JhdGVkIGludG8gdGhlIEFTU09DSUFUSU9OIG9iamVj dCBpbiB0aGUgY3VycmVudCANCnZlcnNpb24sIHdoaWNoIGd1YXJhbnRlZXMgdGhhdCB0aGUgYXNz b2NpYXRpb24gaXMgZ2xvYmFsIHVuaXF1ZS4gU2luY2UgdGhlIA0KQVNTT0NJQVRJT04gb2JqZWN0 IGlzIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBMU1BzLCBqdXN0IG15MmNlbnRzLCB0aGUgDQpkZWZp bmVkIGZvcm1hdCBpcyBkZWZpY2llbnQgdG8gaGFuZGxlIG1vcmUgc2NlbmFyaW9zLiBGb3IgZXhh bXBsZTogDQoNCiAgKDEpIENvbnNpZGVyaW5nIGEgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1As IHdoaWNoIGlzIG5vdCBwcm90ZWN0ZWQgYnkgDQpvdGhlciBMU1BzIHRocm91Z2ggY29udHJvbCBw bGFuZSBhbmQvb3IgZG9lcyBub3Qgc2hhcmUgdGhlIHNhbWUgcmVzb3VyZXMgDQp3aXRoIG90aGVy IExTUHMuIEluIHRoZXNlIGNhc2VzLCB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IHdpbGwgbm90IGJl IA0KY2FycmllZCBpbiB0aGUgc2lnYWxpbmcgbWVzc2FnZXMuIA0KDQogICgyKSBDb25zaWRlcmlu ZyBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBhbHRob3VnaCB0aGUgDQpBU1NPQ0lB VElPTiBvYmplY3QgaXMgY2FycmllZCBpbiB0aGUgc2lnYWxpbmcgbWVzc2FnZXMsIHRoZSBnbG9i YWxfSUQgDQppbmNvcnBvcmF0ZWQgaW4gdGhlIEFTU09DSUFUSU9OIG9iamVjdCBvbmx5IA0KaW5k aWNhdGVzIHRoZSBnbG9iYWwgcHJlZml4IG9mIHRoZSBBMSBvciBaOSBub2Rlcy4gSWYgdGhpcyBM U1AgaXMgYWNyb3NzIA0KZGlmZmVyZW50IGRvbWFpbnMsIEkgdGhpbmsgdGhlIGN1cnJlbnQgZm9y bWF0IGlzIGFsc28gZGVmaWNpZW50IChBMSBkb2VzIA0Kbm90IGtub3cgdGhlIGdvYmFsIElEIG9m IFo5IG5vZGUgb3IgWjkgbm9kZXMgZG9lcyBub3Qga25vdyB0aGUgZ2xvYmFsIElEIA0Kb2YgQTEg KS4gDQoNCjIuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBs cy10cC1vaW8tMDEgDQoNClRoZSBHbG9iYWxfSUQgT2JqZWN0IGFuZCB0aGUgSUNDX09wZXJhdG9y X0lEIE9iamVjdCBhcmUgZGVmaW5lZCBpbiB0aGlzIA0KZHJhZnQsICB3aGljaCBkZXNjcmliZXMg dGhlIHByb2NlZHVyZSBvZiBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCANCihhc3NvY2lhdGVk IGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24p IGFuZCANCnJlcXVpcmVzIHRoYXQgdGhlIHNhbWUgZm9ybWF0KCBHbG9iYWxfSUQgb3IgSUNDX09w ZXJhdG9yX0lEKWlzIHVzZWQgYWxvbmcgDQp0aGUgTFNQLiANCg0KMy4gDQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVs LW51bS0wMSANCg0KDQpUaGUgR2xvYmFsX0lEIGlzIGNhcnJpZWQgYXMgYSBUTFYgb2YgdGhlIExT UF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaCB3aWxsIA0KYXBwZWFyIGluIHRoZSBQYXRoL1Jlc3Yg bWVzc2FnZSBvZiBjb3JvdXRlZCBiaWRyZWN0aW9uYWwgTFNQIGFuZCBvbmx5IA0KYXBwZWFyIGlu IHRoZSBQYXRoIG1lc3NhZ2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gRnVydGhl cm1vcmUsIA0KdGhpcyBkcmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJy eSB0aGUgbG9jYWwgdHVubmVsIG51bWJlciANCmFzc2lnbmVkIGF0IFo5IG5vZGVzIGluIHRoZSBz Y2VuYXJpbyBvZiBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gDQoNCg0KVGhlIGFib3ZlIG1h dGVyaWFscyBvbmx5IHByb3ZpZGUgdGhlIHJvdWdoIGJhY2tncm91bmQuIA0KDQoNCkhvcGUgdG8g aGVhciB0aGUgb3BpbmlvbnMgZnJvbSB0aGUgV0cgdGhhdCBob3cgdG8gY2FycnkgdGhlIEdsb2Jh bF9JRCwgDQp0aGVuIG1vdmUgdGhlIHdvcmsgZm9yd2FyZC4gDQoNCg0KQmVzdCByZWdhcmRzIA0K DQo7KSANCg0KRmVpIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0K --=_alternative 003423AA4825799D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZyYW5jZXNjbzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVsb3cgaXMgb25lIHVzZWNh c2UgYmFzZWQgb24gbXkgdW5kZXJzdGFuZGluZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkExLS0tLS0tLS0tLS0tLS0tLVo5IChjby1yb3V0ZWQpPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgTUVQX0lE IG9mIEExIGlzIEExOkdsb2JhbF9JRDo6Tm9kZV9JRDo6VHVubmVsX051bTo6TFNQX051bSwNCnNp bWlsYXJseSB0aGUgTUVQX0lEIG9mIFo5IGlzIFo5Okdsb2JhbF9JRDo6Tm9kZV9JRDo6VHVubmVs X051bTo6TFNQX051bS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkNvbnNpZGVyIHRoYXQgQ0MtViBwYWNrZXRzIGFyZSBzZW50DQpmcm9tIFo5IHRvIEEx LCBNRVBfSUQgb2YgWjkgaXMgaW5zZXJ0ZWQgaW4gdGhlIENDLVYgcGFja2V0cy48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBNaXMtQ29ubmVjdGl2 aXR5IERlZmVjdCAoUkZDNjM3MSkNCmlzIGRlY2xhcmVkIGJhc2VkIG9uIHRoZSBjb21wYXJpc29u IG9mIGV4cGVjdGVkIE1FUF9JRCBhbmQgcmVjZWl2ZWQgTUVQX0lELA0Kc28gQTEgbmVlZHMgdG8g cHJlLXN0b3JlIHRoZSBNRVBfSUQgb2YgWjkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5Gb3Igc3RhdGljIExTUCwgdGhlIGV4Y2hhbmdlcyBvZiBMU1AN CmlkZW50aWZlcnMgY2FuIGJlIHJlYWxpemVkIGJ5IHRoZSBHQVAgKEctQUNoIEFkdmVydGlzZW1l bnQgUHJvdG9jb2wpIHByb3RvY29sDQpkZWZpbmVkIGluIHRoZSBkcmFmdCBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtZ2FjaC1hZHYtMDAuDQpBcyB0byBkeW5hbWlj YWxseSBlc3RhYmxpc2hlZCBMU1AsIHdoaWNoIGNhbiBiZSBjYXJyaWVkIGluIHRoZSBzaWduYWxp bmcNCm1lc3NhZ2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5JIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIGludGVycHJldGF0aW9uDQppcyByZWFzb25h YmxlIHRvIHlvdS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkJlc3QgcmVnYXJkczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPkZyYW5jZXNjbyBGb25kZWxsaSAmbHQ7ZnJhbmNlc2NvLmZvbmRlbGxpQGdtYWls LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMi0wMi0wNyAxNjo1NjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj56aGFuZy5mZWkzQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PlZlcm8gWmhlbmcgJmx0O3Zlcm8uemhlbmdAaHVhd2VpLmNvbSZndDssDQomcXVvdDtjY2FtcEBp ZXRmLm9yZyZxdW90OyAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW0NDQU1QXSBEaXNjdXNzaW9uIG9uIGhvdyB0byBjYXJyeQ0KdGhlIEdsb2JhbF9JRDwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQpB bSBJIHRoZSBvbmx5IG9uZSBoZXJlIHRoYXQgZmVlbHMgJnF1b3Q7dW5jb21mb3J0YWJsZSZxdW90 OyB3aXRoIHRoaXMgYXBwcm9hY2gNCmFuZCB0aGlzIGFkZGl0aW9uYWwgWjktVHVubmVsX051bSBp bmRleCBpbiBHTVBMUyBmbHlpbmcgZnJvbSBlZ3Jlc3MgdG8NCmluZ3Jlc3MgKGZvciBubyByZWFz b24/IT8pPyBJdCBtaWdodCBiZSBuYWl2ZSBvciBldmVuIHN0dXBpZCBidXQgSSdkIGxpa2UNCnRv IHVuZGVyc3RhbmQgd2h5IHdlIGhhdmUgdG8gYWRkIGFub3RoZXIgaW5kZXguLi4gcGxlYXNlIHNo ZWQgc29tZSBsaWdodA0Kb24gbWUuPGJyPg0KPGJyPg0KW0knbSB0YWxraW5nIGFib3V0IGNvLXJv dXRlZCBiaWRpLCBJIGRvbid0IGNhcmUgYWJvdXQgYXNzb2NpYXRlZF08YnI+DQo8YnI+DQp0aGFu ayB5b3U8YnI+DQpjaWFvPGJyPg0KRkY8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjIw MTIvMi83ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9Mz4mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpWZXJvPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj0jYzAwMDAwIGZhY2U9IkNhbGlicmkiPjxicj4NCldoeSBpcyB0dW5uZWwg bnVtYmVyIG5vdCBrbm93biBieSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZCBoYXMN CmJlZW4gY2FycmllZCBpbiBTZXNzaW9uIGFuZCBTZW5kZXIgVGVtcGxhdGUvRmlsdGVyIFNwZWMg b2JqZWN0IGFuZCBleGNoYW5nZWQNCmJ5IG5vZGUgQSBhbmQgbm9kZSBaIGR1cmluZyB0aGUgTFNQ IHNldC11cC4gQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLjwvZm9udD48Zm9udCBzaXplPTM+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFjY29yZGlu ZyB0byB0aGUgZGVzY3JpcHRpb24gb2YgUkZDNjM3MCwgc2VjdGlvbiA1LjE8L2ZvbnQ+PGZvbnQg c2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQombmJz cDsgJm5ic3A7QXQgZWFjaCBlbmQgcG9pbnQsIGEgdHVubmVsIGlzIHVuaXF1ZWx5IGlkZW50aWZp ZWQgYnkgdGhlDQplbmQgcG9pbnQnczxicj4NCiZuYnNwOyBOb2RlX0lEIGFuZCBhIGxvY2FsbHkg YXNzaWduZWQgdHVubmVsIG51bWJlci4gJm5ic3A7U3BlY2lmaWNhbGx5LA0KYTxicj4NCiZuYnNw OyAmcXVvdDtUdW5uZWwgTnVtYmVyJnF1b3Q7IChUdW5uZWxfTnVtKSBpcyBhIDE2LWJpdCB1bnNp Z25lZCBpbnRlZ2VyDQp1bmlxdWU8YnI+DQombmJzcDsgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRo ZSBOb2RlX0lELiAmbmJzcDtUaGUgbW90aXZhdGlvbiBmb3IgZWFjaA0KZW5kIHBvaW50PGJyPg0K Jm5ic3A7IGhhdmluZyBpdHMgb3duIHR1bm5lbCBudW1iZXIgaXMgdG8gYWxsb3cgYSBjb21wYWN0 IGZvcm0gZm9yIHRoZTxicj4NCiZuYnNwOyBNRVBfSUQuIDwvZm9udD48Zm9udCBzaXplPTM+PGJy Pg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpXaGljaCBtZWFu cyB0aGF0IGZvciBjby1yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3byB0dW5u ZWwgbnVtYmVycywNCm9uZSBpcyBsb2NhbGx5IGFzc2lnbmVkIGF0IG5vZGUgQSBhbmQgdGhlIG90 aGVyIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQNCm5vZGUgWi48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCklmIHRoZSBzaWduYWxp bmcgbWVzc2FnZSBpcyBpbml0aWFsaXplZCBhdCBub2RlIEEsIHRoZSB0dW5uZWwgbnVtYmVyIGNh cnJpZWQNCmluIFNlc3Npb24vU2VuZGVyIFRlbXBsYXRlIG9iamVjdHMgaXMgbG9jYWxseSBhc3Np Z25lZCBhdCBub2RlIEEuIE9mIGNvdXJzZSwNCmEgbmV3PC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpDLXR5cGUsbGlrZSB0eXBl PTgsIGNhbiBiZSBkZWZpbmVkIGluIHRoZSBjbGFzcyBvZiBTRVNTSU9OIHRvIGNhcnJ5IGJhY2sN CnRoZSB0dW5uZWwgbnVtYmVyIGFzc2lnbmVkIGF0IG5vZGUgWjsgYnV0IGFjY29yZGluZyB0byB0 aGUgZGlzY3Vzc2lvbiB3aXRoDQpHZW9yZ2UsIEkgZG8gbm90IHRoaW5rIGl0IGlzIGEgZ29vZCBp ZGVhIHdoaWNoIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlLjwvZm9udD48Zm9udCBzaXplPTM+ DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClJlZ2Fy ZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCkZlaTwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCjwvZm9u dD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00 MSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlZlcm8gWmhlbmcgJmx0OzwvYj48 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tIHRhcmdldD1fYmxhbms+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PHU+dmVyby56aGVu Z0BodWF3ZWkuY29tPC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMTItMDItMDcgMTU6MzM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRkIHdp ZHRoPTU4JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MTAlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg5JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNv bS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcu ZmVpM0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5v cmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5vcmcg dGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtD Q0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkNCnRoZSBHbG9iYWxfSUQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpGZWksPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxm b250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpQbGVhc2Ugc2VlIGluLWxpbmUuPC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBm YWNlPSJDYWxpYnJpIj48YnI+DQpCUiw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVmVybzwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KRmVpLDwvZm9udD48Zm9udCBzaXplPTM+ IDxicj4NCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQp5b3Ugd3JvdGU6PC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KJm5ic3A7PC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCkZpcnN0 LCA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQqhsDIuIDwvZm9udD48YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMtdHAt b2lvLTAxIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IkFyaWFs Ij48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMtdHAt b2lvLTAxPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjxicj4NCjxi cj4NClRoZSBHbG9iYWxfSUQgT2JqZWN0IGFuZCB0aGUgSUNDX09wZXJhdG9yX0lEIE9iamVjdCBh cmUgZGVmaW5lZCBpbiB0aGlzDQpkcmFmdCwgJm5ic3A7d2hpY2ggZGVzY3JpYmVzIHRoZSBwcm9j ZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCihhc3NvY2lhdGVkIGJpZGlyZWN0 aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24pIGFuZA0KcmVx dWlyZXMgdGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvciBJQ0NfT3BlcmF0b3JfSUQp aXMgdXNlZCBhbG9uZw0KdGhlIExTUC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQo8YnI+DQpXaGljaCBpcyBub3QgdHJ1ZS4gVGhlIE9iamVjdCB3ZSBkZWZpbmVkIGNv dWxkIGJlIGNhcnJpZWQgaW4gYm90aCBQYXRoL1Jlc3YNCm1lc3NhZ2UsIGFuZCBpcyBub3QgcmVz dHJpY3RlZCBlaXRoZXIgdG8gY28tcm91dGVkIGJpLWRpcmVjdGlvbmFsIExTUCBvcg0KYXNzb2Np YXRlZCBiaS1kaXJlY3Rpb25hbCBMU1AuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjxicj4NCiZsdDtmZWkm Z3Q7PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdk IGZhY2U9IkNhbGlicmkiPjxicj4NCkFsdGhvdWdoIGVpdGhlciBjby1yb3V0ZWQgb3IgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBub3QgbWVudGlvbmVkDQppbiB0aGlzIGRyYWZ0ICwg YWNjb3JkaW5nIHRvICZuYnNwO3RoZSBkZXNjcmlwaXRpb24gaW4gc2VjdGlvbiAyLjMsICZxdW90 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJyaSI+DQpJZiB0aGUgbm9kZSBhZ3JlZXMs IGl0IE1VU1QgdXNlIHRoZSBzYW1lIGZvcm1hdCBvZiBPcGVyYXRvciBJRC4gJm5ic3A7VGhlDQpz YW1lIEMtVHlwZSBvZiBPSU8gTVVTVCBiZSBjYXJyaWVkIGluIHRoZSBSZXN2IG1lc3NhZ2U8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+JnF1b3Q7LA0Kd2hp Y2ggbWVhbnMgdGhhdCAmbmJzcDt0aGUgcHJvY2VkdXJlIGlzIGZvciBjb3JvdXRlZCBiaWRyZWN0 aW9uYWwgTFNQLjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhlIGFib3ZlIGlzIGp1c3QgbXkgdW5kZXJz dGFuZGluZyBhbmQgcHJvdmlkZWQgZm9yIGRpc2N1c3Npb24sIGFuZCBpZg0KaXQgaXMgd3Jvbmcg b3IgaW5hY2N1cmF0ZSwgcGxlYXNlIGxldCBtZSBrbm93LjwvZm9udD48Zm9udCBzaXplPTM+IDwv Zm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQombHQ7 L2ZlaSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSNj MDAwMDAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVGhlIHByb2NlZHVyZSBkZXNjcmliZWQgYWJvdmUg YWltcyB0byBndWFyYW50ZWUgdGhlIHNlbmRlciBhbmQgdGhlIHJlY2VpdmVyDQp1c2luZyB0aGUg c2FtZSBDLVR5cGUgb2YgdGhlIG9iamVjdCwgaS5lLiBib3RoIGVuZCB1c2luZyBHbG9iYWxfSUQg b3IgYm90aA0KdXNpbmcgSUNDX09wZXJhdG9yX0lELjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQombmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFj ZT0iQ2FsaWJyaSI+PGJyPg0KU2Vjb25kLCA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij48YnI+DQozLiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDEiIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC10dW5u ZWwtbnVtLTAxPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpUaGUgR2xv YmFsX0lEIGlzIGNhcnJpZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3 aGljaCB3aWxsDQphcHBlYXIgaW4gdGhlIFBhdGgvUmVzdiBtZXNzYWdlIG9mIGNvcm91dGVkIGJp ZHJlY3Rpb25hbCBMU1AgYW5kIG9ubHkgYXBwZWFyDQppbiB0aGUgUGF0aCBtZXNzYWdlIG9mIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIEZ1cnRoZXJtb3JlLCB0aGlzDQpkcmFmdCBkZWZp bmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUgbG9jYWwgdHVubmVsIG51bWJl ciBhc3NpZ25lZA0KYXQgWjkgbm9kZXMgaW4gdGhlIHNjZW5hcmlvIG9mIGNvcm91dGVkIGJpZGly ZWN0aW9uYWwgTFNQLjwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQombmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KV2h5IKGwdHVubmVs IG51bWJlcqGxIGlzIGNhcnJpZWQgaW4gdGhlIENvbm5lY3Rpb24gVExWPyBJIGRvbid0IHNlZSBp dHMNCm5lY2Vzc2FyeSBmb3IgYm90aCBjby1yb3V0ZS8gYXNzb2NpYXRlZCBiaS1kaXJlY3Rpb25h bCBMU1AuIENvdWxkIHlvdSBleHBsYWluPzwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQombmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K Jmx0O2ZlaSZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KQXMgSSBzYWlkLCBpdCBpcyB1c2VmdWwgZm9y IGNvcm91dGVkIChub3QgYXNzb2NpYXRlZCkgYmlkaXJlY3Rpb25hbCBMU1AsDQombmJzcDtjb25z aWRlciB0aGF0IHRoZXJlIGlzIG9uZSBMU1AgKExTUDEsIGluaXRpYXRlZCBhdCBub2RlIEEpIGJl dHdlZW4NCm5vZGUgQS9aLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMg Y29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpJZiB0aGUgQ0MtViBwYWtjZXQgaXMg Jm5ic3A7c2VudCBmcm9tICZuYnNwO25vZGUgWiwgdGhlIE1FUF9JRCBvZiBub2RlDQpaIHdpbGwg YmUgaW5zZXJ0ZWQgaW4gdGhlIE9BTSBwYWNrZXRzLCB3aGljaCBpcyBvcmdhbml6ZWQgYnkgbm9k ZV9JRDo6dHVubmVsX251bTo6TFNQX251bQ0KPGJyPg0KKHNlY3Rpb24gNS4yLjEgb3IgNy4yLjIg b2YgUkZDNjM3MCksIGFuZCBpZiB0aGlzIE1FUF9JRCBpcyBub3QgcHJlLXN0b3JlZA0KYXQgbm9k ZSBBLCBpdCBjYW4gbm90IGp1ZGdlIHdoZXRoZXIgdGhpcyBNRVBfSUQgaXMgdmFsaWQuIFNlZSB0 aGUgZGVzY3JpcHRpb24NCmluIHNlY3Rpb24gNS4xLjEuMjwvZm9udD48Zm9udCBzaXplPTM+IDwv Zm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQooPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj48Yj5NaXMtQ29ubmVjdGl2aXR5IERlZmVj dDwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+KQ0K b2YgUkZDNjM3MS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9y PSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTFNQMTwvZm9udD48Zm9udCBzaXpl PTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KQS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1aPC9mb250Pjxmb250IHNpemU9Mz4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxi cj4NCjxicj4NCiZsdDsvZmVpJmd0OzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBz aXplPTMgY29sb3I9I2MwMDAwMCBmYWNlPSJDYWxpYnJpIj48YnI+DQpXaHkgaXMgdHVubmVsIG51 bWJlciBub3Qga25vd24gYnkgbm9kZSBBPyBUaGUgdHVubmVsIG51bWJlciBzaG91bGQgaGFzDQpi ZWVuIGNhcnJpZWQgaW4gU2Vzc2lvbiBhbmQgU2VuZGVyIFRlbXBsYXRlL0ZpbHRlciBTcGVjIG9i amVjdCBhbmQgZXhjaGFuZ2VkDQpieSBub2RlIEEgYW5kIG5vZGUgWiBkdXJpbmcgdGhlIExTUCBz ZXQtdXAuIENvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jYzAwMDAwIGZhY2U9IkNhbGlicmkiPjxicj4NCiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9I2MwMDAwMCBm YWNlPSJDYWxpYnJpIj48YnI+DQpCUiw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGNvbG9yPSNjMDAwMDAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVmVybzwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp Ij48YnI+DQo8YnI+DQpUaGFua3MuPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KJm5ic3A7PC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClZlcm88 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQombmJzcDs8YnI+DQombmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KRnJvbTo8L2I+IDwvZm9udD48YSBocmVmPSJt YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGFob21hIj4NClttYWlsdG86PC9mb250PjxhIGhy ZWY9Im1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUYWhvbWEiPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbiB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+emhhbmcuZmVp M0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRhaG9tYSI+PGI+ PGJyPg0KU2VudDo8L2I+IFN1bmRheSwgSmFudWFyeSAyOSwgMjAxMiA1OjUwIFBNPGI+PGJyPg0K VG86PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmNjYW1wQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KU3ViamVj dDo8L2I+IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRDwv Zm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkFyaWFsIj48YnI+DQo8YnI+DQpIaSBDQ0FNUGVyczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0K PGJyPg0KQXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IElFVEYgbWVldGluZyBhbmQgbWFpbGluZ2xp c3QsIHRoZSBHbG9iYWxfSUQgc2hvdWxkDQpiZSBjYXJyaWVkIGluIHRoZSBzaWduYWxpbmcgbWVz c2FnZXMuIE9uZSByZWFzb24gaXMgdGhhdCB0aGUganVkZ2VtZW50DQpvZiBhIG1pcy1jb25uZWN0 aXZpdHkgZGVmZWN0IG5lZWRzIHRoZSBBMS9aOSBub2RlcyB0byBwcmUtc3RvcmUgZWFjaCBvdGhl cidzDQpNRVBfSUQsIHdob3NlIGZvcm1hdCBpczogR29iYWxfSUQrTm9kZV9JRCtUdW5uZWxfbnVt K0xTUF9udW0uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KRm9ydHVuYXRlbHksIHRo ZXJlIGFyZSBzZXZlcmFsIGRyYWZ0cyByZWxhdGVkIHRvIHRoaXMgdG9waWMgbm93LDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjEuICZuYnNwOzwvZm9udD48YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wMSIgdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDE8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+ DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NClRoZSBHbG9iYV9JRCBpcyBpbmNvcnBv cmF0ZWQgaW50byB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGluIHRoZSBjdXJyZW50DQp2ZXJzaW9u LCB3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIGFzc29jaWF0aW9uIGlzIGdsb2JhbCB1bmlxdWUu IFNpbmNlDQp0aGUgQVNTT0NJQVRJT04gb2JqZWN0IGlzIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBM U1BzLCBqdXN0IG15MmNlbnRzLCB0aGUNCmRlZmluZWQgZm9ybWF0IGlzIGRlZmljaWVudCB0byBo YW5kbGUgbW9yZSBzY2VuYXJpb3MuIEZvciBleGFtcGxlOjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxi cj4NCjxicj4NCiZuYnNwOyAoMSkgQ29uc2lkZXJpbmcgYSBjb3JvdXRlZCBiaWRpcmVjdGlvbmFs IExTUCwgd2hpY2ggaXMgbm90IHByb3RlY3RlZA0KYnkgb3RoZXIgTFNQcyB0aHJvdWdoIGNvbnRy b2wgcGxhbmUgYW5kL29yIGRvZXMgbm90IHNoYXJlIHRoZSBzYW1lIHJlc291cmVzDQp3aXRoIG90 aGVyIExTUHMuIEluIHRoZXNlIGNhc2VzLCB0aGUgQVNTT0NJQVRJT04gb2JqZWN0IHdpbGwgbm90 IGJlIGNhcnJpZWQNCmluIHRoZSBzaWdhbGluZyBtZXNzYWdlcy4gPGJyPg0KPGJyPg0KJm5ic3A7 ICgyKSBDb25zaWRlcmluZyBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBhbHRob3Vn aCB0aGUgQVNTT0NJQVRJT04NCm9iamVjdCBpcyBjYXJyaWVkIGluIHRoZSBzaWdhbGluZyBtZXNz YWdlcywgdGhlIGdsb2JhbF9JRCBpbmNvcnBvcmF0ZWQNCmluIHRoZSBBU1NPQ0lBVElPTiBvYmpl Y3Qgb25seTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCmluZGljYXRlcyB0aGUgZ2xvYmFsIHBy ZWZpeCBvZiB0aGUgQTEgb3IgWjkgbm9kZXMuIElmIHRoaXMgTFNQIGlzIGFjcm9zcw0KZGlmZmVy ZW50IGRvbWFpbnMsIEkgdGhpbmsgdGhlIGN1cnJlbnQgZm9ybWF0IGlzIGFsc28gZGVmaWNpZW50 IChBMSBkb2VzDQpub3Qga25vdyB0aGUgZ29iYWwgSUQgb2YgWjkgbm9kZSBvciBaOSBub2RlcyBk b2VzIG5vdCBrbm93IHRoZSBnbG9iYWwgSUQNCm9mIEExICkuPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48 YnI+DQo8YnI+DQoyLiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2hlbi1jY2FtcC1tcGxzLXRwLW9pby0wMSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2hlbi1jY2FtcC1tcGxzLXRwLW9pby0wMTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MyBmYWNlPSJBcmlhbCI+DQo8YnI+DQo8YnI+DQpUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhl IElDQ19PcGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQgaW4gdGhpcw0KZHJhZnQsICZuYnNw O3doaWNoIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlIG9mIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwg TFNQDQooYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBub3QgY292ZXJlZCBpbiB0aGUg Y3VycmVudCB2ZXJzaW9uKSBhbmQNCnJlcXVpcmVzIHRoYXQgdGhlIHNhbWUgZm9ybWF0KCBHbG9i YWxfSUQgb3IgSUNDX09wZXJhdG9yX0lEKWlzIHVzZWQgYWxvbmcNCnRoZSBMU1AuPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkFyaWFsIj48YnI+DQo8YnI+DQozLiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1u dW0tMDEiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwi Pjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLW1wbHMtdHAt cnN2cHRlLWV4dC10dW5uZWwtbnVtLTAxPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+ DQo8YnI+DQpUaGUgR2xvYmFsX0lEIGlzIGNhcnJpZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRS SUJVVEUgb2JqZWN0LCB3aGljaCB3aWxsDQphcHBlYXIgaW4gdGhlIFBhdGgvUmVzdiBtZXNzYWdl IG9mIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AgYW5kIG9ubHkgYXBwZWFyDQppbiB0aGUgUGF0 aCBtZXNzYWdlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIEZ1cnRoZXJtb3JlLCB0 aGlzDQpkcmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUgbG9j YWwgdHVubmVsIG51bWJlciBhc3NpZ25lZA0KYXQgWjkgbm9kZXMgaW4gdGhlIHNjZW5hcmlvIG9m IGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxi cj4NCjxicj4NClRoZSBhYm92ZSBtYXRlcmlhbHMgb25seSBwcm92aWRlIHRoZSByb3VnaCBiYWNr Z3JvdW5kLiA8YnI+DQo8YnI+DQo8YnI+DQpIb3BlIHRvIGhlYXIgdGhlIG9waW5pb25zIGZyb20g dGhlIFdHIHRoYXQgaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQsDQp0aGVuIG1vdmUgdGhlIHdv cmsgZm9yd2FyZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQo8YnI+DQpCZXN0IHJl Z2FyZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjspPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFs Ij48YnI+DQo8YnI+DQpGZWk8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNDQU1QIG1haWxp bmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250 PjxhIGhyZWY9bWFpbHRvOkNDQU1QQGlldGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1 PkNDQU1QQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2NhbXAgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 003423AA4825799D_=-- From francesco.fondelli@gmail.com Tue Feb 7 05:14:21 2012 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 3430F21F87B4 for ; Tue, 7 Feb 2012 05:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gMqhnRDgJzWf for ; Tue, 7 Feb 2012 05:14:19 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B75521F8790 for ; Tue, 7 Feb 2012 05:14:19 -0800 (PST) Received: by ghbg16 with SMTP id g16so3545311ghb.31 for ; Tue, 07 Feb 2012 05:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ppLN9UnBqF/xdOYtjolWyVnQkskylrVdxBORtWLszcQ=; b=bQWgff6FeYL/YXu3d+XrujVtyqZYA1WHsl1hv+UcEXEogAF4tgLW56nZBRI7uBXiLz KmSCA724ClM/B7umgf/9h8mqjOdiw46WXjGE4mE30COvhFsC1sFYbwstSifyUyIjRikD FvJrjuMYMJdZ9P7AdFeZIVwOKWb5g+lJ0U6WA= MIME-Version: 1.0 Received: by 10.101.157.32 with SMTP id j32mr7916802ano.51.1328620458908; Tue, 07 Feb 2012 05:14:18 -0800 (PST) Received: by 10.236.155.103 with HTTP; Tue, 7 Feb 2012 05:14:18 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Feb 2012 14:14:18 +0100 Message-ID: From: Francesco Fondelli To: zhang.fei3@zte.com.cn Content-Type: multipart/alternative; boundary=0016e68fd04f7e9ccd04b85f8eb5 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 13:14:21 -0000 --0016e68fd04f7e9ccd04b85f8eb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, if this is the only use case I strongly suggest you to make anything related to Z9-Tunnel_Num OPTIONAL in signaling (dunno if this is the case in your I-D). Please. BTW, I'm wondering... if this is just about MEP ID what's the relation of your I-D and this one: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-07 Why not simply assume that A1-Tunnel_Num =3D=3D Z9-Tunnel_Num ? (for co-rou= ted bidi) and leave GMPLS in peace? thanks ciao FF 2012/2/7 > > Francesco > > Below is one usecase based on my understanding. > > A1----------------Z9 (co-routed) > > The MEP_ID of A1 is A1:Global_ID::Node_ID::Tunnel_Num::LSP_Num, similarly > the MEP_ID of Z9 is Z9:Global_ID::Node_ID::Tunnel_Num::LSP_Num. > > Consider that CC-V packets are sent from Z9 to A1, MEP_ID of Z9 is > inserted in the CC-V packets. > > The Mis-Connectivity Defect (RFC6371) is declared based on the comparison > of expected MEP_ID and received MEP_ID, so A1 needs to pre-store the MEP_= ID > of Z9. > > For static LSP, the exchanges of LSP identifers can be realized by the GA= P > (G-ACh Advertisement Protocol) protocol defined in the draft > http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-00. As to dynamically > established LSP, which can be carried in the signaling message. > > I am not sure whether the interpretation is reasonable to you. > > Best regards > > Fei > > > *Francesco Fondelli * > > 2012-02-07 16:56 > =E6=94=B6=E4=BB=B6=E4=BA=BA > zhang.fei3@zte.com.cn > =E6=8A=84=E9=80=81 > Vero Zheng , "ccamp@ietf.org" > =E4=B8=BB=E9=A2=98 > Re: [CCAMP] Discussion on how to carry the Global_ID > > > > > > Am I the only one here that feels "uncomfortable" with this approach and > this additional Z9-Tunnel_Num index in GMPLS flying from egress to ingres= s > (for no reason?!?)? It might be naive or even stupid but I'd like to > understand why we have to add another index... please shed some light on = me. > > [I'm talking about co-routed bidi, I don't care about associated] > > thank you > ciao > FF > > 2012/2/7 <*zhang.fei3@zte.com.cn* > > > Vero > > Why is tunnel number not known by node A? The tunnel number should has > been carried in Session and Sender Template/Filter Spec object and > exchanged by node A and node Z during the LSP set-up. Correct me if I am > wrong. > > According to the description of RFC6370, section 5.1 > At each end point, a tunnel is uniquely identified by the end point's > Node_ID and a locally assigned tunnel number. Specifically, a > "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique > within the context of the Node_ID. The motivation for each end point > having its own tunnel number is to allow a compact form for the > MEP_ID. > > Which means that for co-routed bidrectional LSP, there are two tunnel > numbers, one is locally assigned at node A and the other is locally > assigned at node Z. > If the signaling message is initialized at node A, the tunnel number > carried in Session/Sender Template objects is locally assigned at node A. > Of course, a new > C-type,like type=3D8, can be defined in the class of SESSION to carry bac= k > the tunnel number assigned at node Z; but according to the discussion wit= h > George, I do not think it is a good idea which is not backward compatible= . > > Regards > > Fei > > *Vero Zheng <**vero.zheng@huawei.com* *>* > > 2012-02-07 15:33 > > =E6=94=B6=E4=BB=B6=E4=BA=BA > "*zhang.fei3@zte.com.cn* " <*zhang.fei3@zte.com.cn= * > > > =E6=8A=84=E9=80=81 > "*ccamp@ietf.org* " <*ccamp@ietf.org* > > =E4=B8=BB=E9=A2=98 > RE: [CCAMP] Discussion on how to carry the Global_ID > > > > > > > Fei, > > Please see in-line. > > BR, > Vero > > Fei, > > you wrote: > > First, > =E2=80=9C2. *http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01*<= http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01> > > The Global_ID Object and the ICC_Operator_ID Object are defined in this > draft, which describes the procedure of corouted bidirectional LSP > (associated bidirectional LSP is not covered in the current version) and > requires that the same format( Global_ID or ICC_Operator_ID)is used along > the LSP. > > Which is not true. The Object we defined could be carried in both > Path/Resv message, and is not restricted either to co-routed bi-direction= al > LSP or associated bi-directional LSP. > > > Although either co-routed or associated bidirectional LSP is not mentione= d > in this draft , according to the descripition in section 2.3, " If the > node agrees, it MUST use the same format of Operator ID. The same C-Type > of OIO MUST be carried in the Resv message", which means that the > procedure is for corouted bidrectional LSP. > The above is just my understanding and provided for discussion, and if it > is wrong or inaccurate, please let me know. > > The procedure described above aims to guarantee the sender and the > receiver using the same C-Type of the object, i.e. both end using Global_= ID > or both using ICC_Operator_ID. > > Second, > 3. * > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-nu= m-01 > * > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will > appear in the Path/Resv message of corouted bidrectional LSP and only > appear in the Path message of associated bidirectional LSP. Furthermore, > this draft defined a Connection TLV used to carry the local tunnel number > assigned at Z9 nodes in the scenario of corouted bidirectional LSP. > > Why =E2=80=9Ctunnel number=E2=80=9D is carried in the Connection TLV? I d= on't see its > necessary for both co-route/ associated bi-directional LSP. Could you > explain? > > > As I said, it is useful for corouted (not associated) bidirectional LSP, > consider that there is one LSP (LSP1, initiated at node A) between node > A/Z. > If the CC-V pakcet is sent from node Z, the MEP_ID of node Z will be > inserted in the OAM packets, which is organized by > node_ID::tunnel_num::LSP_num > (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not pre-stored > at node A, it can not judge whether this MEP_ID is valid. See the > description in section 5.1.1.2 > (*Mis-Connectivity Defect*) of RFC6371. > LSP1 > A-------------------------------Z > > > > Why is tunnel number not known by node A? The tunnel number should has > been carried in Session and Sender Template/Filter Spec object and > exchanged by node A and node Z during the LSP set-up. Correct me if I am > wrong. > > BR, > Vero > > Thanks. > > Vero > > * > From:* *ccamp-bounces@ietf.org* [mailto:* > ccamp-bounces@ietf.org* ] *On Behalf Of ** > zhang.fei3@zte.com.cn* * > Sent:* Sunday, January 29, 2012 5:50 PM* > To:* *ccamp@ietf.org* * > Subject:* [CCAMP] Discussion on how to carry the Global_ID > > > Hi CCAMPers > > As discussed in the last IETF meeting and mailinglist, the Global_ID > should be carried in the signaling messages. One reason is that the > judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store > each other's MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num= . > > Fortunately, there are several drafts related to this topic now, > > 1. *http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01* > . > > The Globa_ID is incorporated into the ASSOCIATION object in the current > version, which guarantees that the association is global unique. Since th= e > ASSOCIATION object is used across different LSPs, just my2cents, the > defined format is deficient to handle more scenarios. For example: > > (1) Considering a corouted bidirectional LSP, which is not protected by > other LSPs through control plane and/or does not share the same resoures > with other LSPs. In these cases, the ASSOCIATION object will not be carri= ed > in the sigaling messages. > > (2) Considering an associated bidirectional LSP, although the > ASSOCIATION object is carried in the sigaling messages, the global_ID > incorporated in the ASSOCIATION object only > indicates the global prefix of the A1 or Z9 nodes. If this LSP is across > different domains, I think the current format is also deficient (A1 does > not know the gobal ID of Z9 node or Z9 nodes does not know the global ID = of > A1 ). > > 2. *http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01* > > The Global_ID Object and the ICC_Operator_ID Object are defined in this > draft, which describes the procedure of corouted bidirectional LSP > (associated bidirectional LSP is not covered in the current version) and > requires that the same format( Global_ID or ICC_Operator_ID)is used along > the LSP. > > 3. * > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-nu= m-01 > * > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will > appear in the Path/Resv message of corouted bidrectional LSP and only > appear in the Path message of associated bidirectional LSP. Furthermore, > this draft defined a Connection TLV used to carry the local tunnel number > assigned at Z9 nodes in the scenario of corouted bidirectional LSP. > > > The above materials only provide the rough background. > > > Hope to hear the opinions from the WG that how to carry the Global_ID, > then move the work forward. > > > Best regards > > ;) > > Fei > > _______________________________________________ > CCAMP mailing list* > **CCAMP@ietf.org* * > **https://www.ietf.org/mailman/listinfo/ccamp* > > > --0016e68fd04f7e9ccd04b85f8eb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

if this is the only use case I strongly suggest you to make = anything related to Z9-Tunnel_Num OPTIONAL in signaling (dunno if this is t= he case in your I-D). Please.

BTW, I'm wondering... if this is j= ust about MEP ID what's the relation of your I-D and this one:

http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam= -ext-07

Why not simply assume that A1-Tunnel_Num =3D=3D Z9-Tunne= l_Num ? (for co-routed bidi) and leave GMPLS in peace?

thanks
ciao
FF

2012/2/7 <zhang.fei3@zte.com= .cn>

Francesco

Below is one usecase based on my understandin= g.

A1----------------Z9 (co-routed)

The MEP_ID of A1 is A1:Global_ID::Node_ID::Tu= nnel_Num::LSP_Num, similarly the MEP_ID of Z9 is Z9:Global_ID::Node_ID::Tunnel_Num::LSP_Num.

Consider that CC-V packets are sent from Z9 to A1, MEP_ID of Z9 is inserted in the CC-V packets.

The Mis-Connectivity Defect (RFC6371) is declared based on the comparison of expected MEP_ID and received MEP_ID, so A1 needs to pre-store the MEP_ID of Z9.

For static LSP, the exchanges of LSP identifers can be realized by the GAP (G-ACh Advertisement Protocol) protoc= ol defined in the draft http://tools.ietf.org/html/draft-ietf-mpls-g= ach-adv-00. As to dynamically established LSP, which can be carried in the signaling message.

I am not sure whether the interpretation is reasonable to you.

Best regards

Fei


Francesco Fondell= i <fra= ncesco.fondelli@gmail.com>

2012-02-07 16:56

=E6=94=B6=E4=BB= =B6=E4=BA=BA
zhang.fei3@zte.com.cn
=E6=8A=84=E9=80= =81
Vero Zheng <vero.zheng@huawei.com>, "ccamp@ietf.org" <ccamp@ietf.= org>
=E4=B8=BB=E9=A2= =98
Re: [CCAMP] Discussion on how= to carry the Global_ID






Am I the only one here that feels "uncomfortable" with this appro= ach and this additional Z9-Tunnel_Num index in GMPLS flying from egress to ingress (for no reason?!?)? It might be naive or even stupid but I'd li= ke to understand why we have to add another index... please shed some light on me.

[I'm talking about co-routed bidi, I don't care about associated]
thank you
ciao
FF
2012/2/7 <zhang.fei3@zte.= com.cn>

Vero

Why is tunnel number not known by node A? The tunnel number should has been carried in Session and Sender Template/Filter Spec object and exchange= d by node A and node Z during the LSP set-up. Correct me if I am wrong.

According to the description of RFC6370, section 5.1
=C2=A0 =C2=A0At each end point, a tunnel is uniquely identified by the end point's
=C2=A0 Node_ID and a locally assigned tunnel number. =C2=A0Specifically, a
=C2=A0 "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique
=C2=A0 within the context of the Node_ID. =C2=A0The motivation for each end point
=C2=A0 having its own tunnel number is to allow a compact form for the
=C2=A0 MEP_ID.

Which means that for co-routed bidrectional LSP, there are two tunnel numbe= rs, one is locally assigned at node A and the other is locally assigned at node Z.
If the signaling message is initialized at node A, the tunnel number carrie= d in Session/Sender Template objects is locally assigned at node A. Of course= , a new <= br> C-type,like type=3D8, can be defined in the class of SESSION to carry back the tunnel number assigned at node Z; but according to the discussion with George, I do not think it is a good idea which is not backward compatible.<= /font>

Regards

Fei

Vero Zheng <vero.zheng@huawei.com>

2012-02-07 15:33


=E6=94=B6=E4=BB= =B6=E4=BA=BA
"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn= >
=E6=8A=84=E9=80= =81
"ccamp@ietf.org" <ccamp@ietf.org>
=E4=B8=BB=E9=A2= =98
RE: [CCAMP] Discussion on how= to carry the Global_ID







Fei,
=C2=A0
Please see in-line.
=C2=A0
BR,
Vero
=C2=A0
Fei,
=C2=A0
you wrote:
=C2=A0
First,
=E2=80=9C2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, =C2=A0which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

Which is not true. The Object we defined could be carried in both Path/Resv message, and is not restricted either to co-routed bi-directional LSP or associated bi-directional LSP.

<fei>
Although either co-routed or associated bidirectional LSP is not mentioned in this draft , according to =C2=A0the descripition in section 2.3, "<= /font> If the node agrees, it MUST use the same format of Operator ID. =C2=A0The same C-Type of OIO MUST be carried in the Resv message", which means that =C2=A0the procedure is for corouted bidrectional LSP.
The above is just my understanding and provided for discussion, and if it is wrong or inaccurate, please let me know.
</fei>
The procedure described above aims to guarantee the sender and the receiver using the same C-Type of the object, i.e. both end using Global_ID or both using ICC_Operator_ID.
=C2=A0
Second,
3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvp= te-ext-tunnel-num-01

The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appea= r in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assign= ed at Z9 nodes in the scenario of corouted bidirectional LSP.
=C2=A0
Why =E2=80=9Ctunnel number=E2=80=9D is carried in the Connection TLV? I don= 't see its necessary for both co-route/ associated bi-directional LSP. Could you expla= in?
=C2=A0
<fei>
As I said, it is useful for corouted (not associated) bidirectional LSP, =C2=A0consider that there is one LSP (LSP1, initiated at node A) between node A/Z.
If the CC-V pakcet is =C2=A0sent from =C2=A0node Z, the MEP_ID of node Z will be inserted in the OAM packets, which is organized by node_ID::tunne= l_num::LSP_num
(section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not pre-stored at node A, it can not judge whether this MEP_ID is valid. See the descripti= on in section 5.1.1.2
(Mis-Connectivity Defect) of RFC6371.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 LSP1<= font size=3D"3">
A-------------------------------Z


</fei>
Why is tunnel number not known by node A? The tunnel number should has been carried in Session and Sender Template/Filter Spec object and exchange= d by node A and node Z during the LSP set-up. Correct me if I am wrong.
=C2=A0
BR,
Vero

Thanks.
=C2=A0
Vero
=C2=A0
=C2=A0
From: ccamp-bounces@ietf.org= [mailto:= ccamp-bounces@ietf.org] On Behalf Of zhang.fei3@z= te.com.cn
Sent: Sunday, January 29, 2012 5:50 PM
To: ccamp@ietf.org
Subject: [CCAMP] Discussion on how to carry the Global_ID
=C2=A0

Hi CCAMPers

As discussed in the last IETF meeting and mailinglist, the Global_ID should be carried in the signaling messages. One reason is that the judgement of a mis-connectivity defect needs the A1/Z9 nodes to pre-store each other&= #39;s MEP_ID, whose format is: Gobal_ID+Node_ID+Tunnel_num+LSP_num.

Fortunately, there are several drafts related to this topic now,

1. =C2=A0= http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01<= font face=3D"Arial" size=3D"3">.
=C2=A0
The Globa_ID is incorporated into the ASSOCIATION object in the current version, which guarantees that the association is global unique. Since the ASSOCIATION object is used across different LSPs, just my2cents, the defined format is deficient to handle more scenarios. For example:

=C2=A0 (1) Considering a corouted bidirectional LSP, which is not protected by other LSPs through control plane and/or does not share the same resoures with other LSPs. In these cases, the ASSOCIATION object will not be carried in the sigaling messages.

=C2=A0 (2) Considering an associated bidirectional LSP, although the ASSOCI= ATION object is carried in the sigaling messages, the global_ID incorporated in the ASSOCIATION object only
indicates the global prefix of the A1 or Z9 nodes. If this LSP is across different domains, I think the current format is also deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does not know the global ID of A1 ).

2. h= ttp://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01

The Global_ID Object and the ICC_Operator_ID Object are defined in this draft, =C2=A0which describes the procedure of corouted bidirectional LSP (associated bidirectional LSP is not covered in the current version) and requires that the same format( Global_ID or ICC_Operator_ID)is used along the LSP.

3. http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvp= te-ext-tunnel-num-01

The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which will appear in the Path/Resv message of corouted bidrectional LSP and only appea= r in the Path message of associated bidirectional LSP. Furthermore, this draft defined a Connection TLV used to carry the local tunnel number assign= ed at Z9 nodes in the scenario of corouted bidirectional LSP.


The above materials only provide the rough background.


Hope to hear the opinions from the WG that how to carry the Global_ID, then move the work forward.


Best regards

;)

Fei

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


--0016e68fd04f7e9ccd04b85f8eb5-- From lberger@labn.net Tue Feb 7 05:34:25 2012 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 1B5FE21F8627 for ; Tue, 7 Feb 2012 05:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.377 X-Spam-Level: X-Spam-Status: No, score=-98.377 tagged_above=-999 required=5 tests=[AWL=1.784, 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 G77V11GTKQ0R for ; Tue, 7 Feb 2012 05:34:24 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 13B9F21F85C4 for ; Tue, 7 Feb 2012 05:34:23 -0800 (PST) Received: (qmail 17242 invoked by uid 0); 7 Feb 2012 13:34:23 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 7 Feb 2012 13:34: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=ptQKeMDo3vCWjH5UQ4p1Ai1GDuTPmbwxfP3bErRn52Y=; b=BBYNDTcEXwsbfy80ZQ01HNbXdFHY1jHZu80fJ+oI9vbxHkWxuO4fm40++ujy+RnB5SD7fkR5Yfdc7MLVJU8hlO0p8flmm/lKtVDvPF1GV9bFN7t5aZAZ/Oo5Klh4azz3; 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 1RulBe-0003tK-Vl; Tue, 07 Feb 2012 06:34:23 -0700 Message-ID: <4F31285C.6040107@labn.net> Date: Tue, 07 Feb 2012 08:34:20 -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: Francesco Fondelli References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 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" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 13:34:25 -0000 Francesco, From my perspective, the (minimum) requirements are being driven by rfc6370. Take a look at sections 5.2 and 5.3, and see if you still think more mechanisms are being defined than is necessary. Lou On 2/7/2012 3:56 AM, Francesco Fondelli wrote: > > Am I the only one here that feels "uncomfortable" with this approach and > this additional Z9-Tunnel_Num index in GMPLS flying from egress to > ingress (for no reason?!?)? It might be naive or even stupid but I'd > like to understand why we have to add another index... please shed some > light on me. > > [I'm talking about co-routed bidi, I don't care about associated] > > thank you > ciao > FF > > 2012/2/7 > > > > Vero > > Why is tunnel number not known by node A? The tunnel number should > has been carried in Session and Sender Template/Filter Spec object > and exchanged by node A and node Z during the LSP set-up. Correct me > if I am wrong. > > According to the description of RFC6370, section 5.1 > At each end point, a tunnel is uniquely identified by the end point's > Node_ID and a locally assigned tunnel number. Specifically, a > "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique > within the context of the Node_ID. The motivation for each end point > having its own tunnel number is to allow a compact form for the > MEP_ID. > > Which means that for co-routed bidrectional LSP, there are two > tunnel numbers, one is locally assigned at node A and the other is > locally assigned at node Z. > If the signaling message is initialized at node A, the tunnel number > carried in Session/Sender Template objects is locally assigned at > node A. Of course, a new > C-type,like type=8, can be defined in the class of SESSION to carry > back the tunnel number assigned at node Z; but according to the > discussion with George, I do not think it is a good idea which is > not backward compatible. > > Regards > > Fei > > > *Vero Zheng >* > > 2012-02-07 15:33 > > > 鏀朵欢浜 > "zhang.fei3@zte.com.cn " > > > 鎶勯 > "ccamp@ietf.org " > > 涓婚 > RE: [CCAMP] Discussion on how to carry the Global_ID > > > > > > > > > Fei, > > Please see in-line. > > BR, > Vero > > Fei, > > you wrote: > > First, > 鈥2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 > > The Global_ID Object and the ICC_Operator_ID Object are defined in > this draft, which describes the procedure of corouted bidirectional > LSP (associated bidirectional LSP is not covered in the current > version) and requires that the same format( Global_ID or > ICC_Operator_ID)is used along the LSP. > > Which is not true. The Object we defined could be carried in both > Path/Resv message, and is not restricted either to co-routed > bi-directional LSP or associated bi-directional LSP. > > > Although either co-routed or associated bidirectional LSP is not > mentioned in this draft , according to the descripition in section > 2.3, " If the node agrees, it MUST use the same format of Operator > ID. The same C-Type of OIO MUST be carried in the Resv message", > which means that the procedure is for corouted bidrectional LSP. > The above is just my understanding and provided for discussion, and > if it is wrong or inaccurate, please let me know. > > The procedure described above aims to guarantee the sender and the > receiver using the same C-Type of the object, i.e. both end using > Global_ID or both using ICC_Operator_ID. > > Second, > 3. > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 > > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which > will appear in the Path/Resv message of corouted bidrectional LSP > and only appear in the Path message of associated bidirectional LSP. > Furthermore, this draft defined a Connection TLV used to carry the > local tunnel number assigned at Z9 nodes in the scenario of corouted > bidirectional LSP. > > Why 鈥渢unnel number鈥 is carried in the Connection TLV? I don't see > its necessary for both co-route/ associated bi-directional LSP. > Could you explain? > > > As I said, it is useful for corouted (not associated) bidirectional > LSP, consider that there is one LSP (LSP1, initiated at node A) > between node A/Z. > If the CC-V pakcet is sent from node Z, the MEP_ID of node Z will > be inserted in the OAM packets, which is organized by > node_ID::tunnel_num::LSP_num > (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not > pre-stored at node A, it can not judge whether this MEP_ID is valid. > See the description in section 5.1.1.2 > (*Mis-Connectivity Defect*) of RFC6371. > LSP1 > A-------------------------------Z > > > > Why is tunnel number not known by node A? The tunnel number should > has been carried in Session and Sender Template/Filter Spec object > and exchanged by node A and node Z during the LSP set-up. Correct me > if I am wrong. > > BR, > Vero > > Thanks. > > Vero > > * > From:* ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org ] *On > Behalf Of *zhang.fei3@zte.com.cn * > Sent:* Sunday, January 29, 2012 5:50 PM* > To:* ccamp@ietf.org * > Subject:* [CCAMP] Discussion on how to carry the Global_ID > > > Hi CCAMPers > > As discussed in the last IETF meeting and mailinglist, the Global_ID > should be carried in the signaling messages. One reason is that the > judgement of a mis-connectivity defect needs the A1/Z9 nodes to > pre-store each other's MEP_ID, whose format is: > Gobal_ID+Node_ID+Tunnel_num+LSP_num. > > Fortunately, there are several drafts related to this topic now, > > 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. > > The Globa_ID is incorporated into the ASSOCIATION object in the > current version, which guarantees that the association is global > unique. Since the ASSOCIATION object is used across different LSPs, > just my2cents, the defined format is deficient to handle more > scenarios. For example: > > (1) Considering a corouted bidirectional LSP, which is not > protected by other LSPs through control plane and/or does not share > the same resoures with other LSPs. In these cases, the ASSOCIATION > object will not be carried in the sigaling messages. > > (2) Considering an associated bidirectional LSP, although the > ASSOCIATION object is carried in the sigaling messages, the > global_ID incorporated in the ASSOCIATION object only > indicates the global prefix of the A1 or Z9 nodes. If this LSP is > across different domains, I think the current format is also > deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does > not know the global ID of A1 ). > > 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 > > The Global_ID Object and the ICC_Operator_ID Object are defined in > this draft, which describes the procedure of corouted bidirectional > LSP (associated bidirectional LSP is not covered in the current > version) and requires that the same format( Global_ID or > ICC_Operator_ID)is used along the LSP. > > 3. > http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-01 > > > The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which > will appear in the Path/Resv message of corouted bidrectional LSP > and only appear in the Path message of associated bidirectional LSP. > Furthermore, this draft defined a Connection TLV used to carry the > local tunnel number assigned at Z9 nodes in the scenario of corouted > bidirectional LSP. > > > The above materials only provide the rough background. > > > Hope to hear the opinions from the WG that how to carry the > Global_ID, then move the work forward. > > > Best regards > > ;) > > Fei > > _______________________________________________ > 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 francesco.fondelli@gmail.com Tue Feb 7 06:07:18 2012 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 2240021F87C7 for ; Tue, 7 Feb 2012 06:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.111 X-Spam-Level: X-Spam-Status: No, score=-3.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 gzVIR72MSUZR for ; Tue, 7 Feb 2012 06:07:17 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F11AC21F86B3 for ; Tue, 7 Feb 2012 06:07:16 -0800 (PST) Received: by yhkk25 with SMTP id k25so3407020yhk.31 for ; Tue, 07 Feb 2012 06:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9qbW0yjefF9trdtm4NRJQucfmrCg8G2eGbslL35lD8U=; b=AxAMWWq+Tcy1v5GabPiJJ0hSTYbg5KrYSsvYL4rwzBV6lC2CSFoCA2ZdUmS6SyYK2h vaQDq+sYUyl9isAx0/CNlldD1Xzs/nvkN3R8o85eaGOJ//75a86ZPCe7tUUglgq8sweD uuxMX9xv/K0tNGTCInbdwvFyMOs7T0nK6fmoA= MIME-Version: 1.0 Received: by 10.236.173.202 with SMTP id v50mr32243891yhl.102.1328623636620; Tue, 07 Feb 2012 06:07:16 -0800 (PST) Received: by 10.236.155.103 with HTTP; Tue, 7 Feb 2012 06:07:16 -0800 (PST) In-Reply-To: <4F31285C.6040107@labn.net> References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <4F31285C.6040107@labn.net> Date: Tue, 7 Feb 2012 15:07:16 +0100 Message-ID: From: Francesco Fondelli To: Lou Berger Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 07 Feb 2012 14:07:18 -0000 Hi Lou, I'm staring at those sections since last Wednesday. Z9-Tunnel_Num makes sense for associated bidi... but why we need it for signalling bidi co-routed is still something I have to understand. I'm sure it's me missing something. thanks Ciao FF On Tue, Feb 7, 2012 at 2:34 PM, Lou Berger wrote: > Francesco, > =C2=A0 =C2=A0 =C2=A0 =C2=A0From my perspective, the (minimum) requirement= s are being driven by > rfc6370. Take a look at sections 5.2 and 5.3, and see if you still think > more mechanisms are being defined than is necessary. > > Lou > > On 2/7/2012 3:56 AM, Francesco Fondelli wrote: >> >> Am I the only one here that feels "uncomfortable" with this approach and >> this additional Z9-Tunnel_Num index in GMPLS flying from egress to >> ingress (for no reason?!?)? It might be naive or even stupid but I'd >> like to understand why we have to add another index... please shed some >> light on me. >> >> [I'm talking about co-routed bidi, I don't care about associated] >> >> thank you >> ciao >> FF >> >> 2012/2/7 > >> >> >> =C2=A0 =C2=A0 Vero >> >> =C2=A0 =C2=A0 Why is tunnel number not known by node A? The tunnel numbe= r should >> =C2=A0 =C2=A0 has been carried in Session and Sender Template/Filter Spe= c object >> =C2=A0 =C2=A0 and exchanged by node A and node Z during the LSP set-up. = Correct me >> =C2=A0 =C2=A0 if I am wrong. >> >> =C2=A0 =C2=A0 According to the description of RFC6370, section 5.1 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0At each end point, a tunnel is uniquely ident= ified by the end point's >> =C2=A0 =C2=A0 =C2=A0 Node_ID and a locally assigned tunnel number. =C2= =A0Specifically, a >> =C2=A0 =C2=A0 =C2=A0 "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned i= nteger unique >> =C2=A0 =C2=A0 =C2=A0 within the context of the Node_ID. =C2=A0The motiva= tion for each end point >> =C2=A0 =C2=A0 =C2=A0 having its own tunnel number is to allow a compact = form for the >> =C2=A0 =C2=A0 =C2=A0 MEP_ID. >> >> =C2=A0 =C2=A0 Which means that for co-routed bidrectional LSP, there are= two >> =C2=A0 =C2=A0 tunnel numbers, one is locally assigned at node A and the = other is >> =C2=A0 =C2=A0 locally assigned at node Z. >> =C2=A0 =C2=A0 If the signaling message is initialized at node A, the tun= nel number >> =C2=A0 =C2=A0 carried in Session/Sender Template objects is locally assi= gned at >> =C2=A0 =C2=A0 node A. Of course, a new >> =C2=A0 =C2=A0 C-type,like type=3D8, can be defined in the class of SESSI= ON to carry >> =C2=A0 =C2=A0 back the tunnel number assigned at node Z; but according t= o the >> =C2=A0 =C2=A0 discussion with George, I do not think it is a good idea w= hich is >> =C2=A0 =C2=A0 not backward compatible. >> >> =C2=A0 =C2=A0 Regards >> >> =C2=A0 =C2=A0 Fei >> >> >> =C2=A0 =C2=A0 *Vero Zheng >* >> >> =C2=A0 =C2=A0 2012-02-07 15:33 >> >> >> =C2=A0 =C2=A0 =E6=94=B6=E4=BB=B6=E4=BA=BA >> =C2=A0 =C2=A0 =C2=A0 "zhang.fei3@zte.com.cn " >> =C2=A0 =C2=A0 > >> =C2=A0 =C2=A0 =E6=8A=84=E9=80=81 >> =C2=A0 =C2=A0 =C2=A0 "ccamp@ietf.org " > =C2=A0 =C2=A0 > >> =C2=A0 =C2=A0 =E4=B8=BB=E9=A2=98 >> =C2=A0 =C2=A0 =C2=A0 RE: [CCAMP] Discussion on how to carry the Global_I= D >> >> >> >> >> >> >> >> >> =C2=A0 =C2=A0 Fei, >> >> =C2=A0 =C2=A0 Please see in-line. >> >> =C2=A0 =C2=A0 BR, >> =C2=A0 =C2=A0 Vero >> >> =C2=A0 =C2=A0 Fei, >> >> =C2=A0 =C2=A0 you wrote: >> >> =C2=A0 =C2=A0 First, >> =C2=A0 =C2=A0 =E2=80=9C2. http://tools.ietf.org/html/draft-chen-ccamp-mp= ls-tp-oio-01 >> >> =C2=A0 =C2=A0 The Global_ID Object and the ICC_Operator_ID Object are de= fined in >> =C2=A0 =C2=A0 this draft, =C2=A0which describes the procedure of coroute= d bidirectional >> =C2=A0 =C2=A0 LSP (associated bidirectional LSP is not covered in the cu= rrent >> =C2=A0 =C2=A0 version) and requires that the same format( Global_ID or >> =C2=A0 =C2=A0 ICC_Operator_ID)is used along the LSP. >> >> =C2=A0 =C2=A0 Which is not true. The Object we defined could be carried = in both >> =C2=A0 =C2=A0 Path/Resv message, and is not restricted either to co-rout= ed >> =C2=A0 =C2=A0 bi-directional LSP or associated bi-directional LSP. >> >> =C2=A0 =C2=A0 >> =C2=A0 =C2=A0 Although either co-routed or associated bidirectional LSP = is not >> =C2=A0 =C2=A0 mentioned in this draft , according to =C2=A0the descripit= ion in section >> =C2=A0 =C2=A0 2.3, " If the node agrees, it MUST use the same format of = Operator >> =C2=A0 =C2=A0 ID. =C2=A0The same C-Type of OIO MUST be carried in the Re= sv message", >> =C2=A0 =C2=A0 which means that =C2=A0the procedure is for corouted bidre= ctional LSP. >> =C2=A0 =C2=A0 The above is just my understanding and provided for discus= sion, and >> =C2=A0 =C2=A0 if it is wrong or inaccurate, please let me know. >> =C2=A0 =C2=A0 >> =C2=A0 =C2=A0 The procedure described above aims to guarantee the sender= and the >> =C2=A0 =C2=A0 receiver using the same C-Type of the object, i.e. both en= d using >> =C2=A0 =C2=A0 Global_ID or both using ICC_Operator_ID. >> >> =C2=A0 =C2=A0 Second, >> =C2=A0 =C2=A0 3. >> =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpt= e-ext-tunnel-num-01 >> >> >> =C2=A0 =C2=A0 The Global_ID is carried as a TLV of the LSP_ATTRIBUTE obj= ect, which >> =C2=A0 =C2=A0 will appear in the Path/Resv message of corouted bidrectio= nal LSP >> =C2=A0 =C2=A0 and only appear in the Path message of associated bidirect= ional LSP. >> =C2=A0 =C2=A0 Furthermore, this draft defined a Connection TLV used to c= arry the >> =C2=A0 =C2=A0 local tunnel number assigned at Z9 nodes in the scenario o= f corouted >> =C2=A0 =C2=A0 bidirectional LSP. >> >> =C2=A0 =C2=A0 Why =E2=80=9Ctunnel number=E2=80=9D is carried in the Conn= ection TLV? I don't see >> =C2=A0 =C2=A0 its necessary for both co-route/ associated bi-directional= LSP. >> =C2=A0 =C2=A0 Could you explain? >> >> =C2=A0 =C2=A0 >> =C2=A0 =C2=A0 As I said, it is useful for corouted (not associated) bidi= rectional >> =C2=A0 =C2=A0 LSP, =C2=A0consider that there is one LSP (LSP1, initiated= at node A) >> =C2=A0 =C2=A0 between node A/Z. >> =C2=A0 =C2=A0 If the CC-V pakcet is =C2=A0sent from =C2=A0node Z, the ME= P_ID of node Z will >> =C2=A0 =C2=A0 be inserted in the OAM packets, which is organized by >> =C2=A0 =C2=A0 node_ID::tunnel_num::LSP_num >> =C2=A0 =C2=A0 (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is= not >> =C2=A0 =C2=A0 pre-stored at node A, it can not judge whether this MEP_ID= is valid. >> =C2=A0 =C2=A0 See the description in section 5.1.1.2 >> =C2=A0 =C2=A0 (*Mis-Connectivity Defect*) of RFC6371. >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 LSP1 >> =C2=A0 =C2=A0 A-------------------------------Z >> >> >> =C2=A0 =C2=A0 >> =C2=A0 =C2=A0 Why is tunnel number not known by node A? The tunnel numbe= r should >> =C2=A0 =C2=A0 has been carried in Session and Sender Template/Filter Spe= c object >> =C2=A0 =C2=A0 and exchanged by node A and node Z during the LSP set-up. = Correct me >> =C2=A0 =C2=A0 if I am wrong. >> >> =C2=A0 =C2=A0 BR, >> =C2=A0 =C2=A0 Vero >> >> =C2=A0 =C2=A0 Thanks. >> >> =C2=A0 =C2=A0 Vero >> >> =C2=A0 =C2=A0 =C2=A0* >> =C2=A0 =C2=A0 From:* ccamp-bounces@ietf.org >> =C2=A0 =C2=A0 [mailto:ccamp-bounces@ietf.org ] *On >> =C2=A0 =C2=A0 Behalf Of *zhang.fei3@zte.com.cn * >> =C2=A0 =C2=A0 Sent:* Sunday, January 29, 2012 5:50 PM* >> =C2=A0 =C2=A0 To:* ccamp@ietf.org * >> =C2=A0 =C2=A0 Subject:* [CCAMP] Discussion on how to carry the Global_ID >> >> >> =C2=A0 =C2=A0 Hi CCAMPers >> >> =C2=A0 =C2=A0 As discussed in the last IETF meeting and mailinglist, the= Global_ID >> =C2=A0 =C2=A0 should be carried in the signaling messages. One reason is= that the >> =C2=A0 =C2=A0 judgement of a mis-connectivity defect needs the A1/Z9 nod= es to >> =C2=A0 =C2=A0 pre-store each other's MEP_ID, whose format is: >> =C2=A0 =C2=A0 Gobal_ID+Node_ID+Tunnel_num+LSP_num. >> >> =C2=A0 =C2=A0 Fortunately, there are several drafts related to this topi= c now, >> >> =C2=A0 =C2=A0 1. =C2=A0http://tools.ietf.org/html/draft-ietf-ccamp-assoc= -ext-01. >> >> =C2=A0 =C2=A0 The Globa_ID is incorporated into the ASSOCIATION object i= n the >> =C2=A0 =C2=A0 current version, which guarantees that the association is = global >> =C2=A0 =C2=A0 unique. Since the ASSOCIATION object is used across differ= ent LSPs, >> =C2=A0 =C2=A0 just my2cents, the defined format is deficient to handle m= ore >> =C2=A0 =C2=A0 scenarios. For example: >> >> =C2=A0 =C2=A0 =C2=A0 (1) Considering a corouted bidirectional LSP, which= is not >> =C2=A0 =C2=A0 protected by other LSPs through control plane and/or does = not share >> =C2=A0 =C2=A0 the same resoures with other LSPs. In these cases, the ASS= OCIATION >> =C2=A0 =C2=A0 object will not be carried in the sigaling messages. >> >> =C2=A0 =C2=A0 =C2=A0 (2) Considering an associated bidirectional LSP, al= though the >> =C2=A0 =C2=A0 ASSOCIATION object is carried in the sigaling messages, th= e >> =C2=A0 =C2=A0 global_ID incorporated in the ASSOCIATION object only >> =C2=A0 =C2=A0 indicates the global prefix of the A1 or Z9 nodes. If this= LSP is >> =C2=A0 =C2=A0 across different domains, I think the current format is al= so >> =C2=A0 =C2=A0 deficient (A1 does not know the gobal ID of Z9 node or Z9 = nodes does >> =C2=A0 =C2=A0 not know the global ID of A1 ). >> >> =C2=A0 =C2=A0 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio= -01 >> >> =C2=A0 =C2=A0 The Global_ID Object and the ICC_Operator_ID Object are de= fined in >> =C2=A0 =C2=A0 this draft, =C2=A0which describes the procedure of coroute= d bidirectional >> =C2=A0 =C2=A0 LSP (associated bidirectional LSP is not covered in the cu= rrent >> =C2=A0 =C2=A0 version) and requires that the same format( Global_ID or >> =C2=A0 =C2=A0 ICC_Operator_ID)is used along the LSP. >> >> =C2=A0 =C2=A0 3. >> =C2=A0 =C2=A0 http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpt= e-ext-tunnel-num-01 >> >> >> =C2=A0 =C2=A0 The Global_ID is carried as a TLV of the LSP_ATTRIBUTE obj= ect, which >> =C2=A0 =C2=A0 will appear in the Path/Resv message of corouted bidrectio= nal LSP >> =C2=A0 =C2=A0 and only appear in the Path message of associated bidirect= ional LSP. >> =C2=A0 =C2=A0 Furthermore, this draft defined a Connection TLV used to c= arry the >> =C2=A0 =C2=A0 local tunnel number assigned at Z9 nodes in the scenario o= f corouted >> =C2=A0 =C2=A0 bidirectional LSP. >> >> >> =C2=A0 =C2=A0 The above materials only provide the rough background. >> >> >> =C2=A0 =C2=A0 Hope to hear the opinions from the WG that how to carry th= e >> =C2=A0 =C2=A0 Global_ID, then move the work forward. >> >> >> =C2=A0 =C2=A0 Best regards >> >> =C2=A0 =C2=A0 ;) >> >> =C2=A0 =C2=A0 Fei >> >> =C2=A0 =C2=A0 _______________________________________________ >> =C2=A0 =C2=A0 CCAMP mailing list >> =C2=A0 =C2=A0 CCAMP@ietf.org >> =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ccamp >> >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp From zhang.fei3@zte.com.cn Tue Feb 7 16:40:15 2012 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 C149711E8073 for ; Tue, 7 Feb 2012 16:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.683 X-Spam-Level: X-Spam-Status: No, score=-96.683 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, 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 ezzmEGwUd9Yq for ; Tue, 7 Feb 2012 16:40: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 48C4911E8072 for ; Tue, 7 Feb 2012 16:40:13 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690473195744; Wed, 8 Feb 2012 08:13:35 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.2563153982; Wed, 8 Feb 2012 08:40:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q180duti090561; Wed, 8 Feb 2012 08:39:57 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Francesco Fondelli MIME-Version: 1.0 X-KeepSent: 79DAAA88:075A6C20-4825799E:0002114F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 8 Feb 2012 08:39:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-08 08:39:57, Serialize complete at 2012-02-08 08:39:57 Content-Type: multipart/alternative; boundary="=_alternative 0003A7344825799E_=" X-MAIL: mse02.zte.com.cn q180duti090561 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 08 Feb 2012 00:40:15 -0000 This is a multipart message in MIME format. --=_alternative 0003A7344825799E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RnJhbmNlc2NvDQoNClNlZSBpbiBsaW5lIHdpdGggPGZlaT48L2ZlaT4NCg0KSnVzdCBteTJjZW50 cw0KDQpCZXN0IA0KDQpGZWkNCg0KDQoNCkZyYW5jZXNjbyBGb25kZWxsaSA8ZnJhbmNlc2NvLmZv bmRlbGxpQGdtYWlsLmNvbT4gDQoyMDEyLTAyLTA3IDIxOjE0DQoNCsrVvP7Iyw0KemhhbmcuZmVp M0B6dGUuY29tLmNuDQqzrcvNDQpWZXJvIFpoZW5nIDx2ZXJvLnpoZW5nQGh1YXdlaS5jb20+LCAi Y2NhbXBAaWV0Zi5vcmciIDxjY2FtcEBpZXRmLm9yZz4NCtb3zOINClJlOiBbQ0NBTVBdIERpc2N1 c3Npb24gb24gaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQNCg0KDQoNCg0KDQoNCg0KSGksDQoN CmlmIHRoaXMgaXMgdGhlIG9ubHkgdXNlIGNhc2UgSSBzdHJvbmdseSBzdWdnZXN0IHlvdSB0byBt YWtlIGFueXRoaW5nIA0KcmVsYXRlZCB0byBaOS1UdW5uZWxfTnVtIE9QVElPTkFMIGluIHNpZ25h bGluZyAoZHVubm8gaWYgdGhpcyBpcyB0aGUgY2FzZSANCmluIHlvdXIgSS1EKS4gUGxlYXNlLg0K DQo8ZmVpPg0KSSBqdXN0IGRlc2NyaWJlIHRoaXMgdXNlY2FzZSBpbiB0aGUgY3VycmVudCBkcmFm dCwgYW5kIHRoZSBaOS1UdW5uZWxfTnVtIA0KaXMgT1BUSU9OQUwuDQpJZiB3ZSBjb25zaWRlciB0 aGUgc2VydmljZSBhY2Nlc3MgYXQgWjkgbm9kZSwgdGhlIGluZGV4IHdpbGwgYmUgc2hvcnRlciwg DQpidXQgaXQgaXMgcmVsYXRlZCB0byB0aGUgY29uY3JldGUgcmVhbGl6YXRpb24uIEZ1cnRoZXJt b3JlLCBJIGFtIG5vdCBzdXJlIA0Kd2hldGhlciBpdCB3aWxsIGhhdmUgaW5mbHVlbmNlIG9uIHRo ZSBJR1AgU2hvcnRDdXQsIG5lZWQgdG8gdGhpbmsgYWJvdXQgDQppdC4NCjwvZmVpPiANCg0KQlRX LCBJJ20gd29uZGVyaW5nLi4uIGlmIHRoaXMgaXMganVzdCBhYm91dCBNRVAgSUQgd2hhdCdzIHRo ZSByZWxhdGlvbiBvZiANCnlvdXIgSS1EIGFuZCB0aGlzIG9uZToNCg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLW1wbHMtdHAtb2FtLWV4dC0wNw0K DQo8ZmVpPiANCkFjdHVhbGx5LCBJIHBvaW50ZWQgb3V0IHRoaXMgb24gdGhlIGxhc3QgSUVURiBt ZWV0aW5nIHByZXNlbnRhdGlvbiANCm1hdGVyaWFsLHBsZWFzZSBjaGVjayB0aGUgZm9sbG93aW5n IGxpbms6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzgyL3NsaWRlcy9jY2FtcC0xMC5w ZGYNCjwvZmVpPg0KDQpXaHkgbm90IHNpbXBseSBhc3N1bWUgdGhhdCBBMS1UdW5uZWxfTnVtID09 IFo5LVR1bm5lbF9OdW0gPyAoZm9yIGNvLXJvdXRlZCANCmJpZGkpIGFuZCBsZWF2ZSBHTVBMUyBp biBwZWFjZT8NCg0KPGZlaT4NCkluIHRoZSBwcmFjdGljYWwgaW1wbGVtZW50YXRpb24sIHdlIGNh biBkbyB0aGlzLiBCdXQgdGhlIFR1bm5lbCBzcGFjZSBpcyANCmluZGVwZW5kZW50IGZyb20gZWFj aCBvdGhlciBhdCBldmVyeSBub2RlLCB3aGljaCBtZWFucyB0aGF0IHRoZSANCmNvbmZsaWN0aW5n IHdpbGwgaGFwcGVuLiANCjwvZmVpPg0KDQoNCnRoYW5rcw0KY2lhbw0KRkYNCg0KMjAxMi8yLzcg PHpoYW5nLmZlaTNAenRlLmNvbS5jbj4NCg0KRnJhbmNlc2NvIA0KDQpCZWxvdyBpcyBvbmUgdXNl Y2FzZSBiYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nLiANCg0KQTEtLS0tLS0tLS0tLS0tLS0tWjkg KGNvLXJvdXRlZCkgDQoNClRoZSBNRVBfSUQgb2YgQTEgaXMgQTE6R2xvYmFsX0lEOjpOb2RlX0lE OjpUdW5uZWxfTnVtOjpMU1BfTnVtLCBzaW1pbGFybHkgDQp0aGUgTUVQX0lEIG9mIFo5IGlzIFo5 Okdsb2JhbF9JRDo6Tm9kZV9JRDo6VHVubmVsX051bTo6TFNQX051bS4gDQoNCkNvbnNpZGVyIHRo YXQgQ0MtViBwYWNrZXRzIGFyZSBzZW50IGZyb20gWjkgdG8gQTEsIE1FUF9JRCBvZiBaOSBpcyAN Cmluc2VydGVkIGluIHRoZSBDQy1WIHBhY2tldHMuIA0KDQpUaGUgTWlzLUNvbm5lY3Rpdml0eSBE ZWZlY3QgKFJGQzYzNzEpIGlzIGRlY2xhcmVkIGJhc2VkIG9uIHRoZSBjb21wYXJpc29uIA0Kb2Yg ZXhwZWN0ZWQgTUVQX0lEIGFuZCByZWNlaXZlZCBNRVBfSUQsIHNvIEExIG5lZWRzIHRvIHByZS1z dG9yZSB0aGUgDQpNRVBfSUQgb2YgWjkuIA0KDQpGb3Igc3RhdGljIExTUCwgdGhlIGV4Y2hhbmdl cyBvZiBMU1AgaWRlbnRpZmVycyBjYW4gYmUgcmVhbGl6ZWQgYnkgdGhlIEdBUCANCihHLUFDaCBB ZHZlcnRpc2VtZW50IFByb3RvY29sKSBwcm90b2NvbCBkZWZpbmVkIGluIHRoZSBkcmFmdCANCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbXBscy1nYWNoLWFkdi0wMC4gQXMg dG8gZHluYW1pY2FsbHkgDQplc3RhYmxpc2hlZCBMU1AsIHdoaWNoIGNhbiBiZSBjYXJyaWVkIGlu IHRoZSBzaWduYWxpbmcgbWVzc2FnZS4gDQoNCkkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgaW50 ZXJwcmV0YXRpb24gaXMgcmVhc29uYWJsZSB0byB5b3UuIA0KDQpCZXN0IHJlZ2FyZHMgDQoNCkZl aSANCg0KDQoNCkZyYW5jZXNjbyBGb25kZWxsaSA8ZnJhbmNlc2NvLmZvbmRlbGxpQGdtYWlsLmNv bT4gDQoyMDEyLTAyLTA3IDE2OjU2IA0KDQoNCsrVvP7Iyw0KemhhbmcuZmVpM0B6dGUuY29tLmNu IA0Ks63LzQ0KVmVybyBaaGVuZyA8dmVyby56aGVuZ0BodWF3ZWkuY29tPiwgImNjYW1wQGlldGYu b3JnIiA8Y2NhbXBAaWV0Zi5vcmc+IA0K1vfM4g0KUmU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBo b3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRA0KDQoNCg0KDQoNCg0KDQoNCg0KQW0gSSB0aGUgb25s eSBvbmUgaGVyZSB0aGF0IGZlZWxzICJ1bmNvbWZvcnRhYmxlIiB3aXRoIHRoaXMgYXBwcm9hY2gg YW5kIA0KdGhpcyBhZGRpdGlvbmFsIFo5LVR1bm5lbF9OdW0gaW5kZXggaW4gR01QTFMgZmx5aW5n IGZyb20gZWdyZXNzIHRvIGluZ3Jlc3MgDQooZm9yIG5vIHJlYXNvbj8hPyk/IEl0IG1pZ2h0IGJl IG5haXZlIG9yIGV2ZW4gc3R1cGlkIGJ1dCBJJ2QgbGlrZSB0byANCnVuZGVyc3RhbmQgd2h5IHdl IGhhdmUgdG8gYWRkIGFub3RoZXIgaW5kZXguLi4gcGxlYXNlIHNoZWQgc29tZSBsaWdodCBvbiAN Cm1lLg0KDQpbSSdtIHRhbGtpbmcgYWJvdXQgY28tcm91dGVkIGJpZGksIEkgZG9uJ3QgY2FyZSBh Ym91dCBhc3NvY2lhdGVkXQ0KDQp0aGFuayB5b3UNCmNpYW8NCkZGDQoNCjIwMTIvMi83IDx6aGFu Zy5mZWkzQHp0ZS5jb20uY24+IA0KDQpWZXJvIA0KDQpXaHkgaXMgdHVubmVsIG51bWJlciBub3Qg a25vd24gYnkgbm9kZSBBPyBUaGUgdHVubmVsIG51bWJlciBzaG91bGQgaGFzIA0KYmVlbiBjYXJy aWVkIGluIFNlc3Npb24gYW5kIFNlbmRlciBUZW1wbGF0ZS9GaWx0ZXIgU3BlYyBvYmplY3QgYW5k IA0KZXhjaGFuZ2VkIGJ5IG5vZGUgQSBhbmQgbm9kZSBaIGR1cmluZyB0aGUgTFNQIHNldC11cC4g Q29ycmVjdCBtZSBpZiBJIGFtIA0Kd3JvbmcuIA0KDQpBY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0 aW9uIG9mIFJGQzYzNzAsIHNlY3Rpb24gNS4xIA0KICAgQXQgZWFjaCBlbmQgcG9pbnQsIGEgdHVu bmVsIGlzIHVuaXF1ZWx5IGlkZW50aWZpZWQgYnkgdGhlIGVuZCBwb2ludCdzDQogIE5vZGVfSUQg YW5kIGEgbG9jYWxseSBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyLiAgU3BlY2lmaWNhbGx5LCBhDQog ICJUdW5uZWwgTnVtYmVyIiAoVHVubmVsX051bSkgaXMgYSAxNi1iaXQgdW5zaWduZWQgaW50ZWdl ciB1bmlxdWUNCiAgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBOb2RlX0lELiAgVGhlIG1vdGl2 YXRpb24gZm9yIGVhY2ggZW5kIHBvaW50DQogIGhhdmluZyBpdHMgb3duIHR1bm5lbCBudW1iZXIg aXMgdG8gYWxsb3cgYSBjb21wYWN0IGZvcm0gZm9yIHRoZQ0KICBNRVBfSUQuIA0KDQpXaGljaCBt ZWFucyB0aGF0IGZvciBjby1yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3byB0 dW5uZWwgDQpudW1iZXJzLCBvbmUgaXMgbG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIEEgYW5kIHRo ZSBvdGhlciBpcyBsb2NhbGx5IA0KYXNzaWduZWQgYXQgbm9kZSBaLiANCklmIHRoZSBzaWduYWxp bmcgbWVzc2FnZSBpcyBpbml0aWFsaXplZCBhdCBub2RlIEEsIHRoZSB0dW5uZWwgbnVtYmVyIA0K Y2FycmllZCBpbiBTZXNzaW9uL1NlbmRlciBUZW1wbGF0ZSBvYmplY3RzIGlzIGxvY2FsbHkgYXNz aWduZWQgYXQgbm9kZSBBLiANCk9mIGNvdXJzZSwgYSBuZXcgDQpDLXR5cGUsbGlrZSB0eXBlPTgs IGNhbiBiZSBkZWZpbmVkIGluIHRoZSBjbGFzcyBvZiBTRVNTSU9OIHRvIGNhcnJ5IGJhY2sgDQp0 aGUgdHVubmVsIG51bWJlciBhc3NpZ25lZCBhdCBub2RlIFo7IGJ1dCBhY2NvcmRpbmcgdG8gdGhl IGRpc2N1c3Npb24gd2l0aCANCkdlb3JnZSwgSSBkbyBub3QgdGhpbmsgaXQgaXMgYSBnb29kIGlk ZWEgd2hpY2ggaXMgbm90IGJhY2t3YXJkIGNvbXBhdGlibGUuIA0KDQoNClJlZ2FyZHMgDQoNCkZl aSANCg0KDQpWZXJvIFpoZW5nIDx2ZXJvLnpoZW5nQGh1YXdlaS5jb20+IA0KMjAxMi0wMi0wNyAx NTozMyANCg0KDQrK1bz+yMsNCiJ6aGFuZy5mZWkzQHp0ZS5jb20uY24iIDx6aGFuZy5mZWkzQHp0 ZS5jb20uY24+IA0Ks63LzQ0KImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+IA0K1vfM 4g0KUkU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRA0K DQoNCg0KDQoNCg0KDQoNCg0KDQpGZWksIA0KICANClBsZWFzZSBzZWUgaW4tbGluZS4gDQogIA0K QlIsIA0KVmVybyANCiAgDQpGZWksIA0KIA0KeW91IHdyb3RlOiANCiANCkZpcnN0LCANCqGwMi4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi1jY2FtcC1tcGxzLXRwLW9pby0w MSANCg0KVGhlIEdsb2JhbF9JRCBPYmplY3QgYW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0 IGFyZSBkZWZpbmVkIGluIHRoaXMgDQpkcmFmdCwgIHdoaWNoIGRlc2NyaWJlcyB0aGUgcHJvY2Vk dXJlIG9mIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQIA0KKGFzc29jaWF0ZWQgYmlkaXJlY3Rp b25hbCBMU1AgaXMgbm90IGNvdmVyZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbikgYW5kIA0KcmVx dWlyZXMgdGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvciBJQ0NfT3BlcmF0b3JfSUQp aXMgdXNlZCBhbG9uZyANCnRoZSBMU1AuIA0KDQpXaGljaCBpcyBub3QgdHJ1ZS4gVGhlIE9iamVj dCB3ZSBkZWZpbmVkIGNvdWxkIGJlIGNhcnJpZWQgaW4gYm90aCANClBhdGgvUmVzdiBtZXNzYWdl LCBhbmQgaXMgbm90IHJlc3RyaWN0ZWQgZWl0aGVyIHRvIGNvLXJvdXRlZCANCmJpLWRpcmVjdGlv bmFsIExTUCBvciBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExTUC4gDQoNCjxmZWk+IA0KQWx0 aG91Z2ggZWl0aGVyIGNvLXJvdXRlZCBvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlz IG5vdCBtZW50aW9uZWQgDQppbiB0aGlzIGRyYWZ0ICwgYWNjb3JkaW5nIHRvICB0aGUgZGVzY3Jp cGl0aW9uIGluIHNlY3Rpb24gMi4zLCAiIElmIHRoZSANCm5vZGUgYWdyZWVzLCBpdCBNVVNUIHVz ZSB0aGUgc2FtZSBmb3JtYXQgb2YgT3BlcmF0b3IgSUQuICBUaGUgc2FtZSBDLVR5cGUgDQpvZiBP SU8gTVVTVCBiZSBjYXJyaWVkIGluIHRoZSBSZXN2IG1lc3NhZ2UiLCB3aGljaCBtZWFucyB0aGF0 ICB0aGUgDQpwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AuIA0KVGhl IGFib3ZlIGlzIGp1c3QgbXkgdW5kZXJzdGFuZGluZyBhbmQgcHJvdmlkZWQgZm9yIGRpc2N1c3Np b24sIGFuZCBpZiBpdCANCmlzIHdyb25nIG9yIGluYWNjdXJhdGUsIHBsZWFzZSBsZXQgbWUga25v dy4gDQo8L2ZlaT4gDQpUaGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBhYm92ZSBhaW1zIHRvIGd1YXJh bnRlZSB0aGUgc2VuZGVyIGFuZCB0aGUgDQpyZWNlaXZlciB1c2luZyB0aGUgc2FtZSBDLVR5cGUg b2YgdGhlIG9iamVjdCwgaS5lLiBib3RoIGVuZCB1c2luZyANCkdsb2JhbF9JRCBvciBib3RoIHVz aW5nIElDQ19PcGVyYXRvcl9JRC4gDQogIA0KU2Vjb25kLCANCjMuIA0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1u dW0tMDEgDQoNCg0KVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFzIGEgVExWIG9mIHRoZSBMU1Bf QVRUUklCVVRFIG9iamVjdCwgd2hpY2ggd2lsbCANCmFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1l c3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQgb25seSANCmFwcGVhciBpbiB0 aGUgUGF0aCBtZXNzYWdlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIEZ1cnRoZXJt b3JlLCANCnRoaXMgZHJhZnQgZGVmaW5lZCBhIENvbm5lY3Rpb24gVExWIHVzZWQgdG8gY2Fycnkg dGhlIGxvY2FsIHR1bm5lbCBudW1iZXIgDQphc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2Nl bmFyaW8gb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIA0KIA0KV2h5IKGwdHVubmVsIG51 bWJlcqGxIGlzIGNhcnJpZWQgaW4gdGhlIENvbm5lY3Rpb24gVExWPyBJIGRvbid0IHNlZSBpdHMg DQpuZWNlc3NhcnkgZm9yIGJvdGggY28tcm91dGUvIGFzc29jaWF0ZWQgYmktZGlyZWN0aW9uYWwg TFNQLiBDb3VsZCB5b3UgDQpleHBsYWluPyANCiANCjxmZWk+IA0KQXMgSSBzYWlkLCBpdCBpcyB1 c2VmdWwgZm9yIGNvcm91dGVkIChub3QgYXNzb2NpYXRlZCkgYmlkaXJlY3Rpb25hbCBMU1AsIA0K IGNvbnNpZGVyIHRoYXQgdGhlcmUgaXMgb25lIExTUCAoTFNQMSwgaW5pdGlhdGVkIGF0IG5vZGUg QSkgYmV0d2VlbiBub2RlIA0KQS9aLiANCklmIHRoZSBDQy1WIHBha2NldCBpcyAgc2VudCBmcm9t ICBub2RlIFosIHRoZSBNRVBfSUQgb2Ygbm9kZSBaIHdpbGwgYmUgDQppbnNlcnRlZCBpbiB0aGUg T0FNIHBhY2tldHMsIHdoaWNoIGlzIG9yZ2FuaXplZCBieSANCm5vZGVfSUQ6OnR1bm5lbF9udW06 OkxTUF9udW0gDQooc2VjdGlvbiA1LjIuMSBvciA3LjIuMiBvZiBSRkM2MzcwKSwgYW5kIGlmIHRo aXMgTUVQX0lEIGlzIG5vdCBwcmUtc3RvcmVkIA0KYXQgbm9kZSBBLCBpdCBjYW4gbm90IGp1ZGdl IHdoZXRoZXIgdGhpcyBNRVBfSUQgaXMgdmFsaWQuIFNlZSB0aGUgDQpkZXNjcmlwdGlvbiBpbiBz ZWN0aW9uIDUuMS4xLjIgDQooTWlzLUNvbm5lY3Rpdml0eSBEZWZlY3QpIG9mIFJGQzYzNzEuIA0K ICAgICAgICAgICAgICAgICAgTFNQMSANCkEtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t WiANCg0KDQo8L2ZlaT4gDQpXaHkgaXMgdHVubmVsIG51bWJlciBub3Qga25vd24gYnkgbm9kZSBB PyBUaGUgdHVubmVsIG51bWJlciBzaG91bGQgaGFzIA0KYmVlbiBjYXJyaWVkIGluIFNlc3Npb24g YW5kIFNlbmRlciBUZW1wbGF0ZS9GaWx0ZXIgU3BlYyBvYmplY3QgYW5kIA0KZXhjaGFuZ2VkIGJ5 IG5vZGUgQSBhbmQgbm9kZSBaIGR1cmluZyB0aGUgTFNQIHNldC11cC4gQ29ycmVjdCBtZSBpZiBJ IGFtIA0Kd3JvbmcuIA0KICANCkJSLCANClZlcm8gDQoNClRoYW5rcy4gDQogDQpWZXJvIA0KIA0K IA0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiANCnpoYW5nLmZlaTNAenRlLmNvbS5jbg0KU2VudDogU3VuZGF5 LCBKYW51YXJ5IDI5LCAyMDEyIDU6NTAgUE0NClRvOiBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDog W0NDQU1QXSBEaXNjdXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEIA0KIA0KDQpI aSBDQ0FNUGVycyANCg0KQXMgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IElFVEYgbWVldGluZyBhbmQg bWFpbGluZ2xpc3QsIHRoZSBHbG9iYWxfSUQgDQpzaG91bGQgYmUgY2FycmllZCBpbiB0aGUgc2ln bmFsaW5nIG1lc3NhZ2VzLiBPbmUgcmVhc29uIGlzIHRoYXQgdGhlIA0KanVkZ2VtZW50IG9mIGEg bWlzLWNvbm5lY3Rpdml0eSBkZWZlY3QgbmVlZHMgdGhlIEExL1o5IG5vZGVzIHRvIHByZS1zdG9y ZSANCmVhY2ggb3RoZXIncyBNRVBfSUQsIHdob3NlIGZvcm1hdCBpczogR29iYWxfSUQrTm9kZV9J RCtUdW5uZWxfbnVtK0xTUF9udW0uIA0KDQoNCkZvcnR1bmF0ZWx5LCB0aGVyZSBhcmUgc2V2ZXJh bCBkcmFmdHMgcmVsYXRlZCB0byB0aGlzIHRvcGljIG5vdywgDQoNCjEuICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wMS4gDQogIA0KVGhlIEds b2JhX0lEIGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmplY3QgaW4gdGhl IGN1cnJlbnQgDQp2ZXJzaW9uLCB3aGljaCBndWFyYW50ZWVzIHRoYXQgdGhlIGFzc29jaWF0aW9u IGlzIGdsb2JhbCB1bmlxdWUuIFNpbmNlIHRoZSANCkFTU09DSUFUSU9OIG9iamVjdCBpcyB1c2Vk IGFjcm9zcyBkaWZmZXJlbnQgTFNQcywganVzdCBteTJjZW50cywgdGhlIA0KZGVmaW5lZCBmb3Jt YXQgaXMgZGVmaWNpZW50IHRvIGhhbmRsZSBtb3JlIHNjZW5hcmlvcy4gRm9yIGV4YW1wbGU6IA0K DQogICgxKSBDb25zaWRlcmluZyBhIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB3aGljaCBp cyBub3QgcHJvdGVjdGVkIGJ5IA0Kb3RoZXIgTFNQcyB0aHJvdWdoIGNvbnRyb2wgcGxhbmUgYW5k L29yIGRvZXMgbm90IHNoYXJlIHRoZSBzYW1lIHJlc291cmVzIA0Kd2l0aCBvdGhlciBMU1BzLiBJ biB0aGVzZSBjYXNlcywgdGhlIEFTU09DSUFUSU9OIG9iamVjdCB3aWxsIG5vdCBiZSANCmNhcnJp ZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLiANCg0KICAoMikgQ29uc2lkZXJpbmcgYW4gYXNz b2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgYWx0aG91Z2ggdGhlIA0KQVNTT0NJQVRJT04gb2Jq ZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLCB0aGUgZ2xvYmFsX0lEIA0K aW5jb3Jwb3JhdGVkIGluIHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgb25seSANCmluZGljYXRlcyB0 aGUgZ2xvYmFsIHByZWZpeCBvZiB0aGUgQTEgb3IgWjkgbm9kZXMuIElmIHRoaXMgTFNQIGlzIGFj cm9zcyANCmRpZmZlcmVudCBkb21haW5zLCBJIHRoaW5rIHRoZSBjdXJyZW50IGZvcm1hdCBpcyBh bHNvIGRlZmljaWVudCAoQTEgZG9lcyANCm5vdCBrbm93IHRoZSBnb2JhbCBJRCBvZiBaOSBub2Rl IG9yIFo5IG5vZGVzIGRvZXMgbm90IGtub3cgdGhlIGdsb2JhbCBJRCANCm9mIEExICkuIA0KDQoy LiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1wbHMtdHAtb2lv LTAxIA0KDQpUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19PcGVyYXRvcl9JRCBPYmpl Y3QgYXJlIGRlZmluZWQgaW4gdGhpcyANCmRyYWZ0LCAgd2hpY2ggZGVzY3JpYmVzIHRoZSBwcm9j ZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgDQooYXNzb2NpYXRlZCBiaWRpcmVj dGlvbmFsIExTUCBpcyBub3QgY292ZXJlZCBpbiB0aGUgY3VycmVudCB2ZXJzaW9uKSBhbmQgDQpy ZXF1aXJlcyB0aGF0IHRoZSBzYW1lIGZvcm1hdCggR2xvYmFsX0lEIG9yIElDQ19PcGVyYXRvcl9J RClpcyB1c2VkIGFsb25nIA0KdGhlIExTUC4gDQoNCjMuIA0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDEg DQoNCg0KVGhlIEdsb2JhbF9JRCBpcyBjYXJyaWVkIGFzIGEgVExWIG9mIHRoZSBMU1BfQVRUUklC VVRFIG9iamVjdCwgd2hpY2ggd2lsbCANCmFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ug b2YgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQgb25seSANCmFwcGVhciBpbiB0aGUgUGF0 aCBtZXNzYWdlIG9mIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIEZ1cnRoZXJtb3JlLCAN CnRoaXMgZHJhZnQgZGVmaW5lZCBhIENvbm5lY3Rpb24gVExWIHVzZWQgdG8gY2FycnkgdGhlIGxv Y2FsIHR1bm5lbCBudW1iZXIgDQphc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFyaW8g b2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuIA0KDQoNClRoZSBhYm92ZSBtYXRlcmlhbHMg b25seSBwcm92aWRlIHRoZSByb3VnaCBiYWNrZ3JvdW5kLiANCg0KDQpIb3BlIHRvIGhlYXIgdGhl IG9waW5pb25zIGZyb20gdGhlIFdHIHRoYXQgaG93IHRvIGNhcnJ5IHRoZSBHbG9iYWxfSUQsIA0K dGhlbiBtb3ZlIHRoZSB3b3JrIGZvcndhcmQuIA0KDQoNCkJlc3QgcmVnYXJkcyANCg0KOykgDQoN CkZlaSANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQoNCg0K --=_alternative 0003A7344825799E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZyYW5jZXNjbzwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U2VlIGluIGxpbmUgd2l0aCAm bHQ7ZmVpJmd0OyZsdDsvZmVpJmd0OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+SnVzdCBteTJjZW50czwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5GcmFuY2VzY28gRm9uZGVsbGkgJmx0O2ZyYW5jZXNjby5mb25k ZWxsaUBnbWFpbC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTItMDItMDcgMjE6MTQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5WZXJvIFpoZW5nICZsdDt2ZXJvLnpoZW5nQGh1YXdlaS5jb20mZ3Q7LA0KJnF1 b3Q7Y2NhbXBAaWV0Zi5vcmcmcXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+UmU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkNCnRoZSBHbG9i YWxfSUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXpl PTM+PGJyPg0KSGksPGJyPg0KPGJyPg0KaWYgdGhpcyBpcyB0aGUgb25seSB1c2UgY2FzZSBJIHN0 cm9uZ2x5IHN1Z2dlc3QgeW91IHRvIG1ha2UgYW55dGhpbmcgcmVsYXRlZA0KdG8gWjktVHVubmVs X051bSBPUFRJT05BTCBpbiBzaWduYWxpbmcgKGR1bm5vIGlmIHRoaXMgaXMgdGhlIGNhc2UgaW4g eW91cg0KSS1EKS4gUGxlYXNlLjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jmx0O2Zl aSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkkganVzdCBkZXNjcmliZSB0aGlzIHVzZWNh c2UgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIGFuZA0KdGhlIFo5LVR1bm5lbF9OdW0gaXMgT1BUSU9O QUwuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5JZiB3ZSBjb25zaWRlciB0aGUgc2VydmljZSBh Y2Nlc3MgYXQgWjkgbm9kZSwgdGhlIGluZGV4DQp3aWxsIGJlIHNob3J0ZXIsIGJ1dCBpdCBpcyBy ZWxhdGVkIHRvIHRoZSBjb25jcmV0ZSByZWFsaXphdGlvbi4gRnVydGhlcm1vcmUsDQpJIGFtIG5v dCBzdXJlIHdoZXRoZXIgaXQgd2lsbCBoYXZlIGluZmx1ZW5jZSBvbiB0aGUgSUdQIFNob3J0Q3V0 LCBuZWVkDQp0byB0aGluayBhYm91dCBpdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZsdDsv ZmVpJmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCkJUVywgSSdtIHdvbmRlcmlu Zy4uLiBpZiB0aGlzIGlzIGp1c3QgYWJvdXQgTUVQIElEIHdoYXQncyB0aGUgcmVsYXRpb24NCm9m IHlvdXIgSS1EIGFuZCB0aGlzIG9uZTo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTA3Ij48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZT48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNj YW1wLXJzdnAtdGUtbXBscy10cC1vYW0tZXh0LTA3PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z Pjxicj4NCjxicj4NCiZsdDtmZWkmZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+QWN0dWFs bHksIEkgcG9pbnRlZCBvdXQgdGhpcyBvbiB0aGUgbGFzdCBJRVRGIG1lZXRpbmcNCnByZXNlbnRh dGlvbiBtYXRlcmlhbCxwbGVhc2UgY2hlY2sgdGhlIGZvbGxvd2luZyBsaW5rOjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+aHR0cDovL3Rvb2xzLmlldGYub3JnL2FnZW5kYS84Mi9zbGlkZXMvY2Nh bXAtMTAucGRmPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbHQ7L2ZlaSZndDs8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPldoeSBub3Qgc2ltcGx5IGFzc3VtZSB0aGF0IEExLVR1bm5l bF9OdW0gPT0gWjktVHVubmVsX051bQ0KPyAoZm9yIGNvLXJvdXRlZCBiaWRpKSBhbmQgbGVhdmUg R01QTFMgaW4gcGVhY2U/PGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbHQ7ZmVpJmd0 OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+SW4gdGhlIHByYWN0aWNhbCBpbXBsZW1lbnRhdGlv biwgd2UgY2FuIGRvIHRoaXMuIEJ1dCB0aGUNClR1bm5lbCBzcGFjZSBpcyBpbmRlcGVuZGVudCBm cm9tIGVhY2ggb3RoZXIgYXQgZXZlcnkgbm9kZSwgd2hpY2ggbWVhbnMNCnRoYXQgdGhlIGNvbmZs aWN0aW5nIHdpbGwgaGFwcGVuLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZsdDsvZmVpJmd0 Ozxicj4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+dGhhbmtzPGJyPg0KY2lhbzxi cj4NCkZGPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4yMDEyLzIvNyAmbHQ7PC9mb250 PjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dT56aGFuZy5mZWkzQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+ Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KRnJh bmNlc2NvPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQpCZWxvdyBpcyBvbmUgdXNlY2FzZSBiYXNlZCBvbiBteSB1bmRl cnN0YW5kaW5nLjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQTEtLS0tLS0tLS0tLS0tLS0tWjkgKGNvLXJvdXRlZCk8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NClRoZSBNRVBfSUQgb2YgQTEgaXMgQTE6R2xvYmFsX0lEOjpOb2RlX0lEOjpU dW5uZWxfTnVtOjpMU1BfTnVtLCBzaW1pbGFybHkNCnRoZSBNRVBfSUQgb2YgWjkgaXMgWjk6R2xv YmFsX0lEOjpOb2RlX0lEOjpUdW5uZWxfTnVtOjpMU1BfTnVtLjwvZm9udD48Zm9udCBzaXplPTM+ DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkNvbnNp ZGVyIHRoYXQgQ0MtViBwYWNrZXRzIGFyZSBzZW50IGZyb20gWjkgdG8gQTEsIE1FUF9JRCBvZiBa OSBpcyBpbnNlcnRlZA0KaW4gdGhlIENDLVYgcGFja2V0cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoZSBNaXMt Q29ubmVjdGl2aXR5IERlZmVjdCAoUkZDNjM3MSkgaXMgZGVjbGFyZWQgYmFzZWQgb24gdGhlIGNv bXBhcmlzb24NCm9mIGV4cGVjdGVkIE1FUF9JRCBhbmQgcmVjZWl2ZWQgTUVQX0lELCBzbyBBMSBu ZWVkcyB0byBwcmUtc3RvcmUgdGhlIE1FUF9JRA0Kb2YgWjkuPC9mb250Pjxmb250IHNpemU9Mz4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpGb3Igc3Rh dGljIExTUCwgdGhlIGV4Y2hhbmdlcyBvZiBMU1AgaWRlbnRpZmVycyBjYW4gYmUgcmVhbGl6ZWQg YnkgdGhlDQpHQVAgKEctQUNoIEFkdmVydGlzZW1lbnQgUHJvdG9jb2wpIHByb3RvY29sIGRlZmlu ZWQgaW4gdGhlIGRyYWZ0IDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1wbHMtZ2FjaC1hZHYtMDAiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tcGxzLWdhY2gtYWR2LTAwPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPi4NCkFzIHRvIGR5bmFtaWNhbGx5IGVzdGFibGlzaGVkIExTUCwg d2hpY2ggY2FuIGJlIGNhcnJpZWQgaW4gdGhlIHNpZ25hbGluZw0KbWVzc2FnZS48L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCkkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgaW50ZXJwcmV0YXRpb24gaXMgcmVhc29uYWJs ZSB0byB5b3UuPC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQmVzdCByZWdhcmRzPC9mb250Pjxmb250IHNpemU9Mz4g PGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpGZWk8L2Zv bnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NDMlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5GcmFuY2VzY28gRm9uZGVsbGkgJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1t YWlsdG86ZnJhbmNlc2NvLmZvbmRlbGxpQGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PmZyYW5jZXNjby5mb25kZWxs aUBnbWFpbC5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+MjAxMi0wMi0wNyAxNjo1NjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8dGQgd2lk dGg9NTYlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD03JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MiU+PGEgaHJlZj1tYWlsdG86emhhbmcu ZmVpM0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5WZXJvIFpoZW5nICZsdDs8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6 ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+dmVyby56aGVuZ0BodWF3ZWkuY29t PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDssDQomcXVv dDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5jY2FtcEBpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5jY2FtcEBpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250 IHNpemU9Mz4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBo b3cgdG8gY2FycnkNCnRoZSBHbG9iYWxfSUQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdp ZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjxi cj4NCjxicj4NCjxicj4NCkFtIEkgdGhlIG9ubHkgb25lIGhlcmUgdGhhdCBmZWVscyAmcXVvdDt1 bmNvbWZvcnRhYmxlJnF1b3Q7IHdpdGggdGhpcyBhcHByb2FjaA0KYW5kIHRoaXMgYWRkaXRpb25h bCBaOS1UdW5uZWxfTnVtIGluZGV4IGluIEdNUExTIGZseWluZyBmcm9tIGVncmVzcyB0bw0KaW5n cmVzcyAoZm9yIG5vIHJlYXNvbj8hPyk/IEl0IG1pZ2h0IGJlIG5haXZlIG9yIGV2ZW4gc3R1cGlk IGJ1dCBJJ2QgbGlrZQ0KdG8gdW5kZXJzdGFuZCB3aHkgd2UgaGF2ZSB0byBhZGQgYW5vdGhlciBp bmRleC4uLiBwbGVhc2Ugc2hlZCBzb21lIGxpZ2h0DQpvbiBtZS48YnI+DQo8YnI+DQpbSSdtIHRh bGtpbmcgYWJvdXQgY28tcm91dGVkIGJpZGksIEkgZG9uJ3QgY2FyZSBhYm91dCBhc3NvY2lhdGVk XTxicj4NCjxicj4NCnRoYW5rIHlvdTxicj4NCmNpYW88YnI+DQpGRjxicj4NCjxicj4NCjIwMTIv Mi83ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNu PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsNCjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KVmVybzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTMgY29sb3I9I2MwMDAwMCBmYWNlPSJDYWxpYnJpIj48YnI+DQo8YnI+DQpX aHkgaXMgdHVubmVsIG51bWJlciBub3Qga25vd24gYnkgbm9kZSBBPyBUaGUgdHVubmVsIG51bWJl ciBzaG91bGQgaGFzDQpiZWVuIGNhcnJpZWQgaW4gU2Vzc2lvbiBhbmQgU2VuZGVyIFRlbXBsYXRl L0ZpbHRlciBTcGVjIG9iamVjdCBhbmQgZXhjaGFuZ2VkDQpieSBub2RlIEEgYW5kIG5vZGUgWiBk dXJpbmcgdGhlIExTUCBzZXQtdXAuIENvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 YnI+DQpBY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIFJGQzYzNzAsIHNlY3Rpb24gNS4x PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KJm5ic3A7ICZuYnNwO0F0IGVhY2ggZW5kIHBvaW50LCBhIHR1bm5lbCBpcyB1bmlx dWVseSBpZGVudGlmaWVkIGJ5IHRoZQ0KZW5kIHBvaW50J3M8YnI+DQombmJzcDsgTm9kZV9JRCBh bmQgYSBsb2NhbGx5IGFzc2lnbmVkIHR1bm5lbCBudW1iZXIuICZuYnNwO1NwZWNpZmljYWxseSwN CmE8YnI+DQombmJzcDsgJnF1b3Q7VHVubmVsIE51bWJlciZxdW90OyAoVHVubmVsX051bSkgaXMg YSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlcg0KdW5pcXVlPGJyPg0KJm5ic3A7IHdpdGhpbiB0aGUg Y29udGV4dCBvZiB0aGUgTm9kZV9JRC4gJm5ic3A7VGhlIG1vdGl2YXRpb24gZm9yIGVhY2gNCmVu ZCBwb2ludDxicj4NCiZuYnNwOyBoYXZpbmcgaXRzIG93biB0dW5uZWwgbnVtYmVyIGlzIHRvIGFs bG93IGEgY29tcGFjdCBmb3JtIGZvciB0aGU8YnI+DQombmJzcDsgTUVQX0lELiA8YnI+DQo8YnI+ DQpXaGljaCBtZWFucyB0aGF0IGZvciBjby1yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCwgdGhlcmUg YXJlIHR3byB0dW5uZWwgbnVtYmVycywNCm9uZSBpcyBsb2NhbGx5IGFzc2lnbmVkIGF0IG5vZGUg QSBhbmQgdGhlIG90aGVyIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQNCm5vZGUgWi48L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCklm IHRoZSBzaWduYWxpbmcgbWVzc2FnZSBpcyBpbml0aWFsaXplZCBhdCBub2RlIEEsIHRoZSB0dW5u ZWwgbnVtYmVyIGNhcnJpZWQNCmluIFNlc3Npb24vU2VuZGVyIFRlbXBsYXRlIG9iamVjdHMgaXMg bG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIEEuIE9mIGNvdXJzZSwNCmEgbmV3PC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpDLXR5 cGUsbGlrZSB0eXBlPTgsIGNhbiBiZSBkZWZpbmVkIGluIHRoZSBjbGFzcyBvZiBTRVNTSU9OIHRv IGNhcnJ5IGJhY2sNCnRoZSB0dW5uZWwgbnVtYmVyIGFzc2lnbmVkIGF0IG5vZGUgWjsgYnV0IGFj Y29yZGluZyB0byB0aGUgZGlzY3Vzc2lvbiB3aXRoDQpHZW9yZ2UsIEkgZG8gbm90IHRoaW5rIGl0 IGlzIGEgZ29vZCBpZGVhIHdoaWNoIGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlLjwvZm9udD48 Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cjxicj4NClJlZ2FyZHM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCkZlaTwvZm9udD48Zm9udCBzaXplPTM+IDxicj4N CjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD00MSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlZlcm8gWmhlbmcgJmx0 OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PHU+dmVy by56aGVuZ0BodWF3ZWkuY29tPC91PjwvYj48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTItMDItMDcgMTU6MzM8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0K PHRkIHdpZHRoPTU4JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MTAlPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg5JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNA enRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjx1PnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86 emhhbmcuZmVpM0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJs dWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBA aWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0 Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ UkU6IFtDQ0FNUF0gRGlzY3Vzc2lvbiBvbiBob3cgdG8gY2FycnkNCnRoZSBHbG9iYWxfSUQ8L2Zv bnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9 NTAlPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0K PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjxi cj4NCkZlaSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMx ZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NClBsZWFz ZSBzZWUgaW4tbGluZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9 Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4N CkJSLDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3 ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpWZXJvPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxm b250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJD YWxpYnJpIj48YnI+DQpGZWksPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KJm5ic3A7PC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCnlvdSB3cm90 ZTo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KRmlyc3QsIDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQXJpYWwiPjxicj4NCqGwMi4gPC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBscy10cC1vaW8tMDEiIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1Pmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBscy10cC1vaW8tMDE8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPg0KPGJyPg0KPGJyPg0KVGhlIEdsb2JhbF9JRCBP YmplY3QgYW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0IGFyZSBkZWZpbmVkIGluIHRoaXMN CmRyYWZ0LCAmbmJzcDt3aGljaCBkZXNjcmliZXMgdGhlIHByb2NlZHVyZSBvZiBjb3JvdXRlZCBi aWRpcmVjdGlvbmFsIExTUA0KKGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgaXMgbm90IGNv dmVyZWQgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbikgYW5kDQpyZXF1aXJlcyB0aGF0IHRoZSBzYW1l IGZvcm1hdCggR2xvYmFsX0lEIG9yIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkIGFsb25nDQp0aGUg TFNQLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxm b250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjxicj4NCldoaWNo IGlzIG5vdCB0cnVlLiBUaGUgT2JqZWN0IHdlIGRlZmluZWQgY291bGQgYmUgY2FycmllZCBpbiBi b3RoIFBhdGgvUmVzdg0KbWVzc2FnZSwgYW5kIGlzIG5vdCByZXN0cmljdGVkIGVpdGhlciB0byBj by1yb3V0ZWQgYmktZGlyZWN0aW9uYWwgTFNQIG9yDQphc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFs IExTUC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5 N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPGJyPg0KJmx0O2ZlaSZndDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJy Pg0KQWx0aG91Z2ggZWl0aGVyIGNvLXJvdXRlZCBvciBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg TFNQIGlzIG5vdCBtZW50aW9uZWQNCmluIHRoaXMgZHJhZnQgLCBhY2NvcmRpbmcgdG8gJm5ic3A7 dGhlIGRlc2NyaXBpdGlvbiBpbiBzZWN0aW9uIDIuMywgJnF1b3Q7PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJDYWxpYnJpIj4NCklmIHRoZSBub2RlIGFncmVlcywgaXQgTVVTVCB1c2UgdGhlIHNh bWUgZm9ybWF0IG9mIE9wZXJhdG9yIElELiAmbmJzcDtUaGUNCnNhbWUgQy1UeXBlIG9mIE9JTyBN VVNUIGJlIGNhcnJpZWQgaW4gdGhlIFJlc3YgbWVzc2FnZTwvZm9udD48Zm9udCBzaXplPTMgY29s b3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4mcXVvdDssDQp3aGljaCBtZWFucyB0aGF0ICZuYnNw O3RoZSBwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AuPC9mb250Pjxm b250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQpUaGUgYWJvdmUgaXMganVzdCBteSB1bmRlcnN0YW5kaW5nIGFuZCBwcm92aWRl ZCBmb3IgZGlzY3Vzc2lvbiwgYW5kIGlmDQppdCBpcyB3cm9uZyBvciBpbmFjY3VyYXRlLCBwbGVh c2UgbGV0IG1lIGtub3cuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZsdDsvZmVpJmd0OzwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9I2MwMDAwMCBmYWNlPSJDYWxpYnJp Ij48YnI+DQpUaGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBhYm92ZSBhaW1zIHRvIGd1YXJhbnRlZSB0 aGUgc2VuZGVyIGFuZCB0aGUgcmVjZWl2ZXINCnVzaW5nIHRoZSBzYW1lIEMtVHlwZSBvZiB0aGUg b2JqZWN0LCBpLmUuIGJvdGggZW5kIHVzaW5nIEdsb2JhbF9JRCBvciBib3RoDQp1c2luZyBJQ0Nf T3BlcmF0b3JfSUQuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xv cj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTM+ IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpT ZWNvbmQsIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjMuIDwvZm9udD48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1tcGxz LXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1udW0tMDE8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClRoZSBHbG9iYWxfSUQgaXMgY2FycmllZCBh cyBhIFRMViBvZiB0aGUgTFNQX0FUVFJJQlVURSBvYmplY3QsIHdoaWNoIHdpbGwNCmFwcGVhciBp biB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCBhbmQg b25seSBhcHBlYXINCmluIHRoZSBQYXRoIG1lc3NhZ2Ugb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIExTUC4gRnVydGhlcm1vcmUsIHRoaXMNCmRyYWZ0IGRlZmluZWQgYSBDb25uZWN0aW9uIFRM ViB1c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5uZWwgbnVtYmVyIGFzc2lnbmVkDQphdCBaOSBu b2RlcyBpbiB0aGUgc2NlbmFyaW8gb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1AuPC9mb250 Pjxmb250IHNpemU9Mz4NCjxicj4NCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFm NDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpXaHkgobB0dW5uZWwgbnVtYmVyobEgaXMgY2Fycmll ZCBpbiB0aGUgQ29ubmVjdGlvbiBUTFY/IEkgZG9uJ3Qgc2VlIGl0cw0KbmVjZXNzYXJ5IGZvciBi b3RoIGNvLXJvdXRlLyBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExTUC4gQ291bGQgeW91IGV4 cGxhaW4/PC9mb250Pjxmb250IHNpemU9Mz4NCjxicj4NCiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQombHQ7ZmVpJmd0OzwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQpBcyBJIHNhaWQsIGl0IGlzIHVzZWZ1bCBmb3IgY29yb3V0ZWQgKG5vdCBhc3Nv Y2lhdGVkKSBiaWRpcmVjdGlvbmFsIExTUCwNCiZuYnNwO2NvbnNpZGVyIHRoYXQgdGhlcmUgaXMg b25lIExTUCAoTFNQMSwgaW5pdGlhdGVkIGF0IG5vZGUgQSkgYmV0d2Vlbg0Kbm9kZSBBL1ouPC9m b250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9 IkNhbGlicmkiPjxicj4NCklmIHRoZSBDQy1WIHBha2NldCBpcyAmbmJzcDtzZW50IGZyb20gJm5i c3A7bm9kZSBaLCB0aGUgTUVQX0lEIG9mIG5vZGUNClogd2lsbCBiZSBpbnNlcnRlZCBpbiB0aGUg T0FNIHBhY2tldHMsIHdoaWNoIGlzIG9yZ2FuaXplZCBieSBub2RlX0lEOjp0dW5uZWxfbnVtOjpM U1BfbnVtDQo8YnI+DQooc2VjdGlvbiA1LjIuMSBvciA3LjIuMiBvZiBSRkM2MzcwKSwgYW5kIGlm IHRoaXMgTUVQX0lEIGlzIG5vdCBwcmUtc3RvcmVkDQphdCBub2RlIEEsIGl0IGNhbiBub3QganVk Z2Ugd2hldGhlciB0aGlzIE1FUF9JRCBpcyB2YWxpZC4gU2VlIHRoZSBkZXNjcmlwdGlvbg0KaW4g c2VjdGlvbiA1LjEuMS4yPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBj b2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCig8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNhbGlicmkiPjxiPk1pcy1Db25uZWN0aXZpdHkgRGVmZWN0PC9iPjwvZm9udD48Zm9udCBz aXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4pDQpvZiBSRkM2MzcxLjwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxp YnJpIj48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBMU1AxPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBz aXplPTMgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj48YnI+DQpBLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLVo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPGJyPg0KPGJyPg0KJmx0Oy9mZWkm Z3Q7PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jYzAwMDAw IGZhY2U9IkNhbGlicmkiPjxicj4NCldoeSBpcyB0dW5uZWwgbnVtYmVyIG5vdCBrbm93biBieSBu b2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZCBoYXMNCmJlZW4gY2FycmllZCBpbiBTZXNz aW9uIGFuZCBTZW5kZXIgVGVtcGxhdGUvRmlsdGVyIFNwZWMgb2JqZWN0IGFuZCBleGNoYW5nZWQN CmJ5IG5vZGUgQSBhbmQgbm9kZSBaIGR1cmluZyB0aGUgTFNQIHNldC11cC4gQ29ycmVjdCBtZSBp ZiBJIGFtIHdyb25nLjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNv bG9yPSNjMDAwMDAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9 Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jYzAwMDAwIGZhY2U9IkNhbGlicmkiPjxicj4N CkJSLDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9I2MwMDAw MCBmYWNlPSJDYWxpYnJpIj48YnI+DQpWZXJvPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxm b250IHNpemU9MyBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPjxicj4NCjxicj4NClRoYW5r cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNv bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KVmVybzwvZm9udD48Zm9udCBzaXplPTM+ IDxicj4NCiZuYnNwOzxicj4NCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGFob21h Ij48Yj48YnI+DQpGcm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRh aG9tYSI+PHU+Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MyBmYWNlPSJUYWhvbWEiPg0KW21haWx0bzo8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmNjYW1wLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0iVGFob21hIj48dT5jY2FtcC1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zIGZhY2U9IlRhaG9tYSI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj48L2ZvbnQ+PGEgaHJl Zj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT56aGFuZy5mZWkzQHp0ZS5jb20uY248L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGFob21hIj48Yj48YnI+DQpTZW50OjwvYj4gU3Vu ZGF5LCBKYW51YXJ5IDI5LCAyMDEyIDU6NTAgUE08Yj48YnI+DQpUbzo8L2I+IDwvZm9udD48YSBo cmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xv cj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+Y2NhbXBAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0iVGFob21hIj48Yj48YnI+DQpTdWJqZWN0OjwvYj4gW0NDQU1QXSBEaXNj dXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEPC9mb250Pjxmb250IHNpemU9Mz4N Cjxicj4NCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4N CkhpIENDQU1QZXJzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpBcyBkaXNjdXNzZWQg aW4gdGhlIGxhc3QgSUVURiBtZWV0aW5nIGFuZCBtYWlsaW5nbGlzdCwgdGhlIEdsb2JhbF9JRCBz aG91bGQNCmJlIGNhcnJpZWQgaW4gdGhlIHNpZ25hbGluZyBtZXNzYWdlcy4gT25lIHJlYXNvbiBp cyB0aGF0IHRoZSBqdWRnZW1lbnQNCm9mIGEgbWlzLWNvbm5lY3Rpdml0eSBkZWZlY3QgbmVlZHMg dGhlIEExL1o5IG5vZGVzIHRvIHByZS1zdG9yZSBlYWNoIG90aGVyJ3MNCk1FUF9JRCwgd2hvc2Ug Zm9ybWF0IGlzOiBHb2JhbF9JRCtOb2RlX0lEK1R1bm5lbF9udW0rTFNQX251bS48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkFyaWFsIj48YnI+DQo8YnI+DQpGb3J0dW5hdGVseSwgdGhlcmUgYXJlIHNldmVyYWwgZHJh ZnRzIHJlbGF0ZWQgdG8gdGhpcyB0b3BpYyBub3csPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0K PGJyPg0KMS4gJm5ic3A7PC9mb250PjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LTAxIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC0wMTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJBcmlhbCI+LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N CjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJBcmlhbCI+PGJyPg0KVGhlIEdsb2JhX0lEIGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBBU1NP Q0lBVElPTiBvYmplY3QgaW4gdGhlIGN1cnJlbnQNCnZlcnNpb24sIHdoaWNoIGd1YXJhbnRlZXMg dGhhdCB0aGUgYXNzb2NpYXRpb24gaXMgZ2xvYmFsIHVuaXF1ZS4gU2luY2UNCnRoZSBBU1NPQ0lB VElPTiBvYmplY3QgaXMgdXNlZCBhY3Jvc3MgZGlmZmVyZW50IExTUHMsIGp1c3QgbXkyY2VudHMs IHRoZQ0KZGVmaW5lZCBmb3JtYXQgaXMgZGVmaWNpZW50IHRvIGhhbmRsZSBtb3JlIHNjZW5hcmlv cy4gRm9yIGV4YW1wbGU6PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KJm5ic3A7ICgx KSBDb25zaWRlcmluZyBhIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwgTFNQLCB3aGljaCBpcyBub3Qg cHJvdGVjdGVkDQpieSBvdGhlciBMU1BzIHRocm91Z2ggY29udHJvbCBwbGFuZSBhbmQvb3IgZG9l cyBub3Qgc2hhcmUgdGhlIHNhbWUgcmVzb3VyZXMNCndpdGggb3RoZXIgTFNQcy4gSW4gdGhlc2Ug Y2FzZXMsIHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2lsbCBub3QgYmUgY2FycmllZA0KaW4gdGhl IHNpZ2FsaW5nIG1lc3NhZ2VzLiA8YnI+DQo8YnI+DQombmJzcDsgKDIpIENvbnNpZGVyaW5nIGFu IGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIGFsdGhvdWdoIHRoZSBBU1NPQ0lBVElPTg0K b2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2FsaW5nIG1lc3NhZ2VzLCB0aGUgZ2xvYmFsX0lE IGluY29ycG9yYXRlZA0KaW4gdGhlIEFTU09DSUFUSU9OIG9iamVjdCBvbmx5PC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJBcmlhbCI+PGJyPg0KaW5kaWNhdGVzIHRoZSBnbG9iYWwgcHJlZml4IG9mIHRoZSBBMSBvciBa OSBub2Rlcy4gSWYgdGhpcyBMU1AgaXMgYWNyb3NzDQpkaWZmZXJlbnQgZG9tYWlucywgSSB0aGlu ayB0aGUgY3VycmVudCBmb3JtYXQgaXMgYWxzbyBkZWZpY2llbnQgKEExIGRvZXMNCm5vdCBrbm93 IHRoZSBnb2JhbCBJRCBvZiBaOSBub2RlIG9yIFo5IG5vZGVzIGRvZXMgbm90IGtub3cgdGhlIGds b2JhbCBJRA0Kb2YgQTEgKS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjIuIDwvZm9u dD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1w bHMtdHAtb2lvLTAxIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9 IkFyaWFsIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVuLWNjYW1wLW1w bHMtdHAtb2lvLTAxPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj4NCjxi cj4NCjxicj4NClRoZSBHbG9iYWxfSUQgT2JqZWN0IGFuZCB0aGUgSUNDX09wZXJhdG9yX0lEIE9i amVjdCBhcmUgZGVmaW5lZCBpbiB0aGlzDQpkcmFmdCwgJm5ic3A7d2hpY2ggZGVzY3JpYmVzIHRo ZSBwcm9jZWR1cmUgb2YgY29yb3V0ZWQgYmlkaXJlY3Rpb25hbCBMU1ANCihhc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGluIHRoZSBjdXJyZW50IHZlcnNpb24pIGFu ZA0KcmVxdWlyZXMgdGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvciBJQ0NfT3BlcmF0 b3JfSUQpaXMgdXNlZCBhbG9uZw0KdGhlIExTUC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxi cj4NCjMuIDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtdHVubmVsLW51bS0wMSIgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1bm5lbC1u dW0tMDE8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N CjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClRoZSBHbG9iYWxf SUQgaXMgY2FycmllZCBhcyBhIFRMViBvZiB0aGUgTFNQX0FUVFJJQlVURSBvYmplY3QsIHdoaWNo IHdpbGwNCmFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVj dGlvbmFsIExTUCBhbmQgb25seSBhcHBlYXINCmluIHRoZSBQYXRoIG1lc3NhZ2Ugb2YgYXNzb2Np YXRlZCBiaWRpcmVjdGlvbmFsIExTUC4gRnVydGhlcm1vcmUsIHRoaXMNCmRyYWZ0IGRlZmluZWQg YSBDb25uZWN0aW9uIFRMViB1c2VkIHRvIGNhcnJ5IHRoZSBsb2NhbCB0dW5uZWwgbnVtYmVyIGFz c2lnbmVkDQphdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFyaW8gb2YgY29yb3V0ZWQgYmlkaXJlY3Rp b25hbCBMU1AuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KPGJyPg0KVGhlIGFib3Zl IG1hdGVyaWFscyBvbmx5IHByb3ZpZGUgdGhlIHJvdWdoIGJhY2tncm91bmQuIDxicj4NCjxicj4N Cjxicj4NCkhvcGUgdG8gaGVhciB0aGUgb3BpbmlvbnMgZnJvbSB0aGUgV0cgdGhhdCBob3cgdG8g Y2FycnkgdGhlIEdsb2JhbF9JRCwNCnRoZW4gbW92ZSB0aGUgd29yayBmb3J3YXJkLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCjxicj4NCkJlc3QgcmVnYXJkczwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJB cmlhbCI+PGJyPg0KPGJyPg0KOyk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkZlaTwv Zm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PC9mb250Pjxmb250 IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Q0NB TVBAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5DQ0FN UEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4N CjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjxwPg0K --=_alternative 0003A7344825799E_=-- From mach.chen@huawei.com Tue Feb 7 17:17:40 2012 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 D5F2921F84EC; Tue, 7 Feb 2012 17:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 A45RJfV8wDRu; Tue, 7 Feb 2012 17:17:39 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2639B21F84F6; Tue, 7 Feb 2012 17:17:36 -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 <0LZ100D8KVKQPD@szxga03-in.huawei.com>; Wed, 08 Feb 2012 09:17:14 +0800 (CST) Received: from szxrg02-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 <0LZ1000N0VJ950@szxga03-in.huawei.com>; Wed, 08 Feb 2012 09:17:14 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX67176; Wed, 08 Feb 2012 09:17:14 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 09:16:34 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.206]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Wed, 08 Feb 2012 09:17:45 +0800 Date: Wed, 08 Feb 2012 01:17:03 +0000 From: Mach Chen In-reply-to: <4F31285C.6040107@labn.net> X-Originating-IP: [10.108.4.51] To: Lou Berger , Francesco Fondelli Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: [CCAMP] Discussion on how to carry the Global_ID Thread-index: AQHM3mtqrImy7nMdPk6BWVdOo7CN0ZYqcwYAgABMRgCABdMwAIAAD9MAgAAHloCAAE2MAIABRMig X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <4F31285C.6040107@labn.net> Cc: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 08 Feb 2012 01:17:41 -0000 SGkgTG91LA0KDQpJIGFtIGFsd2F5cyBhc3N1bWUgdGhhdCB0aGUgWjktdHVubmVsLW51bSBlcXVh bHMgdG8gQTEtdHVubmVsLW51bSAoZm9yIGNvLXJvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCkuIFRo ZSBtb3RpdmF0aW9uIChmcm9tIHRoZSB0ZXh0IG9mIFJGQzYzNzAgYW5kIHRoZSBwYXN0IGRpc2N1 c3Npb24gb24gTVBMUy1UUCBpZGVudGlmaWVyKSBvZiB0d28gdHVubmVsLW51bXMgaXMgZm9yIHNp bXBsaWZ5aW5nIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBzaWduYWxpbmcsIGZvciBjby1yb3V0 ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHR3byB0dW5uZWwtbnVtcyBhcmUgdW5uZWNlc3NhcnkuIElm IEkgYW0gd3JvbmcsIHBsZWFzZSBjb3JyZWN0IG1lLihjYyBNUExTIFdHKQ0KDQpJTUhPLCB0aGUg c2ltcGxlc3Qgd2F5IGlzIHRvIGV4cGxpY2l0bHkgY2xhcmlmeSB0aGF0IGZvciBjby1yb3V0ZWQg YmlkaXJlY3Rpb25hbCBMU1AsIEExLXR1bm5lbC1udW09WjktdHVubmVsLW51bSwgbWF5YmUgYSBj bGFyaWZpY2F0aW9uIGVycmF0YSBpcyBuZWVkZWQgZm9yIFJGQzYzNzAuDQoNCkJlc3QgcmVnYXJk cywNCk1hY2gNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjY2FtcC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+IExvdSBCZXJnZXINCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMDcsIDIwMTIgOToz NCBQTQ0KPiBUbzogRnJhbmNlc2NvIEZvbmRlbGxpDQo+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW0NDQU1QXSBEaXNjdXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFs X0lEDQo+IA0KPiBGcmFuY2VzY28sDQo+IAlGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgKG1pbmlt dW0pIHJlcXVpcmVtZW50cyBhcmUgYmVpbmcgZHJpdmVuIGJ5DQo+IHJmYzYzNzAuIFRha2UgYSBs b29rIGF0IHNlY3Rpb25zIDUuMiBhbmQgNS4zLCBhbmQgc2VlIGlmIHlvdSBzdGlsbCB0aGluaw0K PiBtb3JlIG1lY2hhbmlzbXMgYXJlIGJlaW5nIGRlZmluZWQgdGhhbiBpcyBuZWNlc3NhcnkuDQo+ IA0KPiBMb3UNCj4gDQo+IE9uIDIvNy8yMDEyIDM6NTYgQU0sIEZyYW5jZXNjbyBGb25kZWxsaSB3 cm90ZToNCj4gPg0KPiA+IEFtIEkgdGhlIG9ubHkgb25lIGhlcmUgdGhhdCBmZWVscyAidW5jb21m b3J0YWJsZSIgd2l0aCB0aGlzIGFwcHJvYWNoIGFuZA0KPiA+IHRoaXMgYWRkaXRpb25hbCBaOS1U dW5uZWxfTnVtIGluZGV4IGluIEdNUExTIGZseWluZyBmcm9tIGVncmVzcyB0bw0KPiA+IGluZ3Jl c3MgKGZvciBubyByZWFzb24/IT8pPyBJdCBtaWdodCBiZSBuYWl2ZSBvciBldmVuIHN0dXBpZCBi dXQgSSdkDQo+ID4gbGlrZSB0byB1bmRlcnN0YW5kIHdoeSB3ZSBoYXZlIHRvIGFkZCBhbm90aGVy IGluZGV4Li4uIHBsZWFzZSBzaGVkIHNvbWUNCj4gPiBsaWdodCBvbiBtZS4NCj4gPg0KPiA+IFtJ J20gdGFsa2luZyBhYm91dCBjby1yb3V0ZWQgYmlkaSwgSSBkb24ndCBjYXJlIGFib3V0IGFzc29j aWF0ZWRdDQo+ID4NCj4gPiB0aGFuayB5b3UNCj4gPiBjaWFvDQo+ID4gRkYNCj4gPg0KPiA+IDIw MTIvMi83IDx6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20u Y24+Pg0KPiA+DQo+ID4NCj4gPiAgICAgVmVybw0KPiA+DQo+ID4gICAgIFdoeSBpcyB0dW5uZWwg bnVtYmVyIG5vdCBrbm93biBieSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZA0KPiA+ ICAgICBoYXMgYmVlbiBjYXJyaWVkIGluIFNlc3Npb24gYW5kIFNlbmRlciBUZW1wbGF0ZS9GaWx0 ZXIgU3BlYyBvYmplY3QNCj4gPiAgICAgYW5kIGV4Y2hhbmdlZCBieSBub2RlIEEgYW5kIG5vZGUg WiBkdXJpbmcgdGhlIExTUCBzZXQtdXAuIENvcnJlY3QgbWUNCj4gPiAgICAgaWYgSSBhbSB3cm9u Zy4NCj4gPg0KPiA+ICAgICBBY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIG9mIFJGQzYzNzAs IHNlY3Rpb24gNS4xDQo+ID4gICAgICAgIEF0IGVhY2ggZW5kIHBvaW50LCBhIHR1bm5lbCBpcyB1 bmlxdWVseSBpZGVudGlmaWVkIGJ5IHRoZSBlbmQgcG9pbnQncw0KPiA+ICAgICAgIE5vZGVfSUQg YW5kIGEgbG9jYWxseSBhc3NpZ25lZCB0dW5uZWwgbnVtYmVyLiAgU3BlY2lmaWNhbGx5LCBhDQo+ ID4gICAgICAgIlR1bm5lbCBOdW1iZXIiIChUdW5uZWxfTnVtKSBpcyBhIDE2LWJpdCB1bnNpZ25l ZCBpbnRlZ2VyIHVuaXF1ZQ0KPiA+ICAgICAgIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0aGUgTm9k ZV9JRC4gIFRoZSBtb3RpdmF0aW9uIGZvciBlYWNoIGVuZA0KPiBwb2ludA0KPiA+ICAgICAgIGhh dmluZyBpdHMgb3duIHR1bm5lbCBudW1iZXIgaXMgdG8gYWxsb3cgYSBjb21wYWN0IGZvcm0gZm9y IHRoZQ0KPiA+ICAgICAgIE1FUF9JRC4NCj4gPg0KPiA+ICAgICBXaGljaCBtZWFucyB0aGF0IGZv ciBjby1yb3V0ZWQgYmlkcmVjdGlvbmFsIExTUCwgdGhlcmUgYXJlIHR3bw0KPiA+ICAgICB0dW5u ZWwgbnVtYmVycywgb25lIGlzIGxvY2FsbHkgYXNzaWduZWQgYXQgbm9kZSBBIGFuZCB0aGUgb3Ro ZXIgaXMNCj4gPiAgICAgbG9jYWxseSBhc3NpZ25lZCBhdCBub2RlIFouDQo+ID4gICAgIElmIHRo ZSBzaWduYWxpbmcgbWVzc2FnZSBpcyBpbml0aWFsaXplZCBhdCBub2RlIEEsIHRoZSB0dW5uZWwg bnVtYmVyDQo+ID4gICAgIGNhcnJpZWQgaW4gU2Vzc2lvbi9TZW5kZXIgVGVtcGxhdGUgb2JqZWN0 cyBpcyBsb2NhbGx5IGFzc2lnbmVkIGF0DQo+ID4gICAgIG5vZGUgQS4gT2YgY291cnNlLCBhIG5l dw0KPiA+ICAgICBDLXR5cGUsbGlrZSB0eXBlPTgsIGNhbiBiZSBkZWZpbmVkIGluIHRoZSBjbGFz cyBvZiBTRVNTSU9OIHRvIGNhcnJ5DQo+ID4gICAgIGJhY2sgdGhlIHR1bm5lbCBudW1iZXIgYXNz aWduZWQgYXQgbm9kZSBaOyBidXQgYWNjb3JkaW5nIHRvIHRoZQ0KPiA+ICAgICBkaXNjdXNzaW9u IHdpdGggR2VvcmdlLCBJIGRvIG5vdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB3aGljaCBpcw0K PiA+ICAgICBub3QgYmFja3dhcmQgY29tcGF0aWJsZS4NCj4gPg0KPiA+ICAgICBSZWdhcmRzDQo+ ID4NCj4gPiAgICAgRmVpDQo+ID4NCj4gPg0KPiA+ICAgICAqVmVybyBaaGVuZyA8dmVyby56aGVu Z0BodWF3ZWkuY29tDQo+IDxtYWlsdG86dmVyby56aGVuZ0BodWF3ZWkuY29tPj4qDQo+ID4NCj4g PiAgICAgMjAxMi0wMi0wNyAxNTozMw0KPiA+DQo+ID4NCj4gPiAgICAg5pS25Lu25Lq6DQo+ID4g ICAgIAkiemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNu PiINCj4gPiAgICAgPHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRl LmNvbS5jbj4+DQo+ID4gICAgIOaKhOmAgQ0KPiA+ICAgICAJImNjYW1wQGlldGYub3JnIDxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmcNCj4gPiAgICAgPG1haWx0bzpjY2Ft cEBpZXRmLm9yZz4+DQo+ID4gICAgIOS4u+mimA0KPiA+ICAgICAJUkU6IFtDQ0FNUF0gRGlzY3Vz c2lvbiBvbiBob3cgdG8gY2FycnkgdGhlIEdsb2JhbF9JRA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICAgRmVpLA0KPiA+DQo+ID4gICAgIFBsZWFzZSBzZWUg aW4tbGluZS4NCj4gPg0KPiA+ICAgICBCUiwNCj4gPiAgICAgVmVybw0KPiA+DQo+ID4gICAgIEZl aSwNCj4gPg0KPiA+ICAgICB5b3Ugd3JvdGU6DQo+ID4NCj4gPiAgICAgRmlyc3QsDQo+ID4gICAg IOKAnDIuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tY2NhbXAtbXBscy10 cC1vaW8tMDENCj4gPg0KPiA+ICAgICBUaGUgR2xvYmFsX0lEIE9iamVjdCBhbmQgdGhlIElDQ19P cGVyYXRvcl9JRCBPYmplY3QgYXJlIGRlZmluZWQgaW4NCj4gPiAgICAgdGhpcyBkcmFmdCwgIHdo aWNoIGRlc2NyaWJlcyB0aGUgcHJvY2VkdXJlIG9mIGNvcm91dGVkIGJpZGlyZWN0aW9uYWwNCj4g PiAgICAgTFNQIChhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQIGlzIG5vdCBjb3ZlcmVkIGlu IHRoZSBjdXJyZW50DQo+ID4gICAgIHZlcnNpb24pIGFuZCByZXF1aXJlcyB0aGF0IHRoZSBzYW1l IGZvcm1hdCggR2xvYmFsX0lEIG9yDQo+ID4gICAgIElDQ19PcGVyYXRvcl9JRClpcyB1c2VkIGFs b25nIHRoZSBMU1AuDQo+ID4NCj4gPiAgICAgV2hpY2ggaXMgbm90IHRydWUuIFRoZSBPYmplY3Qg d2UgZGVmaW5lZCBjb3VsZCBiZSBjYXJyaWVkIGluIGJvdGgNCj4gPiAgICAgUGF0aC9SZXN2IG1l c3NhZ2UsIGFuZCBpcyBub3QgcmVzdHJpY3RlZCBlaXRoZXIgdG8gY28tcm91dGVkDQo+ID4gICAg IGJpLWRpcmVjdGlvbmFsIExTUCBvciBhc3NvY2lhdGVkIGJpLWRpcmVjdGlvbmFsIExTUC4NCj4g Pg0KPiA+ICAgICA8ZmVpPg0KPiA+ICAgICBBbHRob3VnaCBlaXRoZXIgY28tcm91dGVkIG9yIGFz c29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AgaXMgbm90DQo+ID4gICAgIG1lbnRpb25lZCBpbiB0 aGlzIGRyYWZ0ICwgYWNjb3JkaW5nIHRvICB0aGUgZGVzY3JpcGl0aW9uIGluIHNlY3Rpb24NCj4g PiAgICAgMi4zLCAiIElmIHRoZSBub2RlIGFncmVlcywgaXQgTVVTVCB1c2UgdGhlIHNhbWUgZm9y bWF0IG9mIE9wZXJhdG9yDQo+ID4gICAgIElELiAgVGhlIHNhbWUgQy1UeXBlIG9mIE9JTyBNVVNU IGJlIGNhcnJpZWQgaW4gdGhlIFJlc3YgbWVzc2FnZSIsDQo+ID4gICAgIHdoaWNoIG1lYW5zIHRo YXQgIHRoZSBwcm9jZWR1cmUgaXMgZm9yIGNvcm91dGVkIGJpZHJlY3Rpb25hbCBMU1AuDQo+ID4g ICAgIFRoZSBhYm92ZSBpcyBqdXN0IG15IHVuZGVyc3RhbmRpbmcgYW5kIHByb3ZpZGVkIGZvciBk aXNjdXNzaW9uLCBhbmQNCj4gPiAgICAgaWYgaXQgaXMgd3Jvbmcgb3IgaW5hY2N1cmF0ZSwgcGxl YXNlIGxldCBtZSBrbm93Lg0KPiA+ICAgICA8L2ZlaT4NCj4gPiAgICAgVGhlIHByb2NlZHVyZSBk ZXNjcmliZWQgYWJvdmUgYWltcyB0byBndWFyYW50ZWUgdGhlIHNlbmRlciBhbmQgdGhlDQo+ID4g ICAgIHJlY2VpdmVyIHVzaW5nIHRoZSBzYW1lIEMtVHlwZSBvZiB0aGUgb2JqZWN0LCBpLmUuIGJv dGggZW5kIHVzaW5nDQo+ID4gICAgIEdsb2JhbF9JRCBvciBib3RoIHVzaW5nIElDQ19PcGVyYXRv cl9JRC4NCj4gPg0KPiA+ICAgICBTZWNvbmQsDQo+ID4gICAgIDMuDQo+ID4NCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LXR1 bm5lbC1udW0tMA0KPiAxDQo+ID4NCj4gPg0KPiA+ICAgICBUaGUgR2xvYmFsX0lEIGlzIGNhcnJp ZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaA0KPiA+ICAgICB3 aWxsIGFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVjdGlv bmFsIExTUA0KPiA+ICAgICBhbmQgb25seSBhcHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBvZiBh c3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPiA+ICAgICBGdXJ0aGVybW9yZSwgdGhpcyBk cmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUNCj4gPiAgICAg bG9jYWwgdHVubmVsIG51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFyaW8g b2YgY29yb3V0ZWQNCj4gPiAgICAgYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4NCj4gPiAgICAgV2h5 IOKAnHR1bm5lbCBudW1iZXLigJ0gaXMgY2FycmllZCBpbiB0aGUgQ29ubmVjdGlvbiBUTFY/IEkg ZG9uJ3Qgc2VlDQo+ID4gICAgIGl0cyBuZWNlc3NhcnkgZm9yIGJvdGggY28tcm91dGUvIGFzc29j aWF0ZWQgYmktZGlyZWN0aW9uYWwgTFNQLg0KPiA+ICAgICBDb3VsZCB5b3UgZXhwbGFpbj8NCj4g Pg0KPiA+ICAgICA8ZmVpPg0KPiA+ICAgICBBcyBJIHNhaWQsIGl0IGlzIHVzZWZ1bCBmb3IgY29y b3V0ZWQgKG5vdCBhc3NvY2lhdGVkKSBiaWRpcmVjdGlvbmFsDQo+ID4gICAgIExTUCwgIGNvbnNp ZGVyIHRoYXQgdGhlcmUgaXMgb25lIExTUCAoTFNQMSwgaW5pdGlhdGVkIGF0IG5vZGUgQSkNCj4g PiAgICAgYmV0d2VlbiBub2RlIEEvWi4NCj4gPiAgICAgSWYgdGhlIENDLVYgcGFrY2V0IGlzICBz ZW50IGZyb20gIG5vZGUgWiwgdGhlIE1FUF9JRCBvZiBub2RlIFogd2lsbA0KPiA+ICAgICBiZSBp bnNlcnRlZCBpbiB0aGUgT0FNIHBhY2tldHMsIHdoaWNoIGlzIG9yZ2FuaXplZCBieQ0KPiA+ICAg ICBub2RlX0lEOjp0dW5uZWxfbnVtOjpMU1BfbnVtDQo+ID4gICAgIChzZWN0aW9uIDUuMi4xIG9y IDcuMi4yIG9mIFJGQzYzNzApLCBhbmQgaWYgdGhpcyBNRVBfSUQgaXMgbm90DQo+ID4gICAgIHBy ZS1zdG9yZWQgYXQgbm9kZSBBLCBpdCBjYW4gbm90IGp1ZGdlIHdoZXRoZXIgdGhpcyBNRVBfSUQg aXMgdmFsaWQuDQo+ID4gICAgIFNlZSB0aGUgZGVzY3JpcHRpb24gaW4gc2VjdGlvbiA1LjEuMS4y DQo+ID4gICAgICgqTWlzLUNvbm5lY3Rpdml0eSBEZWZlY3QqKSBvZiBSRkM2MzcxLg0KPiA+ICAg ICAgICAgICAgICAgICAgICAgICBMU1AxDQo+ID4gICAgIEEtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tWg0KPiA+DQo+ID4NCj4gPiAgICAgPC9mZWk+DQo+ID4gICAgIFdoeSBpcyB0dW5u ZWwgbnVtYmVyIG5vdCBrbm93biBieSBub2RlIEE/IFRoZSB0dW5uZWwgbnVtYmVyIHNob3VsZA0K PiA+ICAgICBoYXMgYmVlbiBjYXJyaWVkIGluIFNlc3Npb24gYW5kIFNlbmRlciBUZW1wbGF0ZS9G aWx0ZXIgU3BlYyBvYmplY3QNCj4gPiAgICAgYW5kIGV4Y2hhbmdlZCBieSBub2RlIEEgYW5kIG5v ZGUgWiBkdXJpbmcgdGhlIExTUCBzZXQtdXAuIENvcnJlY3QgbWUNCj4gPiAgICAgaWYgSSBhbSB3 cm9uZy4NCj4gPg0KPiA+ICAgICBCUiwNCj4gPiAgICAgVmVybw0KPiA+DQo+ID4gICAgIFRoYW5r cy4NCj4gPg0KPiA+ICAgICBWZXJvDQo+ID4NCj4gPiAgICAgICoNCj4gPiAgICAgRnJvbToqIGNj YW1wLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnPg0KPiA+ ICAgICBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcC1ib3VuY2Vz QGlldGYub3JnPl0NCj4gKk9uDQo+ID4gICAgIEJlaGFsZiBPZiAqemhhbmcuZmVpM0B6dGUuY29t LmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPioNCj4gPiAgICAgU2VudDoqIFN1bmRh eSwgSmFudWFyeSAyOSwgMjAxMiA1OjUwIFBNKg0KPiA+ICAgICBUbzoqIGNjYW1wQGlldGYub3Jn IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Kg0KPiA+ICAgICBTdWJqZWN0OiogW0NDQU1QXSBEaXNj dXNzaW9uIG9uIGhvdyB0byBjYXJyeSB0aGUgR2xvYmFsX0lEDQo+ID4NCj4gPg0KPiA+ICAgICBI aSBDQ0FNUGVycw0KPiA+DQo+ID4gICAgIEFzIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBJRVRGIG1l ZXRpbmcgYW5kIG1haWxpbmdsaXN0LCB0aGUgR2xvYmFsX0lEDQo+ID4gICAgIHNob3VsZCBiZSBj YXJyaWVkIGluIHRoZSBzaWduYWxpbmcgbWVzc2FnZXMuIE9uZSByZWFzb24gaXMgdGhhdCB0aGUN Cj4gPiAgICAganVkZ2VtZW50IG9mIGEgbWlzLWNvbm5lY3Rpdml0eSBkZWZlY3QgbmVlZHMgdGhl IEExL1o5IG5vZGVzIHRvDQo+ID4gICAgIHByZS1zdG9yZSBlYWNoIG90aGVyJ3MgTUVQX0lELCB3 aG9zZSBmb3JtYXQgaXM6DQo+ID4gICAgIEdvYmFsX0lEK05vZGVfSUQrVHVubmVsX251bStMU1Bf bnVtLg0KPiA+DQo+ID4gICAgIEZvcnR1bmF0ZWx5LCB0aGVyZSBhcmUgc2V2ZXJhbCBkcmFmdHMg cmVsYXRlZCB0byB0aGlzIHRvcGljIG5vdywNCj4gPg0KPiA+ICAgICAxLiAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQtMDEuDQo+ID4NCj4gPiAg ICAgVGhlIEdsb2JhX0lEIGlzIGluY29ycG9yYXRlZCBpbnRvIHRoZSBBU1NPQ0lBVElPTiBvYmpl Y3QgaW4gdGhlDQo+ID4gICAgIGN1cnJlbnQgdmVyc2lvbiwgd2hpY2ggZ3VhcmFudGVlcyB0aGF0 IHRoZSBhc3NvY2lhdGlvbiBpcyBnbG9iYWwNCj4gPiAgICAgdW5pcXVlLiBTaW5jZSB0aGUgQVNT T0NJQVRJT04gb2JqZWN0IGlzIHVzZWQgYWNyb3NzIGRpZmZlcmVudCBMU1BzLA0KPiA+ICAgICBq dXN0IG15MmNlbnRzLCB0aGUgZGVmaW5lZCBmb3JtYXQgaXMgZGVmaWNpZW50IHRvIGhhbmRsZSBt b3JlDQo+ID4gICAgIHNjZW5hcmlvcy4gRm9yIGV4YW1wbGU6DQo+ID4NCj4gPiAgICAgICAoMSkg Q29uc2lkZXJpbmcgYSBjb3JvdXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgd2hpY2ggaXMgbm90DQo+ ID4gICAgIHByb3RlY3RlZCBieSBvdGhlciBMU1BzIHRocm91Z2ggY29udHJvbCBwbGFuZSBhbmQv b3IgZG9lcyBub3Qgc2hhcmUNCj4gPiAgICAgdGhlIHNhbWUgcmVzb3VyZXMgd2l0aCBvdGhlciBM U1BzLiBJbiB0aGVzZSBjYXNlcywgdGhlIEFTU09DSUFUSU9ODQo+ID4gICAgIG9iamVjdCB3aWxs IG5vdCBiZSBjYXJyaWVkIGluIHRoZSBzaWdhbGluZyBtZXNzYWdlcy4NCj4gPg0KPiA+ICAgICAg ICgyKSBDb25zaWRlcmluZyBhbiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLCBhbHRob3Vn aCB0aGUNCj4gPiAgICAgQVNTT0NJQVRJT04gb2JqZWN0IGlzIGNhcnJpZWQgaW4gdGhlIHNpZ2Fs aW5nIG1lc3NhZ2VzLCB0aGUNCj4gPiAgICAgZ2xvYmFsX0lEIGluY29ycG9yYXRlZCBpbiB0aGUg QVNTT0NJQVRJT04gb2JqZWN0IG9ubHkNCj4gPiAgICAgaW5kaWNhdGVzIHRoZSBnbG9iYWwgcHJl Zml4IG9mIHRoZSBBMSBvciBaOSBub2Rlcy4gSWYgdGhpcyBMU1AgaXMNCj4gPiAgICAgYWNyb3Nz IGRpZmZlcmVudCBkb21haW5zLCBJIHRoaW5rIHRoZSBjdXJyZW50IGZvcm1hdCBpcyBhbHNvDQo+ ID4gICAgIGRlZmljaWVudCAoQTEgZG9lcyBub3Qga25vdyB0aGUgZ29iYWwgSUQgb2YgWjkgbm9k ZSBvciBaOSBub2RlcyBkb2VzDQo+ID4gICAgIG5vdCBrbm93IHRoZSBnbG9iYWwgSUQgb2YgQTEg KS4NCj4gPg0KPiA+ICAgICAyLiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jaGVu LWNjYW1wLW1wbHMtdHAtb2lvLTAxDQo+ID4NCj4gPiAgICAgVGhlIEdsb2JhbF9JRCBPYmplY3Qg YW5kIHRoZSBJQ0NfT3BlcmF0b3JfSUQgT2JqZWN0IGFyZSBkZWZpbmVkIGluDQo+ID4gICAgIHRo aXMgZHJhZnQsICB3aGljaCBkZXNjcmliZXMgdGhlIHByb2NlZHVyZSBvZiBjb3JvdXRlZCBiaWRp cmVjdGlvbmFsDQo+ID4gICAgIExTUCAoYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBpcyBu b3QgY292ZXJlZCBpbiB0aGUgY3VycmVudA0KPiA+ICAgICB2ZXJzaW9uKSBhbmQgcmVxdWlyZXMg dGhhdCB0aGUgc2FtZSBmb3JtYXQoIEdsb2JhbF9JRCBvcg0KPiA+ICAgICBJQ0NfT3BlcmF0b3Jf SUQpaXMgdXNlZCBhbG9uZyB0aGUgTFNQLg0KPiA+DQo+ID4gICAgIDMuDQo+ID4NCj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LXR1bm5lbC1udW0tMA0KPiAxDQo+ID4NCj4gPg0KPiA+ICAgICBUaGUgR2xvYmFsX0lEIGlzIGNh cnJpZWQgYXMgYSBUTFYgb2YgdGhlIExTUF9BVFRSSUJVVEUgb2JqZWN0LCB3aGljaA0KPiA+ICAg ICB3aWxsIGFwcGVhciBpbiB0aGUgUGF0aC9SZXN2IG1lc3NhZ2Ugb2YgY29yb3V0ZWQgYmlkcmVj dGlvbmFsIExTUA0KPiA+ICAgICBhbmQgb25seSBhcHBlYXIgaW4gdGhlIFBhdGggbWVzc2FnZSBv ZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwgTFNQLg0KPiA+ICAgICBGdXJ0aGVybW9yZSwgdGhp cyBkcmFmdCBkZWZpbmVkIGEgQ29ubmVjdGlvbiBUTFYgdXNlZCB0byBjYXJyeSB0aGUNCj4gPiAg ICAgbG9jYWwgdHVubmVsIG51bWJlciBhc3NpZ25lZCBhdCBaOSBub2RlcyBpbiB0aGUgc2NlbmFy aW8gb2YgY29yb3V0ZWQNCj4gPiAgICAgYmlkaXJlY3Rpb25hbCBMU1AuDQo+ID4NCj4gPg0KPiA+ ICAgICBUaGUgYWJvdmUgbWF0ZXJpYWxzIG9ubHkgcHJvdmlkZSB0aGUgcm91Z2ggYmFja2dyb3Vu ZC4NCj4gPg0KPiA+DQo+ID4gICAgIEhvcGUgdG8gaGVhciB0aGUgb3BpbmlvbnMgZnJvbSB0aGUg V0cgdGhhdCBob3cgdG8gY2FycnkgdGhlDQo+ID4gICAgIEdsb2JhbF9JRCwgdGhlbiBtb3ZlIHRo ZSB3b3JrIGZvcndhcmQuDQo+ID4NCj4gPg0KPiA+ICAgICBCZXN0IHJlZ2FyZHMNCj4gPg0KPiA+ ICAgICA7KQ0KPiA+DQo+ID4gICAgIEZlaQ0KPiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgIENDQU1QIG1haWxpbmcgbGlz dA0KPiA+ICAgICBDQ0FNUEBpZXRmLm9yZyA8bWFpbHRvOkNDQU1QQGlldGYub3JnPg0KPiA+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+ID4NCj4gPg0K PiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+IENDQU1QQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QN Cj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0K From lberger@labn.net Wed Feb 8 08:15:45 2012 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 813C721F879B for ; Wed, 8 Feb 2012 08:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.556 X-Spam-Level: X-Spam-Status: No, score=-98.556 tagged_above=-999 required=5 tests=[AWL=1.605, 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 7ro81ulgcGfo for ; Wed, 8 Feb 2012 08:15:43 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id BE6A321F8796 for ; Wed, 8 Feb 2012 08:15:43 -0800 (PST) Received: (qmail 1769 invoked by uid 0); 8 Feb 2012 16:15:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 8 Feb 2012 16:15:42 -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=UkOvKr12prxwLn+M9HJOAYRPk32GCkQ/ORtuC+cVPAo=; b=CVA+VnSFLHMdAOUdMAItMQ9aIT3TKeY2SB8pHJdWqWr0rtKxdR9EtuVsvv/46n1yX1LwdWl+uvPOwWvcYkq+ubewVMe+LYHoXI92WMn64vEzK9ULY+Zx4iNLGWlzQh8g; 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 1RvABJ-00006y-IN; Wed, 08 Feb 2012 09:15:41 -0700 Message-ID: <4F329FA9.2070707@labn.net> Date: Wed, 08 Feb 2012 11:15:37 -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: Mach Chen References: <2EEA459CD95CCB4988BFAFC0F2287B5C25917498@SZXEML520-MBS.china.huawei.com> <4F31285C.6040107@labn.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 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: "mpls@ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] Discussion on how to carry the Global_ID 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, 08 Feb 2012 16:15:45 -0000 Mach, Sounds like a good discussion to have with the authors of RFC6370... Lou On 2/7/2012 8:17 PM, Mach Chen wrote: > Hi Lou, > > I am always assume that the Z9-tunnel-num equals to A1-tunnel-num > (for co-routed bidirectional LSP). The motivation (from the text of > RFC6370 and the past discussion on MPLS-TP identifier) of two > tunnel-nums is for simplifying associated bidirectional signaling, > for co-routed bidirectional LSP, two tunnel-nums are unnecessary. If > I am wrong, please correct me.(cc MPLS WG) > > IMHO, the simplest way is to explicitly clarify that for co-routed > bidirectional LSP, A1-tunnel-num=Z9-tunnel-num, maybe a clarification > errata is needed for RFC6370. > > Best regards, Mach > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of >> Lou Berger >> Sent: Tuesday, February 07, 2012 9:34 PM >> To: Francesco Fondelli >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] Discussion on how to carry the Global_ID >> >> Francesco, >> From my perspective, the (minimum) requirements are being driven by >> rfc6370. Take a look at sections 5.2 and 5.3, and see if you still think >> more mechanisms are being defined than is necessary. >> >> Lou >> >> On 2/7/2012 3:56 AM, Francesco Fondelli wrote: >>> >>> Am I the only one here that feels "uncomfortable" with this approach and >>> this additional Z9-Tunnel_Num index in GMPLS flying from egress to >>> ingress (for no reason?!?)? It might be naive or even stupid but I'd >>> like to understand why we have to add another index... please shed some >>> light on me. >>> >>> [I'm talking about co-routed bidi, I don't care about associated] >>> >>> thank you >>> ciao >>> FF >>> >>> 2012/2/7 > >>> >>> >>> Vero >>> >>> Why is tunnel number not known by node A? The tunnel number should >>> has been carried in Session and Sender Template/Filter Spec object >>> and exchanged by node A and node Z during the LSP set-up. Correct me >>> if I am wrong. >>> >>> According to the description of RFC6370, section 5.1 >>> At each end point, a tunnel is uniquely identified by the end point's >>> Node_ID and a locally assigned tunnel number. Specifically, a >>> "Tunnel Number" (Tunnel_Num) is a 16-bit unsigned integer unique >>> within the context of the Node_ID. The motivation for each end >> point >>> having its own tunnel number is to allow a compact form for the >>> MEP_ID. >>> >>> Which means that for co-routed bidrectional LSP, there are two >>> tunnel numbers, one is locally assigned at node A and the other is >>> locally assigned at node Z. >>> If the signaling message is initialized at node A, the tunnel number >>> carried in Session/Sender Template objects is locally assigned at >>> node A. Of course, a new >>> C-type,like type=8, can be defined in the class of SESSION to carry >>> back the tunnel number assigned at node Z; but according to the >>> discussion with George, I do not think it is a good idea which is >>> not backward compatible. >>> >>> Regards >>> >>> Fei >>> >>> >>> *Vero Zheng > >* >>> >>> 2012-02-07 15:33 >>> >>> >>> 鏀朵欢浜 >>> "zhang.fei3@zte.com.cn " >>> > >>> 鎶勯 >>> "ccamp@ietf.org " >> > >>> 涓婚 >>> RE: [CCAMP] Discussion on how to carry the Global_ID >>> >>> >>> >>> >>> >>> >>> >>> >>> Fei, >>> >>> Please see in-line. >>> >>> BR, >>> Vero >>> >>> Fei, >>> >>> you wrote: >>> >>> First, >>> 鈥2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 >>> >>> The Global_ID Object and the ICC_Operator_ID Object are defined in >>> this draft, which describes the procedure of corouted bidirectional >>> LSP (associated bidirectional LSP is not covered in the current >>> version) and requires that the same format( Global_ID or >>> ICC_Operator_ID)is used along the LSP. >>> >>> Which is not true. The Object we defined could be carried in both >>> Path/Resv message, and is not restricted either to co-routed >>> bi-directional LSP or associated bi-directional LSP. >>> >>> >>> Although either co-routed or associated bidirectional LSP is not >>> mentioned in this draft , according to the descripition in section >>> 2.3, " If the node agrees, it MUST use the same format of Operator >>> ID. The same C-Type of OIO MUST be carried in the Resv message", >>> which means that the procedure is for corouted bidrectional LSP. >>> The above is just my understanding and provided for discussion, and >>> if it is wrong or inaccurate, please let me know. >>> >>> The procedure described above aims to guarantee the sender and the >>> receiver using the same C-Type of the object, i.e. both end using >>> Global_ID or both using ICC_Operator_ID. >>> >>> Second, >>> 3. >>> >> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-0 >> 1 >>> >>> >>> The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which >>> will appear in the Path/Resv message of corouted bidrectional LSP >>> and only appear in the Path message of associated bidirectional LSP. >>> Furthermore, this draft defined a Connection TLV used to carry the >>> local tunnel number assigned at Z9 nodes in the scenario of corouted >>> bidirectional LSP. >>> >>> Why 鈥渢unnel number鈥 is carried in the Connection TLV? I don't see >>> its necessary for both co-route/ associated bi-directional LSP. >>> Could you explain? >>> >>> >>> As I said, it is useful for corouted (not associated) bidirectional >>> LSP, consider that there is one LSP (LSP1, initiated at node A) >>> between node A/Z. >>> If the CC-V pakcet is sent from node Z, the MEP_ID of node Z will >>> be inserted in the OAM packets, which is organized by >>> node_ID::tunnel_num::LSP_num >>> (section 5.2.1 or 7.2.2 of RFC6370), and if this MEP_ID is not >>> pre-stored at node A, it can not judge whether this MEP_ID is valid. >>> See the description in section 5.1.1.2 >>> (*Mis-Connectivity Defect*) of RFC6371. >>> LSP1 >>> A-------------------------------Z >>> >>> >>> >>> Why is tunnel number not known by node A? The tunnel number should >>> has been carried in Session and Sender Template/Filter Spec object >>> and exchanged by node A and node Z during the LSP set-up. Correct me >>> if I am wrong. >>> >>> BR, >>> Vero >>> >>> Thanks. >>> >>> Vero >>> >>> * >>> From:* ccamp-bounces@ietf.org >>> [mailto:ccamp-bounces@ietf.org ] >> *On >>> Behalf Of *zhang.fei3@zte.com.cn * >>> Sent:* Sunday, January 29, 2012 5:50 PM* >>> To:* ccamp@ietf.org * >>> Subject:* [CCAMP] Discussion on how to carry the Global_ID >>> >>> >>> Hi CCAMPers >>> >>> As discussed in the last IETF meeting and mailinglist, the Global_ID >>> should be carried in the signaling messages. One reason is that the >>> judgement of a mis-connectivity defect needs the A1/Z9 nodes to >>> pre-store each other's MEP_ID, whose format is: >>> Gobal_ID+Node_ID+Tunnel_num+LSP_num. >>> >>> Fortunately, there are several drafts related to this topic now, >>> >>> 1. http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01. >>> >>> The Globa_ID is incorporated into the ASSOCIATION object in the >>> current version, which guarantees that the association is global >>> unique. Since the ASSOCIATION object is used across different LSPs, >>> just my2cents, the defined format is deficient to handle more >>> scenarios. For example: >>> >>> (1) Considering a corouted bidirectional LSP, which is not >>> protected by other LSPs through control plane and/or does not share >>> the same resoures with other LSPs. In these cases, the ASSOCIATION >>> object will not be carried in the sigaling messages. >>> >>> (2) Considering an associated bidirectional LSP, although the >>> ASSOCIATION object is carried in the sigaling messages, the >>> global_ID incorporated in the ASSOCIATION object only >>> indicates the global prefix of the A1 or Z9 nodes. If this LSP is >>> across different domains, I think the current format is also >>> deficient (A1 does not know the gobal ID of Z9 node or Z9 nodes does >>> not know the global ID of A1 ). >>> >>> 2. http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01 >>> >>> The Global_ID Object and the ICC_Operator_ID Object are defined in >>> this draft, which describes the procedure of corouted bidirectional >>> LSP (associated bidirectional LSP is not covered in the current >>> version) and requires that the same format( Global_ID or >>> ICC_Operator_ID)is used along the LSP. >>> >>> 3. >>> >> http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-0 >> 1 >>> >>> >>> The Global_ID is carried as a TLV of the LSP_ATTRIBUTE object, which >>> will appear in the Path/Resv message of corouted bidrectional LSP >>> and only appear in the Path message of associated bidirectional LSP. >>> Furthermore, this draft defined a Connection TLV used to carry the >>> local tunnel number assigned at Z9 nodes in the scenario of corouted >>> bidirectional LSP. >>> >>> >>> The above materials only provide the rough background. >>> >>> >>> Hope to hear the opinions from the WG that how to carry the >>> Global_ID, then move the work forward. >>> >>> >>> Best regards >>> >>> ;) >>> >>> Fei >>> >>> _______________________________________________ >>> 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 From lberger@labn.net Fri Feb 10 08:41:44 2012 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 49D9921F8714 for ; Fri, 10 Feb 2012 08:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.467 X-Spam-Level: X-Spam-Status: No, score=-97.467 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_40=-0.185, 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 XTt7sdmeY1di for ; Fri, 10 Feb 2012 08:41:43 -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 62B4121F86E4 for ; Fri, 10 Feb 2012 08:41:43 -0800 (PST) Received: (qmail 2983 invoked by uid 0); 10 Feb 2012 16:41:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 10 Feb 2012 16:41:41 -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=52UM1etZvRPMpe25J/v4kPUFSxi7AQDX2j9cPox3QJs=; b=uVk2gRMoVp8DRjimpf2u0651psPEpaYVWwC7uJ2sB4qp2GvnFYji24IpJZYQV9CtCWuitmh416Oeqk1cWNFmtNUQ+G8V9IuUxXlZyx3JQdXRR6832Z6qsaWcZdUbGAJn; 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 1RvtXY-0004Ao-RV; Fri, 10 Feb 2012 09:41:40 -0700 Message-ID: <4F3548C1.3030901@labn.net> Date: Fri, 10 Feb 2012 11:41:37 -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@ietf.org References: <20120206220655.31615.33390.idtracker@ietfa.amsl.com> In-Reply-To: <20120206220655.31615.33390.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 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: dbrungard@att.com Subject: Re: [CCAMP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ccamp-rwa-info-13 (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: Fri, 10 Feb 2012 16:41:44 -0000 CCAMP-ers, This revised IPR disclosure alleviates the WG chairs concern on IETF process violations with this very late disclosure of IPR and impact on this WG document. Given these new terms of license, we see no reason to not continue with the current document. Please send mail to the list (or to us) if you have concerns with this decision. We appreciate the effort by Huawei in providing this revised disclosure. Lou and Deborah CCAMP WG Chairs On 2/6/2012 5:06 PM, IETF Secretariat wrote: > > Dear Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku: > > An IPR disclosure that pertains to your Internet-Draft entitled "Routing and > Wavelength Assignment Information Model for Wavelength Switched Optical > Networks" (draft-ietf-ccamp-rwa-info) was submitted to the IETF Secretariat on > 2012-01-31 and has been posted on the "IETF Page of Intellectual Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1672/). The title of the IPR > disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to > draft-ietf-ccamp-rwa-info-13 (2).""); > > The IETF Secretariat > > > > > From lberger@labn.net Fri Feb 10 08:44:52 2012 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 026ED21F8657 for ; Fri, 10 Feb 2012 08:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.757 X-Spam-Level: X-Spam-Status: No, score=-97.757 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_20=-0.74, 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 TQ7ZSFojNcZX for ; Fri, 10 Feb 2012 08:44:51 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id D645F21F8636 for ; Fri, 10 Feb 2012 08:44:50 -0800 (PST) Received: (qmail 8607 invoked by uid 0); 10 Feb 2012 16:44:49 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 10 Feb 2012 16:44:49 -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=pyo/Cn/dGEbwTnLuP4Hd3A6Y2nOC2u6hixthCHD6UYY=; b=UUuObs9lh+cRglD94tk0tH9F7x3mtNieADG1FHWtqlxsN9xEblYW5CKCC7kWDYu+/b5abw19QA+pLIa3lBigAG1x0bevn/3lrq/3s4As4/mQSvYawBPJUijxSsHKSRo7; 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 1Rvtab-0005H0-8O; Fri, 10 Feb 2012 09:44:49 -0700 Message-ID: <4F35497E.5050000@labn.net> Date: Fri, 10 Feb 2012 11:44:46 -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} Cc: "ccamp-ads@tools.ietf.org" Subject: [CCAMP] Reminder: IETF Disclosure Requirements & Process 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, 10 Feb 2012 16:44:52 -0000 All, We wanted to send out a reminder of the IETF's IPR disclosure requirements. To paraphrase, it says that if you have IPR in IETF work you are to either: (a) disclose it (or have your company disclose it), or (b) not participate in discussions or I-Ds which may be encumbered by the IPR. Please take the time to read the rules about disclosing intellectual property as expressed in RFC 3979 and at http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Some key excerpts are: [from the url] (c) in order for the working group and the rest of the IETF to have the information needed to make an informed decision about the use of a particular technology, all those contributing to the working group's discussions must disclose the existence of any IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion. This applies to both Contributors and other participants, and applies whether they contribute in person, via email or by other means. The requirement applies to all IPR of the participant, the participant's employer, sponsor, or others represented by the participants, that is reasonably and personally known to the participant. No patent search is required. [from the RFC] 6.1.1. A Contributor's IPR in his or her Contribution Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. <...> Contributors must disclose IPR meeting the description in this section; there are no exceptions to this rule. <...> 7. Failure to Disclose There are cases where individuals are not permitted by their employers or by other factors to disclose the existence or substance of patent applications or other IPR. Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR for this reason, or any other reason, must not contribute to or participate in IETF activities with respect to technologies that he or she reasonably and personally knows to be Covered by IPR which he or she will not disclose. Contributing to or participating in IETF discussions about a technology without making required IPR disclosures is a violation of IETF process. Lou and Deborah CCAMP WG Chairs From lberger@labn.net Fri Feb 10 08:49:48 2012 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 78AD121F86FC for ; Fri, 10 Feb 2012 08:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.709 X-Spam-Level: X-Spam-Status: No, score=-98.709 tagged_above=-999 required=5 tests=[AWL=1.452, 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 HyyGS2B5I0o6 for ; Fri, 10 Feb 2012 08:49:47 -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 7975821F85AE for ; Fri, 10 Feb 2012 08:49:44 -0800 (PST) Received: (qmail 29496 invoked by uid 0); 10 Feb 2012 16:49:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 10 Feb 2012 16:49: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:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=PxdxFn3cxdCJJYOljGvM/wkZXu/IcNJCGIk0Nr49kKg=; b=wALJd1Hru1JmJhWJ+nxvOYZdIuJIt9RY9nQVL/Vmnsww94q5AQEwr46IpHsLIojdIgVIxQoK7gZAiN2HQAEHa2WdGT1EE/4MS7b0m9f5ffAs8HMmHz6aI0A4xuFJwbBs; 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 1RvtfL-0007H7-HS; Fri, 10 Feb 2012 09:49:43 -0700 Message-ID: <4F354AA4.7050701@labn.net> Date: Fri, 10 Feb 2012 11:49:40 -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} Cc: CCAMP ADs Subject: [CCAMP] Planned CCAMP WG process change 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, 10 Feb 2012 16:49:48 -0000 All, In order to avoid possible future issues, we plan to make a slight change in how the WG processes documents. In particular, we plan to poll authors on their compliance with IETF IPR rules prior to moving a document to the next step in the WG process, e.g., before an individual draft becomes a WG document or a WG document goes to last call. It is likely that you will see similar plans in other WGs in the near future. Please let us know if you have any comments on this plan. Deborah and Lou CCAMP WG Chairs ----------------------------------------------------------------- To: Cc: AD; CCAMP WG Subject: Regarding IPR on Are you aware of any IPR that applies to ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. CCAMP WG Chairs From wang.lei131@zte.com.cn Wed Feb 15 17:20:46 2012 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 B9B8E21E8033 for ; Wed, 15 Feb 2012 17:20:46 -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=[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 Sa7YcRnG3pTW for ; Wed, 15 Feb 2012 17:20:42 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 22F9321E800E for ; Wed, 15 Feb 2012 17:20:41 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280473195744; Thu, 16 Feb 2012 08:52:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 40235.473195744; Thu, 16 Feb 2012 09:20:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1G1KUdL045051 for ; Thu, 16 Feb 2012 09:20:30 +0800 (GMT-8) (envelope-from wang.lei131@zte.com.cn) To: ccamp@ietf.org MIME-Version: 1.0 X-KeepSent: E3266892:41A7F4EE-482579A6:00055250; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.lei131@zte.com.cn Date: Thu, 16 Feb 2012 09:20:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-16 09:20:30, Serialize complete at 2012-02-16 09:20:30 Content-Type: multipart/alternative; boundary="=_alternative 00075F49482579A6_=" X-MAIL: mse02.zte.com.cn q1G1KUdL045051 Subject: [CCAMP] New Version Notification for draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-00.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, 16 Feb 2012 01:20:46 -0000 This is a multipart message in MIME format. --=_alternative 00075F49482579A6_= Content-Type: text/plain; charset="US-ASCII" Hi, CCAMPers, We have just submitted a new draft "draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-00": Filename: draft-wangl-ccamp-ospf-ext-constraint-flexi-grid Revision: 00 Title: OSPF Extensions for Routing Constraint Encoding in Flexible-Grid Networks Creation date: 2012-02-15 WG ID: Individual Submission Number of pages: 22 Abstract: In Flexible-Grid networks, network elements and links may impose additional routing constraints, which cannot be ignored in Routing and Spectrum Assignment (RSA) process. This document describes the requirements of such constraints, and then provides efficient encodings to specify how the information is carried. A URL for this draft is: http://www.ietf.org/id/draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-00.txt If you have any comment or question, welcome to discuss. Thanks and best regards. -------------------------------------------- LeiWang ZTE Bearer Network Product Pre_research Department, Wireline R&D Insititute Cell phone:+86 13811440067 Email: wang.lei131@zte.com.cn hechen0001@gmail.com leiw@tsinghua.edu.cn ---------------------------------------------- -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00075F49482579A6_= Content-Type: text/html; charset="US-ASCII"
Hi, CCAMPers,

We have just submitted a new draft "draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-00":

Filename:                  draft-wangl-ccamp-ospf-ext-constraint-flexi-grid
Revision:                  00
Title:                                   OSPF Extensions for Routing Constraint Encoding in Flexible-Grid Networks
Creation date:                  2012-02-15
WG ID:                                   Individual Submission
Number of pages: 22

Abstract:
  In Flexible-Grid networks, network elements and links may impose
  additional routing constraints, which cannot be ignored in Routing
  and Spectrum Assignment (RSA) process.  This document describes the
  requirements of such constraints, and then provides efficient
  encodings to specify how the information is carried.

A URL for this draft is:
http://www.ietf.org/id/draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-00.txt

If you have any comment or question, welcome to discuss.

Thanks and best regards.


--------------------------------------------
LeiWang

ZTE
Bearer Network Product Pre_research Department,
Wireline R&D Insititute
Cell phone:+86 13811440067
Email: wang.lei131@zte.com.cn
      hechen0001@gmail.com
      leiw@tsinghua.edu.cn
----------------------------------------------
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00075F49482579A6_=-- From Ben.Wright@metaswitch.com Fri Feb 17 04:44:11 2012 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 25B4821F87BD for ; Fri, 17 Feb 2012 04:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 FdcuGgIA1VsK for ; Fri, 17 Feb 2012 04:44:08 -0800 (PST) Received: from ENFICSETS3.metaswitch.com (enficsets3.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id B914E21F87B7 for ; Fri, 17 Feb 2012 04:44:06 -0800 (PST) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFICSETS3.metaswitch.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 17 Feb 2012 12:44:16 +0000 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0247.003; Fri, 17 Feb 2012 12:43:59 +0000 From: Ben Wright To: Zhangfatai , "draft-zhang-ccamp-gmpls-h-lsp-mln@tools.ietf.org" Thread-Topic: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04 Thread-Index: AQHM7XHRoFhIburGsUeouxnBwPb/Gg== Date: Fri, 17 Feb 2012 12:43:59 +0000 Message-ID: References: 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.71.102] Content-Type: multipart/alternative; boundary="_000_B3B6FD81D3159A45B5421AF9DD500F8846DE5884ENFICSMBX1datco_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04 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, 17 Feb 2012 12:44:11 -0000 --_000_B3B6FD81D3159A45B5421AF9DD500F8846DE5884ENFICSMBX1datco_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Fatai, Thanks for pointing me at this draft. I have a few questions on this. The highest level clarification is that I wasn=1B$B!G=1B(Bt sure whether th= is is designed to address just FA-LSPs (which are advertised back into the = same control plane instance) or any H-LSP (which may be advertised into a d= ifferent control plane / routing protocol instance, if at all)? I think t= hat the draft addresses H-LSPs, is that true? The rest of my comments break down into two broad areas: Management of the= automatically created FA/H-LSPs and extensibility to future enhancements. FA-LSP Management How does a network administrator manage these automatically created FA-LSPs= ? I=1B$B!G=1B(Bm assuming that the server resource may not always (typica= lly?) be in 1:1 correspondence with the client resource. Is that correct?= If so, I think that this means that the FA-LSP cannot just be managed via= signalling the client layer LSP, it must be able to be managed explicitly = by network administrators. So, for example, I suspect we=1B$B!G=1B(Bll ne= ed to provide a mechanism to allow the client LSP signalling to carry a set= of identifiers to be associated with the server LSP, so network administra= tors can manage it separately. I=1B$B!G=1B(Bd also like to define the con= ditions under which the FA-LSP can be deleted (e.g. should it be deleted wh= en the client layer LSP is deleted?). Extensibility I=1B$B!G=1B(Bd like us to use a more extensible format for encoding server = layer information. I can see that the mechanism described in the draft cou= ld be applicable to a wide variety of use cases in future and the ERO subob= ject format isn=1B$B!G=1B(Bt easy to extend to meet them. Some examples w= here there might be a requirement to signal more information are below. 1. It could be useful for the client-layer signalling to be able to specif= y parameters that the server layer should use to create the FA-LSP. For e= xample, it would be useful for the client layer to be able to specify that = the server layer should create an FA-LSP to share resources with an existin= g FA-LSP. 2. The client-layer signalling may need to be able to request the server l= ayer creates multiple server layer LSPs to support the client layer connect= ion (e.g. in a VCAT case)? What do you think? Cheers, Ben (and Steve) From: Zhangfatai [mailto:zhangfatai@huawei.com] Sent: 07 February 2012 01:30 To: Ben Wright; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Cc: ccamp@ietf.org Subject: RE: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-= gmpls-signaling-g709v3-01) Hi Ben, I agreed with the scenario and requirement you mentioned. However, I think it is a kind of generic MLN scenario, not just specific to= OTN signaling, so I was trying to capture this in a generic way and docume= nted this in http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-h-lsp-mln-04.= txt. Please review this draft (draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt) to see = if this draft can address your concern. Let=1B$B!G=1B(Bs discuss more on this issue. Thanks Fatai From: Ben Wright [mailto:Ben.Wright@metaswitch.com] Sent: 2012=1B$BG/=1B(B2=1B$B7n=1B(B7=1B$BF|=1B(B 1:05 To: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org Cc: ccamp@ietf.org Subject: Signaling extensions for FA-LSPs (comment on draft-ietf-ccamp-gmpl= s-signaling-g709v3-01) Hi Fatai et al, We have been thinking about function we will need to add to draft-ietf-ccam= p-gmpls-signaling-g709v3-01 to fully support automatically provisioned FA-L= SPs. I wanted to see whether you agree with our analysis. We think that the RSVP-TE signalling should be extended to carry more infor= mation in order to allow other nodes on the signalling path to set up the c= orrect FA-LSP. For example, in the network in http://tools.ietf.org/html= /draft-ietf-ccamp-gmpls-signaling-g709v3-01#section-7, we believe that N1 s= hould be able to prescribe to N2 the set of hops that it should use to set = up the ODU2 FA-LSP, and the signal type of the FA-LSP it should set up, and= (probably) the multiplexing hierarchy to be used at either end. Typicall= y, we=1B$B!G=1B(Bd expect N1 would want to explicitly prevent N2 from query= ing routing to set up the FA-LSP - otherwise, a routing calculation trigge= red by N2 could compute a path for the FA-LSP inconsistent with N1=1B$B!G= =1B(Bs intentions (e.g. which could break some SRLG diversity requirement). What do you think? Is this an issue that you anticipate addressing in the= text for section 7.1 (alluded to as being for future study)? Thanks, Ben Wright and Steve Balls --_000_B3B6FD81D3159A45B5421AF9DD500F8846DE5884ENFICSMBX1datco_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi Fatai, <= /span>

 

Thanks for pointing me= at this draft.   I have a few questions on this. 

 

The highest level clar= ification is that I wasn=1B$B!G=1B(Bt sure whether this is designed to addr= ess just FA-LSPs (which are advertised back into the same control plane ins= tance) or any H-LSP (which may be advertised into a different control plane / routing protocol instance, if at all)? &n= bsp; I think that the draft addresses H-LSPs, is that true?

 

The rest of my comment= s break down into two broad areas:  Management of the automatically cr= eated FA/H-LSPs and extensibility to future enhancements.

 

FA-LSP Management

 

How does a network adm= inistrator manage these automatically created FA-LSPs?   I=1B$B!G= =1B(Bm assuming that the server resource may not always (typically?) be in = 1:1 correspondence with the client resource.   Is that correct?&n= bsp; If so, I think that this means that the FA-LSP cannot just be managed via = signalling the client layer LSP, it must be able to be managed explicitly b= y network administrators.   So, for example, I suspect we=1B= $B!G=1B(Bll need to provide a mechanism to allow the client LSP signalling to carry a set of identifiers to be associated with the ser= ver LSP, so network administrators can manage it separately.   I= =1B$B!G=1B(Bd also like to define the conditions under which the FA-LSP can= be deleted (e.g. should it be deleted when the client layer LSP is deleted?).   

 

Extensibility<= /o:p>

 

I=1B$B!G=1B(Bd like us= to use a more extensible format for encoding server layer information.&nbs= p; I can see that the mechanism described in the draft could be applicable = to a wide variety of use cases in future and the ERO subobject format isn=1B$B!G=1B(Bt easy to extend to meet them.   = ;Some examples where there might be a requirement to signal more informatio= n are below.

 

1.  It could be u= seful for the client-layer signalling to be able to specify parameters that= the server layer should use to create the FA-LSP.   For example,= it would be useful for the client layer to be able to specify that the server layer should create an FA-LSP to share resource= s with an existing FA-LSP. 

2.  The client-la= yer signalling may need to be able to request the server layer creates mult= iple server layer LSPs to support the client layer connection (e.g. in a VC= AT case)? 

 

What do you think?

 

Cheers,

 

Ben (and Steve)

 

 

From: Zhangfatai [mailto:zhangfatai@huawei.com]
Sent: 07 February 2012 01:30
To: Ben Wright; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.o= rg
Cc: ccamp@ietf.org
Subject: RE: Signaling extensions for FA-LSPs (comment on draft-ietf= -ccamp-gmpls-signaling-g709v3-01)

 

Hi B= en,

 

I ag= reed with the scenario and requirement you mentioned.

 

Howe= ver, I think it is a kind of generic MLN scenario, not just specific to OTN= signaling, so I was trying to capture this in a generic way and documented= this in http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt.

 

Plea= se review this draft (draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt) to see if t= his draft can address your concern.

 

Let= =1B$B!G=1B(Bs discuss more on this issue.

 

 

 

Thanks
 
Fatai

 

From: Ben Wright [mailto:Ben.Wright@metaswitch.com]
Sent: 2012=1B$BG/=1B(B2=1B$B7n=1B(B<= /span>7=1B$BF|=1B(B 1:05
To: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Cc: ccamp@ietf.org
Subject: Signaling extensions for FA-LSPs (comment on draft-ietf-cca= mp-gmpls-signaling-g709v3-01)

 

Hi Fatai et al,

 =

We have been thinking ab= out function we will need to add to draft-ietf-ccamp-gmpls-signaling-g709v3= -01 to fully support automatically provisioned FA-LSPs.   I wante= d to see whether you agree with our analysis. 

 =

We think that the RSVP-T= E signalling should be extended to carry more information in order to allow= other nodes on the signalling path to set up the correct FA-LSP. &nbs= p;  For example, in the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmp= ls-signaling-g709v3-01#section-7, we believe that N1 should be a= ble to prescribe to N2 the set of hops that it should use to set up the ODU= 2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be u= sed at either end.   Typically, we=1B$B!G=1B(Bd expect N1 would w= ant to explicitly prevent N2 from querying routing to set up the FA-LSP &nb= sp;– otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1=1B$B!G=1B(Bs intentions= (e.g. which could break some SRLG diversity requirement).   &nbs= p;  

 =

What do you think?  = ; Is this an issue that you anticipate addressing in the text for sect= ion 7.1 (alluded to as being for future study)?   

 =

Thanks,

 =

Ben Wright and Steve Bal= ls

 =

--_000_B3B6FD81D3159A45B5421AF9DD500F8846DE5884ENFICSMBX1datco_-- From internet-drafts@ietf.org Fri Feb 17 12:30:47 2012 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 237BE1F0C4E; Fri, 17 Feb 2012 12:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 AbEhQEc-WQoK; Fri, 17 Feb 2012 12:30:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07DD1F0C4D; Fri, 17 Feb 2012 12:30:26 -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.64p2 Message-ID: <20120217203026.4999.89559.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2012 12:30:26 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-02.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: Fri, 17 Feb 2012 20:30:47 -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 : RSVP Association Object Extensions Author(s) : Lou Berger Francois Le Faucheur Ashok Narayanan Filename : draft-ietf-ccamp-assoc-ext-02.txt Pages : 16 Date : 2012-02-17 The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines extended ASSOCIATION objects which, in particular, can be used in the context of Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-assoc-ext-02.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-assoc-ext-02.txt From lberger@labn.net Fri Feb 17 12:35:56 2012 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 187FF21E804F for ; Fri, 17 Feb 2012 12:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.102 X-Spam-Level: X-Spam-Status: No, score=-99.102 tagged_above=-999 required=5 tests=[AWL=1.059, 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 VghyWfSeuSPC for ; Fri, 17 Feb 2012 12:35:55 -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 5F11721E8020 for ; Fri, 17 Feb 2012 12:35:55 -0800 (PST) Received: (qmail 14565 invoked by uid 0); 17 Feb 2012 20:35:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 17 Feb 2012 20:35:53 -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=qJmt8FghWAQd33tQgbXkXMTz/PyeszGe+CzUadizcEE=; b=HWGTd5tfemuUFRUe3bt8zvSkmQDO3SLfsNwpaMEQpFlP3VBhMt74mY8V5Sgs1mRZ3EfgJt9R/MS3wxt8MopgtEYESfQtWnSt+I0u4hnJBuRZdA9yXdRAdDjrfRj9W96I; 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 1RyUX3-0003Lo-Mo; Fri, 17 Feb 2012 13:35:53 -0700 Message-ID: <4F3EBA25.30005@labn.net> Date: Fri, 17 Feb 2012 15:35:49 -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@ietf.org References: <20120217203026.4999.89559.idtracker@ietfa.amsl.com> In-Reply-To: <20120217203026.4999.89559.idtracker@ietfa.amsl.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: draft-ietf-ccamp-assoc-ext@tools.ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-02.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: Fri, 17 Feb 2012 20:35:56 -0000 All, This update completes the pre-LC actions discussed at the last session and on the mail list. Changes are as follows: - Editorial cleanup, including fixing some references to [ASSOC-INFO] - Clarifications discussed on list with Fei For a full diff see http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-ccamp-assoc-ext-02.txt Lou (for draft authors) On 2/17/2012 3:30 PM, internet-drafts@ietf.org wrote: > > 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 : RSVP Association Object Extensions > Author(s) : Lou Berger > Francois Le Faucheur > Ashok Narayanan > Filename : draft-ietf-ccamp-assoc-ext-02.txt > Pages : 16 > Date : 2012-02-17 > > The RSVP ASSOCIATION object was defined in the context of GMPLS > (Generalized Multi-Protocol Label Switching) controlled label > switched paths (LSPs). In this context, the object is used to > associate recovery LSPs with the LSP they are protecting. This > object also has broader applicability as a mechanism to associate > RSVP state, and this document defines how the ASSOCIATION object > can be more generally applied. This document also defines > extended ASSOCIATION objects which, in particular, can be used in > the context of Transport Profile of Multiprotocol Label Switching > (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC > 3473. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-assoc-ext-02.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-assoc-ext-02.txt > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From db3546@att.com Fri Feb 17 13:52:53 2012 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 129A221E8054 for ; Fri, 17 Feb 2012 13:52:53 -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 VxootOcktDB7 for ; Fri, 17 Feb 2012 13:52:52 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id AFC2D21E8044 for ; Fri, 17 Feb 2012 13:52:51 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1329515570!16172210!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2951 invoked from network); 17 Feb 2012 21:52:51 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-3.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Feb 2012 21:52:51 -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 q1HLrJ2S031991; Fri, 17 Feb 2012 16:53:20 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1HLrEXG031932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 16:53:15 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 17 Feb 2012 16:52:28 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.184]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0355.002; Fri, 17 Feb 2012 16:52:28 -0500 From: "BRUNGARD, DEBORAH A" To: "draft-ietf-ccamp-assoc-ext@tools.ietf.org" Thread-Topic: Regarding IPR on draft-ietf-ccamp-assoc-ext Thread-Index: AcztvnALifEWE3B2SQaEq6toUJm4zQ== Date: Fri, 17 Feb 2012 21:52:28 +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 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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, 17 Feb 2012 21:52:53 -0000 CCAMP, In preparation of this document for WG Last Call: Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. CCAMP WG Chairs From lberger@labn.net Fri Feb 17 14:13:24 2012 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 17B3421F867A for ; Fri, 17 Feb 2012 14:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.135 X-Spam-Level: X-Spam-Status: No, score=-99.135 tagged_above=-999 required=5 tests=[AWL=1.026, 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 o3dk-tswWS3H for ; Fri, 17 Feb 2012 14:13:23 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 2DA7721F866B for ; Fri, 17 Feb 2012 14:13:23 -0800 (PST) Received: (qmail 4824 invoked by uid 0); 17 Feb 2012 22:13:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 17 Feb 2012 22:13:22 -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=1bLRJk7kvnf022fhGRmQz3DjGnofBrLBGezd8wN7seY=; b=q0yTv6jAMrn1VlkO7dtCnHqa0az1owYi7b3SN5h+iwzhgnSZKW3gbbtUm085vQmeM4saAC6f6EXRscTn4kmJepfqvUwgF3j7sVO/6hlAANaXoPpjrZRYiyj2rZFyrKvx; 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 1RyW3O-0003yG-JR; Fri, 17 Feb 2012 15:13:22 -0700 Message-ID: <4F3ED0FE.5010200@labn.net> Date: Fri, 17 Feb 2012 17:13:18 -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: "BRUNGARD, DEBORAH A" 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@ietf.org" , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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, 17 Feb 2012 22:13:24 -0000 On 2/17/2012 4:52 PM, BRUNGARD, DEBORAH A wrote: > CCAMP, > > In preparation of this document for WG Last Call: > > Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? I'm not aware of any IPR that applies to this draft. Lou (co-author of draft in question) > If > so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > CCAMP WG Chairs > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From wwwrun@rfc-editor.org Mon Feb 20 14:58:09 2012 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 34F4921E8025; Mon, 20 Feb 2012 14:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 tbrRNs8K5-Pt; Mon, 20 Feb 2012 14:58:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C3A2321E8026; Mon, 20 Feb 2012 14:58:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5ED02B1E004; Mon, 20 Feb 2012 14:53:04 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120220225304.5ED02B1E004@rfc-editor.org> Date: Mon, 20 Feb 2012 14:53:04 -0800 (PST) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6510 on Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects 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, 20 Feb 2012 22:58:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6510 Title: Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects Author: L. Berger, G. Swallow Status: Standards Track Stream: IETF Date: February 2012 Mailbox: lberger@labn.net, swallow@cisco.com Pages: 8 Characters: 16650 Updates: RFC4875, RFC5420 I-D Tag: draft-ietf-ccamp-attribute-bnf-02.txt URL: http://www.rfc-editor.org/rfc/rfc6510.txt Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP-specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ma-miyazawa@kddilabs.jp Mon Feb 20 17:16:04 2012 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 0BBD721F852B for ; Mon, 20 Feb 2012 17:16:04 -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 WEKtTvySW1Me for ; Mon, 20 Feb 2012 17:16:03 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 064E421E8016 for ; Mon, 20 Feb 2012 17:16:02 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6FD73174813B; Tue, 21 Feb 2012 10:15:57 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2TrVcJokWP3; Tue, 21 Feb 2012 10:15:56 +0900 (JST) Received: from mail.cn.kddilabs.jp (yellow.lan.kddilabs.jp [172.19.98.10]) by mandala.kddilabs.jp (Postfix) with ESMTP id BFC6417480B9; Tue, 21 Feb 2012 10:15:56 +0900 (JST) Received: from miyazawaPC (dhcp228.wlan.kddilabs.jp [172.19.110.228]) by mail.cn.kddilabs.jp (Postfix) with ESMTP id 86D651E0002; Tue, 21 Feb 2012 10:15:56 +0900 (JST) From: "Masanori Miyazawa" To: "'Autumn Liu'" , "'Ben Wright'" , "'CCAMP'" References: <4DAC8EBF.6080400@labn.net> <366E5F2A62306A4783C60773E99A8D62976EBB6C88@ENFIMBOX1.ad.datcon.co.uk> <026d01cc0799$bdb29590$3917c0b0$@jp> <60C093A41B5E45409A19D42CF7786DFD5223CEE939@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD5223CEE939@EUSAACMS0703.eamcs.ericsson.se> Date: Tue, 21 Feb 2012 10:15:56 +0900 Message-ID: <005b01ccf036$5d62ad70$18280850$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv9/aW/CozRUe4rRbO21+TWEhXQ5QCCDyTQAdCyv1Aeu7rtoBt/GEzw Content-Language: ja Subject: Re: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib 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, 21 Feb 2012 01:16:04 -0000 Hi, Autumn My apologies for the delay in responding to your comment. Regarding your comment, we think that the MT-ID cannot be supported in the MIB, because MTR has not yet supported TE. If you have additional comments, please let us know. With best regards, Masanori > -----Original Message----- > From: Autumn Liu [mailto:autumn.liu@ericsson.com] > Sent: Tuesday, October 04, 2011 10:51 AM > To: Masanori Miyazawa; 'Ben Wright'; 'CCAMP' > Subject: RE: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib > > Hi Masanori et al, > > I have a question regarding the TedTable. Should MT-id be added in the entry? > > Thanks, > Autumn > > > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of labn - Lou Berger > > Sent: 18 April 2011 20:19 > > To: CCAMP > > Subject: [CCAMP] 2nd WG last call on draft-ietf-ccamp-gmpls-ted-mib > > > > This mail begins a 2nd WG last call on: > > > > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ted-mib-08 > > > > The draft has been updated after the earlier working group primarily > > based on MIB Dr. review and discussion on the ccamp list. > > > > This working group last call ends on May 2nd. This LC will be > > announced on the MPLS, OSPF, and ISIS WG lists. Please send comments > > to the CCAMP mailing list. > > > > Lou (and Deborah) > > _______________________________________________ > > 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 From flefauch@cisco.com Tue Feb 21 02:25:21 2012 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 52D9821F8680 for ; Tue, 21 Feb 2012 02:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.033 X-Spam-Level: X-Spam-Status: No, score=-10.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 U7ijC5DA35th for ; Tue, 21 Feb 2012 02:25:17 -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 2359C21F8663 for ; Tue, 21 Feb 2012 02:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2012; q=dns/txt; s=iport; t=1329819917; x=1331029517; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vFiNpgw9fFqxqU2ETYrHx3MMuglf9HJSrOySxe7Gftg=; b=bYqT7RtjPNi8F3j79qoiDS0vDI/JgHi001BOmQxCLYCxvYoR7Y2659ig wfulYmxBUt3gNewDjkUk7xDThUj1GqldZRSgwOdZ/MTL89oXJCko0aead BtV0FqiORjk/sGnSFbgEq0hTrJ21oCYmkF2OyW2uYjXSjxIyqp3J4kmQU I=; X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="130045279" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Feb 2012 10:25:16 +0000 Received: from [144.254.53.250] ([144.254.53.250]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LAPFMm027053; Tue, 21 Feb 2012 10:25:15 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: Date: Tue, 21 Feb 2012 11:25:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10F35982-F1EB-4656-9475-75E2A563F79F@cisco.com> References: To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-ccamp-assoc-ext@tools.ietf.org" , "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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: Tue, 21 Feb 2012 10:25:21 -0000 Hello, On 17 Feb 2012, at 22:52, BRUNGARD, DEBORAH A wrote: > CCAMP, >=20 > In preparation of this document for WG Last Call: >=20 > Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? = If > so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. The bulk of the material initially contained in = draft-narayanan-tsvwg-rsvp-resource-sharing was moved to assoc-info, and = then moved to assoc-ext. Therefore, I believe the IPR disclosed on July = 9, 2009 related to draft-narayanan-tsvwg-rsvp-resource-sharing = (https://datatracker.ietf.org/ipr/1169/) would apply to = draft-ietf-ccamp-assoc-ext. I noticed that the I-D tracker lists = draft-narayanan-tsvwg-rsvp-resource-sharing as replaced by = draft-ietf-ccamp-rsvp-resource-sharing, while it was in effect replaced = by the combination of draft-ietf-ccamp-rsvp-resource-sharing and = assoc-info (and eventually assoc-ext). Francois >=20 > If you are on the CCAMP WG email list but are not listed as an author = or > contributor, we remind you of your obligations under the IETF IPR = rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in = any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > CCAMP WG Chairs >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Tue Feb 21 06:31:47 2012 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 410E321F882C for ; Tue, 21 Feb 2012 06:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.166 X-Spam-Level: X-Spam-Status: No, score=-99.166 tagged_above=-999 required=5 tests=[AWL=0.995, 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 hLJ758FQGk1N for ; Tue, 21 Feb 2012 06:31:43 -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 58A7121F8839 for ; Tue, 21 Feb 2012 06:31:43 -0800 (PST) Received: (qmail 32581 invoked by uid 0); 21 Feb 2012 14:31:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 21 Feb 2012 14:31:42 -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=S/tIneAo3V0aKv9jIUp0m59YbUTi9yib+7kZZxSVl2w=; b=E3DmCZQ9AD9c8ZWJ0sgN6hBaAszUp6kk1CqEL5BWFqQ4PLaP5OGizs3nZm64bbTpxdNuWFizJqKjB/i2lltcl+QGadA7eh7GwqQmuVnZv9S61VMy+8AsSDSJbiST8S81; 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 1Rzqko-0004ud-Ju for ccamp@ietf.org; Tue, 21 Feb 2012 07:31:42 -0700 Message-ID: <4F43AACE.7040507@labn.net> Date: Tue, 21 Feb 2012 09:31:42 -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: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 21 Feb 2012 14:31:47 -0000 All, This draft was motivated by the OTN discussion in December. The general issue raised by that discussion was how should we (the WG) assign Switching types going forward. At the time, my proposal was that we should follow general precedent, i.e., per hierarchy level assignment ala PSC-N. The problem with this, as John and the others pointed out, is that there is also precedent for per technology type assignment. The discussion left off with my commitment to submit a draft on the general topic, which is the draft mentioned below. The intent of this draft is to clearly establish which precedent will be followed in the future. Our proposal is that we follow per technology type assignment, i.e., a Switching type value whenever there may be a different SCSI, and remove any relationship to hierarchy from this field. We also propose to deprecate PSC-2,3 & 4. For compatibility sake, we do not propose changing any other existing Switching type values. Obviously, comments are welcome and desired. Lou (as co-author) -------- Original Message -------- Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Date: Tue, 21 Feb 2012 06:23:55 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Revised Definition of The GMPLS Switching Capability and Type Fields Author(s) : Lou Berger Julien Meuric Filename : draft-berger-ccamp-swcaps-update-00.txt Pages : 9 Date : 2012-02-21 GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values using in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-update-00.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-berger-ccamp-swcaps-update-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From lberger@labn.net Tue Feb 21 06:53:18 2012 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 5903E21F884B for ; Tue, 21 Feb 2012 06:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.195 X-Spam-Level: X-Spam-Status: No, score=-99.195 tagged_above=-999 required=5 tests=[AWL=0.966, 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 D9unxrpw+7L3 for ; Tue, 21 Feb 2012 06:53:13 -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 C16B921F8846 for ; Tue, 21 Feb 2012 06:53:13 -0800 (PST) Received: (qmail 18724 invoked by uid 0); 21 Feb 2012 14:53:12 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 21 Feb 2012 14:53: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=i9HAPJTVhGlhGo2dg2K22Ww7xq7m2+PwNPT8jnHRJaM=; b=nepbeu3No726GbloP4CsGy18V2p+IVZIcECFtbmAigBDK8gqPzoOrOFkVZgJAShT6r+cN4xNWstdj4vSe93A/zntpe4I1WL/Qj+rBCUhib4e1OuZnIkr1bVe0XSNE2nP; 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 1Rzr5c-0005jK-6U; Tue, 21 Feb 2012 07:53:12 -0700 Message-ID: <4F43AFD8.4010305@labn.net> Date: Tue, 21 Feb 2012 09:53:12 -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: Francois Le Faucheur References: <10F35982-F1EB-4656-9475-75E2A563F79F@cisco.com> In-Reply-To: <10F35982-F1EB-4656-9475-75E2A563F79F@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@ietf.org" , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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: Tue, 21 Feb 2012 14:53:18 -0000 Francois, Don't you mean: draft-narayanan-tsvwg-rsvp-resource-sharing REPLACED BY draft-ietf-ccamp-assoc-ext AND draft-ietf-ccamp-rsvp-resource-sharing As is shown by the link below, I don't believe any part of the current draft-ietf-ccamp-assoc-info came from draft-narayanan-tsvwg-rsvp-resource-sharing. (Which is why you and Ashok ended up being dropped as co-authors once the text was reorganized into the drafts listed above). http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?difftype=--hwdiff&url1=http://tools.ietf.org/id/draft-berger-ccamp-assoc-info-00.txt&url2=http://tools.ietf.org/id/draft-ietf-ccamp-assoc-info-03.txt Please confirm. Thanks, Lou On 2/21/2012 5:25 AM, Francois Le Faucheur wrote: > Hello, > > On 17 Feb 2012, at 22:52, BRUNGARD, DEBORAH A wrote: > >> CCAMP, >> >> In preparation of this document for WG Last Call: >> >> Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? If >> so, has this IPR been disclosed in compliance with IETF IPR rules (see >> RFCs 3979, 4879, 3669 and 5378 for more details)? >> >> If you are listed as a document author or contributor please answer the >> above by responding to this email regardless of whether or not you are >> aware of any relevant IPR. This document will not advance to the next >> stage until a response has been received from each author and listed >> contributor. > > The bulk of the material initially contained in > draft-narayanan-tsvwg-rsvp-resource-sharing was moved to assoc-info, > and then moved to assoc-ext. Therefore, I believe the IPR disclosed > on July 9, 2009 related to > draft-narayanan-tsvwg-rsvp-resource-sharing > (https://datatracker.ietf.org/ipr/1169/) would apply to > draft-ietf-ccamp-assoc-ext. > > I noticed that the I-D tracker lists > draft-narayanan-tsvwg-rsvp-resource-sharing as replaced by > draft-ietf-ccamp-rsvp-resource-sharing, while it was in effect > replaced by the combination of draft-ietf-ccamp-rsvp-resource-sharing > and assoc-info (and eventually assoc-ext). > > Francois > > >> >> If you are on the CCAMP WG email list but are not listed as an author or >> contributor, we remind you of your obligations under the IETF IPR rules >> which encourages you to notify the IETF if you are aware of IPR of >> others on an IETF contribution, or to refrain from participating in any >> contribution or discussion related to your undisclosed IPR. For more >> information, please see the RFCs listed above and >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> CCAMP WG Chairs >> >> >> _______________________________________________ >> 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 ashokn@cisco.com Tue Feb 21 08:19:51 2012 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 592B821F885E for ; Tue, 21 Feb 2012 08:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 7vZr-xx5+ynp for ; Tue, 21 Feb 2012 08:19:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE221F8591 for ; Tue, 21 Feb 2012 08:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3631; q=dns/txt; s=iport; t=1329841187; x=1331050787; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=y3DdZwbDwNXAqoqezhnWF4IOjdfmaIKn3F0zfly6EJg=; b=Do+a+FmkFg5bTHzUSfNrY+90N3zwl7IbLlmTCXNIQVmnLqPoInGkyKHp HG0z1s0Cvc8QHbYL46kgkWCphOYgi+3wlTvcfOQ/T78sxn6oqZfk3qsZP Gmto+z1OWpXLAKtgwWwmDVnipe6dJrfIP6qoSxI5RbANPy+ypt5D3N6Uf w=; X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="58019739" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 21 Feb 2012 16:19:45 +0000 Received: from che-vpn-cluster-1-88.cisco.com (che-vpn-cluster-1-88.cisco.com [10.86.240.88]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1LGJhGF006183; Tue, 21 Feb 2012 16:19:44 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ashok Narayanan In-Reply-To: <4F43AFD8.4010305@labn.net> Date: Tue, 21 Feb 2012 11:19:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <26974879-E2EA-4242-A8FC-34F882DFA3E9@cisco.com> References: <10F35982-F1EB-4656-9475-75E2A563F79F@cisco.com> <4F43AFD8.4010305@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-ccamp-assoc-ext@tools.ietf.org" , "ccamp@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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: Tue, 21 Feb 2012 16:19:51 -0000 Yes, that's correct. There may have been some temporary housing in = draft-ietf-ccamp-assoc-info at some time but now the drafts are = distinct. Just to be explicit, Cisco's IPR claim detailed at = https://datatracker.ietf.org/ipr/1169/ is specific to = draft-ietf-ccamp-assoc-ext. -Ashok On Feb 21, 2012, at 2/21 9:53 AM, Lou Berger wrote: > Francois, > Don't you mean: > draft-narayanan-tsvwg-rsvp-resource-sharing > REPLACED BY > draft-ietf-ccamp-assoc-ext > AND > draft-ietf-ccamp-rsvp-resource-sharing >=20 > As is shown by the link below, I don't believe any part of the current > draft-ietf-ccamp-assoc-info came from > draft-narayanan-tsvwg-rsvp-resource-sharing. (Which is why you and = Ashok > ended up being dropped as co-authors once the text was reorganized = into > the drafts listed above). > = http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?difftype=3D--hwdiff&url1=3D= http://tools.ietf.org/id/draft-berger-ccamp-assoc-info-00.txt&url2=3Dhttp:= //tools.ietf.org/id/draft-ietf-ccamp-assoc-info-03.txt >=20 > Please confirm. >=20 > Thanks, > Lou >=20 > On 2/21/2012 5:25 AM, Francois Le Faucheur wrote: >> Hello, >>=20 >> On 17 Feb 2012, at 22:52, BRUNGARD, DEBORAH A wrote: >>=20 >>> CCAMP, >>>=20 >>> In preparation of this document for WG Last Call: >>>=20 >>> Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? = If >>> so, has this IPR been disclosed in compliance with IETF IPR rules = (see >>> RFCs 3979, 4879, 3669 and 5378 for more details)? >>>=20 >>> If you are listed as a document author or contributor please answer = the >>> above by responding to this email regardless of whether or not you = are >>> aware of any relevant IPR. This document will not advance to the = next >>> stage until a response has been received from each author and listed >>> contributor. >>=20 >> The bulk of the material initially contained in >> draft-narayanan-tsvwg-rsvp-resource-sharing was moved to assoc-info, >> and then moved to assoc-ext. Therefore, I believe the IPR disclosed >> on July 9, 2009 related to >> draft-narayanan-tsvwg-rsvp-resource-sharing >> (https://datatracker.ietf.org/ipr/1169/) would apply to >> draft-ietf-ccamp-assoc-ext. >>=20 >> I noticed that the I-D tracker lists >> draft-narayanan-tsvwg-rsvp-resource-sharing as replaced by >> draft-ietf-ccamp-rsvp-resource-sharing, while it was in effect >> replaced by the combination of draft-ietf-ccamp-rsvp-resource-sharing >> and assoc-info (and eventually assoc-ext). >>=20 >> Francois >>=20 >>=20 >>>=20 >>> If you are on the CCAMP WG email list but are not listed as an = author or >>> contributor, we remind you of your obligations under the IETF IPR = rules >>> which encourages you to notify the IETF if you are aware of IPR of >>> others on an IETF contribution, or to refrain from participating in = any >>> contribution or discussion related to your undisclosed IPR. For = more >>> information, please see the RFCs listed above and >>> = http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >>>=20 >>> CCAMP WG Chairs >>>=20 >>>=20 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From flefauch@cisco.com Tue Feb 21 09:24:00 2012 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 13EEA21F8565 for ; Tue, 21 Feb 2012 09:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.686 X-Spam-Level: X-Spam-Status: No, score=-8.686 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] 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 6D3w0zfaLX2n for ; Tue, 21 Feb 2012 09:23:55 -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 6EAD021F87A7 for ; Tue, 21 Feb 2012 09:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=38920; q=dns/txt; s=iport; t=1329845030; x=1331054630; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=0ZdH9hRxTfcew+lYizXekDVSniHLWOjqvAQay8+buwI=; b=GAUgfcdxscGFZdlYIi0HACqTtrLzTz3QW54nKEa2KUlL91cBMNW3lgnA ALI4YxX2GGmsH0LWDo4ZWk0BUWyTkQEXD+QNERcutbayZG83M8M2jlQb3 BZWZjZIwPlxTwZa7/tJ8YbYtIfep2qo7vKUH3x5fJAQlAX+T2IkP9YlEE o=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="66678271" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 21 Feb 2012 17:23:49 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1LHNlZG013568; Tue, 21 Feb 2012 17:23:47 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-113--649477307 From: Francois Le Faucheur In-Reply-To: <26974879-E2EA-4242-A8FC-34F882DFA3E9@cisco.com> Date: Tue, 21 Feb 2012 18:24:00 +0100 Message-Id: <71F78851-F594-4441-82E8-489406368EF5@cisco.com> References: <10F35982-F1EB-4656-9475-75E2A563F79F@cisco.com> <4F43AFD8.4010305@labn.net> <26974879-E2EA-4242-A8FC-34F882DFA3E9@cisco.com> To: Ashok Narayanan X-Mailer: Apple Mail (2.1084) Cc: "ccamp-ads@tools.ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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: Tue, 21 Feb 2012 17:24:00 -0000 --Apple-Mail-113--649477307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 21 Feb 2012, at 17:19, Ashok Narayanan wrote: > Yes, that's correct. Yes. > There may have been some temporary housing in = draft-ietf-ccamp-assoc-info at some time Exactly (that is why I said "assoc-info (and eventually assoc-ext)"). > but now the drafts are distinct. Agreed. >=20 >> Francois, >> Don't you mean: >> draft-narayanan-tsvwg-rsvp-resource-sharing >> REPLACED BY >> draft-ietf-ccamp-assoc-ext >> AND >> draft-ietf-ccamp-rsvp-resource-sharing Yes (with current versions of the document). Cheers Francois >>=20 >> As is shown by the link below, I don't believe any part of the = current >> draft-ietf-ccamp-assoc-info came from >> draft-narayanan-tsvwg-rsvp-resource-sharing. (Which is why you and = Ashok >> ended up being dropped as co-authors once the text was reorganized = into >> the drafts listed above). >> = http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?difftype=3D--hwdiff&url1=3D= http://tools.ietf.org/id/draft-berger-ccamp-assoc-info-00.txt&url2=3Dhttp:= //tools.ietf.org/id/draft-ietf-ccamp-assoc-info-03.txt >>=20 >> Please confirm. >>=20 >> Thanks, >> Lou >>=20 >> On 2/21/2012 5:25 AM, Francois Le Faucheur wrote: >>> Hello, >>>=20 >>> On 17 Feb 2012, at 22:52, BRUNGARD, DEBORAH A wrote: >>>=20 >>>> CCAMP, >>>>=20 >>>> In preparation of this document for WG Last Call: >>>>=20 >>>> Are you aware of any IPR that applies to = draft-ietf-ccamp-assoc-ext? If >>>> so, has this IPR been disclosed in compliance with IETF IPR rules = (see >>>> RFCs 3979, 4879, 3669 and 5378 for more details)? >>>>=20 >>>> If you are listed as a document author or contributor please answer = the >>>> above by responding to this email regardless of whether or not you = are >>>> aware of any relevant IPR. This document will not advance to the = next >>>> stage until a response has been received from each author and = listed >>>> contributor. >>>=20 >>> The bulk of the material initially contained in >>> draft-narayanan-tsvwg-rsvp-resource-sharing was moved to assoc-info, >>> and then moved to assoc-ext. Therefore, I believe the IPR disclosed >>> on July 9, 2009 related to >>> draft-narayanan-tsvwg-rsvp-resource-sharing >>> (https://datatracker.ietf.org/ipr/1169/) would apply to >>> draft-ietf-ccamp-assoc-ext. >>>=20 >>> I noticed that the I-D tracker lists >>> draft-narayanan-tsvwg-rsvp-resource-sharing as replaced by >>> draft-ietf-ccamp-rsvp-resource-sharing, while it was in effect >>> replaced by the combination of = draft-ietf-ccamp-rsvp-resource-sharing >>> and assoc-info (and eventually assoc-ext). >>>=20 >>> Francois >>>=20 >>>=20 >>>>=20 >>>> If you are on the CCAMP WG email list but are not listed as an = author or >>>> contributor, we remind you of your obligations under the IETF IPR = rules >>>> which encourages you to notify the IETF if you are aware of IPR of >>>> others on an IETF contribution, or to refrain from participating in = any >>>> contribution or discussion related to your undisclosed IPR. For = more >>>> information, please see the RFCs listed above and >>>> = http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >>>>=20 >>>> CCAMP WG Chairs >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>=20 >>>=20 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >=20 Francois Le Faucheur Distinguished Engineer Service Provider Video Technology Group =20 flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-113--649477307 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-114--649477307 --Apple-Mail-114--649477307 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Yes, that's correct. =

Yes.

There may have been some temporary housing in = draft-ietf-ccamp-assoc-info at some = time

Exactly (that is why I said = "assoc-info (and eventually assoc-ext)").

but now the drafts are = distinct.

Agreed.

=

Francois,
Don't you = mean:
draft-narayanan-tsvwg-rsvp-resource-sharing
=
REPLACED BY
draft-ietf-ccamp-assoc-ext
AND
draft-ietf-ccamp-rsvp-resource-sharing

Yes (with current versions of the = document).

Cheers

Franco= is



As is shown by = the link below, I don't believe any part of the = current
draft-ietf-ccamp-assoc-info came = from
draft-narayanan-tsvwg-rsvp-resource-sharing. (Which is why = you and Ashok
ended up being = dropped as co-authors once the text was reorganized = into
the drafts listed = above).
ht= tp://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?difftype=3D--hwdiff&url1=3D= http://tools.ietf.org/id/draft-berger-ccamp-assoc-info-00.txt&url2=3Dh= ttp://tools.ietf.org/id/draft-ietf-ccamp-assoc-info-03.txt

Please confirm.

Thanks,
Lou

On 2/21/2012 = 5:25 AM, Francois Le Faucheur wrote:
Hello,

On 17 Feb 2012, at 22:52, = BRUNGARD, DEBORAH A wrote:

CCAMP,

In = preparation of this document for WG Last = Call:

Are = you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? = If
so, = has this IPR been disclosed in compliance with IETF IPR rules = (see
RFCs = 3979, 4879, 3669 and 5378 for more = details)?

If you = are listed as a document author or contributor please answer = the
above = by responding to this email regardless of whether or not you = are
aware = of any relevant IPR.  This document will not advance to the = next
stage = until a response has been received from each author and = listed
contributor.

The bulk of the material = initially contained in
draft-narayanan-tsvwg-rsvp-resource-sharing was moved to = assoc-info,
and then moved to assoc-ext. = Therefore, I believe the IPR = disclosed
on July 9, 2009 related = to
draft-narayanan-tsvwg-rsvp-resource-sharing
=
(https://datatracker.ietf.o= rg/ipr/1169/) would apply = to
draft-ietf-ccamp-assoc-ext.

I noticed that the I-D tracker = lists
draft-narayanan-tsvwg-rsvp-resource-sharing as replaced = by
draft-ietf-ccamp-rsvp-resource-sharing, while it was in = effect
replaced by the combination of = draft-ietf-ccamp-rsvp-resource-sharing
and assoc-info (and = eventually assoc-ext).

Francois



If you = are on the CCAMP WG email list but are not listed as an author = or
contributor, we remind you of your obligations under the = IETF IPR rules
which = encourages you to notify the IETF if you are aware of IPR = of
others = on an IETF contribution, or to refrain from participating in = any
contribution or discussion related to your undisclosed = IPR.  For = more
information, please see the RFCs listed above = and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

CCAMP = WG Chairs


_______________________________________________
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



Francois Le = Faucheur
Distinguished = Engineer
Service Provider Video Technology Group =   

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-114--649477307 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-114--649477307-- --Apple-Mail-113--649477307-- From lberger@labn.net Tue Feb 21 09:26:46 2012 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 7BD9721F8878 for ; Tue, 21 Feb 2012 09:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.249 X-Spam-Level: X-Spam-Status: No, score=-99.249 tagged_above=-999 required=5 tests=[AWL=0.912, 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 0SqBEPgz9lrZ for ; Tue, 21 Feb 2012 09:26:41 -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 96BF121F887B for ; Tue, 21 Feb 2012 09:26:41 -0800 (PST) Received: (qmail 24153 invoked by uid 0); 21 Feb 2012 17:26:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 21 Feb 2012 17:26:40 -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=js0WHfQgNhmJVBKloZZAIEgJ43QnoNcmuGmNnpN1894=; b=QmriufMkqFgn8QtBkSgFkPAhe5I0Goz07uElhM8JPmWu7igvNKcpfgnRY7AlQfJs5xEeMuWwbWAL79WIaTz/L0d0h45Z5gFZqkFmuObQLDr/PyQdtZblzD07jWKEvH09; 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 1RztU8-0002Nk-Hl; Tue, 21 Feb 2012 10:26:40 -0700 Message-ID: <4F43D3CF.7070100@labn.net> Date: Tue, 21 Feb 2012 12:26:39 -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: Francois Le Faucheur References: <10F35982-F1EB-4656-9475-75E2A563F79F@cisco.com> <4F43AFD8.4010305@labn.net> <26974879-E2EA-4242-A8FC-34F882DFA3E9@cisco.com> <71F78851-F594-4441-82E8-489406368EF5@cisco.com> In-Reply-To: <71F78851-F594-4441-82E8-489406368EF5@cisco.com> 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" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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: Tue, 21 Feb 2012 17:26:46 -0000 Excellent. We have definitely had a case of "hot potato" text here. Very confusing... Thanks, Lou On 2/21/2012 12:24 PM, Francois Le Faucheur wrote: > > On 21 Feb 2012, at 17:19, Ashok Narayanan wrote: > >> Yes, that's correct. > > Yes. > >> There may have been some temporary housing in >> draft-ietf-ccamp-assoc-info at some time > > Exactly (that is why I said "assoc-info (and eventually assoc-ext)"). > >> but now the drafts are distinct. > > Agreed. > >> >>> Francois, >>> Don't you mean: >>> draft-narayanan-tsvwg-rsvp-resource-sharing >>> REPLACED BY >>> draft-ietf-ccamp-assoc-ext >>> AND >>> draft-ietf-ccamp-rsvp-resource-sharing > > Yes (with current versions of the document). > > Cheers > > Francois > > >>> >>> As is shown by the link below, I don't believe any part of the current >>> draft-ietf-ccamp-assoc-info came from >>> draft-narayanan-tsvwg-rsvp-resource-sharing. (Which is why you and Ashok >>> ended up being dropped as co-authors once the text was reorganized into >>> the drafts listed above). >>> http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?difftype=--hwdiff&url1=http://tools.ietf.org/id/draft-berger-ccamp-assoc-info-00.txt&url2=http://tools.ietf.org/id/draft-ietf-ccamp-assoc-info-03.txt >>> >>> >>> Please confirm. >>> >>> Thanks, >>> Lou >>> >>> On 2/21/2012 5:25 AM, Francois Le Faucheur wrote: >>>> Hello, >>>> >>>> On 17 Feb 2012, at 22:52, BRUNGARD, DEBORAH A wrote: >>>> >>>>> CCAMP, >>>>> >>>>> In preparation of this document for WG Last Call: >>>>> >>>>> Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? If >>>>> so, has this IPR been disclosed in compliance with IETF IPR rules (see >>>>> RFCs 3979, 4879, 3669 and 5378 for more details)? >>>>> >>>>> If you are listed as a document author or contributor please answer the >>>>> above by responding to this email regardless of whether or not you are >>>>> aware of any relevant IPR. This document will not advance to the next >>>>> stage until a response has been received from each author and listed >>>>> contributor. >>>> >>>> The bulk of the material initially contained in >>>> draft-narayanan-tsvwg-rsvp-resource-sharing was moved to assoc-info, >>>> and then moved to assoc-ext. Therefore, I believe the IPR disclosed >>>> on July 9, 2009 related to >>>> draft-narayanan-tsvwg-rsvp-resource-sharing >>>> (https://datatracker.ietf.org/ipr/1169/) would apply to >>>> draft-ietf-ccamp-assoc-ext. >>>> >>>> I noticed that the I-D tracker lists >>>> draft-narayanan-tsvwg-rsvp-resource-sharing as replaced by >>>> draft-ietf-ccamp-rsvp-resource-sharing, while it was in effect >>>> replaced by the combination of draft-ietf-ccamp-rsvp-resource-sharing >>>> and assoc-info (and eventually assoc-ext). >>>> >>>> Francois >>>> >>>> >>>>> >>>>> If you are on the CCAMP WG email list but are not listed as an >>>>> author or >>>>> contributor, we remind you of your obligations under the IETF IPR rules >>>>> which encourages you to notify the IETF if you are aware of IPR of >>>>> others on an IETF contribution, or to refrain from participating in any >>>>> contribution or discussion related to your undisclosed IPR. For more >>>>> information, please see the RFCs listed above and >>>>> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >>>>> >>>>> CCAMP WG Chairs >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > * > Francois Le Faucheur* > *Distinguished Engineer* > *Service Provider Video Technology Group * > flefauch@cisco.com > Phone: *+33 49 723 2619* > Mobile: *+33 6 19 98 50 90* > > > > > *Cisco Systems France* > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com > > > > > > Think before you print. > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply email and delete all copies of this message. > > Cisco Systems France, Soci閠 responsabiit limit閑, Rue Camille > Desmoulins Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les > Moulineaux, Au capital de 91.470 , 349 166 561 RCS Nanterre, Directeur > de la publication: Jean-Luc Michel Givone. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > From lberger@labn.net Tue Feb 21 09:39:09 2012 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 C7B3721F8562 for ; Tue, 21 Feb 2012 09:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.273 X-Spam-Level: X-Spam-Status: No, score=-99.273 tagged_above=-999 required=5 tests=[AWL=0.888, 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 oXh8UYCOTHFR for ; Tue, 21 Feb 2012 09:39:05 -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 D8DB921F8518 for ; Tue, 21 Feb 2012 09:39:00 -0800 (PST) Received: (qmail 26980 invoked by uid 0); 21 Feb 2012 17:39:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 21 Feb 2012 17:39:00 -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=XJmRrCQ+A203awa+i5UihUmsA6o0HCcx/wEDLZS0CsQ=; b=S9xeeWGsysVxZ6ATdU/52w2y+7HIoQfTF+kCVN1SEqBeFgw2NPyD33rVzGFLw7Fgi6Bttj66QolASVahN5TN/kB6+Tw+Vm+wmX4PP7qKsYTB4+KONDQeczhGgHc3oaOj; 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 1Rztg4-00079w-FP; Tue, 21 Feb 2012 10:39:00 -0700 Message-ID: <4F43D6B2.9000501@labn.net> Date: Tue, 21 Feb 2012 12:38: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: sun.weiqiang@gmail.com, zhangguoying@mail.ritt.com.cn, gjhhit@huawei.com, xieg@cs.ucr.edu, rajiv.papneja@huawei.com, BGu@ixiacom.com, xqwei@fiberhome.com.cn, tm-otani@kddi.com, jingrq@ctbri.com.cn 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 , CCAMP ADs Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-dpm 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, 21 Feb 2012 17:39:10 -0000 Authors, Contributors, (CCAMP) In preparation of this document for WG Last Call: Are you aware of any IPR that applies to draft-ietf-ccamp-dpm? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL 9 OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs From zhangfatai@huawei.com Tue Feb 21 10:21:24 2012 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 1C6B721F8850 for ; Tue, 21 Feb 2012 10:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=-4.546, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, 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 EPPZRW3CcRyY for ; Tue, 21 Feb 2012 10:21: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 56AAC21F88BC for ; Tue, 21 Feb 2012 10:21: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 <0LZR00J6V9NDSQ@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 22 Feb 2012 02:21:13 +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 <0LZR005HS9NDVV@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 22 Feb 2012 02:21:13 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH14610; Wed, 22 Feb 2012 02:21:13 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Feb 2012 02:21:07 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.50]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 22 Feb 2012 02:21:10 +0800 Date: Tue, 21 Feb 2012 18:21:09 +0000 From: Zhangfatai In-reply-to: X-Originating-IP: [172.24.1.69] To: Ben Wright , "draft-zhang-ccamp-gmpls-h-lsp-mln@tools.ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8qGrZ9y16yXg0tlqruYNIQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04 Thread-index: AQHM7XH1K0DkYr3FhUKn67b+VondAJZHrEeE X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogQ29tbWVudHMgb24gZHJhZnQtemhhbmctY2Nh?= =?gb2312?b?bXAtZ21wbHMtaC1sc3AtbWxuLTA0?= 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, 21 Feb 2012 18:21:24 -0000 --Boundary_(ID_8qGrZ9y16yXg0tlqruYNIQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbnMgYW5kIGxvb2sgZm9yd2FyZCB0 byBkaXNjdXNzaW5nIG1vcmUgb24gdGhpcyB0b3BpYy4NCg0KU2VlIG1vcmUgaW4tbGluZSBiZWxv dy4NCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCreivP7IyzogQmVuIFdyaWdodCBbQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbV0NCreiy83K sbzkOiAyMDEyxOoy1MIxN8jVIDIwOjQzDQq1vTogWmhhbmdmYXRhaTsgZHJhZnQtemhhbmctY2Nh bXAtZ21wbHMtaC1sc3AtbWxuQHRvb2xzLmlldGYub3JnDQpDYzogY2NhbXBAaWV0Zi5vcmc7IFN0 ZXZlIEJhbGxzDQrW98ziOiBDb21tZW50cyBvbiBkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1oLWxz cC1tbG4tMDQNCg0KSGkgRmF0YWksDQoNClRoYW5rcyBmb3IgcG9pbnRpbmcgbWUgYXQgdGhpcyBk cmFmdC4gICBJIGhhdmUgYSBmZXcgcXVlc3Rpb25zIG9uIHRoaXMuDQoNClRoZSBoaWdoZXN0IGxl dmVsIGNsYXJpZmljYXRpb24gaXMgdGhhdCBJIHdhc26hr3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMg ZGVzaWduZWQgdG8gYWRkcmVzcyBqdXN0IEZBLUxTUHMgKHdoaWNoIGFyZSBhZHZlcnRpc2VkIGJh Y2sgaW50byB0aGUgc2FtZSBjb250cm9sIHBsYW5lIGluc3RhbmNlKSBvciBhbnkgSC1MU1AgKHdo aWNoIG1heSBiZSBhZHZlcnRpc2VkIGludG8gYSBkaWZmZXJlbnQgY29udHJvbCBwbGFuZSAvIHJv dXRpbmcgcHJvdG9jb2wgaW5zdGFuY2UsIGlmIGF0IGFsbCk/ICAgSSB0aGluayB0aGF0IHRoZSBk cmFmdCBhZGRyZXNzZXMgSC1MU1BzLCBpcyB0aGF0IHRydWU/DQoNCltGYXRhaV0gVGhpcyBkcmFm dCBkb2VzIG5vdCB0b3VjaCBob3cgdG8gYWR2ZXJ0aXNlIHRoZSBsaW5rIGZvcm1lZCBieSBILUxT UC4gR2l2ZW4gdGhhdCBILUxTUCBpcyBicm9hZGVyIHRoYW4gRkEtTFNQLCBzbyBJIHdpbGwgYW5z d2VyICJ5ZXMiIHRvIHlvdXIgcXVlc3Rpb24uDQoNClRoZSByZXN0IG9mIG15IGNvbW1lbnRzIGJy ZWFrIGRvd24gaW50byB0d28gYnJvYWQgYXJlYXM6ICBNYW5hZ2VtZW50IG9mIHRoZSBhdXRvbWF0 aWNhbGx5IGNyZWF0ZWQgRkEvSC1MU1BzIGFuZCBleHRlbnNpYmlsaXR5IHRvIGZ1dHVyZSBlbmhh bmNlbWVudHMuDQoNCkZBLUxTUCBNYW5hZ2VtZW50DQoNCkhvdyBkb2VzIGEgbmV0d29yayBhZG1p bmlzdHJhdG9yIG1hbmFnZSB0aGVzZSBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQgRkEtTFNQcz8gICBJ oa9tIGFzc3VtaW5nIHRoYXQgdGhlIHNlcnZlciByZXNvdXJjZSBtYXkgbm90IGFsd2F5cyAodHlw aWNhbGx5PykgYmUgaW4gMToxIGNvcnJlc3BvbmRlbmNlIHdpdGggdGhlIGNsaWVudCByZXNvdXJj ZS4gICBJcyB0aGF0IGNvcnJlY3Q/ICBJZiBzbywgSSB0aGluayB0aGF0IHRoaXMgbWVhbnMgdGhh dCB0aGUgRkEtTFNQIGNhbm5vdCBqdXN0IGJlIG1hbmFnZWQgdmlhIHNpZ25hbGxpbmcgdGhlIGNs aWVudCBsYXllciBMU1AsIGl0IG11c3QgYmUgYWJsZSB0byBiZSBtYW5hZ2VkIGV4cGxpY2l0bHkg YnkgbmV0d29yayBhZG1pbmlzdHJhdG9ycy4gICBTbywgZm9yIGV4YW1wbGUsIEkgc3VzcGVjdCB3 ZaGvbGwgbmVlZCB0byBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIGFsbG93IHRoZSBjbGllbnQgTFNQ IHNpZ25hbGxpbmcgdG8gY2FycnkgYSBzZXQgb2YgaWRlbnRpZmllcnMgdG8gYmUgYXNzb2NpYXRl ZCB3aXRoIHRoZSBzZXJ2ZXIgTFNQLCBzbyBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIGNhbiBtYW5h Z2UgaXQgc2VwYXJhdGVseS4gICBJoa9kIGFsc28gbGlrZSB0byBkZWZpbmUgdGhlIGNvbmRpdGlv bnMgdW5kZXIgd2hpY2ggdGhlIEZBLUxTUCBjYW4gYmUgZGVsZXRlZCAoZS5nLiBzaG91bGQgaXQg YmUgZGVsZXRlZCB3aGVuIHRoZSBjbGllbnQgbGF5ZXIgTFNQIGlzIGRlbGV0ZWQ/KS4NCg0KW0Zh dGFpXSAgWWVzLCBhZ3JlZSB3aXRoIHlvdS4gRkEtTFNQIGNyZWF0aW9uIHRyaWdnZXJlZCBieSB0 aGUgY2xpZW50IGxheWVyIHNob3VsZCBiZSBnb3Zlcm5lZCBieSB0aGUgbmV0d29yayBhZG1pbmlz dHJhdG9ycywgc28gaXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBtb3JlIGluZm9ybWF0aW9uIGlu IHRoZSBzaWduYWxpbmcgZm9yIHRoZSBwdXJwb3NlIG9mIGFkbWluaXN0cmF0aW9uLg0KDQpFeHRl bnNpYmlsaXR5DQoNCkmhr2QgbGlrZSB1cyB0byB1c2UgYSBtb3JlIGV4dGVuc2libGUgZm9ybWF0 IGZvciBlbmNvZGluZyBzZXJ2ZXIgbGF5ZXIgaW5mb3JtYXRpb24uICBJIGNhbiBzZWUgdGhhdCB0 aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQgY291bGQgYmUgYXBwbGljYWJsZSB0 byBhIHdpZGUgdmFyaWV0eSBvZiB1c2UgY2FzZXMgaW4gZnV0dXJlIGFuZCB0aGUgRVJPIHN1Ym9i amVjdCBmb3JtYXQgaXNuoa90IGVhc3kgdG8gZXh0ZW5kIHRvIG1lZXQgdGhlbS4gICBTb21lIGV4 YW1wbGVzIHdoZXJlIHRoZXJlIG1pZ2h0IGJlIGEgcmVxdWlyZW1lbnQgdG8gc2lnbmFsIG1vcmUg aW5mb3JtYXRpb24gYXJlIGJlbG93Lg0KDQoxLiAgSXQgY291bGQgYmUgdXNlZnVsIGZvciB0aGUg Y2xpZW50LWxheWVyIHNpZ25hbGxpbmcgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHBhcmFtZXRlcnMg dGhhdCB0aGUgc2VydmVyIGxheWVyIHNob3VsZCB1c2UgdG8gY3JlYXRlIHRoZSBGQS1MU1AuICAg Rm9yIGV4YW1wbGUsIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGNsaWVudCBsYXllciB0byBi ZSBhYmxlIHRvIHNwZWNpZnkgdGhhdCB0aGUgc2VydmVyIGxheWVyIHNob3VsZCBjcmVhdGUgYW4g RkEtTFNQIHRvIHNoYXJlIHJlc291cmNlcyB3aXRoIGFuIGV4aXN0aW5nIEZBLUxTUC4NCjIuICBU aGUgY2xpZW50LWxheWVyIHNpZ25hbGxpbmcgbWF5IG5lZWQgdG8gYmUgYWJsZSB0byByZXF1ZXN0 IHRoZSBzZXJ2ZXIgbGF5ZXIgY3JlYXRlcyBtdWx0aXBsZSBzZXJ2ZXIgbGF5ZXIgTFNQcyB0byBz dXBwb3J0IHRoZSBjbGllbnQgbGF5ZXIgY29ubmVjdGlvbiAoZS5nLiBpbiBhIFZDQVQgY2FzZSk/ DQoNCltGYXRhaV0gIEFncmVlIHRvIG1ha2luZyB0aGUgZm9ybWF0IG1vcmUgZXh0ZW5zaWJsZS4g SSB3b3VsZCBsaWtlIHRvIGhlYXIgZnJvbSB5b3Ugb24gaG93IHRvIG1ha2UgaXQuDQoNCldoYXQg ZG8geW91IHRoaW5rPw0KDQpDaGVlcnMsDQoNCkJlbiAoYW5kIFN0ZXZlKQ0KDQoNCkZyb206IFpo YW5nZmF0YWkgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQpTZW50OiAwNyBGZWJydWFy eSAyMDEyIDAxOjMwDQpUbzogQmVuIFdyaWdodDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnDQpDYzogY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6 IFJFOiBTaWduYWxpbmcgZXh0ZW5zaW9ucyBmb3IgRkEtTFNQcyAoY29tbWVudCBvbiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDEpDQoNCkhpIEJlbiwNCg0KSSBhZ3Jl ZWQgd2l0aCB0aGUgc2NlbmFyaW8gYW5kIHJlcXVpcmVtZW50IHlvdSBtZW50aW9uZWQuDQoNCkhv d2V2ZXIsIEkgdGhpbmsgaXQgaXMgYSBraW5kIG9mIGdlbmVyaWMgTUxOIHNjZW5hcmlvLCBub3Qg anVzdCBzcGVjaWZpYyB0byBPVE4gc2lnbmFsaW5nLCBzbyBJIHdhcyB0cnlpbmcgdG8gY2FwdHVy ZSB0aGlzIGluIGEgZ2VuZXJpYyB3YXkgYW5kIGRvY3VtZW50ZWQgdGhpcyBpbiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtaC1sc3AtbWxuLTA0LnR4dC4N Cg0KUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IChkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1oLWxz cC1tbG4tMDQudHh0KSB0byBzZWUgaWYgdGhpcyBkcmFmdCBjYW4gYWRkcmVzcyB5b3VyIGNvbmNl cm4uDQoNCkxldKGvcyBkaXNjdXNzIG1vcmUgb24gdGhpcyBpc3N1ZS4NCg0KDQoNClRoYW5rcw0K DQpGYXRhaQ0KDQpGcm9tOiBCZW4gV3JpZ2h0IFttYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNo LmNvbV0NClNlbnQ6IDIwMTLE6jLUwjfI1SAxOjA1DQpUbzogZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmc+DQpDYzogY2NhbXBAaWV0Zi5v cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogU2lnbmFsaW5nIGV4dGVuc2lvbnMg Zm9yIEZBLUxTUHMgKGNvbW1lbnQgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzLTAxKQ0KDQpIaSBGYXRhaSBldCBhbCwNCg0KV2UgaGF2ZSBiZWVuIHRoaW5raW5nIGFi b3V0IGZ1bmN0aW9uIHdlIHdpbGwgbmVlZCB0byBhZGQgdG8gZHJhZnQtaWV0Zi1jY2FtcC1nbXBs cy1zaWduYWxpbmctZzcwOXYzLTAxIHRvIGZ1bGx5IHN1cHBvcnQgYXV0b21hdGljYWxseSBwcm92 aXNpb25lZCBGQS1MU1BzLiAgIEkgd2FudGVkIHRvIHNlZSB3aGV0aGVyIHlvdSBhZ3JlZSB3aXRo IG91ciBhbmFseXNpcy4NCg0KV2UgdGhpbmsgdGhhdCB0aGUgUlNWUC1URSBzaWduYWxsaW5nIHNo b3VsZCBiZSBleHRlbmRlZCB0byBjYXJyeSBtb3JlIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIGFs bG93IG90aGVyIG5vZGVzIG9uIHRoZSBzaWduYWxsaW5nIHBhdGggdG8gc2V0IHVwIHRoZSBjb3Jy ZWN0IEZBLUxTUC4gICAgRm9yIGV4YW1wbGUsIGluIHRoZSBuZXR3b3JrIGluIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0w MSNzZWN0aW9uLTcsIHdlIGJlbGlldmUgdGhhdCBOMSBzaG91bGQgYmUgYWJsZSB0byBwcmVzY3Jp YmUgdG8gTjIgdGhlIHNldCBvZiBob3BzIHRoYXQgaXQgc2hvdWxkIHVzZSB0byBzZXQgdXAgdGhl IE9EVTIgRkEtTFNQLCBhbmQgdGhlIHNpZ25hbCB0eXBlIG9mIHRoZSBGQS1MU1AgaXQgc2hvdWxk IHNldCB1cCwgYW5kIChwcm9iYWJseSkgdGhlIG11bHRpcGxleGluZyBoaWVyYXJjaHkgdG8gYmUg dXNlZCBhdCBlaXRoZXIgZW5kLiAgIFR5cGljYWxseSwgd2Whr2QgZXhwZWN0IE4xIHdvdWxkIHdh bnQgdG8gZXhwbGljaXRseSBwcmV2ZW50IE4yIGZyb20gcXVlcnlpbmcgcm91dGluZyB0byBzZXQg dXAgdGhlIEZBLUxTUCAgqEMgb3RoZXJ3aXNlLCBhIHJvdXRpbmcgY2FsY3VsYXRpb24gdHJpZ2dl cmVkIGJ5IE4yIGNvdWxkIGNvbXB1dGUgYSBwYXRoIGZvciB0aGUgRkEtTFNQIGluY29uc2lzdGVu dCB3aXRoIE4xoa9zIGludGVudGlvbnMgKGUuZy4gd2hpY2ggY291bGQgYnJlYWsgc29tZSBTUkxH IGRpdmVyc2l0eSByZXF1aXJlbWVudCkuDQoNCldoYXQgZG8geW91IHRoaW5rPyAgIElzIHRoaXMg YW4gaXNzdWUgdGhhdCB5b3UgYW50aWNpcGF0ZSBhZGRyZXNzaW5nIGluIHRoZSB0ZXh0IGZvciBz ZWN0aW9uIDcuMSAoYWxsdWRlZCB0byBhcyBiZWluZyBmb3IgZnV0dXJlIHN0dWR5KT8NCg0KVGhh bmtzLA0KDQpCZW4gV3JpZ2h0IGFuZCBTdGV2ZSBCYWxscw0KDQo= --Boundary_(ID_8qGrZ9y16yXg0tlqruYNIQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi Ben,

Thanks for your suggestions and look= forward to discussing more on this topic.

See more in-line below.

Thanks

Fatai


=B7=A2=BC=FE=C8=CB: Ben Wright [Ben.Wright@metaswitch.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA2=D4=C217=C8=D5 20:43
=B5=BD: Zhangfatai; draft-zhang-ccamp-gmpls-h-lsp-mln@tools.ietf.org=
Cc: ccamp@ietf.org; Steve Balls
=D6=F7=CC=E2: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04

Hi Fatai,

 

Thanks for pointing me at this draft. &n= bsp; I have a few questions on this. 

 

The highest level clarification is that I was= n=A1=AFt sure whether this is designed to address just FA-LSPs (which are a= dvertised back into the same control plane instance) or any H-LSP (which ma= y be advertised into a different control plane / routing protocol instance, if at all)?   I think that th= e draft addresses H-LSPs, is that true?


[Fatai] This draft does not touch how to ad= vertise the link formed by H-LSP. Given that H-LSP is broader than FA-LSP, = so I will answer "yes" to your question.

 

The rest of my comments break down into two b= road areas:  Management of the automatically created FA/H-LSPs and ext= ensibility to future enhancements.

 

FA-LSP Management

 

How does a network administrator manage these= automatically created FA-LSPs?   I=A1=AFm assuming that the serv= er resource may not always (typically?) be in 1:1 correspondence with the c= lient resource.   Is that correct?  If so, I think that this means that the FA-LSP cannot just be managed via signalling the = client layer LSP, it must be able to be managed explicitly by network admin= istrators.   So, for example, I suspect we=A1=AFll need to p= rovide a mechanism to allow the client LSP signalling to carry a set of identifiers to be associated with the server LSP, so net= work administrators can manage it separately.   I=A1=AFd also lik= e to define the conditions under which the FA-LSP can be deleted (e.g. shou= ld it be deleted when the client layer LSP is deleted?).   


[Fatai]  Yes, agree with you. FA-LSP creation triggered by t= he client layer should be governed = ;by the network administrators, so it is a good idea to have more information = in the signaling for the purpose of administration.


Extensibility

 

I=A1=AFd like us to use a more extensible for= mat for encoding server layer information.  I can see that the mechani= sm described in the draft could be applicable to a wide variety of use case= s in future and the ERO subobject format isn=A1=AFt easy to extend to meet them.   Some examples where there might b= e a requirement to signal more information are below.

 

1.  It could be useful for the client-la= yer signalling to be able to specify parameters that the server layer shoul= d use to create the FA-LSP.   For example, it would be useful for= the client layer to be able to specify that the server layer should create an FA-LSP to share resources with an existing F= A-LSP. 

2.  The client-layer signalling may need= to be able to request the server layer creates multiple server layer LSPs = to support the client layer connection (e.g. in a VCAT case)? 

 

[Fatai]  Agree to ma= king the format more extensible. I would like to hear from you on how to ma= ke it. 


What do you think?

 

Cheers,

 

Ben (and Steve)

 

 

From: Zhangfatai [mailto:zhangfatai@huawei.com]
Sent: 07 February 2012 01:30
To: Ben Wright; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.o= rg
Cc: ccamp@ietf.org
Subject: RE: Signaling extensions for FA-LSPs (comment on draft-ietf= -ccamp-gmpls-signaling-g709v3-01)

 

Hi Ben,

 

I agreed with the scenario = and requirement you mentioned.

 

However, I think it is a ki= nd of generic MLN scenario, not just specific to OTN signaling, so I was tr= ying to capture this in a generic way and documented this in http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt.

 

Please review this draft (d= raft-zhang-ccamp-gmpls-h-lsp-mln-04.txt) to see if this draft can address y= our concern.

 

Let=A1=AFs discuss more on = this issue.

 

 

 

Thanks
 
Fatai

 

From: Ben Wright [mailto:Ben.Wright@metaswitch.com]
Sent: 2012=C4=EA2=D4=C27=C8=D5 1:05
To: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Cc: ccamp@ietf.o= rg
Subject: Signaling extensions for FA-LSPs (comment on draft-ietf-cca= mp-gmpls-signaling-g709v3-01)

 

Hi Fatai et al,

 

We have been thinking about function we will ne= ed to add to draft-ietf-ccamp-gmpls-signaling-g709v3-01 to fully support au= tomatically provisioned FA-LSPs.   I wanted to see whether you ag= ree with our analysis. 

 

We think that the RSVP-TE signalling should be = extended to carry more information in order to allow other nodes on the sig= nalling path to set up the correct FA-LSP.    For example, i= n the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmp= ls-signaling-g709v3-01#section-7, we believe that N1 should be a= ble to prescribe to N2 the set of hops that it should use to set up the ODU= 2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be u= sed at either end.   Typically, we=A1=AFd expect N1 would want to= explicitly prevent N2 from querying routing to set up the FA-LSP  =A8= C otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1=A1=AFs intentions (e.g.= which could break some SRLG diversity requirement).    &nbs= p; 

 

What do you think?   Is this an issue= that you anticipate addressing in the text for section 7.1 (alluded to as = being for future study)?   

 

Thanks,

 

Ben Wright and Steve Balls

 

--Boundary_(ID_8qGrZ9y16yXg0tlqruYNIQ)-- From sun.weiqiang@gmail.com Tue Feb 21 16:42:35 2012 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 D90B121E804C for ; Tue, 21 Feb 2012 16:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.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 vpcs8TV5xnZR for ; Tue, 21 Feb 2012 16:42:33 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B952421E801E for ; Tue, 21 Feb 2012 16:42:33 -0800 (PST) Received: by obbwd15 with SMTP id wd15so10692334obb.31 for ; Tue, 21 Feb 2012 16:42:33 -0800 (PST) Received-SPF: pass (google.com: domain of sun.weiqiang@gmail.com designates 10.50.178.8 as permitted sender) client-ip=10.50.178.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sun.weiqiang@gmail.com designates 10.50.178.8 as permitted sender) smtp.mail=sun.weiqiang@gmail.com; dkim=pass header.i=sun.weiqiang@gmail.com Received: from mr.google.com ([10.50.178.8]) by 10.50.178.8 with SMTP id cu8mr23457363igc.12.1329871353152 (num_hops = 1); Tue, 21 Feb 2012 16:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=2WTN9OKBx4G939I38EDZqk5pBc3JfEWh5DyvzLyWn8Q=; b=EMeBWp/sfs60oPO1BT+qMKFUgqQJvwxSvUGxzLvuohmImBWUIlGAOtSWiBDHzGVhR4 SZZhccJMcgSC29v4btwU8tAV9QXsvx6+sBDFuZEHp56PG7UYJc8UauvzLElm77v0aeGL 5k0/3gsc41l+JwQyRZZmKExIu7A47p5ztpDs4= Received: by 10.50.178.8 with SMTP id cu8mr18944440igc.12.1329871353111; Tue, 21 Feb 2012 16:42:33 -0800 (PST) Received: from [192.168.6.63] ([202.120.39.240]) by mx.google.com with ESMTPS id df2sm11765536igb.0.2012.02.21.16.42.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 16:42:31 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 22 Feb 2012 08:42:15 +0800 From: Weiqiang Sun To: Lou Berger , =?GB2312?B?1cW5+tOx?= , , , , , , , Message-ID: Thread-Topic: Regarding IPR on draft-ietf-ccamp-dpm In-Reply-To: <4F43D6B2.9000501@labn.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: CCAMP , CCAMP ADs Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-dpm 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, 22 Feb 2012 00:42:35 -0000 Hi, I'm not aware of any IPR that applies to this draft. Thanks, Weiqiang (co-author) On 2/22/12 1:38 AM, "Lou Berger" wrote: >Authors, Contributors, (CCAMP) > >In preparation of this document for WG Last Call: > >Are you aware of any IPR that applies to draft-ietf-ccamp-dpm? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details)? > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL 9 OF YOU LISTED IN THIS >MESSAGE'S TO LINES. > >If you are on the CCAMP WG email list but are not listed as an author or >contributor, we remind you of your obligations under the IETF IPR rules >which encourages you to notify the IETF if you are aware of IPR of >others on an IETF contribution, or to refrain from participating in any >contribution or discussion related to your undisclosed IPR. For more >information, please see the RFCs listed above and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >CCAMP WG Chairs > From ashokn@cisco.com Wed Feb 22 08:19:11 2012 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 944B821F87D0 for ; Wed, 22 Feb 2012 08:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 lQCmQEJBU0jp for ; Wed, 22 Feb 2012 08:19:07 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4682121F8725 for ; Wed, 22 Feb 2012 08:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ashokn@cisco.com; l=1595; q=dns/txt; s=iport; t=1329927547; x=1331137147; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GezkxdC1DMyyn4tbDi2Wr4aoGsrDE77q8M9xH2gkP14=; b=ImPPI9mbOfQpAuCqplWiWEkseEexnvqkliWy1Fl87iXnNM3XrDHESMMS 6aQs09kTS6Z4N2mqaGi5j97RFd2mBZ4fvZTgIZDKUvvc1YVihCzVvseYW jFTbWX+Msu7UjbQC1nJn8FnrG4fBEy41GVcId+KYFbWPM+YGauee97Lyf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANEURU+rRDoH/2dsb2JhbABEskOBB4FzAQEBAwEBAQEPASc0BgUFCwtGJzAGEyKHXwmfbwGXIIxXAQEBCQkFEggLAw8NAgcQAQwFAwKFFwozDwsOBIJZYwSIT4xpkwuBPg X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="31664226" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 22 Feb 2012 16:19:07 +0000 Received: from dhcp-161-44-183-67.cisco.com (dhcp-161-44-183-67.cisco.com [161.44.183.67]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1MGJ6KW014763; Wed, 22 Feb 2012 16:19:06 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Ashok Narayanan In-Reply-To: Date: Wed, 22 Feb 2012 11:19:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6DF47506-B41C-4D8F-8976-845EC96424C9@cisco.com> References: To: "BRUNGARD, DEBORAH A" X-Mailer: Apple Mail (2.1257) Cc: "ccamp@ietf.org" , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-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: Wed, 22 Feb 2012 16:19:11 -0000 Hi Deborah, Confirming that Cisco does have IPR associated with this draft and it = has already been disclosed as per the appropriate IETF procedures. This = is already detailed in https://datatracker.ietf.org/ipr/1169/ Thanks -Ashok On Feb 17, 2012, at 2/17 4:52 PM, BRUNGARD, DEBORAH A wrote: > CCAMP, >=20 > In preparation of this document for WG Last Call: >=20 > Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-ext? = If > so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If you are listed as a document author or contributor please answer = the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. >=20 > If you are on the CCAMP WG email list but are not listed as an author = or > contributor, we remind you of your obligations under the IETF IPR = rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in = any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > CCAMP WG Chairs >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From prvs=7400a6d220=lyong@ciena.com Thu Feb 23 08:13:29 2012 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 B92E221F883D for ; Thu, 23 Feb 2012 08:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-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 ZbnWvgBQMRIl for ; Thu, 23 Feb 2012 08:13:28 -0800 (PST) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 073BA21F8839 for ; Thu, 23 Feb 2012 08:13:27 -0800 (PST) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q1NGB2VL020760; Thu, 23 Feb 2012 11:13:26 -0500 Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 135pvfgdck-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Feb 2012 11:13:25 -0500 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Thu, 23 Feb 2012 11:13:25 -0500 From: "Ong, Lyndon" To: CCAMP Date: Thu, 23 Feb 2012 11:13:24 -0500 Thread-Topic: question on rerouting with reversion Thread-Index: Aczxfsl5Tq96ss2FSCyMLeBHby5KiAAxyWGQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18730.000 x-tm-as-result: No--47.027300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_A0B4FC0A5EFBD44585414760DB4FD27441835512MDWEXGMB02ciena_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-02-23_06:2012-02-23, 2012-02-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1202230131 Subject: [CCAMP] question on rerouting with reversion 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, 23 Feb 2012 16:13:29 -0000 --_000_A0B4FC0A5EFBD44585414760DB4FD27441835512MDWEXGMB02ciena_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, We would like to be able to support of a version of rerouting that has the= following characteristics: - First the original LSP is established on demand. - Secondly failure of the original LSP causes an alternate LSP to = be created without any prior reservation of backup resources, potentially s= haring some resources - Finally, traffic reverts to the original LSP path once the failu= re is repaired. We wanted to get the benefit of CCAMP's expertise and knowledge as to wheth= er this combination of reversion and rerouting is supported in the existing= recovery specifications or not. We have taken a read through some of the = specifications and haven't found an exact fit yet. In our reading of RFC4872, section 11, full LSP rerouting (protection type = 0x01) involves tearing down the original LSP, although it says make-before-= break can be used to establish the alternate LSP before tearing down the or= iginal, so that some of the resources can be reused. Rerouting without extra traffic (protection type 0x02) involves pre-establi= shment of the alternate LSP using a disjoint path, with no sharing of resou= rces. We also found that section 12 on reversion describes how reversion is suppo= rted for 1+1 bidirectional protection, 1:n protection with extra traffic, a= nd rerouting without extra traffic, but has no description for reversion fo= r the full LSP rerouting case. Is there a procedure that would support the kind of rerouting with reversio= n above that we may have missed or does a procedure might need to be added = to the specifications for this? We are preparing a draft that would identi= fy the functionality and requirements and it would help us to get your inpu= t on whether you think this is already supported or will need extensions to= the specifications (or if you see potential problems supporting something = like this). Thanks for your help! Best regards, Lyndon Ong Evelyne Roch --_000_A0B4FC0A5EFBD44585414760DB4FD27441835512MDWEXGMB02ciena_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,

 

We would like to be able to  support of a ver= sion of rerouting that has the following characteristics:=

-  = ;        = First the original LSP is established on dema= nd.

-          = Secondly failure of the orig= inal LSP causes an alternate LSP to be created without any prior reservatio= n of backup resources, potentially sharing some resources

-         = ; Finally, tra= ffic reverts to the original LSP path once the failure is repaired.

We wanted = to get the benefit of CCAMP’s expertise and knowledge as to whether t= his combination of reversion and rerouting is supported in the existing rec= overy specifications or not.  We have taken a read through some of the= specifications and haven’t found an exact fit yet.=

 

In our reading o= f RFC4872, section 11, full LSP rerouting (protection type 0x01) involves t= earing down the original LSP, although it says make-before-break can be use= d to establish the alternate LSP before tearing down the original, so that = some of the resources can be reused. 

 

Rerouting without extra traf= fic (protection type 0x02) involves pre-establishment of the alternate LSP = using a disjoint path, with no sharing of resources.

<= p class=3DMsoNormal> <= /p>

We also found that se= ction 12 on reversion describes how reversion is supported for 1+1 bidirect= ional protection, 1:n protection with extra traffic, and rerouting without = extra traffic, but has no description for reversion for the full LSP rerout= ing case. 

 

Is there a procedure that would support the kind of rero= uting with reversion above that we may have missed or does a procedure migh= t need to be added to the specifications for this?  We are preparing a= draft that would identify the functionality and requirements and it would = help us to get your input on whether you think this is already supported or= will need extensions to the specifications (or if you see potential proble= ms supporting something like this).

 

Thanks for your help!

 

Best regards,

 

= Lyndon Ong

Evelyne Roch

 <= /o:p>

= --_000_A0B4FC0A5EFBD44585414760DB4FD27441835512MDWEXGMB02ciena_-- From db3546@att.com Thu Feb 23 08:22:02 2012 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 B513221F8712 for ; Thu, 23 Feb 2012 08:22:01 -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 WBSy8-RTEQ3W for ; Thu, 23 Feb 2012 08:22:01 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4F21F85BB for ; Thu, 23 Feb 2012 08:21:56 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-16.tower-119.messagelabs.com!1330014115!17067668!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24935 invoked from network); 23 Feb 2012 16:21:56 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-16.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2012 16:21:56 -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 q1NGMQj9026250; Thu, 23 Feb 2012 11:22:26 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1NGMN2w026212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 11:22:23 -0500 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 23 Feb 2012 11:21:39 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.184]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 11:21:39 -0500 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" , Lou Berger Thread-Topic: Regarding IPR on draft-ietf-ccamp-assoc-info Thread-Index: AczyRzxScK9NFkxDTcKnuYA9LzX6Ww== Date: Thu, 23 Feb 2012 16:21:39 +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 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "ccamp-ads@tools.ietf.org" Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-info 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, 23 Feb 2012 16:22:02 -0000 Author, CCAMP, In preparation of this document for publication: Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-info? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are the listed author please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from the author. If you are on the CCAMP WG email list but are not listed as an author, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs From lberger@labn.net Thu Feb 23 08:24:35 2012 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 F085921F8559 for ; Thu, 23 Feb 2012 08:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.36 X-Spam-Level: X-Spam-Status: No, score=-99.36 tagged_above=-999 required=5 tests=[AWL=0.801, 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 VNsWWtFHO1Rd for ; Thu, 23 Feb 2012 08:24:34 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 2789F21F84DD for ; Thu, 23 Feb 2012 08:24:33 -0800 (PST) Received: (qmail 17613 invoked by uid 0); 23 Feb 2012 16:24:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 23 Feb 2012 16:24:32 -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=Ot9Mj49Xa+0Xg/r2x3GT94X9TgruTqGuvPSUU5zjkyw=; b=LjMKVSV9Fb7s6hYeewx8Zp3cw1rXenQETCbdQ0dBmHkyf3v+3pX5frMLKMpFHFSh4Jc7oONo0O7xTO0vzqf1bWZ36wPDaT3P0OXxczxQF7bcTePrL7AlSHkECAazbxX+; 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 1S0bT6-0000p8-N7; Thu, 23 Feb 2012 09:24:32 -0700 Message-ID: <4F466842.80004@labn.net> Date: Thu, 23 Feb 2012 11:24: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: "BRUNGARD, DEBORAH A" 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@ietf.org" , "ccamp-ads@tools.ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-assoc-info 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, 23 Feb 2012 16:24:35 -0000 Hello, I'm not aware of any IPR that applies to this draft. Lou (author of draft in question) On 2/23/2012 11:21 AM, BRUNGARD, DEBORAH A wrote: > Author, CCAMP, > > In preparation of this document for publication: > > Are you aware of any IPR that applies to draft-ietf-ccamp-assoc-info? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If you are the listed author please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from the author. > > If you are on the CCAMP WG email list but are not listed as an author, > we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > > > > > From lberger@labn.net Thu Feb 23 09:47:03 2012 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 DA4BF21F872B for ; Thu, 23 Feb 2012 09:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.379 X-Spam-Level: X-Spam-Status: No, score=-99.379 tagged_above=-999 required=5 tests=[AWL=0.782, 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 PQq8n+bDkAcQ for ; Thu, 23 Feb 2012 09:47:03 -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 1CD7521F8723 for ; Thu, 23 Feb 2012 09:47:03 -0800 (PST) Received: (qmail 24093 invoked by uid 0); 23 Feb 2012 17:47:02 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 23 Feb 2012 17:47:02 -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=OlJ22EU6n5kQhdR0evkWq0FkMo5EYlCbXv2XiHLBo2E=; b=v5zH0fg4UozOyFGZsM/N1Ca9M617SuxXFCQ9jYmH1+6k2/vkOVWVKCOYNdv4bD1kNxl7ga+Dwd9BkSUM+rwsKuAvuiWH/p/DJft0gONmm+JDt11XbWaAeu6PtmwB7Ipb; 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 1S0ckw-0007I7-01; Thu, 23 Feb 2012 10:47:02 -0700 Message-ID: <4F467B98.7070901@labn.net> Date: Thu, 23 Feb 2012 12:47:04 -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: "Ong, Lyndon" 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] question on rerouting with reversion 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, 23 Feb 2012 17:47:04 -0000 Hi Lyndon, See below. On 2/23/2012 11:13 AM, Ong, Lyndon wrote: > Hi Folks, > > > > We would like to be able to support of a version of rerouting that has > the following characteristics: > > - First the original LSP is established on demand. > > - Secondly failure of the original LSP causes an alternate LSP > to be created without any prior reservation of backup resources, > potentially sharing some resources > > - Finally, traffic reverts to the original LSP path once the > failure is repaired. > I see nothing that precludes this in the current specs. (I believe someone mentioned to me that they support exactly this behavior.) As described, this is largely handled at an application level above signaling. > We wanted to get the benefit of CCAMP抯 expertise and knowledge as to > whether this combination of reversion and rerouting is supported in the > existing recovery specifications or not. We have taken a read through > some of the specifications and haven抰 found an exact fit yet. > > > > In our reading of RFC4872, section 11, full LSP rerouting (protection > type 0x01) involves tearing down the original LSP, although it says > make-before-break can be used to establish the alternate LSP before > tearing down the original, so that some of the resources can be reused. > As you note, the make-before-break is listed as an informative option. Furthermore, the text does no include any required behavior on the alternate LSP. I can't speak for the authors, but I can see why they didn't include required behavior as there is no interoperability issues with several of the different approaches. That said, I think documenting the options, with or without a recommended approach, could be valuable to some. > > > Rerouting without extra traffic (protection type 0x02) involves > pre-establishment of the alternate LSP using a disjoint path, with no > sharing of resources. > > > > We also found that section 12 on reversion describes how reversion is > supported for 1+1 bidirectional protection, 1:n protection with extra > traffic, and rerouting without extra traffic, but has no description for > reversion for the full LSP rerouting case. > Again, I can't speak for the authors, but my guess is that they made a choice to not put requirements on the LSP Rerouting case. If we were to add such constraints, I suspect the change is little more than (in Section 12): s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ > > > Is there a procedure that would support the kind of rerouting with > reversion above that we may have missed The only think you have missed is the perspective that most of the (G)MPLS specs provide tools for a toolbox, and it is often up to the implementer to choose how to implement a particular solution. As I mentioned above, I believe that an implementation can use existing specs to implement this solution. > or does a procedure might need > to be added to the specifications for this? This is a question of perspectives, if you just want everyone to interoperate -- this can be supported today. On the other hand, if your objective is for all to implement this function in the same way, then more specification is needed. To me it seems the authors of 4872 desired the former while you want the latter. > We are preparing a draft > that would identify the functionality and requirements and it would help > us to get your input on whether you think this is already supported or > will need extensions to the specifications (or if you see potential > problems supporting something like this). Well it seems to me (as a WG participant) that there may be room for an informative or, at most, a BCP document, but unless I'm missing something, don't think there's any new protocol mechanisms to define. Obviously, specific comments on your draft will need to wait for it to be published. Lou > > > > Thanks for your help! > > > > Best regards, > > > > Lyndon Ong > > Evelyne Roch > > > From francesco.fondelli@gmail.com Thu Feb 23 10:03:51 2012 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 7195421F853A for ; Thu, 23 Feb 2012 10:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 QGZthD6PMPdH for ; Thu, 23 Feb 2012 10:03:50 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81DE521F87EE for ; Thu, 23 Feb 2012 10:03:50 -0800 (PST) Received: by yhkk25 with SMTP id k25so841607yhk.31 for ; Thu, 23 Feb 2012 10:03:50 -0800 (PST) Received-SPF: pass (google.com: domain of francesco.fondelli@gmail.com designates 10.236.156.34 as permitted sender) client-ip=10.236.156.34; Authentication-Results: mr.google.com; spf=pass (google.com: domain of francesco.fondelli@gmail.com designates 10.236.156.34 as permitted sender) smtp.mail=francesco.fondelli@gmail.com; dkim=pass header.i=francesco.fondelli@gmail.com Received: from mr.google.com ([10.236.156.34]) by 10.236.156.34 with SMTP id l22mr4660727yhk.118.1330020230225 (num_hops = 1); Thu, 23 Feb 2012 10:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IGqmwz1byVnZ527PQPVHrFrFtB0pK7pyJRDOAgS3XaE=; b=Qo+XeIl0CidVa34chFhHcRaRftzFCTmzbL6VTn1AHKHvG2SlO/Sl79EdSKFCNpDrXK Xrm+ET09nDvYMbAzrEvuf02VJju+55Tkw0KdUKf2hJIP6IUf21Y88tzVvFiNFkjMO9oh 8gLplYN+jI/IXBw5f/NwWerzAguSZrZxM4o24= MIME-Version: 1.0 Received: by 10.236.156.34 with SMTP id l22mr3776648yhk.118.1330020230066; Thu, 23 Feb 2012 10:03:50 -0800 (PST) Received: by 10.236.37.228 with HTTP; Thu, 23 Feb 2012 10:03:50 -0800 (PST) In-Reply-To: <4F467B98.7070901@labn.net> References: <4F467B98.7070901@labn.net> Date: Thu, 23 Feb 2012 19:03:50 +0100 Message-ID: From: Francesco Fondelli To: Lou Berger Content-Type: text/plain; charset=UTF-8 Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 23 Feb 2012 18:03:51 -0000 +1 Just a side note: I think the term "reversion" applies only to protection (RFC 4427, section 4.11). "Revertive-ness" in this case can be signaled with draft-takacs-ccamp-revertive-ps-06. In case of restoration is... hmmm "I wanna get back to the orig path as soon as it is in good shape" :-). Anyway, as Lou said, I think is a (one of the possible) local policy. hope this helps ciao FF On Thu, Feb 23, 2012 at 6:47 PM, Lou Berger wrote: > Hi Lyndon, > > See below. > > On 2/23/2012 11:13 AM, Ong, Lyndon wrote: >> Hi Folks, >> >> >> >> We would like to be able to ?support of a version of rerouting that has >> the following characteristics: >> >> - ? ? ? ? ?First the original LSP is established on demand. >> >> - ? ? ? ? ?Secondly failure of the original LSP causes an alternate LSP >> to be created without any prior reservation of backup resources, >> potentially sharing some resources >> >> - ? ? ? ? ?Finally, traffic reverts to the original LSP path once the >> failure is repaired. >> > > I see nothing that precludes this in the current specs. ?(I believe > someone mentioned to me that they support exactly this behavior.) As > described, this is largely handled at an application level above signaling. > >> We wanted to get the benefit of CCAMP?s expertise and knowledge as to >> whether this combination of reversion and rerouting is supported in the >> existing recovery specifications or not. ?We have taken a read through >> some of the specifications and haven?t found an exact fit yet. >> >> >> >> In our reading of RFC4872, section 11, full LSP rerouting (protection >> type 0x01) involves tearing down the original LSP, although it says >> make-before-break can be used to establish the alternate LSP before >> tearing down the original, so that some of the resources can be reused. >> > > As you note, the make-before-break is listed as an informative option. > Furthermore, the text does no include any required behavior on the > alternate LSP. I can't speak for the authors, but I can see why they > didn't include required behavior as there is no interoperability issues > with several of the different approaches. > > That said, I think documenting the options, with or without a > recommended approach, could be valuable to some. > >> >> >> Rerouting without extra traffic (protection type 0x02) involves >> pre-establishment of the alternate LSP using a disjoint path, with no >> sharing of resources. >> >> >> >> We also found that section 12 on reversion describes how reversion is >> supported for 1+1 bidirectional protection, 1:n protection with extra >> traffic, and rerouting without extra traffic, but has no description for >> reversion for the full LSP rerouting case. >> > > Again, I can't speak for the authors, but my guess is that they made a > choice to not put requirements on the LSP Rerouting case. > > If we were to add such constraints, I suspect the change is little more > than (in Section 12): > ? ? ? ?s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ > >> >> >> Is there a procedure that would support the kind of rerouting with >> reversion above that we may have missed > > The only think you have missed is the perspective that most of the > (G)MPLS specs provide tools for a toolbox, and it is often up to the > implementer to choose how to implement a particular solution. > > As I mentioned above, I believe that an implementation can use existing > specs to implement this solution. > >> or does a procedure might need >> to be added to the specifications for this? > > This is a question of perspectives, if you just want everyone to > interoperate -- this can be supported today. ?On the other hand, if your > objective is for all to implement this function in the same way, then > more specification is needed. ?To me it seems the authors of 4872 > desired the former while you want the latter. > >> We are preparing a draft >> that would identify the functionality and requirements and it would help >> us to get your input on whether you think this is already supported or >> will need extensions to the specifications (or if you see potential >> problems supporting something like this). > > Well it seems to me (as a WG participant) that there may be room for an > informative or, at most, a BCP document, but unless I'm missing > something, don't think there's any new protocol mechanisms to define. > > Obviously, specific comments on your draft will need to wait for it to > be published. > > Lou > >> >> >> >> Thanks for your help! >> >> >> >> Best regards, >> >> >> >> Lyndon Ong >> >> Evelyne Roch >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From IBryskin@advaoptical.com Thu Feb 23 10:37:13 2012 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 7C69821F884F for ; Thu, 23 Feb 2012 10:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 Bb-fK9K9pO86 for ; Thu, 23 Feb 2012 10:37:12 -0800 (PST) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 229A221F884E for ; Thu, 23 Feb 2012 10:37:11 -0800 (PST) Received: from MUC-SRV-MAIL10.advaoptical.com (muc-srv-mail10.advaoptical.com [172.20.1.59]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id q1NIb0qi018904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Feb 2012 19:37:00 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 23 Feb 2012 19:37:00 +0100 Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 13:36:57 -0500 From: Igor Bryskin To: Lou Berger , "Ong, Lyndon" Thread-Topic: [CCAMP] question on rerouting with reversion Thread-Index: Aczxfsl5Tq96ss2FSCyMLeBHby5KiAAxyWGQAA3IQAAACPJFkA== Date: Thu, 23 Feb 2012 18:36:56 +0000 Message-ID: References: <4F467B98.7070901@labn.net> In-Reply-To: <4F467B98.7070901@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.1.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-02-23_07:2012-02-23, 2012-02-23, 1970-01-01 signatures=0 Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 23 Feb 2012 18:37:13 -0000 Lou. This someone was me. :=3D) We call it dynamic restoration with reversion. = When the second LSP is created, it is done via make-without-break procedur= e. Once the failure is repaired the second LSP is removed. Cheers, Igor -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Thursday, February 23, 2012 12:47 PM To: Ong, Lyndon Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion Hi Lyndon, See below. On 2/23/2012 11:13 AM, Ong, Lyndon wrote: > Hi Folks, >=20 > =20 >=20 > We would like to be able to support of a version of rerouting that=20 > has the following characteristics: >=20 > - First the original LSP is established on demand. >=20 > - Secondly failure of the original LSP causes an alternate LSP > to be created without any prior reservation of backup resources,=20 > potentially sharing some resources >=20 > - Finally, traffic reverts to the original LSP path once the > failure is repaired. >=20 I see nothing that precludes this in the current specs. (I believe someone= mentioned to me that they support exactly this behavior.) As described, th= is is largely handled at an application level above signaling. > We wanted to get the benefit of CCAMP's expertise and knowledge as to=20 > whether this combination of reversion and rerouting is supported in=20 > the existing recovery specifications or not. We have taken a read=20 > through some of the specifications and haven't found an exact fit yet. >=20 > =20 >=20 > In our reading of RFC4872, section 11, full LSP rerouting (protection=20 > type 0x01) involves tearing down the original LSP, although it says=20 > make-before-break can be used to establish the alternate LSP before=20 > tearing down the original, so that some of the resources can be reused. >=20 As you note, the make-before-break is listed as an informative option. Furthermore, the text does no include any required behavior on the alternat= e LSP. I can't speak for the authors, but I can see why they didn't include= required behavior as there is no interoperability issues with several of t= he different approaches. That said, I think documenting the options, with or without a recommended a= pproach, could be valuable to some. > =20 >=20 > Rerouting without extra traffic (protection type 0x02) involves=20 > pre-establishment of the alternate LSP using a disjoint path, with no=20 > sharing of resources. >=20 > =20 >=20 > We also found that section 12 on reversion describes how reversion is=20 > supported for 1+1 bidirectional protection, 1:n protection with extra=20 > traffic, and rerouting without extra traffic, but has no description=20 > for reversion for the full LSP rerouting case. >=20 Again, I can't speak for the authors, but my guess is that they made a choi= ce to not put requirements on the LSP Rerouting case. If we were to add such constraints, I suspect the change is little more tha= n (in Section 12): s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ > =20 >=20 > Is there a procedure that would support the kind of rerouting with=20 > reversion above that we may have missed The only think you have missed is the perspective that most of the (G)MPLS = specs provide tools for a toolbox, and it is often up to the implementer to= choose how to implement a particular solution. As I mentioned above, I believe that an implementation can use existing spe= cs to implement this solution. > or does a procedure might need > to be added to the specifications for this? =20 This is a question of perspectives, if you just want everyone to interopera= te -- this can be supported today. On the other hand, if your objective is= for all to implement this function in the same way, then more specificatio= n is needed. To me it seems the authors of 4872 desired the former while y= ou want the latter. > We are preparing a draft > that would identify the functionality and requirements and it would=20 > help us to get your input on whether you think this is already=20 > supported or will need extensions to the specifications (or if you see=20 > potential problems supporting something like this). Well it seems to me (as a WG participant) that there may be room for an inf= ormative or, at most, a BCP document, but unless I'm missing something, don= 't think there's any new protocol mechanisms to define. Obviously, specific comments on your draft will need to wait for it to be p= ublished. Lou >=20 > =20 >=20 > Thanks for your help! >=20 > =20 >=20 > Best regards, >=20 > =20 >=20 > Lyndon Ong >=20 > Evelyne Roch >=20 > =20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Thu Feb 23 13:39:08 2012 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 4EC3121F88B8 for ; Thu, 23 Feb 2012 13:39:08 -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=[AWL=0.000, 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 ta+K2r-eSCXD for ; Thu, 23 Feb 2012 13:39:07 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0D721F88B7 for ; Thu, 23 Feb 2012 13:39:06 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1330033145!65062239!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9056 invoked from network); 23 Feb 2012 21:39:06 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2012 21:39:06 -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 q1NLdWOL000895; Thu, 23 Feb 2012 16:39:35 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1NLdOkQ000632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2012 16:39:25 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 23 Feb 2012 16:38:39 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.184]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 16:38:39 -0500 From: "BRUNGARD, DEBORAH A" To: Lou Berger , "Ong, Lyndon" Thread-Topic: question on rerouting with reversion Thread-Index: Aczxfsl5Tq96ss2FSCyMLeBHby5KiAAxyWGQAA3IQAAAA8KEUA== Date: Thu, 23 Feb 2012 21:38:38 +0000 Message-ID: References: <4F467B98.7070901@labn.net> In-Reply-To: <4F467B98.7070901@labn.net> 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 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 23 Feb 2012 21:39:08 -0000 Hi Lyndon, (Chair hat off/co-author hat on) I don't think there was any intentional preclusion of reversion support for= LSP rerouting. As described in RFC4428, reversion was considered a generic= operation, one of the recovery phrases for use with any of the recovery me= chanisms (depending on recovery domain policy). The same treatment was done= for RFC4872, keeping it as a separate section. The sequence may not have b= een detailed in Section 12 (probably due to author interest), but there is = nothing precluding use with LSP rerouting. And as described in Section 11 o= n LSP rerouting, there is no (RFC2119) requirement that the old LSP must be= torn down. If you want to use full LSP rerouting, you may want to look at RFC3209 on S= E, as it describes in Section 2.5 rerouting with reversion as this is the r= eference for this recovery mechanism. So it is supported. Alternatively, th= e Resource Sharing Association Type defined in RFC4783 can be used (which c= an be viewed as running segment recovery where the segment end-points are a= ligned with LSP end-points). And, if you want to do pre-plan for these options, it's not precluded (refe= r to RFC4872 section 11.1). As Lou suggests, you could clarify by doing an errata. If need more clarifi= cation, an informational. Regards, Deborah -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, February 23, 2012 12:47 PM To: Ong, Lyndon Cc: CCAMP; BRUNGARD, DEBORAH A Subject: Re: question on rerouting with reversion Hi Lyndon, See below. On 2/23/2012 11:13 AM, Ong, Lyndon wrote: > Hi Folks, >=20 > =20 >=20 > We would like to be able to support of a version of rerouting that has > the following characteristics: >=20 > - First the original LSP is established on demand. >=20 > - Secondly failure of the original LSP causes an alternate LSP > to be created without any prior reservation of backup resources, > potentially sharing some resources >=20 > - Finally, traffic reverts to the original LSP path once the > failure is repaired. >=20 I see nothing that precludes this in the current specs. (I believe someone mentioned to me that they support exactly this behavior.) As described, this is largely handled at an application level above signaling. > We wanted to get the benefit of CCAMP's expertise and knowledge as to > whether this combination of reversion and rerouting is supported in the > existing recovery specifications or not. We have taken a read through > some of the specifications and haven't found an exact fit yet. >=20 > =20 >=20 > In our reading of RFC4872, section 11, full LSP rerouting (protection > type 0x01) involves tearing down the original LSP, although it says > make-before-break can be used to establish the alternate LSP before > tearing down the original, so that some of the resources can be reused.=20 >=20 As you note, the make-before-break is listed as an informative option. Furthermore, the text does no include any required behavior on the alternate LSP. I can't speak for the authors, but I can see why they didn't include required behavior as there is no interoperability issues with several of the different approaches. That said, I think documenting the options, with or without a recommended approach, could be valuable to some. > =20 >=20 > Rerouting without extra traffic (protection type 0x02) involves > pre-establishment of the alternate LSP using a disjoint path, with no > sharing of resources. >=20 > =20 >=20 > We also found that section 12 on reversion describes how reversion is > supported for 1+1 bidirectional protection, 1:n protection with extra > traffic, and rerouting without extra traffic, but has no description for > reversion for the full LSP rerouting case.=20 >=20 Again, I can't speak for the authors, but my guess is that they made a choice to not put requirements on the LSP Rerouting case. If we were to add such constraints, I suspect the change is little more than (in Section 12): s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ > =20 >=20 > Is there a procedure that would support the kind of rerouting with > reversion above that we may have missed=20 The only think you have missed is the perspective that most of the (G)MPLS specs provide tools for a toolbox, and it is often up to the implementer to choose how to implement a particular solution. As I mentioned above, I believe that an implementation can use existing specs to implement this solution. > or does a procedure might need > to be added to the specifications for this? =20 This is a question of perspectives, if you just want everyone to interoperate -- this can be supported today. On the other hand, if your objective is for all to implement this function in the same way, then more specification is needed. To me it seems the authors of 4872 desired the former while you want the latter. > We are preparing a draft > that would identify the functionality and requirements and it would help > us to get your input on whether you think this is already supported or > will need extensions to the specifications (or if you see potential > problems supporting something like this). Well it seems to me (as a WG participant) that there may be room for an informative or, at most, a BCP document, but unless I'm missing something, don't think there's any new protocol mechanisms to define. Obviously, specific comments on your draft will need to wait for it to be published. Lou >=20 > =20 >=20 > Thanks for your help! >=20 > =20 >=20 > Best regards, >=20 > =20 >=20 > Lyndon Ong >=20 > Evelyne Roch >=20 > =20 >=20 From db3546@att.com Thu Feb 23 14:13:03 2012 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 B235321F87AB for ; Thu, 23 Feb 2012 14:13:03 -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 bTA780HzohQ1 for ; Thu, 23 Feb 2012 14:13:03 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0050721F87A8 for ; Thu, 23 Feb 2012 14:13:02 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1330035181!51044979!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6721 invoked from network); 23 Feb 2012 22:13:02 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2012 22:13:02 -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 q1NMDWTs011352 for ; Thu, 23 Feb 2012 17:13:32 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1NMDTo5011327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 17:13:29 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 23 Feb 2012 17:12:45 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.184]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 17:12:45 -0500 From: "BRUNGARD, DEBORAH A" To: CCAMP Thread-Topic: WG Last Call on draft-ietf-ccamp-assoc-ext Thread-Index: AczyeEPhMS9tcSPVQriB9T4Q9H/mpg== Date: Thu, 23 Feb 2012 22:12:44 +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 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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: Thu, 23 Feb 2012 22:13:03 -0000 All, This starts a two-week working group last call on draft-ietf-ccamp-assoc-ex= t. This working group last call ends March 8th. Please send your comments to t= he CCAMP mailing list. Deborah (and Lou) From zhang.fei3@zte.com.cn Fri Feb 24 00:16:01 2012 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 30C9621E8039; Fri, 24 Feb 2012 00:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.459 X-Spam-Level: X-Spam-Status: No, score=-97.459 tagged_above=-999 required=5 tests=[AWL=0.176, 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 xhEmHpBgVdA5; Fri, 24 Feb 2012 00:16:00 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id AD50921E802A; Fri, 24 Feb 2012 00:15:58 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801461793122; Fri, 24 Feb 2012 15:46:32 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 60473.3175855372; Fri, 24 Feb 2012 16:15:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1O8FcHb085627; Fri, 24 Feb 2012 16:15:38 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "BRUNGARD, DEBORAH A" MIME-Version: 1.0 X-KeepSent: 56B20852:B87E5C24-482579AE:0027AD03; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Fri, 24 Feb 2012 16:15:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-24 16:15:41, Serialize complete at 2012-02-24 16:15:41 Content-Type: multipart/alternative; boundary="=_alternative 002D6035482579AE_=" X-MAIL: mse02.zte.com.cn q1O8FcHb085627 Cc: CCAMP , ccamp-bounces@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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, 24 Feb 2012 08:16:01 -0000 This is a multipart message in MIME format. --=_alternative 002D6035482579AE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SnVzdCBvbmUgY29tbWVudCBhYm91dCB0aGUgY2l0YXRpb25zLg0KDQpBcyBkZXNjcmliZWQgaW4g c2VjdGlvbiAzLjEsIHRoZSBBc3NvY2lhdGlvbiBJRCBhbmQgQXNzb2NpYXRpb24gU291cmNlIGlz IA0KdGhlIHNhbWUgYXMgZGVmaW5lZCBpbiBSRkM0ODcyLg0KDQpBbmQgYWNjb3JkaW5nIHRvIHRo ZSBkZXNjcmlwdGlvbiBpbiBzZWN0aW9uIDE2LjEgb2YgUkZDNDg3MiwgY2l0ZWQgaGVyZQ0KDQoi IEFzc29jaWF0aW9uIElEOiAxNiBiaXRzDQogICAgICAgICBBIHZhbHVlIGFzc2lnbmVkIGJ5IHRo ZSBMU1AgaGVhZC1lbmQuICBXaGVuIGNvbWJpbmVkIHdpdGggdGhlDQogICAgICAgICBBc3NvY2lh dGlvbiBUeXBlIGFuZCBBc3NvY2lhdGlvbiBTb3VyY2UsIHRoaXMgdmFsdWUgdW5pcXVlbHkNCiAg ICAgICAgIGlkZW50aWZpZXMgYW4gYXNzb2NpYXRpb24uIg0KDQoNCiIgQXNzb2NpYXRpb24gU291 cmNlOiA0IG9yIDE2IGJ5dGVzDQogICAgICAgICBBbiBJUHY0IG9yIElQdjYgYWRkcmVzcywgcmVz cGVjdGl2ZWx5LCB0aGF0IGlzIGFzc29jaWF0ZWQgdG8NCiAgICAgICAgIHRoZSBub2RlIHRoYXQg b3JpZ2luYXRlZCB0aGUgYXNzb2NpYXRpb24uIg0KDQo8ZmVpPiANCg0KKDEpIFdoZW4gdGhlIGFz c29jaWF0aW9uIG9iamVjdCBpcyB1c2VkIGZvciB0aGUgY28tcm91dGVkIGJpZGlyZWN0aW9uYWwg DQpMU1AsIHRoZSB0dW5uZWwgSUQgbG9jYWxseSBhc3NpZ25lZCBhdCBaOSBub2RlIG1heWJlIGJl IGZpbGxlZCBoZXJlLCANCmhvd2V2ZXIsDQppdCBpcyBub3QgYXNzaWduZWQgYnkgdGhlIExTUCBo ZWFkLWVuZCAoQTEgbm9kZSksIG9yIHdlIGNhbiBpbnRlcnByZXQgdGhhdCANClo5IGlzIGFsc28g dGhlIExTUCBoZWFkLWVuZD8NCg0KKDIpIEFub3RoZXIgdXNlY2FzZSBpcyB0aGF0IGZvciB0aGUg YXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwgdGhpcyANCmZpZWxkIG1heWJlIGJlIGZpbGxl ZCBieSB0aGUgdGhlIHR1bm5lbCBJRCBvZiB0aGUgZm9yd2FyZCBMU1AxIG9yIHRoZSANCmJhY2t3 YXJkIExTUDIuIElmIGl0IGlzIHRoZSB0dW5uZWwgSUQgb2YgTFNQMSwgd2hpY2ggaXMgbm90IGFz c2lnbmVkIGJ5IA0KdGhlIExTUDIgaGVhZC1lbmQuIA0KDQooMylTaW1pbGFybHkgYXMgYWJvdmUs IHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UgbWF5YmUgYmUgcmVsYXRlZCB0byBBMSBvciBaOSANCm5v ZGUsIGFuZCBib3RoIG9mIHRoZW0gYXJlIHRoZSBub2RlcyB0aGF0IG9yaWdpbmF0ZSB0aGUgYXNz b2NpYXRpb24gd2hlbiANCmRvdWJsZSBzaWRlZCBwcm92aXNpb25naW5nIG1vZGUgaXMgdXNlZC4N Cg0KKDMpSW4gdGhlIGdlbmVyYWwgc2NlbmFyaW9zLCB0aGUgY29tYmluYXRpb24gb2YgQXNzb2Np YXRpb24gVHlwZSwgDQpBc3NvY2lhdGlvbiBTb3VyY2UsIEdsb2JhbCBBc3NvY2lhdGlvbiBTb3Vy Y2UgYW5kIGV4dGVuZGVkIEFzc29jaWF0aW9uIGlkIA0Kd2lsbCBpZGVudGlmeQ0KYW4gYXNzb2Np YXRpb24uDQoNCkp1c3QgbXkyY2VudHMsIHRoZSBkZXNjcmlwdGlvbnMgYWJvdXQgdGhlIGFzc29j aWF0aW9uIHNvdXJjZSBhbmQgaWQgYXJlIA0KYWNjdXJhdGUgdW5kZXIgdGhlIHNjb3BlIG9mIFJG QzQ4NzIsIGJ1dCB0aGUgZGlyZWN0IGNpdGF0aW9uIGZyb20gUkZDNDg3MiANCmlzIG5vdCBhY2N1 cmF0ZSBoZXJlIGlmIHdlIGNvbnNpZGVyIHRoZSBtb3JlIHVzZWNhc2VzLiBDYW4gdGhlIGxpbWl0 YXRpb24gDQpiZSByZWxlYXNlZCBvciB0aGVzZSB3b3JkcyBiZSBvcmdhbml6ZWQgaW4gYW5vdGhl ciB3YXk/DQoNCjwvZmVpPg0KDQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg0KDQoNCiJCUlVOR0FS RCwgREVCT1JBSCBBIiA8ZGIzNTQ2QGF0dC5jb20+IA0Kt6K8/sjLOiAgY2NhbXAtYm91bmNlc0Bp ZXRmLm9yZw0KMjAxMi0wMi0yNCAwNjoxMg0KDQrK1bz+yMsNCkNDQU1QIDxjY2FtcEBpZXRmLm9y Zz4NCrOty80NCg0K1vfM4g0KW0NDQU1QXSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1jY2Ft cC1hc3NvYy1leHQNCg0KDQoNCg0KDQoNCkFsbCwNCg0KVGhpcyBzdGFydHMgYSB0d28td2VlayB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiANCmRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0Lg0K DQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgTWFyY2ggOHRoLiBQbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIA0KdGhlIENDQU1QIG1haWxpbmcgbGlzdC4NCg0KRGVib3JhaCAo YW5kIExvdSkNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQoNCg== --=_alternative 002D6035482579AE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkp1c3Qgb25lIGNvbW1lbnQgYWJv dXQgdGhlIGNpdGF0aW9ucy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMSwgdGhlIEFzc29jaWF0aW9uDQpJ RCBhbmQgQXNzb2NpYXRpb24gU291cmNlIGlzIHRoZSBzYW1lIGFzIGRlZmluZWQgaW4gUkZDNDg3 Mi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFuZCBh Y2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIGluDQpzZWN0aW9uIDE2LjEgb2YgUkZDNDg3Miwg Y2l0ZWQgaGVyZTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7IEFzc29jaWF0aW9uIElEOiAxNiBiaXRzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBBIHZhbHVlIGFzc2lnbmVkIGJ5IHRoZSBMU1AgaGVhZC1lbmQuICZuYnNwO1do ZW4NCmNvbWJpbmVkIHdpdGggdGhlPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBB c3NvY2lhdGlvbiBUeXBlIGFuZCBBc3NvY2lhdGlvbiBTb3VyY2UsIHRoaXMNCnZhbHVlIHVuaXF1 ZWx5PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBpZGVudGlmaWVzIGFuIGFzc29j aWF0aW9uLiZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KJnF1b3Q7IEFzc29jaWF0aW9uIFNvdXJjZTogNCBvciAxNiBieXRlczxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQW4gSVB2NCBvciBJUHY2IGFkZHJlc3MsIHJl c3BlY3RpdmVseSwgdGhhdA0KaXMgYXNzb2NpYXRlZCB0bzxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVkIHRoZSBhc3NvY2lhdGlvbi4mcXVv dDs8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtm ZWkmZ3Q7IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ KDEpIFdoZW4gdGhlIGFzc29jaWF0aW9uIG9iamVjdCBpcyB1c2VkDQpmb3IgdGhlIGNvLXJvdXRl ZCBiaWRpcmVjdGlvbmFsIExTUCwgdGhlIHR1bm5lbCBJRCBsb2NhbGx5IGFzc2lnbmVkIGF0DQpa OSBub2RlIG1heWJlIGJlIGZpbGxlZCBoZXJlLCBob3dldmVyLDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aXQgaXMgbm90IGFzc2lnbmVkIGJ5IHRoZSBMU1AgaGVh ZC1lbmQNCihBMSBub2RlKSwgb3Igd2UgY2FuIGludGVycHJldCB0aGF0IFo5IGlzIGFsc28gdGhl IExTUCBoZWFkLWVuZD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPigyKSBBbm90aGVyIHVzZWNhc2UgaXMgdGhhdCBmb3IgdGhlDQphc3NvY2lhdGVkIGJp ZGlyZWN0aW9uYWwgTFNQLCB0aGlzIGZpZWxkIG1heWJlIGJlIGZpbGxlZCBieSB0aGUgdGhlIHR1 bm5lbA0KSUQgb2YgdGhlIGZvcndhcmQgTFNQMSBvciB0aGUgYmFja3dhcmQgTFNQMi4gSWYgaXQg aXMgdGhlIHR1bm5lbCBJRCBvZg0KTFNQMSwgd2hpY2ggaXMgbm90IGFzc2lnbmVkIGJ5IHRoZSBM U1AyIGhlYWQtZW5kLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPigzKVNpbWlsYXJseSBhcyBhYm92ZSwgdGhlIGFzc29jaWF0aW9uDQpzb3VyY2UgbWF5 YmUgYmUgcmVsYXRlZCB0byBBMSBvciBaOSBub2RlLCBhbmQgYm90aCBvZiB0aGVtIGFyZSB0aGUg bm9kZXMNCnRoYXQgb3JpZ2luYXRlIHRoZSBhc3NvY2lhdGlvbiB3aGVuIGRvdWJsZSBzaWRlZCBw cm92aXNpb25naW5nIG1vZGUgaXMNCnVzZWQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4oMylJbiB0aGUgZ2VuZXJhbCBzY2VuYXJpb3MsIHRoZSBjb21i aW5hdGlvbg0Kb2YgQXNzb2NpYXRpb24gVHlwZSwgQXNzb2NpYXRpb24gU291cmNlLCBHbG9iYWwg QXNzb2NpYXRpb24gU291cmNlIGFuZA0KZXh0ZW5kZWQgQXNzb2NpYXRpb24gaWQgd2lsbCBpZGVu dGlmeTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW4gYXNzb2Np YXRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5K dXN0IG15MmNlbnRzLCB0aGUgZGVzY3JpcHRpb25zIGFib3V0DQp0aGUgYXNzb2NpYXRpb24gc291 cmNlIGFuZCBpZCBhcmUgYWNjdXJhdGUgdW5kZXIgdGhlIHNjb3BlIG9mIFJGQzQ4NzIsDQpidXQg dGhlIGRpcmVjdCBjaXRhdGlvbiBmcm9tIFJGQzQ4NzIgaXMgbm90IGFjY3VyYXRlIGhlcmUgaWYg d2UgY29uc2lkZXINCnRoZSBtb3JlIHVzZWNhc2VzLiBDYW4gdGhlIGxpbWl0YXRpb24gYmUgcmVs ZWFzZWQgb3IgdGhlc2Ugd29yZHMgYmUgb3JnYW5pemVkDQppbiBhbm90aGVyIHdheT88L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZsdDsvZmVpJmd0Ozwv Zm9udD4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVz dCByZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+JnF1b3Q7QlJVTkdBUkQsIERFQk9SQUgNCkEmcXVvdDsgJmx0O2RiMzU0NkBhdHQuY29tJmd0 OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6 ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMi0wMi0yNCAwNjoxMjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5DQ0FNUCAmbHQ7Y2NhbXBAaWV0Zi5vcmcm Z3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5bQ0NBTVBdIFdHIExhc3QgQ2FsbCBvbiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dDwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ QWxsLDxicj4NCjxicj4NClRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0 IGNhbGwgb24gZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQuPGJyPg0KPGJyPg0KVGhpcyB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE1hcmNoIDh0aC4gUGxlYXNlIHNlbmQgeW91ciBjb21t ZW50cw0KdG8gdGhlIENDQU1QIG1haWxpbmcgbGlzdC48YnI+DQo8YnI+DQpEZWJvcmFoIChhbmQg TG91KTxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NB TVBAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj YW1wPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 002D6035482579AE_=-- From daniele.ceccarelli@ericsson.com Fri Feb 24 01:48:39 2012 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 8ADCA21F88CC for ; Fri, 24 Feb 2012 01:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.26 X-Spam-Level: X-Spam-Status: No, score=-8.26 tagged_above=-999 required=5 tests=[AWL=2.339, 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 Zy8ybHtgqAfK for ; Fri, 24 Feb 2012 01:48:38 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4091221F88CB for ; Fri, 24 Feb 2012 01:48:38 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-17-4f475cf5c896 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.9C.27041.5FC574F4; Fri, 24 Feb 2012 10:48:37 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.48]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 24 Feb 2012 10:48:37 +0100 From: Daniele Ceccarelli To: Igor Bryskin , Lou Berger , "Ong, Lyndon" Date: Fri, 24 Feb 2012 10:48:35 +0100 Thread-Topic: [CCAMP] question on rerouting with reversion Thread-Index: Aczxfsl5Tq96ss2FSCyMLeBHby5KiAAxyWGQAA3IQAAACPJFkAAN0LfQ Message-ID: References: <4F467B98.7070901@labn.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 24 Feb 2012 09:48:39 -0000 So do we, but in a slightly different fashion. MBB plus keeping the nominal= path rerources reserveed (this might allow for reuse of part of them from = other LSPs with lower priority). In case the work Lyndon is proposing is pr= ogressed, both options might be reflected. In reply to Francesco and Lou, i agree with you on the fact that it is a lo= cal policy, but local policies are not always manually configured, there ar= e two cases that they are not: 1. SC (swtched connections). In this case the node asking the ingress for a= connection should be able to ask for a "revertive" restoration or not (rev= ertive term not properly used, but "i wanna get back to the orig path as so= os as it is in good shape" was too long) 2. Segment recovery. In this case the policy is not local but remote. The i= ngress should be able to tell the LSR performing the segment recovery wheth= er to go back to the nominal path or not (couldn't find anything on this in= RFC4873). BR Daniele >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of Igor Bryskin >Sent: gioved=EC 23 febbraio 2012 19.37 >To: Lou Berger; Ong, Lyndon >Cc: CCAMP >Subject: Re: [CCAMP] question on rerouting with reversion > >Lou. > >This someone was me. :=3D) We call it dynamic restoration with=20 >reversion. When the second LSP is created, it is done via=20 >make-without-break procedure. Once the failure is repaired the=20 >second LSP is removed. > >Cheers, >Igor > >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of Lou Berger >Sent: Thursday, February 23, 2012 12:47 PM >To: Ong, Lyndon >Cc: CCAMP >Subject: Re: [CCAMP] question on rerouting with reversion > >Hi Lyndon, > >See below. > >On 2/23/2012 11:13 AM, Ong, Lyndon wrote: >> Hi Folks, >>=20 >> =20 >>=20 >> We would like to be able to support of a version of rerouting that=20 >> has the following characteristics: >>=20 >> - First the original LSP is established on demand. >>=20 >> - Secondly failure of the original LSP causes an=20 >alternate LSP >> to be created without any prior reservation of backup resources,=20 >> potentially sharing some resources >>=20 >> - Finally, traffic reverts to the original LSP path once the >> failure is repaired. >>=20 > >I see nothing that precludes this in the current specs. (I=20 >believe someone mentioned to me that they support exactly this=20 >behavior.) As described, this is largely handled at an=20 >application level above signaling. > >> We wanted to get the benefit of CCAMP's expertise and=20 >knowledge as to=20 >> whether this combination of reversion and rerouting is supported in=20 >> the existing recovery specifications or not. We have taken a read=20 >> through some of the specifications and haven't found an=20 >exact fit yet. >>=20 >> =20 >>=20 >> In our reading of RFC4872, section 11, full LSP rerouting=20 >(protection=20 >> type 0x01) involves tearing down the original LSP, although it says=20 >> make-before-break can be used to establish the alternate LSP before=20 >> tearing down the original, so that some of the resources can=20 >be reused. >>=20 > >As you note, the make-before-break is listed as an informative option. >Furthermore, the text does no include any required behavior on=20 >the alternate LSP. I can't speak for the authors, but I can=20 >see why they didn't include required behavior as there is no=20 >interoperability issues with several of the different approaches. > >That said, I think documenting the options, with or without a=20 >recommended approach, could be valuable to some. > >> =20 >>=20 >> Rerouting without extra traffic (protection type 0x02) involves=20 >> pre-establishment of the alternate LSP using a disjoint=20 >path, with no=20 >> sharing of resources. >>=20 >> =20 >>=20 >> We also found that section 12 on reversion describes how=20 >reversion is=20 >> supported for 1+1 bidirectional protection, 1:n protection=20 >with extra=20 >> traffic, and rerouting without extra traffic, but has no description=20 >> for reversion for the full LSP rerouting case. >>=20 > >Again, I can't speak for the authors, but my guess is that=20 >they made a choice to not put requirements on the LSP Rerouting case. > >If we were to add such constraints, I suspect the change is=20 >little more than (in Section 12): > s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ > >> =20 >>=20 >> Is there a procedure that would support the kind of rerouting with=20 >> reversion above that we may have missed > >The only think you have missed is the perspective that most of=20 >the (G)MPLS specs provide tools for a toolbox, and it is often=20 >up to the implementer to choose how to implement a particular solution. > >As I mentioned above, I believe that an implementation can use=20 >existing specs to implement this solution. > >> or does a procedure might need >> to be added to the specifications for this? =20 > >This is a question of perspectives, if you just want everyone=20 >to interoperate -- this can be supported today. On the other=20 >hand, if your objective is for all to implement this function=20 >in the same way, then more specification is needed. To me it=20 >seems the authors of 4872 desired the former while you want the latter. > >> We are preparing a draft >> that would identify the functionality and requirements and it would=20 >> help us to get your input on whether you think this is already=20 >> supported or will need extensions to the specifications (or=20 >if you see=20 >> potential problems supporting something like this). > >Well it seems to me (as a WG participant) that there may be=20 >room for an informative or, at most, a BCP document, but=20 >unless I'm missing something, don't think there's any new=20 >protocol mechanisms to define. > >Obviously, specific comments on your draft will need to wait=20 >for it to be published. > >Lou > >>=20 >> =20 >>=20 >> Thanks for your help! >>=20 >> =20 >>=20 >> Best regards, >>=20 >> =20 >>=20 >> Lyndon Ong >>=20 >> Evelyne Roch >>=20 >> =20 >>=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 >= From ogondio@tid.es Fri Feb 24 02:20:59 2012 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 B732321F86FE for ; Fri, 24 Feb 2012 02:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 KJql6QHXm9Ts for ; Fri, 24 Feb 2012 02:20:51 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9242021F88C8 for ; Fri, 24 Feb 2012 02:20:50 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZW00C497EMRS@tid.hi.inet> for ccamp@ietf.org; Fri, 24 Feb 2012 11:20:48 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id B9.8A.02643.F74674F4; Fri, 24 Feb 2012 11:20:47 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LZW00C4C7ENRS@tid.hi.inet> for ccamp@ietf.org; Fri, 24 Feb 2012 11:20:47 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Fri, 24 Feb 2012 11:20:46 +0100 Date: Fri, 24 Feb 2012 11:20:45 +0100 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= In-reply-to: To: Daniele Ceccarelli , Igor Bryskin , Lou Berger , "Ong, Lyndon" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es-ES Content-transfer-encoding: quoted-printable Accept-Language: es-ES, en-US Thread-topic: [CCAMP] question on rerouting with reversion Thread-index: Aczxfsl5Tq96ss2FSCyMLeBHby5KiAAxyWGQAA3IQAAACPJFkAAN0LfQAAFT+JA= acceptlanguage: es-ES, en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-4e-4f47647f43d5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsXCFe9nqNuQ4u5v8P0Lk8WTOTdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcfTsXLaCf1YV6+4dZW1gvK3fxcjJISFgInGqbTEThC0mceHe erYuRi4OIYFtjBK3bqxkhXB+MEpMOryWEcJpZJQ4+OMNC0gLi4CqxOWJ+1hBbDYBB4l1i3rZ QGxhAUuJl9dbwWxOgSiJ5WtegDWLCCxllPgzeRdYM7OAlMSu9z3sIDavgKfExd7XULagxI/J 96BqdCR6v39jhrDFJeb8msgKYWtLPHl3AcxmFJCVWHn+NCOILSJgJbHlyh8mCNtPYtW9mewQ NTIS/5fvZYH4U0BiyZ7zzBC2qMTLx/+g3mxnkvg+cSbzBEbxWUjumIXkjllI7piF5I4FjCyr GMWKk4oy0zNKchMzc9INjPQyMvUy81JLNjFCoilzB+PynSqHGAU4GJV4eK/EuvkLsSaWFVfm HmKU5GBSEuUNSnT3F+JLyk+pzEgszogvKs1JLT7EKMHBrCTCa7YYqJw3JbGyKrUoHyYlw8Gh JMG7OBmoTbAoNT21Ii0zB5gyYNJMHJwg7TxA7YdAaniLCxJzizPTIfKnGFU5Wp4/v8AoxJKX n5cqJc47C6RIAKQoozQPbs4rRnGgg4Uh1vAAkx7chFdAw5mAhtv/dQUZXpKIkJJqYFRMWWr6 79PfFakXkj4o1+9lmjLdWsiE8cS3x1fvHpf7ZCv0axFT7GLBh8+YE/9OVE079/XTiZ/P1i76 On3Hl10tlysaP333ZlHjmRf64MTSJwcDfNeEls/l2+nUtn1D0z6BOy2i7r/8/x+sfez370Ws A+OPNT6fpglGZq/v2PRlF4td2bNHTkE/lFiKMxINtZiLihMB59HRSDcDAAA= References: <4F467B98.7070901@labn.net> Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 24 Feb 2012 10:21:00 -0000 +1 to Daniele's approach. We keep the nominal path resources reserved, as a way to guarantee the reve= rsion. Otherwise, there is no such guarantee, any new incoming LSP may have= used part of the resources of the original route. =D3scar >-----Mensaje original----- >De: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] En nombre de >Daniele Ceccarelli >Enviado el: viernes, 24 de febrero de 2012 10:49 >Para: Igor Bryskin; Lou Berger; Ong, Lyndon >CC: CCAMP >Asunto: Re: [CCAMP] question on rerouting with reversion > >So do we, but in a slightly different fashion. MBB plus keeping the nomina= l >path rerources reserveed (this might allow for reuse of part of them from >other LSPs with lower priority). In case the work Lyndon is proposing is >progressed, both options might be reflected. > >In reply to Francesco and Lou, i agree with you on the fact that it is a l= ocal >policy, but local policies are not always manually configured, there are t= wo >cases that they are not: > >1. SC (swtched connections). In this case the node asking the ingress for = a >connection should be able to ask for a "revertive" restoration or not (rev= ertive >term not properly used, but "i wanna get back to the orig path as soos as = it is >in good shape" was too long) > >2. Segment recovery. In this case the policy is not local but remote. The >ingress should be able to tell the LSR performing the segment recovery >whether to go back to the nominal path or not (couldn't find anything on t= his >in RFC4873). > >BR >Daniele > > > >>-----Original Message----- >>From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>Of Igor Bryskin >>Sent: gioved=EC 23 febbraio 2012 19.37 >>To: Lou Berger; Ong, Lyndon >>Cc: CCAMP >>Subject: Re: [CCAMP] question on rerouting with reversion >> >>Lou. >> >>This someone was me. :=3D) We call it dynamic restoration with >>reversion. When the second LSP is created, it is done via >>make-without-break procedure. Once the failure is repaired the second >>LSP is removed. >> >>Cheers, >>Igor >> >>-----Original Message----- >>From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>Of Lou Berger >>Sent: Thursday, February 23, 2012 12:47 PM >>To: Ong, Lyndon >>Cc: CCAMP >>Subject: Re: [CCAMP] question on rerouting with reversion >> >>Hi Lyndon, >> >>See below. >> >>On 2/23/2012 11:13 AM, Ong, Lyndon wrote: >>> Hi Folks, >>> >>> >>> >>> We would like to be able to support of a version of rerouting that >>> has the following characteristics: >>> >>> - First the original LSP is established on demand. >>> >>> - Secondly failure of the original LSP causes an >>alternate LSP >>> to be created without any prior reservation of backup resources, >>> potentially sharing some resources >>> >>> - Finally, traffic reverts to the original LSP path once the >>> failure is repaired. >>> >> >>I see nothing that precludes this in the current specs. (I believe >>someone mentioned to me that they support exactly this >>behavior.) As described, this is largely handled at an application >>level above signaling. >> >>> We wanted to get the benefit of CCAMP's expertise and >>knowledge as to >>> whether this combination of reversion and rerouting is supported in >>> the existing recovery specifications or not. We have taken a read >>> through some of the specifications and haven't found an >>exact fit yet. >>> >>> >>> >>> In our reading of RFC4872, section 11, full LSP rerouting >>(protection >>> type 0x01) involves tearing down the original LSP, although it says >>> make-before-break can be used to establish the alternate LSP before >>> tearing down the original, so that some of the resources can >>be reused. >>> >> >>As you note, the make-before-break is listed as an informative option. >>Furthermore, the text does no include any required behavior on the >>alternate LSP. I can't speak for the authors, but I can see why they >>didn't include required behavior as there is no interoperability issues >>with several of the different approaches. >> >>That said, I think documenting the options, with or without a >>recommended approach, could be valuable to some. >> >>> >>> >>> Rerouting without extra traffic (protection type 0x02) involves >>> pre-establishment of the alternate LSP using a disjoint >>path, with no >>> sharing of resources. >>> >>> >>> >>> We also found that section 12 on reversion describes how >>reversion is >>> supported for 1+1 bidirectional protection, 1:n protection >>with extra >>> traffic, and rerouting without extra traffic, but has no description >>> for reversion for the full LSP rerouting case. >>> >> >>Again, I can't speak for the authors, but my guess is that they made a >>choice to not put requirements on the LSP Rerouting case. >> >>If we were to add such constraints, I suspect the change is little more >>than (in Section 12): >> s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ >> >>> >>> >>> Is there a procedure that would support the kind of rerouting with >>> reversion above that we may have missed >> >>The only think you have missed is the perspective that most of the >>(G)MPLS specs provide tools for a toolbox, and it is often up to the >>implementer to choose how to implement a particular solution. >> >>As I mentioned above, I believe that an implementation can use existing >>specs to implement this solution. >> >>> or does a procedure might need >>> to be added to the specifications for this? >> >>This is a question of perspectives, if you just want everyone to >>interoperate -- this can be supported today. On the other hand, if >>your objective is for all to implement this function in the same way, >>then more specification is needed. To me it seems the authors of 4872 >>desired the former while you want the latter. >> >>> We are preparing a draft >>> that would identify the functionality and requirements and it would >>> help us to get your input on whether you think this is already >>> supported or will need extensions to the specifications (or >>if you see >>> potential problems supporting something like this). >> >>Well it seems to me (as a WG participant) that there may be room for an >>informative or, at most, a BCP document, but unless I'm missing >>something, don't think there's any new protocol mechanisms to define. >> >>Obviously, specific comments on your draft will need to wait for it to >>be published. >> >>Lou >> >>> >>> >>> >>> Thanks for your help! >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Lyndon Ong >>> >>> Evelyne Roch >>> >>> >>> >>_______________________________________________ >>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 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From db3546@att.com Fri Feb 24 08:14:45 2012 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 AD26E21F86B6 for ; Fri, 24 Feb 2012 08:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 kTGBE9tu6kRU for ; Fri, 24 Feb 2012 08:14:43 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBE521F8671 for ; Fri, 24 Feb 2012 08:14:29 -0800 (PST) X-Env-Sender: db3546@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1330100067!65158031!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12964 invoked from network); 24 Feb 2012 16:14:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Feb 2012 16:14:28 -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 q1OGEv9n000647; Fri, 24 Feb 2012 11:14:58 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1OGEtUA000581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 11:14:56 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint02.pst.cso.att.com (RSA Interceptor); Fri, 24 Feb 2012 11:14:18 -0500 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.184]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 11:14:18 -0500 From: "BRUNGARD, DEBORAH A" To: Francesco Fondelli Thread-Topic: [CCAMP] question on rerouting with reversion Thread-Index: Aczxfsl5Tq96ss2FSCyMLeBHby5KiAAxyWGQAA3IQAAAAJXnAAAi1NaA Date: Fri, 24 Feb 2012 16:14:18 +0000 Message-ID: References: <4F467B98.7070901@labn.net> In-Reply-To: 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 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 24 Feb 2012 16:14:45 -0000 Hi Francesco, Thanks for the input. Section 4.11 is part of Section 4: "Recovery Terminology Common to Protecti= on and Restoration". So 4.11, "revertive recovery operation" refers to both= protection and restoration. You gave a good reminder with Attila's draft (which has expired). Maybe it = will be of more interest at this time (and it's similar to Attila's OAM con= figuration documents). Maybe a MIBs would be helpful for folks interested i= n configuration. Ciao, Deborah -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= rancesco Fondelli Sent: Thursday, February 23, 2012 1:04 PM To: Lou Berger Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion +1 Just a side note: I think the term "reversion" applies only to protection (RFC 4427, section 4.11). "Revertive-ness" in this case can be signaled with draft-takacs-ccamp-revertive-ps-06. In case of restoration is... hmmm "I wanna get back to the orig path as soon as it is in good shape" :-). Anyway, as Lou said, I think is a (one of the possible) local policy. hope this helps ciao FF On Thu, Feb 23, 2012 at 6:47 PM, Lou Berger wrote: > Hi Lyndon, > > See below. > > On 2/23/2012 11:13 AM, Ong, Lyndon wrote: >> Hi Folks, >> >> >> >> We would like to be able to ?support of a version of rerouting that has >> the following characteristics: >> >> - ? ? ? ? ?First the original LSP is established on demand. >> >> - ? ? ? ? ?Secondly failure of the original LSP causes an alternate LSP >> to be created without any prior reservation of backup resources, >> potentially sharing some resources >> >> - ? ? ? ? ?Finally, traffic reverts to the original LSP path once the >> failure is repaired. >> > > I see nothing that precludes this in the current specs. ?(I believe > someone mentioned to me that they support exactly this behavior.) As > described, this is largely handled at an application level above signalin= g. > >> We wanted to get the benefit of CCAMP?s expertise and knowledge as to >> whether this combination of reversion and rerouting is supported in the >> existing recovery specifications or not. ?We have taken a read through >> some of the specifications and haven?t found an exact fit yet. >> >> >> >> In our reading of RFC4872, section 11, full LSP rerouting (protection >> type 0x01) involves tearing down the original LSP, although it says >> make-before-break can be used to establish the alternate LSP before >> tearing down the original, so that some of the resources can be reused. >> > > As you note, the make-before-break is listed as an informative option. > Furthermore, the text does no include any required behavior on the > alternate LSP. I can't speak for the authors, but I can see why they > didn't include required behavior as there is no interoperability issues > with several of the different approaches. > > That said, I think documenting the options, with or without a > recommended approach, could be valuable to some. > >> >> >> Rerouting without extra traffic (protection type 0x02) involves >> pre-establishment of the alternate LSP using a disjoint path, with no >> sharing of resources. >> >> >> >> We also found that section 12 on reversion describes how reversion is >> supported for 1+1 bidirectional protection, 1:n protection with extra >> traffic, and rerouting without extra traffic, but has no description for >> reversion for the full LSP rerouting case. >> > > Again, I can't speak for the authors, but my guess is that they made a > choice to not put requirements on the LSP Rerouting case. > > If we were to add such constraints, I suspect the change is little more > than (in Section 12): > ? ? ? ?s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ > >> >> >> Is there a procedure that would support the kind of rerouting with >> reversion above that we may have missed > > The only think you have missed is the perspective that most of the > (G)MPLS specs provide tools for a toolbox, and it is often up to the > implementer to choose how to implement a particular solution. > > As I mentioned above, I believe that an implementation can use existing > specs to implement this solution. > >> or does a procedure might need >> to be added to the specifications for this? > > This is a question of perspectives, if you just want everyone to > interoperate -- this can be supported today. ?On the other hand, if your > objective is for all to implement this function in the same way, then > more specification is needed. ?To me it seems the authors of 4872 > desired the former while you want the latter. > >> We are preparing a draft >> that would identify the functionality and requirements and it would help >> us to get your input on whether you think this is already supported or >> will need extensions to the specifications (or if you see potential >> problems supporting something like this). > > Well it seems to me (as a WG participant) that there may be room for an > informative or, at most, a BCP document, but unless I'm missing > something, don't think there's any new protocol mechanisms to define. > > Obviously, specific comments on your draft will need to wait for it to > be published. > > Lou > >> >> >> >> Thanks for your help! >> >> >> >> Best regards, >> >> >> >> Lyndon Ong >> >> Evelyne Roch >> >> >> > _______________________________________________ > 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 francesco.fondelli@gmail.com Fri Feb 24 09:50:25 2012 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 5242821F8817 for ; Fri, 24 Feb 2012 09:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, 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 cNVlf0eqYjJE for ; Fri, 24 Feb 2012 09:50:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5493F21F8815 for ; Fri, 24 Feb 2012 09:50:24 -0800 (PST) Received: by yenm3 with SMTP id m3so1413927yen.31 for ; Fri, 24 Feb 2012 09:50:24 -0800 (PST) Received-SPF: pass (google.com: domain of francesco.fondelli@gmail.com designates 10.236.124.170 as permitted sender) client-ip=10.236.124.170; Authentication-Results: mr.google.com; spf=pass (google.com: domain of francesco.fondelli@gmail.com designates 10.236.124.170 as permitted sender) smtp.mail=francesco.fondelli@gmail.com; dkim=pass header.i=francesco.fondelli@gmail.com Received: from mr.google.com ([10.236.124.170]) by 10.236.124.170 with SMTP id x30mr6500182yhh.70.1330105824030 (num_hops = 1); Fri, 24 Feb 2012 09:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=odgOOk4BXs/D6qAcW2sY6BZ/u6ebnecYPBychB3BDbY=; b=FWDjisdMFE2pH1pDDe0e7Ru0LTXuLX6UE2CvS971dShNuTftxaPgOw0yr3Ut+J9gEY 2KF8xAhqZVQEoZ2JhldyhFdX2fuLJ9OtHA5yG79UP8L65TGALsbwO9Cxnozkwcc8GqzT gNCI/RTrsHMCl964rzX17ZUwpZ2AoJR3H/B4w= MIME-Version: 1.0 Received: by 10.236.124.170 with SMTP id x30mr4959813yhh.70.1330105721532; Fri, 24 Feb 2012 09:48:41 -0800 (PST) Received: by 10.236.37.228 with HTTP; Fri, 24 Feb 2012 09:48:41 -0800 (PST) In-Reply-To: References: <4F467B98.7070901@labn.net> Date: Fri, 24 Feb 2012 18:48:41 +0100 Message-ID: From: Francesco Fondelli To: "BRUNGARD, DEBORAH A" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: CCAMP Subject: Re: [CCAMP] question on rerouting with reversion 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, 24 Feb 2012 17:50:25 -0000 On Fri, Feb 24, 2012 at 5:14 PM, BRUNGARD, DEBORAH A wrote= : > Hi Francesco, Hi Deborah, > Thanks for the input. > > Section 4.11 is part of Section 4: "Recovery Terminology Common to Protec= tion and Restoration". So 4.11, "revertive recovery operation" refers to bo= th protection and restoration. I see, statements like "switching operation" and "switch-over requests" make me think at protection rather than restoration. Anyway, you are right= . > You gave a good reminder with Attila's draft (which has expired). > Maybe it will be of more interest at this time (and it's similar > to Attila's OAM yep! I agree. >configuration documents). Maybe a MIBs would be helpful for folks interest= ed in configuration. > Ciao, > Deborah thanks Ciao FF > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of= Francesco Fondelli > Sent: Thursday, February 23, 2012 1:04 PM > To: Lou Berger > Cc: CCAMP > Subject: Re: [CCAMP] question on rerouting with reversion > > +1 > > Just a side note: I think the term "reversion" applies only to > protection (RFC 4427, section 4.11). =C2=A0"Revertive-ness" in this > case can be signaled with draft-takacs-ccamp-revertive-ps-06. > > In case of restoration is... hmmm "I wanna get back to the orig > path as soon as it is in good shape" :-). =C2=A0Anyway, as Lou said, I > think is a (one of the possible) local policy. > > hope this helps > ciao > FF > > On Thu, Feb 23, 2012 at 6:47 PM, Lou Berger wrote: >> Hi Lyndon, >> >> See below. >> >> On 2/23/2012 11:13 AM, Ong, Lyndon wrote: >>> Hi Folks, >>> >>> >>> >>> We would like to be able to ?support of a version of rerouting that has >>> the following characteristics: >>> >>> - ? ? ? ? ?First the original LSP is established on demand. >>> >>> - ? ? ? ? ?Secondly failure of the original LSP causes an alternate LSP >>> to be created without any prior reservation of backup resources, >>> potentially sharing some resources >>> >>> - ? ? ? ? ?Finally, traffic reverts to the original LSP path once the >>> failure is repaired. >>> >> >> I see nothing that precludes this in the current specs. ?(I believe >> someone mentioned to me that they support exactly this behavior.) As >> described, this is largely handled at an application level above signali= ng. >> >>> We wanted to get the benefit of CCAMP?s expertise and knowledge as to >>> whether this combination of reversion and rerouting is supported in the >>> existing recovery specifications or not. ?We have taken a read through >>> some of the specifications and haven?t found an exact fit yet. >>> >>> >>> >>> In our reading of RFC4872, section 11, full LSP rerouting (protection >>> type 0x01) involves tearing down the original LSP, although it says >>> make-before-break can be used to establish the alternate LSP before >>> tearing down the original, so that some of the resources can be reused. >>> >> >> As you note, the make-before-break is listed as an informative option. >> Furthermore, the text does no include any required behavior on the >> alternate LSP. I can't speak for the authors, but I can see why they >> didn't include required behavior as there is no interoperability issues >> with several of the different approaches. >> >> That said, I think documenting the options, with or without a >> recommended approach, could be valuable to some. >> >>> >>> >>> Rerouting without extra traffic (protection type 0x02) involves >>> pre-establishment of the alternate LSP using a disjoint path, with no >>> sharing of resources. >>> >>> >>> >>> We also found that section 12 on reversion describes how reversion is >>> supported for 1+1 bidirectional protection, 1:n protection with extra >>> traffic, and rerouting without extra traffic, but has no description fo= r >>> reversion for the full LSP rerouting case. >>> >> >> Again, I can't speak for the authors, but my guess is that they made a >> choice to not put requirements on the LSP Rerouting case. >> >> If we were to add such constraints, I suspect the change is little more >> than (in Section 12): >> ? ? ? ?s/For "Rerouting/For "(Full) LSP Rerouting" and "Rerouting/ >> >>> >>> >>> Is there a procedure that would support the kind of rerouting with >>> reversion above that we may have missed >> >> The only think you have missed is the perspective that most of the >> (G)MPLS specs provide tools for a toolbox, and it is often up to the >> implementer to choose how to implement a particular solution. >> >> As I mentioned above, I believe that an implementation can use existing >> specs to implement this solution. >> >>> or does a procedure might need >>> to be added to the specifications for this? >> >> This is a question of perspectives, if you just want everyone to >> interoperate -- this can be supported today. ?On the other hand, if your >> objective is for all to implement this function in the same way, then >> more specification is needed. ?To me it seems the authors of 4872 >> desired the former while you want the latter. >> >>> We are preparing a draft >>> that would identify the functionality and requirements and it would hel= p >>> us to get your input on whether you think this is already supported or >>> will need extensions to the specifications (or if you see potential >>> problems supporting something like this). >> >> Well it seems to me (as a WG participant) that there may be room for an >> informative or, at most, a BCP document, but unless I'm missing >> something, don't think there's any new protocol mechanisms to define. >> >> Obviously, specific comments on your draft will need to wait for it to >> be published. >> >> Lou >> >>> >>> >>> >>> Thanks for your help! >>> >>> >>> >>> Best regards, >>> >>> >>> >>> Lyndon Ong >>> >>> Evelyne Roch >>> >>> >>> >> _______________________________________________ >> 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 Fri Feb 24 09:53:56 2012 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 CF14721F88C1 for ; Fri, 24 Feb 2012 09:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.162 X-Spam-Level: X-Spam-Status: No, score=-98.162 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, 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 1OSJa9c8R-O5 for ; Fri, 24 Feb 2012 09:53:56 -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 DD26121F889E for ; Fri, 24 Feb 2012 09:53:55 -0800 (PST) Received: (qmail 3850 invoked by uid 0); 24 Feb 2012 17:53:54 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 24 Feb 2012 17:53: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=WdTGp5vekxyGn/jiZDsXrkjCuBsMTo2Hmg+XIS7BKY8=; b=QLZOXDuoPtb9Km69HD5+vSONBaSaanNN//J4NYF705Hc+uRO+2DHmtlZDQfEAheVjERMtYxLkYGksOqQFASaE4nSz0Kal5kssNrBVnL+kz/IxtI+DgbEidN8K12eXtCb; 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 1S0zL8-0003jr-3Q; Fri, 24 Feb 2012 10:53:54 -0700 Message-ID: <4F47CEB5.7060408@labn.net> Date: Fri, 24 Feb 2012 12:53:57 -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: zhang.fei3@zte.com.cn References: In-Reply-To: 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: CCAMP , ccamp-bounces@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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, 24 Feb 2012 17:53:56 -0000 Fei, see below for in-line responses. On 2/24/2012 3:15 AM, zhang.fei3@zte.com.cn wrote: > > Just one comment about the citations. > > As described in section 3.1, the Association ID and Association Source > is the same as defined in RFC4872. > > And according to the description in section 16.1 of RFC4872, cited here > > " Association ID: 16 bits > A value assigned by the LSP head-end. When combined with the > Association Type and Association Source, this value uniquely > identifies an association." > > > " Association Source: 4 or 16 bytes > An IPv4 or IPv6 address, respectively, that is associated to > the node that originated the association." > > > > (1) When the association object is used for the co-routed bidirectional > LSP, the tunnel ID locally assigned at Z9 node maybe be filled here, > however, > it is not assigned by the LSP head-end (A1 node), or we can interpret > that Z9 is also the LSP head-end? > The intent was that "the association ID is selected by the node creating the association object". This should be explicitly stated by the draft. This is an important clarification and will result in a few tweaks to the current document. Good catch. > (2) Another usecase is that for the associated bidirectional LSP, this > field maybe be filled by the the tunnel ID of the forward LSP1 or the > backward LSP2. If it is the tunnel ID of LSP1, which is not assigned by > the LSP2 head-end. Agreed. I think the above revision will accommodate this. > > (3)Similarly as above, the association source maybe be related to A1 or > Z9 node, and both of them are the nodes that originate the association > when double sided provisionging mode is used. same response... > > (3)In the general scenarios, the combination of Association Type, > Association Source, Global Association Source and extended Association > id will identify > an association. I'm not clear on your comment here. Does this relate to specific text? Are you looking for a change in the draft? Please clarify. > > Just my2cents, the descriptions about the association source and id are > accurate under the scope of RFC4872, but the direct citation from > RFC4872 is not accurate here if we consider the more usecases. I think we're in agreement. > Can the > limitation be released or these words be organized in another way? Yes, will revise as part of the post-LC revision. Thanks, Lou > > > > > Best regards > > Fei > > > *"BRUNGARD, DEBORAH A" * > 发件人: ccamp-bounces@ietf.org > > 2012-02-24 06:12 > > > 收件人 > CCAMP > 抄送 > > 主题 > [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext > > > > > > > > > All, > > This starts a two-week working group last call on > draft-ietf-ccamp-assoc-ext. > > This working group last call ends March 8th. Please send your comments > to the CCAMP mailing list. > > Deborah (and Lou) > > > > > _______________________________________________ > 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 Fri Feb 24 10:38:20 2012 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 264E021F8790 for ; Fri, 24 Feb 2012 10:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.152 X-Spam-Level: X-Spam-Status: No, score=-98.152 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, 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 81esVx5B8eQe for ; Fri, 24 Feb 2012 10:38:19 -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 4F72621F86C6 for ; Fri, 24 Feb 2012 10:38:19 -0800 (PST) Received: (qmail 4431 invoked by uid 0); 24 Feb 2012 18:38:19 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 24 Feb 2012 18:38:19 -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=TmqcJLz93gBG2zi0M7pgFSaHlTrdb2J5GcgZ6pj8nPU=; b=Z+kaa7i4QMM4i1hpHtYzj+0JlMMAZpo7fSIme59IeYmQmX0TRm8aeAzQLIMdRB+fxREt7k90tkRirz0ik3RBs9i0VIeLsoIJbH39Z1eiDVPNOB1aZipPBMKGNJBAbydo; 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 1S1026-00050y-QS; Fri, 24 Feb 2012 11:38:19 -0700 Message-ID: <4F47D91E.5090109@labn.net> Date: Fri, 24 Feb 2012 13:38: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: zhang.fei3@zte.com.cn References: <4F47CEB5.7060408@labn.net> In-Reply-To: <4F47CEB5.7060408@labn.net> 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: CCAMP , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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, 24 Feb 2012 18:38:20 -0000 Fei/All, I propose to address the Fei's comments by adding the following new section to the document. (as well as some other related editorial changes.) 2. Modified Association ID Field Definition The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION objects defined in [RFC4872]. The [RFC4872] definition of the field reads: A value assigned by the LSP head-end. When combined with the Association Type and Association Source, this value uniquely identifies an association. This document allows for the origination of ASSOCIATION objects by nodes other than "the LSP head-end". As such, the definition of the Association ID field needs to be modified to accommodate such usage. This document defines the Association ID field of the IPv4 and IPv6 ASSOCIATION objects as: A value assigned by the the node that originated the association. When combined with the Association Type and Association Source, this value uniquely identifies an association. This change in definition does not impact [RFC4872] or [RFC4873] defined procedures or mechanisms, nor does it impact existing implementations of [RFC4872] or [RFC4873]. I believe this addresses the comment. Let me know if you disagree, or have other comments. Much thanks, Lou (draft co-author) On 2/24/2012 12:53 PM, Lou Berger wrote: > Fei, > see below for in-line responses. > > On 2/24/2012 3:15 AM, zhang.fei3@zte.com.cn wrote: > >> Just one comment about the citations. >> >> As described in section 3.1, the Association ID and Association Source >> is the same as defined in RFC4872. >> >> And according to the description in section 16.1 of RFC4872, cited here >> >> " Association ID: 16 bits >> A value assigned by the LSP head-end. When combined with the >> Association Type and Association Source, this value uniquely >> identifies an association." >> >> >> " Association Source: 4 or 16 bytes >> An IPv4 or IPv6 address, respectively, that is associated to >> the node that originated the association." >> >> >> >> (1) When the association object is used for the co-routed bidirectional >> LSP, the tunnel ID locally assigned at Z9 node maybe be filled here, >> however, >> it is not assigned by the LSP head-end (A1 node), or we can interpret >> that Z9 is also the LSP head-end? >> >> > The intent was that "the association ID is selected by the node creating > the association object". This should be explicitly stated by the draft. > This is an important clarification and will result in a few tweaks to > the current document. > > Good catch. > > >> (2) Another usecase is that for the associated bidirectional LSP, this >> field maybe be filled by the the tunnel ID of the forward LSP1 or the >> backward LSP2. If it is the tunnel ID of LSP1, which is not assigned by >> the LSP2 head-end. >> > Agreed. I think the above revision will accommodate this. > > >> (3)Similarly as above, the association source maybe be related to A1 or >> Z9 node, and both of them are the nodes that originate the association >> when double sided provisionging mode is used. >> > same response... > > >> (3)In the general scenarios, the combination of Association Type, >> Association Source, Global Association Source and extended Association >> id will identify >> an association. >> > I'm not clear on your comment here. Does this relate to specific text? > Are you looking for a change in the draft? Please clarify. > > >> Just my2cents, the descriptions about the association source and id are >> accurate under the scope of RFC4872, but the direct citation from >> RFC4872 is not accurate here if we consider the more usecases. >> > I think we're in agreement. > > >> Can the >> limitation be released or these words be organized in another way? >> > Yes, will revise as part of the post-LC revision. > > Thanks, > Lou > >> >> >> >> Best regards >> >> Fei >> >> >> *"BRUNGARD, DEBORAH A" * >> 发件人: ccamp-bounces@ietf.org >> >> 2012-02-24 06:12 >> >> >> 收件人 >> CCAMP >> 抄送 >> >> 主题 >> [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext >> >> >> >> >> >> >> >> >> All, >> >> This starts a two-week working group last call on >> draft-ietf-ccamp-assoc-ext. >> >> This working group last call ends March 8th. Please send your comments >> to the CCAMP mailing list. >> >> Deborah (and Lou) >> >> >> >> >> _______________________________________________ >> 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 Rajiv.Papneja@huawei.com Sun Feb 26 05:42:57 2012 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 2D1ED21F860B for ; Sun, 26 Feb 2012 05:42:57 -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 7GJvNY2Dfa83 for ; Sun, 26 Feb 2012 05:42:56 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C73221F848F for ; Sun, 26 Feb 2012 05:42:55 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ADP16530; Sun, 26 Feb 2012 08:42:55 -0500 (EST) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 26 Feb 2012 05:42:36 -0800 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.249]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Sun, 26 Feb 2012 21:42:27 +0800 From: Rajiv Papneja To: Lou Berger , "sun.weiqiang@gmail.com" , "zhangguoying@mail.ritt.com.cn" , "Gaojianhua(A)" , "xieg@cs.ucr.edu" , "BGu@ixiacom.com" , "xqwei@fiberhome.com.cn" , "tm-otani@kddi.com" , "jingrq@ctbri.com.cn" Thread-Topic: Regarding IPR on draft-ietf-ccamp-dpm Thread-Index: AQHM8L+3gEb7v+WmBkCzDQeKXDdHg5ZPNs3g Date: Sun, 26 Feb 2012 13:42:26 +0000 Message-ID: <52B0D42F4BADB144B850705C4549F6EA017C2F6D@dfweml511-mbx.china.huawei.com> References: <4F43D6B2.9000501@labn.net> In-Reply-To: <4F43D6B2.9000501@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.148.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: CCAMP , CCAMP ADs Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-dpm 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, 26 Feb 2012 13:42:57 -0000 Hi Lou, I'm not aware of any IPR that applies to this draft. Regards, -Rajiv -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, February 21, 2012 12:39 PM To: sun.weiqiang@gmail.com; zhangguoying@mail.ritt.com.cn; Gaojianhua(A); x= ieg@cs.ucr.edu; Rajiv Papneja; BGu@ixiacom.com; xqwei@fiberhome.com.cn; tm-= otani@kddi.com; jingrq@ctbri.com.cn Cc: CCAMP; CCAMP ADs Subject: Regarding IPR on draft-ietf-ccamp-dpm Authors, Contributors, (CCAMP) In preparation of this document for WG Last Call: Are you aware of any IPR that applies to draft-ietf-ccamp-dpm? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL 9 OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs From zhang.fei3@zte.com.cn Sun Feb 26 17:20:40 2012 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 15C2F21F850D for ; Sun, 26 Feb 2012 17:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.568 X-Spam-Level: X-Spam-Status: No, score=-96.568 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_50=0.001, 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 Zve+GaCMhxl8 for ; Sun, 26 Feb 2012 17:20:38 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB3021F8508 for ; Sun, 26 Feb 2012 17:20:37 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 52373473195744; Mon, 27 Feb 2012 09:14:17 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 35739.3730950899; Mon, 27 Feb 2012 09:20:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1R1KIgo081009; Mon, 27 Feb 2012 09:20:18 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4F47D91E.5090109@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: A86EF914:CEE92C03-482579B1:00045994; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 27 Feb 2012 09:20:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-27 09:20:19, Serialize complete at 2012-02-27 09:20:19 Content-Type: multipart/alternative; boundary="=_alternative 00075800482579B1_=" X-MAIL: mse01.zte.com.cn q1R1KIgo081009 Cc: CCAMP , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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: Mon, 27 Feb 2012 01:20:40 -0000 This is a multipart message in MIME format. --=_alternative 00075800482579B1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91IA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UgaW1tZWRpYXRlbHksIGFuZCBJIHRoaW5r IHRoYXQgdGhlIHJldmlzZWQgDQpzZW50ZW5jZSAiQSB2YWx1ZSBhc3NpZ25lZCBieSB0aGUgdGhl IG5vZGUgdGhhdCBvcmlnaW5hdGVkIHRoZSBhc3NvY2lhdGlvbg0KIiByZWZsZWN0cyBteSBjb21t ZW50cyBwcmVjaXNlbHkuDQoNCkFjY29yZGluZyB0byB0aGUgc2VjdGlvbiAzLjEgb2YgdGhlIGRy YWZ0IGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0LCB0aGUgDQpFeHRlbmRlZCBBc3NvY2lhaXRv biBvYmplY3QgaXMgZGVmaW5lZCBieSBhZGRpbmcgdHdvIGZpZWxkcyBpbiB0aGUgb2xkIA0KQXNz b2NpYXRpb24gDQpvYmplY3QsIG9uZSBpcyB0aGUgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSBh bmQgdGhlIG90aGVyIGlzIHRoZSBFeHRlbmRlZCANCkFzc29jaWF0aW9uIElELiBJbiBzb21lIGNh c2VzLCBmb3IgZXhhbXBsZSwgbGlrZSBhbiBMU1AgYWNyb3NzIGRpZmZlcmVudCANCkFTcywgb3Ig DQp0aGUgQXNzb2NpYXRpb24gSUQgZmllbGQgaXMgaW5zdWZmaWNpZW50LCB0aGUgYXNzb2NpYXRp b24gaXMgdW5pcXVseSANCmlkZW50aWZpZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mIEFzc29jaWF0 aW9uIFR5cGWhokFzc29jaWF0aW9uIFNvdXJjZaGiDQpHbG9iYWwgQXNzb2NpYXRpb24NClNvdXJj ZSBhbmQgRXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQuIE9mIGNvdXJjZSwgdGhlIEdsb2JhbCBBc3Nv Y2lhdGlvbiANClNvdXJjZSBtYXliZSBiZSBzZXQgdG8gemVybywgb3IgdGhlIGxlbmd0aCBvZiB0 aGUgRXh0ZW5kZWQgQXNzb2NpYXRpb24gDQpmaWVsZCBpcyB6ZXJvLg0KDQpTbyBhcyB0byB0aGUg c2Vjb25kIHJldmlzZWQgc2VudGVuY2UgdGhhdCAiV2hlbiBjb21iaW5lZCB3aXRoIHRoZSANCkFz c29jaWF0aW9uIFR5cGUgYW5kIEFzc29jaWF0aW9uIFNvdXJjZSwgdGhpcyB2YWx1ZSB1bmlxdWVs eSBpZGVudGlmaWVzIGFuIA0KYXNzb2NpYXRpb24iLCB3aGljaA0KbWF5IGxldCB0aGUgcmVhZGVy cyB0aGluayB0aGF0IHRoZSBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGFuZCB0aGUgdGhlIA0K RXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQgYXJlIG5vdCB1c2VkIHRvIGlkZW50aWZ5IGFuIGFzc29j aWF0aW9uIHVuaXF1bHkuDQoNCldoYXQgYWJvdXQgdGhlIHJldmlzaW9uIGxpa2UgIldoZW4gY29t YmluZWQgd2l0aCB0aGUgQXNzb2NpYXRpb24gVHlwZaGiDQpBc3NvY2lhdGlvbiBTb3VyY2Whokds b2JhbCBBc3NvY2lhdGlvbiBTb3VyY2UgYW5kIEV4dGVuZGVkIEFzc29jaWF0aW9uIElELCANCnRo aXMgdmFsdWUgdW5pcXVlbHkgaWRlbnRpZmllcyBhbiBhc3NvY2lhdGlvbiIgb3IgaW4gb3RoZXIg d2F5IGlmIHlvdSANCnRoaW5rIHRoZSBjbGFyaWZpY2F0aW9uIGlzIHVzZWZ1bD8NCg0KQmVzdA0K DQpGZWkNCg0KDQoNCkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IA0KMjAxMi0wMi0yNSAw MjozOA0KDQrK1bz+yMsNCnpoYW5nLmZlaTNAenRlLmNvbS5jbg0Ks63LzQ0KImRyYWZ0LWlldGYt Y2NhbXAtYXNzb2MtZXh0QHRvb2xzLmlldGYub3JnIiANCjxkcmFmdC1pZXRmLWNjYW1wLWFzc29j LWV4dEB0b29scy5pZXRmLm9yZz4sICJCUlVOR0FSRCwgREVCT1JBSCBBIiANCjxkYjM1NDZAYXR0 LmNvbT4sIENDQU1QIDxjY2FtcEBpZXRmLm9yZz4NCtb3zOINClJlOiBbQ0NBTVBdIFdHIExhc3Qg Q2FsbCBvbiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dA0KDQoNCg0KDQoNCg0KRmVpL0FsbCwN CkkgcHJvcG9zZSB0byBhZGRyZXNzIHRoZSBGZWkncyBjb21tZW50cyBieSBhZGRpbmcgdGhlIGZv bGxvd2luZyBuZXcNCnNlY3Rpb24gdG8gdGhlIGRvY3VtZW50LiAoYXMgd2VsbCBhcyBzb21lIG90 aGVyIHJlbGF0ZWQgZWRpdG9yaWFsIA0KY2hhbmdlcy4pDQoNCjIuIE1vZGlmaWVkIEFzc29jaWF0 aW9uIElEIEZpZWxkIERlZmluaXRpb24NCg0KVGhlIEFzc29jaWF0aW9uIElEIGZpZWxkIGlzIGNh cnJpZWQgaW4gdGhlIElQdjQgYW5kIElQdjYgQVNTT0NJQVRJT04NCm9iamVjdHMgZGVmaW5lZCBp biBbUkZDNDg3Ml0uIFRoZSBbUkZDNDg3Ml0gZGVmaW5pdGlvbiBvZiB0aGUgZmllbGQNCnJlYWRz Og0KDQpBIHZhbHVlIGFzc2lnbmVkIGJ5IHRoZSBMU1AgaGVhZC1lbmQuIFdoZW4gY29tYmluZWQg d2l0aCB0aGUNCkFzc29jaWF0aW9uIFR5cGUgYW5kIEFzc29jaWF0aW9uIFNvdXJjZSwgdGhpcyB2 YWx1ZSB1bmlxdWVseQ0KaWRlbnRpZmllcyBhbiBhc3NvY2lhdGlvbi4NCg0KVGhpcyBkb2N1bWVu dCBhbGxvd3MgZm9yIHRoZSBvcmlnaW5hdGlvbiBvZiBBU1NPQ0lBVElPTiBvYmplY3RzIGJ5DQpu b2RlcyBvdGhlciB0aGFuICJ0aGUgTFNQIGhlYWQtZW5kIi4gQXMgc3VjaCwgdGhlIGRlZmluaXRp b24gb2YgdGhlDQpBc3NvY2lhdGlvbiBJRCBmaWVsZCBuZWVkcyB0byBiZSBtb2RpZmllZCB0byBh Y2NvbW1vZGF0ZSBzdWNoIHVzYWdlLg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBBc3NvY2lh dGlvbiBJRCBmaWVsZCBvZiB0aGUgSVB2NCBhbmQgSVB2Ng0KQVNTT0NJQVRJT04gb2JqZWN0cyBh czoNCg0KQSB2YWx1ZSBhc3NpZ25lZCBieSB0aGUgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVkIHRo ZSBhc3NvY2lhdGlvbi4NCldoZW4gY29tYmluZWQgd2l0aCB0aGUgQXNzb2NpYXRpb24gVHlwZSBh bmQgQXNzb2NpYXRpb24gU291cmNlLA0KdGhpcyB2YWx1ZSB1bmlxdWVseSBpZGVudGlmaWVzIGFu IGFzc29jaWF0aW9uLg0KDQpUaGlzIGNoYW5nZSBpbiBkZWZpbml0aW9uIGRvZXMgbm90IGltcGFj dCBbUkZDNDg3Ml0gb3IgW1JGQzQ4NzNdDQpkZWZpbmVkIHByb2NlZHVyZXMgb3IgbWVjaGFuaXNt cywgbm9yIGRvZXMgaXQgaW1wYWN0IGV4aXN0aW5nDQppbXBsZW1lbnRhdGlvbnMgb2YgW1JGQzQ4 NzJdIG9yIFtSRkM0ODczXS4NCg0KSSBiZWxpZXZlIHRoaXMgYWRkcmVzc2VzIHRoZSBjb21tZW50 LiBMZXQgbWUga25vdyBpZiB5b3UgZGlzYWdyZWUsIG9yDQpoYXZlIG90aGVyIGNvbW1lbnRzLg0K DQpNdWNoIHRoYW5rcywNCkxvdSAoZHJhZnQgY28tYXV0aG9yKQ0KDQpPbiAyLzI0LzIwMTIgMTI6 NTMgUE0sIExvdSBCZXJnZXIgd3JvdGU6DQo+IEZlaSwNCj4gICAgICAgICAgICAgICAgc2VlIGJl bG93IGZvciBpbi1saW5lIHJlc3BvbnNlcy4NCj4NCj4gT24gMi8yNC8yMDEyIDM6MTUgQU0sIHpo YW5nLmZlaTNAenRlLmNvbS5jbiB3cm90ZToNCj4gDQo+PiBKdXN0IG9uZSBjb21tZW50IGFib3V0 IHRoZSBjaXRhdGlvbnMuDQo+Pg0KPj4gQXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4xLCB0aGUg QXNzb2NpYXRpb24gSUQgYW5kIEFzc29jaWF0aW9uIFNvdXJjZQ0KPj4gaXMgdGhlIHNhbWUgYXMg ZGVmaW5lZCBpbiBSRkM0ODcyLg0KPj4NCj4+IEFuZCBhY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0 aW9uIGluIHNlY3Rpb24gMTYuMSBvZiBSRkM0ODcyLCBjaXRlZCBoZXJlDQo+Pg0KPj4gIiBBc3Nv Y2lhdGlvbiBJRDogMTYgYml0cw0KPj4gICAgICAgICBBIHZhbHVlIGFzc2lnbmVkIGJ5IHRoZSBM U1AgaGVhZC1lbmQuICBXaGVuIGNvbWJpbmVkIHdpdGggdGhlDQo+PiAgICAgICAgIEFzc29jaWF0 aW9uIFR5cGUgYW5kIEFzc29jaWF0aW9uIFNvdXJjZSwgdGhpcyB2YWx1ZSB1bmlxdWVseQ0KPj4g ICAgICAgICBpZGVudGlmaWVzIGFuIGFzc29jaWF0aW9uLiINCj4+DQo+Pg0KPj4gIiBBc3NvY2lh dGlvbiBTb3VyY2U6IDQgb3IgMTYgYnl0ZXMNCj4+ICAgICAgICAgQW4gSVB2NCBvciBJUHY2IGFk ZHJlc3MsIHJlc3BlY3RpdmVseSwgdGhhdCBpcyBhc3NvY2lhdGVkIHRvDQo+PiAgICAgICAgIHRo ZSBub2RlIHRoYXQgb3JpZ2luYXRlZCB0aGUgYXNzb2NpYXRpb24uIg0KPj4NCj4+IDxmZWk+DQo+ Pg0KPj4gKDEpIFdoZW4gdGhlIGFzc29jaWF0aW9uIG9iamVjdCBpcyB1c2VkIGZvciB0aGUgY28t cm91dGVkIGJpZGlyZWN0aW9uYWwNCj4+IExTUCwgdGhlIHR1bm5lbCBJRCBsb2NhbGx5IGFzc2ln bmVkIGF0IFo5IG5vZGUgbWF5YmUgYmUgZmlsbGVkIGhlcmUsDQo+PiBob3dldmVyLA0KPj4gaXQg aXMgbm90IGFzc2lnbmVkIGJ5IHRoZSBMU1AgaGVhZC1lbmQgKEExIG5vZGUpLCBvciB3ZSBjYW4g aW50ZXJwcmV0DQo+PiB0aGF0IFo5IGlzIGFsc28gdGhlIExTUCBoZWFkLWVuZD8NCj4+DQo+PiAN Cj4gVGhlIGludGVudCB3YXMgdGhhdCAidGhlIGFzc29jaWF0aW9uIElEIGlzIHNlbGVjdGVkIGJ5 IHRoZSBub2RlIGNyZWF0aW5nDQo+IHRoZSBhc3NvY2lhdGlvbiBvYmplY3QiLiAgVGhpcyBzaG91 bGQgYmUgZXhwbGljaXRseSBzdGF0ZWQgYnkgdGhlIGRyYWZ0Lg0KPiAgVGhpcyBpcyBhbiBpbXBv cnRhbnQgY2xhcmlmaWNhdGlvbiBhbmQgd2lsbCByZXN1bHQgaW4gYSBmZXcgdHdlYWtzIHRvDQo+ IHRoZSBjdXJyZW50IGRvY3VtZW50Lg0KPg0KPiBHb29kIGNhdGNoLg0KPg0KPiANCj4+ICgyKSBB bm90aGVyIHVzZWNhc2UgaXMgdGhhdCBmb3IgdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1AsIHRoaXMNCj4+IGZpZWxkIG1heWJlIGJlIGZpbGxlZCBieSB0aGUgdGhlIHR1bm5lbCBJRCBv ZiB0aGUgZm9yd2FyZCBMU1AxIG9yIHRoZQ0KPj4gYmFja3dhcmQgTFNQMi4gSWYgaXQgaXMgdGhl IHR1bm5lbCBJRCBvZiBMU1AxLCB3aGljaCBpcyBub3QgYXNzaWduZWQgYnkNCj4+IHRoZSBMU1Ay IGhlYWQtZW5kLg0KPj4gDQo+IEFncmVlZC4gIEkgdGhpbmsgdGhlIGFib3ZlIHJldmlzaW9uIHdp bGwgYWNjb21tb2RhdGUgdGhpcy4NCj4NCj4gDQo+PiAoMylTaW1pbGFybHkgYXMgYWJvdmUsIHRo ZSBhc3NvY2lhdGlvbiBzb3VyY2UgbWF5YmUgYmUgcmVsYXRlZCB0byBBMSBvcg0KPj4gWjkgbm9k ZSwgYW5kIGJvdGggb2YgdGhlbSBhcmUgdGhlIG5vZGVzIHRoYXQgb3JpZ2luYXRlIHRoZSBhc3Nv Y2lhdGlvbg0KPj4gd2hlbiBkb3VibGUgc2lkZWQgcHJvdmlzaW9uZ2luZyBtb2RlIGlzIHVzZWQu DQo+PiANCj4gc2FtZSByZXNwb25zZS4uLg0KPg0KPiANCj4+ICgzKUluIHRoZSBnZW5lcmFsIHNj ZW5hcmlvcywgdGhlIGNvbWJpbmF0aW9uIG9mIEFzc29jaWF0aW9uIFR5cGUsDQo+PiBBc3NvY2lh dGlvbiBTb3VyY2UsIEdsb2JhbCBBc3NvY2lhdGlvbiBTb3VyY2UgYW5kIGV4dGVuZGVkIEFzc29j aWF0aW9uDQo+PiBpZCB3aWxsIGlkZW50aWZ5DQo+PiBhbiBhc3NvY2lhdGlvbi4NCj4+IA0KPiBJ J20gbm90IGNsZWFyIG9uIHlvdXIgY29tbWVudCBoZXJlLiAgRG9lcyB0aGlzIHJlbGF0ZSB0byBz cGVjaWZpYyB0ZXh0Pw0KPiAgQXJlIHlvdSBsb29raW5nIGZvciBhIGNoYW5nZSBpbiB0aGUgZHJh ZnQ/ICBQbGVhc2UgY2xhcmlmeS4NCj4NCj4gDQo+PiBKdXN0IG15MmNlbnRzLCB0aGUgZGVzY3Jp cHRpb25zIGFib3V0IHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UgYW5kIGlkIGFyZQ0KPj4gYWNjdXJh dGUgdW5kZXIgdGhlIHNjb3BlIG9mIFJGQzQ4NzIsIGJ1dCB0aGUgZGlyZWN0IGNpdGF0aW9uIGZy b20NCj4+IFJGQzQ4NzIgaXMgbm90IGFjY3VyYXRlIGhlcmUgaWYgd2UgY29uc2lkZXIgdGhlIG1v cmUgdXNlY2FzZXMuIA0KPj4gDQo+IEkgdGhpbmsgd2UncmUgaW4gYWdyZWVtZW50Lg0KPg0KPiAN Cj4+IENhbiB0aGUNCj4+IGxpbWl0YXRpb24gYmUgcmVsZWFzZWQgb3IgdGhlc2Ugd29yZHMgYmUg b3JnYW5pemVkIGluIGFub3RoZXIgd2F5Pw0KPj4gDQo+IFllcywgd2lsbCByZXZpc2UgYXMgcGFy dCBvZiB0aGUgcG9zdC1MQyByZXZpc2lvbi4NCj4NCj4gVGhhbmtzLA0KPiBMb3UNCj4gDQo+PiA8 L2ZlaT4NCj4+DQo+Pg0KPj4gQmVzdCByZWdhcmRzDQo+Pg0KPj4gRmVpDQo+Pg0KPj4NCj4+ICoi QlJVTkdBUkQsIERFQk9SQUggQSIgPGRiMzU0NkBhdHQuY29tPioNCj4+ILeivP7IyzogIGNjYW1w LWJvdW5jZXNAaWV0Zi5vcmcNCj4+DQo+PiAyMDEyLTAyLTI0IDA2OjEyDQo+Pg0KPj4gDQo+PiDK 1bz+yMsNCj4+ICAgICAgICAgICAgICAgQ0NBTVAgPGNjYW1wQGlldGYub3JnPg0KPj4gs63LzQ0K Pj4gDQo+PiDW98ziDQo+PiAgICAgICAgICAgICAgIFtDQ0FNUF0gV0cgTGFzdCBDYWxsIG9uIGRy YWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0DQo+Pg0KPj4NCj4+IA0KPj4NCj4+DQo+Pg0KPj4NCj4+ DQo+PiBBbGwsDQo+Pg0KPj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxh c3QgY2FsbCBvbg0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1hc3NvYy1leHQuDQo+Pg0KPj4gVGhpcyB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBlbmRzIE1hcmNoIDh0aC4gUGxlYXNlIHNlbmQgeW91ciBj b21tZW50cw0KPj4gdG8gdGhlIENDQU1QIG1haWxpbmcgbGlzdC4NCj4+DQo+PiBEZWJvcmFoIChh bmQgTG91KQ0KPj4NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+IENDQU1QQGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+Pg0K Pj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4gQ0NBTVBAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+IA0KDQoNCg0K --=_alternative 00075800482579B1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdSA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciByZXNwb25z ZSBpbW1lZGlhdGVseSwNCmFuZCBJIHRoaW5rIHRoYXQgdGhlIHJldmlzZWQgc2VudGVuY2UgJnF1 b3Q7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+QSB2YWx1ZQ0KYXNzaWduZWQgYnkgdGhlIHRoZSBu b2RlIHRoYXQgb3JpZ2luYXRlZCB0aGUgYXNzb2NpYXRpb248L2ZvbnQ+PC90dD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7DQpyZWZsZWN0cyBteSBjb21tZW50cyBwcmVjaXNl bHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BY2Nv cmRpbmcgdG8gdGhlIHNlY3Rpb24gMy4xIG9mIHRoZQ0KZHJhZnQgZHJhZnQtaWV0Zi1jY2FtcC1h c3NvYy1leHQsIHRoZSBFeHRlbmRlZCBBc3NvY2lhaXRvbiBvYmplY3QgaXMgZGVmaW5lZA0KYnkg YWRkaW5nIHR3byBmaWVsZHMgaW4gdGhlIG9sZCBBc3NvY2lhdGlvbiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm9iamVjdCwgb25lIGlzIHRoZSBHbG9iYWwgQXNz b2NpYXRpb24NClNvdXJjZSBhbmQgdGhlIG90aGVyIGlzIHRoZSBFeHRlbmRlZCBBc3NvY2lhdGlv biBJRC4gSW4gc29tZSBjYXNlcywgZm9yDQpleGFtcGxlLCBsaWtlIGFuIExTUCBhY3Jvc3MgZGlm ZmVyZW50IEFTcywgb3IgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij50aGUgQXNzb2NpYXRpb24gSUQgZmllbGQgaXMgaW5zdWZmaWNpZW50LA0KdGhlIGFzc29jaWF0 aW9uIGlzIHVuaXF1bHkgaWRlbnRpZmllZCBieSB0aGUgY29tYmluYXRpb24gb2YgQXNzb2NpYXRp b24NClR5cGWhokFzc29jaWF0aW9uIFNvdXJjZaGiR2xvYmFsIEFzc29jaWF0aW9uPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Tb3VyY2UgYW5kIEV4dGVuZGVkIEFz c29jaWF0aW9uIElELg0KT2YgY291cmNlLCB0aGUgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSBt YXliZSBiZSBzZXQgdG8gemVybywgb3IgdGhlIGxlbmd0aA0Kb2YgdGhlIEV4dGVuZGVkIEFzc29j aWF0aW9uIGZpZWxkIGlzIHplcm8uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5TbyBhcyB0byB0aGUgc2Vjb25kIHJldmlzZWQgc2VudGVuY2UNCnRoYXQg JnF1b3Q7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+V2hlbiBjb21iaW5lZCB3aXRoIHRoZSBBc3Nv Y2lhdGlvbiBUeXBlDQphbmQgQXNzb2NpYXRpb24gU291cmNlLCB0aGlzIHZhbHVlIHVuaXF1ZWx5 IGlkZW50aWZpZXMgYW4gYXNzb2NpYXRpb248L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7LA0Kd2hpY2g8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPm1heSBsZXQgdGhlIHJlYWRlcnMgdGhpbmsgdGhhdCB0aGUgR2xvYmFsDQpB c3NvY2lhdGlvbiBTb3VyY2UgYW5kIHRoZSB0aGUgRXh0ZW5kZWQgQXNzb2NpYXRpb24gSUQgYXJl IG5vdCB1c2VkIHRvDQppZGVudGlmeSBhbiBhc3NvY2lhdGlvbiB1bmlxdWx5LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2hhdCBhYm91dCB0aGUgcmV2 aXNpb24gbGlrZSAmcXVvdDs8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj5XaGVuDQpjb21iaW5lZCB3 aXRoIHRoZSBBc3NvY2lhdGlvbiBUeXBloaJBc3NvY2lhdGlvbiBTb3VyY2WhojwvZm9udD48L3R0 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HbG9iYWwNCkFzc29jaWF0aW9uIFNvdXJj ZTwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPiBhbmQgPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkV4dGVuZGVkDQpBc3NvY2lhdGlvbiBJRDwvZm9udD48dHQ+PGZvbnQg c2l6ZT0yPiwgdGhpcyB2YWx1ZSB1bmlxdWVseSBpZGVudGlmaWVzDQphbiBhc3NvY2lhdGlvbjwv Zm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsgb3IgaW4gb3Ro ZXINCndheSBpZiB5b3UgdGhpbmsgdGhlIGNsYXJpZmljYXRpb24gaXMgdXNlZnVsPzwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkxvdSBCZXJnZXIgJmx0O2xi ZXJnZXJAbGFibi5uZXQmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTItMDItMjUgMDI6Mzg8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhhbmcuZmVpM0B6dGUuY29tLmNuPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4mcXVvdDtkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dEB0b29scy5pZXRmLm9y ZyZxdW90Ow0KJmx0O2RyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0QHRvb2xzLmlldGYub3JnJmd0 OywgJnF1b3Q7QlJVTkdBUkQsIERFQk9SQUgNCkEmcXVvdDsgJmx0O2RiMzU0NkBhdHQuY29tJmd0 OywgQ0NBTVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtD Q0FNUF0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0PC9mb250Pjwv dGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxl Pg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5GZWkvQWxs LDxicj4NCkkgcHJvcG9zZSB0byBhZGRyZXNzIHRoZSBGZWkncyBjb21tZW50cyBieSBhZGRpbmcg dGhlIGZvbGxvd2luZyBuZXc8YnI+DQpzZWN0aW9uIHRvIHRoZSBkb2N1bWVudC4gKGFzIHdlbGwg YXMgc29tZSBvdGhlciByZWxhdGVkIGVkaXRvcmlhbCBjaGFuZ2VzLik8YnI+DQo8YnI+DQoyLiBN b2RpZmllZCBBc3NvY2lhdGlvbiBJRCBGaWVsZCBEZWZpbml0aW9uPGJyPg0KPGJyPg0KVGhlIEFz c29jaWF0aW9uIElEIGZpZWxkIGlzIGNhcnJpZWQgaW4gdGhlIElQdjQgYW5kIElQdjYgQVNTT0NJ QVRJT048YnI+DQpvYmplY3RzIGRlZmluZWQgaW4gW1JGQzQ4NzJdLiBUaGUgW1JGQzQ4NzJdIGRl ZmluaXRpb24gb2YgdGhlIGZpZWxkPGJyPg0KcmVhZHM6PGJyPg0KPGJyPg0KQSB2YWx1ZSBhc3Np Z25lZCBieSB0aGUgTFNQIGhlYWQtZW5kLiBXaGVuIGNvbWJpbmVkIHdpdGggdGhlPGJyPg0KQXNz b2NpYXRpb24gVHlwZSBhbmQgQXNzb2NpYXRpb24gU291cmNlLCB0aGlzIHZhbHVlIHVuaXF1ZWx5 PGJyPg0KaWRlbnRpZmllcyBhbiBhc3NvY2lhdGlvbi48YnI+DQo8YnI+DQpUaGlzIGRvY3VtZW50 IGFsbG93cyBmb3IgdGhlIG9yaWdpbmF0aW9uIG9mIEFTU09DSUFUSU9OIG9iamVjdHMgYnk8YnI+ DQpub2RlcyBvdGhlciB0aGFuICZxdW90O3RoZSBMU1AgaGVhZC1lbmQmcXVvdDsuIEFzIHN1Y2gs IHRoZSBkZWZpbml0aW9uDQpvZiB0aGU8YnI+DQpBc3NvY2lhdGlvbiBJRCBmaWVsZCBuZWVkcyB0 byBiZSBtb2RpZmllZCB0byBhY2NvbW1vZGF0ZSBzdWNoIHVzYWdlLjxicj4NClRoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgQXNzb2NpYXRpb24gSUQgZmllbGQgb2YgdGhlIElQdjQgYW5kIElQdjY8 YnI+DQpBU1NPQ0lBVElPTiBvYmplY3RzIGFzOjxicj4NCjxicj4NCkEgdmFsdWUgYXNzaWduZWQg YnkgdGhlIHRoZSBub2RlIHRoYXQgb3JpZ2luYXRlZCB0aGUgYXNzb2NpYXRpb24uPGJyPg0KV2hl biBjb21iaW5lZCB3aXRoIHRoZSBBc3NvY2lhdGlvbiBUeXBlIGFuZCBBc3NvY2lhdGlvbiBTb3Vy Y2UsPGJyPg0KdGhpcyB2YWx1ZSB1bmlxdWVseSBpZGVudGlmaWVzIGFuIGFzc29jaWF0aW9uLjxi cj4NCjxicj4NClRoaXMgY2hhbmdlIGluIGRlZmluaXRpb24gZG9lcyBub3QgaW1wYWN0IFtSRkM0 ODcyXSBvciBbUkZDNDg3M108YnI+DQpkZWZpbmVkIHByb2NlZHVyZXMgb3IgbWVjaGFuaXNtcywg bm9yIGRvZXMgaXQgaW1wYWN0IGV4aXN0aW5nPGJyPg0KaW1wbGVtZW50YXRpb25zIG9mIFtSRkM0 ODcyXSBvciBbUkZDNDg3M10uPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoaXMgYWRkcmVzc2VzIHRo ZSBjb21tZW50LiBMZXQgbWUga25vdyBpZiB5b3UgZGlzYWdyZWUsIG9yPGJyPg0KaGF2ZSBvdGhl ciBjb21tZW50cy48YnI+DQo8YnI+DQpNdWNoIHRoYW5rcyw8YnI+DQpMb3UgKGRyYWZ0IGNvLWF1 dGhvcik8YnI+DQo8YnI+DQpPbiAyLzI0LzIwMTIgMTI6NTMgUE0sIExvdSBCZXJnZXIgd3JvdGU6 PGJyPg0KJmd0OyBGZWksPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlZQ0KYmVsb3cgZm9yIGluLWxpbmUgcmVz cG9uc2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDIvMjQvMjAxMiAzOjE1IEFNLCB6aGFuZy5m ZWkzQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyZndDsgSnVz dCBvbmUgY29tbWVudCBhYm91dCB0aGUgY2l0YXRpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgQXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMy4xLCB0aGUgQXNzb2NpYXRpb24gSUQgYW5k IEFzc29jaWF0aW9uDQpTb3VyY2U8YnI+DQomZ3Q7Jmd0OyBpcyB0aGUgc2FtZSBhcyBkZWZpbmVk IGluIFJGQzQ4NzIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbmQgYWNjb3JkaW5nIHRv IHRoZSBkZXNjcmlwdGlvbiBpbiBzZWN0aW9uIDE2LjEgb2YgUkZDNDg3MiwgY2l0ZWQNCmhlcmU8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZxdW90OyBBc3NvY2lhdGlvbiBJRDogMTYgYml0 czxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBIHZhbHVlIGFzc2ln bmVkIGJ5IHRoZSBMU1AgaGVhZC1lbmQuDQombmJzcDtXaGVuIGNvbWJpbmVkIHdpdGggdGhlPGJy Pg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFzc29jaWF0aW9uIFR5cGUg YW5kIEFzc29jaWF0aW9uIFNvdXJjZSwNCnRoaXMgdmFsdWUgdW5pcXVlbHk8YnI+DQomZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaWRlbnRpZmllcyBhbiBhc3NvY2lhdGlvbi4m cXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJnF1b3Q7IEFz c29jaWF0aW9uIFNvdXJjZTogNCBvciAxNiBieXRlczxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBBbiBJUHY0IG9yIElQdjYgYWRkcmVzcywgcmVzcGVjdGl2ZWx5LA0K dGhhdCBpcyBhc3NvY2lhdGVkIHRvPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHRoZSBub2RlIHRoYXQgb3JpZ2luYXRlZCB0aGUgYXNzb2NpYXRpb24uJnF1b3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbHQ7ZmVpJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgKDEpIFdoZW4gdGhlIGFzc29jaWF0aW9uIG9iamVjdCBpcyB1c2VkIGZvciB0aGUg Y28tcm91dGVkIGJpZGlyZWN0aW9uYWw8YnI+DQomZ3Q7Jmd0OyBMU1AsIHRoZSB0dW5uZWwgSUQg bG9jYWxseSBhc3NpZ25lZCBhdCBaOSBub2RlIG1heWJlIGJlIGZpbGxlZA0KaGVyZSw8YnI+DQom Z3Q7Jmd0OyBob3dldmVyLDxicj4NCiZndDsmZ3Q7IGl0IGlzIG5vdCBhc3NpZ25lZCBieSB0aGUg TFNQIGhlYWQtZW5kIChBMSBub2RlKSwgb3Igd2UgY2FuIGludGVycHJldDxicj4NCiZndDsmZ3Q7 IHRoYXQgWjkgaXMgYWxzbyB0aGUgTFNQIGhlYWQtZW5kPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7IFRoZSBpbnRlbnQgd2FzIHRoYXQgJnF1b3Q7 dGhlIGFzc29jaWF0aW9uIElEIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlDQpjcmVhdGluZzxicj4N CiZndDsgdGhlIGFzc29jaWF0aW9uIG9iamVjdCZxdW90Oy4gJm5ic3A7VGhpcyBzaG91bGQgYmUg ZXhwbGljaXRseSBzdGF0ZWQNCmJ5IHRoZSBkcmFmdC48YnI+DQomZ3Q7ICZuYnNwO1RoaXMgaXMg YW4gaW1wb3J0YW50IGNsYXJpZmljYXRpb24gYW5kIHdpbGwgcmVzdWx0IGluIGEgZmV3DQp0d2Vh a3MgdG88YnI+DQomZ3Q7IHRoZSBjdXJyZW50IGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IEdvb2QgY2F0Y2guPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsmZ3Q7ICgy KSBBbm90aGVyIHVzZWNhc2UgaXMgdGhhdCBmb3IgdGhlIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25h bCBMU1AsDQp0aGlzPGJyPg0KJmd0OyZndDsgZmllbGQgbWF5YmUgYmUgZmlsbGVkIGJ5IHRoZSB0 aGUgdHVubmVsIElEIG9mIHRoZSBmb3J3YXJkIExTUDENCm9yIHRoZTxicj4NCiZndDsmZ3Q7IGJh Y2t3YXJkIExTUDIuIElmIGl0IGlzIHRoZSB0dW5uZWwgSUQgb2YgTFNQMSwgd2hpY2ggaXMgbm90 IGFzc2lnbmVkDQpieTxicj4NCiZndDsmZ3Q7IHRoZSBMU1AyIGhlYWQtZW5kLjxicj4NCiZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyBBZ3JlZWQuICZuYnNwO0kgdGhpbmsgdGhlIGFi b3ZlIHJldmlzaW9uIHdpbGwgYWNjb21tb2RhdGUgdGhpcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAm bmJzcDsgPGJyPg0KJmd0OyZndDsgKDMpU2ltaWxhcmx5IGFzIGFib3ZlLCB0aGUgYXNzb2NpYXRp b24gc291cmNlIG1heWJlIGJlIHJlbGF0ZWQNCnRvIEExIG9yPGJyPg0KJmd0OyZndDsgWjkgbm9k ZSwgYW5kIGJvdGggb2YgdGhlbSBhcmUgdGhlIG5vZGVzIHRoYXQgb3JpZ2luYXRlIHRoZSBhc3Nv Y2lhdGlvbjxicj4NCiZndDsmZ3Q7IHdoZW4gZG91YmxlIHNpZGVkIHByb3Zpc2lvbmdpbmcgbW9k ZSBpcyB1c2VkLjxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyBzYW1lIHJl c3BvbnNlLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsmZ3Q7ICgzKUlu IHRoZSBnZW5lcmFsIHNjZW5hcmlvcywgdGhlIGNvbWJpbmF0aW9uIG9mIEFzc29jaWF0aW9uIFR5 cGUsPGJyPg0KJmd0OyZndDsgQXNzb2NpYXRpb24gU291cmNlLCBHbG9iYWwgQXNzb2NpYXRpb24g U291cmNlIGFuZCBleHRlbmRlZCBBc3NvY2lhdGlvbjxicj4NCiZndDsmZ3Q7IGlkIHdpbGwgaWRl bnRpZnk8YnI+DQomZ3Q7Jmd0OyBhbiBhc3NvY2lhdGlvbi48YnI+DQomZ3Q7Jmd0OyAmbmJzcDsg Jm5ic3A7IDxicj4NCiZndDsgSSdtIG5vdCBjbGVhciBvbiB5b3VyIGNvbW1lbnQgaGVyZS4gJm5i c3A7RG9lcyB0aGlzIHJlbGF0ZSB0byBzcGVjaWZpYw0KdGV4dD88YnI+DQomZ3Q7ICZuYnNwO0Fy ZSB5b3UgbG9va2luZyBmb3IgYSBjaGFuZ2UgaW4gdGhlIGRyYWZ0PyAmbmJzcDtQbGVhc2UgY2xh cmlmeS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyZndDsgSnVzdCBteTJj ZW50cywgdGhlIGRlc2NyaXB0aW9ucyBhYm91dCB0aGUgYXNzb2NpYXRpb24gc291cmNlIGFuZA0K aWQgYXJlPGJyPg0KJmd0OyZndDsgYWNjdXJhdGUgdW5kZXIgdGhlIHNjb3BlIG9mIFJGQzQ4NzIs IGJ1dCB0aGUgZGlyZWN0IGNpdGF0aW9uIGZyb208YnI+DQomZ3Q7Jmd0OyBSRkM0ODcyIGlzIG5v dCBhY2N1cmF0ZSBoZXJlIGlmIHdlIGNvbnNpZGVyIHRoZSBtb3JlIHVzZWNhc2VzLg0KPGJyPg0K Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7IEkgdGhpbmsgd2UncmUgaW4gYWdyZWVt ZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7Jmd0OyBDYW4gdGhlPGJy Pg0KJmd0OyZndDsgbGltaXRhdGlvbiBiZSByZWxlYXNlZCBvciB0aGVzZSB3b3JkcyBiZSBvcmdh bml6ZWQgaW4gYW5vdGhlcg0Kd2F5Pzxicj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgPGJyPg0K Jmd0OyBZZXMsIHdpbGwgcmV2aXNlIGFzIHBhcnQgb2YgdGhlIHBvc3QtTEMgcmV2aXNpb24uPGJy Pg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgTG91PGJyPg0KJmd0OyAmbmJzcDsg PGJyPg0KJmd0OyZndDsgJmx0Oy9mZWkmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEJlc3QgcmVnYXJkczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRmVp PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IComcXVvdDtCUlVOR0FS RCwgREVCT1JBSCBBJnF1b3Q7ICZsdDtkYjM1NDZAYXR0LmNvbSZndDsqPGJyPg0KJmd0OyZndDsg t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyAyMDEyLTAyLTI0IDA2OjEyPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDs8YnI+DQomZ3Q7Jmd0OyDK1bz+yMs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtDQ0FNUCAmbHQ7Y2Nh bXBAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyZndDsgs63LzTxicj4NCiZndDsmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzxi cj4NCiZndDsmZ3Q7INb3zOI8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtbQ0NBTVBdIFdHIExhc3QgQ2Fs bCBvbiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQWxsLDxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbjxicj4NCiZndDsmZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtYXNzb2Mt ZXh0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhpcyB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBlbmRzIE1hcmNoIDh0aC4gUGxlYXNlIHNlbmQgeW91cg0KY29tbWVudHM8YnI+DQomZ3Q7 Jmd0OyB0byB0aGUgQ0NBTVAgbWFpbGluZyBsaXN0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgRGVib3JhaCAoYW5kIExvdSk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgQ0NBTVAgbWFpbGluZyBsaXN0 PGJyPg0KJmd0OyZndDsgQ0NBTVBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IENDQU1QIG1h aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IENDQU1QQGlldGYub3JnPGJyPg0KJmd0OyZndDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsgPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 00075800482579B1_=-- From zhang.fei3@zte.com.cn Sun Feb 26 17:29:26 2012 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 3E0FB21F847C; Sun, 26 Feb 2012 17:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.475 X-Spam-Level: X-Spam-Status: No, score=-97.475 tagged_above=-999 required=5 tests=[AWL=0.160, 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 v4fSDWHEM4os; Sun, 26 Feb 2012 17:29: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 968C821F8474; Sun, 26 Feb 2012 17:29:24 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801461793122; Mon, 27 Feb 2012 08:59:03 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 73687.3687618379; Mon, 27 Feb 2012 09:29:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q1R1TBQg078863; Mon, 27 Feb 2012 09:29:11 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4F47CEB5.7060408@labn.net> To: Lou Berger MIME-Version: 1.0 X-KeepSent: F6888C43:367C5937-482579B1:00075DCC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 27 Feb 2012 09:29:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-27 09:29:13, Serialize complete at 2012-02-27 09:29:13 Content-Type: multipart/alternative; boundary="=_alternative 0008283F482579B1_=" X-MAIL: mse02.zte.com.cn q1R1TBQg078863 Cc: CCAMP , ccamp-bounces@ietf.org Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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: Mon, 27 Feb 2012 01:29:26 -0000 This is a multipart message in MIME format. --=_alternative 0008283F482579B1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TG91DQoNCg0KPiAoMylJbiB0aGUgZ2VuZXJhbCBzY2VuYXJpb3MsIHRoZSBjb21iaW5hdGlvbiBv ZiBBc3NvY2lhdGlvbiBUeXBlLA0KPiBBc3NvY2lhdGlvbiBTb3VyY2UsIEdsb2JhbCBBc3NvY2lh dGlvbiBTb3VyY2UgYW5kIGV4dGVuZGVkIEFzc29jaWF0aW9uDQo+IGlkIHdpbGwgaWRlbnRpZnkN Cj4gYW4gYXNzb2NpYXRpb24uDQoNCkknbSBub3QgY2xlYXIgb24geW91ciBjb21tZW50IGhlcmUu ICBEb2VzIHRoaXMgcmVsYXRlIHRvIHNwZWNpZmljIHRleHQ/DQogQXJlIHlvdSBsb29raW5nIGZv ciBhIGNoYW5nZSBpbiB0aGUgZHJhZnQ/ICBQbGVhc2UgY2xhcmlmeS4NCg0KPGZlaT4gU29ycnkg Zm9yIHRoZSB1bmNsZWFyIGRlc2NyaXB0aW9uLCBwbGVhc2UgY2hlY2sgbXkgcmVzcG9uc2UgaW4g DQphbm90aGVyIG1haWwgd2hpY2ggaXMgdGhlIHNhbWUuIDwvZmVpPg0KDQpCZXN0IA0KDQpGZWkN Cg0KDQoNCkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+IA0KMjAxMi0wMi0yNSAwMTo1Mw0K DQrK1bz+yMsNCnpoYW5nLmZlaTNAenRlLmNvbS5jbg0Ks63LzQ0KIkJSVU5HQVJELCBERUJPUkFI IEEiIDxkYjM1NDZAYXR0LmNvbT4sIENDQU1QIDxjY2FtcEBpZXRmLm9yZz4sIA0KY2NhbXAtYm91 bmNlc0BpZXRmLm9yZw0K1vfM4g0KUmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWll dGYtY2NhbXAtYXNzb2MtZXh0DQoNCg0KDQoNCg0KDQpGZWksDQogICAgICAgICAgICAgICAgIHNl ZSBiZWxvdyBmb3IgaW4tbGluZSByZXNwb25zZXMuDQoNCk9uIDIvMjQvMjAxMiAzOjE1IEFNLCB6 aGFuZy5mZWkzQHp0ZS5jb20uY24gd3JvdGU6DQo+IA0KPiBKdXN0IG9uZSBjb21tZW50IGFib3V0 IHRoZSBjaXRhdGlvbnMuDQo+IA0KPiBBcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjEsIHRoZSBB c3NvY2lhdGlvbiBJRCBhbmQgQXNzb2NpYXRpb24gU291cmNlDQo+IGlzIHRoZSBzYW1lIGFzIGRl ZmluZWQgaW4gUkZDNDg3Mi4NCj4gDQo+IEFuZCBhY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9u IGluIHNlY3Rpb24gMTYuMSBvZiBSRkM0ODcyLCBjaXRlZCBoZXJlDQo+IA0KPiAiIEFzc29jaWF0 aW9uIElEOiAxNiBiaXRzDQo+ICAgICAgICAgQSB2YWx1ZSBhc3NpZ25lZCBieSB0aGUgTFNQIGhl YWQtZW5kLiAgV2hlbiBjb21iaW5lZCB3aXRoIHRoZQ0KPiAgICAgICAgIEFzc29jaWF0aW9uIFR5 cGUgYW5kIEFzc29jaWF0aW9uIFNvdXJjZSwgdGhpcyB2YWx1ZSB1bmlxdWVseQ0KPiAgICAgICAg IGlkZW50aWZpZXMgYW4gYXNzb2NpYXRpb24uIg0KPiANCj4gDQo+ICIgQXNzb2NpYXRpb24gU291 cmNlOiA0IG9yIDE2IGJ5dGVzDQo+ICAgICAgICAgQW4gSVB2NCBvciBJUHY2IGFkZHJlc3MsIHJl c3BlY3RpdmVseSwgdGhhdCBpcyBhc3NvY2lhdGVkIHRvDQo+ICAgICAgICAgdGhlIG5vZGUgdGhh dCBvcmlnaW5hdGVkIHRoZSBhc3NvY2lhdGlvbi4iDQo+IA0KPiA8ZmVpPg0KPiANCj4gKDEpIFdo ZW4gdGhlIGFzc29jaWF0aW9uIG9iamVjdCBpcyB1c2VkIGZvciB0aGUgY28tcm91dGVkIGJpZGly ZWN0aW9uYWwNCj4gTFNQLCB0aGUgdHVubmVsIElEIGxvY2FsbHkgYXNzaWduZWQgYXQgWjkgbm9k ZSBtYXliZSBiZSBmaWxsZWQgaGVyZSwNCj4gaG93ZXZlciwNCj4gaXQgaXMgbm90IGFzc2lnbmVk IGJ5IHRoZSBMU1AgaGVhZC1lbmQgKEExIG5vZGUpLCBvciB3ZSBjYW4gaW50ZXJwcmV0DQo+IHRo YXQgWjkgaXMgYWxzbyB0aGUgTFNQIGhlYWQtZW5kPw0KPiANCg0KVGhlIGludGVudCB3YXMgdGhh dCAidGhlIGFzc29jaWF0aW9uIElEIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIGNyZWF0aW5nDQp0 aGUgYXNzb2NpYXRpb24gb2JqZWN0Ii4gIFRoaXMgc2hvdWxkIGJlIGV4cGxpY2l0bHkgc3RhdGVk IGJ5IHRoZSBkcmFmdC4NCiBUaGlzIGlzIGFuIGltcG9ydGFudCBjbGFyaWZpY2F0aW9uIGFuZCB3 aWxsIHJlc3VsdCBpbiBhIGZldyB0d2Vha3MgdG8NCnRoZSBjdXJyZW50IGRvY3VtZW50Lg0KDQpH b29kIGNhdGNoLg0KDQo+ICgyKSBBbm90aGVyIHVzZWNhc2UgaXMgdGhhdCBmb3IgdGhlIGFzc29j aWF0ZWQgYmlkaXJlY3Rpb25hbCBMU1AsIHRoaXMNCj4gZmllbGQgbWF5YmUgYmUgZmlsbGVkIGJ5 IHRoZSB0aGUgdHVubmVsIElEIG9mIHRoZSBmb3J3YXJkIExTUDEgb3IgdGhlDQo+IGJhY2t3YXJk IExTUDIuIElmIGl0IGlzIHRoZSB0dW5uZWwgSUQgb2YgTFNQMSwgd2hpY2ggaXMgbm90IGFzc2ln bmVkIGJ5DQo+IHRoZSBMU1AyIGhlYWQtZW5kLg0KDQpBZ3JlZWQuICBJIHRoaW5rIHRoZSBhYm92 ZSByZXZpc2lvbiB3aWxsIGFjY29tbW9kYXRlIHRoaXMuDQoNCj4gDQo+ICgzKVNpbWlsYXJseSBh cyBhYm92ZSwgdGhlIGFzc29jaWF0aW9uIHNvdXJjZSBtYXliZSBiZSByZWxhdGVkIHRvIEExIG9y DQo+IFo5IG5vZGUsIGFuZCBib3RoIG9mIHRoZW0gYXJlIHRoZSBub2RlcyB0aGF0IG9yaWdpbmF0 ZSB0aGUgYXNzb2NpYXRpb24NCj4gd2hlbiBkb3VibGUgc2lkZWQgcHJvdmlzaW9uZ2luZyBtb2Rl IGlzIHVzZWQuDQoNCnNhbWUgcmVzcG9uc2UuLi4NCg0KPiANCj4gKDMpSW4gdGhlIGdlbmVyYWwg c2NlbmFyaW9zLCB0aGUgY29tYmluYXRpb24gb2YgQXNzb2NpYXRpb24gVHlwZSwNCj4gQXNzb2Np YXRpb24gU291cmNlLCBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGFuZCBleHRlbmRlZCBBc3Nv Y2lhdGlvbg0KPiBpZCB3aWxsIGlkZW50aWZ5DQo+IGFuIGFzc29jaWF0aW9uLg0KDQpJJ20gbm90 IGNsZWFyIG9uIHlvdXIgY29tbWVudCBoZXJlLiAgRG9lcyB0aGlzIHJlbGF0ZSB0byBzcGVjaWZp YyB0ZXh0Pw0KIEFyZSB5b3UgbG9va2luZyBmb3IgYSBjaGFuZ2UgaW4gdGhlIGRyYWZ0PyAgUGxl YXNlIGNsYXJpZnkuDQoNCj4gDQo+IEp1c3QgbXkyY2VudHMsIHRoZSBkZXNjcmlwdGlvbnMgYWJv dXQgdGhlIGFzc29jaWF0aW9uIHNvdXJjZSBhbmQgaWQgYXJlDQo+IGFjY3VyYXRlIHVuZGVyIHRo ZSBzY29wZSBvZiBSRkM0ODcyLCBidXQgdGhlIGRpcmVjdCBjaXRhdGlvbiBmcm9tDQo+IFJGQzQ4 NzIgaXMgbm90IGFjY3VyYXRlIGhlcmUgaWYgd2UgY29uc2lkZXIgdGhlIG1vcmUgdXNlY2FzZXMu IA0KDQpJIHRoaW5rIHdlJ3JlIGluIGFncmVlbWVudC4NCg0KPiBDYW4gdGhlDQo+IGxpbWl0YXRp b24gYmUgcmVsZWFzZWQgb3IgdGhlc2Ugd29yZHMgYmUgb3JnYW5pemVkIGluIGFub3RoZXIgd2F5 Pw0KDQpZZXMsIHdpbGwgcmV2aXNlIGFzIHBhcnQgb2YgdGhlIHBvc3QtTEMgcmV2aXNpb24uDQoN ClRoYW5rcywNCkxvdQ0KPiANCj4gPC9mZWk+DQo+IA0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0K PiBGZWkNCj4gDQo+IA0KPiAqIkJSVU5HQVJELCBERUJPUkFIIEEiIDxkYjM1NDZAYXR0LmNvbT4q DQo+ILeivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCj4gDQo+IDIwMTItMDItMjQgMDY6 MTINCj4gDQo+IA0KPiDK1bz+yMsNCj4gICAgICAgICAgICAgICAgQ0NBTVAgPGNjYW1wQGlldGYu b3JnPg0KPiCzrcvNDQo+IA0KPiDW98ziDQo+ICAgICAgICAgICAgICAgIFtDQ0FNUF0gV0cgTGFz dCBDYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0DQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gQWxsLA0KPiANCj4gVGhpcyBzdGFydHMgYSB0d28td2VlayB3b3JraW5n IGdyb3VwIGxhc3QgY2FsbCBvbg0KPiBkcmFmdC1pZXRmLWNjYW1wLWFzc29jLWV4dC4NCj4gDQo+ IFRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZW5kcyBNYXJjaCA4dGguIFBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMNCj4gdG8gdGhlIENDQU1QIG1haWxpbmcgbGlzdC4NCj4gDQo+IERlYm9y YWggKGFuZCBMb3UpDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiAN Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQoNCg== --=_alternative 0008283F482579B1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxvdTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgKDMpSW4gdGhlIGdlbmVyYWwgc2NlbmFyaW9z LCB0aGUgY29tYmluYXRpb24NCm9mIEFzc29jaWF0aW9uIFR5cGUsPGJyPg0KJmd0OyBBc3NvY2lh dGlvbiBTb3VyY2UsIEdsb2JhbCBBc3NvY2lhdGlvbiBTb3VyY2UgYW5kIGV4dGVuZGVkIEFzc29j aWF0aW9uPGJyPg0KJmd0OyBpZCB3aWxsIGlkZW50aWZ5PGJyPg0KJmd0OyBhbiBhc3NvY2lhdGlv bi48YnI+DQo8YnI+DQpJJ20gbm90IGNsZWFyIG9uIHlvdXIgY29tbWVudCBoZXJlLiAmbmJzcDtE b2VzIHRoaXMgcmVsYXRlIHRvIHNwZWNpZmljDQp0ZXh0Pzxicj4NCiBBcmUgeW91IGxvb2tpbmcg Zm9yIGEgY2hhbmdlIGluIHRoZSBkcmFmdD8gJm5ic3A7UGxlYXNlIGNsYXJpZnkuPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtmZWkmZ3Q7 IFNvcnJ5IGZvciB0aGUgdW5jbGVhciBkZXNjcmlwdGlvbiwNCnBsZWFzZSBjaGVjayBteSByZXNw b25zZSBpbiBhbm90aGVyIG1haWwgd2hpY2ggaXMgdGhlIHNhbWUuICZsdDsvZmVpJmd0OzwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCA8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb3UgQmVyZ2VyICZs dDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDEyLTAyLTI1IDAxOjUzPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpoYW5nLmZlaTNAenRlLmNvbS5jbjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7QlJVTkdBUkQsIERFQk9SQUggQSZxdW90OyAmbHQ7ZGIzNTQ2 QGF0dC5jb20mZ3Q7LA0KQ0NBTVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OywgY2NhbXAtYm91bmNl c0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gV0cgTGFzdCBDYWxsIG9u IGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5GZWksPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnNlZSBiZWxvdyBmb3IgaW4t bGluZSByZXNwb25zZXMuPGJyPg0KPGJyPg0KT24gMi8yNC8yMDEyIDM6MTUgQU0sIHpoYW5nLmZl aTNAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSnVzdCBvbmUgY29tbWVu dCBhYm91dCB0aGUgY2l0YXRpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBBcyBkZXNjcmliZWQg aW4gc2VjdGlvbiAzLjEsIHRoZSBBc3NvY2lhdGlvbiBJRCBhbmQgQXNzb2NpYXRpb24gU291cmNl PGJyPg0KJmd0OyBpcyB0aGUgc2FtZSBhcyBkZWZpbmVkIGluIFJGQzQ4NzIuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEFuZCBhY2NvcmRpbmcgdG8gdGhlIGRlc2NyaXB0aW9uIGluIHNlY3Rpb24gMTYu MSBvZiBSRkM0ODcyLCBjaXRlZA0KaGVyZTxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDsgQXNz b2NpYXRpb24gSUQ6IDE2IGJpdHM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBBIHZhbHVlIGFzc2lnbmVkIGJ5IHRoZSBMU1AgaGVhZC1lbmQuDQombmJzcDtXaGVuIGNvbWJp bmVkIHdpdGggdGhlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXNzb2Np YXRpb24gVHlwZSBhbmQgQXNzb2NpYXRpb24gU291cmNlLA0KdGhpcyB2YWx1ZSB1bmlxdWVseTxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlkZW50aWZpZXMgYW4gYXNzb2Np YXRpb24uJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7IEFzc29j aWF0aW9uIFNvdXJjZTogNCBvciAxNiBieXRlczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IEFuIElQdjQgb3IgSVB2NiBhZGRyZXNzLCByZXNwZWN0aXZlbHksDQp0aGF0IGlz IGFzc29jaWF0ZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUg bm9kZSB0aGF0IG9yaWdpbmF0ZWQgdGhlIGFzc29jaWF0aW9uLiZxdW90Ozxicj4NCiZndDsgPGJy Pg0KJmd0OyAmbHQ7ZmVpJmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAoMSkgV2hlbiB0aGUgYXNz b2NpYXRpb24gb2JqZWN0IGlzIHVzZWQgZm9yIHRoZSBjby1yb3V0ZWQgYmlkaXJlY3Rpb25hbDxi cj4NCiZndDsgTFNQLCB0aGUgdHVubmVsIElEIGxvY2FsbHkgYXNzaWduZWQgYXQgWjkgbm9kZSBt YXliZSBiZSBmaWxsZWQgaGVyZSw8YnI+DQomZ3Q7IGhvd2V2ZXIsPGJyPg0KJmd0OyBpdCBpcyBu b3QgYXNzaWduZWQgYnkgdGhlIExTUCBoZWFkLWVuZCAoQTEgbm9kZSksIG9yIHdlIGNhbiBpbnRl cnByZXQ8YnI+DQomZ3Q7IHRoYXQgWjkgaXMgYWxzbyB0aGUgTFNQIGhlYWQtZW5kPzxicj4NCiZn dDsgPGJyPg0KPGJyPg0KVGhlIGludGVudCB3YXMgdGhhdCAmcXVvdDt0aGUgYXNzb2NpYXRpb24g SUQgaXMgc2VsZWN0ZWQgYnkgdGhlIG5vZGUgY3JlYXRpbmc8YnI+DQp0aGUgYXNzb2NpYXRpb24g b2JqZWN0JnF1b3Q7LiAmbmJzcDtUaGlzIHNob3VsZCBiZSBleHBsaWNpdGx5IHN0YXRlZCBieQ0K dGhlIGRyYWZ0Ljxicj4NCiBUaGlzIGlzIGFuIGltcG9ydGFudCBjbGFyaWZpY2F0aW9uIGFuZCB3 aWxsIHJlc3VsdCBpbiBhIGZldyB0d2Vha3MgdG88YnI+DQp0aGUgY3VycmVudCBkb2N1bWVudC48 YnI+DQo8YnI+DQpHb29kIGNhdGNoLjxicj4NCjxicj4NCiZndDsgKDIpIEFub3RoZXIgdXNlY2Fz ZSBpcyB0aGF0IGZvciB0aGUgYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCwNCnRoaXM8YnI+ DQomZ3Q7IGZpZWxkIG1heWJlIGJlIGZpbGxlZCBieSB0aGUgdGhlIHR1bm5lbCBJRCBvZiB0aGUg Zm9yd2FyZCBMU1AxIG9yDQp0aGU8YnI+DQomZ3Q7IGJhY2t3YXJkIExTUDIuIElmIGl0IGlzIHRo ZSB0dW5uZWwgSUQgb2YgTFNQMSwgd2hpY2ggaXMgbm90IGFzc2lnbmVkDQpieTxicj4NCiZndDsg dGhlIExTUDIgaGVhZC1lbmQuPGJyPg0KPGJyPg0KQWdyZWVkLiAmbmJzcDtJIHRoaW5rIHRoZSBh Ym92ZSByZXZpc2lvbiB3aWxsIGFjY29tbW9kYXRlIHRoaXMuPGJyPg0KPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICgzKVNpbWlsYXJseSBhcyBhYm92ZSwgdGhlIGFzc29jaWF0aW9uIHNvdXJjZSBtYXli ZSBiZSByZWxhdGVkIHRvDQpBMSBvcjxicj4NCiZndDsgWjkgbm9kZSwgYW5kIGJvdGggb2YgdGhl bSBhcmUgdGhlIG5vZGVzIHRoYXQgb3JpZ2luYXRlIHRoZSBhc3NvY2lhdGlvbjxicj4NCiZndDsg d2hlbiBkb3VibGUgc2lkZWQgcHJvdmlzaW9uZ2luZyBtb2RlIGlzIHVzZWQuPGJyPg0KPGJyPg0K c2FtZSByZXNwb25zZS4uLjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyAoMylJbiB0aGUgZ2Vu ZXJhbCBzY2VuYXJpb3MsIHRoZSBjb21iaW5hdGlvbiBvZiBBc3NvY2lhdGlvbiBUeXBlLDxicj4N CiZndDsgQXNzb2NpYXRpb24gU291cmNlLCBHbG9iYWwgQXNzb2NpYXRpb24gU291cmNlIGFuZCBl eHRlbmRlZCBBc3NvY2lhdGlvbjxicj4NCiZndDsgaWQgd2lsbCBpZGVudGlmeTxicj4NCiZndDsg YW4gYXNzb2NpYXRpb24uPGJyPg0KPGJyPg0KSSdtIG5vdCBjbGVhciBvbiB5b3VyIGNvbW1lbnQg aGVyZS4gJm5ic3A7RG9lcyB0aGlzIHJlbGF0ZSB0byBzcGVjaWZpYw0KdGV4dD88YnI+DQogQXJl IHlvdSBsb29raW5nIGZvciBhIGNoYW5nZSBpbiB0aGUgZHJhZnQ/ICZuYnNwO1BsZWFzZSBjbGFy aWZ5Ljxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBKdXN0IG15MmNlbnRzLCB0aGUgZGVzY3Jp cHRpb25zIGFib3V0IHRoZSBhc3NvY2lhdGlvbiBzb3VyY2UgYW5kIGlkDQphcmU8YnI+DQomZ3Q7 IGFjY3VyYXRlIHVuZGVyIHRoZSBzY29wZSBvZiBSRkM0ODcyLCBidXQgdGhlIGRpcmVjdCBjaXRh dGlvbiBmcm9tPGJyPg0KJmd0OyBSRkM0ODcyIGlzIG5vdCBhY2N1cmF0ZSBoZXJlIGlmIHdlIGNv bnNpZGVyIHRoZSBtb3JlIHVzZWNhc2VzLiA8YnI+DQo8YnI+DQpJIHRoaW5rIHdlJ3JlIGluIGFn cmVlbWVudC48YnI+DQo8YnI+DQomZ3Q7IENhbiB0aGU8YnI+DQomZ3Q7IGxpbWl0YXRpb24gYmUg cmVsZWFzZWQgb3IgdGhlc2Ugd29yZHMgYmUgb3JnYW5pemVkIGluIGFub3RoZXIgd2F5Pzxicj4N Cjxicj4NClllcywgd2lsbCByZXZpc2UgYXMgcGFydCBvZiB0aGUgcG9zdC1MQyByZXZpc2lvbi48 YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KTG91PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZsdDsvZmVp Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJlc3QgcmVnYXJkczxicj4NCiZn dDsgPGJyPg0KJmd0OyBGZWk8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqJnF1b3Q7 QlJVTkdBUkQsIERFQk9SQUggQSZxdW90OyAmbHQ7ZGIzNTQ2QGF0dC5jb20mZ3Q7Kjxicj4NCiZn dDsgt6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGlldGYub3JnPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDIwMTItMDItMjQgMDY6MTI8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7 IMrVvP7Iyzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtDQ0FNUA0KJmx0O2NjYW1wQGlldGYub3JnJmd0Ozxicj4N CiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 W0NDQU1QXQ0KV0cgTGFzdCBDYWxsIG9uIGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbGwsPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFRoaXMgc3RhcnRzIGEgdHdvLXdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwg b248YnI+DQomZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtYXNzb2MtZXh0Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgTWFyY2ggOHRoLiBQbGVhc2Ug c2VuZCB5b3VyIGNvbW1lbnRzPGJyPg0KJmd0OyB0byB0aGUgQ0NBTVAgbWFpbGluZyBsaXN0Ljxi cj4NCiZndDsgPGJyPg0KJmd0OyBEZWJvcmFoIChhbmQgTG91KTxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jY2FtcDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRm Lm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft cDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0008283F482579B1_=-- From okamoto@ieee.org Mon Feb 27 00:49:44 2012 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 1D74E21F846C for ; Mon, 27 Feb 2012 00:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.863 X-Spam-Level: X-Spam-Status: No, score=-99.863 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SARE_SUB_OBFU_Q1=0.227, 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 EpUr+ePoQ0Al for ; Mon, 27 Feb 2012 00:49:43 -0800 (PST) Received: from red.yamanaka.ics.keio.ac.jp (red.yamanaka.ics.keio.ac.jp [131.113.102.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4B21F8464 for ; Mon, 27 Feb 2012 00:49:43 -0800 (PST) Received: from [192.168.4.32] (radish.yamanaka.k2.keio.ac.jp [131.113.23.34]) by red.yamanaka.ics.keio.ac.jp (Postfix) with ESMTP id 96EB41B00034; Mon, 27 Feb 2012 17:49:41 +0900 (JST) Message-ID: <4F4B43A4.6090005@ieee.org> Date: Mon, 27 Feb 2012 17:49:40 +0900 From: Satoru OKAMOTO User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ccamp@ietf.org References: <20120227084011.26669.46805.idtracker@ietfa.amsl.com> In-Reply-To: <20120227084011.26669.46805.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120227084011.26669.46805.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Fwd: I-D Action: draft-okamoto-ccamp-midori-gmpls-extension-reqs-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: Mon, 27 Feb 2012 08:49:44 -0000 All, I have uploaded a new draft into the IETF repository. This draft defines new GMPLS Extension Requirements for Energy Efficient Traffic Engineering. In this version, Notify Requirement is newly added. All comments are welcome. Best regards, Satoru Okamoto -------- Original Message -------- Subject: I-D Action: draft-okamoto-ccamp-midori-gmpls-extension-reqs-01.txt Date: Mon, 27 Feb 2012 00:40:11 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements of GMPLS Extensions for Energy Efficient Traffic Engineering Author(s) : Satoru Okamoto Filename : draft-okamoto-ccamp-midori-gmpls-extension-reqs-01.txt Pages : 6 Date : 2012-02-27 This document discusses some of extensions required in existing GMPLS OSPF routing protocol, RSVP signaling protocol, and LMP to support the energy efficient traffic engineering technology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-okamoto-ccamp-midori-gmpls-extension-reqs-01.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-okamoto-ccamp-midori-gmpls-extension-reqs-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From daniele.ceccarelli@ericsson.com Mon Feb 27 06:51:23 2012 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 6D81221F86F9 for ; Mon, 27 Feb 2012 06:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.727 X-Spam-Level: X-Spam-Status: No, score=-8.727 tagged_above=-999 required=5 tests=[AWL=1.872, 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 qEgvnqdDVs0w for ; Mon, 27 Feb 2012 06:51:22 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9621F86F4 for ; Mon, 27 Feb 2012 06:51:21 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-0a-4f4b9868d23f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7D.19.01970.8689B4F4; Mon, 27 Feb 2012 15:51:21 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.18]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 27 Feb 2012 15:51:20 +0100 From: Daniele Ceccarelli To: Lou Berger , CCAMP Date: Mon, 27 Feb 2012 15:51:19 +0100 Thread-Topic: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Thread-Index: AczwpZngN8omRSB2ToKtKbWI0UX/BwEmGzNQ Message-ID: References: <4F43AACE.7040507@labn.net> In-Reply-To: <4F43AACE.7040507@labn.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 14:51:23 -0000 Hi Lou, Julien, I had a look at the ID. It is a good work and definitely something we neede= d to put some order in past so to have solid bases for the future. Please find some notes/comments/questions below: 1. PSC deprecation - agree 2. Revised Switiching Type definition - agree with a question - "A different Switching Type SHOULD be used for each data plane technology= even when those technologies share the same type of multiplexing or switch= ing." Does this mean that e.g. SDH and OTN, despite sharing same type of sw= itching SHOULD use different Switching type? What is not clear to me is "sa= me type of multiplexing" could you please clarify?=20 3. "Additionally, a different Switching Type MUST be used to indicate diffe= rent Switching Capability specific information field formats."=20 - This is potentially non future proof. If we have one to one mapping betwe= en the Switching Type and the SCSI the SCSI design MUST be future proof, ot= herwise we fall back in the issue of the Min LSP bandwidth SCSI linked to S= witch Cap TDM. Maybe avoiding this 1:1 mapping but allowing a 1:N would pre= vent this problem to happening. 4. It is not clear to me how the ILH field is used. From my understanding t= here is a mapping as follows (i'm considering the OTN as example) ODU0 --> Switch Type=3DOTN; ILH=3D1 ODU1 --> Switch Type=3DOTN; ILH=3D2 ODU2 --> Switch Type=3DOTN; ILH=3D3 ... This would imply advertising 1 ISCD for each "signal type" instead of 1 ISC= D for each "muxing hierarchy" as it is now stated in draft-ospf-g709v3. Is = my understanding correct? Thanks, Daniele >-----Original Message----- >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 >On Behalf Of Lou Berger >Sent: marted=EC 21 febbraio 2012 15.32 >To: CCAMP >Subject: [CCAMP] Fwd: I-D Action:=20 >draft-berger-ccamp-swcaps-update-00.txt > >All, > This draft was motivated by the OTN discussion in=20 >December. The general issue raised by that discussion was how=20 >should we (the WG) assign Switching types going forward. At=20 >the time, my proposal was that we should follow general=20 >precedent, i.e., per hierarchy level assignment ala PSC-N. The=20 >problem with this, as John and the others pointed out, is that=20 >there is also precedent for per technology type assignment. =20 >The discussion left off with my commitment to submit a draft=20 >on the general topic, which is the draft mentioned below. > >The intent of this draft is to clearly establish which=20 >precedent will be followed in the future. Our proposal is=20 >that we follow per technology type assignment, i.e., a=20 >Switching type value whenever there may be a different SCSI,=20 >and remove any relationship to hierarchy from this field. We=20 >also propose to deprecate PSC-2,3 & 4. For compatibility=20 >sake, we do not propose changing any other existing Switching=20 >type values. > >Obviously, comments are welcome and desired. > >Lou (as co-author) > >-------- Original Message -------- >Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt >Date: Tue, 21 Feb 2012 06:23:55 -0800 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > > Title : Revised Definition of The GMPLS=20 >Switching Capability >and Type Fields > Author(s) : Lou Berger > Julien Meuric > Filename : draft-berger-ccamp-swcaps-update-00.txt > Pages : 9 > Date : 2012-02-21 > > GMPLS provides control for multiple switching technologies, and > hierarchical switching within a technology. GMPLS routing and > signaling use common values to indicate switching technology type. > These values are carried in routing in the Switching Capability > field, and in signaling in the Switching Type field. While the > values using in these fields are the primary indicators of the > technology and hierarchy level being controlled, the values are > not consistently defined and used across the different > technologies supported by GMPLS. This document is intended to > resolve the inconsistent definition and use of the Switching > Capability and Type fields by narrowly scoping the meaning and use > of the fields. This document updates any document that uses the > GMPLS Switching Capability and Types fields, in particular RFC > 3471, RFC 4202, RFC 4203, and RFC 5307. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-u >pdate-00.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-berger-ccamp-swcaps-up >date-00.txt > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp >= From lberger@labn.net Mon Feb 27 07:32:15 2012 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 DA62521F8794 for ; Mon, 27 Feb 2012 07:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.142 X-Spam-Level: X-Spam-Status: No, score=-98.142 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, 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 ZyfBXfugWw-b for ; Mon, 27 Feb 2012 07:32:15 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id C4C8D21F8707 for ; Mon, 27 Feb 2012 07:32:14 -0800 (PST) Received: (qmail 2712 invoked by uid 0); 27 Feb 2012 15:32:14 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 27 Feb 2012 15:32: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=UA7p/jsqg8G4160DCRh8KmxOYhONXvKBsXnvcxfzeuY=; b=JPHgQW5+55TnPnI101kB6AaRDrC3nKhBTk5JJd0OlwXoF6+3rb6BASn2GDXtWNkn+5e/b62fxvqmUaSNeBjMIeiU5znE5pgFV8aRXwc10FfKR7qe4nB0Bknc8Ktc0kgQ; 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 1S22Yf-0005kp-OU; Mon, 27 Feb 2012 08:32:14 -0700 Message-ID: <4F4BA1FC.4060107@labn.net> Date: Mon, 27 Feb 2012 10:32:12 -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: zhang.fei3@zte.com.cn References: In-Reply-To: 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: CCAMP , "draft-ietf-ccamp-assoc-ext@tools.ietf.org" Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-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: Mon, 27 Feb 2012 15:32:16 -0000 Fei, Okay, but I think we're really splitting hairs here. I'll change it to: A value assigned by the the node that originated the association. When combined with the other fields carried in the object, this value uniquely identifies an association. I think this covers all possible uses/interpretations. Lou On 2/26/2012 8:20 PM, zhang.fei3@zte.com.cn wrote: > > Lou > > Thanks for your response immediately, and I think that the revised > sentence "A value assigned by the the node that originated the > association" reflects my comments precisely. > > According to the section 3.1 of the draft draft-ietf-ccamp-assoc-ext, > the Extended Associaiton object is defined by adding two fields in the > old Association > object, one is the Global Association Source and the other is the > Extended Association ID. In some cases, for example, like an LSP across > different ASs, or > the Association ID field is insufficient, the association is uniquly > identified by the combination of Association Type、Association Source、 > Global Association > Source and Extended Association ID. Of cource, the Global Association > Source maybe be set to zero, or the length of the Extended Association > field is zero. > > So as to the second revised sentence that "When combined with the > Association Type and Association Source, this value uniquely identifies > an association", which > may let the readers think that the Global Association Source and the the > Extended Association ID are not used to identify an association uniquly. > > What about the revision like "When combined with the Association Type、 > Association Source、Global Association Source and Extended Association > ID, this value uniquely identifies an association" or in other way if > you think the clarification is useful? > > Best > > Fei > > > *Lou Berger * > > 2012-02-25 02:38 > > > 收件人 > zhang.fei3@zte.com.cn > 抄送 > "draft-ietf-ccamp-assoc-ext@tools.ietf.org" > , "BRUNGARD, DEBORAH A" > , CCAMP > 主题 > Re: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext > > > > > > > > > Fei/All, > I propose to address the Fei's comments by adding the following new > section to the document. (as well as some other related editorial changes.) > > 2. Modified Association ID Field Definition > > The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION > objects defined in [RFC4872]. The [RFC4872] definition of the field > reads: > > A value assigned by the LSP head-end. When combined with the > Association Type and Association Source, this value uniquely > identifies an association. > > This document allows for the origination of ASSOCIATION objects by > nodes other than "the LSP head-end". As such, the definition of the > Association ID field needs to be modified to accommodate such usage. > This document defines the Association ID field of the IPv4 and IPv6 > ASSOCIATION objects as: > > A value assigned by the the node that originated the association. > When combined with the Association Type and Association Source, > this value uniquely identifies an association. > > This change in definition does not impact [RFC4872] or [RFC4873] > defined procedures or mechanisms, nor does it impact existing > implementations of [RFC4872] or [RFC4873]. > > I believe this addresses the comment. Let me know if you disagree, or > have other comments. > > Much thanks, > Lou (draft co-author) > > On 2/24/2012 12:53 PM, Lou Berger wrote: >> Fei, >> see below for in-line responses. >> >> On 2/24/2012 3:15 AM, zhang.fei3@zte.com.cn wrote: >> >>> Just one comment about the citations. >>> >>> As described in section 3.1, the Association ID and Association Source >>> is the same as defined in RFC4872. >>> >>> And according to the description in section 16.1 of RFC4872, cited here >>> >>> " Association ID: 16 bits >>> A value assigned by the LSP head-end. When combined with the >>> Association Type and Association Source, this value uniquely >>> identifies an association." >>> >>> >>> " Association Source: 4 or 16 bytes >>> An IPv4 or IPv6 address, respectively, that is associated to >>> the node that originated the association." >>> >>> >>> >>> (1) When the association object is used for the co-routed bidirectional >>> LSP, the tunnel ID locally assigned at Z9 node maybe be filled here, >>> however, >>> it is not assigned by the LSP head-end (A1 node), or we can interpret >>> that Z9 is also the LSP head-end? >>> >>> >> The intent was that "the association ID is selected by the node creating >> the association object". This should be explicitly stated by the draft. >> This is an important clarification and will result in a few tweaks to >> the current document. >> >> Good catch. >> >> >>> (2) Another usecase is that for the associated bidirectional LSP, this >>> field maybe be filled by the the tunnel ID of the forward LSP1 or the >>> backward LSP2. If it is the tunnel ID of LSP1, which is not assigned by >>> the LSP2 head-end. >>> >> Agreed. I think the above revision will accommodate this. >> >> >>> (3)Similarly as above, the association source maybe be related to A1 or >>> Z9 node, and both of them are the nodes that originate the association >>> when double sided provisionging mode is used. >>> >> same response... >> >> >>> (3)In the general scenarios, the combination of Association Type, >>> Association Source, Global Association Source and extended Association >>> id will identify >>> an association. >>> >> I'm not clear on your comment here. Does this relate to specific text? >> Are you looking for a change in the draft? Please clarify. >> >> >>> Just my2cents, the descriptions about the association source and id are >>> accurate under the scope of RFC4872, but the direct citation from >>> RFC4872 is not accurate here if we consider the more usecases. >>> >> I think we're in agreement. >> >> >>> Can the >>> limitation be released or these words be organized in another way? >>> >> Yes, will revise as part of the post-LC revision. >> >> Thanks, >> Lou >> >>> >>> >>> >>> Best regards >>> >>> Fei >>> >>> >>> *"BRUNGARD, DEBORAH A" * >>> 发件人: ccamp-bounces@ietf.org >>> >>> 2012-02-24 06:12 >>> >>> >>> 收件人 >>> CCAMP >>> 抄送 >>> >>> 主题 >>> [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-ext >>> >>> >>> >>> >>> >>> >>> >>> >>> All, >>> >>> This starts a two-week working group last call on >>> draft-ietf-ccamp-assoc-ext. >>> >>> This working group last call ends March 8th. Please send your comments >>> to the CCAMP mailing list. >>> >>> Deborah (and Lou) >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Feb 27 08:08:17 2012 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 4091021F87B7 for ; Mon, 27 Feb 2012 08:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.358 X-Spam-Level: X-Spam-Status: No, score=-99.358 tagged_above=-999 required=5 tests=[AWL=0.803, 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 WA5FtdUVsY26 for ; Mon, 27 Feb 2012 08:08:16 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 6609121F879C for ; Mon, 27 Feb 2012 08:08:16 -0800 (PST) Received: (qmail 25391 invoked by uid 0); 27 Feb 2012 16:08:15 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 27 Feb 2012 16:08: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=ntN4YljBp3aQ34FVTFV1XqyOkFwCVKzFVLEMyRzBdyQ=; b=PDB/kCv2LrKOhB1BV+BuMmOqlQaGrHKj+3nd4gF9/F8Pei7F25BJ+6tpQojVtvmykXa6GLyOnS2qmTsLR55PkayjE+kZe/APd8zBj7VOIrCz/gJoYqor6jkSHcCF2JHJ; 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 1S237X-0003g5-2q; Mon, 27 Feb 2012 09:08:15 -0700 Message-ID: <4F4BAA6E.9070106@labn.net> Date: Mon, 27 Feb 2012 11:08:14 -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: <4F43AACE.7040507@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] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 16:08:17 -0000 Daniele, Thanks for the comments. Please see responses below. On 2/27/2012 9:51 AM, Daniele Ceccarelli wrote: > Hi Lou, Julien, > > I had a look at the ID. It is a good work and definitely something we needed to put some order in past so to have solid bases for the future. > > Please find some notes/comments/questions below: > > 1. PSC deprecation - agree > > 2. Revised Switiching Type definition - agree with a question > - "A different Switching Type SHOULD be used for each data plane > technology even when those technologies share the same type of > multiplexing or switching." Does this mean that e.g. SDH and OTN, > despite sharing same type of switching SHOULD use different Switching > type? For *future* technology definitions, yes, as they may use different SCSIs. > What is not clear to me is "same type of multiplexing" could > you please clarify? > The text currently provides the following example: For example, Time Division Multiplexing (TDM) technologies that have different multiplexing structures should use two different Switching Types. Is this not sufficiently clear? Can you suggest some clarifying text as I'm not sure what else to say? > 3. "Additionally, a different Switching Type MUST be used to indicate > different Switching Capability specific information field formats." > > - This is potentially non future proof. If we have one to one mapping > between the Switching Type and the SCSI the SCSI design MUST be > future proof, otherwise we fall back in the issue of the Min LSP > bandwidth SCSI linked to Switch Cap TDM. Maybe avoiding this 1:1 > mapping but allowing a 1:N would prevent this problem to happening. I think you may be misinterpreting our intent. Does the following rephrasing cover your concern: OLD: Additionally, a different Switching Type MUST be used to indicate different Switching Capability specific information field formats. NEW: As the format of the Switching Capability specific information field is dependent on the value of this field, a different Switching Type value MUST be used to differentiate between different Switching Capability specific information field formats. This doesn't mean that two technologies (and two Switching Type value) can't share the same SCSI format. Just that when there are two SCSI formats, two different Switching Types must be used. This is already an implicit requirement in [RFC4203] and [RFC5307]. > > 4. It is not clear to me how the ILH field is used. From my > understanding there is a mapping as follows (i'm considering the OTN > as example) > ODU0 --> Switch Type=OTN; ILH=1 > ODU1 --> Switch Type=OTN; ILH=2 > ODU2 --> Switch Type=OTN; ILH=3 > ... > This would imply advertising 1 ISCD for each "signal type" instead of 1 ISCD for each "muxing hierarchy" as it is now stated in draft-ospf-g709v3. Is my understanding correct? > Given that maturity level of this (our) draft, I would not recommend any changes to gmpls-ospf-g709v3 at this time. That said, if you want to use gmpls-ospf-g709v3 as an example, ILH would be set to match the Signal Type of the #stages=0 TLV carried in the ISCD/SCSI. As I read the gmpls-ospf-g709v3, gmpls-ospf-g709v3 already precludes the advertisement of different Signal Type at the #stages=0 in the same ISCD, so there would be no change in number of advertised ISCDs due to the use of ILH field in this example. Lou > Thanks, > Daniele > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On Behalf Of Lou Berger >> Sent: marted 21 febbraio 2012 15.32 >> To: CCAMP >> Subject: [CCAMP] Fwd: I-D Action: >> draft-berger-ccamp-swcaps-update-00.txt >> >> All, >> This draft was motivated by the OTN discussion in >> December. The general issue raised by that discussion was how >> should we (the WG) assign Switching types going forward. At >> the time, my proposal was that we should follow general >> precedent, i.e., per hierarchy level assignment ala PSC-N. The >> problem with this, as John and the others pointed out, is that >> there is also precedent for per technology type assignment. >> The discussion left off with my commitment to submit a draft >> on the general topic, which is the draft mentioned below. >> >> The intent of this draft is to clearly establish which >> precedent will be followed in the future. Our proposal is >> that we follow per technology type assignment, i.e., a >> Switching type value whenever there may be a different SCSI, >> and remove any relationship to hierarchy from this field. We >> also propose to deprecate PSC-2,3 & 4. For compatibility >> sake, we do not propose changing any other existing Switching >> type values. >> >> Obviously, comments are welcome and desired. >> >> Lou (as co-author) >> >> -------- Original Message -------- >> Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt >> Date: Tue, 21 Feb 2012 06:23:55 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : Revised Definition of The GMPLS >> Switching Capability >> and Type Fields >> Author(s) : Lou Berger >> Julien Meuric >> Filename : draft-berger-ccamp-swcaps-update-00.txt >> Pages : 9 >> Date : 2012-02-21 >> >> GMPLS provides control for multiple switching technologies, and >> hierarchical switching within a technology. GMPLS routing and >> signaling use common values to indicate switching technology type. >> These values are carried in routing in the Switching Capability >> field, and in signaling in the Switching Type field. While the >> values using in these fields are the primary indicators of the >> technology and hierarchy level being controlled, the values are >> not consistently defined and used across the different >> technologies supported by GMPLS. This document is intended to >> resolve the inconsistent definition and use of the Switching >> Capability and Type fields by narrowly scoping the meaning and use >> of the fields. This document updates any document that uses the >> GMPLS Switching Capability and Types fields, in particular RFC >> 3471, RFC 4202, RFC 4203, and RFC 5307. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-u >> pdate-00.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-berger-ccamp-swcaps-up >> date-00.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > > > From daniele.ceccarelli@ericsson.com Mon Feb 27 08:39:34 2012 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 EF13F21F8647 for ; Mon, 27 Feb 2012 08:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.039 X-Spam-Level: X-Spam-Status: No, score=-9.039 tagged_above=-999 required=5 tests=[AWL=1.560, 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 95INLtGPmek2 for ; Mon, 27 Feb 2012 08:39:34 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7175C21F85AD for ; Mon, 27 Feb 2012 08:39:33 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-6c-4f4bb1c3779b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 58.2A.01970.3C1BB4F4; Mon, 27 Feb 2012 17:39:31 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.18]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 27 Feb 2012 17:39:31 +0100 From: Daniele Ceccarelli To: Lou Berger Date: Mon, 27 Feb 2012 17:39:30 +0100 Thread-Topic: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Thread-Index: Acz1agS1jV7M6LbISQC1vFf+KvVfTQAATmvg Message-ID: References: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> In-Reply-To: <4F4BAA6E.9070106@labn.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: CCAMP Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 16:39:35 -0000 Hi Lou, My replies in line. Thanks, Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: luned=EC 27 febbraio 2012 17.08 >To: Daniele Ceccarelli >Cc: CCAMP >Subject: Re: [CCAMP] Fwd: I-D Action:=20 >draft-berger-ccamp-swcaps-update-00.txt > >Daniele, > Thanks for the comments. Please see responses below. > >On 2/27/2012 9:51 AM, Daniele Ceccarelli wrote: >> Hi Lou, Julien, >> >> I had a look at the ID. It is a good work and definitely something we >needed to put some order in past so to have solid bases for the future. >> >> Please find some notes/comments/questions below: >> >> 1. PSC deprecation - agree >> >> 2. Revised Switiching Type definition - agree with a question >> - "A different Switching Type SHOULD be used for each data plane=20 >> technology even when those technologies share the same type of=20 >> multiplexing or switching." Does this mean that e.g. SDH and OTN,=20 >> despite sharing same type of switching SHOULD use different=20 >Switching=20 >> type? > >For *future* technology definitions, yes, as they may use=20 >different SCSIs. OK, it was just a confirmation. So OTN is a future technology :-) > >> What is not clear to me is "same type of multiplexing" could you=20 >> please clarify? >> > >The text currently provides the following example: > For example, Time Division Multiplexing (TDM) technologies that > have different multiplexing structures should use two different > Switching Types. > >Is this not sufficiently clear? Can you suggest some=20 >clarifying text as I'm not sure what else to say? What was not clear to me was whether you were referring to: 1. different muxing technology between SDH and OTN=20 2. different muxing technology within SDH or within OTN. In case 2. different OTN muxing hierarchies (e.g. ODU1->ODU2 and ODU1->ODU3= )should have a different Switching Type for each muxing hierarchy. I assume you were refering to case 1. and suggest the following text: OLD: For example, Time Division Multiplexing (TDM) technologies that have different multiplexing structures should use two different Switching Types. NEW: For example, different Time Division Multiplexing (TDM) technologies should use different Switching Types. > >> 3. "Additionally, a different Switching Type MUST be used to=20 >indicate=20 >> different Switching Capability specific information field formats." >> >> - This is potentially non future proof. If we have one to=20 >one mapping=20 >> between the Switching Type and the SCSI the SCSI design MUST=20 >be future=20 >> proof, otherwise we fall back in the issue of the Min LSP bandwidth=20 >> SCSI linked to Switch Cap TDM. Maybe avoiding this 1:1 mapping but=20 >> allowing a 1:N would prevent this problem to happening. > >I think you may be misinterpreting our intent. Does the=20 >following rephrasing cover your concern: > >OLD: > Additionally, a different Switching Type MUST be used to > indicate different Switching Capability specific information > field formats. >NEW: > As the format of the Switching Capability specific information > field is dependent on the value of this field, a different > Switching Type value MUST be used to differentiate between=20 >different > Switching Capability specific information field formats. Perfect > >This doesn't mean that two technologies (and two Switching=20 >Type value) can't share the same SCSI format. Just that when=20 >there are two SCSI formats, two different Switching Types must=20 >be used. This is already an implicit requirement in [RFC4203]=20 >and [RFC5307]. > >> >> 4. It is not clear to me how the ILH field is used. From my=20 >> understanding there is a mapping as follows (i'm considering the OTN=20 >> as example) ODU0 --> Switch Type=3DOTN; ILH=3D1 >> ODU1 --> Switch Type=3DOTN; ILH=3D2 >> ODU2 --> Switch Type=3DOTN; ILH=3D3 >> ... >> This would imply advertising 1 ISCD for each "signal type" instead of >1 ISCD for each "muxing hierarchy" as it is now stated in=20 >draft-ospf-g709v3. Is my understanding correct? >> > >Given that maturity level of this (our) draft, I would not=20 >recommend any changes to gmpls-ospf-g709v3 at this time. > >That said, if you want to use gmpls-ospf-g709v3 as an example,=20 >ILH would be set to match the Signal Type of the #stages=3D0 TLV=20 >carried in the ISCD/SCSI. As I read the gmpls-ospf-g709v3,=20 >gmpls-ospf-g709v3 already precludes the advertisement of=20 >different Signal Type at the #stages=3D0 in the same ISCD, so=20 >there would be no change in number of advertised ISCDs due to=20 >the use of ILH field in this example. Again a misunderstanding from my side, but i think it is worth spending few= more words to identify the meaning of the ILH. A suggestion: OLD: In order to support hierarchical switching within a particular data plane technology in routing, this section defines a Intra-Layer Hierarchy, or ILH, field. This field allows for representation of up to 15 layers of hierarchical switching. The ILH field is carried in a portion of the previously defined reserved field of the Interface Switching Capability Descriptor and has the following format: NEW: In order to support hierarchical switching within a particular data plane technology in routing, this section defines a Intra-Layer Hierarchy, or ILH, field. This field allows for representation of up to 15 layers of hierarchical switching. The ILH field represent the=20 bottom most layer of the multiplexing hierarchy and is carried in a portion of the previously defined reserved field of the Interface Switching Capability Descriptor and has the following format: > >Lou > >> Thanks, >> Daniele >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>> Behalf Of Lou Berger >>> Sent: marted=EC 21 febbraio 2012 15.32 >>> To: CCAMP >>> Subject: [CCAMP] Fwd: I-D Action: >>> draft-berger-ccamp-swcaps-update-00.txt >>> >>> All, >>> This draft was motivated by the OTN discussion in=20 >December. The=20 >>> general issue raised by that discussion was how should we (the WG)=20 >>> assign Switching types going forward. At the time, my proposal was=20 >>> that we should follow general precedent, i.e., per hierarchy level=20 >>> assignment ala PSC-N. The problem with this, as John and the others=20 >>> pointed out, is that there is also precedent for per=20 >technology type=20 >>> assignment. >>> The discussion left off with my commitment to submit a draft on the=20 >>> general topic, which is the draft mentioned below. >>> >>> The intent of this draft is to clearly establish which=20 >precedent will=20 >>> be followed in the future. Our proposal is that we follow per=20 >>> technology type assignment, i.e., a Switching type value whenever=20 >>> there may be a different SCSI, and remove any relationship to=20 >>> hierarchy from this field. We also propose to deprecate=20 >PSC-2,3 & 4. =20 >>> For compatibility sake, we do not propose changing any=20 >other existing=20 >>> Switching type values. >>> >>> Obviously, comments are welcome and desired. >>> >>> Lou (as co-author) >>> >>> -------- Original Message -------- >>> Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt >>> Date: Tue, 21 Feb 2012 06:23:55 -0800 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>> >>> Title : Revised Definition of The GMPLS >>> Switching Capability >>> and Type Fields >>> Author(s) : Lou Berger >>> Julien Meuric >>> Filename : draft-berger-ccamp-swcaps-update-00.txt >>> Pages : 9 >>> Date : 2012-02-21 >>> >>> GMPLS provides control for multiple switching technologies, and >>> hierarchical switching within a technology. GMPLS routing and >>> signaling use common values to indicate switching technology type. >>> These values are carried in routing in the Switching Capability >>> field, and in signaling in the Switching Type field. While the >>> values using in these fields are the primary indicators of the >>> technology and hierarchy level being controlled, the values are >>> not consistently defined and used across the different >>> technologies supported by GMPLS. This document is intended to >>> resolve the inconsistent definition and use of the Switching >>> Capability and Type fields by narrowly scoping the meaning and use >>> of the fields. This document updates any document that uses the >>> GMPLS Switching Capability and Types fields, in particular RFC >>> 3471, RFC 4202, RFC 4203, and RFC 5307. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-u >>> pdate-00.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-berger-ccamp-swcaps-up >>> date-00.txt >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >> >> >> > >= From lberger@labn.net Mon Feb 27 09:02:04 2012 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 4150A21F87A7 for ; Mon, 27 Feb 2012 09:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.375 X-Spam-Level: X-Spam-Status: No, score=-99.375 tagged_above=-999 required=5 tests=[AWL=0.786, 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 J77zqA+0CQRs for ; Mon, 27 Feb 2012 09:02:02 -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 3D5D421F8692 for ; Mon, 27 Feb 2012 09:02:02 -0800 (PST) Received: (qmail 17740 invoked by uid 0); 27 Feb 2012 17:01:57 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 27 Feb 2012 17:01:57 -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=c2+w5E6WbskXphAH8Io8Aof/tNhLC9XlUVZrlVghTFo=; b=L+xOUCOfMToD8EOpXQg4YX1TIoiqj8PZPMQr6tG1x4KNa+diCfC6lNdL2jTTjsPokYS52E4NuSN5qkVvkpDkwx9LYtRiblIxbkZaB/Thdu8tQKnuyeUuLxkctxq18eVL; 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 1S23xV-0007kV-9v; Mon, 27 Feb 2012 10:01:57 -0700 Message-ID: <4F4BB704.2020208@labn.net> Date: Mon, 27 Feb 2012 12:01:56 -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: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@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] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 17:02:04 -0000 Daniele, See below. On 2/27/2012 11:39 AM, Daniele Ceccarelli wrote: > Hi Lou, > > My replies in line. > > Thanks, > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: luned 27 febbraio 2012 17.08 >> To: Daniele Ceccarelli >> Cc: CCAMP >> Subject: Re: [CCAMP] Fwd: I-D Action: >> draft-berger-ccamp-swcaps-update-00.txt >> >> Daniele, >> Thanks for the comments. Please see responses below. >> >> On 2/27/2012 9:51 AM, Daniele Ceccarelli wrote: >>> Hi Lou, Julien, >>> >>> I had a look at the ID. It is a good work and definitely something we >> needed to put some order in past so to have solid bases for the future. >>> >>> Please find some notes/comments/questions below: >>> >>> 1. PSC deprecation - agree >>> >>> 2. Revised Switiching Type definition - agree with a question >>> - "A different Switching Type SHOULD be used for each data plane >>> technology even when those technologies share the same type of >>> multiplexing or switching." Does this mean that e.g. SDH and OTN, >>> despite sharing same type of switching SHOULD use different >> Switching >>> type? >> >> For *future* technology definitions, yes, as they may use >> different SCSIs. > > OK, it was just a confirmation. So OTN is a future technology :-) Future, as in what the working group works on *after* the new approach in the draft is accepted by the working group.... > >> >>> What is not clear to me is "same type of multiplexing" could you >>> please clarify? >>> >> >> The text currently provides the following example: >> For example, Time Division Multiplexing (TDM) technologies that >> have different multiplexing structures should use two different >> Switching Types. >> >> Is this not sufficiently clear? Can you suggest some >> clarifying text as I'm not sure what else to say? > > What was not clear to me was whether you were referring to: > 1. different muxing technology between SDH and OTN > 2. different muxing technology within SDH or within OTN. > In case 2. different OTN muxing hierarchies (e.g. ODU1->ODU2 and ODU1->ODU3)should have a different Switching Type for each muxing hierarchy. > I assume you were refering to case 1. and suggest the following text: So I interpret this as not liking the phrase "multiplexing structures". I took this term from ITU-T documents. For example, take a look at Page 8 of G.707 pr page 16 of G.709, both show "Multiplexing structure", which are clearly not shared. I think it's beneficial to reuse the terminology used in the definitions of the data plane, rather than try to come up with something new. > > OLD: > For example, Time Division Multiplexing (TDM) technologies that > have different multiplexing structures should use two different > Switching Types. > NEW: > For example, different Time Division Multiplexing (TDM) technologies > should use different Switching Types. How about: For example, Time Division Multiplexing (TDM) technologies that have different multiplexing structures, such as SDH [G.707] and OTN [G.709], should use two different Switching Types. > >> >>> 3. "Additionally, a different Switching Type MUST be used to >> indicate >>> different Switching Capability specific information field formats." >>> >>> - This is potentially non future proof. If we have one to >> one mapping >>> between the Switching Type and the SCSI the SCSI design MUST >> be future >>> proof, otherwise we fall back in the issue of the Min LSP bandwidth >>> SCSI linked to Switch Cap TDM. Maybe avoiding this 1:1 mapping but >>> allowing a 1:N would prevent this problem to happening. >> >> I think you may be misinterpreting our intent. Does the >> following rephrasing cover your concern: >> >> OLD: >> Additionally, a different Switching Type MUST be used to >> indicate different Switching Capability specific information >> field formats. >> NEW: >> As the format of the Switching Capability specific information >> field is dependent on the value of this field, a different >> Switching Type value MUST be used to differentiate between >> different >> Switching Capability specific information field formats. > > Perfect > >> >> This doesn't mean that two technologies (and two Switching >> Type value) can't share the same SCSI format. Just that when >> there are two SCSI formats, two different Switching Types must >> be used. This is already an implicit requirement in [RFC4203] >> and [RFC5307]. >> >>> >>> 4. It is not clear to me how the ILH field is used. From my >>> understanding there is a mapping as follows (i'm considering the OTN >>> as example) ODU0 --> Switch Type=OTN; ILH=1 >>> ODU1 --> Switch Type=OTN; ILH=2 >>> ODU2 --> Switch Type=OTN; ILH=3 >>> ... >>> This would imply advertising 1 ISCD for each "signal type" instead of >> 1 ISCD for each "muxing hierarchy" as it is now stated in >> draft-ospf-g709v3. Is my understanding correct? >>> >> >> Given that maturity level of this (our) draft, I would not >> recommend any changes to gmpls-ospf-g709v3 at this time. >> >> That said, if you want to use gmpls-ospf-g709v3 as an example, >> ILH would be set to match the Signal Type of the #stages=0 TLV >> carried in the ISCD/SCSI. As I read the gmpls-ospf-g709v3, >> gmpls-ospf-g709v3 already precludes the advertisement of >> different Signal Type at the #stages=0 in the same ISCD, so >> there would be no change in number of advertised ISCDs due to >> the use of ILH field in this example. > > Again a misunderstanding from my side, but i think it is worth spending few more words to identify the meaning of the ILH. > > A suggestion: > > OLD: > In order to support hierarchical switching within a particular data > plane technology in routing, this section defines a Intra-Layer > Hierarchy, or ILH, field. This field allows for representation of up > to 15 layers of hierarchical switching. The ILH field is carried in > a portion of the previously defined reserved field of the Interface > Switching Capability Descriptor and has the following format: > > NEW: > In order to support hierarchical switching within a particular data > plane technology in routing, this section defines a Intra-Layer > Hierarchy, or ILH, field. This field allows for representation of up > to 15 layers of hierarchical switching. The ILH field represent the > bottom most layer of the multiplexing hierarchy and is carried in > a portion of the previously defined reserved field of the Interface > Switching Capability Descriptor and has the following format: > How about: ... This field allows for representation of up to 15 layers of hierarchical switching. It, for example, can represent the bottom most layer of a multiplexing hierarchy. The ILH field is carried... Thanks again, Lou >> >> Lou >> >>> Thanks, >>> Daniele >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Lou Berger >>>> Sent: marted 21 febbraio 2012 15.32 >>>> To: CCAMP >>>> Subject: [CCAMP] Fwd: I-D Action: >>>> draft-berger-ccamp-swcaps-update-00.txt >>>> >>>> All, >>>> This draft was motivated by the OTN discussion in >> December. The >>>> general issue raised by that discussion was how should we (the WG) >>>> assign Switching types going forward. At the time, my proposal was >>>> that we should follow general precedent, i.e., per hierarchy level >>>> assignment ala PSC-N. The problem with this, as John and the others >>>> pointed out, is that there is also precedent for per >> technology type >>>> assignment. >>>> The discussion left off with my commitment to submit a draft on the >>>> general topic, which is the draft mentioned below. >>>> >>>> The intent of this draft is to clearly establish which >> precedent will >>>> be followed in the future. Our proposal is that we follow per >>>> technology type assignment, i.e., a Switching type value whenever >>>> there may be a different SCSI, and remove any relationship to >>>> hierarchy from this field. We also propose to deprecate >> PSC-2,3 & 4. >>>> For compatibility sake, we do not propose changing any >> other existing >>>> Switching type values. >>>> >>>> Obviously, comments are welcome and desired. >>>> >>>> Lou (as co-author) >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt >>>> Date: Tue, 21 Feb 2012 06:23:55 -0800 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Revised Definition of The GMPLS >>>> Switching Capability >>>> and Type Fields >>>> Author(s) : Lou Berger >>>> Julien Meuric >>>> Filename : draft-berger-ccamp-swcaps-update-00.txt >>>> Pages : 9 >>>> Date : 2012-02-21 >>>> >>>> GMPLS provides control for multiple switching technologies, and >>>> hierarchical switching within a technology. GMPLS routing and >>>> signaling use common values to indicate switching technology type. >>>> These values are carried in routing in the Switching Capability >>>> field, and in signaling in the Switching Type field. While the >>>> values using in these fields are the primary indicators of the >>>> technology and hierarchy level being controlled, the values are >>>> not consistently defined and used across the different >>>> technologies supported by GMPLS. This document is intended to >>>> resolve the inconsistent definition and use of the Switching >>>> Capability and Type fields by narrowly scoping the meaning and use >>>> of the fields. This document updates any document that uses the >>>> GMPLS Switching Capability and Types fields, in particular RFC >>>> 3471, RFC 4202, RFC 4203, and RFC 5307. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-u >>>> pdate-00.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-berger-ccamp-swcaps-up >>>> date-00.txt >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories: http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>> >>> >>> >> >> > > > From tnadeau@lucidvision.com Mon Feb 27 13:13:09 2012 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 2AB5921E8040 for ; Mon, 27 Feb 2012 13:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, 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 j6yXGV8ByUyQ for ; Mon, 27 Feb 2012 13:13:08 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3699921E803A for ; Mon, 27 Feb 2012 13:13:08 -0800 (PST) Received: from [192.168.1.53] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id B6CF615370A for ; Mon, 27 Feb 2012 16:13:07 -0500 (EST) From: Thomas Nadeau Content-Type: multipart/alternative; boundary="Apple-Mail=_B23545ED-7EC2-4AF3-B58B-0EE03754A549" Date: Mon, 27 Feb 2012 16:13:07 -0500 Message-Id: <736EFB16-389E-4E1C-8604-C973C5B3CE60@lucidvision.com> To: ccamp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [CCAMP] The MPLS 2012 International Conference Call For Papers 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, 27 Feb 2012 21:13:09 -0000 --Apple-Mail=_B23545ED-7EC2-4AF3-B58B-0EE03754A549 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The MPLS 2012 International Conference, the 15th Annual International Conference on MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2012/call_for_papers/cfp.htm Many of these topics have been of interest to members of in the past, and many people active on this list have been presenters at past events. On behalf of the Technical Planning Committee --Apple-Mail=_B23545ED-7EC2-4AF3-B58B-0EE03754A549 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The MPLS 2012 International = Conference, the 15th Annual International
31, 2012, in Washington, DC. The Technical Program = Committee is
soliciting abstracts summarizing a = proposed presentation representing
original/unpublished = work covering cutting-edge topics.

Presentations covering new technologies and = operational experience are
solicited from network = equipment vendors, service/transport providers,
government = agencies, the research community, and enterprise users.
The deadline for submission of presentation = proposals is April 30, 2012.
If you want further = information on MPLS 2012 or want to submit a
presentation = abstract, please see the following URL:

Many of these topics have = been of interest to members of <this community>

On behalf of the Technical Planning = Committee
= --Apple-Mail=_B23545ED-7EC2-4AF3-B58B-0EE03754A549-- From jdrake@juniper.net Mon Feb 27 13:28:04 2012 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 7FB9E21E8042 for ; Mon, 27 Feb 2012 13:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[AWL=1.698, 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 4PltVxVI7L3Z for ; Mon, 27 Feb 2012 13:28:04 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id A896D21E803B for ; Mon, 27 Feb 2012 13:28:03 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT0v1YChfIvw9pxxyAzMQdDkCaLCeXV6b@postini.com; Mon, 27 Feb 2012 13:28:03 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, 27 Feb 2012 13:26:36 -0800 From: John E Drake To: Lou Berger , Daniele Ceccarelli Date: Mon, 27 Feb 2012 13:26:34 -0800 Thread-Topic: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Thread-Index: Acz1agel5eK/U9ReR9O79yqEN/ytyQAEI//A Message-ID: <5E893DB832F57341992548CDBB333163A55CE2CB3C@EMBX01-HQ.jnpr.net> References: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> In-Reply-To: <4F4BAA6E.9070106@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 21:28:04 -0000 Snipped, comments inline >=20 > Given that maturity level of this (our) draft, I would not recommend > any > changes to gmpls-ospf-g709v3 at this time. >=20 > That said, if you want to use gmpls-ospf-g709v3 as an example, ILH > would > be set to match the Signal Type of the #stages=3D0 TLV carried in the > ISCD/SCSI. As I read the gmpls-ospf-g709v3, gmpls-ospf-g709v3 already > precludes the advertisement of different Signal Type at the #stages=3D0 > in > the same ISCD, so there would be no change in number of advertised > ISCDs > due to the use of ILH field in this example. >=20 [JD] This is the same problem I have had all along. Viz, you are explicit= ly equating trunk bandwidth with layer boundaries. =20 I have yet to hear anyone articulate why this is necessary or useful, and e= ven if it were necessary or useful, advertising an explicit field is duplic= ative because we *already* advertise trunk bandwidth, and hence in this for= mulation, layer boundaries. If an implementation were to decide that havin= g an explicit field was necessary or useful, it could easily be included in= their internal data structures without cluttering the advertisements. As an aside, PSC 1-4 did not do this. Instead, PSC 1-4 was an entirely log= ical concept, which meant that the network designer could place the layer b= oundaries wherever they wished. Thanks, John From lberger@labn.net Mon Feb 27 14:24:29 2012 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 39F5A21F84F4 for ; Mon, 27 Feb 2012 14:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.391 X-Spam-Level: X-Spam-Status: No, score=-99.391 tagged_above=-999 required=5 tests=[AWL=0.770, 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 cGAhY15yMxun for ; Mon, 27 Feb 2012 14:24:28 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 5160921F84F2 for ; Mon, 27 Feb 2012 14:24:28 -0800 (PST) Received: (qmail 17287 invoked by uid 0); 27 Feb 2012 22:24:28 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 27 Feb 2012 22:24:28 -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=U9I9gPQaAj+vu8xczRiRrQ9HG+wkVTE9SVOMKON36Qg=; b=yybLMzNPvbVQfY6Xcc3zPDmoVfUPaQaPwhUCnjzvMBgvxTA7yxsyLlh0+MbKhFI29l29TgXB40ci98spJ3cK13WhN5K3TD7aOzeN455WBuBBTkiCLcyw6EPkF0lCA6oY; 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 1S28zb-0000tF-Q6; Mon, 27 Feb 2012 15:24:28 -0700 Message-ID: <4F4C029A.30409@labn.net> Date: Mon, 27 Feb 2012 17:24: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: John E Drake References: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> <5E893DB832F57341992548CDBB333163A55CE2CB3C@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A55CE2CB3C@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] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 22:24:29 -0000 On 2/27/2012 4:26 PM, John E Drake wrote: > Snipped, comments inline > >> >> Given that maturity level of this (our) draft, I would not recommend >> any >> changes to gmpls-ospf-g709v3 at this time. >> >> That said, if you want to use gmpls-ospf-g709v3 as an example, ILH >> would >> be set to match the Signal Type of the #stages=0 TLV carried in the >> ISCD/SCSI. As I read the gmpls-ospf-g709v3, gmpls-ospf-g709v3 already >> precludes the advertisement of different Signal Type at the #stages=0 >> in >> the same ISCD, so there would be no change in number of advertised >> ISCDs >> due to the use of ILH field in this example. >> > > [JD] This is the same problem I have had all along. Viz, you are > explicitly equating trunk bandwidth with layer boundaries. > > I have yet to hear anyone articulate why this is necessary or useful, > and even if it were necessary or useful, advertising an explicit > field is duplicative because we *already* advertise trunk bandwidth, > and hence in this formulation, layer boundaries. If an > implementation were to decide that having an explicit field was > necessary or useful, it could easily be included in their internal > data structures without cluttering the advertisements. > > As an aside, PSC 1-4 did not do this. Instead, PSC 1-4 was an > entirely logical concept, which meant that the network designer could > place the layer boundaries wherever they wished. > John, Yes. MPLS and label stacking are wonderfully flexible technologies. Unfortunately, SDH and OTN are not as flexible and there is a fixed multiplexing structure. (See page pgs 16 & 17 of G.709, there are only a finite number of mappings down to the physical layer.) ILH *could* be used to represent this, or it could *not*. This is a discussion for the future as all the draft says at this point is: The mapping of ILH values to specific levels of hierarchy within a data plane technology is specific to each switching technology and is therefore outside the scope of this document. and I previously said, "I would not recommend any changes to gmpls-ospf-g709v3 at this time." So we really can leave this argument until such time as someone makes a proposal on using ILH with OTN... Lou > Thanks, > > John > > > > From jdrake@juniper.net Mon Feb 27 15:54:50 2012 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 5853921F8542 for ; Mon, 27 Feb 2012 15:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 tagged_above=-999 required=5 tests=[AWL=1.658, 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 oW7dDIDAsQmw for ; Mon, 27 Feb 2012 15:54:49 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA18421F853A for ; Mon, 27 Feb 2012 15:54:48 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT0wXxdGVQSoerWAFQ5h8S0Nc+1EvWcCy@postini.com; Mon, 27 Feb 2012 15:54:48 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 27 Feb 2012 15:51:26 -0800 From: John E Drake To: Lou Berger Date: Mon, 27 Feb 2012 15:51:26 -0800 Thread-Topic: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Thread-Index: Acz1npTVemqXNlxHSTmwBLP5CL8BYQACW5cA Message-ID: <5E893DB832F57341992548CDBB333163A55CE2CD66@EMBX01-HQ.jnpr.net> References: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> <5E893DB832F57341992548CDBB333163A55CE2CB3C@EMBX01-HQ.jnpr.net> <4F4C029A.30409@labn.net> In-Reply-To: <4F4C029A.30409@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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: Mon, 27 Feb 2012 23:54:50 -0000 Snipped, comments inline > > > > [JD] This is the same problem I have had all along. Viz, you are > > explicitly equating trunk bandwidth with layer boundaries. > > > > I have yet to hear anyone articulate why this is necessary or useful, > > and even if it were necessary or useful, advertising an explicit > > field is duplicative because we *already* advertise trunk bandwidth, > > and hence in this formulation, layer boundaries. If an > > implementation were to decide that having an explicit field was > > necessary or useful, it could easily be included in their internal > > data structures without cluttering the advertisements. > > > > As an aside, PSC 1-4 did not do this. Instead, PSC 1-4 was an > > entirely logical concept, which meant that the network designer could > > place the layer boundaries wherever they wished. > > >=20 > John, >=20 > Yes. MPLS and label stacking are wonderfully flexible technologies. > Unfortunately, SDH and OTN are not as flexible and there is a fixed > multiplexing structure. (See page pgs 16 & 17 of G.709, there are only > a finite number of mappings down to the physical layer.) [JD] You didn't actually answer any of my points but rather just re-asserte= d that a layer indicator is needed and that layers correspond to trunk band= widths. I continue to find both assertions questionable as we didn't need = a layer indicator in SDH/SONET and people far more knowledgeable than eithe= r you or I have said it is unnecessary in OTN. To put it another way, if a TE advertisement contained a layer indicator, w= hat *exactly* would you differently in your processing of such an advertise= ment? >=20 > ILH *could* be used to represent this, or it could *not*. This is a > discussion for the future as all the draft says at this point is: >=20 > The mapping of ILH values to specific > levels of hierarchy within a data plane technology is specific to > each switching technology and is therefore outside the scope of this > document. [JD] This presupposes that a mapping of ILH values to specific levels of h= ierarchy is either necessary or useful. =20 >=20 > and I previously said, "I would not recommend any changes to > gmpls-ospf-g709v3 at this time." So we really can leave this argument > until such time as someone makes a proposal on using ILH with OTN... [JD] Your email to which I initially responded proposed *exactly* this. If= no one knows how ILH is to be used, why are we introducing it?=20 >=20 > Lou >=20 >=20 > > Thanks, > > > > John >=20 > > > > > > > > From zhang.fei3@zte.com.cn Tue Feb 28 01:46:27 2012 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 32DAB21F8691; Tue, 28 Feb 2012 01:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.888 X-Spam-Level: X-Spam-Status: No, score=-96.888 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_92=0.6, 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 N6i9fLd3YcUJ; Tue, 28 Feb 2012 01:46:26 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5921F8678; Tue, 28 Feb 2012 01:46:25 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 122801461793122; Tue, 28 Feb 2012 17:15:33 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 63083.3183536426; Tue, 28 Feb 2012 17:46:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q1S9k77c060647; Tue, 28 Feb 2012 17:46:07 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <5E893DB832F57341992548CDBB333163A55CE2CD66@EMBX01-HQ.jnpr.net> To: Lou Berger , John E Drake MIME-Version: 1.0 X-KeepSent: 378585B6:6B7E1CB6-482579B2:0031284F; 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, 28 Feb 2012 17:46:06 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-28 17:46:09, Serialize complete at 2012-02-28 17:46:09 Content-Type: multipart/alternative; boundary="=_alternative 0035A688482579B2_=" X-MAIL: mse01.zte.com.cn q1S9k77c060647 Cc: CCAMP , ccamp-bounces@ietf.org Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 28 Feb 2012 09:46:27 -0000 This is a multipart message in MIME format. --=_alternative 0035A688482579B2_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTG91LCBKb2huDQoNCkkgYW0gY29uZnVzZWQgd2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIElM SCBhbHNvLCB0cnkgdG8gZmlndXJlIG91dCBpdCANCmJhc2VkIG9uIHRoZSBleGFjdCBleGFtcGxl IChsaWtlIE9UTiwgd2hpY2ggaXMgdGhlIGhvdCB0b3BpYyBkaXNjdXNzZWQgDQpyZWNlbnRseSku DQoNCkJlbG93IGlzIG15IHVuZGVyc3RhbmRpbmcgcHJvdmlkZWQgZm9yIGRpc2N1c3Npb24sIHBs ZWFzZSBkbyBub3QgaGVzaXRhdGUgDQp0byBsZXQgbWUga25vdyBpZiBpdCBpcyB3cm9uZy4NCg0K KDEpIFRoZSBJU0NEIG9mIHRoZSBPRFVLL09UVUsgaXMgbm90IGNoYW5nZWQgZXhjZXB0IHRoYXQg dGhlIGFkZGVkIElMSCANCmZpZWxkIGFuZCBtb3ZpbmcgdGhlIE1heCBMU1AgQmFuZHdpZHRoIHBl ciBwcmlvcml0eSBhcyBhIFRMViBpbnRvIHRoZSBTQ1NJIA0KVExWPw0KDQooMikgVGhlIElTQ0Qg b2YgdGhlIE9EVWogaXMgcmVmbGVjdGVkIGJ5IHRoZSBJTEggKGZvciBleGFtcGxlIDEgT0RVMS8y IA0KT0RVMi8zIE9EVTMvNCBPRFU0LyA4IE9EVTAvIDkgT0RVMmUvMTAgT0RVZmxleCBDQlIuLi4p IGFuZCB0aGUgVExWIA0KY2FycnlpbmcgdGhlIHVucmVzZXJ2ZWQgYmFuZHdpZHRoIGxvb2tzIGxp a2U/DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgfCAgUmVzZXJ2ZWQgICAgIHwgTnVtIG9mIHN0YWdlcyB8VHxT fCBUU0cgfCBSZXMgfCAgIFByaW9yaXR5ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgIFN0YWdl IzEgICAgfCAgICAgIC4uLiAgICAgIHwgICBTdGFnZSNOICAgICB8ICAgIFBhZGRpbmcgICAgfA0K ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgIHwgICAgIFVucmVzIE9EVWogYXQgUHJpbyAwICAgICAgfCAgICAgVW5y ZXMgT0RVaiBhdCBQcmlvIDEgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgVW5yZXMgT0RV aiBhdCBQcmlvIDIgICAgICB8ICAgICBVbnJlcyBPRFVqIGF0IFByaW8gMyAgICAgIHwNCiAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICB8ICAgICBVbnJlcyBPRFVqIGF0IFByaW8gNCAgICAgIHwgICAgIFVucmVzIE9E VWogYXQgUHJpbyA1ICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgIFVucmVzIE9EVWogYXQg UHJpbyA2ICAgICAgfCAgICAgVW5yZXMgT0RVaiBhdCBQcmlvIDcgICAgICB8DQogICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KTm90ZXM6IA0KKDEpIFRoZSBzdHJ1Y3R1cmUgaXMgY29waWVkIGZyb20gdGhlIGRyYWZ0IA0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5 djMtMDEudHh0IHdpdGggbm8gDQpzaWdhbCB0eXBlIHRoZXJlLg0KDQooMikgRm9yIHRoZSB0cnVu ayBPRFVLLCBib3RoIE1heCBhbmQgVW5yZXNlcnZlZCBUTFYgU0hPVUxEIGJlIGNhcnJpZWQgd2l0 aCANCnRoZSBzYW1lIElTQ0QgaGVhZGVyLg0KDQooM6OpVGhlIElBQ0QgaXMgY2hhbmdlZCBsaWtl Pw0KDQpDb25zaWRlciBhbiBpbnRlcmZhY2Ugd2hpY2ggc3VwcG9ydCBPVE4gYW5kIFNESCBzd2l0 Y2hpbmcsb3IgT1ROIGFuZCANCnBhY2tldCBzd2l0Y2hpbmcuDQpUaGUgVkMtNCBmcmFtZXMvR0ZQ IGZyYW1lcyBjYW4gYmUgbWFwcGVkIGRpcmVjdGx5IGludG8gT0RVMCwgYnV0IE9EVTEgaXMgDQpm b3JiaWRkZW4gKGxvY2FsIHBvbGljZXMpLg0KSW4gdGhpcyBjYXNlLCB0aGUgTG93ZXIgSUxIIHdp bGwgYmUgdXNlZnVsLg0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8IFVw cGVyIFNDICAgICAgfCBVcHBlciBFbmNvZGluZ3wgUmVzZXJ2ZWQgICAgICAgICAgICB8VXBwZXIg SUxIfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgIHwgTG93ZXIgU0MgICAgICB8IExvd2VyIEVuY29kaW5nfCBS ZXNlcnZlZCAgICAgICAgICAgfExvd2VyIElMSCB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQpOb3RlczogdGhl IG90aGVyIHBhcnRzIGlzIHNuaXBwZWQgaGVyZS4gYW5kIHRoZSBYUk8gDQoNCg0KQmVzdCByZWdh cmRzDQoNCkZlaQ0KDQoNCg0KSm9obiBFIERyYWtlIDxqZHJha2VAanVuaXBlci5uZXQ+IA0Kt6K8 /sjLOiAgY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMi0wMi0yOCAwNzo1MQ0KDQrK1bz+yMsN CkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQqzrcvNDQpDQ0FNUCA8Y2NhbXBAaWV0Zi5v cmc+DQrW98ziDQpSZTogW0NDQU1QXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWJlcmdlci1jY2Ft cC1zd2NhcHMtdXBkYXRlLTAwLnR4dA0KDQoNCg0KDQoNCg0KU25pcHBlZCwgY29tbWVudHMgaW5s aW5lDQoNCj4gPg0KPiA+IFtKRF0gIFRoaXMgaXMgdGhlIHNhbWUgcHJvYmxlbSBJIGhhdmUgaGFk IGFsbCBhbG9uZy4gIFZpeiwgeW91IGFyZQ0KPiA+IGV4cGxpY2l0bHkgZXF1YXRpbmcgdHJ1bmsg YmFuZHdpZHRoIHdpdGggbGF5ZXIgYm91bmRhcmllcy4NCj4gPg0KPiA+IEkgaGF2ZSB5ZXQgdG8g aGVhciBhbnlvbmUgYXJ0aWN1bGF0ZSB3aHkgdGhpcyBpcyBuZWNlc3Nhcnkgb3IgdXNlZnVsLA0K PiA+IGFuZCBldmVuIGlmIGl0IHdlcmUgbmVjZXNzYXJ5IG9yIHVzZWZ1bCwgYWR2ZXJ0aXNpbmcg YW4gZXhwbGljaXQNCj4gPiBmaWVsZCBpcyBkdXBsaWNhdGl2ZSBiZWNhdXNlIHdlICphbHJlYWR5 KiBhZHZlcnRpc2UgdHJ1bmsgYmFuZHdpZHRoLA0KPiA+IGFuZCBoZW5jZSBpbiB0aGlzIGZvcm11 bGF0aW9uLCBsYXllciBib3VuZGFyaWVzLiAgSWYgYW4NCj4gPiBpbXBsZW1lbnRhdGlvbiB3ZXJl IHRvIGRlY2lkZSB0aGF0IGhhdmluZyBhbiBleHBsaWNpdCBmaWVsZCB3YXMNCj4gPiBuZWNlc3Nh cnkgb3IgdXNlZnVsLCBpdCBjb3VsZCBlYXNpbHkgYmUgaW5jbHVkZWQgaW4gdGhlaXIgaW50ZXJu YWwNCj4gPiBkYXRhIHN0cnVjdHVyZXMgd2l0aG91dCBjbHV0dGVyaW5nIHRoZSBhZHZlcnRpc2Vt ZW50cy4NCj4gPg0KPiA+IEFzIGFuIGFzaWRlLCBQU0MgMS00IGRpZCBub3QgZG8gdGhpcy4gIElu c3RlYWQsIFBTQyAxLTQgd2FzIGFuDQo+ID4gZW50aXJlbHkgbG9naWNhbCBjb25jZXB0LCB3aGlj aCBtZWFudCB0aGF0IHRoZSBuZXR3b3JrIGRlc2lnbmVyIGNvdWxkDQo+ID4gcGxhY2UgdGhlIGxh eWVyIGJvdW5kYXJpZXMgd2hlcmV2ZXIgdGhleSB3aXNoZWQuDQo+ID4NCj4gDQo+IEpvaG4sDQo+ IA0KPiBZZXMuICBNUExTIGFuZCBsYWJlbCBzdGFja2luZyBhcmUgd29uZGVyZnVsbHkgZmxleGli bGUgdGVjaG5vbG9naWVzLg0KPiBVbmZvcnR1bmF0ZWx5LCBTREggYW5kIE9UTiBhcmUgbm90IGFz IGZsZXhpYmxlIGFuZCB0aGVyZSBpcyBhIGZpeGVkDQo+IG11bHRpcGxleGluZyBzdHJ1Y3R1cmUu ICAoU2VlIHBhZ2UgcGdzIDE2ICYgMTcgb2YgRy43MDksIHRoZXJlIGFyZSBvbmx5DQo+IGEgZmlu aXRlIG51bWJlciBvZiBtYXBwaW5ncyBkb3duIHRvIHRoZSBwaHlzaWNhbCBsYXllci4pDQoNCltK RF0gWW91IGRpZG4ndCBhY3R1YWxseSBhbnN3ZXIgYW55IG9mIG15IHBvaW50cyBidXQgcmF0aGVy IGp1c3QgDQpyZS1hc3NlcnRlZCB0aGF0IGEgbGF5ZXIgaW5kaWNhdG9yIGlzIG5lZWRlZCBhbmQg dGhhdCBsYXllcnMgY29ycmVzcG9uZCB0byANCnRydW5rIGJhbmR3aWR0aHMuICBJIGNvbnRpbnVl IHRvIGZpbmQgYm90aCBhc3NlcnRpb25zIHF1ZXN0aW9uYWJsZSBhcyB3ZSANCmRpZG4ndCBuZWVk IGEgbGF5ZXIgaW5kaWNhdG9yIGluIFNESC9TT05FVCBhbmQgcGVvcGxlIGZhciBtb3JlIA0Ka25v d2xlZGdlYWJsZSB0aGFuIGVpdGhlciB5b3Ugb3IgSSBoYXZlIHNhaWQgaXQgaXMgdW5uZWNlc3Nh cnkgaW4gT1ROLg0KDQpUbyBwdXQgaXQgYW5vdGhlciB3YXksIGlmIGEgVEUgYWR2ZXJ0aXNlbWVu dCBjb250YWluZWQgYSBsYXllciBpbmRpY2F0b3IsIA0Kd2hhdCAqZXhhY3RseSogd291bGQgeW91 IGRpZmZlcmVudGx5IGluIHlvdXIgcHJvY2Vzc2luZyBvZiBzdWNoIGFuIA0KYWR2ZXJ0aXNlbWVu dD8NCg0KPiANCj4gSUxIICpjb3VsZCogYmUgdXNlZCB0byByZXByZXNlbnQgdGhpcywgb3IgaXQg Y291bGQgKm5vdCouICBUaGlzIGlzIGENCj4gZGlzY3Vzc2lvbiBmb3IgdGhlIGZ1dHVyZSBhcyBh bGwgdGhlIGRyYWZ0IHNheXMgYXQgdGhpcyBwb2ludCBpczoNCj4gDQo+ICAgIFRoZSBtYXBwaW5n IG9mIElMSCB2YWx1ZXMgdG8gc3BlY2lmaWMNCj4gICAgbGV2ZWxzIG9mIGhpZXJhcmNoeSB3aXRo aW4gYSBkYXRhIHBsYW5lIHRlY2hub2xvZ3kgaXMgc3BlY2lmaWMgdG8NCj4gICAgZWFjaCBzd2l0 Y2hpbmcgdGVjaG5vbG9neSBhbmQgaXMgdGhlcmVmb3JlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMNCj4gICAgZG9jdW1lbnQuDQoNCltKRF0gIFRoaXMgcHJlc3VwcG9zZXMgdGhhdCBhIG1hcHBp bmcgb2YgSUxIIHZhbHVlcyB0byBzcGVjaWZpYyBsZXZlbHMgb2YgDQpoaWVyYXJjaHkgaXMgZWl0 aGVyIG5lY2Vzc2FyeSBvciB1c2VmdWwuIA0KDQo+IA0KPiBhbmQgSSBwcmV2aW91c2x5IHNhaWQs ICJJIHdvdWxkIG5vdCByZWNvbW1lbmQgYW55IGNoYW5nZXMgdG8NCj4gZ21wbHMtb3NwZi1nNzA5 djMgYXQgdGhpcyB0aW1lLiIgIFNvIHdlIHJlYWxseSBjYW4gbGVhdmUgdGhpcyBhcmd1bWVudA0K PiB1bnRpbCBzdWNoIHRpbWUgYXMgc29tZW9uZSBtYWtlcyBhIHByb3Bvc2FsIG9uIHVzaW5nIElM SCB3aXRoIE9UTi4uLg0KDQpbSkRdIFlvdXIgZW1haWwgdG8gd2hpY2ggSSBpbml0aWFsbHkgcmVz cG9uZGVkIHByb3Bvc2VkICpleGFjdGx5KiB0aGlzLiBJZiANCm5vIG9uZSBrbm93cyBob3cgSUxI IGlzIHRvIGJlIHVzZWQsIHdoeSBhcmUgd2UgaW50cm9kdWNpbmcgaXQ/IA0KDQo+IA0KPiBMb3UN Cj4gDQo+IA0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IEpvaG4NCj4gDQo+ID4NCj4gPg0KPiA+DQo+ ID4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FN UCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KDQo= --=_alternative 0035A688482579B2_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIExvdSwgSm9objwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBjb25mdXNlZCB3 aXRoIHRoZSBpbnRyb2R1Y3Rpb24NCm9mIElMSCBhbHNvLCB0cnkgdG8gZmlndXJlIG91dCBpdCBi YXNlZCBvbiB0aGUgZXhhY3QgZXhhbXBsZSAobGlrZSBPVE4sDQp3aGljaCBpcyB0aGUgaG90IHRv cGljIGRpc2N1c3NlZCByZWNlbnRseSkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5CZWxvdyBpcyBteSB1bmRlcnN0YW5kaW5nIHByb3ZpZGVkIGZvcg0K ZGlzY3Vzc2lvbiwgcGxlYXNlIGRvIG5vdCBoZXNpdGF0ZSB0byBsZXQgbWUga25vdyBpZiBpdCBp cyB3cm9uZy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PigxKSBUaGUgSVNDRCBvZiB0aGUgT0RVSy9PVFVLIGlzIG5vdA0KY2hhbmdlZCBleGNlcHQgdGhh dCB0aGUgYWRkZWQgSUxIIGZpZWxkIGFuZCBtb3ZpbmcgdGhlIE1heCBMU1AgQmFuZHdpZHRoDQpw ZXIgcHJpb3JpdHkgYXMgYSBUTFYgaW50byB0aGUgU0NTSSBUTFY/PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4oMikgVGhlIElTQ0Qgb2YgdGhlIE9EVWog aXMgcmVmbGVjdGVkDQpieSB0aGUgSUxIIChmb3IgZXhhbXBsZSAxIE9EVTEvMiBPRFUyLzMgT0RV My80IE9EVTQvIDggT0RVMC8gOSBPRFUyZS8xMA0KT0RVZmxleCBDQlIuLi4pIGFuZCB0aGUgVExW IGNhcnJ5aW5nIHRoZSB1bnJlc2VydmVkIGJhbmR3aWR0aCBsb29rcyBsaWtlPzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOystKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mj4mbmJzcDsgJm5ic3A7fCAmbmJzcDtSZXNlcnZlZCAmbmJzcDsgJm5ic3A7IHwgTnVtIG9m IHN0YWdlcw0KfFR8U3wgVFNHIHwgUmVzIHwgJm5ic3A7IFByaW9yaXR5ICZuYnNwOyAmbmJzcDt8 PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7Ky0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDtTdGFnZSMxICZuYnNw OyAmbmJzcDt8ICZuYnNwOw0KJm5ic3A7ICZuYnNwOy4uLiAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7IFN0YWdlI04gJm5ic3A7ICZuYnNwOyB8ICZuYnNwOw0KJm5ic3A7UGFkZGluZyAmbmJz cDsgJm5ic3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOystKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IFVu cmVzIE9EVWogYXQgUHJpbyAwICZuYnNwOw0KJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyBV bnJlcyBPRFVqIGF0IFByaW8gMSAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+ Jm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyBVbnJlcyBPRFVqIGF0IFByaW8gMiAmbmJzcDsN CiZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgVW5yZXMgT0RVaiBhdCBQcmlvIDMgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7Ky0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgVW5yZXMgT0RVaiBhdCBQcmlvIDQgJm5ic3A7DQombmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5i c3A7IFVucmVzIE9EVWogYXQgUHJpbyA1ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOystKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mj4mbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7IFVucmVzIE9EVWogYXQgUHJpbyA2ICZu YnNwOw0KJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyBVbnJlcyBPRFVqIGF0IFByaW8gNyAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJz cDsrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Tm90 ZXM6IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDEpIFRoZSBz dHJ1Y3R1cmUgaXMgY29waWVkIGZyb20gdGhlDQpkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1vc3BmLWc3MDl2My0wMS50eHQNCndpdGggbm8gc2ln YWwgdHlwZSB0aGVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPigyKSBGb3IgdGhlIHRydW5rIE9EVUssIGJvdGggTWF4IGFuZA0KVW5yZXNlcnZlZCBU TFYgU0hPVUxEIGJlIGNhcnJpZWQgd2l0aCB0aGUgc2FtZSBJU0NEIGhlYWRlci48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPigzo6lUaGUgSUFDRCBpcyBj aGFuZ2VkIGxpa2U/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5Db25zaWRlciBhbiBpbnRlcmZhY2Ugd2hpY2ggc3VwcG9ydA0KT1ROIGFuZCBTREggc3dp dGNoaW5nLG9yIE9UTiBhbmQgcGFja2V0IHN3aXRjaGluZy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBWQy00IGZyYW1lcy9HRlAgZnJhbWVzIGNhbiBiZSBt YXBwZWQNCmRpcmVjdGx5IGludG8gT0RVMCwgYnV0IE9EVTEgaXMgZm9yYmlkZGVuIChsb2NhbCBw b2xpY2VzKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIHRo aXMgY2FzZSwgdGhlIExvd2VyIElMSCB3aWxsIGJlDQp1c2VmdWwuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mj4mbmJzcDsgJm5ic3A7IDAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IDEgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IDIgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDM8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5DQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+Jm5ic3A7ICZuYnNwOystKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4m bmJzcDsgJm5ic3A7fCBVcHBlciBTQyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgVXBwZXIgRW5jb2Rp bmd8DQpSZXNlcnZlZCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3xV cHBlciBJTEh8PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7Ky0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDt8IExvd2VyIFNDICZuYnNwOyAm bmJzcDsgJm5ic3A7fCBMb3dlciBFbmNvZGluZ3wNClJlc2VydmVkICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfExvd2VyIElMSCB8PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj4m bmJzcDsgJm5ic3A7Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPk5vdGVz OiB0aGUgb3RoZXIgcGFydHMgaXMgc25pcHBlZCBoZXJlLiBhbmQgdGhlIFhSTyA8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJk czwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RmVpPC9m b250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkpvaG4g RSBEcmFrZSAmbHQ7amRyYWtlQGp1bmlwZXIubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGll dGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDIt MjggMDc6NTE8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPkNDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Ptb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJl OiBbQ0NBTVBdIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtYmVyZ2VyLWNjYW1wLXN3Y2Fwcy11cGRh dGUtMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5TbmlwcGVkLCBjb21tZW50cyBpbmxpbmU8YnI+DQo8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgW0pEXSAmbmJzcDtUaGlzIGlzIHRoZSBzYW1lIHByb2JsZW0gSSBoYXZl IGhhZCBhbGwgYWxvbmcuICZuYnNwO1ZpeiwNCnlvdSBhcmU8YnI+DQomZ3Q7ICZndDsgZXhwbGlj aXRseSBlcXVhdGluZyB0cnVuayBiYW5kd2lkdGggd2l0aCBsYXllciBib3VuZGFyaWVzLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGhhdmUgeWV0IHRvIGhlYXIgYW55b25lIGFydGlj dWxhdGUgd2h5IHRoaXMgaXMgbmVjZXNzYXJ5IG9yDQp1c2VmdWwsPGJyPg0KJmd0OyAmZ3Q7IGFu ZCBldmVuIGlmIGl0IHdlcmUgbmVjZXNzYXJ5IG9yIHVzZWZ1bCwgYWR2ZXJ0aXNpbmcgYW4gZXhw bGljaXQ8YnI+DQomZ3Q7ICZndDsgZmllbGQgaXMgZHVwbGljYXRpdmUgYmVjYXVzZSB3ZSAqYWxy ZWFkeSogYWR2ZXJ0aXNlIHRydW5rIGJhbmR3aWR0aCw8YnI+DQomZ3Q7ICZndDsgYW5kIGhlbmNl IGluIHRoaXMgZm9ybXVsYXRpb24sIGxheWVyIGJvdW5kYXJpZXMuICZuYnNwO0lmIGFuPGJyPg0K Jmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9uIHdlcmUgdG8gZGVjaWRlIHRoYXQgaGF2aW5nIGFuIGV4 cGxpY2l0IGZpZWxkIHdhczxicj4NCiZndDsgJmd0OyBuZWNlc3Nhcnkgb3IgdXNlZnVsLCBpdCBj b3VsZCBlYXNpbHkgYmUgaW5jbHVkZWQgaW4gdGhlaXIgaW50ZXJuYWw8YnI+DQomZ3Q7ICZndDsg ZGF0YSBzdHJ1Y3R1cmVzIHdpdGhvdXQgY2x1dHRlcmluZyB0aGUgYWR2ZXJ0aXNlbWVudHMuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFzIGFuIGFzaWRlLCBQU0MgMS00IGRpZCBub3Qg ZG8gdGhpcy4gJm5ic3A7SW5zdGVhZCwgUFNDIDEtNA0Kd2FzIGFuPGJyPg0KJmd0OyAmZ3Q7IGVu dGlyZWx5IGxvZ2ljYWwgY29uY2VwdCwgd2hpY2ggbWVhbnQgdGhhdCB0aGUgbmV0d29yayBkZXNp Z25lcg0KY291bGQ8YnI+DQomZ3Q7ICZndDsgcGxhY2UgdGhlIGxheWVyIGJvdW5kYXJpZXMgd2hl cmV2ZXIgdGhleSB3aXNoZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEpv aG4sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFllcy4gJm5ic3A7TVBMUyBhbmQgbGFiZWwgc3RhY2tp bmcgYXJlIHdvbmRlcmZ1bGx5IGZsZXhpYmxlIHRlY2hub2xvZ2llcy48YnI+DQomZ3Q7IFVuZm9y dHVuYXRlbHksIFNESCBhbmQgT1ROIGFyZSBub3QgYXMgZmxleGlibGUgYW5kIHRoZXJlIGlzIGEg Zml4ZWQ8YnI+DQomZ3Q7IG11bHRpcGxleGluZyBzdHJ1Y3R1cmUuICZuYnNwOyhTZWUgcGFnZSBw Z3MgMTYgJmFtcDsgMTcgb2YgRy43MDksDQp0aGVyZSBhcmUgb25seTxicj4NCiZndDsgYSBmaW5p dGUgbnVtYmVyIG9mIG1hcHBpbmdzIGRvd24gdG8gdGhlIHBoeXNpY2FsIGxheWVyLik8YnI+DQo8 YnI+DQpbSkRdIFlvdSBkaWRuJ3QgYWN0dWFsbHkgYW5zd2VyIGFueSBvZiBteSBwb2ludHMgYnV0 IHJhdGhlciBqdXN0IHJlLWFzc2VydGVkDQp0aGF0IGEgbGF5ZXIgaW5kaWNhdG9yIGlzIG5lZWRl ZCBhbmQgdGhhdCBsYXllcnMgY29ycmVzcG9uZCB0byB0cnVuayBiYW5kd2lkdGhzLg0KJm5ic3A7 SSBjb250aW51ZSB0byBmaW5kIGJvdGggYXNzZXJ0aW9ucyBxdWVzdGlvbmFibGUgYXMgd2UgZGlk bid0IG5lZWQNCmEgbGF5ZXIgaW5kaWNhdG9yIGluIFNESC9TT05FVCBhbmQgcGVvcGxlIGZhciBt b3JlIGtub3dsZWRnZWFibGUgdGhhbiBlaXRoZXINCnlvdSBvciBJIGhhdmUgc2FpZCBpdCBpcyB1 bm5lY2Vzc2FyeSBpbiBPVE4uPGJyPg0KPGJyPg0KVG8gcHV0IGl0IGFub3RoZXIgd2F5LCBpZiBh IFRFIGFkdmVydGlzZW1lbnQgY29udGFpbmVkIGEgbGF5ZXIgaW5kaWNhdG9yLA0Kd2hhdCAqZXhh Y3RseSogd291bGQgeW91IGRpZmZlcmVudGx5IGluIHlvdXIgcHJvY2Vzc2luZyBvZiBzdWNoIGFu IGFkdmVydGlzZW1lbnQ/PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElMSCAqY291bGQqIGJl IHVzZWQgdG8gcmVwcmVzZW50IHRoaXMsIG9yIGl0IGNvdWxkICpub3QqLiAmbmJzcDtUaGlzDQpp cyBhPGJyPg0KJmd0OyBkaXNjdXNzaW9uIGZvciB0aGUgZnV0dXJlIGFzIGFsbCB0aGUgZHJhZnQg c2F5cyBhdCB0aGlzIHBvaW50IGlzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 VGhlIG1hcHBpbmcgb2YgSUxIIHZhbHVlcyB0byBzcGVjaWZpYzxicj4NCiZndDsgJm5ic3A7ICZu YnNwO2xldmVscyBvZiBoaWVyYXJjaHkgd2l0aGluIGEgZGF0YSBwbGFuZSB0ZWNobm9sb2d5IGlz DQpzcGVjaWZpYyB0bzxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2VhY2ggc3dpdGNoaW5nIHRlY2hu b2xvZ3kgYW5kIGlzIHRoZXJlZm9yZSBvdXRzaWRlIHRoZQ0Kc2NvcGUgb2YgdGhpczxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO2RvY3VtZW50Ljxicj4NCjxicj4NCltKRF0gJm5ic3A7VGhpcyBwcmVz dXBwb3NlcyB0aGF0IGEgbWFwcGluZyBvZiBJTEggdmFsdWVzIHRvIHNwZWNpZmljIGxldmVscw0K b2YgaGllcmFyY2h5IGlzIGVpdGhlciBuZWNlc3Nhcnkgb3IgdXNlZnVsLiAmbmJzcDs8YnI+DQo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgYW5kIEkgcHJldmlvdXNseSBzYWlkLCAmcXVvdDtJIHdvdWxk IG5vdCByZWNvbW1lbmQgYW55IGNoYW5nZXMgdG88YnI+DQomZ3Q7IGdtcGxzLW9zcGYtZzcwOXYz IGF0IHRoaXMgdGltZS4mcXVvdDsgJm5ic3A7U28gd2UgcmVhbGx5IGNhbiBsZWF2ZQ0KdGhpcyBh cmd1bWVudDxicj4NCiZndDsgdW50aWwgc3VjaCB0aW1lIGFzIHNvbWVvbmUgbWFrZXMgYSBwcm9w b3NhbCBvbiB1c2luZyBJTEggd2l0aCBPVE4uLi48YnI+DQo8YnI+DQpbSkRdIFlvdXIgZW1haWwg dG8gd2hpY2ggSSBpbml0aWFsbHkgcmVzcG9uZGVkIHByb3Bvc2VkICpleGFjdGx5KiB0aGlzLg0K Jm5ic3A7SWYgbm8gb25lIGtub3dzIGhvdyBJTEggaXMgdG8gYmUgdXNlZCwgd2h5IGFyZSB3ZSBp bnRyb2R1Y2luZyBpdD8NCjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBMb3U8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgSm9objxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FN UEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Nh bXA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 0035A688482579B2_=-- From Ben.Wright@metaswitch.com Tue Feb 28 02:35:18 2012 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 169B721F85E1 for ; Tue, 28 Feb 2012 02:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.153 X-Spam-Level: X-Spam-Status: No, score=0.153 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 jbVoTQ59OKUi for ; Tue, 28 Feb 2012 02:35:16 -0800 (PST) Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 002E721F85EC for ; Tue, 28 Feb 2012 02:35:09 -0800 (PST) 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.2.247.3; Tue, 28 Feb 2012 10:35:46 +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.02.0247.003; Tue, 28 Feb 2012 10:35:08 +0000 From: Ben Wright To: Zhangfatai , "draft-zhang-ccamp-gmpls-h-lsp-mln@tools.ietf.org" Thread-Topic: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04 Thread-Index: AQHM7XHRoFhIburGsUeouxnBwPb/GpZHsEaAgAp+D1A= Date: Tue, 28 Feb 2012 10:35:08 +0000 Message-ID: References: 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.71.113] Content-Type: multipart/alternative; boundary="_000_B3B6FD81D3159A45B5421AF9DD500F8846E0ECC7ENFICSMBX1datco_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04 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, 28 Feb 2012 10:35:18 -0000 --_000_B3B6FD81D3159A45B5421AF9DD500F8846E0ECC7ENFICSMBX1datco_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRmF0YWksDQoNClRoYW5rcyBmb3IgeW91ciByZXNwb25zZXMuDQoNCkluIHRlcm1zIG9mIGhv dyB0byBtYWtlIHRoaXMgbW9yZSBleHRlbnNpYmxlLCB0aGVyZSBhcmUgYSBmZXcgb3B0aW9ucy4g ICBJoa9kIHByb2JhYmx5IG9wdCBmb3Igc29tZXRoaW5nIGFsb25nIHRoZSBmb2xsb3dpbmcgbGlu ZXMuDQoNCi0gSSBjYW4gZW52aXNhZ2UgdGhhdCB0aGVyZSBjb3VsZCBiZSBhIGxvdCBvZiBGQS1M U1Atc3BlY2lmaWMgcGFyYW1ldGVycyB0aGF0IHdvdWxkIG5lZWQgdG8gYmUgc2lnbmFsbGVkLCBh bmQgc28gSaGvZCBwcm9wb3NlIHdlIGRvbqGvdCBhZGQgYWxsIHRoZXNlIHBhcmFtZXRlcnMgaW50 byB0aGUgRVJPIGl0c2VsZi4gICBJbnN0ZWFkLCB3ZSBjb3VsZCBkZWZpbmUgdGhlIFNFUlZFUl9M QVlFUl9JTkZPIEVSTyBzdWJvYmplY3Qgc28gaXQganVzdCBpbmRpY2F0ZXMgdGhhdCBhbiBGQS1M U1Agd2l0aCBhIHBhcnRpY3VsYXIgSUQgbXVzdCBiZSBjcmVhdGVkIHRvIHRoZSBuZXh0IEVSTyBo b3AgYnV0IGRvZXMgbm90IGluY2x1ZGUgYW55IFRFIHBhcmFtZXRlcnMgb3IgYWRhcHRhdGlvbiBp bmZvcm1hdGlvbi4NCi0gSaGvZCB0aGVuIGFkZCBhIHNlcGFyYXRlIEZBLUxTUC1JRCBvYmplY3Qs IHdoaWNoIGNhcnJpZXMgYWxsIHRoZSBwYXJhbWV0ZXJzIGZvciB0aGUgRkEtTFNQLiAgIFRoaXMg b2JqZWN0IGNvdWxkIGluY2x1ZGUgYSB2YXJpYWJsZSBudW1iZXIgb2Ygb3RoZXIgUlNWUCBvYmpl Y3RzIChlLmcuIFNFU1NJT04sIFNFTkRFUl9UU1BFQywgRVJPIGV0YykuDQotIEmhr2QgbGlrZSB0 byBpbmNsdWRlIGEgc3RhdGVtZW50IG9uIHRoZSBsaWZldGltZSBvZiB0aGUgRkEtTFNQIKhDIGZv ciBleGFtcGxlLCBpZiBhbiBSU1ZQIFNFU1NJT04gYW5kIFNFTkRFUl9UU1BFQyBvYmplY3Qgd2Vy ZSBtYW5kYXRvcnkgdGhlbiB0aGF0IHdvdWxkIHByb3ZpZGUgaWRlbnRpZmllcnMgZm9yIHRoZSBG QS1MU1AsIGFuZCB0aGVuIHdlIGNvdWxkIHN0YXRlIHRoYXQgdGhlIEZBLUxTUCBzaG91bGQgZXhp c3QgdW50aWwgaXQgaXMgZGVzdHJveWVkIGJ5IG5ldHdvcmsgYWRtaW5pc3RyYXRvcnMuDQoNCldo YXQgZG8geW91IHRoaW5rPyAgSWYgdGhpcyBpcyBub3QgY2xlYXIsIEkgY2FuIHByb3Bvc2Ugc29t ZSBwcm90b2NvbCBmb3JtYXRzIHRvIGhlbHAgaWxsdXN0cmF0ZSB0aGUgcG9pbnQuDQoNCkJlbg0K DQoNCkZyb206IFpoYW5nZmF0YWkgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQpTZW50 OiAyMSBGZWJydWFyeSAyMDEyIDE4OjIxDQpUbzogQmVuIFdyaWdodDsgZHJhZnQtemhhbmctY2Nh bXAtZ21wbHMtaC1sc3AtbWxuQHRvb2xzLmlldGYub3JnDQpDYzogY2NhbXBAaWV0Zi5vcmc7IFN0 ZXZlIEJhbGxzDQpTdWJqZWN0OiC08Li0OiBDb21tZW50cyBvbiBkcmFmdC16aGFuZy1jY2FtcC1n bXBscy1oLWxzcC1tbG4tMDQNCg0KSGkgQmVuLA0KDQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlv bnMgYW5kIGxvb2sgZm9yd2FyZCB0byBkaXNjdXNzaW5nIG1vcmUgb24gdGhpcyB0b3BpYy4NCg0K U2VlIG1vcmUgaW4tbGluZSBiZWxvdy4NCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogQmVuIFdyaWdodCBbQmVuLldyaWdodEBt ZXRhc3dpdGNoLmNvbV0NCreiy83KsbzkOiAyMDEyxOoy1MIxN8jVIDIwOjQzDQq1vTogWmhhbmdm YXRhaTsgZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtaC1sc3AtbWxuQHRvb2xzLmlldGYub3JnPG1h aWx0bzpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1oLWxzcC1tbG5AdG9vbHMuaWV0Zi5vcmc+DQpD YzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPjsgU3RldmUgQmFsbHMNCtb3 zOI6IENvbW1lbnRzIG9uIGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWgtbHNwLW1sbi0wNA0KSGkg RmF0YWksDQoNClRoYW5rcyBmb3IgcG9pbnRpbmcgbWUgYXQgdGhpcyBkcmFmdC4gICBJIGhhdmUg YSBmZXcgcXVlc3Rpb25zIG9uIHRoaXMuDQoNClRoZSBoaWdoZXN0IGxldmVsIGNsYXJpZmljYXRp b24gaXMgdGhhdCBJIHdhc26hr3Qgc3VyZSB3aGV0aGVyIHRoaXMgaXMgZGVzaWduZWQgdG8gYWRk cmVzcyBqdXN0IEZBLUxTUHMgKHdoaWNoIGFyZSBhZHZlcnRpc2VkIGJhY2sgaW50byB0aGUgc2Ft ZSBjb250cm9sIHBsYW5lIGluc3RhbmNlKSBvciBhbnkgSC1MU1AgKHdoaWNoIG1heSBiZSBhZHZl cnRpc2VkIGludG8gYSBkaWZmZXJlbnQgY29udHJvbCBwbGFuZSAvIHJvdXRpbmcgcHJvdG9jb2wg aW5zdGFuY2UsIGlmIGF0IGFsbCk/ICAgSSB0aGluayB0aGF0IHRoZSBkcmFmdCBhZGRyZXNzZXMg SC1MU1BzLCBpcyB0aGF0IHRydWU/DQoNCltGYXRhaV0gVGhpcyBkcmFmdCBkb2VzIG5vdCB0b3Vj aCBob3cgdG8gYWR2ZXJ0aXNlIHRoZSBsaW5rIGZvcm1lZCBieSBILUxTUC4gR2l2ZW4gdGhhdCBI LUxTUCBpcyBicm9hZGVyIHRoYW4gRkEtTFNQLCBzbyBJIHdpbGwgYW5zd2VyICJ5ZXMiIHRvIHlv dXIgcXVlc3Rpb24uDQoNClRoZSByZXN0IG9mIG15IGNvbW1lbnRzIGJyZWFrIGRvd24gaW50byB0 d28gYnJvYWQgYXJlYXM6ICBNYW5hZ2VtZW50IG9mIHRoZSBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQg RkEvSC1MU1BzIGFuZCBleHRlbnNpYmlsaXR5IHRvIGZ1dHVyZSBlbmhhbmNlbWVudHMuDQoNCkZB LUxTUCBNYW5hZ2VtZW50DQoNCkhvdyBkb2VzIGEgbmV0d29yayBhZG1pbmlzdHJhdG9yIG1hbmFn ZSB0aGVzZSBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQgRkEtTFNQcz8gICBJoa9tIGFzc3VtaW5nIHRo YXQgdGhlIHNlcnZlciByZXNvdXJjZSBtYXkgbm90IGFsd2F5cyAodHlwaWNhbGx5PykgYmUgaW4g MToxIGNvcnJlc3BvbmRlbmNlIHdpdGggdGhlIGNsaWVudCByZXNvdXJjZS4gICBJcyB0aGF0IGNv cnJlY3Q/ICBJZiBzbywgSSB0aGluayB0aGF0IHRoaXMgbWVhbnMgdGhhdCB0aGUgRkEtTFNQIGNh bm5vdCBqdXN0IGJlIG1hbmFnZWQgdmlhIHNpZ25hbGxpbmcgdGhlIGNsaWVudCBsYXllciBMU1As IGl0IG11c3QgYmUgYWJsZSB0byBiZSBtYW5hZ2VkIGV4cGxpY2l0bHkgYnkgbmV0d29yayBhZG1p bmlzdHJhdG9ycy4gICBTbywgZm9yIGV4YW1wbGUsIEkgc3VzcGVjdCB3ZaGvbGwgbmVlZCB0byBw cm92aWRlIGEgbWVjaGFuaXNtIHRvIGFsbG93IHRoZSBjbGllbnQgTFNQIHNpZ25hbGxpbmcgdG8g Y2FycnkgYSBzZXQgb2YgaWRlbnRpZmllcnMgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzZXJ2 ZXIgTFNQLCBzbyBuZXR3b3JrIGFkbWluaXN0cmF0b3JzIGNhbiBtYW5hZ2UgaXQgc2VwYXJhdGVs eS4gICBJoa9kIGFsc28gbGlrZSB0byBkZWZpbmUgdGhlIGNvbmRpdGlvbnMgdW5kZXIgd2hpY2gg dGhlIEZBLUxTUCBjYW4gYmUgZGVsZXRlZCAoZS5nLiBzaG91bGQgaXQgYmUgZGVsZXRlZCB3aGVu IHRoZSBjbGllbnQgbGF5ZXIgTFNQIGlzIGRlbGV0ZWQ/KS4NCg0KW0ZhdGFpXSAgWWVzLCBhZ3Jl ZSB3aXRoIHlvdS4gRkEtTFNQIGNyZWF0aW9uIHRyaWdnZXJlZCBieSB0aGUgY2xpZW50IGxheWVy IHNob3VsZCBiZSBnb3Zlcm5lZCBieSB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9ycywgc28gaXQg aXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBtb3JlIGluZm9ybWF0aW9uIGluIHRoZSBzaWduYWxpbmcg Zm9yIHRoZSBwdXJwb3NlIG9mIGFkbWluaXN0cmF0aW9uLg0KDQpFeHRlbnNpYmlsaXR5DQoNCkmh r2QgbGlrZSB1cyB0byB1c2UgYSBtb3JlIGV4dGVuc2libGUgZm9ybWF0IGZvciBlbmNvZGluZyBz ZXJ2ZXIgbGF5ZXIgaW5mb3JtYXRpb24uICBJIGNhbiBzZWUgdGhhdCB0aGUgbWVjaGFuaXNtIGRl c2NyaWJlZCBpbiB0aGUgZHJhZnQgY291bGQgYmUgYXBwbGljYWJsZSB0byBhIHdpZGUgdmFyaWV0 eSBvZiB1c2UgY2FzZXMgaW4gZnV0dXJlIGFuZCB0aGUgRVJPIHN1Ym9iamVjdCBmb3JtYXQgaXNu oa90IGVhc3kgdG8gZXh0ZW5kIHRvIG1lZXQgdGhlbS4gICBTb21lIGV4YW1wbGVzIHdoZXJlIHRo ZXJlIG1pZ2h0IGJlIGEgcmVxdWlyZW1lbnQgdG8gc2lnbmFsIG1vcmUgaW5mb3JtYXRpb24gYXJl IGJlbG93Lg0KDQoxLiAgSXQgY291bGQgYmUgdXNlZnVsIGZvciB0aGUgY2xpZW50LWxheWVyIHNp Z25hbGxpbmcgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IHBhcmFtZXRlcnMgdGhhdCB0aGUgc2VydmVy IGxheWVyIHNob3VsZCB1c2UgdG8gY3JlYXRlIHRoZSBGQS1MU1AuICAgRm9yIGV4YW1wbGUsIGl0 IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGNsaWVudCBsYXllciB0byBiZSBhYmxlIHRvIHNwZWNp ZnkgdGhhdCB0aGUgc2VydmVyIGxheWVyIHNob3VsZCBjcmVhdGUgYW4gRkEtTFNQIHRvIHNoYXJl IHJlc291cmNlcyB3aXRoIGFuIGV4aXN0aW5nIEZBLUxTUC4NCjIuICBUaGUgY2xpZW50LWxheWVy IHNpZ25hbGxpbmcgbWF5IG5lZWQgdG8gYmUgYWJsZSB0byByZXF1ZXN0IHRoZSBzZXJ2ZXIgbGF5 ZXIgY3JlYXRlcyBtdWx0aXBsZSBzZXJ2ZXIgbGF5ZXIgTFNQcyB0byBzdXBwb3J0IHRoZSBjbGll bnQgbGF5ZXIgY29ubmVjdGlvbiAoZS5nLiBpbiBhIFZDQVQgY2FzZSk/DQoNCltGYXRhaV0gIEFn cmVlIHRvIG1ha2luZyB0aGUgZm9ybWF0IG1vcmUgZXh0ZW5zaWJsZS4gSSB3b3VsZCBsaWtlIHRv IGhlYXIgZnJvbSB5b3Ugb24gaG93IHRvIG1ha2UgaXQuDQoNCldoYXQgZG8geW91IHRoaW5rPw0K DQpDaGVlcnMsDQoNCkJlbiAoYW5kIFN0ZXZlKQ0KDQoNCkZyb206IFpoYW5nZmF0YWkgW21haWx0 bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dDQpTZW50OiAwNyBGZWJydWFyeSAyMDEyIDAxOjMwDQpU bzogQmVuIFdyaWdodDsgZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzQHRv b2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5 djNAdG9vbHMuaWV0Zi5vcmc+DQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYu b3JnPg0KU3ViamVjdDogUkU6IFNpZ25hbGluZyBleHRlbnNpb25zIGZvciBGQS1MU1BzIChjb21t ZW50IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0wMSkNCg0KSGkg QmVuLA0KDQpJIGFncmVlZCB3aXRoIHRoZSBzY2VuYXJpbyBhbmQgcmVxdWlyZW1lbnQgeW91IG1l bnRpb25lZC4NCg0KSG93ZXZlciwgSSB0aGluayBpdCBpcyBhIGtpbmQgb2YgZ2VuZXJpYyBNTE4g c2NlbmFyaW8sIG5vdCBqdXN0IHNwZWNpZmljIHRvIE9UTiBzaWduYWxpbmcsIHNvIEkgd2FzIHRy eWluZyB0byBjYXB0dXJlIHRoaXMgaW4gYSBnZW5lcmljIHdheSBhbmQgZG9jdW1lbnRlZCB0aGlz IGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1oLWxz cC1tbG4tMDQudHh0Lg0KDQpQbGVhc2UgcmV2aWV3IHRoaXMgZHJhZnQgKGRyYWZ0LXpoYW5nLWNj YW1wLWdtcGxzLWgtbHNwLW1sbi0wNC50eHQpIHRvIHNlZSBpZiB0aGlzIGRyYWZ0IGNhbiBhZGRy ZXNzIHlvdXIgY29uY2Vybi4NCg0KTGV0oa9zIGRpc2N1c3MgbW9yZSBvbiB0aGlzIGlzc3VlLg0K DQoNCg0KVGhhbmtzDQoNCkZhdGFpDQoNCkZyb206IEJlbiBXcmlnaHQgW21haWx0bzpCZW4uV3Jp Z2h0QG1ldGFzd2l0Y2guY29tXQ0KU2VudDogMjAxMsTqMtTCN8jVIDE6MDUNClRvOiBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2M0B0b29scy5pZXRmLm9yZz4NCkNj OiBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBTaWduYWxp bmcgZXh0ZW5zaW9ucyBmb3IgRkEtTFNQcyAoY29tbWVudCBvbiBkcmFmdC1pZXRmLWNjYW1wLWdt cGxzLXNpZ25hbGluZy1nNzA5djMtMDEpDQoNCkhpIEZhdGFpIGV0IGFsLA0KDQpXZSBoYXZlIGJl ZW4gdGhpbmtpbmcgYWJvdXQgZnVuY3Rpb24gd2Ugd2lsbCBuZWVkIHRvIGFkZCB0byBkcmFmdC1p ZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMDEgdG8gZnVsbHkgc3VwcG9ydCBhdXRv bWF0aWNhbGx5IHByb3Zpc2lvbmVkIEZBLUxTUHMuICAgSSB3YW50ZWQgdG8gc2VlIHdoZXRoZXIg eW91IGFncmVlIHdpdGggb3VyIGFuYWx5c2lzLg0KDQpXZSB0aGluayB0aGF0IHRoZSBSU1ZQLVRF IHNpZ25hbGxpbmcgc2hvdWxkIGJlIGV4dGVuZGVkIHRvIGNhcnJ5IG1vcmUgaW5mb3JtYXRpb24g aW4gb3JkZXIgdG8gYWxsb3cgb3RoZXIgbm9kZXMgb24gdGhlIHNpZ25hbGxpbmcgcGF0aCB0byBz ZXQgdXAgdGhlIGNvcnJlY3QgRkEtTFNQLiAgICBGb3IgZXhhbXBsZSwgaW4gdGhlIG5ldHdvcmsg aW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzLTAxI3NlY3Rpb24tNywgd2UgYmVsaWV2ZSB0aGF0IE4xIHNob3VsZCBiZSBh YmxlIHRvIHByZXNjcmliZSB0byBOMiB0aGUgc2V0IG9mIGhvcHMgdGhhdCBpdCBzaG91bGQgdXNl IHRvIHNldCB1cCB0aGUgT0RVMiBGQS1MU1AsIGFuZCB0aGUgc2lnbmFsIHR5cGUgb2YgdGhlIEZB LUxTUCBpdCBzaG91bGQgc2V0IHVwLCBhbmQgKHByb2JhYmx5KSB0aGUgbXVsdGlwbGV4aW5nIGhp ZXJhcmNoeSB0byBiZSB1c2VkIGF0IGVpdGhlciBlbmQuICAgVHlwaWNhbGx5LCB3ZaGvZCBleHBl Y3QgTjEgd291bGQgd2FudCB0byBleHBsaWNpdGx5IHByZXZlbnQgTjIgZnJvbSBxdWVyeWluZyBy b3V0aW5nIHRvIHNldCB1cCB0aGUgRkEtTFNQICCoQyBvdGhlcndpc2UsIGEgcm91dGluZyBjYWxj dWxhdGlvbiB0cmlnZ2VyZWQgYnkgTjIgY291bGQgY29tcHV0ZSBhIHBhdGggZm9yIHRoZSBGQS1M U1AgaW5jb25zaXN0ZW50IHdpdGggTjGhr3MgaW50ZW50aW9ucyAoZS5nLiB3aGljaCBjb3VsZCBi cmVhayBzb21lIFNSTEcgZGl2ZXJzaXR5IHJlcXVpcmVtZW50KS4NCg0KV2hhdCBkbyB5b3UgdGhp bms/ICAgSXMgdGhpcyBhbiBpc3N1ZSB0aGF0IHlvdSBhbnRpY2lwYXRlIGFkZHJlc3NpbmcgaW4g dGhlIHRleHQgZm9yIHNlY3Rpb24gNy4xIChhbGx1ZGVkIHRvIGFzIGJlaW5nIGZvciBmdXR1cmUg c3R1ZHkpPw0KDQpUaGFua3MsDQoNCkJlbiBXcmlnaHQgYW5kIFN0ZXZlIEJhbGxzDQoNCg== --_000_B3B6FD81D3159A45B5421AF9DD500F8846E0ECC7ENFICSMBX1datco_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Fatai, <= /span>

 

Thanks for your respon= ses.  

 

In terms of how to mak= e this more extensible, there are a few options.   I=A1=AFd proba= bly opt for something along the following lines.  

 

- I can envisage that = there could be a lot of FA-LSP-specific parameters that would need to be si= gnalled, and so I=A1=AFd propose we don=A1=AFt add all these parameters int= o the ERO itself.   Instead, we could define the SERVER_LAYER_INFO ERO subobject so it just indicates that an FA-LSP with a= particular ID must be created to the next ERO hop but does not include any= TE parameters or adaptation information.

- I=A1=AFd then add a = separate FA-LSP-ID object, which carries all the parameters for the FA-LSP.=    This object could include a variable number of other RSVP obje= cts (e.g. SESSION, SENDER_TSPEC, ERO etc). 

- I=A1=AFd like to inc= lude a statement on the lifetime of the FA-LSP =A8C for example, if an RSVP= SESSION and SENDER_TSPEC object were mandatory then that would provide ide= ntifiers for the FA-LSP, and then we could state that the FA-LSP should exist until it is destroyed by network administrato= rs. 

 

What do you think? &nb= sp;If this is not clear, I can propose some protocol formats to help illust= rate the point.    

 

Ben<= /p>

 

 

From: Zhangfatai [mailto:zhangfatai@huawei.com]
Sent: 21 February 2012 18:21
To: Ben Wright; draft-zhang-ccamp-gmpls-h-lsp-mln@tools.ietf.org
Cc: ccamp@ietf.org; Steve Balls
Subject: =B4=F0=B8=B4: Comments on = draft-zhang-ccamp-gmpls-h-lsp-mln-04

 

Hi Ben,=

 

Thanks = for your suggestions and look forward to discussing more on this topic.

 

See mor= e in-line below.

 

Thanks<= /span>

 

Fatai

 

 

=B7=A2=BC=FE= =C8=CB: Ben Wright [Ben.Wright@metaswitch.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA2=D4=C217=C8=D5=B5=BD: Zhangfatai; draft-zhang-ccamp-gmpls-h-lsp-mln@tools.ietf.org
Cc: ccamp@ietf.org; Steve Ball= s
=D6=F7=CC=E2: Comments on draft-zhang-ccamp-gmpls-h-lsp-mln-04

Hi Fatai,

 

Thanks for pointing me= at this draft.   I have a few questions on this. 

 

The highest level clar= ification is that I wasn=A1=AFt sure whether this is designed to address ju= st FA-LSPs (which are advertised back into the same control plane instance) or any H-LSP (which may be advertised into a different control p= lane / routing protocol instance, if at all)?   I think that the = draft addresses H-LSPs, is that true?

 =

[Fatai] This draft does n= ot touch how to advertise the link formed by H-LSP. Given that H-LSP is bro= ader than FA-LSP, so I will answer "yes" to your question.=

 

The rest of my comment= s break down into two broad areas:  Management of the automatically cr= eated FA/H-LSPs and extensibility to future enhancements.

 

FA-LSP Management

 

How does a network adm= inistrator manage these automatically created FA-LSPs?   I=A1=AFm= assuming that the server resource may not always (typically?) be in 1:1 correspondence with the client resource.   Is that correct? = ; If so, I think that this means that the FA-LSP cannot just be managed via= signalling the client layer LSP, it must be able to be managed explicitly = by network administrators.   So, for example, I suspect we=A1=AFll need to provide a mechanism to allow the client LSP sig= nalling to carry a set of identifiers to be associated with the server LSP,= so network administrators can manage it separately.   I=A1=AFd a= lso like to define the conditions under which the FA-LSP can be deleted (e.g. should it be deleted when the client layer LSP is del= eted?).   

 =

[Fatai]  Yes, agree with you= . FA-LSP creation triggered by the client layer should be governed by the network administrators, so it is a good idea to have more information = in the signaling for the purpose of administration.

 =

Extensibility

 

I=A1=AFd like us to us= e a more extensible format for encoding server layer information.  I c= an see that the mechanism described in the draft could be applicable to a wide variety of use cases in future and the ERO subobject format isn= =A1=AFt easy to extend to meet them.   Some examples where there = might be a requirement to signal more information are below.

 

1.  It could be u= seful for the client-layer signalling to be able to specify parameters that= the server layer should use to create the FA-LSP.   For example, it would be useful for the client layer to be able to specify that the ser= ver layer should create an FA-LSP to share resources with an existing FA-LS= P. 

2.  The client-la= yer signalling may need to be able to request the server layer creates mult= iple server layer LSPs to support the client layer connection (e.g. in a VCAT case)? 

 

[Fatai]  Agree to ma= king the format more extensible. I would like to hear from you on how to ma= ke it. 

 =

What do you think?

 

Cheers,

 

Ben (and Steve)=

 

 

From: Zhangfatai [mailto:zhangfatai@huawei.com]
Sent: 07 February 2012 01:30
To: Ben Wright; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Cc: ccamp@ietf.org
Subject: RE: Signaling extensions for FA-LSPs (comment on draft-ietf= -ccamp-gmpls-signaling-g709v3-01)

 =

Hi Ben,

 

I agreed = with the scenario and requirement you mentioned.

 

However, = I think it is a kind of generic MLN scenario, not just specific to OTN sign= aling, so I was trying to capture this in a generic way and documented this in http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt.

 

Please re= view this draft (draft-zhang-ccamp-gmpls-h-lsp-mln-04.txt) to see if this d= raft can address your concern.

 

Let=A1=AF= s discuss more on this issue.=

 

 

 

Thanks  
Fatai

 

From: Ben Wright [mailto:Ben.Wright@metaswitch.= com]
Sent: 2012=C4=EA2=D4=C27=C8=D5 1:05
To: draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org
Cc: ccamp@ietf.o= rg
Subject: Signaling extensions for FA-LSPs (comment on draft-ietf-cca= mp-gmpls-signaling-g709v3-01)=

 

Hi Fatai et al,

 =

We have been thinking ab= out function we will need to add to draft-ietf-ccamp-gmpls-signaling-g709v3= -01 to fully support automatically provisioned FA-LSPs.   I wanted to see whether you agree with our analysis. 

 =

We think that the RSVP-T= E signalling should be extended to carry more information in order to allow= other nodes on the signalling path to set up the correct FA-LSP.    For example, in the network in http://tools.ietf.org/html/draft-ietf-ccamp-gmp= ls-signaling-g709v3-01#section-7, we believe that N1 should be a= ble to prescribe to N2 the set of hops that it should use to set up the ODU= 2 FA-LSP, and the signal type of the FA-LSP it should set up, and (probably) the multiplexing hierarchy to be u= sed at either end.   Typically, we=A1=AFd expect N1 would want to= explicitly prevent N2 from querying routing to set up the FA-LSP  =A8= C otherwise, a routing calculation triggered by N2 could compute a path for the FA-LSP inconsistent with N1=A1=AFs intentions (e.g.= which could break some SRLG diversity requirement).    &nbs= p; 

 =

What do you think?  = ; Is this an issue that you anticipate addressing in the text for sect= ion 7.1 (alluded to as being for future study)?   

 =

Thanks,

 =

Ben Wright and Steve Bal= ls

 =

--_000_B3B6FD81D3159A45B5421AF9DD500F8846E0ECC7ENFICSMBX1datco_-- From daniele.ceccarelli@ericsson.com Tue Feb 28 03:10:52 2012 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 A4A0A21F85FC for ; Tue, 28 Feb 2012 03:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.262 X-Spam-Level: X-Spam-Status: No, score=-9.262 tagged_above=-999 required=5 tests=[AWL=1.337, 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 611wWQqoi6NI for ; Tue, 28 Feb 2012 03:10:51 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3735F21F85FB for ; Tue, 28 Feb 2012 03:10:49 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-32-4f4cb6377ded Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 76.6C.01970.736BC4F4; Tue, 28 Feb 2012 12:10:48 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.18]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 28 Feb 2012 12:10:47 +0100 From: Daniele Ceccarelli To: Lou Berger , "jdrake@juniper.net" Date: Tue, 28 Feb 2012 12:10:46 +0100 Thread-Topic: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Thread-Index: Acz1cYUq6L60A5RsScGKJWalWdDvHAAlOyXQ Message-ID: References: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> <4F4BB704.2020208@labn.net> In-Reply-To: <4F4BB704.2020208@labn.net> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: CCAMP Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 28 Feb 2012 11:10:52 -0000 Lou, Comments to your previous replies in line and a further consideration here: What i'm really interested in is not loosing the pieces of information that= have been added to the OTN SCSI (muxing hierarchies and relationship betwe= en the various layers) and the introduction of the ILH as currently defined= does not affect it, so i'm not against it.=20 Nevertheless i find no reason to be in favour of it because, as John does, = can't really see any advantage it introduces or any problem it solves. Coul= d you please explain what is the rationale behind introducing it?=20 Thanks, Daniele >-----Original Message----- >From: Lou Berger [mailto:lberger@labn.net]=20 >Sent: luned=EC 27 febbraio 2012 18.02 >To: Daniele Ceccarelli >Cc: CCAMP >Subject: Re: [CCAMP] Fwd: I-D Action:=20 >draft-berger-ccamp-swcaps-update-00.txt > >Daniele, > See below. > > >On 2/27/2012 11:39 AM, Daniele Ceccarelli wrote: >> Hi Lou, >>=20 >> My replies in line. >>=20 >> Thanks, >> Daniele >>=20 >>> -----Original Message----- >>> From: Lou Berger [mailto:lberger@labn.net] >>> Sent: luned=EC 27 febbraio 2012 17.08 >>> To: Daniele Ceccarelli >>> Cc: CCAMP >>> Subject: Re: [CCAMP] Fwd: I-D Action:=20 >>> draft-berger-ccamp-swcaps-update-00.txt >>> >>> Daniele, >>> Thanks for the comments. Please see responses below. >>> >>> On 2/27/2012 9:51 AM, Daniele Ceccarelli wrote: >>>> Hi Lou, Julien, >>>> >>>> I had a look at the ID. It is a good work and definitely something=20 >>>> we >>> needed to put some order in past so to have solid bases for=20 >the future. >>>> >>>> Please find some notes/comments/questions below: >>>> >>>> 1. PSC deprecation - agree >>>> >>>> 2. Revised Switiching Type definition - agree with a question >>>> - "A different Switching Type SHOULD be used for each data plane=20 >>>> technology even when those technologies share the same type of=20 >>>> multiplexing or switching." Does this mean that e.g. SDH and OTN,=20 >>>> despite sharing same type of switching SHOULD use different >>> Switching >>>> type? >>> >>> For *future* technology definitions, yes, as they may use different=20 >>> SCSIs. >>=20 >> OK, it was just a confirmation. So OTN is a future technology :-) > >Future, as in what the working group works on *after* the new=20 >approach in the draft is accepted by the working group.... OK, what i mean is that, given that SDH uses SC=3D100 and OTN uses SC=3D101= , the OTN draft is already compliant to what is stated here. > >>=20 >>> >>>> What is not clear to me is "same type of multiplexing" could you=20 >>>> please clarify? >>>> >>> >>> The text currently provides the following example: >>> For example, Time Division Multiplexing (TDM) technologies that =20 >>> have different multiplexing structures should use two different =20 >>> Switching Types. >>> >>> Is this not sufficiently clear? Can you suggest some=20 >clarifying text=20 >>> as I'm not sure what else to say? >>=20 >> What was not clear to me was whether you were referring to: >> 1. different muxing technology between SDH and OTN 2.=20 >different muxing=20 >> technology within SDH or within OTN. >> In case 2. different OTN muxing hierarchies (e.g. ODU1->ODU2=20 >and ODU1->ODU3)should have a different Switching Type for each=20 >muxing hierarchy. >> I assume you were refering to case 1. and suggest the following text: > >So I interpret this as not liking the phrase "multiplexing structures". > I took this term from ITU-T documents. For example, take a=20 >look at Page 8 of G.707 pr page 16 of G.709, both show=20 >"Multiplexing structure", which are clearly not shared. I=20 >think it's beneficial to reuse the terminology used in the=20 >definitions of the data plane, rather than try to come up with=20 >something new. It might be misleading for me, but once that it is clear that different ult= iplexing structure means intertechnology structures and not intratechnology= ones i agree on keeping alignment with ITU-T docs. > >>=20 >> OLD: >> For example, Time Division Multiplexing (TDM) technologies that >> have different multiplexing structures should use two different >> Switching Types. >> NEW: >> For example, different Time Division Multiplexing (TDM)=20 >technologies >> should use different Switching Types. > >How about: > For example, Time Division Multiplexing (TDM) technologies that > have different multiplexing structures, such as SDH [G.707] and > OTN [G.709], should use two different Switching Types. OK >>=20 >>> >>>> 3. "Additionally, a different Switching Type MUST be used to >>> indicate >>>> different Switching Capability specific information field formats." >>>> >>>> - This is potentially non future proof. If we have one to >>> one mapping >>>> between the Switching Type and the SCSI the SCSI design MUST >>> be future >>>> proof, otherwise we fall back in the issue of the Min LSP=20 >bandwidth=20 >>>> SCSI linked to Switch Cap TDM. Maybe avoiding this 1:1 mapping but=20 >>>> allowing a 1:N would prevent this problem to happening. >>> >>> I think you may be misinterpreting our intent. Does the following=20 >>> rephrasing cover your concern: >>> >>> OLD: >>> Additionally, a different Switching Type MUST be used to >>> indicate different Switching Capability specific information >>> field formats. >>> NEW: >>> As the format of the Switching Capability specific information >>> field is dependent on the value of this field, a different >>> Switching Type value MUST be used to differentiate between=20 >>> different >>> Switching Capability specific information field formats. >>=20 >> Perfect >>=20 >>> >>> This doesn't mean that two technologies (and two Switching Type=20 >>> value) can't share the same SCSI format. Just that when there are=20 >>> two SCSI formats, two different Switching Types must be used. This=20 >>> is already an implicit requirement in [RFC4203] and [RFC5307]. >>> >>>> >>>> 4. It is not clear to me how the ILH field is used. From my=20 >>>> understanding there is a mapping as follows (i'm=20 >considering the OTN=20 >>>> as example) ODU0 --> Switch Type=3DOTN; ILH=3D1 >>>> ODU1 --> Switch Type=3DOTN; ILH=3D2 >>>> ODU2 --> Switch Type=3DOTN; ILH=3D3 >>>> ... >>>> This would imply advertising 1 ISCD for each "signal type"=20 >instead of >>> 1 ISCD for each "muxing hierarchy" as it is now stated in=20 >>> draft-ospf-g709v3. Is my understanding correct? >>>> >>> >>> Given that maturity level of this (our) draft, I would not=20 >>> recommend any changes to gmpls-ospf-g709v3 at this time. >>> >>> That said, if you want to use gmpls-ospf-g709v3 as an example,=20 >>> ILH would be set to match the Signal Type of the #stages=3D0 TLV=20 >>> carried in the ISCD/SCSI. As I read the gmpls-ospf-g709v3,=20 >>> gmpls-ospf-g709v3 already precludes the advertisement of=20 >>> different Signal Type at the #stages=3D0 in the same ISCD, so=20 >>> there would be no change in number of advertised ISCDs due to=20 >>> the use of ILH field in this example. >>=20 >> Again a misunderstanding from my side, but i think it is=20 >worth spending few more words to identify the meaning of the ILH. >>=20 >> A suggestion: >>=20 >> OLD: >> In order to support hierarchical switching within a=20 >particular data >> plane technology in routing, this section defines a Intra-Layer >> Hierarchy, or ILH, field. This field allows for=20 >representation of up >> to 15 layers of hierarchical switching. The ILH field is=20 >carried in >> a portion of the previously defined reserved field of the=20 >Interface >> Switching Capability Descriptor and has the following format: >>=20 >> NEW: >> In order to support hierarchical switching within a=20 >particular data >> plane technology in routing, this section defines a Intra-Layer >> Hierarchy, or ILH, field. This field allows for=20 >representation of up >> to 15 layers of hierarchical switching. The ILH field=20 >represent the=20 >> bottom most layer of the multiplexing hierarchy and is carried in >> a portion of the previously defined reserved field of the=20 >Interface >> Switching Capability Descriptor and has the following format: >>=20 > >How about: > ... This field allows for > representation of up to 15 layers of hierarchical switching. It, > for example, can represent the bottom most layer of a > multiplexing hierarchy. The ILH field is carried... Ok, but the comment on its usefulness still needs to be addressed. >Thanks again, >Lou > >>> >>> Lou >>> >>>> Thanks, >>>> Daniele >>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>> Behalf Of Lou Berger >>>>> Sent: marted=EC 21 febbraio 2012 15.32 >>>>> To: CCAMP >>>>> Subject: [CCAMP] Fwd: I-D Action: >>>>> draft-berger-ccamp-swcaps-update-00.txt >>>>> >>>>> All, >>>>> This draft was motivated by the OTN discussion in=20 >>> December. The=20 >>>>> general issue raised by that discussion was how should we=20 >(the WG)=20 >>>>> assign Switching types going forward. At the time, my=20 >proposal was=20 >>>>> that we should follow general precedent, i.e., per=20 >hierarchy level=20 >>>>> assignment ala PSC-N. The problem with this, as John and=20 >the others=20 >>>>> pointed out, is that there is also precedent for per=20 >>> technology type=20 >>>>> assignment. >>>>> The discussion left off with my commitment to submit a=20 >draft on the=20 >>>>> general topic, which is the draft mentioned below. >>>>> >>>>> The intent of this draft is to clearly establish which=20 >>> precedent will=20 >>>>> be followed in the future. Our proposal is that we follow per=20 >>>>> technology type assignment, i.e., a Switching type value whenever=20 >>>>> there may be a different SCSI, and remove any relationship to=20 >>>>> hierarchy from this field. We also propose to deprecate=20 >>> PSC-2,3 & 4. =20 >>>>> For compatibility sake, we do not propose changing any=20 >>> other existing=20 >>>>> Switching type values. >>>>> >>>>> Obviously, comments are welcome and desired. >>>>> >>>>> Lou (as co-author) >>>>> >>>>> -------- Original Message -------- >>>>> Subject: I-D Action: draft-berger-ccamp-swcaps-update-00.txt >>>>> Date: Tue, 21 Feb 2012 06:23:55 -0800 >>>>> From: internet-drafts@ietf.org >>>>> Reply-To: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line=20 >Internet-Drafts=20 >>>>> directories. >>>>> >>>>> Title : Revised Definition of The GMPLS >>>>> Switching Capability >>>>> and Type Fields >>>>> Author(s) : Lou Berger >>>>> Julien Meuric >>>>> Filename : draft-berger-ccamp-swcaps-update-00.txt >>>>> Pages : 9 >>>>> Date : 2012-02-21 >>>>> >>>>> GMPLS provides control for multiple switching technologies, and >>>>> hierarchical switching within a technology. GMPLS routing and >>>>> signaling use common values to indicate switching=20 >technology type. >>>>> These values are carried in routing in the Switching Capability >>>>> field, and in signaling in the Switching Type field. While the >>>>> values using in these fields are the primary indicators of the >>>>> technology and hierarchy level being controlled, the values are >>>>> not consistently defined and used across the different >>>>> technologies supported by GMPLS. This document is intended to >>>>> resolve the inconsistent definition and use of the Switching >>>>> Capability and Type fields by narrowly scoping the=20 >meaning and use >>>>> of the fields. This document updates any document that uses the >>>>> GMPLS Switching Capability and Types fields, in particular RFC >>>>> 3471, RFC 4202, RFC 4203, and RFC 5307. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-berger-ccamp-swcaps-u >>>>> pdate-00.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-berger-ccamp-swcaps-up >>>>> date-00.txt >>>>> >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> I-D-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>> >>>> >>>> >>> >>> >>=20 >>=20 >>=20 >= From lberger@labn.net Tue Feb 28 04:25:57 2012 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 C10F621F8587 for ; Tue, 28 Feb 2012 04:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.406 X-Spam-Level: X-Spam-Status: No, score=-99.406 tagged_above=-999 required=5 tests=[AWL=0.755, 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 G1ZgQTSeFIFe for ; Tue, 28 Feb 2012 04:25:56 -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 C897C21F8545 for ; Tue, 28 Feb 2012 04:25:56 -0800 (PST) Received: (qmail 26431 invoked by uid 0); 28 Feb 2012 12:25:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 28 Feb 2012 12:25:55 -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=KvYxVJhWdGlJt71cNZuQdDA2lL3u3ivk3xFrzJ9FUMY=; b=dQTvjyP+loZmRg2KuPZ1NiZSDlD0hiOMHUJkgw+N/3zcGkWXd4ySjHftEcsk3BojgFML+4EMqZhYIYT/DpAmZxzY1YcF/y6ZZdNfp9JrBdem7UOvl0KN6TWlETegqwU9; 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 1S2M7v-0005fD-1K; Tue, 28 Feb 2012 05:25:55 -0700 Message-ID: <4F4CC7D1.6090907@labn.net> Date: Tue, 28 Feb 2012 07:25:53 -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: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> <5E893DB832F57341992548CDBB333163A55CE2CB3C@EMBX01-HQ.jnpr.net> <4F4C029A.30409@labn.net> <5E893DB832F57341992548CDBB333163A55CE2CD66@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A55CE2CD66@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] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 28 Feb 2012 12:25:57 -0000 John, On 2/27/2012 6:51 PM, John E Drake wrote: >> So we really can leave this argument >> > until such time as someone makes a proposal on using ILH with OTN... > [JD] Your email to which I initially responded proposed *exactly* this. You seemed to have missed the point of my mail. Daniele asked if introduction to ILH would require to the OTN SCSI format. My response was no, and I tried to illustrate why. My mistake for providing too much information. Again, the key points from my response to him: from 2/27/2012 11:08 AM, Lou Berger wrote: > Given that maturity level of this (our) draft, I would not recommend > any changes to gmpls-ospf-g709v3 at this time. and > so there would be no change in number of advertised ISCDs > due to the use of ILH field in this example. and On 2/27/2012 5:24 PM, Lou Berger wrote: > ILH *could* be used to represent this, or it could *not*. This is a > discussion for the future as all the draft says at this point is: > > The mapping of ILH values to specific > levels of hierarchy within a data plane technology is specific to > each switching technology and is therefore outside the scope of > this document. > Just to be clear, I'll say it again. I'm not proposing the use of ILH for OTN at this time. (Might I do so in the future? Possibly, but I really don't know what form such a proposal would take as the the use and definition of ILH is still a work in progress. I'm not yet sure such a proposal makes sense for OTN, from a technical perspective, and it certainly doesn't make sense at this point from a procedural perspective.) Lou From lberger@labn.net Tue Feb 28 04:38:18 2012 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 A597F21F863C for ; Tue, 28 Feb 2012 04:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.596 X-Spam-Level: X-Spam-Status: No, score=-97.596 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_51=0.6, J_CHICKENPOX_92=0.6, MIME_CHARSET_FARAWAY=2.45, 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 0jcOmId3hA0a for ; Tue, 28 Feb 2012 04:38:17 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 7404D21F862F for ; Tue, 28 Feb 2012 04:38:17 -0800 (PST) Received: (qmail 11861 invoked by uid 0); 28 Feb 2012 12:38:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 28 Feb 2012 12:38: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=/8yrcjtym+g4V2xT8690CPuhaoyQU8+rDDXtviTQ0Oo=; b=pYBynjo4I7PxI+mFQFYkKzL/9roKJrCHQFI1TCKFZWtxXu3O/fK66SDCP2aGodRoSCj2yLKpwAD/thAV/btX8KPlaX4EUmhxrNu5bvhsXW9pJoxfIM9gNI894j7FzWWK; 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 1S2MJs-0000zy-2q; Tue, 28 Feb 2012 05:38:16 -0700 Message-ID: <4F4CCAB6.7050002@labn.net> Date: Tue, 28 Feb 2012 07:38:14 -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: zhang.fei3@zte.com.cn References: In-Reply-To: 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: CCAMP Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 28 Feb 2012 12:38:18 -0000 Fei, Per my last message. The introduction of ILH does not require, or proposal, any change to the WG OTN documents. (Although it does imply the use of a new Switching Type for OTNv3 -- which is already in the drafts.) If someone wants to propose changes to the OTN drafts based on ILH, that's fine, but such a proposal is *not* in our draft. Lou On 2/28/2012 4:46 AM, zhang.fei3@zte.com.cn wrote: > > Hi Lou, John > > I am confused with the introduction of ILH also, try to figure out it > based on the exact example (like OTN, which is the hot topic discussed > recently). > > Below is my understanding provided for discussion, please do not > hesitate to let me know if it is wrong. > > (1) The ISCD of the ODUK/OTUK is not changed except that the added ILH > field and moving the Max LSP Bandwidth per priority as a TLV into the > SCSI TLV? > > (2) The ISCD of the ODUj is reflected by the ILH (for example 1 ODU1/2 > ODU2/3 ODU3/4 ODU4/ 8 ODU0/ 9 ODU2e/10 ODUflex CBR...) and the TLV > carrying the unreserved bandwidth looks like? > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | Num of stages |T|S| TSG | Res | Priority | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Stage#1 | ... | Stage#N | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unres ODUj at Prio 0 | Unres ODUj at Prio 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unres ODUj at Prio 2 | Unres ODUj at Prio 3 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unres ODUj at Prio 4 | Unres ODUj at Prio 5 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Unres ODUj at Prio 6 | Unres ODUj at Prio 7 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Notes: > (1) The structure is copied from the draft > http://tools.ietf.org/id/draft-ietf-ccamp-gmpls-ospf-g709v3-01.txt with > no sigal type there. > > (2) For the trunk ODUK, both Max and Unreserved TLV SHOULD be carried > with the same ISCD header. > > (3）The IACD is changed like? > > Consider an interface which support OTN and SDH switching,or OTN and > packet switching. > The VC-4 frames/GFP frames can be mapped directly into ODU0, but ODU1 is > forbidden (local polices). > In this case, the Lower ILH will be useful. > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Upper SC | Upper Encoding| Reserved |Upper ILH| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lower SC | Lower Encoding| Reserved |Lower ILH | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Notes: the other parts is snipped here. and the XRO > > > Best regards > > Fei > > > *John E Drake * > 发件人: ccamp-bounces@ietf.org > > 2012-02-28 07:51 > > > 收件人 > Lou Berger > 抄送 > CCAMP > 主题 > Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt > > > > > > > > > Snipped, comments inline > >> > >> > [JD] This is the same problem I have had all along. Viz, you are >> > explicitly equating trunk bandwidth with layer boundaries. >> > >> > I have yet to hear anyone articulate why this is necessary or useful, >> > and even if it were necessary or useful, advertising an explicit >> > field is duplicative because we *already* advertise trunk bandwidth, >> > and hence in this formulation, layer boundaries. If an >> > implementation were to decide that having an explicit field was >> > necessary or useful, it could easily be included in their internal >> > data structures without cluttering the advertisements. >> > >> > As an aside, PSC 1-4 did not do this. Instead, PSC 1-4 was an >> > entirely logical concept, which meant that the network designer could >> > place the layer boundaries wherever they wished. >> > >> >> John, >> >> Yes. MPLS and label stacking are wonderfully flexible technologies. >> Unfortunately, SDH and OTN are not as flexible and there is a fixed >> multiplexing structure. (See page pgs 16 & 17 of G.709, there are only >> a finite number of mappings down to the physical layer.) > > [JD] You didn't actually answer any of my points but rather just > re-asserted that a layer indicator is needed and that layers correspond > to trunk bandwidths. I continue to find both assertions questionable as > we didn't need a layer indicator in SDH/SONET and people far more > knowledgeable than either you or I have said it is unnecessary in OTN. > > To put it another way, if a TE advertisement contained a layer > indicator, what *exactly* would you differently in your processing of > such an advertisement? > >> >> ILH *could* be used to represent this, or it could *not*. This is a >> discussion for the future as all the draft says at this point is: >> >> The mapping of ILH values to specific >> levels of hierarchy within a data plane technology is specific to >> each switching technology and is therefore outside the scope of this >> document. > > [JD] This presupposes that a mapping of ILH values to specific levels > of hierarchy is either necessary or useful. > >> >> and I previously said, "I would not recommend any changes to >> gmpls-ospf-g709v3 at this time." So we really can leave this argument >> until such time as someone makes a proposal on using ILH with OTN... > > [JD] Your email to which I initially responded proposed *exactly* this. > If no one knows how ILH is to be used, why are we introducing it? > >> >> Lou >> >> >> > Thanks, >> > >> > John >> >> > >> > >> > >> > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From lberger@labn.net Tue Feb 28 05:27:32 2012 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 DE88221F8605 for ; Tue, 28 Feb 2012 05:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.4 X-Spam-Level: X-Spam-Status: No, score=-99.4 tagged_above=-999 required=5 tests=[AWL=0.761, 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 g1OZeO49ds6y for ; Tue, 28 Feb 2012 05:27:32 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 3702321F859A for ; Tue, 28 Feb 2012 05:27:32 -0800 (PST) Received: (qmail 2961 invoked by uid 0); 28 Feb 2012 13:27:31 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 28 Feb 2012 13:27:31 -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=2HW1bjgC8I6mjwRSsbzTEaeB/n5Z0UjH+kgqkrC2GMQ=; b=PYMFNAwaD6toOFsit2J9LTgRjkPcjiQ+glQ4XU/qITgJxD+4obdKeiEtqlm4gnl9WXklCkfsG1/BhfS7Bpbqth9j6haao7B5zIWAP0c9D9iRli+imGAul2siy49s2ZTA; 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 1S2N5X-00081H-9P; Tue, 28 Feb 2012 06:27:31 -0700 Message-ID: <4F4CD642.4000709@labn.net> Date: Tue, 28 Feb 2012 08:27:30 -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: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> <4F4BB704.2020208@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 Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 28 Feb 2012 13:27:33 -0000 On 2/28/2012 6:10 AM, Daniele Ceccarelli wrote: >... > Could you please explain what is the rationale > behind introducing it? > ... Daniele, Now this is a good question! The ILH field is motivated by the WG goal of identifying and defining common control plane mechanisms for different data plane technologies. This draft says it this way: Multiple switching technologies support forms of hierarchical switching within a particular data plane technology. As discussed above, GMPLS routing originally envisioned support for such cases for packet networks using PSC-2, 3, 4. In other cases, GMPLS defined support using technology specific mechanisms, for example Signal Type was defined for SONET/SDH, see [RFC4606]. Given that one of the objectives of GMPLS is to generalize control plane protocols, it is reasonable to define a method for supporting hierarchical switching within a particular data plane technology that is not specific to any particular technology. >From the advent of GMPLS, there has been general agreement that there may be hierarchical switching within a particular data plane technology. What hasn't been figured out is the best way to represent this in a common format. This draft documents what we think is general agreement; that the use of the routing Switching Cap field is the wrong place. So what is the benefit of a generic/common representation of intra-technology hierarchy? >From my perspective, i.e. not speaking for Julien, it is that it enables a function that is common across multiple technologies to be implemented in a technology agnostic fashion -- which is, of course, on the fundamental precepts of CCAMP and GMPLS. Some example benefits include that it enables per-hierarchy level topologies to be constructed by (routing) implementations *without* parsing the SCSI. Additionally, on equipment that doesn't support a particular technology/hierarchy combination, processing of advertisements for such non-supported combinations can be minimized. As an implementor, I also like the code & testing benefits of having common mechanisms/implementation for equivalent per-technology functions. I also can see some potential operations benefits, but these certainly will be implementation dependent. These benefits seem sufficient to warrant looking into the mechanisms in more detail to determine if the benefit is worth the cost of the introduction of a new generic mechanism. We also recognize, as has been discussed multiple times before in the WG, there is the common tendency of those focused on a new technology to want to solve generic problems in a technology-specific fashion and it's the WG's job to identify when this is happening and when it's appropriate to define new generic mechanisms. As we say in the document, we think that the introduction of ILH is an open-discussion and certainly look for more/WG input. Lou From ietf-ipr@ietf.org Tue Feb 28 07:35:31 2012 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 CFE8521F86A5; Tue, 28 Feb 2012 07:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 MqlHzEh41fN0; Tue, 28 Feb 2012 07:35:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2C21F8681; Tue, 28 Feb 2012 07:35:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: zhangfatai@huawei.com, gregb@grotto-networking.com, hanjianrui@huawei.com, ylee@huawei.com, xuyunbin@mail.ritt.com.cn X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120228153531.14234.14704.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 07:35:31 -0800 Cc: ccamp@ietf.org, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to 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, 28 Feb 2012 15:35:31 -0000 Dear Fatai Zhang, Greg Bernstein, Jianrui Han, Young Lee, Yunbin Xu: An IPR disclosure that pertains to your Internet-Draft entitled "OSPF-TE Extensions for General Network Element Constraints" (draft-ietf-ccamp-gmpls- general-constraints-ospf-te) was submitted to the IETF Secretariat on 2012-= 02-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1697/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.""); The IETF Secretariat From ietf-ipr@ietf.org Tue Feb 28 07:36:16 2012 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 B8AE821F86AD; Tue, 28 Feb 2012 07:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 cFH01kAfhiSQ; Tue, 28 Feb 2012 07:36:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F68721F85E1; Tue, 28 Feb 2012 07:36:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: gregb@grotto-networking.com, ylee@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120228153616.13978.90295.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 07:36:16 -0800 Cc: ccamp@ietf.org, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-ccamp-wson-signal-compatibility-ospf-07 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, 28 Feb 2012 15:36:16 -0000 Dear Greg Bernstein, Young Lee: An IPR disclosure that pertains to your Internet-Draft entitled "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Swi= tched Optical Networks" (draft-ietf-ccamp-wson-signal-compatibility-ospf) was submitted to the IETF Secretariat on 2012-02-28 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1696/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-cc= amp- wson-signal-compatibility-ospf-07.""); The IETF Secretariat From jdrake@juniper.net Tue Feb 28 07:57:10 2012 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 B1A9721F86B6 for ; Tue, 28 Feb 2012 07:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.98 X-Spam-Level: X-Spam-Status: No, score=-4.98 tagged_above=-999 required=5 tests=[AWL=1.619, 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 KkCCkchhMJxe for ; Tue, 28 Feb 2012 07:57:08 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 866B121F86B5 for ; Tue, 28 Feb 2012 07:57:08 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT0z5UeThd2kSZw4T1vSUUZPlRefW85NP@postini.com; Tue, 28 Feb 2012 07:57:08 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 28 Feb 2012 07:56:45 -0800 From: John E Drake To: Lou Berger , Daniele Ceccarelli Date: Tue, 28 Feb 2012 07:56:41 -0800 Thread-Topic: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.txt Thread-Index: Acz2HMEzhutq4BRkSgyzYycSH0Pm4AAE4gcg Message-ID: <5E893DB832F57341992548CDBB333163A55CF607A3@EMBX01-HQ.jnpr.net> References: <4F43AACE.7040507@labn.net> <4F4BAA6E.9070106@labn.net> <4F4BB704.2020208@labn.net> <4F4CD642.4000709@labn.net> In-Reply-To: <4F4CD642.4000709@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update-00.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, 28 Feb 2012 15:57:10 -0000 Comments inline > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Lou Berger > Sent: Tuesday, February 28, 2012 5:28 AM > To: Daniele Ceccarelli > Cc: CCAMP > Subject: Re: [CCAMP] Fwd: I-D Action: draft-berger-ccamp-swcaps-update- > 00.txt >=20 > On 2/28/2012 6:10 AM, Daniele Ceccarelli wrote: > >... > > Could you please explain what is the rationale > > behind introducing it? > > ... >=20 > Daniele, >=20 > Now this is a good question! >=20 > The ILH field is motivated by the WG goal of identifying and defining > common control plane mechanisms for different data plane technologies. > This draft says it this way: >=20 > Multiple switching technologies support forms of hierarchical > switching within a particular data plane technology. As discussed > above, GMPLS routing originally envisioned support for such cases > for > packet networks using PSC-2, 3, 4. In other cases, GMPLS defined > support using technology specific mechanisms, for example Signal > Type > was defined for SONET/SDH, see [RFC4606]. Given that one of the > objectives of GMPLS is to generalize control plane protocols, it is > reasonable to define a method for supporting hierarchical switching > within a particular data plane technology that is not specific to > any > particular technology. [JD] The problem with the above statement is that the term 'hierarchical s= witching' is not defined.=20 >=20 > From the advent of GMPLS, there has been general agreement that there > may be hierarchical switching within a particular data plane > technology. > What hasn't been figured out is the best way to represent this in a > common format. This draft documents what we think is general > agreement; > that the use of the routing Switching Cap field is the wrong place. >=20 > So what is the benefit of a generic/common representation of > intra-technology hierarchy? >=20 > From my perspective, i.e. not speaking for Julien, it is that it > enables > a function that is common across multiple technologies to be > implemented > in a technology agnostic fashion -- which is, of course, on the > fundamental precepts of CCAMP and GMPLS. [JD] The problem with the above statement is that the term 'a function' is= not defined. =20 >=20 > Some example benefits include that it enables per-hierarchy level > topologies to be constructed by (routing) implementations *without* > parsing the SCSI. [JD] If you don't parse the SCSI, how do you place it in your TE database? > Additionally, on equipment that doesn't support a > particular technology/hierarchy combination, processing of > advertisements for such non-supported combinations can be minimized. [JD] How exactly?=20 > As > an implementor, I also like the code & testing benefits of having > common > mechanisms/implementation for equivalent per-technology functions. I > also can see some potential operations benefits, but these certainly > will be implementation dependent. [JD] A common mechanism in support of what exactly? Also, even though ther= e a single proposed field, the values in it will be technology specific. >=20 > These benefits seem sufficient to warrant looking into the mechanisms > in > more detail to determine if the benefit is worth the cost of the > introduction of a new generic mechanism. We also recognize, as has > been > discussed multiple times before in the WG, there is the common tendency > of those focused on a new technology to want to solve generic problems > in a technology-specific fashion and it's the WG's job to identify when > this is happening and when it's appropriate to define new generic > mechanisms. >=20 > As we say in the document, we think that the introduction of ILH is an > open-discussion and certainly look for more/WG input. >=20 > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From huawei.danli@huawei.com Wed Feb 29 00:45:11 2012 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 4CBA921F87E4 for ; Wed, 29 Feb 2012 00:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=1.151, 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 yduY0iPv+Snw for ; Wed, 29 Feb 2012 00:45:10 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8121F87E3 for ; Wed, 29 Feb 2012 00:45:09 -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 <0M0500J6WC9G6A@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 29 Feb 2012 16:44:04 +0800 (CST) Received: from szxrg02-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 <0M0500F3AC9GL4@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 29 Feb 2012 16:44:04 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHM49636; Wed, 29 Feb 2012 16:44:03 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Feb 2012 16:43:39 +0800 Received: from l00037133 (10.70.77.60) by szxeml419-hub.china.huawei.com (10.82.67.158) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Feb 2012 16:44:20 +0800 Date: Wed, 29 Feb 2012 16:43:59 +0800 From: Dan Li X-Originating-IP: [10.70.77.60] To: ccamp@ietf.org Message-id: <00bc01ccf6be$47930ba0$3c4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20120228153616.13978.90295.idtracker@ietfa.amsl.com> Subject: Re: [CCAMP] IPR Disclosure 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, 29 Feb 2012 08:45:11 -0000 Dear CCAMPer, As you have noticed that Huawei has just filed the following IPR disclosures on Feb 28, 2012. https://datatracker.ietf.org/ipr/1696/ https://datatracker.ietf.org/ipr/1697/ This is a part of a follow-up commitment to clean up our late disclosure for the previous late disclosure. The licensing declaration is same as the previous case (No-Assert) and noted as follows: If any claim of any patent owned or controlled by Huawei or its Affiliates is essential on a technical ground to the specification adopted by IETF, Huawei on behalf of itself and its Affiliates hereby covenant not to assert any such claim against any party for making, using, selling, offering for sale or importing a product that implements the corresponding part of the specification. FRAND royalty-bearing licenses will be available to anyone who prefers that option. Again, we are very sorry for the late disclosure problem have caused in CCAMP and IETF recently. Thanks, Dan Li Huawei Technologies Co., Ltd. ----- Original Message ----- From: "IETF Secretariat" To: ; Cc: ; ; Sent: Tuesday, February 28, 2012 11:36 PM Subject: [CCAMP] IPR Disclosure: Huawei Technologies Co.,Ltd's Statement about IPR relatedto draft-ietf-ccamp-wson-signal-compatibility-ospf-07 > > Dear Greg Bernstein, Young Lee: > > An IPR disclosure that pertains to your Internet-Draft entitled "GMPLS OSPF > Enhancement for Signal and Network Element Compatibility for Wavelength Switched > Optical Networks" (draft-ietf-ccamp-wson-signal-compatibility-ospf) was > submitted to the IETF Secretariat on 2012-02-28 and has been posted on the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1696/). The title of the IPR disclosure is > "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-ccamp- > wson-signal-compatibility-ospf-07.""); > > The IETF Secretariat > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From julien.meuric@orange.com Wed Feb 29 02:04:14 2012 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 14C9921F8803; Wed, 29 Feb 2012 02:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=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 I0T0ewi309-L; Wed, 29 Feb 2012 02:04:13 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A621F87FF; Wed, 29 Feb 2012 02:04:12 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D9E31E307A7; Wed, 29 Feb 2012 11:05:12 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D04D3E302B6; Wed, 29 Feb 2012 11:05:12 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 11:04:11 +0100 Received: from [10.193.71.161] ([10.193.71.161]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 11:04:11 +0100 Message-ID: <4F4DF81A.3010801@orange.com> Date: Wed, 29 Feb 2012 11:04:10 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org References: <20120206.202719.2135711079242187783.harai@nict.go.jp> In-Reply-To: <20120206.202719.2135711079242187783.harai@nict.go.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Feb 2012 10:04:11.0533 (UTC) FILETIME=[7BF3B3D0:01CCF6C9] Cc: iPOP2012-tpc-sec@pilab.jp Subject: Re: [CCAMP] iPOP2012 Call for Presentation (extended deadline: Feb 29) 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, 29 Feb 2012 10:04:14 -0000 Hi IETF-ers. The extended deadline of iPOP CfP is today: this is your very last chance to submit a proposal to the 2012 edition of iPOP. Best regards, Julien Le 06/02/2012 12:27, Hiroaki Harai a 茅crit : > (Apologies if you received multiple copies of this message.) > > Dear CCAMP, PCE and MPLS subscribers, > > Please find iPOP2012 Call for Presentation. The deadline for > submitting presentation proposal (1-page abstract) is February 15th, > 2012. > > Best regards, > Hiroaki Harai > TPC Co-Chair for iPOP 2012 > > > --------------------------------------------------------------------- > Call for Presentation > > 8th International Conference on IP + Optical Network (iPOP 2012) > May 31 - June 1, 2012 > Hiyoshi Campus, Keio University, Yokohama-shi, Kanagawa, Japan > http://www.pilab.jp/ipop2012/ > > The conference is intended to share among the industry and the academia, > the knowledge, new findings, and experience on the state-of-the art of > IP and optical networking technologies. It features technical sessions > and planned exhibitions. The opportunity to participate is open to all. > > Important Dates: > Submission deadline of one-page abstract: February 15, 2012 > Notification of acceptance: March 30, 2012 > Submission deadline of final presentation slides: April 20, 2012 > > The Technical Program Committee for iPOP 2012 is soliciting presentation > proposals for this conference. Protocol design, experiment, theory, > implementation, and operational experiences are solicited. > The topics of the conference will include but not be limited to the following: > > * Photonic Network for NxGN and NwGN > * Multi-layer network (MLN) / Multi-region network (MRN) > * Inter-area/Inter-AS network > * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, > Impairment management > * GMPLS/ASON technologies > * GMPLS Network management, OA&M > * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet > transport technologies > * Path Computation Element (PCE), Traffic engineering > * Application with high-bandwidth demand > * L1VPN, Bandwidth on Demand, and Photonic Grid > * MPLS and Ethernet networking for Inter-data center connectivity for cloud > computing > * Carrier Ethernet and MPLS-TP for backhauling > * Testbed, field trial > > > If you wish to submit a topic for consideration, please send an Extended > Abstracts of 400 words and a maximum of 1 page, including figures and > diagrams, speaker鈥檚 name, affiliation, and contact information > to the Technical Program Committee at ipop2012-CFP@pilab.jp. > Please see http://www.pilab.jp/ipop2012/ for more details. > > Kind regards, > Hiroaki Harai, Julien Meuric, Eiji Oki > iPOP 2012 TPC Co-Chairs > > -------------------------------------------------------------------- > >