From zhang.fei3@zte.com.cn Sat Sep 1 19:53:37 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 26E6611E818C for ; Sat, 1 Sep 2012 19:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.452 X-Spam-Level: X-Spam-Status: No, score=-96.452 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nimg2ZknI5K1 for ; Sat, 1 Sep 2012 19:53:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id F2B1611E8188 for ; Sat, 1 Sep 2012 19:53:35 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 23255473195744; Sun, 2 Sep 2012 10:46:52 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C82A070824C; Sun, 2 Sep 2012 10:49:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q822rSgV048575; Sun, 2 Sep 2012 10:53:28 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Rakesh Gandhi (rgandhi)" MIME-Version: 1.0 X-KeepSent: 9B11B7CF:AFDB8F52-48257A6D:000E1394; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Sun, 2 Sep 2012 10:53:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-02 10:53:30, Serialize complete at 2012-09-02 10:53:30 Content-Type: multipart/alternative; boundary="=_alternative 000FC76C48257A6D_=" X-MAIL: mse02.zte.com.cn q822rSgV048575 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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: Sun, 02 Sep 2012 02:53:37 -0000 This is a multipart message in MIME format. --=_alternative 000FC76C48257A6D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFrZXNoDQoNClNlZSBpbiBsaW5lIHRhZ2dlZCB3aXRoIDxmZWk+DQoNCkJlc3QgcmVnYXJk cw0KDQpGZWkNCg0KDQoNCiJSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28u Y29tPiANCjIwMTItMDgtMzEgMjE6NDkNCg0KytW8/sjLDQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxh Ym4ubmV0Pg0Ks63LzQ0KInpoYW5nLmZlaTNAenRlLmNvbS5jbiIgPHpoYW5nLmZlaTNAenRlLmNv bS5jbj4sICJjY2FtcEBpZXRmLm9yZyIgDQo8Y2NhbXBAaWV0Zi5vcmc+DQrW98ziDQpRdWVzdGlv biBvbiBMU1AgY29udHJvbCBpbiANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KDQoNCg0KDQoNCg0KSGkgTG91LCBGZWksDQoNCldoZW4g YW4gKG9yaWdpbmF0aW5nKSBpbmdyZXNzIG5vZGUgaXMgcHJvdmlzaW9uZWQgd2l0aCAiNSAoVEJE KSAgU2luZ2xlIA0KU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMgIChBKSIgYW5k IHdpc2hlcyB0byBjb250cm9sIGJvdGggDQpmb3J3YXJkIGFuZCByZXZlcnNlICBMU1BzIGJ5IGFk ZGluZyAiUkVWRVJTRV9MU1AiIG9iamVjdCwgSSB3b3VsZCB0aGluayANCnRoYXQgdGhlIGluZ3Jl c3Mgbm9kZSBuZWVkcyB0byBrbm93IGFib3V0IHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyAN CihzdWNoIGFzIHNvZnQgcHJlZW1wdGlvbiBvciBhZG1pc3Npb24gZmFpbHVyZSkgb24gdGhlIHJl dmVyc2UgTFNQLiAgSXMgDQp0aGVyZSBhbnkgdGV4dCBzb21ld2hlcmUgaW4gYW4gUkZDL2RyYWZ0 IHRoYXQgZGVzY3JpYmVzIGhvdyBhIG1pZC1wb2ludCANCm5vZGUgY2FuIHNlbmQgdGhlIHNpZ25h bGluZyAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nIGluZ3Jlc3Mgbm9kZSANCmZvciB0 aGUgcmV2ZXJzZSBMU1A/IElzIHRoZXJlIGFuIGFzc3VtcHRpb24gdG8gdXNlIFJTVlBfTk9USUZZ IG1lc3NhZ2U/IA0KU29ycnkgaWYgSSBoYWQgbWlzc2VkIGFueSBwcmV2aW91cyBkaXNjdXNzaW9u IG9uIHRoaXMgdG9waWMuDQoNCjxmZWk+IFBsZWFzZSBjaGVjayANCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQt bHNwLTA0I3NlY3Rpb24tMy4yLjkgDQp0byBzZWUgd2hldGhlciB3ZSBuZWVkIHRvIGFkZCBtb3Jl IHdvcmRzIGhlcmUuIDopDQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0KDQo= --=_alternative 000FC76C48257A6D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJha2VzaDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U2VlIGluIGxpbmUgdGFnZ2Vk IHdpdGggJmx0O2ZlaSZndDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPkJlc3QgcmVnYXJkczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+RmVpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjxiPiZxdW90O1Jha2VzaCBHYW5kaGkgKHJnYW5kaGkpJnF1b3Q7DQombHQ7 cmdhbmRoaUBjaXNjby5jb20mZ3Q7PC9iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMi0wOC0zMSAyMTo0OTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Mb3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4u bmV0Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7emhhbmcuZmVpM0B6dGUuY29tLmNuJnF1 b3Q7ICZsdDt6aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7LA0KJnF1b3Q7Y2NhbXBAaWV0Zi5vcmcm cXVvdDsgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UXVlc3Rpb24g b24gTFNQIGNvbnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNz b2NpYXRlZC1sc3AtMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBMb3UsIEZlaSw8YnI+DQo8YnI+DQpXaGVuIGFuIChvcmln aW5hdGluZykgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggJnF1b3Q7NSAoVEJEKSAm bmJzcDtTaW5nbGUNClNpZGVkIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzICZuYnNwOyhB KSZxdW90OyBhbmQgd2lzaGVzIHRvIGNvbnRyb2wNCmJvdGggZm9yd2FyZCBhbmQgcmV2ZXJzZSAm bmJzcDtMU1BzIGJ5IGFkZGluZyAmcXVvdDtSRVZFUlNFX0xTUCZxdW90OyBvYmplY3QsDQpJIHdv dWxkIHRoaW5rIHRoYXQgdGhlIGluZ3Jlc3Mgbm9kZSBuZWVkcyB0byBrbm93IGFib3V0IHRoZSBz aWduYWxpbmcgKHBhdGgpDQplcnJvcnMgKHN1Y2ggYXMgc29mdCBwcmVlbXB0aW9uIG9yIGFkbWlz c2lvbiBmYWlsdXJlKSBvbiB0aGUgcmV2ZXJzZSBMU1AuDQombmJzcDtJcyB0aGVyZSBhbnkgdGV4 dCBzb21ld2hlcmUgaW4gYW4gUkZDL2RyYWZ0IHRoYXQgZGVzY3JpYmVzIGhvdyBhDQptaWQtcG9p bnQgbm9kZSBjYW4gc2VuZCB0aGUgc2lnbmFsaW5nIChwYXRoKSBlcnJvciB0byB0aGUgb3JpZ2lu YXRpbmcgaW5ncmVzcw0Kbm9kZSBmb3IgdGhlIHJldmVyc2UgTFNQPyBJcyB0aGVyZSBhbiBhc3N1 bXB0aW9uIHRvIHVzZSBSU1ZQX05PVElGWSBtZXNzYWdlPw0KU29ycnkgaWYgSSBoYWQgbWlzc2Vk IGFueSBwcmV2aW91cyBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuPC9mb250PjwvdHQ+DQo8YnI+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7ZmVpJmd0OyBQbGVhc2UgY2hlY2sgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNz b2NpYXRlZC1sc3AtMDQjc2VjdGlvbi0zLjIuOQ0KdG8gc2VlIHdoZXRoZXIgd2UgbmVlZCB0byBh ZGQgbW9yZSB3b3JkcyBoZXJlLiA6KTxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSYWtlc2g8YnI+ DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 000FC76C48257A6D_=-- From rgandhi@cisco.com Tue Sep 4 08:14: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 0090621F84F1 for ; Tue, 4 Sep 2012 08:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAcz9ARB4gYs for ; Tue, 4 Sep 2012 08:14:45 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id CC01A21F847B for ; Tue, 4 Sep 2012 08:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=13099; q=dns/txt; s=iport; t=1346771684; x=1347981284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fst5KB+Bo6k+MI16T4+qhUw/3/+QJuR4batJRJ78xUk=; b=lVYGHbwfmFT/42gEkXougNLnjSnlMsMMz/ck7stWmvyXvy8DPMpjE9xE 9SZZXOTn2ImmfDGnmKlBCIa/iQ3STVQGPLIqia+XISzR7pkWgxHT9rv54 pPvSemawd0e5yHDFCKbfdPt3OQmrf0an9ZwWrX8xcHnWp85mOhcGPeANG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAGAaRlCtJV2d/2dsb2JhbABFgkqDO6xKAYdldoEHgiABAQEEEgEaTBACAQYCEQQBAQsdBQICMBQJCAEBBA4FCBqHawuaXI0TCJJdiw2GHDZgA5ZtjR+BZ4Jj X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208,217";a="117891191" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 04 Sep 2012 15:14:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q84FEi4n004685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 15:14:44 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 4 Sep 2012 10:14:44 -0500 From: "Rakesh Gandhi (rgandhi)" To: "zhang.fei3@zte.com.cn" Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgBYJAIAAHPCyDA= Date: Tue, 4 Sep 2012 15:14:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.61] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005 x-tm-as-result: No--50.132900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C24078437xmbalnx07ciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 04 Sep 2012 15:14:46 -0000 --_000_B7D2A316AA32B6469D9670B6A81B7C24078437xmbalnx07ciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIEZlaSBmb3IgeW91ciByZXBseS4gUGxlYXNlIHNlZSBpbmxpbmUuLjxSRz4uDQoNCkZy b206IHpoYW5nLmZlaTNAenRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0N ClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMDEsIDIwMTIgMTA6NTMgUE0NClRvOiBSYWtlc2gg R2FuZGhpIChyZ2FuZGhpKQ0KQ2M6IGNjYW1wQGlldGYub3JnOyBMb3UgQmVyZ2VyDQpTdWJqZWN0 OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCg0KSGkgUmFrZXNoDQoNClNlZSBp biBsaW5lIHRhZ2dlZCB3aXRoIDxmZWk+DQoNCkJlc3QgcmVnYXJkcw0KDQpGZWkNCg0KIlJha2Vz aCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNjby5jb208bWFpbHRvOnJnYW5kaGlAY2lz Y28uY29tPj4NCg0KMjAxMi0wOC0zMSAyMTo0OQ0KDQrK1bz+yMsNCg0KTG91IEJlcmdlciA8bGJl cmdlckBsYWJuLm5ldDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQoNCrOty80NCg0KInpoYW5n LmZlaTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPiIgPHpoYW5nLmZl aTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPj4sICJjY2FtcEBpZXRm Lm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1w QGlldGYub3JnPj4NCg0K1vfM4g0KDQpRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBkcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQoN Cg0KDQoNCg0KSGkgTG91LCBGZWksDQoNCldoZW4gYW4gKG9yaWdpbmF0aW5nKSBpbmdyZXNzIG5v ZGUgaXMgcHJvdmlzaW9uZWQgd2l0aCAiNSAoVEJEKSAgU2luZ2xlIFNpZGVkIEFzc29jaWF0ZWQg QmlkaXJlY3Rpb25hbCBMU1BzICAoQSkiIGFuZCB3aXNoZXMgdG8gY29udHJvbCBib3RoIGZvcndh cmQgYW5kIHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIgb2JqZWN0LCBJIHdv dWxkIHRoaW5rIHRoYXQgdGhlIGluZ3Jlc3Mgbm9kZSBuZWVkcyB0byBrbm93IGFib3V0IHRoZSBz aWduYWxpbmcgKHBhdGgpIGVycm9ycyAoc3VjaCBhcyBzb2Z0IHByZWVtcHRpb24gb3IgYWRtaXNz aW9uIGZhaWx1cmUpIG9uIHRoZSByZXZlcnNlIExTUC4gIElzIHRoZXJlIGFueSB0ZXh0IHNvbWV3 aGVyZSBpbiBhbiBSRkMvZHJhZnQgdGhhdCBkZXNjcmliZXMgaG93IGEgbWlkLXBvaW50IG5vZGUg Y2FuIHNlbmQgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nIGlu Z3Jlc3Mgbm9kZSBmb3IgdGhlIHJldmVyc2UgTFNQPyBJcyB0aGVyZSBhbiBhc3N1bXB0aW9uIHRv IHVzZSBSU1ZQX05PVElGWSBtZXNzYWdlPyBTb3JyeSBpZiBJIGhhZCBtaXNzZWQgYW55IHByZXZp b3VzIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NCg0KPGZlaT4gUGxlYXNlIGNoZWNrIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LWFzc29jaWF0ZWQtbHNwLTA0I3NlY3Rpb24tMy4yLjkgdG8gc2VlIHdoZXRoZXIgd2UgbmVlZCB0 byBhZGQgbW9yZSB3b3JkcyBoZXJlLiA6KQ0KDQo8Ukc+IFdoYXQgSSBhbSByZWZlcnJpbmcgdG8g aXMgYXMgZm9sbG93czogZm9yd2FyZCBMU1AgcGF0aCBmcm9tIEEgKEluZ3Jlc3MpIC0gQiCoQyBD IKhDIEQgKGVncmVzcykuIFJldmVyc2UgTFNQIHBhdGggaXMgRCCoQyBFIKhDIEYgqEMgQS4gSGVy ZSBub2RlIEEgaXMgdGhlIGluaXRpYWxpemluZyBMU1AgaW5ncmVzcyBub2RlIGFuZCBjb250cm9s cyB0aGUgcGF0aCBmb3IgcmV2ZXJzZSBMU1AgYnkgYWRkaW5nIFJFVkVSU0VfTFNQIG9iamVjdC4g U28gaWYgdGhlcmUgaXMgYSBwYXRoIGVycm9yIG9uIHRoZSByZXZlcnNlIExTUCBzYXkgb24gbGlu ayBGLUUsIHRoZSBwYXRoIGVycm9yIHdpbGwgYmUgc2VudCB0byBoZWFkLWVuZCBvZiB0aGF0IExT UCB3aGljaCBpcyBub2RlIEQuIEFzIHBhdGggZm9yIHRoZSByZXZlcnNlIExTUCBpcyBjb250cm9s bGVkIGJ5IG5vZGUgQSwgbm9kZSBBIG5lZWRzIHRvIGtub3cgYWJvdXQgdGhpcyBwYXRoIGVycm9y IHNvIGl0IG1heSBjb21wdXRlIGFuIGFsdGVybmF0ZSBwYXRoIGZvciB0aGUgcmV2ZXJzZSBMU1Au IElzIHRoZXJlIGEgbWVjaGFuaXNtIHNvbWV3aGVyZSBkZWZpbmVkIGZvciBub2RlIEQgdG8gcmVs YXkgdGhpcyBwYXRoIGVycm9yIHRvIGluaXRpYWxpemluZyBub2RlIEE/DQpUaGFua3MsDQpSYWtl c2gNCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0K --_000_B7D2A316AA32B6469D9670B6A81B7C24078437xmbalnx07ciscocom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks Fei for your reply= . Please see inline..<RG>.

 <= /p>

From: zhang.fe= i3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
Sent: Saturday, September 01, 2012 10:53 PM
To: Rakesh Gandhi (rgandhi)
Cc: ccamp@ietf.org; Lou Berger
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsv= pte-ext-associated-lsp-04.txt

 


Hi Rakesh

See in line tagged with <fei>

Best regards

Fei

"Rakesh Gandhi (rgandhi)" <= ;rgandhi@cisco.com><= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f"">

2012-08-31 21:49

=CA=D5=BC=FE=C8=CB<= /p>

Lou Berger <lberger@labn.net>

=B3=AD=CB=CD

"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>, "ccamp@ietf.org" <ccamp@ietf.org> <= /o:p>

=D6=F7=CC=E2

Question on LSP control in draft-ietf-ccam= p-mpls-tp-rsvpte-ext-associated-lsp-04.txt

 




Hi Lou, Fei,

When an (originating) ingress node is provisioned with "5 (TBD) &n= bsp;Single Sided Associated Bidirectional LSPs  (A)" and wishes t= o control both forward and reverse  LSPs by adding "REVERSE_LSP&q= uot; object, I would think that the ingress node needs to know about the signaling (path) errors (such as soft preemption or admission failure)= on the reverse LSP.  Is there any text somewhere in an RFC/draft that= describes how a mid-point node can send the signaling (path) error to the = originating ingress node for the reverse LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had mis= sed any previous discussion on this topic.

<fei> Please check http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-l= sp-04#section-3.2.9 to see whether we need to add more words here. :)

<RG> What I am referring to is as follows: forward LSP path fro= m A (Ingress) - B =A8C C =A8C D (egress). Reverse LSP path is D =A8C E =A8C F =A8C A. Here node A is the initializing LSP ingress node and controls th= e path for reverse LSP by adding REVERSE_LSP object. So if there is a path = error on the reverse LSP say on link F-E, the path error will be sent to he= ad-end of that LSP which is node D. As path for the reverse LSP is controlled by node A, node A needs to know = about this path error so it may compute an alternate path for the reverse L= SP. Is there a mechanism somewhere defined for node D to relay this path er= ror to initializing node A?

Thanks,

Rakesh


Thanks,
Rakesh


--_000_B7D2A316AA32B6469D9670B6A81B7C24078437xmbalnx07ciscocom_-- From lberger@labn.net Tue Sep 4 08:35: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 EE8A021F8674 for ; Tue, 4 Sep 2012 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YglxLYwaAJat for ; Tue, 4 Sep 2012 08:35:29 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 61D1821F8569 for ; Tue, 4 Sep 2012 08:35:26 -0700 (PDT) Received: (qmail 21457 invoked by uid 0); 4 Sep 2012 15:35:13 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 4 Sep 2012 15:35: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=Bqkn6miuomHLhsF5bIMrMUAQU0lsJ+Aeiu+h7Ru5qtQ=; b=uZVKVWdPF7DxAFtDvQ1MNqaz004G6CtxZ8O7FjHUszX0fEP3MVmPju7mDqe38eKe8KQM5brFJMgh3guG9IwrNkakfb35HcId6jhzTTVXjHpk9LU9q8sxpsI7Q+fbGYXf; Received: from box313.bluehost.com ([69.89.31.113]:33104 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T8v9k-0006vL-Ot; Tue, 04 Sep 2012 09:35:12 -0600 Message-ID: <50461FB2.7080707@labn.net> Date: Tue, 04 Sep 2012 11:35:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 04 Sep 2012 15:35:31 -0000 As I read the current rev, no such notification mechanism is specified. Looks like you get to propose one! Lou (as WG participant). On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, Fei, > > When an (originating) ingress node is provisioned with "5 (TBD) Single Sided Associated Bidirectional LSPs (A)" and wishes to control both forward and reverse LSPs by adding "REVERSE_LSP" object, I would think that the ingress node needs to know about the signaling (path) errors (such as soft preemption or admission failure) on the reverse LSP. Is there any text somewhere in an RFC/draft that describes how a mid-point node can send the signaling (path) error to the originating ingress node for the reverse LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any previous discussion on this topic. > > Thanks, > Rakesh > > > > > From rgandhi@cisco.com Tue Sep 4 09:26: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 4A85D11E809A for ; Tue, 4 Sep 2012 09:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YsEjDYTFjsp for ; Tue, 4 Sep 2012 09:26:50 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1FE21F84DA for ; Tue, 4 Sep 2012 09:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rgandhi@cisco.com; l=7932; q=dns/txt; s=iport; t=1346776010; x=1347985610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H3Gpw+MdffMB9kO+/VrvHvMTHEGzsyjfaAjK/qmWeiI=; b=bIDyn7iZYdVHMIoy89+bFaGvBpc/EzfBJYsLEYJWQNDwqNaIzVlZZOvl UI00k9jaZpOzINsZNjFzTuSxfZcOoUyWLzaronkuF7IymijCnASYfydJq oIX/NQwHCZze3rSnJsmB2pfeI7VqFAPpY4Y+8VlxePbq+HgI8Pw4cZcCy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAL4qRlCtJV2Z/2dsb2JhbAA7CoYFtDB2gQeCIAEBAQQSASEzEgwEAgEGAg4DBAEBAQQGGQQFAgIwFAkIAgQBDQUIGodrmmONEwiSXoEdiXAQBIYINmADpAyBZ4JjgVg X-IronPort-AV: E=Sophos;i="4.80,367,1344211200"; d="scan'208";a="118127028" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 04 Sep 2012 16:26:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q84GQnuE009076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 16:26:49 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 11:26:48 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , "zhang.fei3@zte.com.cn" Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNhMO1KWryoN3/QKaPbjEu2q9iw5dvgLYAgAroR+A= Date: Tue, 4 Sep 2012 16:26:47 +0000 Message-ID: References: <503CBDC2.9040308@labn.net> In-Reply-To: <503CBDC2.9040308@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.61] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005 x-tm-as-result: No--52.159100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 04 Sep 2012 16:26:51 -0000 VGhhbmtzIExvdS4NCg0KWW91ciBwcm9wb3NhbCBiZWxvdyBzb3VuZHMgZ29vZC4NCg0KUG90ZW50 aWFsIHRleHQgZm9yIHRoZSByZW1haW5lZCB0d28gc2VjdGlvbnMgaW4gdGhlIGRyYWZ0IGNhbiBi ZSBhcyBmb2xsb3dzLiBQbGVhc2UgZmVlbCBmcmVlIHRvIHJldmlzZS4NCg0KMy4yLjYgU2lnbmFs aW5nIG9mIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1AgRm9yIERpZmZlcmVudCBMU1AgUm9s ZXMNClRoZXJlIGNhbiBhbHNvIGJlIGEgcGFpciBvZiByZWNvdmVyeSBhbmQvb3IgcmVyb3V0ZSBM U1BzIGFzIHBlciBwcm9jZWR1cmVzIGRlZmluZSBpbiBbUkZDNDg3Ml0sIFtSRkM0ODczXSBhbmQg W1JGQzQwOTBdLiBUb2dldGhlciB3aXRoIHRob3NlIHByb2NlZHVyZXMsIGEgbm9kZSB1c2VzIEV4 dGVuZGVkIEFTU09DSUFUSU9OIG9iamVjdCBvciBBU1NPQ0lBVElPTiBvYmplY3QgZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IHRvIGZvcm0gYW4gYXNzb2NpYXRlZCBiaWRpcmVjdGlvbmFsIExTUCBw YWlyIGZvciBlYWNoIExTUCByb2xlLg0KDQozLjIuNy4gU2lnbmFsaW5nIG9mIEF1dG8tdHVubmVs IE1lc2gtZ3JvdXAgTFNQcw0KICAgQSBub2RlIG1heSBidWlsZCBMU1BzIGF1dG9tYXRpY2FsbHkg dG8gcmVtb3RlIHBlZXJzIGluIGEgbWVzaCB1c2luZw0KICAgdGhlIG1lc2gtZ3JvdXAgbWVtYmVy c2hpcCBkZWZpbmVkIGluIFtSRkM0OTcyXS4gQSBub2RlIE1VU1QgYmUgcHJvdmlzaW9uZWQgd2l0 aCBpZGVudGljYWwgYXNzb2NpYXRpb24gSUQNCiAgIGZvciB0aGUgZ2l2ZW4gbWVzaC1ncm91cCBt ZW1iZXJzIHBlZXJzIHRvIGJ1aWxkIGEgbWVzaCBvZiBhc3NvY2lhdGVkIGJpZGlyZWN0aW9uYWwg TFNQcy4gVGhlIGV4dGVuZGVkDQogICBhc3NvY2lhdGlvbiBJRCBjYW4gYmUgdXNlZCB0byBmb3Jt IHVuaXF1ZSBFeHRlbmRlZCBBU1NPQ0lBSVRPTiBvYmplY3QgaW4gZWFjaCBMU1AgdG8gZGlmZmVy ZW50IHJlbW90ZSBwZWVycy4NCg0KDQpUaGFua3MsDQpSYWtlc2gNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRd IA0KU2VudDogVHVlc2RheSwgQXVndXN0IDI4LCAyMDEyIDg6NDcgQU0NClRvOiB6aGFuZy5mZWkz QHp0ZS5jb20uY24NCkNjOiBjY2FtcEBpZXRmLm9yZzsgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkN ClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluIGRyYWZ0 LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KDQpG ZWksDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHRleHQgYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiBzZWxl Y3Rpb24gb2YgYXNzb2NpYXRpb24gb2JqZWN0IGNvbnRlbnRzIGluIHRoZSBjYXNlIG9mIGRvdWJs ZSBzaWRlZCBwcm92aXNpb25pbmcuICBIb3cgYWJvdXQ6DQotIGluIHRoZSBjYXNlIG9mIGRvdWJs ZSBzaWRlZCBwcm92aXNpb25pbmcgKm9ubHkqDQogIDEuIEFzc29jaWF0aW9uIFNvdXJjZSBpcyBz ZXQgdG8gYW4gYWRkcmVzcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdpbmF0 ZXMgdGhlIGFzc29jaWF0aW9uLiAod2hpY2ggbWF5IGJlIGEgbWFuYWdlbWVudCBlbnRpdHkuKQ0K ICAyLiBBc3NvY2lhdGlvbiBJRCBpcyBhIHZhbHVlIGFzc2lnbmVkIGJ1dCB0aGUgbm9kZSB0aGF0 IG9yaWdpbmF0ZXMNCiAgICAgdGhlIGFzc29jaWF0aW9uLg0KICAzLiBHbG9iYWwgQXNzb2NpYXRp b24gU291cmNlLCB3aGVuIHVzZWQsIGlzIHNldCB0byB0aGUgR2xvYmFsX0lEIG9mDQogICAgIHRo ZSBub2RlIHRoYXQgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uDQogIDQuIEV4dGVuZGVkIEFz c29jaWF0aW9uIElELCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQNCiAg ICAgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uDQogIC0gIElmIGVpdGhlciAoMykgb3IgKDQp IGFyZSB1c2VkLCBhbiBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3QNCiAgICAgW2Fzc29jLWV4 dF0gaXMgdXNlZC4gIE90aGVyd2lzZSBhIEFTU09DSUFUSU9OIG9iamVjdCBbcmZjNDg3Ml0NCiAg ICAgaXMgdXNlZA0KDQotIHdoaWxlIHdlJ3JlIGF0IGl0LCBpbiB0aGUgY2FzZSBvZiBzaW5nbGUg c2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5KiAobm90ZSBvbmx5ICMxIGRpZmZlcnMpDQogIDEuIEFz c29jaWF0aW9uIFNvdXJjZSBpcyBzZXQgdG8gYW4gYWRkcmVzcyBhc3NpZ25lZCB0byB0aGUgbm9k ZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMgdGhlIExTUC4NCiAgMi4gQXNzb2NpYXRpb24gSUQgaXMg YSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzDQogICAgIHRoZSBh c3NvY2lhdGlvbi4NCiAgMy4gR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSwgd2hlbiB1c2VkLCBp cyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KICAgICB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0ZXMg dGhlIGFzc29jaWF0aW9uLg0KICA0LiBFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCwgd2hlbiB1c2Vk LCBpcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMgdGhlIGFzc29j aWF0aW9uLg0KICAtICBJZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5kZWQg QVNTT0NJQVRJT04gb2JqZWN0DQogICAgIFthc3NvYy1leHRdIGlzIHVzZWQuICBPdGhlcndpc2Ug YSBBU1NPQ0lBVElPTiBvYmplY3QgW3JmYzQ4NzJdDQogICAgIGlzIHVzZWQNCg0KSSB0aGluayB0 aGUgYWJvdmUgYWRkcmVzc2VzIG15IHBvaW50IGFzIGl0IGNhbiBiZSB1c2VkIHRvIGVuc3VyZSB1 bmlxdWUgTFNQIGFzc29jaWF0aW9uIGluIGFsbCBjYXNlcy4gIEJUVyBpdCBhbHNvIGFsaWducyB2 ZXJ5IG5pY2VseSB3aXRoIHRoZSBleGlzdGluZyBkZWZpbml0aW9uIG9mIHRoZSBhc3NvY2lhdGlv biBvYmplY3RzLg0KDQpUbyBhZGRyZXNzIHdoYXQgSSBzdXNwZWN0IGlzIHlvdXIgY29uY2Vybiwg My4yLjggY2FuIHRoZW4gYmVjb21lIHNvbWV0aGluZyBsaWtlIChmZWVsIGZyZWUgdG8gcmV2aXNl KToNCg0KICAzLjIuOCAgTVBMUy1UUCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIElkZW50 aWZpZXJzDQoNCiAgW1JGQzYzNzBdIGRlZmluZXMgdGhlIExTUCBhc3NvY2lhdGVkIGlkZW50aWZp ZXJzIGJhc2VkIG9uIHRoZQ0KICBzaWduYWxpbmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRpcmVj dGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0aW9uDQogIG9mIGVhY2ggdW5pZGlyZWN0aW9uYWwgTFNQ J3MgcGFyYW1ldGVycyBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZQ0KICBBc3NvY2lhdGVkIEJpZGly ZWN0aW9uYWwgTFNQLiAgVXNpbmcgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbg0KICB0aGlzIGRv Y3VtZW50LCBhbnkgbm9kZSB0aGF0IGlzIGFsb25nIHRoZSBwYXRoIG9mIGJvdGgNCiAgdW5pZGly ZWN0aW9uYWwgTFNQcyBjYW4gaWRlbnRpZnkgd2hpY2ggcGFpciBvZiB1bmlkaXJlY3Rpb25hbCBM U1BzDQogIHN1cHBvcnQgYW4gQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBhcyB3ZWxsIGFz IHRoZSBzaWduYWxpbmcNCiAgcGFyYW1ldGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICBOb3Rl IHRoYXQgdGhlIExTUCBlbmQtcG9pbnRzDQogIHdpbGwgYWx3YXlzIGJlIHRoZSBwYXRoIG9mIGJv dGggdW5pZGlyZWN0aW9uYWwgTFNQcy4NCg0KTG91DQoNCk9uIDgvMjcvMjAxMiAxMDoyMCBQTSwg emhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gVGhhbmsgeW91IGxvdQ0KPiANCj4g SG93IGFib3V0IGNoYW5naW5nIHRoZSBkZXNjcmlwdGlvbnMgaW4gcGFyYWdyYXBoIDMuMi44DQo+ IA0KPiAgICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMgdGhlIGFzc29jaWF0aW9u IHNvdXJjZSBNQVkgbmVlZCB0bw0KPiAgIGxlYXJuIGFib3V0IHRoZSBHbG9iYWxfSUQgW1JGQzYz NzBdIG9mIHRoZSBwZWVyIG5vZGUsIHdoaWNoIGNhbiBiZQ0KPiAgIGRvbmUgYnkgaW5zZXJ0aW5n IHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBlICJMU1ANCj4gICBp ZGVudGlmaWVycyIgaW4gdGhlIG91dGdvaW5nIFBhdGggbWVzc2FnZSBhbmQgYmVpbmcgY2Fycmll ZCBiYWNrIGluDQo+ICAgdGhlIFJlc3YgbWVzc2FnZSwgYXMgZGVmaW5lZCBpbiBbSS1ELCBkcmFm dC16aGFuZy1jY2FtcC1tcGxzLXRwLQ0KPiAgIHJzdnB0ZS1leHQtdHVubmVsLW51bV0uDQo+IA0K PiBpbnRvDQo+IA0KPiAgICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMgdGhlIGFz c29jaWF0aW9uIHNvdXJjZSBNQVkgbmVlZCB0bw0KPiAgIGxlYXJuIGFib3V0IHRoZSBHbG9iYWxf SUQgW1JGQzYzNzBdIG9mIHRoZSBwZWVyIG5vZGUuIEFsdGhvdWdoIHRoZQ0KPiAgICBzY29wZSBv ZiB0aGUgZHJhZnQgW0ktRCwNCj4gZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0 LXR1bm5lbC1udW1dDQo+ICAgIGlzIGxpbWl0ZWQgdG8gdGhlIGNvLXJvdXRlZCBiaWRpcmVjdGlv bmFsIExTUCwgdGhlIGRlZmluZWQgDQo+IHByb2NlZHVyZXMgY2FuDQo+ICAgIGJlIHJldXNlZCBo ZXJlIGFsc28uIFRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBlICJM U1ANCj4gICBJZGVudGlmaWVycyIgaXMgaW5zZXJ0ZWQgaW4gdGhlIG91dGdvaW5nIFBhdGggbWVz c2FnZSBhdCB0aGUgYXNzb2NpYXRpb24NCj4gICAgc291cmNlIGFuZCBjYXJyaWVkIGJhY2sgaW4g dGhlIGNvcnJlc3BvbmRpbmcgUmVzdiBtZXNzYWdlLiBBbGwgdGhlIA0KPiBmaWVsZHMNCj4gICAg b2YgdGhlIEFTU09DSUFUSU9OIG9iamVjdCBleGNlcHQgdGhlIEFzc29jaWF0aW9uIFR5cGUgaW4g dGhlIFBhdGggDQo+IG1lc3NhZ2UNCj4gICAgY2FuIGJlIGlnbm9yZWQgYnkgdGhlIHJlY2VpdmVy IGFuZCB0aGUgR2xvYmFsX0lEIG9mIHRoZSBwZWVyIG5vZGUgDQo+IGlzIHB1c2hlZA0KPiAgICBp bnRvIHRoZSBmaWVsZCBvZiB0aGUgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSBpbiB0aGUgUmVz diBtZXNzYWdlLg0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBGZWkNCj4gDQo+IA0KPiAqTG91 IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+IA0KPiAyMDEyLTA4LTI4IDAyOjMwDQo+IA0K PiAJDQo+IMrVvP7Iyw0KPiAJemhhbmcuZmVpM0B6dGUuY29tLmNuDQo+ILOty80NCj4gCSJjY2Ft cEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiwgIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIg0K PiA8cmdhbmRoaUBjaXNjby5jb20+DQo+INb3zOINCj4gCVJlOiBbQ0NBTVBdIFJldmlldyBSZXF1 ZXN0IEZvciBDaGFuZ2VzIGluIA0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4 dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gDQo+IA0KPiAJDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gRmVpLA0KPiAgICAgICAgICAgICAgICAgVGhlIHByb2JsZW0gb25seSBleGlzdHMgaW4gdGhl IGRvdWJsZSBzaWRlZCANCj4gcHJvdmlzaW9pbmcgY2FzZSwgc28gbm8gbmVlZCB0byBjb21wbGlj YXRlIHRoZSBzaW5nbGUgc2lkZWQgDQo+IHByb3Zpc2lvbmluZyBjYXNlLg0KPiANCj4gTG91DQo+ IA0KPiANCj4gT24gOC8yNi8yMDEyIDk6MDMgUE0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3cm90 ZToNCj4+IFRoZSBhZG1pbmlzdHJhdGl2ZQ0KPj4gYXBwcm9hY2ggY2FuIGludGVncmF0ZSBib3Ro IG1vZGVscywgd2lsbCBiZSBhIGdvb2QgaWRlYS4NCj4gDQo+IA0K From rgandhi@cisco.com Tue Sep 4 10:35:43 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 4D16A21F8697 for ; Tue, 4 Sep 2012 10:35:43 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgWsm61+i2BZ for ; Tue, 4 Sep 2012 10:35:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8675621F8681 for ; Tue, 4 Sep 2012 10:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3011; q=dns/txt; s=iport; t=1346780142; x=1347989742; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TUnaWMhFhASnw5cCAHLkBz2mCho/M5PBbDbyHH4EwG8=; b=IJFs1xitBwltqyqX0zukXFa0d7Gk1c0y0PLnuIAPhSVJO5blcKzSABHj LJb4mLwZVy+Ck+vdYpLM3fxGKEaOdNz9gI2rSfTydIKzrjVGDjnLYUzLn PYletsNk70K+WAQJ5Ps+a+0oNER+x7jnk0W7Lgxnhfo892uo/HB2iJRKx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANY6RlCtJV2c/2dsb2JhbABFuyGBB4IgAQEBBBIBJz8MBAIBCA4DBAEBAQoUCQcyFAkIAQEEDgUIGodrmk+gBYsJhlJgA6QMgWeCYw X-IronPort-AV: E=Sophos;i="4.80,368,1344211200"; d="scan'208";a="115138141" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 04 Sep 2012 17:35:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q84HZfdw000962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 17:35:41 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 12:35:40 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetA= Date: Tue, 4 Sep 2012 17:35:39 +0000 Message-ID: References: <50461FB2.7080707@labn.net> In-Reply-To: <50461FB2.7080707@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.212.163] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.005 x-tm-as-result: No--40.196600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 04 Sep 2012 17:35:43 -0000 Thanks Lou for your reply. RFC 3473 defines procedures for NOTIFY request and reply. We could use this= for reverse LSP signaling error notification to the initiating ingress nod= e. ::=3D [] [ [ | = ] ... ] =20 > There are multiple ways we can use the NOTIFY message. Method 1 - Mid-point aware with Path message request: When an egress node receives a Path message with REVERSE_LSP object, the no= de will insert NOTIFY_REQ message in the reverse LSP path message with node= ID of the initiating ingress node. A mid-point node will send a copy of t= he signaling error to the initiating node using the NOTIFY message. IPv4 Notify Request Object IPv4 Notify Node Address: 32 bits The IP address of the node that should be notified when generating an= error message. Method 2 - Mid-point aware with Resv message request: When an initiating ingress node receives a Path message for a reverse LSP, = the node will insert NOTIFY_REQ message in the reverse LSP Resv message wit= h its own node ID. A mid-point node will send a copy of the signaling error= to the initiating node using the NOTIFY message. Method 3 - Tail-end relaying : When an egress node receives a Path message with REVERSE_LSP object, the no= de will relay the received signaling error message on the reverse LSP to th= e initializing ingress node. The egress node copies the received "ERROR_SPE= C" object into a NOTIFY [RFC3473, section 4.3] message and signals it to th= e ingress node. In this case, NOTIFY_REQ message is not required.=20 Please advise your thoughts. Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, September 04, 2012 11:35 AM To: Rakesh Gandhi (rgandhi) Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-04.txt As I read the current rev, no such notification mechanism is specified. Looks like you get to propose one! Lou (as WG participant). On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, Fei, >=20 > When an (originating) ingress node is provisioned with "5 (TBD) Single S= ided Associated Bidirectional LSPs (A)" and wishes to control both forward= and reverse LSPs by adding "REVERSE_LSP" object, I would think that the i= ngress node needs to know about the signaling (path) errors (such as soft p= reemption or admission failure) on the reverse LSP. Is there any text some= where in an RFC/draft that describes how a mid-point node can send the sign= aling (path) error to the originating ingress node for the reverse LSP? Is = there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any p= revious discussion on this topic. >=20 > Thanks, > Rakesh >=20 >=20 >=20 >=20 >=20 From gregb@grotto-networking.com Tue Sep 4 12:58:42 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 D6A7021E8082 for ; Tue, 4 Sep 2012 12:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2-cQQ1aJWsR for ; Tue, 4 Sep 2012 12:58:41 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BD80E21E8098 for ; Tue, 4 Sep 2012 12:58:41 -0700 (PDT) Received: from [10.0.0.4] (c-24-7-86-163.hsd1.ca.comcast.net [24.7.86.163]) by smtp.webfaction.com (Postfix) with ESMTP id 4E2D720FFEE4 for ; Tue, 4 Sep 2012 14:58:40 -0500 (CDT) Message-ID: <50465D6B.1060809@grotto-networking.com> Date: Tue, 04 Sep 2012 12:58:35 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> In-Reply-To: <50327B42.2010108@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.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, 04 Sep 2012 19:58:43 -0000 Hi Lou and CCAMPers. I haven't heard anything on this issue in two weeks. One simple way out of this would be to just use a variable length field for the OIC using the ITU-T application string rather than a fixed 64 bit field. If the ITU-T comes up with another specific encoding (64 bit or otherwise) in the future we can make sure to have a place holder. However, currently the ITU-T only defines application strings for this purpose. If I don't hear any other suggestions in two weeks, I'll make the change to incorporate variable length strings and keep place holders for defining fixed length fields. Then we can move this and related WSON documents into last call. Best Regards Greg B. On 8/20/2012 11:00 AM, Greg Bernstein wrote: > Optical Interface Class draft authors can you respond to Lou/List. > Let me know if we need to update the text. We are trying to get this > into last call. > Best Regards > Greg > On 8/20/2012 10:28 AM, Lou Berger wrote: >> Authors, >> >> I see that the draft says: >> In case of ITU Application Code, there should be a mapping between >> the string defining the application code and the 64 bits number >> implementing the optical interface class. >> >> Where is this mapping defined? Doesn't it have to be either in this >> draft or a normative reference? >> >> Thanks, >> Lou >> >> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>> Encoding for Wavelength Switched Optical Networks >>> Author(s) : Greg M. Bernstein >>> Young Lee >>> Dan Li >>> Wataru Imajuku >>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>> Pages : 33 >>> Date : 2012-08-16 >>> >>> Abstract: >>> A wavelength switched optical network (WSON) requires that certain >>> key information elements are made available to facilitate path >>> computation and the establishment of label switching paths (LSPs). >>> The information model described in "Routing and Wavelength >>> Assignment Information for Wavelength Switched Optical Networks" >>> shows what information is required at specific points in the WSON. >>> Part of the WSON information model contains aspects that may be of >>> general applicability to other technologies, while other parts are >>> fairly specific to WSONs. >>> >>> This document provides efficient, protocol-agnostic encodings for >>> the WSON specific information elements. It is intended that >>> protocol-specific documents will reference this memo to describe >>> how >>> information is carried for specific uses. Such encodings can be >>> used >>> to extend GMPLS signaling and routing protocols. In addition these >>> encodings could be used by other mechanisms to convey this same >>> information to a path computation element (PCE). >>> >>> >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 >> >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Tue Sep 4 13:16: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 DC63A21E8084 for ; Tue, 4 Sep 2012 13:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAaI-7Mp8iuj for ; Tue, 4 Sep 2012 13:16:45 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 1F75621E8082 for ; Tue, 4 Sep 2012 13:16:45 -0700 (PDT) Received: (qmail 4396 invoked by uid 0); 4 Sep 2012 20:16:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 4 Sep 2012 20:16: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=aIwRDbcwQkcNV3AViL9o++uFEYilJMASJRvXuDyxLBE=; b=kGimBqiQP6Etk8nd9ZvgVAvoBcbvVo6Wx1Ufni3ZdPKXOWf8pEmikbb4ty9M/aa0Z1hJ/zPKABLqfRoeZKbj/teBcF+JnevJpL/lrIxcYN587ruNzs5wkYbl3SMcISBz; Received: from box313.bluehost.com ([69.89.31.113]:34343 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T8zYA-0007rP-J6; Tue, 04 Sep 2012 14:16:42 -0600 Message-ID: <504661AC.3040109@labn.net> Date: Tue, 04 Sep 2012 16:16:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Greg Bernstein References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> In-Reply-To: <50465D6B.1060809@grotto-networking.com> X-Enigmail-Version: 1.4.4 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] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.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, 04 Sep 2012 20:16:46 -0000 Greg, Why not start with the concrete proposal that's already on the table, i.e., the text in http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? Frankly, I'm not sure why that text wasn't incorporated in the first place and figured I missed something -- which is why I sent my earlier mail. Lou On 9/4/2012 3:58 PM, Greg Bernstein wrote: > Hi Lou and CCAMPers. I haven't heard anything on this issue in two > weeks. One simple way out of this would be to just use a variable > length field for the OIC using the ITU-T application string rather than > a fixed 64 bit field. > If the ITU-T comes up with another specific encoding (64 bit or > otherwise) in the future we can make sure to have a place holder. > However, currently the ITU-T only defines application strings for this > purpose. > > If I don't hear any other suggestions in two weeks, I'll make the change > to incorporate variable length strings and keep place holders for > defining fixed length fields. Then we can move this and related WSON > documents into last call. > > Best Regards > Greg B. > > On 8/20/2012 11:00 AM, Greg Bernstein wrote: >> Optical Interface Class draft authors can you respond to Lou/List. >> Let me know if we need to update the text. We are trying to get this >> into last call. >> Best Regards >> Greg >> On 8/20/2012 10:28 AM, Lou Berger wrote: >>> Authors, >>> >>> I see that the draft says: >>> In case of ITU Application Code, there should be a mapping between >>> the string defining the application code and the 64 bits number >>> implementing the optical interface class. >>> >>> Where is this mapping defined? Doesn't it have to be either in this >>> draft or a normative reference? >>> >>> Thanks, >>> Lou >>> >>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>> Encoding for Wavelength Switched Optical Networks >>>> Author(s) : Greg M. Bernstein >>>> Young Lee >>>> Dan Li >>>> Wataru Imajuku >>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>> Pages : 33 >>>> Date : 2012-08-16 >>>> >>>> Abstract: >>>> A wavelength switched optical network (WSON) requires that certain >>>> key information elements are made available to facilitate path >>>> computation and the establishment of label switching paths (LSPs). >>>> The information model described in "Routing and Wavelength >>>> Assignment Information for Wavelength Switched Optical Networks" >>>> shows what information is required at specific points in the WSON. >>>> Part of the WSON information model contains aspects that may be of >>>> general applicability to other technologies, while other parts are >>>> fairly specific to WSONs. >>>> >>>> This document provides efficient, protocol-agnostic encodings for >>>> the WSON specific information elements. It is intended that >>>> protocol-specific documents will reference this memo to describe >>>> how >>>> information is carried for specific uses. Such encodings can be >>>> used >>>> to extend GMPLS signaling and routing protocols. In addition these >>>> encodings could be used by other mechanisms to convey this same >>>> information to a path computation element (PCE). >>>> >>>> >>>> >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 dieter.beller@alcatel-lucent.com Tue Sep 4 14:04: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 1049E21E8089 for ; Tue, 4 Sep 2012 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.791 X-Spam-Level: X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+rGHZqqnlMz for ; Tue, 4 Sep 2012 14:04:31 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 826D711E809A for ; Tue, 4 Sep 2012 14:04:30 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q84L4P2X001134 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 4 Sep 2012 23:04:26 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 23:04:25 +0200 Received: from [138.120.161.200] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Sep 2012 17:04:17 -0400 Message-ID: <50466CCD.9060300@alcatel-lucent.com> Date: Tue, 4 Sep 2012 23:04:13 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Lou Berger , Greg Bernstein References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> In-Reply-To: <504661AC.3040109@labn.net> Content-Type: multipart/related; boundary="------------000307020302060809090205" X-Originating-IP: [135.5.27.17] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.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, 04 Sep 2012 21:04:32 -0000 --------------000307020302060809090205 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Lou, Greg , and CCAMPers,

defining a mapping table (encoding) as proposed in the mentioned draft below seems
to be a reasonable way how to move forward. I do have some reservations when
dealing with strings in protocols.


Thanks,
Dieter

On 04.09.2012 22:16, Lou Berger wrote:
Greg,
	Why not start with the concrete proposal that's already on the table,
i.e., the text in
http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03?
Frankly, I'm not sure why that text wasn't incorporated in the first
place and figured I missed something -- which is why I sent my earlier mail.

Lou

On 9/4/2012 3:58 PM, Greg Bernstein wrote:

Hi Lou and CCAMPers.  I haven't heard anything on this issue in two 
weeks.  One simple way out of this would be to just use a variable 
length field for the OIC using the ITU-T application string rather than 
a fixed 64 bit field.
If the ITU-T comes up with another specific encoding (64 bit or 
otherwise) in the future we can make sure to have a place holder. 
However, currently the ITU-T only defines application strings for this 
purpose.

If I don't hear any other suggestions in two weeks, I'll make the change 
to incorporate variable length strings and keep place holders for 
defining fixed length fields.  Then we can move this and related WSON 
documents into last call.

Best Regards
Greg B.

On 8/20/2012 11:00 AM, Greg Bernstein wrote:

Optical Interface Class draft authors can you respond to Lou/List.  
Let me know if we need to update the text.  We are trying to get this 
into last call.
Best Regards
Greg
On 8/20/2012 10:28 AM, Lou Berger wrote:

Authors,

I see that the draft says:
      In case of ITU Application Code, there should be a mapping between
      the string defining the application code and the 64 bits number
      implementing the optical interface class.

Where is this mapping defined?  Doesn't it have to be either in this
draft or a normative reference?

Thanks,
Lou

On 8/16/2012 7:14 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           : Routing and Wavelength Assignment Information 
Encoding for Wavelength Switched Optical Networks
    Author(s)       : Greg M. Bernstein
                           Young Lee
                           Dan Li
                           Wataru Imajuku
    Filename        : draft-ietf-ccamp-rwa-wson-encode-16.txt
    Pages           : 33
    Date            : 2012-08-16

Abstract:
    A wavelength switched optical network (WSON) requires that certain
    key information elements are made available to facilitate path
    computation and the establishment of label switching paths (LSPs).
    The information model described in "Routing and Wavelength
    Assignment Information for Wavelength Switched Optical Networks"
    shows what information is required at specific points in the WSON.
    Part of the WSON information model contains aspects that may be of
    general applicability to other technologies, while other parts are
    fairly specific to WSONs.

    This document provides efficient, protocol-agnostic encodings for
    the WSON specific information elements. It is intended that
    protocol-specific documents will reference this memo to describe 
how
    information is carried for specific uses. Such encodings can be 
used
    to extend GMPLS signaling and routing protocols. In addition these
    encodings could be used by other mechanisms to convey this same
    information to a path computation element (PCE).





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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

--

DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
NETWORKS GROUP, OPTICS DIVISION
TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10
70435 Stuttgart, Germany
T: +49 711 821 43125
M: +49 175 7266874
Dieter.Beller@alcatel-lucent.com

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub ·
Dr. Rainer Fechner · Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the
e-mail and its attachments, if any, immediately. If you have received this e-mail in
error, you must not forward or make use of the e-mail and its attachments, if any.
--------------000307020302060809090205 Content-Type: image/jpeg; name="Corporate-sig-logo.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="Corporate-sig-logo.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5 OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX 2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69 1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09 bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ 7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3 PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT 51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7 jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1 +i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R 1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0 E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y 8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm 1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr 5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3 10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq 0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9 5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf 4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh 7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D 2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0 6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z 9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F /HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0 w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3 vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi 8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY 8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/ EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r 3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w 8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63 rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3 FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP 2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/ g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1 XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70 m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p 4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo 6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3 b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U 49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN 25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h /wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697 917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r 3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z --------------000307020302060809090205-- From iesg-secretary@ietf.org Tue Sep 4 14:16: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 6632F21E8089; Tue, 4 Sep 2012 14:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-QkLFJ1xo4L; Tue, 4 Sep 2012 14:16:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3341A21E8083; Tue, 4 Sep 2012 14:16:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120904211605.26354.6253.idtracker@ietfa.amsl.com> Date: Tue, 04 Sep 2012 14:16:05 -0700 Cc: ccamp mailing list , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks' to Proposed Standard (draft-ietf-ccamp-dpm-08.txt) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 21:16:06 -0000 The IESG has approved the following document: - 'Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks' (draft-ietf-ccamp-dpm-08.txt) as Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-dpm/ Technical Summary This document defines a series of performance metrics to evaluate the availability of data path during the signaling process. The metrics defined in this document complements the control plane metrics defined in [RFC5814]. These metrics can be used to verify the conformance of implementations against related specifications, as elaborated in [RFC6383]. Working Group Summary Document was a result of discussions that took place related to RFC5814. There were no objections raised to it's publication The document is on the Standards Track. This is consistent with its partner document, RFC 5814, and the output of the IPPM working group. Document Quality Implementation status is unknown (as is often the case), but contributors include a number of different types of vendors and carriers. Al Morton commented on the document while it was being moved through the working group. He also reviewed it as a member of the Performance Metrics Directorate. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd Adrian Farrel (adrian@olddog.co.uk) is the Area Director. From gregb@grotto-networking.com Wed Sep 5 08:03: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 81BDD21F8471 for ; Wed, 5 Sep 2012 08:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRjOuhlXc3pL for ; Wed, 5 Sep 2012 08:03:54 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 80D5E21F846D for ; Wed, 5 Sep 2012 08:03:53 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id B391C21009AB; Wed, 5 Sep 2012 10:03:52 -0500 (CDT) Message-ID: <504769D3.5020704@grotto-networking.com> Date: Wed, 05 Sep 2012 08:03:47 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Lou Berger References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> In-Reply-To: <504661AC.3040109@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:03:55 -0000 Hi Lou, I'll look at that text. I added to our document what the QIC authors suggested. Maybe they were planning something else? Greg On 9/4/2012 1:16 PM, Lou Berger wrote: > Greg, > Why not start with the concrete proposal that's already on the table, > i.e., the text in > http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? > Frankly, I'm not sure why that text wasn't incorporated in the first > place and figured I missed something -- which is why I sent my earlier mail. > > Lou > > On 9/4/2012 3:58 PM, Greg Bernstein wrote: >> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >> weeks. One simple way out of this would be to just use a variable >> length field for the OIC using the ITU-T application string rather than >> a fixed 64 bit field. >> If the ITU-T comes up with another specific encoding (64 bit or >> otherwise) in the future we can make sure to have a place holder. >> However, currently the ITU-T only defines application strings for this >> purpose. >> >> If I don't hear any other suggestions in two weeks, I'll make the change >> to incorporate variable length strings and keep place holders for >> defining fixed length fields. Then we can move this and related WSON >> documents into last call. >> >> Best Regards >> Greg B. >> >> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>> Optical Interface Class draft authors can you respond to Lou/List. >>> Let me know if we need to update the text. We are trying to get this >>> into last call. >>> Best Regards >>> Greg >>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>> Authors, >>>> >>>> I see that the draft says: >>>> In case of ITU Application Code, there should be a mapping between >>>> the string defining the application code and the 64 bits number >>>> implementing the optical interface class. >>>> >>>> Where is this mapping defined? Doesn't it have to be either in this >>>> draft or a normative reference? >>>> >>>> Thanks, >>>> Lou >>>> >>>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>>> Encoding for Wavelength Switched Optical Networks >>>>> Author(s) : Greg M. Bernstein >>>>> Young Lee >>>>> Dan Li >>>>> Wataru Imajuku >>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>> Pages : 33 >>>>> Date : 2012-08-16 >>>>> >>>>> Abstract: >>>>> A wavelength switched optical network (WSON) requires that certain >>>>> key information elements are made available to facilitate path >>>>> computation and the establishment of label switching paths (LSPs). >>>>> The information model described in "Routing and Wavelength >>>>> Assignment Information for Wavelength Switched Optical Networks" >>>>> shows what information is required at specific points in the WSON. >>>>> Part of the WSON information model contains aspects that may be of >>>>> general applicability to other technologies, while other parts are >>>>> fairly specific to WSONs. >>>>> >>>>> This document provides efficient, protocol-agnostic encodings for >>>>> the WSON specific information elements. It is intended that >>>>> protocol-specific documents will reference this memo to describe >>>>> how >>>>> information is carried for specific uses. Such encodings can be >>>>> used >>>>> to extend GMPLS signaling and routing protocols. In addition these >>>>> encodings could be used by other mechanisms to convey this same >>>>> information to a path computation element (PCE). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>>> >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Wed Sep 5 08:18: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 9A58A21F84CD for ; Wed, 5 Sep 2012 08:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.161 X-Spam-Level: X-Spam-Status: No, score=-100.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv2quMQGraiE for ; Wed, 5 Sep 2012 08:18:45 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id B8B6921F84E6 for ; Wed, 5 Sep 2012 08:18:45 -0700 (PDT) Received: (qmail 5740 invoked by uid 0); 5 Sep 2012 15:18:43 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 5 Sep 2012 15:18:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=knrCFzHZ8s2vWnbd793ClGWUCPsA7O74BYiVe1mWG0U=; b=AlyB/d+mtdfqom4CgIaRu+25nPS69uRRg3u6rGwpQtSRRAHLB4gKUUwRXKvJAnp6/tBJArDKiOfRi5KNa2JzxENyumJi6NB3s5Lhp4Q1E9IYRH6MzYkmP5eKFD5WJqmx; Received: from box313.bluehost.com ([69.89.31.113]:50516 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T9HNL-0000Zq-97; Wed, 05 Sep 2012 09:18:43 -0600 Message-ID: <50476D56.6000108@labn.net> Date: Wed, 05 Sep 2012 11:18:46 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Greg Bernstein References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> In-Reply-To: <504769D3.5020704@grotto-networking.com> X-Enigmail-Version: 1.4.4 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] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:18:46 -0000 Greg, Okay. Based on the meeting/discussions and the draft, I had expected there was sufficient consensus & text to work from. As editors, you're free to document your perspective on consensus as works best for you. Let us (chairs) know if you need assistance and we'll figure out how to help. Lou On 9/5/2012 11:03 AM, Greg Bernstein wrote: > Hi Lou, I'll look at that text. I added to our document what the QIC > authors suggested. Maybe they were planning something else? > Greg > On 9/4/2012 1:16 PM, Lou Berger wrote: >> Greg, >> Why not start with the concrete proposal that's already on the table, >> i.e., the text in >> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >> Frankly, I'm not sure why that text wasn't incorporated in the first >> place and figured I missed something -- which is why I sent my earlier mail. >> >> Lou >> >> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>> weeks. One simple way out of this would be to just use a variable >>> length field for the OIC using the ITU-T application string rather than >>> a fixed 64 bit field. >>> If the ITU-T comes up with another specific encoding (64 bit or >>> otherwise) in the future we can make sure to have a place holder. >>> However, currently the ITU-T only defines application strings for this >>> purpose. >>> >>> If I don't hear any other suggestions in two weeks, I'll make the change >>> to incorporate variable length strings and keep place holders for >>> defining fixed length fields. Then we can move this and related WSON >>> documents into last call. >>> >>> Best Regards >>> Greg B. >>> >>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>> Optical Interface Class draft authors can you respond to Lou/List. >>>> Let me know if we need to update the text. We are trying to get this >>>> into last call. >>>> Best Regards >>>> Greg >>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>> Authors, >>>>> >>>>> I see that the draft says: >>>>> In case of ITU Application Code, there should be a mapping between >>>>> the string defining the application code and the 64 bits number >>>>> implementing the optical interface class. >>>>> >>>>> Where is this mapping defined? Doesn't it have to be either in this >>>>> draft or a normative reference? >>>>> >>>>> Thanks, >>>>> Lou >>>>> >>>>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>>>> Encoding for Wavelength Switched Optical Networks >>>>>> Author(s) : Greg M. Bernstein >>>>>> Young Lee >>>>>> Dan Li >>>>>> Wataru Imajuku >>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>> Pages : 33 >>>>>> Date : 2012-08-16 >>>>>> >>>>>> Abstract: >>>>>> A wavelength switched optical network (WSON) requires that certain >>>>>> key information elements are made available to facilitate path >>>>>> computation and the establishment of label switching paths (LSPs). >>>>>> The information model described in "Routing and Wavelength >>>>>> Assignment Information for Wavelength Switched Optical Networks" >>>>>> shows what information is required at specific points in the WSON. >>>>>> Part of the WSON information model contains aspects that may be of >>>>>> general applicability to other technologies, while other parts are >>>>>> fairly specific to WSONs. >>>>>> >>>>>> This document provides efficient, protocol-agnostic encodings for >>>>>> the WSON specific information elements. It is intended that >>>>>> protocol-specific documents will reference this memo to describe >>>>>> how >>>>>> information is carried for specific uses. Such encodings can be >>>>>> used >>>>>> to extend GMPLS signaling and routing protocols. In addition these >>>>>> encodings could be used by other mechanisms to convey this same >>>>>> information to a path computation element (PCE). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>>>> >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> 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 internet-drafts@ietf.org Wed Sep 5 11:25: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 9138B21F86BB; Wed, 5 Sep 2012 11:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNHtpNcEHF7q; Wed, 5 Sep 2012 11:25:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007B121F865E; Wed, 5 Sep 2012 11:25:31 -0700 (PDT) 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: 4.34 Message-ID: <20120905182530.5079.13283.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 11:25:30 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-17.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:25:31 -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 Work= ing Group of the IETF. Title : Routing and Wavelength Assignment Information Encoding f= or Wavelength Switched Optical Networks Author(s) : Greg M. Bernstein Young Lee Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-wson-encode-17.txt Pages : 38 Date : 2012-09-05 Abstract: A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-encode-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gregb@grotto-networking.com Wed Sep 5 11: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 7A3E621F8671 for ; Wed, 5 Sep 2012 11:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOHjBQmvAWOK for ; Wed, 5 Sep 2012 11:31:45 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3728E21F8669 for ; Wed, 5 Sep 2012 11:31:45 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 4533920FFE3D for ; Wed, 5 Sep 2012 13:31:28 -0500 (CDT) Message-ID: <50479A7B.3010401@grotto-networking.com> Date: Wed, 05 Sep 2012 11:31:23 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <20120905182530.5079.13283.idtracker@ietfa.amsl.com> In-Reply-To: <20120905182530.5079.13283.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-17.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:31:47 -0000 Hi CCAMPer's we have updated the WSON Encoding draft to use the ITU-T application string to 64 bit field mapping defined in the OIC draft with some small editorial changes for clarity and generality, e.g., the G.959.1 application code suffixes do not appear to all be mutually exclusive hence a bit map field seems called for. Please review. URL:http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-17.txt Best Regards Greg B. On 9/5/2012 11:25 AM, 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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks > Author(s) : Greg M. Bernstein > Young Lee > Dan Li > Wataru Imajuku > Filename : draft-ietf-ccamp-rwa-wson-encode-17.txt > Pages : 38 > Date : 2012-09-05 > > Abstract: > A wavelength switched optical network (WSON) requires that certain > key information elements are made available to facilitate path > computation and the establishment of label switching paths (LSPs). > The information model described in "Routing and Wavelength > Assignment Information for Wavelength Switched Optical Networks" > shows what information is required at specific points in the WSON. > Part of the WSON information model contains aspects that may be of > general applicability to other technologies, while other parts are > fairly specific to WSONs. > > This document provides efficient, protocol-agnostic encodings for > the WSON specific information elements. It is intended that > protocol-specific documents will reference this memo to describe how > information is carried for specific uses. Such encodings can be used > to extend GMPLS signaling and routing protocols. In addition these > encodings could be used by other mechanisms to convey this same > information to a path computation element (PCE). > > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-17 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-17 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Wed Sep 5 12:03: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 63ABB21F86CE for ; Wed, 5 Sep 2012 12:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.084 X-Spam-Level: X-Spam-Status: No, score=-100.084 tagged_above=-999 required=5 tests=[AWL=0.077, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfwBVfmx1Uwq for ; Wed, 5 Sep 2012 12:03:38 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id A71BF21F865B for ; Wed, 5 Sep 2012 12:03:38 -0700 (PDT) Received: (qmail 21302 invoked by uid 0); 5 Sep 2012 19:03:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 5 Sep 2012 19:03:37 -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=U7OmKThrT9FZJWao58KS2TQoo43gy4WuC+F6iXKqUqU=; b=bOagljYfYtCF+fVYhih5B1hq4g493g4ftK+g++VnQzfV0cno3yqBHPJcxDyJVXeGirAscEaRMKEmMMjCTF3oo4vSjmFtpevr1rmCu00Oktr6sJYdk6hZ/te+e5aPnXsQ; Received: from box313.bluehost.com ([69.89.31.113]:44843 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T9Ksz-0008QO-0Z; Wed, 05 Sep 2012 13:03:37 -0600 Message-ID: <5047A20C.9030202@labn.net> Date: Wed, 05 Sep 2012 15:03:40 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Greg Bernstein References: <20120905182530.5079.13283.idtracker@ietfa.amsl.com> <50479A7B.3010401@grotto-networking.com> In-Reply-To: <50479A7B.3010401@grotto-networking.com> X-Enigmail-Version: 1.4.4 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] I-D Action: draft-ietf-ccamp-rwa-wson-encode-17.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:03:39 -0000 Greg, Thank you for the quick turn-around! Lou On 9/5/2012 2:31 PM, Greg Bernstein wrote: > Hi CCAMPer's we have updated the WSON Encoding draft to use the ITU-T > application string to 64 bit field mapping defined in the OIC draft with > some small editorial changes for clarity and generality, e.g., the > G.959.1 application code suffixes do not appear to all be mutually > exclusive hence a bit map field seems called for. Please review. > > URL:http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-17.txt > > Best Regards > Greg B. > > On 9/5/2012 11:25 AM, 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 : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks >> Author(s) : Greg M. Bernstein >> Young Lee >> Dan Li >> Wataru Imajuku >> Filename : draft-ietf-ccamp-rwa-wson-encode-17.txt >> Pages : 38 >> Date : 2012-09-05 >> >> Abstract: >> A wavelength switched optical network (WSON) requires that certain >> key information elements are made available to facilitate path >> computation and the establishment of label switching paths (LSPs). >> The information model described in "Routing and Wavelength >> Assignment Information for Wavelength Switched Optical Networks" >> shows what information is required at specific points in the WSON. >> Part of the WSON information model contains aspects that may be of >> general applicability to other technologies, while other parts are >> fairly specific to WSONs. >> >> This document provides efficient, protocol-agnostic encodings for >> the WSON specific information elements. It is intended that >> protocol-specific documents will reference this memo to describe how >> information is carried for specific uses. Such encodings can be used >> to extend GMPLS signaling and routing protocols. In addition these >> encodings could be used by other mechanisms to convey this same >> information to a path computation element (PCE). >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-17 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-17 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> > > From internet-drafts@ietf.org Wed Sep 5 14:44: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 920D921F86FC; Wed, 5 Sep 2012 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uxNTWca5v4H; Wed, 5 Sep 2012 14:44:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A021F86D4; Wed, 5 Sep 2012 14:44:53 -0700 (PDT) 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: 4.34 Message-ID: <20120905214453.2031.89347.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 14:44:53 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 21:44:53 -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 Work= ing Group of the IETF. Title : RSVP Association Object Extensions Author(s) : Lou Berger Francois Le Faucheur Ashok Narayanan Filename : draft-ietf-ccamp-assoc-ext-05.txt Pages : 17 Date : 2012-09-05 Abstract: 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 the Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-assoc-ext-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lberger@labn.net Wed Sep 5 16:59:07 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 9DAB121F86D5 for ; Wed, 5 Sep 2012 16:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.037 X-Spam-Level: X-Spam-Status: No, score=-100.037 tagged_above=-999 required=5 tests=[AWL=0.124, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VS+5C1Ka2be9 for ; Wed, 5 Sep 2012 16:59:07 -0700 (PDT) Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 93DAA21F86E8 for ; Wed, 5 Sep 2012 16:59:06 -0700 (PDT) Received: (qmail 28022 invoked by uid 0); 5 Sep 2012 21:49:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 5 Sep 2012 21:49:37 -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=XChJK/Is45HDheAOGszEKmZ6ma85QnvirikFVMsHDXQ=; b=ANO+8S4tgRVVqMa85xjQ0qWJRChM+GtxB9M5ewXTS5suKPa6yaCebYJWpOYgh4yAWZGMKWIHszqCn8FSJVwvfA5ZHaONfNSNNVAUg8IxhA3KTw8l2bhDjFa2u4idezkQ; Received: from box313.bluehost.com ([69.89.31.113]:32965 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1T9NTd-00026K-Dc; Wed, 05 Sep 2012 15:49:37 -0600 Message-ID: <5047C8F4.1070904@labn.net> Date: Wed, 05 Sep 2012 17:49:40 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: ccamp@ietf.org References: <20120905214453.2031.89347.idtracker@ietfa.amsl.com> In-Reply-To: <20120905214453.2031.89347.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 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: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 23:59:07 -0000 All, This update addresses comments received during AD and IESG review. There are quite a few editorial changes thanks to a very careful review by Dimitri. The technically substantive changes are the additions of the following: 3.3.2. Unknown Association Types A node that receives an ASSOCIATION object with an unknown ASSOCIATION type MUST forward all received ASSOCIATION objects as defined above. The node MAY also identify associations per the defined processing, e.g., to make this information available via a management interface. and 5. Compatibility Per [RFC4872], the ASSOCIATION object uses an object class number of the form 11bbbbbb to ensure compatibility with non- supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification. This is essentially also the action taken for unknown association types as discussed above in Section 3.3.2. Operators wishing to use a function supported by particular association type should ensure that the type is supported on any node which is expected to act on the association. Lou (as co-author) On 9/5/2012 5:44 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-05.txt > Pages : 17 > Date : 2012-09-05 > > Abstract: > 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 the Transport Profile of Multiprotocol Label > Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, > and RFC 3473. It also generalizes the definition of the Association > ID field defined in RFC 4872. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > > From internet-drafts@ietf.org Fri Sep 7 06:58: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 1579121F87EC; Fri, 7 Sep 2012 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HmfQeFLqvBk; Fri, 7 Sep 2012 06:58:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F39A21F87B6; Fri, 7 Sep 2012 06:58:38 -0700 (PDT) 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: 4.34 Message-ID: <20120907135838.3865.87500.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 06:58:38 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05.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, 07 Sep 2012 13:58:39 -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 Work= ing Group of the IETF. Title : GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Confi= guration Author(s) : Andras Kern Attila Takacs Filename : draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05.txt Pages : 22 Date : 2012-09-07 Abstract: GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for the configuration of the supervision functions is not specified. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in [GMPLS-OAM-FWK]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext= -05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From giomarti@cisco.com Mon Sep 10 10:02:37 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 73D9821F84D6 for ; Mon, 10 Sep 2012 10:02:37 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q912nnACJM18 for ; Mon, 10 Sep 2012 10:02:36 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8046E21F859E for ; Mon, 10 Sep 2012 10:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6889; q=dns/txt; s=iport; t=1347296556; x=1348506156; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ygVK/+bFwozc1+XGtDJnyMY/gln0exYSWsVJXPD4UPA=; b=Lu2tGaD6XOWicWyMzu1LmRR2xU6+sNLydOQFMZV6XwqqPYy9aBREMQgF usf1hl8NIcvqYvNB4/Qlw8bvImni4xjPjEG2BWNxli++cfM9RnL0k+hqq rMLY2r/C2476QSnVIb+NFWaaCqhAObJN6Lq9x0HR8zBUi9A7rmdC9vYms Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP4bTlCtJV2a/2dsb2JhbABFu0OBB4IgAQEBAwEBAQEPASctBwsFCwIBCA4KHhAnCyUCBA4FCRmHaAYLmzGMD5NyixMahTxgA5VdgRSNIoFngmaBYw X-IronPort-AV: E=Sophos;i="4.80,398,1344211200"; d="scan'208";a="120063577" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 10 Sep 2012 17:02:35 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8AH2ZS5031195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Sep 2012 17:02:35 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Mon, 10 Sep 2012 12:02:35 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt Thread-Index: AQHNitezjDYoXHthsUGj7mjNperrOZd68okAgAE65YCAAAQwAIAH+KsA Date: Mon, 10 Sep 2012 17:02:34 +0000 Message-ID: <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> In-Reply-To: <50476D56.6000108@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.005 x-tm-as-result: No--65.082400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.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, 10 Sep 2012 17:02:37 -0000 Hi Greg, Lou, having a quick look to wson draft update I generally agree on content (as e= xpected) what I'm wandering if it worth moving the interface class encoding= within the draft-ieft-ccamp-rwa-wson-encode. Here an alternate proposal on the table:=20 leave the generic OIC container definition within current wson-encode draft= and put specific OIC encoding (with related ITU references) in a separate = draft (which could be a new version of draft-martinelli-wson-interface-clas= s or a brand new draft). This separation will probably allow finalizing the= wson-info-model and wson-encoding separately from specific OIC content (so= we'll collect most updated ITU references as already mentioned we still mi= ss few of them. =20 I guess is for WG chairs to decide. If we stay with current doc splitting I'll go for a detailed review on late= st updates. Sorry for raising it with a bit of delay but, just want to make= sure was an option consciously avoided. Cheers G On Sep 5, 2012, at 17:18 , Lou Berger wrote: > Greg, > Okay. Based on the meeting/discussions and the draft, I had expected > there was sufficient consensus & text to work from. As editors, you're > free to document your perspective on consensus as works best for you. > Let us (chairs) know if you need assistance and we'll figure out how to > help. >=20 > Lou >=20 > On 9/5/2012 11:03 AM, Greg Bernstein wrote: >> Hi Lou, I'll look at that text. I added to our document what the QIC=20 >> authors suggested. Maybe they were planning something else? >> Greg >> On 9/4/2012 1:16 PM, Lou Berger wrote: >>> Greg, >>> Why not start with the concrete proposal that's already on the table, >>> i.e., the text in >>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >>> Frankly, I'm not sure why that text wasn't incorporated in the first >>> place and figured I missed something -- which is why I sent my earlier = mail. >>>=20 >>> Lou >>>=20 >>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>>> weeks. One simple way out of this would be to just use a variable >>>> length field for the OIC using the ITU-T application string rather tha= n >>>> a fixed 64 bit field. >>>> If the ITU-T comes up with another specific encoding (64 bit or >>>> otherwise) in the future we can make sure to have a place holder. >>>> However, currently the ITU-T only defines application strings for this >>>> purpose. >>>>=20 >>>> If I don't hear any other suggestions in two weeks, I'll make the chan= ge >>>> to incorporate variable length strings and keep place holders for >>>> defining fixed length fields. Then we can move this and related WSON >>>> documents into last call. >>>>=20 >>>> Best Regards >>>> Greg B. >>>>=20 >>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>> Optical Interface Class draft authors can you respond to Lou/List. >>>>> Let me know if we need to update the text. We are trying to get this >>>>> into last call. >>>>> Best Regards >>>>> Greg >>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>> Authors, >>>>>>=20 >>>>>> I see that the draft says: >>>>>> In case of ITU Application Code, there should be a mapping bet= ween >>>>>> the string defining the application code and the 64 bits numbe= r >>>>>> implementing the optical interface class. >>>>>>=20 >>>>>> Where is this mapping defined? Doesn't it have to be either in this >>>>>> draft or a normative reference? >>>>>>=20 >>>>>> Thanks, >>>>>> Lou >>>>>>=20 >>>>>> On 8/16/2012 7:14 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. >>>>>>>=20 >>>>>>> Title : Routing and Wavelength Assignment Information >>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>> Author(s) : Greg M. Bernstein >>>>>>> Young Lee >>>>>>> Dan Li >>>>>>> Wataru Imajuku >>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>> Pages : 33 >>>>>>> Date : 2012-08-16 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> A wavelength switched optical network (WSON) requires that cert= ain >>>>>>> key information elements are made available to facilitate path >>>>>>> computation and the establishment of label switching paths (LSP= s). >>>>>>> The information model described in "Routing and Wavelength >>>>>>> Assignment Information for Wavelength Switched Optical Networks= " >>>>>>> shows what information is required at specific points in the WS= ON. >>>>>>> Part of the WSON information model contains aspects that may be= of >>>>>>> general applicability to other technologies, while other parts = are >>>>>>> fairly specific to WSONs. >>>>>>>=20 >>>>>>> This document provides efficient, protocol-agnostic encodings f= or >>>>>>> the WSON specific information elements. It is intended that >>>>>>> protocol-specific documents will reference this memo to describ= e >>>>>>> how >>>>>>> information is carried for specific uses. Such encodings can be >>>>>>> used >>>>>>> to extend GMPLS signaling and routing protocols. In addition th= ese >>>>>>> encodings could be used by other mechanisms to convey this same >>>>>>> information to a path computation element (PCE). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>=20 >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-encode= -16 >>>>>>>=20 >>>>>>>=20 >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>=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 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >>=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From rgandhi@cisco.com Tue Sep 11 06:22:28 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 2965521F85E6 for ; Tue, 11 Sep 2012 06:22:26 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9Xi6Pu9Fi9S for ; Tue, 11 Sep 2012 06:22:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 686CB21F87E7 for ; Tue, 11 Sep 2012 06:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3355; q=dns/txt; s=iport; t=1347369742; x=1348579342; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=Ae8iRtp2Ys6v+T3W9Q5GIect5sf2/VATx1qcfWXvfWY=; b=h3uFYD68FFA3rj+VGFJ13XZYtxxA4gWGR15NizC7NTiapcD2SRpEIR2K 6XBW8EvSFtAZkiRujIpJ40YuxEjyYC1Tq8td8HsDuebpUNhDYRja8ZzJM h2MZI8dKCjmjEco5hRkOOMonUnFEm4AqHlgv0PYcj8RRKTmnhTW0zbZn1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJs6T1CtJXG//2dsb2JhbABFu1CBB4IgAQEBBBIBJz8MBAIBCA4DBAEBAQoUCQcyFAkIAQEEDgUIGodum0ygVIsQhUZgA6QTgWeCZg X-IronPort-AV: E=Sophos;i="4.80,404,1344211200"; d="scan'208";a="120415629" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 11 Sep 2012 13:22:21 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8BDMKIM027592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Sep 2012 13:22:20 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Tue, 11 Sep 2012 08:22:20 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsA== Date: Tue, 11 Sep 2012 13:22:19 +0000 Message-ID: References: <50461FB2.7080707@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.232.238] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19176.006 x-tm-as-result: No--40.196600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 11 Sep 2012 13:22:28 -0000 Hi WG, Any thoughts on the following proposal? Thanks, Rakesh -----Original Message----- From: Rakesh Gandhi (rgandhi)=20 Sent: Tuesday, September 04, 2012 1:36 PM To: 'Lou Berger' Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-04.txt Thanks Lou for your reply. RFC 3473 defines procedures for NOTIFY request and reply. We could use this= for reverse LSP signaling error notification to the initiating ingress nod= e. ::=3D [] [ [ | = ] ... ] =20 > There are multiple ways we can use the NOTIFY message. Method 1 - Mid-point aware with Path message request: When an egress node receives a Path message with REVERSE_LSP object, the no= de will insert NOTIFY_REQ message in the reverse LSP path message with node= ID of the initiating ingress node. A mid-point node will send a copy of t= he signaling error to the initiating node using the NOTIFY message. IPv4 Notify Request Object IPv4 Notify Node Address: 32 bits The IP address of the node that should be notified when generating an= error message. Method 2 - Mid-point aware with Resv message request: When an initiating ingress node receives a Path message for a reverse LSP, = the node will insert NOTIFY_REQ message in the reverse LSP Resv message wit= h its own node ID. A mid-point node will send a copy of the signaling error= to the initiating node using the NOTIFY message. Method 3 - Tail-end relaying : When an egress node receives a Path message with REVERSE_LSP object, the no= de will relay the received signaling error message on the reverse LSP to th= e initializing ingress node. The egress node copies the received "ERROR_SPE= C" object into a NOTIFY [RFC3473, section 4.3] message and signals it to th= e ingress node. In this case, NOTIFY_REQ message is not required.=20 Please advise your thoughts. Thanks, Rakesh -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Tuesday, September 04, 2012 11:35 AM To: Rakesh Gandhi (rgandhi) Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext= -associated-lsp-04.txt As I read the current rev, no such notification mechanism is specified. Looks like you get to propose one! Lou (as WG participant). On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote: > Hi Lou, Fei, >=20 > When an (originating) ingress node is provisioned with "5 (TBD) Single S= ided Associated Bidirectional LSPs (A)" and wishes to control both forward= and reverse LSPs by adding "REVERSE_LSP" object, I would think that the i= ngress node needs to know about the signaling (path) errors (such as soft p= reemption or admission failure) on the reverse LSP. Is there any text some= where in an RFC/draft that describes how a mid-point node can send the sign= aling (path) error to the originating ingress node for the reverse LSP? Is = there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any p= revious discussion on this topic. >=20 > Thanks, > Rakesh >=20 >=20 >=20 >=20 >=20 From swallow@cisco.com Tue Sep 11 12:29:05 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 6E16121F8692 for ; Tue, 11 Sep 2012 12:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl0-oCm6sRxN for ; Tue, 11 Sep 2012 12:29:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5B17A21F85EA for ; Tue, 11 Sep 2012 12:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2406; q=dns/txt; s=iport; t=1347391737; x=1348601337; h=from:to:cc:subject:date:message-id:mime-version; bh=sC+4AoyWUTjeGwfkbOUYxZagZmNeZcC1OLyWW6OHxD8=; b=VUCnHma0ZUGlGBU3HPiF53E+fy6KIBg4fdafcpec+cp0VUUBCd1j0CCm 8WuuDb4Yk1w6XiqqiCTrjikGTWU6wIr8SwVT9uUDpilc0cm9is23xca32 Or/T8tLdKPE2oFzgw8JOeGPYNqgVaoYS9XndpXJXayP/hjZVf8mLZeqE8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALSQT1CtJV2b/2dsb2JhbABFgku5C4EHgicSAWYSAQwBcycEDieHbps6oFeRNgOVX442gWeCZg X-IronPort-AV: E=Sophos;i="4.80,406,1344211200"; d="scan'208,217";a="120515393" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 11 Sep 2012 19:28:57 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8BJSuo6017682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Sep 2012 19:28:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Tue, 11 Sep 2012 14:28:56 -0500 From: "George Swallow (swallow)" To: Julien Meuric Thread-Topic: Objective function draft Thread-Index: AQHNkFOv4OOKfbxolEe2spFvFX1LfA== Date: Tue, 11 Sep 2012 19:28:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.32.167] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.000 x-tm-as-result: No--28.301900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC750935C0DFswallowciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] Objective function draft 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, 11 Sep 2012 19:29:05 -0000 --_000_CC750935C0DFswallowciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Julien - Reading the CCAMP notes (which capture little of the actual discussion) I s= ee that there may have been a perception in the room that PCE functionality= at the UNI-N was assumed (actual or proxy). This is not the case. The reason for our draft is that with the UNI, much = of the functionality that resides at the headend is moved to the UNI-N. So= the UNI-C needs a way to express an objective function even if there is no= PCE. Operationally it seems burdensome to require a PCEP at the UNI-C and a PCEP= at the UNI-N, when all that is being done is enabling the UNI-N to perform= what the client would do if it were connected to the network via a normal = link. Do you still object to the draft? Thanks, =85George --_000_CC750935C0DFswallowciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Julien -

Reading the CCAMP notes (which capture little of the actual discussion= ) I see that there may have been a perception in the room that PCE function= ality at the UNI-N was assumed (actual or proxy).

This is not the case.  The reason for our draft is that with the = UNI, much of the functionality that resides at the headend is moved to the = UNI-N.  So the UNI-C needs a way to express an objective function even= if there is no PCE.  

Operationally it seems burdensome to require a PCEP at the UNI-C and a= PCEP at the UNI-N, when all that is being done is enabling the UNI-N to pe= rform what the client would do if it were connected to the network via a no= rmal link.

Do you still object to the draft?  

Thanks,

=85George
--_000_CC750935C0DFswallowciscocom_-- From gregb@grotto-networking.com Tue Sep 11 13:22: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 3E3E521F86B2 for ; Tue, 11 Sep 2012 13:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J1hhPN13HnV for ; Tue, 11 Sep 2012 13:22:24 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0007421F871D for ; Tue, 11 Sep 2012 13:22:23 -0700 (PDT) Received: from [10.0.0.4] (c-24-7-86-163.hsd1.ca.comcast.net [24.7.86.163]) by smtp.webfaction.com (Postfix) with ESMTP id B31AE20781E8; Tue, 11 Sep 2012 15:22:22 -0500 (CDT) Message-ID: <504F9D7C.2040302@grotto-networking.com> Date: Tue, 11 Sep 2012 13:22:20 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> In-Reply-To: <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.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, 11 Sep 2012 20:22:25 -0000 Hi Giovanni we updated the WSON encode draft back on September 5th to put the interface class encoding into the draft. This was in response to the question raised by Lou in a August 20th email. Lou, Deborah and OIC draft authors do we need to change this back? Please let us know ASAP as we are trying to get all the WSON drafts into last call and this seems to be the last outstanding issue. Best Regards Greg On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: > Hi Greg, Lou, > > having a quick look to wson draft update I generally agree on content (as expected) what I'm wandering if it worth moving the interface class encoding within the draft-ieft-ccamp-rwa-wson-encode. > > Here an alternate proposal on the table: > leave the generic OIC container definition within current wson-encode draft and put specific OIC encoding (with related ITU references) in a separate draft (which could be a new version of draft-martinelli-wson-interface-class or a brand new draft). This separation will probably allow finalizing the wson-info-model and wson-encoding separately from specific OIC content (so we'll collect most updated ITU references as already mentioned we still miss few of them. > > > I guess is for WG chairs to decide. > > If we stay with current doc splitting I'll go for a detailed review on latest updates. Sorry for raising it with a bit of delay but, just want to make sure was an option consciously avoided. > > Cheers > G > > > > On Sep 5, 2012, at 17:18 , Lou Berger wrote: > >> Greg, >> Okay. Based on the meeting/discussions and the draft, I had expected >> there was sufficient consensus & text to work from. As editors, you're >> free to document your perspective on consensus as works best for you. >> Let us (chairs) know if you need assistance and we'll figure out how to >> help. >> >> Lou >> >> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>> Hi Lou, I'll look at that text. I added to our document what the QIC >>> authors suggested. Maybe they were planning something else? >>> Greg >>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>> Greg, >>>> Why not start with the concrete proposal that's already on the table, >>>> i.e., the text in >>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >>>> Frankly, I'm not sure why that text wasn't incorporated in the first >>>> place and figured I missed something -- which is why I sent my earlier mail. >>>> >>>> Lou >>>> >>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>>>> weeks. One simple way out of this would be to just use a variable >>>>> length field for the OIC using the ITU-T application string rather than >>>>> a fixed 64 bit field. >>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>> otherwise) in the future we can make sure to have a place holder. >>>>> However, currently the ITU-T only defines application strings for this >>>>> purpose. >>>>> >>>>> If I don't hear any other suggestions in two weeks, I'll make the change >>>>> to incorporate variable length strings and keep place holders for >>>>> defining fixed length fields. Then we can move this and related WSON >>>>> documents into last call. >>>>> >>>>> Best Regards >>>>> Greg B. >>>>> >>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>> Optical Interface Class draft authors can you respond to Lou/List. >>>>>> Let me know if we need to update the text. We are trying to get this >>>>>> into last call. >>>>>> Best Regards >>>>>> Greg >>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>> Authors, >>>>>>> >>>>>>> I see that the draft says: >>>>>>> In case of ITU Application Code, there should be a mapping between >>>>>>> the string defining the application code and the 64 bits number >>>>>>> implementing the optical interface class. >>>>>>> >>>>>>> Where is this mapping defined? Doesn't it have to be either in this >>>>>>> draft or a normative reference? >>>>>>> >>>>>>> Thanks, >>>>>>> Lou >>>>>>> >>>>>>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>> Young Lee >>>>>>>> Dan Li >>>>>>>> Wataru Imajuku >>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>> Pages : 33 >>>>>>>> Date : 2012-08-16 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> A wavelength switched optical network (WSON) requires that certain >>>>>>>> key information elements are made available to facilitate path >>>>>>>> computation and the establishment of label switching paths (LSPs). >>>>>>>> The information model described in "Routing and Wavelength >>>>>>>> Assignment Information for Wavelength Switched Optical Networks" >>>>>>>> shows what information is required at specific points in the WSON. >>>>>>>> Part of the WSON information model contains aspects that may be of >>>>>>>> general applicability to other technologies, while other parts are >>>>>>>> fairly specific to WSONs. >>>>>>>> >>>>>>>> This document provides efficient, protocol-agnostic encodings for >>>>>>>> the WSON specific information elements. It is intended that >>>>>>>> protocol-specific documents will reference this memo to describe >>>>>>>> how >>>>>>>> information is carried for specific uses. Such encodings can be >>>>>>>> used >>>>>>>> to extend GMPLS signaling and routing protocols. In addition these >>>>>>>> encodings could be used by other mechanisms to convey this same >>>>>>>> information to a path computation element (PCE). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>> >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From adrian@olddog.co.uk Tue Sep 11 16:39: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 5CD7121E804B for ; Tue, 11 Sep 2012 16:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7ldoNkvEDGc for ; Tue, 11 Sep 2012 16:39:18 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9C06B21E804A for ; Tue, 11 Sep 2012 16:39:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q8BNdEI5016631; Wed, 12 Sep 2012 00:39:14 +0100 Received: from 950129200 ([200.35.189.178]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q8BNd8CU016598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2012 00:39:12 +0100 From: "Adrian Farrel" To: "'George Swallow \(swallow\)'" , "'Julien Meuric'" References: In-Reply-To: Date: Wed, 12 Sep 2012 00:39:07 +0100 Message-ID: <03d701cd9076$a5bfbf00$f13f3d00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03D8_01CD907F.078D9CE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGNprBeZWrGTHwFWXeFYqDAiAskDpgFm7VQ Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] Objective function draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 23:39:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03D8_01CD907F.078D9CE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm hoping that you have looked at RFC 5623 that describes some approaches to inter-layer networking using PCE. But it seems that perhaps you are more interested in the per-domain PCE mechanism (RFC 5152) and that you have observed that the OF that would be used in each domain to select the path is not currently available because it is missing from RSVP-TE. That seems to me to be a perfectly reasonable thing to add to RSVP-TE and I think it enables and supports the work of the PEC working group without any conflict, but I would hope that you share definitions of OFs with the PCE WG. And one last point, when you say > even if there is no PCE you misunderstand the PCE architecture. If you are computing a path (in an LSR) you are de facto providing PCE functionality. There is no need in the architecture (and thus the implementation) to expose an external (PCEP) interface in order to be logically providing PCE function, and this is *exactly* why you want access to the OF. However, you would perhaps do better to absorb this ambivalence and note that you need the OF and Metric whether or not the PCE is external. All of which you may take as general support for your idea, but a feeling that the I-D is not happily written and deviating too much from shared context with PCE. Cheers, Adrian From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of George Swallow (swallow) Sent: 11 September 2012 20:29 To: Julien Meuric Cc: ccamp@ietf.org Subject: [CCAMP] Objective function draft Julien - Reading the CCAMP notes (which capture little of the actual discussion) I see that there may have been a perception in the room that PCE functionality at the UNI-N was assumed (actual or proxy). This is not the case. The reason for our draft is that with the UNI, much of the functionality that resides at the headend is moved to the UNI-N. So the UNI-C needs a way to express an objective function even if there is no PCE. Operationally it seems burdensome to require a PCEP at the UNI-C and a PCEP at the UNI-N, when all that is being done is enabling the UNI-N to perform what the client would do if it were connected to the network via a normal link. Do you still object to the draft? Thanks, .George ------=_NextPart_000_03D8_01CD907F.078D9CE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<individual contributor = mode>

 

I'm hoping that you have = looked at RFC 5623 that describes some approaches to inter-layer = networking using PCE.

 

But it seems that perhaps you = are more interested in the per-domain PCE mechanism (RFC 5152) and that = you have observed that the OF that would be used in each domain to = select the path is not currently available because it is missing from = RSVP-TE. That seems to me to be a perfectly reasonable thing to add to = RSVP-TE and I think it enables and supports the work of the PEC working = group without any conflict, but I would hope that you share definitions = of OFs with the PCE WG.

 

And one last point, when you = say

 

> even if there is no = PCE

 

you misunderstand the PCE = architecture. If you are computing a path (in an LSR) you are de facto = providing PCE functionality. There is no need in the architecture (and = thus the implementation) to expose an external (PCEP) interface in order = to be logically providing PCE function, and this is *exactly* why you = want access to the OF.

 

However, you would perhaps do = better to absorb this ambivalence and note that you need the OF and = Metric whether or not the PCE is external.

 

All of which you may take as = general support for your idea, but a feeling that the I-D is not happily = written and deviating too much from shared context with = PCE.

 

Cheers,

Adrian

 

From: = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = George Swallow (swallow)
Sent: 11 September 2012 = 20:29
To: Julien Meuric
Cc: = ccamp@ietf.org
Subject: [CCAMP] Objective function = draft

 

Julien = -

 

Reading the CCAMP notes = (which capture little of the actual discussion) I see that there may = have been a perception in the room that PCE functionality at the UNI-N = was assumed (actual or proxy).

 

This is not the case. =  The reason for our draft is that with the UNI, much of the = functionality that resides at the headend is moved to the UNI-N. =  So the UNI-C needs a way to express an objective function even if = there is no PCE.  

 

Operationally it seems = burdensome to require a PCEP at the UNI-C and a PCEP at the UNI-N, when = all that is being done is enabling the UNI-N to perform what the client = would do if it were connected to the network via a normal = link.

 

Do you still object to the = draft?  

 

Thanks,

 

…George

= ------=_NextPart_000_03D8_01CD907F.078D9CE0-- From zhang.fei3@zte.com.cn Tue Sep 11 18:44:12 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 18E5621F8535 for ; Tue, 11 Sep 2012 18:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFpdyYJXQS07 for ; Tue, 11 Sep 2012 18:44:11 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A044D21F852E for ; Tue, 11 Sep 2012 18:44:10 -0700 (PDT) Received: from [192.168.168.119] by mx5.zte.com.cn with surfront esmtp id 10723473195744; Wed, 12 Sep 2012 09:25:20 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 5CB3E71F7CD; Wed, 12 Sep 2012 09:40:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q8C1hsud035897; Wed, 12 Sep 2012 09:43:55 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Rakesh Gandhi (rgandhi)" MIME-Version: 1.0 X-KeepSent: 9C039EEF:4C280C22-48257A77:0002A8A8; 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, 12 Sep 2012 09:43:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-12 09:43:50, Serialize complete at 2012-09-12 09:43:50 Content-Type: multipart/alternative; boundary="=_alternative 0009828C48257A77_=" X-MAIL: mse01.zte.com.cn q8C1hsud035897 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:44:12 -0000 This is a multipart message in MIME format. --=_alternative 0009828C48257A77_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUmFrZXNoDQoNCkFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb25zIGluIFJGQzM0NzMsIEkg YW0gYWZyYWlkIGJvdGggdGhlIHVwc3RyZWFtIA0Kbm90aWZpY2F0aW9uIGFuZCBkb3duc3RyZWFt IG5vdGlmaWNhdGlvbiBhcmUgcGVybWl0dGVkLg0KDQpTb21lIG90aGVyIGlzc3VlcyB0aGF0IG5l ZWQgdG8gYmUgZGlzY3Vzc2VkIGFyZSB0YWdnZWQgaW4gbGluZSB3aXRoIDxmZWk+IA0KDQpCZXN0 IHJlZ2FyZHMNCg0KRmVpDQoNCg0KDQoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2FuZGhp QGNpc2NvLmNvbT4gDQoyMDEyLTA5LTExIDIxOjIyDQoNCsrVvP7Iyw0KTG91IEJlcmdlciA8bGJl cmdlckBsYWJuLm5ldD4NCrOty80NCiJ6aGFuZy5mZWkzQHp0ZS5jb20uY24iIDx6aGFuZy5mZWkz QHp0ZS5jb20uY24+LCAiY2NhbXBAaWV0Zi5vcmciIA0KPGNjYW1wQGlldGYub3JnPg0K1vfM4g0K UkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRw LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCg0KDQoNCg0KDQpIaSBXRywNCg0K QW55IHRob3VnaHRzIG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWw/DQoNClRoYW5rcywNClJha2Vz aA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYWtlc2ggR2FuZGhpIChy Z2FuZGhpKSANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNDQpUbzog J0xvdSBCZXJnZXInDQpDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuOyBjY2FtcEBpZXRmLm9yZw0K U3ViamVjdDogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KZHJhZnQtaWV0Zi1jY2Ft cC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCg0KVGhhbmtzIExv dSBmb3IgeW91ciByZXBseS4NCg0KUkZDIDM0NzMgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJ RlkgcmVxdWVzdCBhbmQgcmVwbHkuIFdlIGNvdWxkIHVzZSANCnRoaXMgZm9yIHJldmVyc2UgTFNQ IHNpZ25hbGluZyBlcnJvciBub3RpZmljYXRpb24gdG8gdGhlIGluaXRpYXRpbmcgDQppbmdyZXNz IG5vZGUuDQoNCjxOb3RpZnkgbWVzc2FnZT4gOjo9IDxDb21tb24gSGVhZGVyPiBbPElOVEVHUklU WT5dIFsgWzxNRVNTQUdFX0lEX0FDSz4gfCANCjxNRVNTQUdFX0lEX05BQ0s+XSAuLi4gXQ0KPEVS Uk9SX1NQRUM+IA0KPG5vdGlmeSBzZXNzaW9uIGxpc3QgOjo9IDx1cHN0cmVhbSBzZXNzaW9uPiA8 ZG93bnN0cmVhbSBzZXNzaW9uPiAgPg0KDQpUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB3ZSBjYW4g dXNlIHRoZSBOT1RJRlkgbWVzc2FnZS4NCg0KTWV0aG9kIDEgLSBNaWQtcG9pbnQgYXdhcmUgd2l0 aCBQYXRoIG1lc3NhZ2UgcmVxdWVzdDoNCldoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQ YXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsIHRoZSANCm5vZGUgd2lsbCBpbnNl cnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNlIExTUCBwYXRoIG1lc3NhZ2Ugd2l0 aCANCm5vZGUgSUQgb2YgdGhlIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlLiBBIG1pZC1wb2ludCBu b2RlIHdpbGwgc2VuZCAgYSBjb3B5IA0Kb2YgdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5p dGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS4NCg0KPGZlaT5PaywgY2FuIHlv dSBjbGFyaWZ5IHdoaWNoIHNlc3Npb24gdGhlIGNvcGllZCBOT1RJRlkgbWVzc2FnZSBhcmUgDQpj YXJyeWluZz8gdGhlIGZvcndhcmQgc2Vzc2lvbjEgb3IgdGhlIHJldmVyc2Ugc2Vzc2lvbjI/DQog DQpJZiBpdCBpcyBzZXNzaW9uMSwgSSBhbSBhZnJhaWQgdGhhdCB0aGUgTk9USUZZX1JFUSBvYmpl Y3QgaXMgYWxzbyBuZWVkZWQgDQppbiB0aGUgZm9yd2FyZCBMU1AgUGF0aCBtZXNzYWdlICggIk5v dGUgdGhhdCBhIE5vdGlmeSBtZXNzYWdlIE1VU1QgTk9UIGJlIA0KZ2VuZXJhdGVkIHVubGVzcyBh biBhcHByb3ByaWF0ZSBOb3RpZnkgUmVxdWVzdCBvYmplY3QgaGFzIGJlZW4gcmVjZWl2ZWQuIiAN CmNvcGllZCBmcm9tIHBhcmFncmFwaCA0LjMuMiBmcm9tIFJGQzM0NzMgKQ0KIA0KIElmIGl0IGlz IHNlc3Npb24yLCB0aGVyZSBpcyBubyBjb3BpZWQgTk9USUZZIG1lc3NhZ2UuDQoNCklQdjQgTm90 aWZ5IFJlcXVlc3QgT2JqZWN0DQogICBJUHY0IE5vdGlmeSBOb2RlIEFkZHJlc3M6IDMyIGJpdHMN CiAgICAgIFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIHRoYXQgc2hvdWxkIGJlIG5vdGlmaWVk IHdoZW4gZ2VuZXJhdGluZyANCmFuIGVycm9yIG1lc3NhZ2UuDQoNCg0KTWV0aG9kIDIgLSBNaWQt cG9pbnQgYXdhcmUgd2l0aCBSZXN2IG1lc3NhZ2UgcmVxdWVzdDoNCldoZW4gYW4gaW5pdGlhdGlu ZyBpbmdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2UgZm9yIGEgcmV2ZXJzZSBMU1As IA0KdGhlIG5vZGUgd2lsbCBpbnNlcnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNl IExTUCBSZXN2IG1lc3NhZ2UgDQp3aXRoIGl0cyBvd24gbm9kZSBJRC4gQSBtaWQtcG9pbnQgbm9k ZSB3aWxsIHNlbmQgYSBjb3B5IG9mIHRoZSBzaWduYWxpbmcgDQplcnJvciB0byB0aGUgaW5pdGlh dGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS4NCg0KPGZlaT4gU2VlIGFib3ZlLCBp ZiBpdCBpcyBzZXNzaW9uMiwgbm8gY29waWVkIE5PVElGWSBtZXNzYWdlIGFsc28uDQoNCk1ldGhv ZCAzIC0gVGFpbC1lbmQgcmVsYXlpbmcgOg0KV2hlbiBhbiBlZ3Jlc3Mgbm9kZSByZWNlaXZlcyBh IFBhdGggbWVzc2FnZSB3aXRoIFJFVkVSU0VfTFNQIG9iamVjdCwgdGhlIA0Kbm9kZSB3aWxsIHJl bGF5IHRoZSByZWNlaXZlZCBzaWduYWxpbmcgZXJyb3IgbWVzc2FnZSBvbiB0aGUgcmV2ZXJzZSBM U1AgdG8gDQp0aGUgaW5pdGlhbGl6aW5nIGluZ3Jlc3Mgbm9kZS4gVGhlIGVncmVzcyBub2RlIGNv cGllcyB0aGUgcmVjZWl2ZWQgDQoiRVJST1JfU1BFQyIgb2JqZWN0IGludG8gYSBOT1RJRlkgW1JG QzM0NzMsIHNlY3Rpb24gNC4zXSBtZXNzYWdlIGFuZCANCnNpZ25hbHMgaXQgdG8gdGhlIGluZ3Jl c3Mgbm9kZS4gSW4gdGhpcyBjYXNlLCBOT1RJRllfUkVRIG1lc3NhZ2UgaXMgbm90IA0KcmVxdWly ZWQuIA0KDQo8ZmVpPiBJIGFtIGFmcmFpZCBOT1RJRllfUkVRIG9iamVjdCBpcyBhbHNvIHJlcXVp cmVkIGluIHRoZSBmb3J3YXJkIGFuZCANCnJldmVyc2UgTFNQJ3MgUGF0aCBvciBSZXN2IG1lc3Nh Z2UsIG90aGVyd2lzZSAsdGhlIGVncmVzcyBub2RlIHdpbGwgbm90IA0KcmVhbHkgdGhlIGVycm9y IG1lc3NhZ2UuDQoNClBsZWFzZSBhZHZpc2UgeW91ciB0aG91Z2h0cy4NCg0KVGhhbmtzLA0KUmFr ZXNoDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBb bWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA0LCAy MDEyIDExOjM1IEFNDQpUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCkNjOiB6aGFuZy5mZWkz QHp0ZS5jb20uY247IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQ IGNvbnRyb2wgaW4gDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh dGVkLWxzcC0wNC50eHQNCg0KQXMgSSByZWFkIHRoZSBjdXJyZW50IHJldiwgbm8gc3VjaCBub3Rp ZmljYXRpb24gbWVjaGFuaXNtIGlzIHNwZWNpZmllZC4NCiBMb29rcyBsaWtlIHlvdSBnZXQgdG8g cHJvcG9zZSBvbmUhDQoNCkxvdSAoYXMgV0cgcGFydGljaXBhbnQpLg0KDQpPbiA4LzMxLzIwMTIg OTo0OSBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+IEhpIExvdSwgRmVpLA0K PiANCj4gV2hlbiBhbiAob3JpZ2luYXRpbmcpIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3 aXRoICI1IChUQkQpICBTaW5nbGUgDQpTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQ cyAgKEEpIiBhbmQgd2lzaGVzIHRvIGNvbnRyb2wgYm90aCANCmZvcndhcmQgYW5kIHJldmVyc2Ug IExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIgb2JqZWN0LCBJIHdvdWxkIHRoaW5rIA0KdGhh dCB0aGUgaW5ncmVzcyBub2RlIG5lZWRzIHRvIGtub3cgYWJvdXQgdGhlIHNpZ25hbGluZyAocGF0 aCkgZXJyb3JzIA0KKHN1Y2ggYXMgc29mdCBwcmVlbXB0aW9uIG9yIGFkbWlzc2lvbiBmYWlsdXJl KSBvbiB0aGUgcmV2ZXJzZSBMU1AuICBJcyANCnRoZXJlIGFueSB0ZXh0IHNvbWV3aGVyZSBpbiBh biBSRkMvZHJhZnQgdGhhdCBkZXNjcmliZXMgaG93IGEgbWlkLXBvaW50IA0Kbm9kZSBjYW4gc2Vu ZCB0aGUgc2lnbmFsaW5nIChwYXRoKSBlcnJvciB0byB0aGUgb3JpZ2luYXRpbmcgaW5ncmVzcyBu b2RlIA0KZm9yIHRoZSByZXZlcnNlIExTUD8gSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2Ug UlNWUF9OT1RJRlkgbWVzc2FnZT8gDQpTb3JyeSBpZiBJIGhhZCBtaXNzZWQgYW55IHByZXZpb3Vz IGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NCj4gDQo+IFRoYW5rcywNCj4gUmFrZXNoDQo+IA0K PiANCj4gDQo+IA0KPiANCg0KDQoNCg== --=_alternative 0009828C48257A77_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJha2VzaDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPkFjY29yZGluZyB0byB0aGUgZGVzY3Jp cHRpb25zIGluIFJGQzM0NzMsDQpJIGFtIGFmcmFpZCBib3RoIHRoZSB1cHN0cmVhbSBub3RpZmlj YXRpb24gYW5kIGRvd25zdHJlYW0gbm90aWZpY2F0aW9uDQphcmUgcGVybWl0dGVkLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlNvbWUgb3RoZXIgaXNzdWVzIHRo YXQgbmVlZCB0byBiZSBkaXNjdXNzZWQNCmFyZSB0YWdnZWQgaW4gbGluZSB3aXRoICZsdDtmZWkm Z3Q7IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPkJlc3QgcmVn YXJkczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPkZlaTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtS YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90Ow0KJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0Ozwv Yj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDktMTEg MjE6MjI8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O3poYW5nLmZlaTNAenRlLmNvbS5jbiZxdW90OyAmbHQ7emhhbmcuZmVpM0B6dGUu Y29tLmNuJmd0OywNCiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBpZXRmLm9y ZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBk cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkhpIFdHLDxicj4NCjxicj4NCkFueSB0aG91Z2h0cyBvbiB0aGUgZm9sbG93aW5nIHByb3Bvc2Fs Pzxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSYWtlc2g8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIDxi cj4NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNPGJyPg0KVG86ICdM b3UgQmVyZ2VyJzxicj4NCkNjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IGNjYW1wQGlldGYub3Jn PGJyPg0KU3ViamVjdDogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIGRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCjxicj4N Cjxicj4NClRoYW5rcyBMb3UgZm9yIHlvdXIgcmVwbHkuPGJyPg0KPGJyPg0KUkZDIDM0NzMgZGVm aW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJRlkgcmVxdWVzdCBhbmQgcmVwbHkuIFdlIGNvdWxkIHVz ZQ0KdGhpcyBmb3IgcmV2ZXJzZSBMU1Agc2lnbmFsaW5nIGVycm9yIG5vdGlmaWNhdGlvbiB0byB0 aGUgaW5pdGlhdGluZyBpbmdyZXNzDQpub2RlLjxicj4NCjxicj4NCiZsdDtOb3RpZnkgbWVzc2Fn ZSZndDsgOjo9ICZsdDtDb21tb24gSGVhZGVyJmd0OyBbJmx0O0lOVEVHUklUWSZndDtdIFsNClsm bHQ7TUVTU0FHRV9JRF9BQ0smZ3Q7IHwgJmx0O01FU1NBR0VfSURfTkFDSyZndDtdIC4uLiBdPGJy Pg0KJmx0O0VSUk9SX1NQRUMmZ3Q7ICZuYnNwOyA8YnI+DQombHQ7bm90aWZ5IHNlc3Npb24gbGlz dCA6Oj0gJmx0O3Vwc3RyZWFtIHNlc3Npb24mZ3Q7ICZsdDtkb3duc3RyZWFtIHNlc3Npb24mZ3Q7 DQombmJzcDsmZ3Q7PGJyPg0KPGJyPg0KVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgd2UgY2FuIHVz ZSB0aGUgTk9USUZZIG1lc3NhZ2UuPGJyPg0KPGJyPg0KTWV0aG9kIDEgLSBNaWQtcG9pbnQgYXdh cmUgd2l0aCBQYXRoIG1lc3NhZ2UgcmVxdWVzdDo8YnI+DQpXaGVuIGFuIGVncmVzcyBub2RlIHJl Y2VpdmVzIGEgUGF0aCBtZXNzYWdlIHdpdGggUkVWRVJTRV9MU1Agb2JqZWN0LCB0aGUNCm5vZGUg d2lsbCBpbnNlcnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNlIExTUCBwYXRoIG1l c3NhZ2Ugd2l0aA0Kbm9kZSBJRCBvZiB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUuIEEgbWlk LXBvaW50IG5vZGUgd2lsbCBzZW5kICZuYnNwO2ENCmNvcHkgb2YgdGhlIHNpZ25hbGluZyBlcnJv ciB0byB0aGUgaW5pdGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS48YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jmx0O2ZlaSZndDtP aywgY2FuIHlvdSBjbGFyaWZ5IHdoaWNoIHNlc3Npb24NCnRoZSBjb3BpZWQgTk9USUZZIG1lc3Nh Z2UgYXJlIGNhcnJ5aW5nPyB0aGUgZm9yd2FyZCBzZXNzaW9uMSBvciB0aGUgcmV2ZXJzZQ0Kc2Vz c2lvbjI/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPiZuYnNw OyAmbmJzcDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1i bHVlPklmIGl0IGlzIHNlc3Npb24xLCBJIGFtIGFmcmFpZCB0aGF0IHRoZQ0KTk9USUZZX1JFUSBv YmplY3QgaXMgYWxzbyBuZWVkZWQgaW4gdGhlIGZvcndhcmQgTFNQIFBhdGggbWVzc2FnZSAoICZx dW90O05vdGUNCnRoYXQgYSBOb3RpZnkgbWVzc2FnZSBNVVNUIE5PVCBiZSBnZW5lcmF0ZWQgdW5s ZXNzIGFuIGFwcHJvcHJpYXRlIE5vdGlmeQ0KUmVxdWVzdCBvYmplY3QgaGFzIGJlZW4gcmVjZWl2 ZWQuJnF1b3Q7IGNvcGllZCBmcm9tIHBhcmFncmFwaCA0LjMuMiBmcm9tDQpSRkMzNDczICk8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jm5ic3A7ICZuYnNwOyA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+Jm5ic3A7SWYgaXQg aXMgc2Vzc2lvbjIsIHRoZXJlIGlzIG5vIGNvcGllZA0KTk9USUZZIG1lc3NhZ2UuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpJUHY0IE5vdGlmeSBSZXF1ZXN0IE9iamVj dDxicj4NCiAmbmJzcDsgSVB2NCBOb3RpZnkgTm9kZSBBZGRyZXNzOiAzMiBiaXRzPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7VGhlIElQIGFkZHJlc3Mgb2YgdGhlIG5vZGUgdGhhdCBzaG91bGQg YmUgbm90aWZpZWQNCndoZW4gZ2VuZXJhdGluZyBhbiBlcnJvciBtZXNzYWdlLjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KTWV0aG9kIDIgLSBNaWQtcG9pbnQg YXdhcmUgd2l0aCBSZXN2IG1lc3NhZ2UgcmVxdWVzdDo8YnI+DQpXaGVuIGFuIGluaXRpYXRpbmcg aW5ncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIGZvciBhIHJldmVyc2UgTFNQLA0K dGhlIG5vZGUgd2lsbCBpbnNlcnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNlIExT UCBSZXN2IG1lc3NhZ2UNCndpdGggaXRzIG93biBub2RlIElELiBBIG1pZC1wb2ludCBub2RlIHdp bGwgc2VuZCBhIGNvcHkgb2YgdGhlIHNpZ25hbGluZw0KZXJyb3IgdG8gdGhlIGluaXRpYXRpbmcg bm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPiZsdDtmZWkmZ3Q7IFNlZSBhYm92ZSwgaWYgaXQgaXMg c2Vzc2lvbjIsDQpubyBjb3BpZWQgTk9USUZZIG1lc3NhZ2UgYWxzby48L2ZvbnQ+PC90dD48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCjxicj4NCk1ldGhvZCAzIC0gVGFpbC1lbmQgcmVsYXlpbmcgOjxi cj4NCldoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZF UlNFX0xTUCBvYmplY3QsIHRoZQ0Kbm9kZSB3aWxsIHJlbGF5IHRoZSByZWNlaXZlZCBzaWduYWxp bmcgZXJyb3IgbWVzc2FnZSBvbiB0aGUgcmV2ZXJzZSBMU1ANCnRvIHRoZSBpbml0aWFsaXppbmcg aW5ncmVzcyBub2RlLiBUaGUgZWdyZXNzIG5vZGUgY29waWVzIHRoZSByZWNlaXZlZCAmcXVvdDtF UlJPUl9TUEVDJnF1b3Q7DQpvYmplY3QgaW50byBhIE5PVElGWSBbUkZDMzQ3Mywgc2VjdGlvbiA0 LjNdIG1lc3NhZ2UgYW5kIHNpZ25hbHMgaXQgdG8gdGhlDQppbmdyZXNzIG5vZGUuIEluIHRoaXMg Y2FzZSwgTk9USUZZX1JFUSBtZXNzYWdlIGlzIG5vdCByZXF1aXJlZC4gPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7ZmVpPC9mb250PjwvdHQ+PHR0Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlPiZndDsNCkkgYW0gYWZyYWlkIE5PVElGWV9SRVEgb2JqZWN0IGlzIGFs c28gcmVxdWlyZWQgaW4gdGhlIGZvcndhcmQgYW5kIHJldmVyc2UNCkxTUCdzIFBhdGggb3IgUmVz diBtZXNzYWdlLCBvdGhlcndpc2UgLHRoZSBlZ3Jlc3Mgbm9kZSB3aWxsIG5vdCByZWFseSB0aGUN CmVycm9yIG1lc3NhZ2UuPC9mb250PjwvdHQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpQ bGVhc2UgYWR2aXNlIHlvdXIgdGhvdWdodHMuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClJha2Vz aDxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K RnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIDxicj4NClNlbnQ6IFR1 ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMTozNSBBTTxicj4NClRvOiBSYWtlc2ggR2FuZGhp IChyZ2FuZGhpKTxicj4NCkNjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IGNjYW1wQGlldGYub3Jn PGJyPg0KU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIGRyYWZ0LWlldGYt Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCjxicj4N CkFzIEkgcmVhZCB0aGUgY3VycmVudCByZXYsIG5vIHN1Y2ggbm90aWZpY2F0aW9uIG1lY2hhbmlz bSBpcyBzcGVjaWZpZWQuPGJyPg0KIExvb2tzIGxpa2UgeW91IGdldCB0byBwcm9wb3NlIG9uZSE8 YnI+DQo8YnI+DQpMb3UgKGFzIFdHIHBhcnRpY2lwYW50KS48YnI+DQo8YnI+DQpPbiA4LzMxLzIw MTIgOTo0OSBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6PGJyPg0KJmd0OyBIaSBM b3UsIEZlaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hlbiBhbiAob3JpZ2luYXRpbmcpIGluZ3Jl c3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICZxdW90OzUgKFRCRCkNCiZuYnNwO1NpbmdsZSBT aWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyAmbmJzcDsoQSkmcXVvdDsgYW5kIHdp c2hlcw0KdG8gY29udHJvbCBib3RoIGZvcndhcmQgYW5kIHJldmVyc2UgJm5ic3A7TFNQcyBieSBh ZGRpbmcgJnF1b3Q7UkVWRVJTRV9MU1AmcXVvdDsNCm9iamVjdCwgSSB3b3VsZCB0aGluayB0aGF0 IHRoZSBpbmdyZXNzIG5vZGUgbmVlZHMgdG8ga25vdyBhYm91dCB0aGUgc2lnbmFsaW5nDQoocGF0 aCkgZXJyb3JzIChzdWNoIGFzIHNvZnQgcHJlZW1wdGlvbiBvciBhZG1pc3Npb24gZmFpbHVyZSkg b24gdGhlIHJldmVyc2UNCkxTUC4gJm5ic3A7SXMgdGhlcmUgYW55IHRleHQgc29tZXdoZXJlIGlu IGFuIFJGQy9kcmFmdCB0aGF0IGRlc2NyaWJlcyBob3cNCmEgbWlkLXBvaW50IG5vZGUgY2FuIHNl bmQgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nDQppbmdyZXNz IG5vZGUgZm9yIHRoZSByZXZlcnNlIExTUD8gSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2Ug UlNWUF9OT1RJRlkNCm1lc3NhZ2U/IFNvcnJ5IGlmIEkgaGFkIG1pc3NlZCBhbnkgcHJldmlvdXMg ZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MsPGJy Pg0KJmd0OyBSYWtlc2g8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 0009828C48257A77_=-- From giomarti@cisco.com Wed Sep 12 00:31: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 49F2C21F856D for ; Wed, 12 Sep 2012 00:31:01 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNtVU85iVUQV for ; Wed, 12 Sep 2012 00:31:00 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6121F8582 for ; Wed, 12 Sep 2012 00:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8311; q=dns/txt; s=iport; t=1347435060; x=1348644660; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PtEq0+Mwuo/+4zbwsEZmB3SEHJ/V5EXgM/hZc1SdFQM=; b=if6QO0bHnAnLxKvqQeAqYFvkt+MJUUKRA8YnsggNUFXAPs659oIbggaR nbvjpEX9CAd+hhL12fusMGDe/Sl5U+bfJnstmJKlc5v2exD48i3Qp6Csh wTro7Rv8pWFd0fv1nW4Ye25L8C7IFA0GFfA/t7Z6j29h33sqAB+2SYBq1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPU4UFCtJV2b/2dsb2JhbABCA7tVgQeCIAEBAQMBAQEBDwFUBwsFCwIBCBguJwslAgQOBQkZh2UGC5tbjA+UM4sQGoMEgkRgA4ggjT+BFI0igWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208";a="120471786" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 12 Sep 2012 07:30:59 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8C7UxXD001985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 07:30:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 02:30:58 -0500 From: "Giovanni Martinelli (giomarti)" To: Greg Bernstein Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt Thread-Index: AQHNitezjDYoXHthsUGj7mjNperrOZd68okAgAE65YCAAAQwAIAH+KsAgAHKIwCAALrPgA== Date: Wed, 12 Sep 2012 07:30:57 +0000 Message-ID: <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> <504F9D7C.2040302@grotto-networking.com> In-Reply-To: <504F9D7C.2040302@grotto-networking.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.166.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.004 x-tm-as-result: No--76.385700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7D198A73C83E5948AA7F1ABB5E047EAA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 07:31:01 -0000 Hi Greg, I know looks like a little bouncing but was just wondering if there's a par= titioning that at the end will simplify even current wson-encode draft mana= gement (so the path to last call).=20 Anyway I'm fine with any wg chairs decision cheers G On Sep 11, 2012, at 22:22 , Greg Bernstein wrote: > Hi Giovanni we updated the WSON encode draft back on September 5th to put= the interface class encoding into the draft. This was in response to the q= uestion raised by Lou in a August 20th email. Lou, Deborah and OIC draft a= uthors do we need to change this back? > Please let us know ASAP as we are trying to get all the WSON drafts into = last call and this seems to be the last outstanding issue. >=20 > Best Regards > Greg > On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: >> Hi Greg, Lou, >>=20 >> having a quick look to wson draft update I generally agree on content (a= s expected) what I'm wandering if it worth moving the interface class encod= ing within the draft-ieft-ccamp-rwa-wson-encode. >>=20 >> Here an alternate proposal on the table: >> leave the generic OIC container definition within current wson-encode dr= aft and put specific OIC encoding (with related ITU references) in a separa= te draft (which could be a new version of draft-martinelli-wson-interface-c= lass or a brand new draft). This separation will probably allow finalizing = the wson-info-model and wson-encoding separately from specific OIC content = (so we'll collect most updated ITU references as already mentioned we still= miss few of them. >>=20 >>=20 >> I guess is for WG chairs to decide. >>=20 >> If we stay with current doc splitting I'll go for a detailed review on l= atest updates. Sorry for raising it with a bit of delay but, just want to m= ake sure was an option consciously avoided. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >> On Sep 5, 2012, at 17:18 , Lou Berger wrote: >>=20 >>> Greg, >>> Okay. Based on the meeting/discussions and the draft, I had expected >>> there was sufficient consensus & text to work from. As editors, you're >>> free to document your perspective on consensus as works best for you. >>> Let us (chairs) know if you need assistance and we'll figure out how to >>> help. >>>=20 >>> Lou >>>=20 >>> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>>> Hi Lou, I'll look at that text. I added to our document what the QIC >>>> authors suggested. Maybe they were planning something else? >>>> Greg >>>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>>> Greg, >>>>> Why not start with the concrete proposal that's already on the table= , >>>>> i.e., the text in >>>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >>>>> Frankly, I'm not sure why that text wasn't incorporated in the first >>>>> place and figured I missed something -- which is why I sent my earlie= r mail. >>>>>=20 >>>>> Lou >>>>>=20 >>>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>>>>> weeks. One simple way out of this would be to just use a variable >>>>>> length field for the OIC using the ITU-T application string rather t= han >>>>>> a fixed 64 bit field. >>>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>>> otherwise) in the future we can make sure to have a place holder. >>>>>> However, currently the ITU-T only defines application strings for th= is >>>>>> purpose. >>>>>>=20 >>>>>> If I don't hear any other suggestions in two weeks, I'll make the ch= ange >>>>>> to incorporate variable length strings and keep place holders for >>>>>> defining fixed length fields. Then we can move this and related WSO= N >>>>>> documents into last call. >>>>>>=20 >>>>>> Best Regards >>>>>> Greg B. >>>>>>=20 >>>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>>> Optical Interface Class draft authors can you respond to Lou/List. >>>>>>> Let me know if we need to update the text. We are trying to get th= is >>>>>>> into last call. >>>>>>> Best Regards >>>>>>> Greg >>>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>>> Authors, >>>>>>>>=20 >>>>>>>> I see that the draft says: >>>>>>>> In case of ITU Application Code, there should be a mapping b= etween >>>>>>>> the string defining the application code and the 64 bits num= ber >>>>>>>> implementing the optical interface class. >>>>>>>>=20 >>>>>>>> Where is this mapping defined? Doesn't it have to be either in th= is >>>>>>>> draft or a normative reference? >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>>=20 >>>>>>>> On 8/16/2012 7:14 PM, internet-drafts@ietf.org wrote: >>>>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s >>>>>>>>> directories. >>>>>>>>> This draft is a work item of the Common Control and Measurement >>>>>>>>> Plane Working Group of the IETF. >>>>>>>>>=20 >>>>>>>>> Title : Routing and Wavelength Assignment Informati= on >>>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>>> Young Lee >>>>>>>>> Dan Li >>>>>>>>> Wataru Imajuku >>>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>>> Pages : 33 >>>>>>>>> Date : 2012-08-16 >>>>>>>>>=20 >>>>>>>>> Abstract: >>>>>>>>> A wavelength switched optical network (WSON) requires that ce= rtain >>>>>>>>> key information elements are made available to facilitate pat= h >>>>>>>>> computation and the establishment of label switching paths (L= SPs). >>>>>>>>> The information model described in "Routing and Wavelength >>>>>>>>> Assignment Information for Wavelength Switched Optical Networ= ks" >>>>>>>>> shows what information is required at specific points in the = WSON. >>>>>>>>> Part of the WSON information model contains aspects that may = be of >>>>>>>>> general applicability to other technologies, while other part= s are >>>>>>>>> fairly specific to WSONs. >>>>>>>>>=20 >>>>>>>>> This document provides efficient, protocol-agnostic encodings= for >>>>>>>>> the WSON specific information elements. It is intended that >>>>>>>>> protocol-specific documents will reference this memo to descr= ibe >>>>>>>>> how >>>>>>>>> information is carried for specific uses. Such encodings can = be >>>>>>>>> used >>>>>>>>> to extend GMPLS signaling and routing protocols. In addition = these >>>>>>>>> encodings could be used by other mechanisms to convey this sa= me >>>>>>>>> information to a path computation element (PCE). >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>>>>>=20 >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>=20 >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-enco= de-16 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>=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 >>>>>>>>=20 >>>>=20 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>=20 >>=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 >=20 From lberger@labn.net Wed Sep 12 06:08: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 C007D21F8508 for ; Wed, 12 Sep 2012 06:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.066 X-Spam-Level: X-Spam-Status: No, score=-100.066 tagged_above=-999 required=5 tests=[AWL=0.095, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkEkRQe9B2yX for ; Wed, 12 Sep 2012 06:08:01 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id CB25321F84FD for ; Wed, 12 Sep 2012 06:08:01 -0700 (PDT) Received: (qmail 22189 invoked by uid 0); 12 Sep 2012 13:08:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 12 Sep 2012 13:08:01 -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=dptv6smpoToYEnkpVim6JBV25oHyOyKn7ExIjp7D3Qo=; b=VjPW5fq+E44xfOGhx9GJ8aSBN9PKuI0d+HSUCdzGV5sOuH50XureeGUjiQ1hla5KZIZtqWH7DlH6FMYMzg5JFdXfpztZfeO+D77SU6gmmt8d7KRlUpnX9LAd9Clu/+f4; Received: from box313.bluehost.com ([69.89.31.113]:34665 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TBmfg-0008IN-Tl; Wed, 12 Sep 2012 07:08:01 -0600 Message-ID: <5050892D.4030709@labn.net> Date: Wed, 12 Sep 2012 09:07:57 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> <504F9D7C.2040302@grotto-networking.com> <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> In-Reply-To: <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> X-Enigmail-Version: 1.4.4 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: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:08:02 -0000 Giovanni, From the process standpoint, splitting the drafts as you suggest would make the new draft a normative reference (in the current draft) which would result in the current draft's publication being blocked until the new draft is also ready for publication. Given that the new draft doesn't exist and would need to start at the beginning of the WG process, I'm not sure there's much positive value in the proposed split from the process standpoint. That said, if there was a good technical reason for the split, we should discuss it. Was there any technical rationale for your proposal or was it purely motivated by process? If the former, can you elaborate? Lou On 9/12/2012 3:30 AM, Giovanni Martinelli (giomarti) wrote: > Hi Greg, > > I know looks like a little bouncing but was just wondering if there's a partitioning that at the end will simplify even current wson-encode draft management (so the path to last call). > > Anyway I'm fine with any wg chairs decision > > cheers > G > > > > On Sep 11, 2012, at 22:22 , Greg Bernstein wrote: > >> Hi Giovanni we updated the WSON encode draft back on September 5th to put the interface class encoding into the draft. This was in response to the question raised by Lou in a August 20th email. Lou, Deborah and OIC draft authors do we need to change this back? >> Please let us know ASAP as we are trying to get all the WSON drafts into last call and this seems to be the last outstanding issue. >> >> Best Regards >> Greg >> On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: >>> Hi Greg, Lou, >>> >>> having a quick look to wson draft update I generally agree on content (as expected) what I'm wandering if it worth moving the interface class encoding within the draft-ieft-ccamp-rwa-wson-encode. >>> >>> Here an alternate proposal on the table: >>> leave the generic OIC container definition within current wson-encode draft and put specific OIC encoding (with related ITU references) in a separate draft (which could be a new version of draft-martinelli-wson-interface-class or a brand new draft). This separation will probably allow finalizing the wson-info-model and wson-encoding separately from specific OIC content (so we'll collect most updated ITU references as already mentioned we still miss few of them. >>> >>> >>> I guess is for WG chairs to decide. >>> >>> If we stay with current doc splitting I'll go for a detailed review on latest updates. Sorry for raising it with a bit of delay but, just want to make sure was an option consciously avoided. >>> >>> Cheers >>> G >>> >>> >>> >>> On Sep 5, 2012, at 17:18 , Lou Berger wrote: >>> >>>> Greg, >>>> Okay. Based on the meeting/discussions and the draft, I had expected >>>> there was sufficient consensus & text to work from. As editors, you're >>>> free to document your perspective on consensus as works best for you. >>>> Let us (chairs) know if you need assistance and we'll figure out how to >>>> help. >>>> >>>> Lou >>>> >>>> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>>>> Hi Lou, I'll look at that text. I added to our document what the QIC >>>>> authors suggested. Maybe they were planning something else? >>>>> Greg >>>>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>>>> Greg, >>>>>> Why not start with the concrete proposal that's already on the table, >>>>>> i.e., the text in >>>>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >>>>>> Frankly, I'm not sure why that text wasn't incorporated in the first >>>>>> place and figured I missed something -- which is why I sent my earlier mail. >>>>>> >>>>>> Lou >>>>>> >>>>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>>>>>> weeks. One simple way out of this would be to just use a variable >>>>>>> length field for the OIC using the ITU-T application string rather than >>>>>>> a fixed 64 bit field. >>>>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>>>> otherwise) in the future we can make sure to have a place holder. >>>>>>> However, currently the ITU-T only defines application strings for this >>>>>>> purpose. >>>>>>> >>>>>>> If I don't hear any other suggestions in two weeks, I'll make the change >>>>>>> to incorporate variable length strings and keep place holders for >>>>>>> defining fixed length fields. Then we can move this and related WSON >>>>>>> documents into last call. >>>>>>> >>>>>>> Best Regards >>>>>>> Greg B. >>>>>>> >>>>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>>>> Optical Interface Class draft authors can you respond to Lou/List. >>>>>>>> Let me know if we need to update the text. We are trying to get this >>>>>>>> into last call. >>>>>>>> Best Regards >>>>>>>> Greg >>>>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>>>> Authors, >>>>>>>>> >>>>>>>>> I see that the draft says: >>>>>>>>> In case of ITU Application Code, there should be a mapping between >>>>>>>>> the string defining the application code and the 64 bits number >>>>>>>>> implementing the optical interface class. >>>>>>>>> >>>>>>>>> Where is this mapping defined? Doesn't it have to be either in this >>>>>>>>> draft or a normative reference? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lou >>>>>>>>> >>>>>>>>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>>>> Young Lee >>>>>>>>>> Dan Li >>>>>>>>>> Wataru Imajuku >>>>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>>>> Pages : 33 >>>>>>>>>> Date : 2012-08-16 >>>>>>>>>> >>>>>>>>>> Abstract: >>>>>>>>>> A wavelength switched optical network (WSON) requires that certain >>>>>>>>>> key information elements are made available to facilitate path >>>>>>>>>> computation and the establishment of label switching paths (LSPs). >>>>>>>>>> The information model described in "Routing and Wavelength >>>>>>>>>> Assignment Information for Wavelength Switched Optical Networks" >>>>>>>>>> shows what information is required at specific points in the WSON. >>>>>>>>>> Part of the WSON information model contains aspects that may be of >>>>>>>>>> general applicability to other technologies, while other parts are >>>>>>>>>> fairly specific to WSONs. >>>>>>>>>> >>>>>>>>>> This document provides efficient, protocol-agnostic encodings for >>>>>>>>>> the WSON specific information elements. It is intended that >>>>>>>>>> protocol-specific documents will reference this memo to describe >>>>>>>>>> how >>>>>>>>>> information is carried for specific uses. Such encodings can be >>>>>>>>>> used >>>>>>>>>> to extend GMPLS signaling and routing protocols. In addition these >>>>>>>>>> encodings could be used by other mechanisms to convey this same >>>>>>>>>> information to a path computation element (PCE). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>>>>>> >>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>> >>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>> >>> >> >> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> > > > > > From lberger@labn.net Wed Sep 12 06:14: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 3C96621F858F for ; Wed, 12 Sep 2012 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.072 X-Spam-Level: X-Spam-Status: No, score=-100.072 tagged_above=-999 required=5 tests=[AWL=0.089, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcMZljl6Sdcq for ; Wed, 12 Sep 2012 06:14:55 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 86D0B21F8582 for ; Wed, 12 Sep 2012 06:14:55 -0700 (PDT) Received: (qmail 4721 invoked by uid 0); 12 Sep 2012 13:14:53 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 12 Sep 2012 13:14: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=3Wvto74nY20ZOJ2VwjGzVBYbWZeY+2rb4NV4WD9tFbU=; b=z1EmKyQFLeFCTFAFsQ7azaF+ntRnF3JauZHn4AZW2Dpqhbm/Kuem6dj+H7tJTRDx0khfZc/B5p4n4wK8/3Ftp5peFFT1UGsA4ACShoXMTFhQMoSykfTJ+GGpQUREec5V; Received: from box313.bluehost.com ([69.89.31.113]:35394 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TBmmK-0002TI-VF; Wed, 12 Sep 2012 07:14:53 -0600 Message-ID: <50508AC9.5000709@labn.net> Date: Wed, 12 Sep 2012 09:14:49 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Rakesh Gandhi (rgandhi)" References: <50461FB2.7080707@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:14:56 -0000 Rakesh, Speaking as WG participant, I haven't thought about this too much so may be off, but method 3 seems to be most consistent with the usage of the REVERSE_LSP Object in the path message. Perhaps consider using the REVERSE_LSP Object in the upstream/Resv direction to allow the egress/tail to provide the ingress/head with arbitrary information.... Lou On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote: > Hi WG, > > Any thoughts on the following proposal? > > Thanks, > Rakesh > > > -----Original Message----- > From: Rakesh Gandhi (rgandhi) > Sent: Tuesday, September 04, 2012 1:36 PM > To: 'Lou Berger' > Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org > Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > > Thanks Lou for your reply. > > RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node. > > ::= [] [ [ | ] ... ] > > > > > There are multiple ways we can use the NOTIFY message. > > Method 1 - Mid-point aware with Path message request: > When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message. > > IPv4 Notify Request Object > IPv4 Notify Node Address: 32 bits > The IP address of the node that should be notified when generating an error message. > > Method 2 - Mid-point aware with Resv message request: > When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message. > > Method 3 - Tail-end relaying : > When an egress node receives a Path message with REVERSE_LSP object, the node will relay the received signaling error message on the reverse LSP to the initializing ingress node. The egress node copies the received "ERROR_SPEC" object into a NOTIFY [RFC3473, section 4.3] message and signals it to the ingress node. In this case, NOTIFY_REQ message is not required. > > Please advise your thoughts. > > Thanks, > Rakesh > > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, September 04, 2012 11:35 AM > To: Rakesh Gandhi (rgandhi) > Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org > Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt > > As I read the current rev, no such notification mechanism is specified. > Looks like you get to propose one! > > Lou (as WG participant). > > On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote: >> Hi Lou, Fei, >> >> When an (originating) ingress node is provisioned with "5 (TBD) Single Sided Associated Bidirectional LSPs (A)" and wishes to control both forward and reverse LSPs by adding "REVERSE_LSP" object, I would think that the ingress node needs to know about the signaling (path) errors (such as soft preemption or admission failure) on the reverse LSP. Is there any text somewhere in an RFC/draft that describes how a mid-point node can send the signaling (path) error to the originating ingress node for the reverse LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any previous discussion on this topic. >> >> Thanks, >> Rakesh >> >> >> >> >> > > > > From swallow@cisco.com Wed Sep 12 06:34: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 C642E21F8564 for ; Wed, 12 Sep 2012 06:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3FJQL8BZ7gO for ; Wed, 12 Sep 2012 06:34:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE721F853F for ; Wed, 12 Sep 2012 06:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34702; q=dns/txt; s=iport; t=1347456887; x=1348666487; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=hYdarQFbpDj8RvuFEY7DMX7XJWlXEodjBUQcdJFxjBs=; b=OcyWzC/0eI/2kghsTPGDGZAHw1BwopNud2Vj9QCHGhwLu2zuiQD6Kuc2 3QGNcSjU580FPYhYgx1Uj7AAT3KQJ/nWj0jnpLdr4y2Ef031ilQNDWnpN FffVv6f70+V9yGEpRGDz2Sq+84p4hBAxbgOeIgk4WzAqEnu/3oV0FX8qB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOOOUFCtJV2b/2dsb2JhbABFgku4dYEHgiABAQEDARIBGkwFDQEIEQECAQEBIQEGLQwUAwYIAgQBDQQBIoVvgXYGnC+gQ4sQhkIDlV+ONoFpgmaBYzQ X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208,217";a="120794582" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2012 13:34:47 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8CDYkdU029316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 13:34:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 08:34:46 -0500 From: "George Swallow (swallow)" To: "adrian@olddog.co.uk" , "'Julien Meuric'" Thread-Topic: [CCAMP] Objective function draft Thread-Index: AQHNkFOv4OOKfbxolEe2spFvFX1LfJeGIG+AgACmagA= Date: Wed, 12 Sep 2012 13:34:45 +0000 Message-ID: In-Reply-To: <03d701cd9076$a5bfbf00$f13f3d00$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.131.2.24] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--28.738400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC7605A78107swallowciscocom_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Objective function draft 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, 12 Sep 2012 13:34:48 -0000 --_000_CC7605A78107swallowciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Adrian - I think we are quite in agreement! The only difference is that I was using= PCE in a narrower sense of an entity that also runs PCEP. But reading th= e PCE architecture document, I see that you are correct. =85George From: Adrian Farrel > Reply-To: Adrian Farrel > Date: Tuesday, September 11, 2012 7:39 PM To: Cisco Employee >, Julien Me= uric > Cc: "ccamp@ietf.org" > Subject: RE: [CCAMP] Objective function draft I'm hoping that you have looked at RFC 5623 that describes some approaches = to inter-layer networking using PCE. But it seems that perhaps you are more interested in the per-domain PCE mec= hanism (RFC 5152) and that you have observed that the OF that would be used= in each domain to select the path is not currently available because it is= missing from RSVP-TE. That seems to me to be a perfectly reasonable thing = to add to RSVP-TE and I think it enables and supports the work of the PEC w= orking group without any conflict, but I would hope that you share definiti= ons of OFs with the PCE WG. And one last point, when you say > even if there is no PCE you misunderstand the PCE architecture. If you are computing a path (in an = LSR) you are de facto providing PCE functionality. There is no need in the = architecture (and thus the implementation) to expose an external (PCEP) int= erface in order to be logically providing PCE function, and this is *exactl= y* why you want access to the OF. However, you would perhaps do better to absorb this ambivalence and note th= at you need the OF and Metric whether or not the PCE is external. All of which you may take as general support for your idea, but a feeling t= hat the I-D is not happily written and deviating too much from shared conte= xt with PCE. Cheers, Adrian From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of George Swallow (swallow) Sent: 11 September 2012 20:29 To: Julien Meuric Cc: ccamp@ietf.org Subject: [CCAMP] Objective function draft Julien - Reading the CCAMP notes (which capture little of the actual discussion) I s= ee that there may have been a perception in the room that PCE functionality= at the UNI-N was assumed (actual or proxy). This is not the case. The reason for our draft is that with the UNI, much = of the functionality that resides at the headend is moved to the UNI-N. So= the UNI-C needs a way to express an objective function even if there is no= PCE. Operationally it seems burdensome to require a PCEP at the UNI-C and a PCEP= at the UNI-N, when all that is being done is enabling the UNI-N to perform= what the client would do if it were connected to the network via a normal = link. Do you still object to the draft? Thanks, =85George --_000_CC7605A78107swallowciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Adrian -

I think we are quite in agreement!  The only difference is that I= was using PCE  in a narrower sense of an entity that also runs PCEP. =  But reading the PCE architecture document, I see that you are correct= .

=85George



From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
Date: Tuesday, September 11, 2012 7= :39 PM
To: Cisco Employee <swallow@cisco.com>, Julien Meuric <julien.meuric@orange.com>
Cc: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: RE: [CCAMP] Objective func= tion draft

<individual contributor mode>= ;

 

I'm hoping that you have looked at= RFC 5623 that describes some approaches to inter-layer networking using PC= E.

 

But it seems that perhaps you are = more interested in the per-domain PCE mechanism (RFC 5152) and that you hav= e observed that the OF that would be used in each domain to select the path is not currently available because = it is missing from RSVP-TE. That seems to me to be a perfectly reasonable t= hing to add to RSVP-TE and I think it enables and supports the work of the = PEC working group without any conflict, but I would hope that you share definitions of OFs with the PCE WG.

 

And one last point, when you say

 

> even if there is no PCE<= /o:p>

 

you misunderstand the PCE architec= ture. If you are computing a path (in an LSR) you are de facto providing PC= E functionality. There is no need in the architecture (and thus the implementation) to expose an external (PCEP= ) interface in order to be logically providing PCE function, and this is *e= xactly* why you want access to the OF.

 

However, you would perhaps do bett= er to absorb this ambivalence and note that you need the OF and Metric whet= her or not the PCE is external.

 

All of which you may take as gener= al support for your idea, but a feeling that the I-D is not happily written= and deviating too much from shared context with PCE.

 

Cheers,

Adrian

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of George Swallow (swallow)
Sent: 11 September 2012 20:29
To: Julien Meuric
Cc: ccamp@ietf.org
Subject: [CCAMP] Objective function draft

 

Julien -

 

Reading the CCAMP notes (which capture litt= le of the actual discussion) I see that there may have been a perception in= the room that PCE functionality at the UNI-N was assumed (actual or proxy).

 

This is not the case.  The reason for = our draft is that with the UNI, much of the functionality that resides at t= he headend is moved to the UNI-N.  So the UNI-C needs a way to express an objective function even if there is no PCE= .  

 

Operationally it seems burdensome to requir= e a PCEP at the UNI-C and a PCEP at the UNI-N, when all that is being done = is enabling the UNI-N to perform what the client would do if it were connected to the network via a normal link.=

 

Do you still object to the draft?  

 

Thanks,

 

=85George

 --_000_CC7605A78107swallowciscocom_-- From giomarti@cisco.com Wed Sep 12 06:56: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 34F0421F85A4 for ; Wed, 12 Sep 2012 06:56:08 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+bGTxhTqS0U for ; Wed, 12 Sep 2012 06:56:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0266B21F85F3 for ; Wed, 12 Sep 2012 06:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10449; q=dns/txt; s=iport; t=1347458167; x=1348667767; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=isEEXwNq5msNybx8NCg995b44jhCrAJR8SN6CGiW5L4=; b=Wg9EiooSYAZda2DWEDgnZ4jLEHkrfGyTeZ9LHf8bRo0vIEkxET8lm62r jvnqwPc2rigELR9NnzRgTJjam7k43r7WjHWZmRmg9Y3uT7steB+fPD3M3 krv8eQg4oiDIQ4Kh2tUqJnX1d1PhdMs8hhs+5W8KzQ1MC++VCNnSgWnJZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJGTUFCtJXG//2dsb2JhbABCA7tAgQeCIAEBAQMBAQEBDwFUBwsFCwIBCA4KLicLJQIEDgUJGYdlBgucJIwPlDaLEBqDBIJEYAOIII0/gRSNIoFpgmaBYzQ X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="120829792" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 12 Sep 2012 13:56:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8CDu6be007751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 13:56:06 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 08:56:05 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt Thread-Index: AQHNitezjDYoXHthsUGj7mjNperrOZd68okAgAE65YCAAAQwAIAH+KsAgAHKIwCAALrPgIAAXiiAgAANdAA= Date: Wed, 12 Sep 2012 13:56:05 +0000 Message-ID: References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> <504F9D7C.2040302@grotto-networking.com> <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> <5050892D.4030709@labn.net> In-Reply-To: <5050892D.4030709@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.182] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--77.123400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9D3061A61E021B4583E7654280467D48@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:56:08 -0000 Lou, On Sep 12, 2012, at 15:07 , Lou Berger wrote: > Giovanni, > From the process standpoint, splitting the drafts as you suggest would > make the new draft a normative reference (in the current draft) which > would result in the current draft's publication being blocked until the > new draft is also ready for publication. Given that the new draft > doesn't exist and would need to start at the beginning of the WG > process, I'm not sure there's much positive value in the proposed split > from the process standpoint. >=20 GM> ok > That said, if there was a good technical reason for the split, we should > discuss it. >=20 > Was there any technical rationale for your proposal or was it purely > motivated by process? If the former, can you elaborate? >=20 GM> yes reason was merely technical i) wson-info-model and wson-encode define the "optical interface class" and= an object with the related list of object. So in details, updates on both = draft are basically on up to draft-ietf-ccamp-rwa-wson-encode-17 section 5.= 2.1 first picture (which define the OIC format). Probably once OIC and OIC-= list are defined these two documents can progress independently, right? ii) Code points for specific ITU recommendations and related application co= des encoding may reside in a separate draft so it can be refined further (i= .e. finalize the list of related ITU recommendation, finalize the encoding)= . This draft will actually hold the references to ITU documents. hope made it bit more clear. Anyway, if you feel current format is good eno= ugh I'm ok as well. Cheers G > Lou >=20 > On 9/12/2012 3:30 AM, Giovanni Martinelli (giomarti) wrote: >> Hi Greg, >>=20 >> I know looks like a little bouncing but was just wondering if there's a = partitioning that at the end will simplify even current wson-encode draft m= anagement (so the path to last call).=20 >>=20 >> Anyway I'm fine with any wg chairs decision >>=20 >> cheers >> G >>=20 >>=20 >>=20 >> On Sep 11, 2012, at 22:22 , Greg Bernstein wrote: >>=20 >>> Hi Giovanni we updated the WSON encode draft back on September 5th to p= ut the interface class encoding into the draft. This was in response to the= question raised by Lou in a August 20th email. Lou, Deborah and OIC draft= authors do we need to change this back? >>> Please let us know ASAP as we are trying to get all the WSON drafts int= o last call and this seems to be the last outstanding issue. >>>=20 >>> Best Regards >>> Greg >>> On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: >>>> Hi Greg, Lou, >>>>=20 >>>> having a quick look to wson draft update I generally agree on content = (as expected) what I'm wandering if it worth moving the interface class enc= oding within the draft-ieft-ccamp-rwa-wson-encode. >>>>=20 >>>> Here an alternate proposal on the table: >>>> leave the generic OIC container definition within current wson-encode = draft and put specific OIC encoding (with related ITU references) in a sepa= rate draft (which could be a new version of draft-martinelli-wson-interface= -class or a brand new draft). This separation will probably allow finalizin= g the wson-info-model and wson-encoding separately from specific OIC conten= t (so we'll collect most updated ITU references as already mentioned we sti= ll miss few of them. >>>>=20 >>>>=20 >>>> I guess is for WG chairs to decide. >>>>=20 >>>> If we stay with current doc splitting I'll go for a detailed review on= latest updates. Sorry for raising it with a bit of delay but, just want to= make sure was an option consciously avoided. >>>>=20 >>>> Cheers >>>> G >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 5, 2012, at 17:18 , Lou Berger wrote: >>>>=20 >>>>> Greg, >>>>> Okay. Based on the meeting/discussions and the draft, I had expecte= d >>>>> there was sufficient consensus & text to work from. As editors, you'= re >>>>> free to document your perspective on consensus as works best for you. >>>>> Let us (chairs) know if you need assistance and we'll figure out how = to >>>>> help. >>>>>=20 >>>>> Lou >>>>>=20 >>>>> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>>>>> Hi Lou, I'll look at that text. I added to our document what the QI= C >>>>>> authors suggested. Maybe they were planning something else? >>>>>> Greg >>>>>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>>>>> Greg, >>>>>>> Why not start with the concrete proposal that's already on the tab= le, >>>>>>> i.e., the text in >>>>>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03= ? >>>>>>> Frankly, I'm not sure why that text wasn't incorporated in the firs= t >>>>>>> place and figured I missed something -- which is why I sent my earl= ier mail. >>>>>>>=20 >>>>>>> Lou >>>>>>>=20 >>>>>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in tw= o >>>>>>>> weeks. One simple way out of this would be to just use a variable >>>>>>>> length field for the OIC using the ITU-T application string rather= than >>>>>>>> a fixed 64 bit field. >>>>>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>>>>> otherwise) in the future we can make sure to have a place holder. >>>>>>>> However, currently the ITU-T only defines application strings for = this >>>>>>>> purpose. >>>>>>>>=20 >>>>>>>> If I don't hear any other suggestions in two weeks, I'll make the = change >>>>>>>> to incorporate variable length strings and keep place holders for >>>>>>>> defining fixed length fields. Then we can move this and related W= SON >>>>>>>> documents into last call. >>>>>>>>=20 >>>>>>>> Best Regards >>>>>>>> Greg B. >>>>>>>>=20 >>>>>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>>>>> Optical Interface Class draft authors can you respond to Lou/List= . >>>>>>>>> Let me know if we need to update the text. We are trying to get = this >>>>>>>>> into last call. >>>>>>>>> Best Regards >>>>>>>>> Greg >>>>>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>>>>> Authors, >>>>>>>>>>=20 >>>>>>>>>> I see that the draft says: >>>>>>>>>> In case of ITU Application Code, there should be a mapping = between >>>>>>>>>> the string defining the application code and the 64 bits nu= mber >>>>>>>>>> implementing the optical interface class. >>>>>>>>>>=20 >>>>>>>>>> Where is this mapping defined? Doesn't it have to be either in = this >>>>>>>>>> draft or a normative reference? >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Lou >>>>>>>>>>=20 >>>>>>>>>> On 8/16/2012 7:14 PM, internet-drafts@ietf.org wrote: >>>>>>>>>>> A New Internet-Draft is available from the on-line Internet-Dra= fts >>>>>>>>>>> directories. >>>>>>>>>>> This draft is a work item of the Common Control and Measuremen= t >>>>>>>>>>> Plane Working Group of the IETF. >>>>>>>>>>>=20 >>>>>>>>>>> Title : Routing and Wavelength Assignment Informat= ion >>>>>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>>>>> Young Lee >>>>>>>>>>> Dan Li >>>>>>>>>>> Wataru Imajuku >>>>>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>>>>> Pages : 33 >>>>>>>>>>> Date : 2012-08-16 >>>>>>>>>>>=20 >>>>>>>>>>> Abstract: >>>>>>>>>>> A wavelength switched optical network (WSON) requires that c= ertain >>>>>>>>>>> key information elements are made available to facilitate pa= th >>>>>>>>>>> computation and the establishment of label switching paths (= LSPs). >>>>>>>>>>> The information model described in "Routing and Wavelength >>>>>>>>>>> Assignment Information for Wavelength Switched Optical Netwo= rks" >>>>>>>>>>> shows what information is required at specific points in the= WSON. >>>>>>>>>>> Part of the WSON information model contains aspects that may= be of >>>>>>>>>>> general applicability to other technologies, while other par= ts are >>>>>>>>>>> fairly specific to WSONs. >>>>>>>>>>>=20 >>>>>>>>>>> This document provides efficient, protocol-agnostic encoding= s for >>>>>>>>>>> the WSON specific information elements. It is intended that >>>>>>>>>>> protocol-specific documents will reference this memo to desc= ribe >>>>>>>>>>> how >>>>>>>>>>> information is carried for specific uses. Such encodings can= be >>>>>>>>>>> used >>>>>>>>>>> to extend GMPLS signaling and routing protocols. In addition= these >>>>>>>>>>> encodings could be used by other mechanisms to convey this s= ame >>>>>>>>>>> information to a path computation element (PCE). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-enco= de >>>>>>>>>>>=20 >>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>>>=20 >>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-en= code-16 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>=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 >>>>>>>>>>=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From lberger@labn.net Wed Sep 12 07:08: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 1DF3D21F8604 for ; Wed, 12 Sep 2012 07:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.078 X-Spam-Level: X-Spam-Status: No, score=-100.078 tagged_above=-999 required=5 tests=[AWL=0.083, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHnaDDOvyHFB for ; Wed, 12 Sep 2012 07:08:28 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 2774921F8606 for ; Wed, 12 Sep 2012 07:08:28 -0700 (PDT) Received: (qmail 31253 invoked by uid 0); 12 Sep 2012 14:08:26 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 12 Sep 2012 14:08:26 -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=5WgoUR+0FxhLrDun0bZdXYyor2VNY3CxrjAYHJqeiAo=; b=Fr5fp4tRhWNxEhG1s+tZQFBr4xuLkWDy4YpaZXo+oXg5BPPgU0yL59/6fxcIFfznb5M9KOJXR/3RE0xTM8d25PAwthStWOw73QMX0tahSzoxbB8fuuo5HqQDcZAuZ4sl; Received: from box313.bluehost.com ([69.89.31.113]:41436 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TBncA-0005qZ-6H; Wed, 12 Sep 2012 08:08:26 -0600 Message-ID: <50509757.7000400@labn.net> Date: Wed, 12 Sep 2012 10:08:23 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> <504F9D7C.2040302@grotto-networking.com> <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> <5050892D.4030709@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.4 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: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:08:29 -0000 Giovanni, I don't have a strong preference for where the code points are defined, just that they are. I do think that there is strong justification for the drafts that collectively support a solution to progress as as a group. I, from the chair perspective, defer to the authors to propose their preferred approach to documenting the solution. The WG can agree/disagree from a proposal once made. But not having the full solution documented, e.g., using fields without formal definitions, is a good way to limit progressing the work. Lou On 9/12/2012 9:56 AM, Giovanni Martinelli (giomarti) wrote: > Lou, > > On Sep 12, 2012, at 15:07 , Lou Berger wrote: > >> Giovanni, >> From the process standpoint, splitting the drafts as you suggest would >> make the new draft a normative reference (in the current draft) which >> would result in the current draft's publication being blocked until the >> new draft is also ready for publication. Given that the new draft >> doesn't exist and would need to start at the beginning of the WG >> process, I'm not sure there's much positive value in the proposed split >> from the process standpoint. >> > > GM> ok > >> That said, if there was a good technical reason for the split, we should >> discuss it. >> >> Was there any technical rationale for your proposal or was it purely >> motivated by process? If the former, can you elaborate? >> > > GM> yes reason was merely technical > i) wson-info-model and wson-encode define the "optical interface class" and an object with the related list of object. So in details, updates on both draft are basically on up to draft-ietf-ccamp-rwa-wson-encode-17 section 5.2.1 first picture (which define the OIC format). Probably once OIC and OIC-list are defined these two documents can progress independently, right? > > ii) Code points for specific ITU recommendations and related application codes encoding may reside in a separate draft so it can be refined further (i.e. finalize the list of related ITU recommendation, finalize the encoding). This draft will actually hold the references to ITU documents. > > hope made it bit more clear. Anyway, if you feel current format is good enough I'm ok as well. > > Cheers > G > > > >> Lou >> >> On 9/12/2012 3:30 AM, Giovanni Martinelli (giomarti) wrote: >>> Hi Greg, >>> >>> I know looks like a little bouncing but was just wondering if there's a partitioning that at the end will simplify even current wson-encode draft management (so the path to last call). >>> >>> Anyway I'm fine with any wg chairs decision >>> >>> cheers >>> G >>> >>> >>> >>> On Sep 11, 2012, at 22:22 , Greg Bernstein wrote: >>> >>>> Hi Giovanni we updated the WSON encode draft back on September 5th to put the interface class encoding into the draft. This was in response to the question raised by Lou in a August 20th email. Lou, Deborah and OIC draft authors do we need to change this back? >>>> Please let us know ASAP as we are trying to get all the WSON drafts into last call and this seems to be the last outstanding issue. >>>> >>>> Best Regards >>>> Greg >>>> On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: >>>>> Hi Greg, Lou, >>>>> >>>>> having a quick look to wson draft update I generally agree on content (as expected) what I'm wandering if it worth moving the interface class encoding within the draft-ieft-ccamp-rwa-wson-encode. >>>>> >>>>> Here an alternate proposal on the table: >>>>> leave the generic OIC container definition within current wson-encode draft and put specific OIC encoding (with related ITU references) in a separate draft (which could be a new version of draft-martinelli-wson-interface-class or a brand new draft). This separation will probably allow finalizing the wson-info-model and wson-encoding separately from specific OIC content (so we'll collect most updated ITU references as already mentioned we still miss few of them. >>>>> >>>>> >>>>> I guess is for WG chairs to decide. >>>>> >>>>> If we stay with current doc splitting I'll go for a detailed review on latest updates. Sorry for raising it with a bit of delay but, just want to make sure was an option consciously avoided. >>>>> >>>>> Cheers >>>>> G >>>>> >>>>> >>>>> >>>>> On Sep 5, 2012, at 17:18 , Lou Berger wrote: >>>>> >>>>>> Greg, >>>>>> Okay. Based on the meeting/discussions and the draft, I had expected >>>>>> there was sufficient consensus & text to work from. As editors, you're >>>>>> free to document your perspective on consensus as works best for you. >>>>>> Let us (chairs) know if you need assistance and we'll figure out how to >>>>>> help. >>>>>> >>>>>> Lou >>>>>> >>>>>> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>>>>>> Hi Lou, I'll look at that text. I added to our document what the QIC >>>>>>> authors suggested. Maybe they were planning something else? >>>>>>> Greg >>>>>>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>>>>>> Greg, >>>>>>>> Why not start with the concrete proposal that's already on the table, >>>>>>>> i.e., the text in >>>>>>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >>>>>>>> Frankly, I'm not sure why that text wasn't incorporated in the first >>>>>>>> place and figured I missed something -- which is why I sent my earlier mail. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>>>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>>>>>>>> weeks. One simple way out of this would be to just use a variable >>>>>>>>> length field for the OIC using the ITU-T application string rather than >>>>>>>>> a fixed 64 bit field. >>>>>>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>>>>>> otherwise) in the future we can make sure to have a place holder. >>>>>>>>> However, currently the ITU-T only defines application strings for this >>>>>>>>> purpose. >>>>>>>>> >>>>>>>>> If I don't hear any other suggestions in two weeks, I'll make the change >>>>>>>>> to incorporate variable length strings and keep place holders for >>>>>>>>> defining fixed length fields. Then we can move this and related WSON >>>>>>>>> documents into last call. >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> Greg B. >>>>>>>>> >>>>>>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>>>>>> Optical Interface Class draft authors can you respond to Lou/List. >>>>>>>>>> Let me know if we need to update the text. We are trying to get this >>>>>>>>>> into last call. >>>>>>>>>> Best Regards >>>>>>>>>> Greg >>>>>>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>>>>>> Authors, >>>>>>>>>>> >>>>>>>>>>> I see that the draft says: >>>>>>>>>>> In case of ITU Application Code, there should be a mapping between >>>>>>>>>>> the string defining the application code and the 64 bits number >>>>>>>>>>> implementing the optical interface class. >>>>>>>>>>> >>>>>>>>>>> Where is this mapping defined? Doesn't it have to be either in this >>>>>>>>>>> draft or a normative reference? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Lou >>>>>>>>>>> >>>>>>>>>>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>>>>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>>>>>> Young Lee >>>>>>>>>>>> Dan Li >>>>>>>>>>>> Wataru Imajuku >>>>>>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>>>>>> Pages : 33 >>>>>>>>>>>> Date : 2012-08-16 >>>>>>>>>>>> >>>>>>>>>>>> Abstract: >>>>>>>>>>>> A wavelength switched optical network (WSON) requires that certain >>>>>>>>>>>> key information elements are made available to facilitate path >>>>>>>>>>>> computation and the establishment of label switching paths (LSPs). >>>>>>>>>>>> The information model described in "Routing and Wavelength >>>>>>>>>>>> Assignment Information for Wavelength Switched Optical Networks" >>>>>>>>>>>> shows what information is required at specific points in the WSON. >>>>>>>>>>>> Part of the WSON information model contains aspects that may be of >>>>>>>>>>>> general applicability to other technologies, while other parts are >>>>>>>>>>>> fairly specific to WSONs. >>>>>>>>>>>> >>>>>>>>>>>> This document provides efficient, protocol-agnostic encodings for >>>>>>>>>>>> the WSON specific information elements. It is intended that >>>>>>>>>>>> protocol-specific documents will reference this memo to describe >>>>>>>>>>>> how >>>>>>>>>>>> information is carried for specific uses. Such encodings can be >>>>>>>>>>>> used >>>>>>>>>>>> to extend GMPLS signaling and routing protocols. In addition these >>>>>>>>>>>> encodings could be used by other mechanisms to convey this same >>>>>>>>>>>> information to a path computation element (PCE). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>>>>>>>> >>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>>>> >>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> =================================================== >>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>>> >>> >>> >>> >>> >>> > > > > > From rgandhi@cisco.com Wed Sep 12 07:13: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 99F3E21F8569 for ; Wed, 12 Sep 2012 07:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azX1vzISrtUg for ; Wed, 12 Sep 2012 07:13:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5878E21F8540 for ; Wed, 12 Sep 2012 07:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8560; q=dns/txt; s=iport; t=1347459229; x=1348668829; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=rinSqtln/LKiFDDueX7yeEBRD9ucZ25VgWiuYvWeSps=; b=EdkwG/Hvh0CjnsaFbzXdFnpAn4cw7jhBpzAcEhsHo0+8Wsn7YK4AlzGD 7qp5RmF8rhADDJLCOfQ5G2UtbDvyl3Abs2hBjb9Xwfv3pYrSWLNlE+CWc bWOU6Be4nRFq4y2PStExQizmkG/PDPbmISPk9hEROFXyQ9q8QVQlnjdBB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAJuXUFCtJV2c/2dsb2JhbAA7CoYHtEdygQeCIAEBAQQSASEzEgwEAgEGAg4DBAEBAQQGGQQFAgIwFAkIAgQBDQUIGodrnDKNEwiTKIEdiXMQBIUYNmADpBWBaYJmgVo9 X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="120803609" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 12 Sep 2012 14:13:45 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8CEDjSe021636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 14:13:45 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 09:13:45 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , "zhang.fei3@zte.com.cn" Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt Thread-Index: AQHNhMO1KWryoN3/QKaPbjEu2q9iw5dvgLYAgAroR+CADG6KMA== Date: Wed, 12 Sep 2012 14:13:45 +0000 Message-ID: References: <503CBDC2.9040308@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.162] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--54.385800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:13:50 -0000 SGkgTG91LCBGZWksIFdHLA0KDQpQbGVhc2UgYWR2aXNlIHlvdXIgcmV2aWV3IGNvbW1lbnRzIG9u IHRoZSBmb2xsb3dpbmcuDQoNCldlIGFyZSBjbG9zZWQgdG8gYW4gYWdyZWVtZW50IGFuZCBtaWdo dCBiZSBhbiBpZGVhIHRvIHJldmlzZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQoNClRoYW5rcywN ClJha2VzaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYWtlc2ggR2Fu ZGhpIChyZ2FuZGhpKSANClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMjoyNyBQ TQ0KVG86ICdMb3UgQmVyZ2VyJzsgemhhbmcuZmVpM0B6dGUuY29tLmNuDQpDYzogY2NhbXBAaWV0 Zi5vcmcNClN1YmplY3Q6IFJFOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGlu IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4 dA0KDQpUaGFua3MgTG91Lg0KDQpZb3VyIHByb3Bvc2FsIGJlbG93IHNvdW5kcyBnb29kLg0KDQpQ b3RlbnRpYWwgdGV4dCBmb3IgdGhlIHJlbWFpbmVkIHR3byBzZWN0aW9ucyBpbiB0aGUgZHJhZnQg Y2FuIGJlIGFzIGZvbGxvd3MuIFBsZWFzZSBmZWVsIGZyZWUgdG8gcmV2aXNlLg0KDQozLjIuNiBT aWduYWxpbmcgb2YgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBGb3IgRGlmZmVyZW50IExT UCBSb2xlcyBUaGVyZSBjYW4gYWxzbyBiZSBhIHBhaXIgb2YgcmVjb3ZlcnkgYW5kL29yIHJlcm91 dGUgTFNQcyBhcyBwZXIgcHJvY2VkdXJlcyBkZWZpbmUgaW4gW1JGQzQ4NzJdLCBbUkZDNDg3M10g YW5kIFtSRkM0MDkwXS4gVG9nZXRoZXIgd2l0aCB0aG9zZSBwcm9jZWR1cmVzLCBhIG5vZGUgdXNl cyBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3Qgb3IgQVNTT0NJQVRJT04gb2JqZWN0IGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudCB0byBmb3JtIGFuIGFzc29jaWF0ZWQgYmlkaXJlY3Rpb25hbCBM U1AgcGFpciBmb3IgZWFjaCBMU1Agcm9sZS4NCg0KMy4yLjcuIFNpZ25hbGluZyBvZiBBdXRvLXR1 bm5lbCBNZXNoLWdyb3VwIExTUHMNCiAgIEEgbm9kZSBtYXkgYnVpbGQgTFNQcyBhdXRvbWF0aWNh bGx5IHRvIHJlbW90ZSBwZWVycyBpbiBhIG1lc2ggdXNpbmcNCiAgIHRoZSBtZXNoLWdyb3VwIG1l bWJlcnNoaXAgZGVmaW5lZCBpbiBbUkZDNDk3Ml0uIEEgbm9kZSBNVVNUIGJlIHByb3Zpc2lvbmVk IHdpdGggaWRlbnRpY2FsIGFzc29jaWF0aW9uIElEDQogICBmb3IgdGhlIGdpdmVuIG1lc2gtZ3Jv dXAgbWVtYmVycyBwZWVycyB0byBidWlsZCBhIG1lc2ggb2YgYXNzb2NpYXRlZCBiaWRpcmVjdGlv bmFsIExTUHMuIFRoZSBleHRlbmRlZA0KICAgYXNzb2NpYXRpb24gSUQgY2FuIGJlIHVzZWQgdG8g Zm9ybSB1bmlxdWUgRXh0ZW5kZWQgQVNTT0NJQUlUT04gb2JqZWN0IGluIGVhY2ggTFNQIHRvIGRp ZmZlcmVudCByZW1vdGUgcGVlcnMuDQoNCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u bmV0XQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDI4LCAyMDEyIDg6NDcgQU0NClRvOiB6aGFuZy5m ZWkzQHp0ZS5jb20uY24NCkNjOiBjY2FtcEBpZXRmLm9yZzsgUmFrZXNoIEdhbmRoaSAocmdhbmRo aSkNClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFJldmlldyBSZXF1ZXN0IEZvciBDaGFuZ2VzIGluIGRy YWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0K DQpGZWksDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHRleHQgYWRkcmVzc2VzIHRoZSBpc3N1ZSBvZiBz ZWxlY3Rpb24gb2YgYXNzb2NpYXRpb24gb2JqZWN0IGNvbnRlbnRzIGluIHRoZSBjYXNlIG9mIGRv dWJsZSBzaWRlZCBwcm92aXNpb25pbmcuICBIb3cgYWJvdXQ6DQotIGluIHRoZSBjYXNlIG9mIGRv dWJsZSBzaWRlZCBwcm92aXNpb25pbmcgKm9ubHkqDQogIDEuIEFzc29jaWF0aW9uIFNvdXJjZSBp cyBzZXQgdG8gYW4gYWRkcmVzcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdp bmF0ZXMgdGhlIGFzc29jaWF0aW9uLiAod2hpY2ggbWF5IGJlIGEgbWFuYWdlbWVudCBlbnRpdHku KQ0KICAyLiBBc3NvY2lhdGlvbiBJRCBpcyBhIHZhbHVlIGFzc2lnbmVkIGJ1dCB0aGUgbm9kZSB0 aGF0IG9yaWdpbmF0ZXMNCiAgICAgdGhlIGFzc29jaWF0aW9uLg0KICAzLiBHbG9iYWwgQXNzb2Np YXRpb24gU291cmNlLCB3aGVuIHVzZWQsIGlzIHNldCB0byB0aGUgR2xvYmFsX0lEIG9mDQogICAg IHRoZSBub2RlIHRoYXQgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uDQogIDQuIEV4dGVuZGVk IEFzc29jaWF0aW9uIElELCB3aGVuIHVzZWQsIGlzIHNlbGVjdGVkIGJ5IHRoZSBub2RlIHRoYXQN CiAgICAgb3JpZ2luYXRlcyB0aGUgYXNzb2NpYXRpb24uDQogIC0gIElmIGVpdGhlciAoMykgb3Ig KDQpIGFyZSB1c2VkLCBhbiBFeHRlbmRlZCBBU1NPQ0lBVElPTiBvYmplY3QNCiAgICAgW2Fzc29j LWV4dF0gaXMgdXNlZC4gIE90aGVyd2lzZSBhIEFTU09DSUFUSU9OIG9iamVjdCBbcmZjNDg3Ml0N CiAgICAgaXMgdXNlZA0KDQotIHdoaWxlIHdlJ3JlIGF0IGl0LCBpbiB0aGUgY2FzZSBvZiBzaW5n bGUgc2lkZWQgcHJvdmlzaW9uaW5nICpvbmx5KiAobm90ZSBvbmx5ICMxIGRpZmZlcnMpDQogIDEu IEFzc29jaWF0aW9uIFNvdXJjZSBpcyBzZXQgdG8gYW4gYWRkcmVzcyBhc3NpZ25lZCB0byB0aGUg bm9kZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMgdGhlIExTUC4NCiAgMi4gQXNzb2NpYXRpb24gSUQg aXMgYSB2YWx1ZSBhc3NpZ25lZCBidXQgdGhlIG5vZGUgdGhhdCBvcmlnaW5hdGVzDQogICAgIHRo ZSBhc3NvY2lhdGlvbi4NCiAgMy4gR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSwgd2hlbiB1c2Vk LCBpcyBzZXQgdG8gdGhlIEdsb2JhbF9JRCBvZg0KICAgICB0aGUgbm9kZSB0aGF0IG9yaWdpbmF0 ZXMgdGhlIGFzc29jaWF0aW9uLg0KICA0LiBFeHRlbmRlZCBBc3NvY2lhdGlvbiBJRCwgd2hlbiB1 c2VkLCBpcyBzZWxlY3RlZCBieSB0aGUgbm9kZSB0aGF0DQogICAgIG9yaWdpbmF0ZXMgdGhlIGFz c29jaWF0aW9uLg0KICAtICBJZiBlaXRoZXIgKDMpIG9yICg0KSBhcmUgdXNlZCwgYW4gRXh0ZW5k ZWQgQVNTT0NJQVRJT04gb2JqZWN0DQogICAgIFthc3NvYy1leHRdIGlzIHVzZWQuICBPdGhlcndp c2UgYSBBU1NPQ0lBVElPTiBvYmplY3QgW3JmYzQ4NzJdDQogICAgIGlzIHVzZWQNCg0KSSB0aGlu ayB0aGUgYWJvdmUgYWRkcmVzc2VzIG15IHBvaW50IGFzIGl0IGNhbiBiZSB1c2VkIHRvIGVuc3Vy ZSB1bmlxdWUgTFNQIGFzc29jaWF0aW9uIGluIGFsbCBjYXNlcy4gIEJUVyBpdCBhbHNvIGFsaWdu cyB2ZXJ5IG5pY2VseSB3aXRoIHRoZSBleGlzdGluZyBkZWZpbml0aW9uIG9mIHRoZSBhc3NvY2lh dGlvbiBvYmplY3RzLg0KDQpUbyBhZGRyZXNzIHdoYXQgSSBzdXNwZWN0IGlzIHlvdXIgY29uY2Vy biwgMy4yLjggY2FuIHRoZW4gYmVjb21lIHNvbWV0aGluZyBsaWtlIChmZWVsIGZyZWUgdG8gcmV2 aXNlKToNCg0KICAzLjIuOCAgTVBMUy1UUCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQIElk ZW50aWZpZXJzDQoNCiAgW1JGQzYzNzBdIGRlZmluZXMgdGhlIExTUCBhc3NvY2lhdGVkIGlkZW50 aWZpZXJzIGJhc2VkIG9uIHRoZQ0KICBzaWduYWxpbmcgcGFyYW1ldGVycyBvZiBlYWNoIHVuaWRp cmVjdGlvbmFsIExTUC4gVGhlIGNvbWJpbmF0aW9uDQogIG9mIGVhY2ggdW5pZGlyZWN0aW9uYWwg TFNQJ3MgcGFyYW1ldGVycyBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZQ0KICBBc3NvY2lhdGVkIEJp ZGlyZWN0aW9uYWwgTFNQLiAgVXNpbmcgdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbg0KICB0aGlz IGRvY3VtZW50LCBhbnkgbm9kZSB0aGF0IGlzIGFsb25nIHRoZSBwYXRoIG9mIGJvdGgNCiAgdW5p ZGlyZWN0aW9uYWwgTFNQcyBjYW4gaWRlbnRpZnkgd2hpY2ggcGFpciBvZiB1bmlkaXJlY3Rpb25h bCBMU1BzDQogIHN1cHBvcnQgYW4gQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUCBhcyB3ZWxs IGFzIHRoZSBzaWduYWxpbmcNCiAgcGFyYW1ldGVycyByZXF1aXJlZCBieSBbUkZDNjM3MF0uICBO b3RlIHRoYXQgdGhlIExTUCBlbmQtcG9pbnRzDQogIHdpbGwgYWx3YXlzIGJlIHRoZSBwYXRoIG9m IGJvdGggdW5pZGlyZWN0aW9uYWwgTFNQcy4NCg0KTG91DQoNCk9uIDgvMjcvMjAxMiAxMDoyMCBQ TSwgemhhbmcuZmVpM0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gVGhhbmsgeW91IGxvdQ0KPiAN Cj4gSG93IGFib3V0IGNoYW5naW5nIHRoZSBkZXNjcmlwdGlvbnMgaW4gcGFyYWdyYXBoIDMuMi44 DQo+IA0KPiAgICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMgdGhlIGFzc29jaWF0 aW9uIHNvdXJjZSBNQVkgbmVlZCB0bw0KPiAgIGxlYXJuIGFib3V0IHRoZSBHbG9iYWxfSUQgW1JG QzYzNzBdIG9mIHRoZSBwZWVyIG5vZGUsIHdoaWNoIGNhbiBiZQ0KPiAgIGRvbmUgYnkgaW5zZXJ0 aW5nIHRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBlICJMU1ANCj4g ICBpZGVudGlmaWVycyIgaW4gdGhlIG91dGdvaW5nIFBhdGggbWVzc2FnZSBhbmQgYmVpbmcgY2Fy cmllZCBiYWNrIGluDQo+ICAgdGhlIFJlc3YgbWVzc2FnZSwgYXMgZGVmaW5lZCBpbiBbSS1ELCBk cmFmdC16aGFuZy1jY2FtcC1tcGxzLXRwLQ0KPiAgIHJzdnB0ZS1leHQtdHVubmVsLW51bV0uDQo+ IA0KPiBpbnRvDQo+IA0KPiAgICBJbiBzb21lIHNjZW5hcmlvcywgYSBub2RlIHRoYXQgaXMgdGhl IGFzc29jaWF0aW9uIHNvdXJjZSBNQVkgbmVlZCB0bw0KPiAgIGxlYXJuIGFib3V0IHRoZSBHbG9i YWxfSUQgW1JGQzYzNzBdIG9mIHRoZSBwZWVyIG5vZGUuIEFsdGhvdWdoIHRoZQ0KPiAgICBzY29w ZSBvZiB0aGUgZHJhZnQgW0ktRCwNCj4gZHJhZnQtemhhbmctY2NhbXAtbXBscy10cC1yc3ZwdGUt ZXh0LXR1bm5lbC1udW1dDQo+ICAgIGlzIGxpbWl0ZWQgdG8gdGhlIGNvLXJvdXRlZCBiaWRpcmVj dGlvbmFsIExTUCwgdGhlIGRlZmluZWQgDQo+IHByb2NlZHVyZXMgY2FuDQo+ICAgIGJlIHJldXNl ZCBoZXJlIGFsc28uIFRoZSBBU1NPQ0lBVElPTiBvYmplY3Qgd2l0aCBBc3NvY2lhdGlvbiBUeXBl ICJMU1ANCj4gICBJZGVudGlmaWVycyIgaXMgaW5zZXJ0ZWQgaW4gdGhlIG91dGdvaW5nIFBhdGgg bWVzc2FnZSBhdCB0aGUgYXNzb2NpYXRpb24NCj4gICAgc291cmNlIGFuZCBjYXJyaWVkIGJhY2sg aW4gdGhlIGNvcnJlc3BvbmRpbmcgUmVzdiBtZXNzYWdlLiBBbGwgdGhlIA0KPiBmaWVsZHMNCj4g ICAgb2YgdGhlIEFTU09DSUFUSU9OIG9iamVjdCBleGNlcHQgdGhlIEFzc29jaWF0aW9uIFR5cGUg aW4gdGhlIFBhdGggDQo+IG1lc3NhZ2UNCj4gICAgY2FuIGJlIGlnbm9yZWQgYnkgdGhlIHJlY2Vp dmVyIGFuZCB0aGUgR2xvYmFsX0lEIG9mIHRoZSBwZWVyIG5vZGUgDQo+IGlzIHB1c2hlZA0KPiAg ICBpbnRvIHRoZSBmaWVsZCBvZiB0aGUgR2xvYmFsIEFzc29jaWF0aW9uIFNvdXJjZSBpbiB0aGUg UmVzdiBtZXNzYWdlLg0KPiANCj4gQmVzdCByZWdhcmRzDQo+IA0KPiBGZWkNCj4gDQo+IA0KPiAq TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4qDQo+IA0KPiAyMDEyLTA4LTI4IDAyOjMwDQo+ IA0KPiAJDQo+IMrVvP7Iyw0KPiAJemhhbmcuZmVpM0B6dGUuY29tLmNuDQo+ILOty80NCj4gCSJj Y2FtcEBpZXRmLm9yZyIgPGNjYW1wQGlldGYub3JnPiwgIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkp Ig0KPiA8cmdhbmRoaUBjaXNjby5jb20+DQo+INb3zOINCj4gCVJlOiBbQ0NBTVBdIFJldmlldyBS ZXF1ZXN0IEZvciBDaGFuZ2VzIGluIA0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRl LWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gDQo+IA0KPiAJDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gRmVpLA0KPiAgICAgICAgICAgICAgICAgVGhlIHByb2JsZW0gb25seSBleGlzdHMgaW4g dGhlIGRvdWJsZSBzaWRlZCANCj4gcHJvdmlzaW9pbmcgY2FzZSwgc28gbm8gbmVlZCB0byBjb21w bGljYXRlIHRoZSBzaW5nbGUgc2lkZWQgDQo+IHByb3Zpc2lvbmluZyBjYXNlLg0KPiANCj4gTG91 DQo+IA0KPiANCj4gT24gOC8yNi8yMDEyIDk6MDMgUE0sIHpoYW5nLmZlaTNAenRlLmNvbS5jbiB3 cm90ZToNCj4+IFRoZSBhZG1pbmlzdHJhdGl2ZQ0KPj4gYXBwcm9hY2ggY2FuIGludGVncmF0ZSBi b3RoIG1vZGVscywgd2lsbCBiZSBhIGdvb2QgaWRlYS4NCj4gDQo+IA0K From giomarti@cisco.com Wed Sep 12 08:10: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 7751921F8618 for ; Wed, 12 Sep 2012 08:10:56 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlQ50p6BXQBw for ; Wed, 12 Sep 2012 08:10:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3185121F8569 for ; Wed, 12 Sep 2012 08:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11693; q=dns/txt; s=iport; t=1347462655; x=1348672255; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pM3znfdx4StrPWjzWH4wqoAektXOaIzkQq4LVWtDQYk=; b=e97RJhr6BS8Qn6eltnElbtGz37gURZ/rJfNRyKrLK1Ezx3wRAb/lp5Ej XqViebTrNpA9GE1y6OMHa6KqoSVkYO7XiY7a0wGvbmBDfCV3ibe2Hh8We qOYR2OcNkHV7vUkd/xNuQdWxDPDkovklMQMinishE2cphbC+pOstjJ7LB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAKlUFCtJV2d/2dsb2JhbABCA7tAgQeCIAEBAQMBAQEBDwFUBwsFCwIBCA4KLicLJQIEDgUJEgeHZQYLnA6MD5QnixAVBYMEgkRgA4ggjT+BFI0igWmCZoFbCDQ X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="120606327" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 12 Sep 2012 15:10:54 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8CFAsEs031868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 15:10:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.3]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 10:10:53 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt Thread-Index: AQHNitezjDYoXHthsUGj7mjNperrOZd68okAgAE65YCAAAQwAIAH+KsAgAHKIwCAALrPgIAAXiiAgAANdACAAANvgIAAEXUA Date: Wed, 12 Sep 2012 15:10:53 +0000 Message-ID: References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> <504F9D7C.2040302@grotto-networking.com> <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> <5050892D.4030709@labn.net> <50509757.7000400@labn.net> In-Reply-To: <50509757.7000400@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.182] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--79.306600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:10:56 -0000 got the point, thx! ~G On Sep 12, 2012, at 16:08 , Lou Berger wrote: > Giovanni, > I don't have a strong preference for where the code points are defined, > just that they are. I do think that there is strong justification for > the drafts that collectively support a solution to progress as as a > group. I, from the chair perspective, defer to the authors to propose > their preferred approach to documenting the solution. The WG can > agree/disagree from a proposal once made. >=20 > But not having the full solution documented, e.g., using fields without > formal definitions, is a good way to limit progressing the work. >=20 > Lou >=20 > On 9/12/2012 9:56 AM, Giovanni Martinelli (giomarti) wrote: >> Lou, >>=20 >> On Sep 12, 2012, at 15:07 , Lou Berger wrote: >>=20 >>> Giovanni, >>> From the process standpoint, splitting the drafts as you suggest would >>> make the new draft a normative reference (in the current draft) which >>> would result in the current draft's publication being blocked until the >>> new draft is also ready for publication. Given that the new draft >>> doesn't exist and would need to start at the beginning of the WG >>> process, I'm not sure there's much positive value in the proposed split >>> from the process standpoint. >>>=20 >>=20 >> GM> ok >>=20 >>> That said, if there was a good technical reason for the split, we shoul= d >>> discuss it. >>>=20 >>> Was there any technical rationale for your proposal or was it purely >>> motivated by process? If the former, can you elaborate? >>>=20 >>=20 >> GM> yes reason was merely technical >> i) wson-info-model and wson-encode define the "optical interface class" = and an object with the related list of object. So in details, updates on bo= th draft are basically on up to draft-ietf-ccamp-rwa-wson-encode-17 section= 5.2.1 first picture (which define the OIC format). Probably once OIC and O= IC-list are defined these two documents can progress independently, right? >>=20 >> ii) Code points for specific ITU recommendations and related application= codes encoding may reside in a separate draft so it can be refined further= (i.e. finalize the list of related ITU recommendation, finalize the encodi= ng). This draft will actually hold the references to ITU documents. >>=20 >> hope made it bit more clear. Anyway, if you feel current format is good = enough I'm ok as well. >>=20 >> Cheers >> G >>=20 >>=20 >>=20 >>> Lou >>>=20 >>> On 9/12/2012 3:30 AM, Giovanni Martinelli (giomarti) wrote: >>>> Hi Greg, >>>>=20 >>>> I know looks like a little bouncing but was just wondering if there's = a partitioning that at the end will simplify even current wson-encode draft= management (so the path to last call).=20 >>>>=20 >>>> Anyway I'm fine with any wg chairs decision >>>>=20 >>>> cheers >>>> G >>>>=20 >>>>=20 >>>>=20 >>>> On Sep 11, 2012, at 22:22 , Greg Bernstein wrote: >>>>=20 >>>>> Hi Giovanni we updated the WSON encode draft back on September 5th to= put the interface class encoding into the draft. This was in response to t= he question raised by Lou in a August 20th email. Lou, Deborah and OIC dra= ft authors do we need to change this back? >>>>> Please let us know ASAP as we are trying to get all the WSON drafts i= nto last call and this seems to be the last outstanding issue. >>>>>=20 >>>>> Best Regards >>>>> Greg >>>>> On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: >>>>>> Hi Greg, Lou, >>>>>>=20 >>>>>> having a quick look to wson draft update I generally agree on conten= t (as expected) what I'm wandering if it worth moving the interface class e= ncoding within the draft-ieft-ccamp-rwa-wson-encode. >>>>>>=20 >>>>>> Here an alternate proposal on the table: >>>>>> leave the generic OIC container definition within current wson-encod= e draft and put specific OIC encoding (with related ITU references) in a se= parate draft (which could be a new version of draft-martinelli-wson-interfa= ce-class or a brand new draft). This separation will probably allow finaliz= ing the wson-info-model and wson-encoding separately from specific OIC cont= ent (so we'll collect most updated ITU references as already mentioned we s= till miss few of them. >>>>>>=20 >>>>>>=20 >>>>>> I guess is for WG chairs to decide. >>>>>>=20 >>>>>> If we stay with current doc splitting I'll go for a detailed review = on latest updates. Sorry for raising it with a bit of delay but, just want = to make sure was an option consciously avoided. >>>>>>=20 >>>>>> Cheers >>>>>> G >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sep 5, 2012, at 17:18 , Lou Berger wrote: >>>>>>=20 >>>>>>> Greg, >>>>>>> Okay. Based on the meeting/discussions and the draft, I had expec= ted >>>>>>> there was sufficient consensus & text to work from. As editors, yo= u're >>>>>>> free to document your perspective on consensus as works best for yo= u. >>>>>>> Let us (chairs) know if you need assistance and we'll figure out ho= w to >>>>>>> help. >>>>>>>=20 >>>>>>> Lou >>>>>>>=20 >>>>>>> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>>>>>>> Hi Lou, I'll look at that text. I added to our document what the = QIC >>>>>>>> authors suggested. Maybe they were planning something else? >>>>>>>> Greg >>>>>>>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>>>>>>> Greg, >>>>>>>>> Why not start with the concrete proposal that's already on the t= able, >>>>>>>>> i.e., the text in >>>>>>>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-= 03? >>>>>>>>> Frankly, I'm not sure why that text wasn't incorporated in the fi= rst >>>>>>>>> place and figured I missed something -- which is why I sent my ea= rlier mail. >>>>>>>>>=20 >>>>>>>>> Lou >>>>>>>>>=20 >>>>>>>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>>>>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in = two >>>>>>>>>> weeks. One simple way out of this would be to just use a variab= le >>>>>>>>>> length field for the OIC using the ITU-T application string rath= er than >>>>>>>>>> a fixed 64 bit field. >>>>>>>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>>>>>>> otherwise) in the future we can make sure to have a place holder= . >>>>>>>>>> However, currently the ITU-T only defines application strings fo= r this >>>>>>>>>> purpose. >>>>>>>>>>=20 >>>>>>>>>> If I don't hear any other suggestions in two weeks, I'll make th= e change >>>>>>>>>> to incorporate variable length strings and keep place holders fo= r >>>>>>>>>> defining fixed length fields. Then we can move this and related= WSON >>>>>>>>>> documents into last call. >>>>>>>>>>=20 >>>>>>>>>> Best Regards >>>>>>>>>> Greg B. >>>>>>>>>>=20 >>>>>>>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>>>>>>> Optical Interface Class draft authors can you respond to Lou/Li= st. >>>>>>>>>>> Let me know if we need to update the text. We are trying to ge= t this >>>>>>>>>>> into last call. >>>>>>>>>>> Best Regards >>>>>>>>>>> Greg >>>>>>>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>>>>>>> Authors, >>>>>>>>>>>>=20 >>>>>>>>>>>> I see that the draft says: >>>>>>>>>>>> In case of ITU Application Code, there should be a mapping= between >>>>>>>>>>>> the string defining the application code and the 64 bits n= umber >>>>>>>>>>>> implementing the optical interface class. >>>>>>>>>>>>=20 >>>>>>>>>>>> Where is this mapping defined? Doesn't it have to be either i= n this >>>>>>>>>>>> draft or a normative reference? >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Lou >>>>>>>>>>>>=20 >>>>>>>>>>>> On 8/16/2012 7:14 PM, internet-drafts@ietf.org wrote: >>>>>>>>>>>>> A New Internet-Draft is available from the on-line Internet-D= rafts >>>>>>>>>>>>> directories. >>>>>>>>>>>>> This draft is a work item of the Common Control and Measureme= nt >>>>>>>>>>>>> Plane Working Group of the IETF. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Title : Routing and Wavelength Assignment Informa= tion >>>>>>>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>>>>>>> Young Lee >>>>>>>>>>>>> Dan Li >>>>>>>>>>>>> Wataru Imajuku >>>>>>>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>>>>>>> Pages : 33 >>>>>>>>>>>>> Date : 2012-08-16 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Abstract: >>>>>>>>>>>>> A wavelength switched optical network (WSON) requires that = certain >>>>>>>>>>>>> key information elements are made available to facilitate p= ath >>>>>>>>>>>>> computation and the establishment of label switching paths = (LSPs). >>>>>>>>>>>>> The information model described in "Routing and Wavelength >>>>>>>>>>>>> Assignment Information for Wavelength Switched Optical Netw= orks" >>>>>>>>>>>>> shows what information is required at specific points in th= e WSON. >>>>>>>>>>>>> Part of the WSON information model contains aspects that ma= y be of >>>>>>>>>>>>> general applicability to other technologies, while other pa= rts are >>>>>>>>>>>>> fairly specific to WSONs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> This document provides efficient, protocol-agnostic encodin= gs for >>>>>>>>>>>>> the WSON specific information elements. It is intended that >>>>>>>>>>>>> protocol-specific documents will reference this memo to des= cribe >>>>>>>>>>>>> how >>>>>>>>>>>>> information is carried for specific uses. Such encodings ca= n be >>>>>>>>>>>>> used >>>>>>>>>>>>> to extend GMPLS signaling and routing protocols. In additio= n these >>>>>>>>>>>>> encodings could be used by other mechanisms to convey this = same >>>>>>>>>>>>> information to a path computation element (PCE). >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-en= code >>>>>>>>>>>>>=20 >>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-1= 6 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-= encode-16 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>=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 >>>>>>>>>>>>=20 >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 From gregb@grotto-networking.com Wed Sep 12 08:36: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 CB39D21F860D for ; Wed, 12 Sep 2012 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scl3ilto8o2Q for ; Wed, 12 Sep 2012 08:36:44 -0700 (PDT) Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 269D621F8564 for ; Wed, 12 Sep 2012 08:36:44 -0700 (PDT) Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id DF0DC2100DFC; Wed, 12 Sep 2012 10:36:42 -0500 (CDT) Message-ID: <5050AC08.9050303@grotto-networking.com> Date: Wed, 12 Sep 2012 08:36:40 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Giovanni Martinelli (giomarti)" References: <20120816231453.15922.4595.idtracker@ietfa.amsl.com> <503273AE.8000700@labn.net> <50327B42.2010108@grotto-networking.com> <50465D6B.1060809@grotto-networking.com> <504661AC.3040109@labn.net> <504769D3.5020704@grotto-networking.com> <50476D56.6000108@labn.net> <7D9D17F0-3B67-41CF-8484-8EA7BE3B610D@cisco.com> <504F9D7C.2040302@grotto-networking.com> <7D2FDA3B-AEE4-41FE-8FE1-5F12EF4C58F2@cisco.com> <5050892D.4030709@labn.net> <50509757.7000400@labn.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070205060003010205090003" Cc: "" Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-16.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:36:45 -0000 This is a multi-part message in MIME format. --------------070205060003010205090003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So it seems we'll stick with defining the optical interface class ITU-T string mappings to 64 bit encoding in the WSON Encode draft. OIC draft authors can you double check what we put in draft-ietf-ccamp-rwa-wson-encode-17.txt . We took this from the OIC draft but had to change some text and a bit of the encoding (a bit map seemed needed for suffixes). Best Regards Greg On 9/12/2012 8:10 AM, Giovanni Martinelli (giomarti) wrote: > got the point, thx! > > ~G > > On Sep 12, 2012, at 16:08 , Lou Berger wrote: > >> Giovanni, >> I don't have a strong preference for where the code points are defined, >> just that they are. I do think that there is strong justification for >> the drafts that collectively support a solution to progress as as a >> group. I, from the chair perspective, defer to the authors to propose >> their preferred approach to documenting the solution. The WG can >> agree/disagree from a proposal once made. >> >> But not having the full solution documented, e.g., using fields without >> formal definitions, is a good way to limit progressing the work. >> >> Lou >> >> On 9/12/2012 9:56 AM, Giovanni Martinelli (giomarti) wrote: >>> Lou, >>> >>> On Sep 12, 2012, at 15:07 , Lou Berger wrote: >>> >>>> Giovanni, >>>> From the process standpoint, splitting the drafts as you suggest would >>>> make the new draft a normative reference (in the current draft) which >>>> would result in the current draft's publication being blocked until the >>>> new draft is also ready for publication. Given that the new draft >>>> doesn't exist and would need to start at the beginning of the WG >>>> process, I'm not sure there's much positive value in the proposed split >>>> from the process standpoint. >>>> >>> GM> ok >>> >>>> That said, if there was a good technical reason for the split, we should >>>> discuss it. >>>> >>>> Was there any technical rationale for your proposal or was it purely >>>> motivated by process? If the former, can you elaborate? >>>> >>> GM> yes reason was merely technical >>> i) wson-info-model and wson-encode define the "optical interface class" and an object with the related list of object. So in details, updates on both draft are basically on up to draft-ietf-ccamp-rwa-wson-encode-17 section 5.2.1 first picture (which define the OIC format). Probably once OIC and OIC-list are defined these two documents can progress independently, right? >>> >>> ii) Code points for specific ITU recommendations and related application codes encoding may reside in a separate draft so it can be refined further (i.e. finalize the list of related ITU recommendation, finalize the encoding). This draft will actually hold the references to ITU documents. >>> >>> hope made it bit more clear. Anyway, if you feel current format is good enough I'm ok as well. >>> >>> Cheers >>> G >>> >>> >>> >>>> Lou >>>> >>>> On 9/12/2012 3:30 AM, Giovanni Martinelli (giomarti) wrote: >>>>> Hi Greg, >>>>> >>>>> I know looks like a little bouncing but was just wondering if there's a partitioning that at the end will simplify even current wson-encode draft management (so the path to last call). >>>>> >>>>> Anyway I'm fine with any wg chairs decision >>>>> >>>>> cheers >>>>> G >>>>> >>>>> >>>>> >>>>> On Sep 11, 2012, at 22:22 , Greg Bernstein wrote: >>>>> >>>>>> Hi Giovanni we updated the WSON encode draft back on September 5th to put the interface class encoding into the draft. This was in response to the question raised by Lou in a August 20th email. Lou, Deborah and OIC draft authors do we need to change this back? >>>>>> Please let us know ASAP as we are trying to get all the WSON drafts into last call and this seems to be the last outstanding issue. >>>>>> >>>>>> Best Regards >>>>>> Greg >>>>>> On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote: >>>>>>> Hi Greg, Lou, >>>>>>> >>>>>>> having a quick look to wson draft update I generally agree on content (as expected) what I'm wandering if it worth moving the interface class encoding within the draft-ieft-ccamp-rwa-wson-encode. >>>>>>> >>>>>>> Here an alternate proposal on the table: >>>>>>> leave the generic OIC container definition within current wson-encode draft and put specific OIC encoding (with related ITU references) in a separate draft (which could be a new version of draft-martinelli-wson-interface-class or a brand new draft). This separation will probably allow finalizing the wson-info-model and wson-encoding separately from specific OIC content (so we'll collect most updated ITU references as already mentioned we still miss few of them. >>>>>>> >>>>>>> >>>>>>> I guess is for WG chairs to decide. >>>>>>> >>>>>>> If we stay with current doc splitting I'll go for a detailed review on latest updates. Sorry for raising it with a bit of delay but, just want to make sure was an option consciously avoided. >>>>>>> >>>>>>> Cheers >>>>>>> G >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sep 5, 2012, at 17:18 , Lou Berger wrote: >>>>>>> >>>>>>>> Greg, >>>>>>>> Okay. Based on the meeting/discussions and the draft, I had expected >>>>>>>> there was sufficient consensus & text to work from. As editors, you're >>>>>>>> free to document your perspective on consensus as works best for you. >>>>>>>> Let us (chairs) know if you need assistance and we'll figure out how to >>>>>>>> help. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> On 9/5/2012 11:03 AM, Greg Bernstein wrote: >>>>>>>>> Hi Lou, I'll look at that text. I added to our document what the QIC >>>>>>>>> authors suggested. Maybe they were planning something else? >>>>>>>>> Greg >>>>>>>>> On 9/4/2012 1:16 PM, Lou Berger wrote: >>>>>>>>>> Greg, >>>>>>>>>> Why not start with the concrete proposal that's already on the table, >>>>>>>>>> i.e., the text in >>>>>>>>>> http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03? >>>>>>>>>> Frankly, I'm not sure why that text wasn't incorporated in the first >>>>>>>>>> place and figured I missed something -- which is why I sent my earlier mail. >>>>>>>>>> >>>>>>>>>> Lou >>>>>>>>>> >>>>>>>>>> On 9/4/2012 3:58 PM, Greg Bernstein wrote: >>>>>>>>>>> Hi Lou and CCAMPers. I haven't heard anything on this issue in two >>>>>>>>>>> weeks. One simple way out of this would be to just use a variable >>>>>>>>>>> length field for the OIC using the ITU-T application string rather than >>>>>>>>>>> a fixed 64 bit field. >>>>>>>>>>> If the ITU-T comes up with another specific encoding (64 bit or >>>>>>>>>>> otherwise) in the future we can make sure to have a place holder. >>>>>>>>>>> However, currently the ITU-T only defines application strings for this >>>>>>>>>>> purpose. >>>>>>>>>>> >>>>>>>>>>> If I don't hear any other suggestions in two weeks, I'll make the change >>>>>>>>>>> to incorporate variable length strings and keep place holders for >>>>>>>>>>> defining fixed length fields. Then we can move this and related WSON >>>>>>>>>>> documents into last call. >>>>>>>>>>> >>>>>>>>>>> Best Regards >>>>>>>>>>> Greg B. >>>>>>>>>>> >>>>>>>>>>> On 8/20/2012 11:00 AM, Greg Bernstein wrote: >>>>>>>>>>>> Optical Interface Class draft authors can you respond to Lou/List. >>>>>>>>>>>> Let me know if we need to update the text. We are trying to get this >>>>>>>>>>>> into last call. >>>>>>>>>>>> Best Regards >>>>>>>>>>>> Greg >>>>>>>>>>>> On 8/20/2012 10:28 AM, Lou Berger wrote: >>>>>>>>>>>>> Authors, >>>>>>>>>>>>> >>>>>>>>>>>>> I see that the draft says: >>>>>>>>>>>>> In case of ITU Application Code, there should be a mapping between >>>>>>>>>>>>> the string defining the application code and the 64 bits number >>>>>>>>>>>>> implementing the optical interface class. >>>>>>>>>>>>> >>>>>>>>>>>>> Where is this mapping defined? Doesn't it have to be either in this >>>>>>>>>>>>> draft or a normative reference? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Lou >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/16/2012 7:14 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 : Routing and Wavelength Assignment Information >>>>>>>>>>>>>> Encoding for Wavelength Switched Optical Networks >>>>>>>>>>>>>> Author(s) : Greg M. Bernstein >>>>>>>>>>>>>> Young Lee >>>>>>>>>>>>>> Dan Li >>>>>>>>>>>>>> Wataru Imajuku >>>>>>>>>>>>>> Filename : draft-ietf-ccamp-rwa-wson-encode-16.txt >>>>>>>>>>>>>> Pages : 33 >>>>>>>>>>>>>> Date : 2012-08-16 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Abstract: >>>>>>>>>>>>>> A wavelength switched optical network (WSON) requires that certain >>>>>>>>>>>>>> key information elements are made available to facilitate path >>>>>>>>>>>>>> computation and the establishment of label switching paths (LSPs). >>>>>>>>>>>>>> The information model described in "Routing and Wavelength >>>>>>>>>>>>>> Assignment Information for Wavelength Switched Optical Networks" >>>>>>>>>>>>>> shows what information is required at specific points in the WSON. >>>>>>>>>>>>>> Part of the WSON information model contains aspects that may be of >>>>>>>>>>>>>> general applicability to other technologies, while other parts are >>>>>>>>>>>>>> fairly specific to WSONs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This document provides efficient, protocol-agnostic encodings for >>>>>>>>>>>>>> the WSON specific information elements. It is intended that >>>>>>>>>>>>>> protocol-specific documents will reference this memo to describe >>>>>>>>>>>>>> how >>>>>>>>>>>>>> information is carried for specific uses. Such encodings can be >>>>>>>>>>>>>> used >>>>>>>>>>>>>> to extend GMPLS signaling and routing protocols. In addition these >>>>>>>>>>>>>> encodings could be used by other mechanisms to convey this same >>>>>>>>>>>>>> information to a path computation element (PCE). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>>>>>> >>>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>>>>>> >>>>>> >>>>>> -- >>>>>> =================================================== >>>>>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------070205060003010205090003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
So it seems we'll stick with defining the optical interface class ITU-T string mappings to 64 bit encoding in the WSON Encode draft.
OIC draft authors can you double check what we put in draft-ietf-ccamp-rwa-wson-encode-17.txt. We took this from the OIC draft but had to change some text and a bit of the encoding (a bit map seemed needed for suffixes).

Best Regards
Greg
On 9/12/2012 8:10 AM, Giovanni Martinelli (giomarti) wrote:
got the point, thx!

~G

On Sep 12, 2012, at 16:08 , Lou Berger wrote:


Giovanni,
	I don't have a strong preference for where the code points are defined,
just that they are.  I do think that there is strong justification for
the drafts that collectively support a solution to progress as as a
group.  I, from the chair perspective, defer to the authors to propose
their preferred approach to documenting the solution.  The WG can
agree/disagree from a proposal once made.

But not having the full solution documented, e.g., using fields without
formal definitions, is a good way to limit progressing the work.

Lou

On 9/12/2012 9:56 AM, Giovanni Martinelli (giomarti) wrote:

Lou,

On Sep 12, 2012, at 15:07 , Lou Berger wrote:


Giovanni,
	From the process standpoint, splitting the drafts as you suggest would
make the new draft a normative reference (in the current  draft) which
would result in the current draft's publication being blocked until the
new draft is also ready for publication.  Given that the new draft
doesn't exist and would need to start at the beginning of the WG
process, I'm not sure there's much positive value in the proposed split
from the process standpoint.


GM> ok


That said, if there was a good technical reason for the split, we should
discuss it.

Was there any technical rationale for your proposal or was it purely
motivated by process?  If the former, can you elaborate?


GM> yes reason was merely technical
i) wson-info-model and wson-encode define the "optical interface class" and an object with the related list of object. So in details, updates on both draft are basically on up to draft-ietf-ccamp-rwa-wson-encode-17 section 5.2.1 first picture (which define the OIC format). Probably once OIC and OIC-list are defined these two documents can progress independently, right?

ii) Code points for specific ITU recommendations and related application codes encoding may reside in a separate draft so it can be refined further (i.e. finalize the list of related ITU recommendation, finalize the encoding). This draft will actually hold the references to ITU documents.

hope made it bit more clear. Anyway, if you feel current format is good enough I'm ok as well.

Cheers
G




Lou

On 9/12/2012 3:30 AM, Giovanni Martinelli (giomarti) wrote:

Hi Greg,

I know looks like a little bouncing but was just wondering if there's a partitioning that at the end will simplify even current wson-encode draft management (so the path to last call). 

Anyway I'm fine with any wg chairs decision

cheers
G



On Sep 11, 2012, at 22:22 , Greg Bernstein wrote:


Hi Giovanni we updated the WSON encode draft back on September 5th to put the interface class encoding into the draft. This was in response to the question raised by Lou in a August 20th email.  Lou, Deborah and OIC draft authors do we need to change this back?
Please let us know ASAP as we are trying to get all the WSON drafts into last call and this seems to be the last outstanding issue.

Best Regards
Greg
On 9/10/2012 10:02 AM, Giovanni Martinelli (giomarti) wrote:

Hi Greg, Lou,

having a quick look to wson draft update I generally agree on content (as expected) what I'm wandering if it worth moving the interface class encoding within  the draft-ieft-ccamp-rwa-wson-encode.

Here an alternate proposal on the table:
leave the generic OIC container definition within current wson-encode draft and put specific OIC encoding (with related ITU references) in a separate draft (which could be a new version of draft-martinelli-wson-interface-class or a brand new draft). This separation will probably allow finalizing the wson-info-model and wson-encoding separately from specific OIC content (so we'll collect most updated ITU references as already mentioned we still miss few of them.


I guess is for  WG chairs to decide.

If we stay with current doc splitting I'll go for a detailed review on latest updates. Sorry for raising it with a bit of delay but, just want to make sure was an option consciously avoided.

Cheers
G



On Sep 5, 2012, at 17:18 , Lou Berger wrote:


Greg,
	Okay.  Based on the meeting/discussions and the draft, I had expected
there was sufficient consensus & text to work from.  As editors, you're
free to document your perspective on consensus as works best for you.
Let us (chairs) know if you need assistance and we'll figure out how to
help.

Lou

On 9/5/2012 11:03 AM, Greg Bernstein wrote:

Hi Lou, I'll look at that text.  I added to our document what the QIC
authors suggested.  Maybe they were planning something else?
Greg
On 9/4/2012 1:16 PM, Lou Berger wrote:

Greg,
	Why not start with the concrete proposal that's already on the table,
i.e., the text in
http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03?
Frankly, I'm not sure why that text wasn't incorporated in the first
place and figured I missed something -- which is why I sent my earlier mail.

Lou

On 9/4/2012 3:58 PM, Greg Bernstein wrote:

Hi Lou and CCAMPers.  I haven't heard anything on this issue in two
weeks.  One simple way out of this would be to just use a variable
length field for the OIC using the ITU-T application string rather than
a fixed 64 bit field.
If the ITU-T comes up with another specific encoding (64 bit or
otherwise) in the future we can make sure to have a place holder.
However, currently the ITU-T only defines application strings for this
purpose.

If I don't hear any other suggestions in two weeks, I'll make the change
to incorporate variable length strings and keep place holders for
defining fixed length fields.  Then we can move this and related WSON
documents into last call.

Best Regards
Greg B.

On 8/20/2012 11:00 AM, Greg Bernstein wrote:

Optical Interface Class draft authors can you respond to Lou/List.
Let me know if we need to update the text.  We are trying to get this
into last call.
Best Regards
Greg
On 8/20/2012 10:28 AM, Lou Berger wrote:

Authors,

I see that the draft says:
    In case of ITU Application Code, there should be a mapping between
    the string defining the application code and the 64 bits number
    implementing the optical interface class.

Where is this mapping defined?  Doesn't it have to be either in this
draft or a normative reference?

Thanks,
Lou

On 8/16/2012 7:14 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           : Routing and Wavelength Assignment Information
Encoding for Wavelength Switched Optical Networks
  Author(s)       : Greg M. Bernstein
                         Young Lee
                         Dan Li
                         Wataru Imajuku
  Filename        : draft-ietf-ccamp-rwa-wson-encode-16.txt
  Pages           : 33
  Date            : 2012-08-16

Abstract:
  A wavelength switched optical network (WSON) requires that certain
  key information elements are made available to facilitate path
  computation and the establishment of label switching paths (LSPs).
  The information model described in "Routing and Wavelength
  Assignment Information for Wavelength Switched Optical Networks"
  shows what information is required at specific points in the WSON.
  Part of the WSON information model contains aspects that may be of
  general applicability to other technologies, while other parts are
  fairly specific to WSONs.

  This document provides efficient, protocol-agnostic encodings for
  the WSON specific information elements. It is intended that
  protocol-specific documents will reference this memo to describe
how
  information is carried for specific uses. Such encodings can be
used
  to extend GMPLS signaling and routing protocols. In addition these
  encodings could be used by other mechanisms to convey this same
  information to a path computation element (PCE).





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-rwa-wson-encode-16


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
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


                  

                  



                

                

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237



              

              






            

          

          






        

      

      




    

    

    

    
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237



  


--------------070205060003010205090003--

From rgandhi@cisco.com  Wed Sep 12 08:52: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 9AE1021F859B for ; Wed, 12 Sep 2012 08:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.497
X-Spam-Level: 
X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[AWL=2.102,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4dailrt-S6t for ; Wed, 12 Sep 2012 08:52:45 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12D21F863F for ; Wed, 12 Sep 2012 08:52:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4605; q=dns/txt; s=iport; t=1347465151; x=1348674751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iyTAgpkZsjxbFO1Uatf3C1gHotzM9LLgojBFZzCBHr0=; b=H4bdcHYsocAyIVkZAssaVufuy06HLwKeZA30NiuuA/l7XrNt8811v5nX RhC6FaEfxVCL03mdRedJ5u4JU+zM2IGcW7stsiCBs6MDTBzKp4E4ijJr7 pYsRluYv47WrY4gvfWCunntAprbONWpb5L7V7TF4zucDTBIsgF2oHGz6I w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAA+vUFCtJV2d/2dsb2JhbABFu0iBB4IgAQEBBBIBFBM/DAQCAQgOAwQBAQEKFAkHMhQJCAEBBA4FCBqHa5wBoDSLEIViYAOkFYFpgmaCFw
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="120846657"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2012 15:52:24 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8CFqOs6016791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 15:52:24 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 10:52:24 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Lou Berger 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObA=
Date: Wed, 12 Sep 2012 15:52:23 +0000
Message-ID: 
References:  <50461FB2.7080707@labn.net>  <50508AC9.5000709@labn.net>
In-Reply-To: <50508AC9.5000709@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005
x-tm-as-result: No--45.643100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2012 15:52:51 -0000

Thanks Lou.

Are we ok in general to use NOTIFY message [RFC3473] for this?

One advantage with the mid-point sending notification for the reverse LSP i=
s that signaling error propagation time (mid->egress-node->ingress-node) is=
 significantly reduced (to mid->ingress-node) which may be preferred in som=
e cases.

Thanks,
Rakesh


-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Wednesday, September 12, 2012 9:15 AM
To: Rakesh Gandhi (rgandhi)
Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext=
-associated-lsp-04.txt

Rakesh,
	Speaking as WG participant, I haven't thought about this too much so may b=
e off, but method 3 seems to be most consistent with the usage of the REVER=
SE_LSP Object in the path message.  Perhaps consider using the REVERSE_LSP =
Object in the upstream/Resv direction to allow the egress/tail to provide t=
he ingress/head with arbitrary information....

Lou

On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
> Hi WG,
>=20
> Any thoughts on the following proposal?
>=20
> Thanks,
> Rakesh
>=20
>=20
> -----Original Message-----
> From: Rakesh Gandhi (rgandhi)
> Sent: Tuesday, September 04, 2012 1:36 PM
> To: 'Lou Berger'
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: RE: Question on LSP control in=20
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>=20
>=20
> Thanks Lou for your reply.
>=20
> RFC 3473 defines procedures for NOTIFY request and reply. We could use th=
is for reverse LSP signaling error notification to the initiating ingress n=
ode.
>=20
>  ::=3D  [] [ [ =
| ] ... ]
>   =20
>    >
>=20
> There are multiple ways we can use the NOTIFY message.
>=20
> Method 1 - Mid-point aware with Path message request:
> When an egress node receives a Path message with REVERSE_LSP object, the =
node will insert NOTIFY_REQ message in the reverse LSP path message with no=
de ID of the initiating ingress node. A mid-point node will send  a copy of=
 the signaling error to the initiating node using the NOTIFY message.
>=20
> IPv4 Notify Request Object
>    IPv4 Notify Node Address: 32 bits
>       The IP address of the node that should be notified when generating =
an error message.
>=20
> Method 2 - Mid-point aware with Resv message request:
> When an initiating ingress node receives a Path message for a reverse LSP=
, the node will insert NOTIFY_REQ message in the reverse LSP Resv message w=
ith its own node ID. A mid-point node will send a copy of the signaling err=
or to the initiating node using the NOTIFY message.
>=20
> Method 3 - Tail-end relaying :
> When an egress node receives a Path message with REVERSE_LSP object, the =
node will relay the received signaling error message on the reverse LSP to =
the initializing ingress node. The egress node copies the received "ERROR_S=
PEC" object into a NOTIFY [RFC3473, section 4.3] message and signals it to =
the ingress node. In this case, NOTIFY_REQ message is not required.=20
>=20
> Please advise your thoughts.
>=20
> Thanks,
> Rakesh
>=20
>=20
>=20
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Tuesday, September 04, 2012 11:35 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: Re: Question on LSP control in=20
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>=20
> As I read the current rev, no such notification mechanism is specified.
>  Looks like you get to propose one!
>=20
> Lou (as WG participant).
>=20
> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>> Hi Lou, Fei,
>>
>> When an (originating) ingress node is provisioned with "5 (TBD)  Single =
Sided Associated Bidirectional LSPs  (A)" and wishes to control both forwar=
d and reverse  LSPs by adding "REVERSE_LSP" object, I would think that the =
ingress node needs to know about the signaling (path) errors (such as soft =
preemption or admission failure) on the reverse LSP.  Is there any text som=
ewhere in an RFC/draft that describes how a mid-point node can send the sig=
naling (path) error to the originating ingress node for the reverse LSP? Is=
 there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any =
previous discussion on this topic.
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>>
>>
>=20
>=20
>=20
>=20

From lberger@labn.net  Wed Sep 12 09:10: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 1C2BA21F85A4 for ; Wed, 12 Sep 2012 09:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.084
X-Spam-Level: 
X-Spam-Status: No, score=-100.084 tagged_above=-999 required=5 tests=[AWL=0.077, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUMoi08p8bZh for ; Wed, 12 Sep 2012 09:10:46 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 32F1B21F859C for ; Wed, 12 Sep 2012 09:10:46 -0700 (PDT)
Received: (qmail 14413 invoked by uid 0); 12 Sep 2012 16:10:45 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 12 Sep 2012 16:10:45 -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=FgJq2SgZNUpQd5BZM9itp9NFjhgmw9pVeG+HPHQrzzc=;  b=fcQVTHhd6lxAhwr5fYvov5CB3o/DDWt9GcQotuUvKHoru9iXZu13f24PN465z6DlHdmX6Km9kuu64UaFDDpcGAVIEt6jR3swcuK/KjMKkKC+fq3us5k9WAu7rYbN7f9g;
Received: from box313.bluehost.com ([69.89.31.113]:56167 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TBpWW-0006DV-NK; Wed, 12 Sep 2012 10:10:45 -0600
Message-ID: <5050B401.6070008@labn.net>
Date: Wed, 12 Sep 2012 12:10:41 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" 
References:  <5037C010.7010605@labn.net>  <5037E6C4.5050507@labn.net>  <503A3309.4020907@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
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] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2012 16:10:47 -0000

Rakesh,
	Looks like you switched threads in your last message.  (BTW I think I'm
getting lost in the number of changes being discussed and think having a
new version capturing changes to date would help...)

Let me try to merge them:

>On 8/27/2012 5:16 PM, Rakesh Gandhi (rgandhi) wrote:
>>
>> Let me propose revised texts for section 3.2.6 [item 7], 3.2.7 [item
8] and 4.1 [items 1,2,3,6].	
>>
>> Regards,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Sunday, August 26, 2012 10:31 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>> Subject: Re: [CCAMP] Review Request For Changes in
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>
>> Rakesh,
>> 	See below (using normal reply notation)...
>>
>> On 8/24/2012 5:18 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Lou,
>>>
>>> Please see inline....
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Friday, August 24, 2012 4:41 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>> Subject: Re: [CCAMP] Review Request For Changes in
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>> Rakesh,
>>>
>>> See below.
>>>
>>> On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
>>>>
>>>> Thanks for your review. Please see inline....
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Friday, August 24, 2012 1:55 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: ccamp@ietf.org
>>>> Subject: Re: [CCAMP] Review Request For Changes in
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>
>>>> Speaking as a WG participant, and ignoring changes 4 and 5 as you
plan to revert these:
>>>>
>>>> On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote:
>[...]
>
>>>>> 7. Path Protection object:
>>>>> Version 03 of the draft vaguely mentioned and assumed of
>>>>> using protection object for path protection. New version 04
>>>>> adds some texts to clarify it, no new rule is added.
>>>>>
>>>>
>>>> I think providing informative text on interactions of this
>>>> document with the various defined recovery (4872 and 4872) and
>>>> reroute (4090) mechanisms is a really good idea. That said, I
>>>> found this section a bit opaque. Ignoring the wordsmithing, what
>>>> specific points are you trying to make?
>>>> 
>>>>
>>>>  It just highlights that for a bi-directional tunnel, there
>>>> can be a working bidirectional LSPs and protecting bidirectional
>>>> LSPs. That's all.
>>>>
>>>
>>> I think the proposed text is really confusing and doesn't cover the
>>> full scope (in particular 4872 is about recovery which is both
>>> protection and restoration, it doesn't cover 4873 or 4090). Can you
>>> propose (one the
>>> list) some alternate text?
>>>
>>>  Idea here is that there are multiple bidirectional LSPs for a
>>> tunnel for different LSP roles. We could remove the LSP type as
>>> primary and secondary reference from the text, and just state LSPs
>>> for different roles.
>>>
>>
>> Again, I think the issue is with the proposed language.


On 9/4/2012 12:26 PM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou.
> Potential text for the remained two sections in the draft can be as
>  follows. Please feel free to revise.
>
> 3.2.6 Signaling of Associated Bidirectional LSP For Different LSP
> Roles
> There can also be a pair of recovery and/or reroute LSPs as per
> procedures define in [RFC4872], [RFC4873] and [RFC4090]. Together
> with those procedures, a node uses Extended ASSOCIATION object or
> ASSOCIATION object defined in this document to form an associated
> bidirectional LSP pair for each LSP role.

I still don't understand this text.  Perhaps you mean something like:

3.2.6. Associated Bidirectional LSPs and LSP Recovery

LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not
impacted by this document.  The recovery mechanisms defined in [RFC4872]
and [RFC4873] rely on the use of ASSOCIATION Objects, but use a
different Association Type field value than defined in this document so
should not be impacted.  The mechanisms defined in [RFC4090] does not
rely on the use of ASSOCIATION Objects and is therefore also not
impacted by the mechanisms defined in this document.


>>
>>
>>>>
>>>>> 8. Auto-tunnel mesh:
>>>>> New version 04 adds a section to elaborate on a use case for
>>>>> auto-tunnel mesh. This is added as an FYI and can be removed if
>>>>> WG thinks so.
>>>>>
>>>>
>>>> How is the association id field value selected in this case?
>>>>
>>>>  Proposal allows that single association-id can be provisioned
>>>> for a mesh-group.
>>> I don't think you have text that supports this.  The closest you
>>> come is:
>>>    A node provisioned to
>>>    build a mesh of associated bidirectional LSPs may use identical
>>>    association ID for the given mesh-group member peers.
>>>
>>> which doesn't say that the "identical association ID" MUST be
>>> provisioned.
>>>
>>>  Yes, we can clarify this.


On 9/4/2012 12:26 PM, Rakesh Gandhi (rgandhi) wrote:
>
> 3.2.7. Signaling of Auto-tunnel Mesh-group LSPs
> A node may build LSPs automatically to remote peers in a mesh using
> the mesh-group membership defined in [RFC4972]. A node MUST be
> provisioned with identical association ID for the given mesh-group
> members peers to build a mesh of associated bidirectional LSPs. The
> extended association ID can be used to form unique Extended
> ASSOCIAITON object in each LSP to different remote peers.

How about something along the lines of:

3.2.7. Associated Bidirectional LSPs and TE Mesh-Groups

TE mesh-groups is defined in [RFC4972]. A node supporting both
Associated Bidirectional LSPs and TE mesh-groups, MAY include an
ASSOCIATION object as defined in this document in Path messages of LSPs
used to support the mesh-group.  To enable unambiguous identification of
the mesh-group's associated bidirectional LSPs, the information carried
in the ASSOCIATION object, including the contents of the Association
Source and Identifier fields MUST be provisioned.

Lou (as WG participant)

>>>
>>
>> Great!
>>
>> Lou
>>
>>> Thanks,
>>> Rakesh
>>>
>>> Lou
>

From lberger@labn.net  Wed Sep 12 09:14: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 ECEEB21F864A for ; Wed, 12 Sep 2012 09:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.088
X-Spam-Level: 
X-Spam-Status: No, score=-100.088 tagged_above=-999 required=5 tests=[AWL=0.073, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kE9yt5uQsItq for ; Wed, 12 Sep 2012 09:14:13 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 28E2121F84EE for ; Wed, 12 Sep 2012 09:14:13 -0700 (PDT)
Received: (qmail 9847 invoked by uid 0); 12 Sep 2012 16:14:10 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 12 Sep 2012 16:14: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=J2e2Oc0R+APxBbhBVR/Rbk+KQUtrYMCVuURM9JU0Q3E=;  b=o29sxxXocuqnxAPoA2849jYfyQ8NvRxUVm3/6lbqQXJO7xaUi4eG5qp0G53sJ4fFiX7bmkmovdVeTLT5nbcJVELUHEE07Cm8smTRm29r62Y5JXZY2HVd0ejfdckDNQr/;
Received: from box313.bluehost.com ([69.89.31.113]:56604 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TBpZp-0007fn-R1; Wed, 12 Sep 2012 10:14:10 -0600
Message-ID: <5050B4CD.10500@labn.net>
Date: Wed, 12 Sep 2012 12:14:05 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" 
References:  <50461FB2.7080707@labn.net>  <50508AC9.5000709@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2012 16:14:14 -0000

Rakesh,


On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou.
> 
> Are we ok in general to use NOTIFY message [RFC3473] for this?

I'm not speaking for the WG, as noted my comments were as a participant.
 IMO you'll need to fully document the proposal, perhaps discuss
alternatives considered, and then ask the WG for concurrence.

> 
> One advantage with the mid-point sending notification for the reverse
> LSP is that signaling error propagation time
> (mid->egress-node->ingress-node) is significantly reduced (to
> mid->ingress-node) which may be preferred in some cases.

>From my (personal) perspective, the added complexity isn't worth the
effort.  Of course, a detailed proposal may show otherwise.

Lou

> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Wednesday, September 12, 2012 9:15 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 	Speaking as WG participant, I haven't thought about this too much so may be off, but method 3 seems to be most consistent with the usage of the REVERSE_LSP Object in the path message.  Perhaps consider using the REVERSE_LSP Object in the upstream/Resv direction to allow the egress/tail to provide the ingress/head with arbitrary information....
> 
> Lou
> 
> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
>> Hi WG,
>>
>> Any thoughts on the following proposal?
>>
>> Thanks,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Rakesh Gandhi (rgandhi)
>> Sent: Tuesday, September 04, 2012 1:36 PM
>> To: 'Lou Berger'
>> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
>> Subject: RE: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>
>> Thanks Lou for your reply.
>>
>> RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node.
>>
>>  ::=  [] [ [ | ] ... ]
>>    
>>    >
>>
>> There are multiple ways we can use the NOTIFY message.
>>
>> Method 1 - Mid-point aware with Path message request:
>> When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send  a copy of the signaling error to the initiating node using the NOTIFY message.
>>
>> IPv4 Notify Request Object
>>    IPv4 Notify Node Address: 32 bits
>>       The IP address of the node that should be notified when generating an error message.
>>
>> Method 2 - Mid-point aware with Resv message request:
>> When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message.
>>
>> Method 3 - Tail-end relaying :
>> When an egress node receives a Path message with REVERSE_LSP object, the node will relay the received signaling error message on the reverse LSP to the initializing ingress node. The egress node copies the received "ERROR_SPEC" object into a NOTIFY [RFC3473, section 4.3] message and signals it to the ingress node. In this case, NOTIFY_REQ message is not required. 
>>
>> Please advise your thoughts.
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, September 04, 2012 11:35 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
>> Subject: Re: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> As I read the current rev, no such notification mechanism is specified.
>>  Looks like you get to propose one!
>>
>> Lou (as WG participant).
>>
>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Lou, Fei,
>>>
>>> When an (originating) ingress node is provisioned with "5 (TBD)  Single Sided Associated Bidirectional LSPs  (A)" and wishes to control both forward and reverse  LSPs by adding "REVERSE_LSP" object, I would think that the ingress node needs to know about the signaling (path) errors (such as soft preemption or admission failure) on the reverse LSP.  Is there any text somewhere in an RFC/draft that describes how a mid-point node can send the signaling (path) error to the originating ingress node for the reverse LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any previous discussion on this topic.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
> 
> 
> 
> 

From rgandhi@cisco.com  Wed Sep 12 09:18: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 48B7C21F85A3 for ; Wed, 12 Sep 2012 09:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.023
X-Spam-Level: 
X-Spam-Status: No, score=-9.023 tagged_above=-999 required=5 tests=[AWL=1.576,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOvy7Vk2fCZw for ; Wed, 12 Sep 2012 09:18:44 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CF44021F84F6 for ; Wed, 12 Sep 2012 09:18:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8156; q=dns/txt; s=iport; t=1347466724; x=1348676324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0rGjTgTtbs7GStJmey3wTg4nqH9HDXfVFQhkiL+3f1s=; b=WbLaHMnBr0n9y7xAVoCxeUMBRzmoyywfdAZW7rT4wEoAvulyoXhfYOsb blitNWOOFSEKxc6o8+BuHRqDMIS2Mr9vNM1CKVyji8TBmVJbFBSuPw/09 mE6qjf+/G+Bs2Zkq0ZOhGsgmYO/WJLTnig2EpS6r1znsOT0qTOeJ3Rwe5 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAEW1UFCtJV2c/2dsb2JhbABFu0iBB4IgAQEBBBIBJy0SDAQCAQgOAwQBAQEKFAUEBzIUCQgCBA4FCBqHa5wEoC+FY4UthWJgA6QVgWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="120852775"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 12 Sep 2012 16:18:43 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8CGIhdq025758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 16:18:43 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 11:18:42 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Lou Berger 
Thread-Topic: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2BSy6dKWryoN3/QKaPbjEu2q9iwwBAF9gAAAmySlD//+CQAIAAS+fwgAJxX4D//lFBwIAcgluAgABS8cA=
Date: Wed, 12 Sep 2012 16:18:42 +0000
Message-ID: 
References:  <5037C010.7010605@labn.net>  <5037E6C4.5050507@labn.net>  <503A3309.4020907@labn.net>  <5050B401.6070008@labn.net>
In-Reply-To: <5050B401.6070008@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005
x-tm-as-result: No--50.473400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2012 16:18:45 -0000

Hi Lou,

Thank you for your reply.

I agree with you to revise the draft capturing the agreed changes so far.=20

Your proposal for the following text looks good.=20

3.2.6. Associated Bidirectional LSPs and LSP Recovery

LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not impact=
ed by this document.  The recovery mechanisms defined in [RFC4872] and [RFC=
4873] rely on the use of ASSOCIATION Objects, but use a different Associati=
on Type field value than defined in this document so should not be impacted=
.  The mechanisms defined in [RFC4090] does not rely on the use of ASSOCIAT=
ION Objects and is therefore also not impacted by the mechanisms defined in=
 this document.

3.2.7. Associated Bidirectional LSPs and TE Mesh-Groups

TE mesh-groups is defined in [RFC4972]. A node supporting both Associated B=
idirectional LSPs and TE mesh-groups, MAY include an ASSOCIATION object as =
defined in this document in Path messages of LSPs used to support the mesh-=
group.  To enable unambiguous identification of the mesh-group's associated=
 bidirectional LSPs, the information carried in the ASSOCIATION object, inc=
luding the contents of the Association Source and Identifier fields MUST be=
 provisioned.


Thanks,
Rakesh



-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Wednesday, September 12, 2012 12:11 PM
To: Rakesh Gandhi (rgandhi)
Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
Subject: Re: [CCAMP] Review Request For Changes in draft-ietf-ccamp-mpls-tp=
-rsvpte-ext-associated-lsp-04.txt


Rakesh,
	Looks like you switched threads in your last message.  (BTW I think I'm ge=
tting lost in the number of changes being discussed and think having a new =
version capturing changes to date would help...)

Let me try to merge them:

>On 8/27/2012 5:16 PM, Rakesh Gandhi (rgandhi) wrote:
>>
>> Let me propose revised texts for section 3.2.6 [item 7], 3.2.7 [item
8] and 4.1 [items 1,2,3,6].=09
>>
>> Regards,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Sunday, August 26, 2012 10:31 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>> Subject: Re: [CCAMP] Review Request For Changes in
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>
>> Rakesh,
>> 	See below (using normal reply notation)...
>>
>> On 8/24/2012 5:18 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Lou,
>>>
>>> Please see inline....
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Friday, August 24, 2012 4:41 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: ccamp@ietf.org; zhang.fei3@zte.com.cn
>>> Subject: Re: [CCAMP] Review Request For Changes in=20
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>> Rakesh,
>>>
>>> See below.
>>>
>>> On 8/24/2012 2:31 PM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou,
>>>>
>>>> Thanks for your review. Please see inline....
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Friday, August 24, 2012 1:55 PM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: ccamp@ietf.org
>>>> Subject: Re: [CCAMP] Review Request For Changes in=20
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>
>>>> Speaking as a WG participant, and ignoring changes 4 and 5 as you
plan to revert these:
>>>>
>>>> On 8/23/2012 12:20 PM, Rakesh Gandhi (rgandhi) wrote:
>[...]
>
>>>>> 7. Path Protection object:
>>>>> Version 03 of the draft vaguely mentioned and assumed of using=20
>>>>> protection object for path protection. New version 04 adds some=20
>>>>> texts to clarify it, no new rule is added.
>>>>>
>>>>
>>>> I think providing informative text on interactions of this document=20
>>>> with the various defined recovery (4872 and 4872) and reroute=20
>>>> (4090) mechanisms is a really good idea. That said, I found this=20
>>>> section a bit opaque. Ignoring the wordsmithing, what specific=20
>>>> points are you trying to make?
>>>>=20
>>>>
>>>>  It just highlights that for a bi-directional tunnel, there can=20
>>>> be a working bidirectional LSPs and protecting bidirectional LSPs.=20
>>>> That's all.
>>>>
>>>
>>> I think the proposed text is really confusing and doesn't cover the=20
>>> full scope (in particular 4872 is about recovery which is both=20
>>> protection and restoration, it doesn't cover 4873 or 4090). Can you=20
>>> propose (one the
>>> list) some alternate text?
>>>
>>>  Idea here is that there are multiple bidirectional LSPs for a=20
>>> tunnel for different LSP roles. We could remove the LSP type as=20
>>> primary and secondary reference from the text, and just state LSPs=20
>>> for different roles.
>>>
>>
>> Again, I think the issue is with the proposed language.


On 9/4/2012 12:26 PM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou.
> Potential text for the remained two sections in the draft can be as =20
> follows. Please feel free to revise.
>
> 3.2.6 Signaling of Associated Bidirectional LSP For Different LSP=20
> Roles There can also be a pair of recovery and/or reroute LSPs as per=20
> procedures define in [RFC4872], [RFC4873] and [RFC4090]. Together with=20
> those procedures, a node uses Extended ASSOCIATION object or=20
> ASSOCIATION object defined in this document to form an associated=20
> bidirectional LSP pair for each LSP role.

I still don't understand this text.  Perhaps you mean something like:

3.2.6. Associated Bidirectional LSPs and LSP Recovery

LSP recovery as defined in [RFC4872], [RFC4873] and [RFC4090] is not impact=
ed by this document.  The recovery mechanisms defined in [RFC4872] and [RFC=
4873] rely on the use of ASSOCIATION Objects, but use a different Associati=
on Type field value than defined in this document so should not be impacted=
.  The mechanisms defined in [RFC4090] does not rely on the use of ASSOCIAT=
ION Objects and is therefore also not impacted by the mechanisms defined in=
 this document.


>>
>>
>>>>
>>>>> 8. Auto-tunnel mesh:
>>>>> New version 04 adds a section to elaborate on a use case for=20
>>>>> auto-tunnel mesh. This is added as an FYI and can be removed if WG=20
>>>>> thinks so.
>>>>>
>>>>
>>>> How is the association id field value selected in this case?
>>>>
>>>>  Proposal allows that single association-id can be provisioned=20
>>>> for a mesh-group.
>>> I don't think you have text that supports this.  The closest you=20
>>> come is:
>>>    A node provisioned to
>>>    build a mesh of associated bidirectional LSPs may use identical
>>>    association ID for the given mesh-group member peers.
>>>
>>> which doesn't say that the "identical association ID" MUST be=20
>>> provisioned.
>>>
>>>  Yes, we can clarify this.


On 9/4/2012 12:26 PM, Rakesh Gandhi (rgandhi) wrote:
>
> 3.2.7. Signaling of Auto-tunnel Mesh-group LSPs A node may build LSPs=20
> automatically to remote peers in a mesh using the mesh-group=20
> membership defined in [RFC4972]. A node MUST be provisioned with=20
> identical association ID for the given mesh-group members peers to=20
> build a mesh of associated bidirectional LSPs. The extended=20
> association ID can be used to form unique Extended ASSOCIAITON object=20
> in each LSP to different remote peers.

How about something along the lines of:

3.2.7. Associated Bidirectional LSPs and TE Mesh-Groups

TE mesh-groups is defined in [RFC4972]. A node supporting both Associated B=
idirectional LSPs and TE mesh-groups, MAY include an ASSOCIATION object as =
defined in this document in Path messages of LSPs used to support the mesh-=
group.  To enable unambiguous identification of the mesh-group's associated=
 bidirectional LSPs, the information carried in the ASSOCIATION object, inc=
luding the contents of the Association Source and Identifier fields MUST be=
 provisioned.

Lou (as WG participant)

>>>
>>
>> Great!
>>
>> Lou
>>
>>> Thanks,
>>> Rakesh
>>>
>>> Lou
>

From rgandhi@cisco.com  Wed Sep 12 09:59: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 86A3221F865F for ; Wed, 12 Sep 2012 09:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.236
X-Spam-Level: 
X-Spam-Status: No, score=-7.236 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxb78NNb9ZNg for ; Wed, 12 Sep 2012 09:59:47 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5003A21F85B8 for ; Wed, 12 Sep 2012 09:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25501; q=dns/txt; s=iport; t=1347469185; x=1348678785; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dDhYyXgOeTrEwpDEeDYMQLzLUMc61Vla/yz72US6pew=; b=PF0lLDJXnzhSCS2qiowLVgmhWe27ZG62vS3ZDv7yrF5xW1f5qMBDYxWj wYFL+/jMEK6WTp7Xxz30GTiwSuxDQcr/1N3c+JDpPhp/D7GWDmaJ3p1e/ YQcN7pkFf+Vlp0Efi8kWab5iwohOqc4S00/7QBCm9wWfEJ5FZUGnF1yM1 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAE6/UFCtJXHB/2dsb2JhbABFgkuDPLRTc4EHgiABAQEEEgEaTAwEAgEGAhEEAQEBChYHBQICMBQJCAEBBA4FCBqHa5wJjRMIkxSLEIUsNmADpBWBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200";  d="scan'208,217";a="117868301"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 12 Sep 2012 16:59:31 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8CGxVSY026324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 16:59:31 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 11:59:30 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: "zhang.fei3@zte.com.cn" 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAAkZwOAABUsRXA=
Date: Wed, 12 Sep 2012 16:59:30 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005
x-tm-as-result: No--47.155300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C2409839Axmbalnx07ciscocom_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2012 16:59:48 -0000

--_000_B7D2A316AA32B6469D9670B6A81B7C2409839Axmbalnx07ciscocom_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgRmVpLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkuDQoNClBsZWFzZSBzZWUgaW5saW5lLi48
Ukc+Li4NCg0KDQpGcm9tOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gW21haWx0bzp6aGFuZy5mZWkz
QHp0ZS5jb20uY25dDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTIgOTo0NCBQTQ0K
VG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogY2NhbXBAaWV0Zi5vcmc7IExvdSBCZXJn
ZXINClN1YmplY3Q6IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBkcmFmdC1pZXRmLWNj
YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQpIaSBSYWtl
c2gNCg0KQWNjb3JkaW5nIHRvIHRoZSBkZXNjcmlwdGlvbnMgaW4gUkZDMzQ3MywgSSBhbSBhZnJh
aWQgYm90aCB0aGUgdXBzdHJlYW0gbm90aWZpY2F0aW9uIGFuZCBkb3duc3RyZWFtIG5vdGlmaWNh
dGlvbiBhcmUgcGVybWl0dGVkLg0KPFJHPiBSaWdodC4gSW4gY2FzZSBvZiByZXZlcnNlIExTUCwg
b25seSBkb3duc3RyZWFtIG5vdGlmaWNhdGlvbiBpcyByZXF1aXJlZCB0b3dhcmRzIHRoZSBpbml0
aWF0aW5nIGluZ3Jlc3Mgbm9kZS4NCg0KDQpTb21lIG90aGVyIGlzc3VlcyB0aGF0IG5lZWQgdG8g
YmUgZGlzY3Vzc2VkIGFyZSB0YWdnZWQgaW4gbGluZSB3aXRoIDxmZWk+DQoNCkJlc3QgcmVnYXJk
cw0KDQpGZWkNCg0KIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNjby5jb208
bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj4NCg0KMjAxMi0wOS0xMSAyMToyMg0KDQrK1bz+yMsN
Cg0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+
DQoNCrOty80NCg0KInpoYW5nLmZlaTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUu
Y29tLmNuPiIgPHpoYW5nLmZlaTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29t
LmNuPj4sICJjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0
Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4NCg0K1vfM4g0KDQpSRTogUXVlc3Rpb24gb24g
TFNQIGNvbnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2Np
YXRlZC1sc3AtMDQudHh0DQoNCg0KDQoNCg0KDQoNCkhpIFdHLA0KDQpBbnkgdGhvdWdodHMgb24g
dGhlIGZvbGxvd2luZyBwcm9wb3NhbD8NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpTZW50OiBU
dWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTIgMTozNiBQTQ0KVG86ICdMb3UgQmVyZ2VyJw0KQ2M6
IHpoYW5nLmZlaTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjsgY2Nh
bXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFF1ZXN0aW9u
IG9uIExTUCBjb250cm9sIGluIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFz
c29jaWF0ZWQtbHNwLTA0LnR4dA0KDQoNClRoYW5rcyBMb3UgZm9yIHlvdXIgcmVwbHkuDQoNClJG
QyAzNDczIGRlZmluZXMgcHJvY2VkdXJlcyBmb3IgTk9USUZZIHJlcXVlc3QgYW5kIHJlcGx5LiBX
ZSBjb3VsZCB1c2UgdGhpcyBmb3IgcmV2ZXJzZSBMU1Agc2lnbmFsaW5nIGVycm9yIG5vdGlmaWNh
dGlvbiB0byB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUuDQoNCjxOb3RpZnkgbWVzc2FnZT4g
Ojo9IDxDb21tb24gSGVhZGVyPiBbPElOVEVHUklUWT5dIFsgWzxNRVNTQUdFX0lEX0FDSz4gfCA8
TUVTU0FHRV9JRF9OQUNLPl0gLi4uIF0NCjxFUlJPUl9TUEVDPg0KPG5vdGlmeSBzZXNzaW9uIGxp
c3QgOjo9IDx1cHN0cmVhbSBzZXNzaW9uPiA8ZG93bnN0cmVhbSBzZXNzaW9uPiAgPg0KDQpUaGVy
ZSBhcmUgbXVsdGlwbGUgd2F5cyB3ZSBjYW4gdXNlIHRoZSBOT1RJRlkgbWVzc2FnZS4NCg0KTWV0
aG9kIDEgLSBNaWQtcG9pbnQgYXdhcmUgd2l0aCBQYXRoIG1lc3NhZ2UgcmVxdWVzdDoNCldoZW4g
YW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBv
YmplY3QsIHRoZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUgcmV2
ZXJzZSBMU1AgcGF0aCBtZXNzYWdlIHdpdGggbm9kZSBJRCBvZiB0aGUgaW5pdGlhdGluZyBpbmdy
ZXNzIG5vZGUuIEEgbWlkLXBvaW50IG5vZGUgd2lsbCBzZW5kICBhIGNvcHkgb2YgdGhlIHNpZ25h
bGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2Fn
ZS4NCg0KPGZlaT5PaywgY2FuIHlvdSBjbGFyaWZ5IHdoaWNoIHNlc3Npb24gdGhlIGNvcGllZCBO
T1RJRlkgbWVzc2FnZSBhcmUgY2Fycnlpbmc/IHRoZSBmb3J3YXJkIHNlc3Npb24xIG9yIHRoZSBy
ZXZlcnNlIHNlc3Npb24yPw0KPFJHPiBSZXZlcnNlIExTUCAtIHNlc3Npb24yLg0KSWYgaXQgaXMg
c2Vzc2lvbjEsIEkgYW0gYWZyYWlkIHRoYXQgdGhlIE5PVElGWV9SRVEgb2JqZWN0IGlzIGFsc28g
bmVlZGVkIGluIHRoZSBmb3J3YXJkIExTUCBQYXRoIG1lc3NhZ2UgKCAiTm90ZSB0aGF0IGEgTm90
aWZ5IG1lc3NhZ2UgTVVTVCBOT1QgYmUgZ2VuZXJhdGVkIHVubGVzcyBhbiBhcHByb3ByaWF0ZSBO
b3RpZnkgUmVxdWVzdCBvYmplY3QgaGFzIGJlZW4gcmVjZWl2ZWQuIiBjb3BpZWQgZnJvbSBwYXJh
Z3JhcGggNC4zLjIgZnJvbSBSRkMzNDczICkNCg0KIElmIGl0IGlzIHNlc3Npb24yLCB0aGVyZSBp
cyBubyBjb3BpZWQgTk9USUZZIG1lc3NhZ2UuDQoNCjxSRz4gTm90IHN1cmUgaWYgSSBmb2xsb3cg
obBubyBjb3BpZWQgTk9USUZZIG1lc3NhZ2WhsS4gIFdoZW4gdGhlcmUgaXMgYSBzaWduYWxpbmcg
ZXJyb3Igb24gYSByZXZlcnNlIExTUCAoc2Vzc2lvbiAyKSwgYSBtaWQtcG9pbnQgbm9kZSBhdXRv
bWF0aWNhbGx5IHNlbmRzIHNpZ25hbGluZyBlcnJvciB0b3dhcmRzIGVncmVzcyBub2RlIGJ1dCBp
dCBhbHNvIHNlbmRzIGEgY29weSBvZiBpdCB0b3dhcmRzIHRoZSBpbml0aWF0aW5nIGluZ3Jlc3Mg
bm9kZSB3aGVuIGl0IGhhZCByZWNlaXZlZCBOT1RJRlkgcmVxdWVzdCBtZXNzYWdlIGZvciB0aGUg
cmV2ZXJzZSBMU1AgKHNlc3Npb24yKS4NCg0KSVB2NCBOb3RpZnkgUmVxdWVzdCBPYmplY3QNCiAg
SVB2NCBOb3RpZnkgTm9kZSBBZGRyZXNzOiAzMiBiaXRzDQogICAgIFRoZSBJUCBhZGRyZXNzIG9m
IHRoZSBub2RlIHRoYXQgc2hvdWxkIGJlIG5vdGlmaWVkIHdoZW4gZ2VuZXJhdGluZyBhbiBlcnJv
ciBtZXNzYWdlLg0KDQoNCk1ldGhvZCAyIC0gTWlkLXBvaW50IGF3YXJlIHdpdGggUmVzdiBtZXNz
YWdlIHJlcXVlc3Q6DQpXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIHJlY2VpdmVzIGEg
UGF0aCBtZXNzYWdlIGZvciBhIHJldmVyc2UgTFNQLCB0aGUgbm9kZSB3aWxsIGluc2VydCBOT1RJ
RllfUkVRIG1lc3NhZ2UgaW4gdGhlIHJldmVyc2UgTFNQIFJlc3YgbWVzc2FnZSB3aXRoIGl0cyBv
d24gbm9kZSBJRC4gQSBtaWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQgYSBjb3B5IG9mIHRoZSBzaWdu
YWxpbmcgZXJyb3IgdG8gdGhlIGluaXRpYXRpbmcgbm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3Nh
Z2UuDQoNCjxmZWk+IFNlZSBhYm92ZSwgaWYgaXQgaXMgc2Vzc2lvbjIsIG5vIGNvcGllZCBOT1RJ
RlkgbWVzc2FnZSBhbHNvLg0KPFJHPiBQbGVhc2Ugc2VlIHByZXZpb3VzIHJlcGx5Lg0KDQpNZXRo
b2QgMyAtIFRhaWwtZW5kIHJlbGF5aW5nIDoNCldoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMg
YSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsIHRoZSBub2RlIHdpbGwgcmVs
YXkgdGhlIHJlY2VpdmVkIHNpZ25hbGluZyBlcnJvciBtZXNzYWdlIG9uIHRoZSByZXZlcnNlIExT
UCB0byB0aGUgaW5pdGlhbGl6aW5nIGluZ3Jlc3Mgbm9kZS4gVGhlIGVncmVzcyBub2RlIGNvcGll
cyB0aGUgcmVjZWl2ZWQgIkVSUk9SX1NQRUMiIG9iamVjdCBpbnRvIGEgTk9USUZZIFtSRkMzNDcz
LCBzZWN0aW9uIDQuM10gbWVzc2FnZSBhbmQgc2lnbmFscyBpdCB0byB0aGUgaW5ncmVzcyBub2Rl
LiBJbiB0aGlzIGNhc2UsIE5PVElGWV9SRVEgbWVzc2FnZSBpcyBub3QgcmVxdWlyZWQuDQoNCjxm
ZWk+IEkgYW0gYWZyYWlkIE5PVElGWV9SRVEgb2JqZWN0IGlzIGFsc28gcmVxdWlyZWQgaW4gdGhl
IGZvcndhcmQgYW5kIHJldmVyc2UgTFNQJ3MgUGF0aCBvciBSZXN2IG1lc3NhZ2UsIG90aGVyd2lz
ZSAsdGhlIGVncmVzcyBub2RlIHdpbGwgbm90IHJlYWx5IHRoZSBlcnJvciBtZXNzYWdlLg0KPFJH
PiBUaGlzIHdvdWxkIGJlIGEgc2ltcGxpZmljYXRpb24sIHdoZXJlIGluIHRoZSBhYnNlbmNlIG9m
IGEgTk9USUZZIHJlcXVlc3QgbWVzc2FnZSwgYW5kIHByZXNlbmNlIG9mIHRoZSBSRVZFUlNFX0xT
UCBvYmplY3QsIGVncmVzcyBub2RlIHJlbGF5cyB0aGUgcmVjZWl2ZWQgc2lnbmFsaW5nIGVycm9y
IG9uIHRoZSByZXZlcnNlIExTUCAoc2Vzc2lvbiAyKSB0byB0aGUgaW5pdGlhdGluZyBpbmdyZXNz
IG5vZGUuDQpUaGFua3MsDQpSYWtlc2gNCg0KDQpQbGVhc2UgYWR2aXNlIHlvdXIgdGhvdWdodHMu
DQoNClRoYW5rcywNClJha2VzaA0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XTxtYWlsdG86W21haWx0bzps
YmVyZ2VyQGxhYm4ubmV0XT4NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMToz
NSBBTQ0KVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogemhhbmcuZmVpM0B6dGUuY29t
LmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+OyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86
Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4g
ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0
DQoNCkFzIEkgcmVhZCB0aGUgY3VycmVudCByZXYsIG5vIHN1Y2ggbm90aWZpY2F0aW9uIG1lY2hh
bmlzbSBpcyBzcGVjaWZpZWQuDQpMb29rcyBsaWtlIHlvdSBnZXQgdG8gcHJvcG9zZSBvbmUhDQoN
CkxvdSAoYXMgV0cgcGFydGljaXBhbnQpLg0KDQpPbiA4LzMxLzIwMTIgOTo0OSBBTSwgUmFrZXNo
IEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+IEhpIExvdSwgRmVpLA0KPg0KPiBXaGVuIGFuIChv
cmlnaW5hdGluZykgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggIjUgKFRCRCkgIFNp
bmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyAgKEEpIiBhbmQgd2lzaGVz
IHRvIGNvbnRyb2wgYm90aCBmb3J3YXJkIGFuZCByZXZlcnNlICBMU1BzIGJ5IGFkZGluZyAiUkVW
RVJTRV9MU1AiIG9iamVjdCwgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBpbmdyZXNzIG5vZGUgbmVl
ZHMgdG8ga25vdyBhYm91dCB0aGUgc2lnbmFsaW5nIChwYXRoKSBlcnJvcnMgKHN1Y2ggYXMgc29m
dCBwcmVlbXB0aW9uIG9yIGFkbWlzc2lvbiBmYWlsdXJlKSBvbiB0aGUgcmV2ZXJzZSBMU1AuICBJ
cyB0aGVyZSBhbnkgdGV4dCBzb21ld2hlcmUgaW4gYW4gUkZDL2RyYWZ0IHRoYXQgZGVzY3JpYmVz
IGhvdyBhIG1pZC1wb2ludCBub2RlIGNhbiBzZW5kIHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9y
IHRvIHRoZSBvcmlnaW5hdGluZyBpbmdyZXNzIG5vZGUgZm9yIHRoZSByZXZlcnNlIExTUD8gSXMg
dGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2UgUlNWUF9OT1RJRlkgbWVzc2FnZT8gU29ycnkgaWYg
SSBoYWQgbWlzc2VkIGFueSBwcmV2aW91cyBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuDQo+DQo+
IFRoYW5rcywNCj4gUmFrZXNoDQo+DQo+DQo+DQo+DQo+DQoNCg==

--_000_B7D2A316AA32B6469D9670B6A81B7C2409839Axmbalnx07ciscocom_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Fei,=



 <=
/p>

Thanks for your reply.


 <=
/p>

Please see inline..<RG=
>..


 <=
/p>

 <=
/p>

From: zhang.fe=
i3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]


Sent: Tuesday, September 11, 2012 9:44 PM

To: Rakesh Gandhi (rgandhi)

Cc: ccamp@ietf.org; Lou Berger

Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsv=
pte-ext-associated-lsp-04.txt


 




Hi Rakesh 



According to the descriptions in RFC3473, I am afraid both the up=
stream notification and downstream notification are permitted.



<RG> Right. In case of reverse LSP, only downstream notificatio=
n is required towards the initiating ingress node.   <=
/span>






Some other issues that need to be discussed are tagged in line wi=
th <fei>




Best regards




Fei 












"Rakesh Gandhi (rgandhi)" <=
;rgandhi@cisco.com><=
span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri=
f"">



2012-09-11 21:22











=CA=D5=BC=FE=C8=CB<=
/p>




Lou Berger <lberger@labn.net>









=B3=AD=CB=CD




"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>, "ccamp@ietf.org"
 <ccamp@ietf.org> <=
/o:p>








=D6=F7=CC=E2




RE: Question on LSP control in draft-ietf-=
ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt








 


























Hi WG,



Any thoughts on the following proposal?



Thanks,

Rakesh





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

From: Rakesh Gandhi (rgandhi) 

Sent: Tuesday, September 04, 2012 1:36 PM

To: 'Lou Berger'

Cc: zhang.fei3@zte.com.cn;=
 
ccamp@ietf.org

Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte=
-ext-associated-lsp-04.txt





Thanks Lou for your reply.



RFC 3473 defines procedures for NOTIFY request and reply. We could use =
this for reverse LSP signaling error notification to the initiating ingress=
 node.



<Notify message> ::=3D <Common Header> [<INTEGRITY>] =
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]

<ERROR_SPEC>   

<notify session list ::=3D <upstream session> <downstream s=
ession>  >



There are multiple ways we can use the NOTIFY message.



Method 1 - Mid-point aware with Path message request:

When an egress node receives a Path message with REVERSE_LSP object, th=
e node will insert NOTIFY_REQ message in the reverse LSP path message with =
node ID of the initiating ingress node. A mid-point node will send  a =
copy of the signaling error to the initiating
 node using the NOTIFY message.



<fei>Ok, can you clar=
ify which session the copied NOTIFY message are carrying? the forward sessi=
on1 or the reverse session2?



<RG> Reverse LSP - session2.


If it is session1, I am afraid that the NOTIFY_R=
EQ object is also needed in the forward LSP Path message ( "Note that =
a Notify message MUST NOT be generated unless
 an appropriate Notify Request object has been received." copied from =
paragraph 4.3.2 from RFC3473 )


    <=
br>
 If it is session2, th=
ere is no copied NOTIFY message.







<RG> Not sure if I follow =A1=B0no copied NOTIFY message=A1=B1.=
  When there is a signaling error on a reverse LSP (session 2), a mid-=
point
 node automatically sends signaling error towards egress node but it also s=
ends a copy of it towards the initiating ingress node when it had received =
NOTIFY request message for the reverse LSP (session2).



IPv4 Notify Request Object

  IPv4 Notify Node Address: 32 bits

     The IP address of the node that should be notified =
when generating an error message.






Method 2 - Mid-point aware with Resv message request:

When an initiating ingress node receives a Path message for a reverse L=
SP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message=
 with its own node ID. A mid-point node will send a copy of the signaling e=
rror to the initiating node using
 the NOTIFY message. 



<fei> See above, if i=
t is session2, no copied NOTIFY message also.


<RG> Please see previous reply.



Method 3 - Tail-end relaying :

When an egress node receives a Path message with REVERSE_LSP object, th=
e node will relay the received signaling error message on the reverse LSP t=
o the initializing ingress node. The egress node copies the received "=
ERROR_SPEC" object into a NOTIFY [RFC3473,
 section 4.3] message and signals it to the ingress node. In this case, NOT=
IFY_REQ message is not required.




<fei>=
 I am afraid NOTIFY_REQ object is also required in the forward and reverse =
LSP's Path or Resv message, otherwise ,the egress node will not realy the e=
rror message.<=
/span>


<RG> This would be a simplification, where in the absence of a =
NOTIFY request message, and presence of the REVERSE_LSP object,
 egress node relays the received signaling error on the reverse LSP (sessio=
n 2) to the initiating ingress node.


Thanks,


Rakesh






Please advise your thoughts.



Thanks,

Rakesh







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

From: Lou Berger [mailto:l=
berger@labn.net]


Sent: Tuesday, September 04, 2012 11:35 AM

To: Rakesh Gandhi (rgandhi)

Cc: zhang.fei3@zte.com.cn;=
 
ccamp@ietf.org

Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte=
-ext-associated-lsp-04.txt



As I read the current rev, no such notification mechanism is specified.=


Looks like you get to propose one!



Lou (as WG participant).



On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:

> Hi Lou, Fei,

> 

> When an (originating) ingress node is provisioned with "5 (TB=
D)  Single Sided Associated Bidirectional LSPs  (A)" and wis=
hes to control both forward and reverse  LSPs by adding "REVERSE_=
LSP" object, I would think that the ingress node needs to know about
 the signaling (path) errors (such as soft preemption or admission failure)=
 on the reverse LSP.  Is there any text somewhere in an RFC/draft that=
 describes how a mid-point node can send the signaling (path) error to the =
originating ingress node for the reverse
 LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had mis=
sed any previous discussion on this topic.

> 

> Thanks,

> Rakesh

> 

> 

> 

> 

> 










--_000_B7D2A316AA32B6469D9670B6A81B7C2409839Axmbalnx07ciscocom_--

From rgandhi@cisco.com  Wed Sep 12 10:23:58 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 CBF8821F859B for ; Wed, 12 Sep 2012 10:23:58 -0700 (PDT)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU4L1MXabfbm for ; Wed, 12 Sep 2012 10:23:58 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1810A21F8587 for ; Wed, 12 Sep 2012 10:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6263; q=dns/txt; s=iport; t=1347470637; x=1348680237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kredHL3Sx9tqvvzOHc3xZ+pNE/Ttk6Y1Q+//MrJhWZ0=; b=ETD03rnT3Jj+iLBf+fKgIw7QyfD5/bELIzzR1RpdTxmEAIC8bxsSy5fG 32sn5q0e9+hMZvMELA2kTkWLHOuMCFGEsKf/KJbWSepv9PR/sA41AJKhr uNKJrJMijAqOlK4obPOtwhkyu65nPv1/mfGJ9vND/xcgXfqP3qNS/FtzO Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAHDEUFCtJV2a/2dsb2JhbABFu06BB4IgAQEBAwESARQTPwwEAgEIDgMEAQEBChQJBzIUCQgCBA4FCBMHh2UGnAigLosQhWJgA6QVgWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="120882613"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2012 17:23:56 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8CHNuaG010625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 17:23:56 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 12:23:56 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Lou Berger 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObAAASWMgAAIiywQ
Date: Wed, 12 Sep 2012 17:23:55 +0000
Message-ID: 
References:  <50461FB2.7080707@labn.net>  <50508AC9.5000709@labn.net>  <5050B4CD.10500@labn.net>
In-Reply-To: <5050B4CD.10500@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005
x-tm-as-result: No--55.522000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Sep 2012 17:23:59 -0000

Hi Lou, Fei, WG,

Thanks for your replies. May I propose following text to cover this case? T=
his allows the mid-point solution which has advantages but given the additi=
onal complexity can be optional.

Please advise.=20

"When an initiating ingress node is provisioned with "Single Sided Associat=
ed Bidirectional LSPs" and wishes to control both forward and reverse  LSPs=
 by adding "REVERSE_LSP" object, the ingress node SHOULD know the signaling=
 (path) errors on the reverse LSP.  A transit node MAY be requested to noti=
fy the signaling error on the reverse LSP by using the NOTIFY message and p=
rocedures defined in RFC[3473]. In the absence of such notification request=
, egress node SHOULD relay the received signaling error on the reverse LSP =
to the ingress node using the NOTIFY message."

Thanks,
Rakesh


-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Wednesday, September 12, 2012 12:14 PM
To: Rakesh Gandhi (rgandhi)
Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext=
-associated-lsp-04.txt

Rakesh,


On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou.
>=20
> Are we ok in general to use NOTIFY message [RFC3473] for this?

I'm not speaking for the WG, as noted my comments were as a participant.
 IMO you'll need to fully document the proposal, perhaps discuss alternativ=
es considered, and then ask the WG for concurrence.

>=20
> One advantage with the mid-point sending notification for the reverse=20
> LSP is that signaling error propagation time
> (mid->egress-node->ingress-node) is significantly reduced (to
> mid->ingress-node) which may be preferred in some cases.

>From my (personal) perspective, the added complexity isn't worth the effort=
.  Of course, a detailed proposal may show otherwise.

Lou

>=20
> Thanks,
> Rakesh
>=20
>=20
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, September 12, 2012 9:15 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: Re: Question on LSP control in=20
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>=20
> Rakesh,
> 	Speaking as WG participant, I haven't thought about this too much so may=
 be off, but method 3 seems to be most consistent with the usage of the REV=
ERSE_LSP Object in the path message.  Perhaps consider using the REVERSE_LS=
P Object in the upstream/Resv direction to allow the egress/tail to provide=
 the ingress/head with arbitrary information....
>=20
> Lou
>=20
> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
>> Hi WG,
>>
>> Any thoughts on the following proposal?
>>
>> Thanks,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Rakesh Gandhi (rgandhi)
>> Sent: Tuesday, September 04, 2012 1:36 PM
>> To: 'Lou Berger'
>> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
>> Subject: RE: Question on LSP control in=20
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>
>> Thanks Lou for your reply.
>>
>> RFC 3473 defines procedures for NOTIFY request and reply. We could use t=
his for reverse LSP signaling error notification to the initiating ingress =
node.
>>
>>  ::=3D  [] [ [=
 | ] ... ]
>>   =20
>>    >
>>
>> There are multiple ways we can use the NOTIFY message.
>>
>> Method 1 - Mid-point aware with Path message request:
>> When an egress node receives a Path message with REVERSE_LSP object, the=
 node will insert NOTIFY_REQ message in the reverse LSP path message with n=
ode ID of the initiating ingress node. A mid-point node will send  a copy o=
f the signaling error to the initiating node using the NOTIFY message.
>>
>> IPv4 Notify Request Object
>>    IPv4 Notify Node Address: 32 bits
>>       The IP address of the node that should be notified when generating=
 an error message.
>>
>> Method 2 - Mid-point aware with Resv message request:
>> When an initiating ingress node receives a Path message for a reverse LS=
P, the node will insert NOTIFY_REQ message in the reverse LSP Resv message =
with its own node ID. A mid-point node will send a copy of the signaling er=
ror to the initiating node using the NOTIFY message.
>>
>> Method 3 - Tail-end relaying :
>> When an egress node receives a Path message with REVERSE_LSP object, the=
 node will relay the received signaling error message on the reverse LSP to=
 the initializing ingress node. The egress node copies the received "ERROR_=
SPEC" object into a NOTIFY [RFC3473, section 4.3] message and signals it to=
 the ingress node. In this case, NOTIFY_REQ message is not required.=20
>>
>> Please advise your thoughts.
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, September 04, 2012 11:35 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
>> Subject: Re: Question on LSP control in=20
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> As I read the current rev, no such notification mechanism is specified.
>>  Looks like you get to propose one!
>>
>> Lou (as WG participant).
>>
>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Lou, Fei,
>>>
>>> When an (originating) ingress node is provisioned with "5 (TBD)  Single=
 Sided Associated Bidirectional LSPs  (A)" and wishes to control both forwa=
rd and reverse  LSPs by adding "REVERSE_LSP" object, I would think that the=
 ingress node needs to know about the signaling (path) errors (such as soft=
 preemption or admission failure) on the reverse LSP.  Is there any text so=
mewhere in an RFC/draft that describes how a mid-point node can send the si=
gnaling (path) error to the originating ingress node for the reverse LSP? I=
s there an assumption to use RSVP_NOTIFY message? Sorry if I had missed any=
 previous discussion on this topic.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>=20
>=20
>=20
>=20

From zhang.fei3@zte.com.cn  Wed Sep 12 17:41: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 D916321F8652 for ; Wed, 12 Sep 2012 17:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.976
X-Spam-Level: 
X-Spam-Status: No, score=-96.976 tagged_above=-999 required=5 tests=[AWL=-1.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btsX+UYaiVM2 for ; Wed, 12 Sep 2012 17:41:56 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DBD0A21F8620 for ; Wed, 12 Sep 2012 17:41:55 -0700 (PDT)
Received: from [10.30.3.20] by mx5.zte.com.cn with surfront esmtp id 232552685115152(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO);  Thu, 13 Sep 2012 08:34:22 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q8D0fjSA078393; Thu, 13 Sep 2012 08:41:45 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: 
To: "Rakesh Gandhi (rgandhi)" 
MIME-Version: 1.0
X-KeepSent: FDA18ACB:EDA82B53-48257A78:0002692C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhang.fei3@zte.com.cn
Date: Thu, 13 Sep 2012 08:41:39 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-13 08:41:38, Serialize complete at 2012-09-13 08:41:38
Content-Type: multipart/alternative; boundary="=_alternative 0003D24948257A78_="
X-MAIL: mse01.zte.com.cn q8D0fjSA078393
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 00:41:58 -0000

This is a multipart message in MIME format.
--=_alternative 0003D24948257A78_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgUmFrZXNoIA0KDQogSW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBub3RpZmljYXRpb24gcmVxdWVz
dCwgZWdyZXNzIG5vZGUgU0hPVUxEIHJlbGF5IHRoZSANCnJlY2VpdmVkIHNpZ25hbGluZyBlcnJv
ciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mgbm9kZSB1c2luZyB0aGUgDQpOT1RJ
RlkgbWVzc2FnZS4iDQoNCjxmZWk+ICJOb3RlIHRoYXQgYSBOb3RpZnkgbWVzc2FnZSBNVVNUIE5P
VCBiZSBnZW5lcmF0ZWQgdW5sZXNzIGFuIA0KYXBwcm9wcmlhdGUgTm90aWZ5IFJlcXVlc3Qgb2Jq
ZWN0IGhhcyBiZWVuIHJlY2VpdmVkLiINCg0KICAgICAgIElmIG15IHVuZGVyc3RhbmRpbmcgaXMg
Y29ycmVjdCwgeW91ciBwcm9wb3NlZCByZWxheSBtZWNoYW5pc20gZG9lcyANCm5vdCBkZXBlbmQg
b24gdGhlIGV4aXN0aW5nIG9mIHRoZSBOb3RpZnkgUmVxdWVzdCBvYmplY3QsIHdoaWNoIG1heSAN
CmNvbmZsaWN0IHdpdGggdGhlDQogICAgICAgZGVzY3JpcGl0b25zIGluIFJGQzM0NzMuIA0KDQog
ICAgICAgRG8geW91IHdhbnQgdG8gY2hhbmdlIHRoaXMgb3IgZG8gSSBoYXZlIHNvbWUgbWlzdW5k
ZXJzdGFuZGluZz8gDQoNCg0KUmVnYXJkcw0KDQpGZWkNCg0KDQoNCiJSYWtlc2ggR2FuZGhpIChy
Z2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPiANCjIwMTItMDktMTMgMDE6MjMNCg0KytW8/sjL
DQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0Ks63LzQ0KInpoYW5nLmZlaTNAenRlLmNv
bS5jbiIgPHpoYW5nLmZlaTNAenRlLmNvbS5jbj4sICJjY2FtcEBpZXRmLm9yZyIgDQo8Y2NhbXBA
aWV0Zi5vcmc+DQrW98ziDQpSRTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gDQpkcmFmdC1p
ZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KDQoN
Cg0KDQoNCkhpIExvdSwgRmVpLCBXRywNCg0KVGhhbmtzIGZvciB5b3VyIHJlcGxpZXMuIE1heSBJ
IHByb3Bvc2UgZm9sbG93aW5nIHRleHQgdG8gY292ZXIgdGhpcyBjYXNlPyANClRoaXMgYWxsb3dz
IHRoZSBtaWQtcG9pbnQgc29sdXRpb24gd2hpY2ggaGFzIGFkdmFudGFnZXMgYnV0IGdpdmVuIHRo
ZSANCmFkZGl0aW9uYWwgY29tcGxleGl0eSBjYW4gYmUgb3B0aW9uYWwuDQoNClBsZWFzZSBhZHZp
c2UuIA0KDQoiV2hlbiBhbiBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3
aXRoICJTaW5nbGUgU2lkZWQgDQpBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyIgYW5kIHdp
c2hlcyB0byBjb250cm9sIGJvdGggZm9yd2FyZCBhbmQgDQpyZXZlcnNlICBMU1BzIGJ5IGFkZGlu
ZyAiUkVWRVJTRV9MU1AiIG9iamVjdCwgdGhlIGluZ3Jlc3Mgbm9kZSBTSE9VTEQga25vdyANCnRo
ZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyBvbiB0aGUgcmV2ZXJzZSBMU1AuICBBIHRyYW5zaXQg
bm9kZSBNQVkgYmUgDQpyZXF1ZXN0ZWQgdG8gbm90aWZ5IHRoZSBzaWduYWxpbmcgZXJyb3Igb24g
dGhlIHJldmVyc2UgTFNQIGJ5IHVzaW5nIHRoZSANCk5PVElGWSBtZXNzYWdlIGFuZCBwcm9jZWR1
cmVzIGRlZmluZWQgaW4gUkZDWzM0NzNdLiBJbiB0aGUgYWJzZW5jZSBvZiBzdWNoIA0Kbm90aWZp
Y2F0aW9uIHJlcXVlc3QsIGVncmVzcyBub2RlIFNIT1VMRCByZWxheSB0aGUgcmVjZWl2ZWQgc2ln
bmFsaW5nIA0KZXJyb3Igb24gdGhlIHJldmVyc2UgTFNQIHRvIHRoZSBpbmdyZXNzIG5vZGUgdXNp
bmcgdGhlIE5PVElGWSBtZXNzYWdlLiINCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4u
bmV0XSANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDEyOjE0IFBNDQpUbzog
UmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCkNjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IGNjYW1w
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gDQpkcmFm
dC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0K
UmFrZXNoLA0KDQoNCk9uIDkvMTIvMjAxMiAxMTo1MiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRo
aSkgd3JvdGU6DQo+IFRoYW5rcyBMb3UuDQo+IA0KPiBBcmUgd2Ugb2sgaW4gZ2VuZXJhbCB0byB1
c2UgTk9USUZZIG1lc3NhZ2UgW1JGQzM0NzNdIGZvciB0aGlzPw0KDQpJJ20gbm90IHNwZWFraW5n
IGZvciB0aGUgV0csIGFzIG5vdGVkIG15IGNvbW1lbnRzIHdlcmUgYXMgYSBwYXJ0aWNpcGFudC4N
CiBJTU8geW91J2xsIG5lZWQgdG8gZnVsbHkgZG9jdW1lbnQgdGhlIHByb3Bvc2FsLCBwZXJoYXBz
IGRpc2N1c3MgDQphbHRlcm5hdGl2ZXMgY29uc2lkZXJlZCwgYW5kIHRoZW4gYXNrIHRoZSBXRyBm
b3IgY29uY3VycmVuY2UuDQoNCj4gDQo+IE9uZSBhZHZhbnRhZ2Ugd2l0aCB0aGUgbWlkLXBvaW50
IHNlbmRpbmcgbm90aWZpY2F0aW9uIGZvciB0aGUgcmV2ZXJzZSANCj4gTFNQIGlzIHRoYXQgc2ln
bmFsaW5nIGVycm9yIHByb3BhZ2F0aW9uIHRpbWUNCj4gKG1pZC0+ZWdyZXNzLW5vZGUtPmluZ3Jl
c3Mtbm9kZSkgaXMgc2lnbmlmaWNhbnRseSByZWR1Y2VkICh0bw0KPiBtaWQtPmluZ3Jlc3Mtbm9k
ZSkgd2hpY2ggbWF5IGJlIHByZWZlcnJlZCBpbiBzb21lIGNhc2VzLg0KDQpGcm9tIG15IChwZXJz
b25hbCkgcGVyc3BlY3RpdmUsIHRoZSBhZGRlZCBjb21wbGV4aXR5IGlzbid0IHdvcnRoIHRoZSAN
CmVmZm9ydC4gIE9mIGNvdXJzZSwgYSBkZXRhaWxlZCBwcm9wb3NhbCBtYXkgc2hvdyBvdGhlcndp
c2UuDQoNCkxvdQ0KDQo+IA0KPiBUaGFua3MsDQo+IFJha2VzaA0KPiANCj4gDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxh
Ym4ubmV0XQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA5OjE1IEFNDQo+
IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNu
OyBjY2FtcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wg
aW4gDQo+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw
LTA0LnR4dA0KPiANCj4gUmFrZXNoLA0KPiAgICAgICAgICAgICAgICBTcGVha2luZyBhcyBXRyBw
YXJ0aWNpcGFudCwgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQgdGhpcyANCnRvbyBtdWNoIHNvIG1h
eSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBtb3N0IGNvbnNpc3RlbnQgd2l0aCB0
aGUgDQp1c2FnZSBvZiB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSBwYXRoIG1lc3NhZ2Uu
ICBQZXJoYXBzIGNvbnNpZGVyIA0KdXNpbmcgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUg
dXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24gdG8gYWxsb3cgdGhlIA0KZWdyZXNzL3RhaWwgdG8gcHJv
dmlkZSB0aGUgaW5ncmVzcy9oZWFkIHdpdGggYXJiaXRyYXJ5IGluZm9ybWF0aW9uLi4uLg0KPiAN
Cj4gTG91DQo+IA0KPiBPbiA5LzExLzIwMTIgOToyMiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRo
aSkgd3JvdGU6DQo+PiBIaSBXRywNCj4+DQo+PiBBbnkgdGhvdWdodHMgb24gdGhlIGZvbGxvd2lu
ZyBwcm9wb3NhbD8NCj4+DQo+PiBUaGFua3MsDQo+PiBSYWtlc2gNCj4+DQo+Pg0KPj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+
PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTIgMTozNiBQTQ0KPj4gVG86ICdMb3Ug
QmVyZ2VyJw0KPj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbjsgY2NhbXBAaWV0Zi5vcmcNCj4+
IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiANCj4+IGRyYWZ0LWlldGYt
Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4NCj4+DQo+
PiBUaGFua3MgTG91IGZvciB5b3VyIHJlcGx5Lg0KPj4NCj4+IFJGQyAzNDczIGRlZmluZXMgcHJv
Y2VkdXJlcyBmb3IgTk9USUZZIHJlcXVlc3QgYW5kIHJlcGx5LiBXZSBjb3VsZCB1c2UgDQp0aGlz
IGZvciByZXZlcnNlIExTUCBzaWduYWxpbmcgZXJyb3Igbm90aWZpY2F0aW9uIHRvIHRoZSBpbml0
aWF0aW5nIA0KaW5ncmVzcyBub2RlLg0KPj4NCj4+IDxOb3RpZnkgbWVzc2FnZT4gOjo9IDxDb21t
b24gSGVhZGVyPiBbPElOVEVHUklUWT5dIFsgWzxNRVNTQUdFX0lEX0FDSz4gDQp8IDxNRVNTQUdF
X0lEX05BQ0s+XSAuLi4gXQ0KPj4gPEVSUk9SX1NQRUM+IA0KPj4gPG5vdGlmeSBzZXNzaW9uIGxp
c3QgOjo9IDx1cHN0cmVhbSBzZXNzaW9uPiA8ZG93bnN0cmVhbSBzZXNzaW9uPiAgPg0KPj4NCj4+
IFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHdlIGNhbiB1c2UgdGhlIE5PVElGWSBtZXNzYWdlLg0K
Pj4NCj4+IE1ldGhvZCAxIC0gTWlkLXBvaW50IGF3YXJlIHdpdGggUGF0aCBtZXNzYWdlIHJlcXVl
c3Q6DQo+PiBXaGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIHdpdGgg
UkVWRVJTRV9MU1Agb2JqZWN0LCANCnRoZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVz
c2FnZSBpbiB0aGUgcmV2ZXJzZSBMU1AgcGF0aCBtZXNzYWdlIA0Kd2l0aCBub2RlIElEIG9mIHRo
ZSBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZS4gQSBtaWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQgIGEg
DQpjb3B5IG9mIHRoZSBzaWduYWxpbmcgZXJyb3IgdG8gdGhlIGluaXRpYXRpbmcgbm9kZSB1c2lu
ZyB0aGUgTk9USUZZIA0KbWVzc2FnZS4NCj4+DQo+PiBJUHY0IE5vdGlmeSBSZXF1ZXN0IE9iamVj
dA0KPj4gICAgSVB2NCBOb3RpZnkgTm9kZSBBZGRyZXNzOiAzMiBiaXRzDQo+PiAgICAgICBUaGUg
SVAgYWRkcmVzcyBvZiB0aGUgbm9kZSB0aGF0IHNob3VsZCBiZSBub3RpZmllZCB3aGVuIA0KZ2Vu
ZXJhdGluZyBhbiBlcnJvciBtZXNzYWdlLg0KPj4NCj4+IE1ldGhvZCAyIC0gTWlkLXBvaW50IGF3
YXJlIHdpdGggUmVzdiBtZXNzYWdlIHJlcXVlc3Q6DQo+PiBXaGVuIGFuIGluaXRpYXRpbmcgaW5n
cmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIGZvciBhIHJldmVyc2UgDQpMU1AsIHRo
ZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUgcmV2ZXJzZSBMU1Ag
UmVzdiANCm1lc3NhZ2Ugd2l0aCBpdHMgb3duIG5vZGUgSUQuIEEgbWlkLXBvaW50IG5vZGUgd2ls
bCBzZW5kIGEgY29weSBvZiB0aGUgDQpzaWduYWxpbmcgZXJyb3IgdG8gdGhlIGluaXRpYXRpbmcg
bm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UuDQo+Pg0KPj4gTWV0aG9kIDMgLSBUYWlsLWVu
ZCByZWxheWluZyA6DQo+PiBXaGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNz
YWdlIHdpdGggUkVWRVJTRV9MU1Agb2JqZWN0LCANCnRoZSBub2RlIHdpbGwgcmVsYXkgdGhlIHJl
Y2VpdmVkIHNpZ25hbGluZyBlcnJvciBtZXNzYWdlIG9uIHRoZSByZXZlcnNlIA0KTFNQIHRvIHRo
ZSBpbml0aWFsaXppbmcgaW5ncmVzcyBub2RlLiBUaGUgZWdyZXNzIG5vZGUgY29waWVzIHRoZSBy
ZWNlaXZlZCANCiJFUlJPUl9TUEVDIiBvYmplY3QgaW50byBhIE5PVElGWSBbUkZDMzQ3Mywgc2Vj
dGlvbiA0LjNdIG1lc3NhZ2UgYW5kIA0Kc2lnbmFscyBpdCB0byB0aGUgaW5ncmVzcyBub2RlLiBJ
biB0aGlzIGNhc2UsIE5PVElGWV9SRVEgbWVzc2FnZSBpcyBub3QgDQpyZXF1aXJlZC4gDQo+Pg0K
Pj4gUGxlYXNlIGFkdmlzZSB5b3VyIHRob3VnaHRzLg0KPj4NCj4+IFRoYW5rcywNCj4+IFJha2Vz
aA0KPj4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IExv
dSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPj4gU2VudDogVHVlc2RheSwgU2Vw
dGVtYmVyIDA0LCAyMDEyIDExOjM1IEFNDQo+PiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkN
Cj4+IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IGNjYW1wQGlldGYub3JnDQo+PiBTdWJqZWN0
OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gDQo+PiBkcmFmdC1pZXRmLWNjYW1wLW1w
bHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4+DQo+PiBBcyBJIHJlYWQg
dGhlIGN1cnJlbnQgcmV2LCBubyBzdWNoIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gaXMgc3BlY2lm
aWVkLg0KPj4gIExvb2tzIGxpa2UgeW91IGdldCB0byBwcm9wb3NlIG9uZSENCj4+DQo+PiBMb3Ug
KGFzIFdHIHBhcnRpY2lwYW50KS4NCj4+DQo+PiBPbiA4LzMxLzIwMTIgOTo0OSBBTSwgUmFrZXNo
IEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+Pj4gSGkgTG91LCBGZWksDQo+Pj4NCj4+PiBXaGVu
IGFuIChvcmlnaW5hdGluZykgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggIjUgKFRC
RCkgU2luZ2xlIA0KU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMgIChBKSIgYW5k
IHdpc2hlcyB0byBjb250cm9sIGJvdGggDQpmb3J3YXJkIGFuZCByZXZlcnNlICBMU1BzIGJ5IGFk
ZGluZyAiUkVWRVJTRV9MU1AiIG9iamVjdCwgSSB3b3VsZCB0aGluayANCnRoYXQgdGhlIGluZ3Jl
c3Mgbm9kZSBuZWVkcyB0byBrbm93IGFib3V0IHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyAN
CihzdWNoIGFzIHNvZnQgcHJlZW1wdGlvbiBvciBhZG1pc3Npb24gZmFpbHVyZSkgb24gdGhlIHJl
dmVyc2UgTFNQLiAgSXMgDQp0aGVyZSBhbnkgdGV4dCBzb21ld2hlcmUgaW4gYW4gUkZDL2RyYWZ0
IHRoYXQgZGVzY3JpYmVzIGhvdyBhIG1pZC1wb2ludCANCm5vZGUgY2FuIHNlbmQgdGhlIHNpZ25h
bGluZyAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nIGluZ3Jlc3Mgbm9kZSANCmZvciB0
aGUgcmV2ZXJzZSBMU1A/IElzIHRoZXJlIGFuIGFzc3VtcHRpb24gdG8gdXNlIFJTVlBfTk9USUZZ
IG1lc3NhZ2U/IA0KU29ycnkgaWYgSSBoYWQgbWlzc2VkIGFueSBwcmV2aW91cyBkaXNjdXNzaW9u
IG9uIHRoaXMgdG9waWMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gUmFrZXNoDQo+Pj4NCj4+Pg0K
Pj4+DQo+Pj4NCj4+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4gDQo+IA0KPiANCj4gDQoNCg0KDQo=
--=_alternative 0003D24948257A78_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5IaSBSYWtlc2ggPC9mb250Pg0KPGJyPg0K
PGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7SW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBub3RpZmlj
YXRpb24gcmVxdWVzdCwNCmVncmVzcyBub2RlIFNIT1VMRCByZWxheSB0aGUgcmVjZWl2ZWQgc2ln
bmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNlIExTUA0KdG8gdGhlIGluZ3Jlc3Mgbm9kZSB1c2lu
ZyB0aGUgTk9USUZZIG1lc3NhZ2UuJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxm
b250IHNpemU9MiBjb2xvcj1ibHVlPiZsdDtmZWkmZ3Q7ICZxdW90O05vdGUgdGhhdCBhIE5vdGlm
eSBtZXNzYWdlDQpNVVNUIE5PVCBiZSBnZW5lcmF0ZWQgdW5sZXNzIGFuIGFwcHJvcHJpYXRlIE5v
dGlmeSBSZXF1ZXN0IG9iamVjdCBoYXMgYmVlbg0KcmVjZWl2ZWQuJnF1b3Q7PC9mb250PjwvdHQ+
DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwO0lmIG15IHVuZGVyc3RhbmRpbmcNCmlzIGNvcnJlY3QsIHlvdXIgcHJvcG9zZWQg
cmVsYXkgbWVjaGFuaXNtIGRvZXMgbm90IGRlcGVuZCBvbiB0aGUgZXhpc3RpbmcNCm9mIHRoZSBO
b3RpZnkgUmVxdWVzdCBvYmplY3QsIHdoaWNoIG1heSBjb25mbGljdCB3aXRoIHRoZTwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT4mbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtkZXNjcmlwaXRvbnMNCmluIFJGQzM0NzMuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJy
Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtE
byB5b3Ugd2FudA0KdG8gY2hhbmdlIHRoaXMgb3IgZG8gSSBoYXZlIHNvbWUgbWlzdW5kZXJzdGFu
ZGluZz8gJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj5SZWdhcmRzPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5GZWk8L2Zv
bnQ+PC90dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln
bj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4m
cXVvdDtSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZxdW90Ow0KJmx0O3JnYW5kaGlAY2lzY28uY29t
Jmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTIt
MDktMTMgMDE6MjM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8
dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i
c2Fucy1zZXJpZiI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2ZvbnQ+DQo8
dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPiZxdW90O3poYW5nLmZlaTNAenRlLmNvbS5jbiZxdW90OyAmbHQ7emhhbmcuZmVp
M0B6dGUuY29tLmNuJmd0OywNCiZxdW90O2NjYW1wQGlldGYub3JnJnF1b3Q7ICZsdDtjY2FtcEBp
ZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln
aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+
PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJv
bCBpbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0w
NC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk
Pg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPkhpIExvdSwgRmVpLCBXRyw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIgcmVwbGll
cy4gTWF5IEkgcHJvcG9zZSBmb2xsb3dpbmcgdGV4dCB0byBjb3ZlciB0aGlzIGNhc2U/DQpUaGlz
IGFsbG93cyB0aGUgbWlkLXBvaW50IHNvbHV0aW9uIHdoaWNoIGhhcyBhZHZhbnRhZ2VzIGJ1dCBn
aXZlbiB0aGUgYWRkaXRpb25hbA0KY29tcGxleGl0eSBjYW4gYmUgb3B0aW9uYWwuPGJyPg0KPGJy
Pg0KUGxlYXNlIGFkdmlzZS4gPGJyPg0KPGJyPg0KJnF1b3Q7V2hlbiBhbiBpbml0aWF0aW5nIGlu
Z3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICZxdW90O1NpbmdsZQ0KU2lkZWQgQXNzb2Np
YXRlZCBCaWRpcmVjdGlvbmFsIExTUHMmcXVvdDsgYW5kIHdpc2hlcyB0byBjb250cm9sIGJvdGgg
Zm9yd2FyZA0KYW5kIHJldmVyc2UgJm5ic3A7TFNQcyBieSBhZGRpbmcgJnF1b3Q7UkVWRVJTRV9M
U1AmcXVvdDsgb2JqZWN0LCB0aGUgaW5ncmVzcw0Kbm9kZSBTSE9VTEQga25vdyB0aGUgc2lnbmFs
aW5nIChwYXRoKSBlcnJvcnMgb24gdGhlIHJldmVyc2UgTFNQLiAmbmJzcDtBDQp0cmFuc2l0IG5v
ZGUgTUFZIGJlIHJlcXVlc3RlZCB0byBub3RpZnkgdGhlIHNpZ25hbGluZyBlcnJvciBvbiB0aGUg
cmV2ZXJzZQ0KTFNQIGJ5IHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZSBhbmQgcHJvY2VkdXJlcyBk
ZWZpbmVkIGluIFJGQ1szNDczXS4gSW4NCnRoZSBhYnNlbmNlIG9mIHN1Y2ggbm90aWZpY2F0aW9u
IHJlcXVlc3QsIGVncmVzcyBub2RlIFNIT1VMRCByZWxheSB0aGUNCnJlY2VpdmVkIHNpZ25hbGlu
ZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mgbm9kZSB1c2luZyB0aGUN
Ck5PVElGWSBtZXNzYWdlLiZxdW90Ozxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSYWtlc2g8YnI+
DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IExvdSBC
ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSA8YnI+DQpTZW50OiBXZWRuZXNkYXksIFNl
cHRlbWJlciAxMiwgMjAxMiAxMjoxNCBQTTxicj4NClRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhp
KTxicj4NCkNjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IGNjYW1wQGlldGYub3JnPGJyPg0KU3Vi
amVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIGRyYWZ0LWlldGYtY2NhbXAtbXBs
cy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCjxicj4NClJha2VzaCw8
YnI+DQo8YnI+DQo8YnI+DQpPbiA5LzEyLzIwMTIgMTE6NTIgQU0sIFJha2VzaCBHYW5kaGkgKHJn
YW5kaGkpIHdyb3RlOjxicj4NCiZndDsgVGhhbmtzIExvdS48YnI+DQomZ3Q7IDxicj4NCiZndDsg
QXJlIHdlIG9rIGluIGdlbmVyYWwgdG8gdXNlIE5PVElGWSBtZXNzYWdlIFtSRkMzNDczXSBmb3Ig
dGhpcz88YnI+DQo8YnI+DQpJJ20gbm90IHNwZWFraW5nIGZvciB0aGUgV0csIGFzIG5vdGVkIG15
IGNvbW1lbnRzIHdlcmUgYXMgYSBwYXJ0aWNpcGFudC48YnI+DQogSU1PIHlvdSdsbCBuZWVkIHRv
IGZ1bGx5IGRvY3VtZW50IHRoZSBwcm9wb3NhbCwgcGVyaGFwcyBkaXNjdXNzIGFsdGVybmF0aXZl
cw0KY29uc2lkZXJlZCwgYW5kIHRoZW4gYXNrIHRoZSBXRyBmb3IgY29uY3VycmVuY2UuPGJyPg0K
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uZSBhZHZhbnRhZ2Ugd2l0aCB0aGUgbWlkLXBvaW50IHNl
bmRpbmcgbm90aWZpY2F0aW9uIGZvciB0aGUgcmV2ZXJzZQ0KPGJyPg0KJmd0OyBMU1AgaXMgdGhh
dCBzaWduYWxpbmcgZXJyb3IgcHJvcGFnYXRpb24gdGltZTxicj4NCiZndDsgKG1pZC0mZ3Q7ZWdy
ZXNzLW5vZGUtJmd0O2luZ3Jlc3Mtbm9kZSkgaXMgc2lnbmlmaWNhbnRseSByZWR1Y2VkICh0bzxi
cj4NCiZndDsgbWlkLSZndDtpbmdyZXNzLW5vZGUpIHdoaWNoIG1heSBiZSBwcmVmZXJyZWQgaW4g
c29tZSBjYXNlcy48YnI+DQo8YnI+DQpGcm9tIG15IChwZXJzb25hbCkgcGVyc3BlY3RpdmUsIHRo
ZSBhZGRlZCBjb21wbGV4aXR5IGlzbid0IHdvcnRoIHRoZSBlZmZvcnQuDQombmJzcDtPZiBjb3Vy
c2UsIGEgZGV0YWlsZWQgcHJvcG9zYWwgbWF5IHNob3cgb3RoZXJ3aXNlLjxicj4NCjxicj4NCkxv
dTxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0OyBSYWtlc2g8YnI+
DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi
cj4NCiZndDsgRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPGJyPg0K
Jmd0OyBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA5OjE1IEFNPGJyPg0KJmd0
OyBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSk8YnI+DQomZ3Q7IENjOiB6aGFuZy5mZWkzQHp0
ZS5jb20uY247IGNjYW1wQGlldGYub3JnPGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogUXVlc3Rpb24g
b24gTFNQIGNvbnRyb2wgaW4gPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2
cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmFrZXNo
LDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtTcGVha2luZw0KYXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0
aG91Z2h0IGFib3V0IHRoaXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwNCmJ1dCBtZXRob2QgMyBz
ZWVtcyB0byBiZSBtb3N0IGNvbnNpc3RlbnQgd2l0aCB0aGUgdXNhZ2Ugb2YgdGhlIFJFVkVSU0Vf
TFNQDQpPYmplY3QgaW4gdGhlIHBhdGggbWVzc2FnZS4gJm5ic3A7UGVyaGFwcyBjb25zaWRlciB1
c2luZyB0aGUgUkVWRVJTRV9MU1ANCk9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rp
b24gdG8gYWxsb3cgdGhlIGVncmVzcy90YWlsIHRvIHByb3ZpZGUNCnRoZSBpbmdyZXNzL2hlYWQg
d2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24uLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExvdTxi
cj4NCiZndDsgPGJyPg0KJmd0OyBPbiA5LzExLzIwMTIgOToyMiBBTSwgUmFrZXNoIEdhbmRoaSAo
cmdhbmRoaSkgd3JvdGU6PGJyPg0KJmd0OyZndDsgSGkgV0csPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyBBbnkgdGhvdWdodHMgb24gdGhlIGZvbGxvd2luZyBwcm9wb3NhbD88YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyBSYWtlc2g8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKTxicj4NCiZndDsm
Z3Q7IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNPGJyPg0KJmd0OyZn
dDsgVG86ICdMb3UgQmVyZ2VyJzxicj4NCiZndDsmZ3Q7IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20u
Y247IGNjYW1wQGlldGYub3JnPGJyPg0KJmd0OyZndDsgU3ViamVjdDogUkU6IFF1ZXN0aW9uIG9u
IExTUCBjb250cm9sIGluIDxicj4NCiZndDsmZ3Q7IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y
c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MgTG91IGZvciB5b3VyIHJlcGx5Ljxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgUkZDIDM0NzMgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJRlkgcmVx
dWVzdCBhbmQgcmVwbHkuIFdlIGNvdWxkDQp1c2UgdGhpcyBmb3IgcmV2ZXJzZSBMU1Agc2lnbmFs
aW5nIGVycm9yIG5vdGlmaWNhdGlvbiB0byB0aGUgaW5pdGlhdGluZw0KaW5ncmVzcyBub2RlLjxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmx0O05vdGlmeSBtZXNzYWdlJmd0OyA6Oj0gJmx0
O0NvbW1vbiBIZWFkZXImZ3Q7IFsmbHQ7SU5URUdSSVRZJmd0O10NClsgWyZsdDtNRVNTQUdFX0lE
X0FDSyZndDsgfCAmbHQ7TUVTU0FHRV9JRF9OQUNLJmd0O10gLi4uIF08YnI+DQomZ3Q7Jmd0OyAm
bHQ7RVJST1JfU1BFQyZndDsgJm5ic3A7IDxicj4NCiZndDsmZ3Q7ICZsdDtub3RpZnkgc2Vzc2lv
biBsaXN0IDo6PSAmbHQ7dXBzdHJlYW0gc2Vzc2lvbiZndDsgJmx0O2Rvd25zdHJlYW0NCnNlc3Np
b24mZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZXJlIGFyZSBt
dWx0aXBsZSB3YXlzIHdlIGNhbiB1c2UgdGhlIE5PVElGWSBtZXNzYWdlLjxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgTWV0aG9kIDEgLSBNaWQtcG9pbnQgYXdhcmUgd2l0aCBQYXRoIG1lc3Nh
Z2UgcmVxdWVzdDo8YnI+DQomZ3Q7Jmd0OyBXaGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVzIGEg
UGF0aCBtZXNzYWdlIHdpdGggUkVWRVJTRV9MU1Agb2JqZWN0LA0KdGhlIG5vZGUgd2lsbCBpbnNl
cnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNlIExTUCBwYXRoIG1lc3NhZ2UNCndp
dGggbm9kZSBJRCBvZiB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUuIEEgbWlkLXBvaW50IG5v
ZGUgd2lsbCBzZW5kDQombmJzcDthIGNvcHkgb2YgdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUg
aW5pdGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkNCm1lc3NhZ2UuPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyBJUHY0IE5vdGlmeSBSZXF1ZXN0IE9iamVjdDxicj4NCiZndDsmZ3Q7ICZu
YnNwOyAmbmJzcDtJUHY0IE5vdGlmeSBOb2RlIEFkZHJlc3M6IDMyIGJpdHM8YnI+DQomZ3Q7Jmd0
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgSVAgYWRkcmVzcyBvZiB0aGUgbm9kZSB0aGF0IHNo
b3VsZCBiZQ0Kbm90aWZpZWQgd2hlbiBnZW5lcmF0aW5nIGFuIGVycm9yIG1lc3NhZ2UuPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBNZXRob2QgMiAtIE1pZC1wb2ludCBhd2FyZSB3aXRoIFJl
c3YgbWVzc2FnZSByZXF1ZXN0Ojxicj4NCiZndDsmZ3Q7IFdoZW4gYW4gaW5pdGlhdGluZyBpbmdy
ZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2UgZm9yIGENCnJldmVyc2UgTFNQLCB0aGUg
bm9kZSB3aWxsIGluc2VydCBOT1RJRllfUkVRIG1lc3NhZ2UgaW4gdGhlIHJldmVyc2UgTFNQDQpS
ZXN2IG1lc3NhZ2Ugd2l0aCBpdHMgb3duIG5vZGUgSUQuIEEgbWlkLXBvaW50IG5vZGUgd2lsbCBz
ZW5kIGEgY29weSBvZg0KdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGluZyBub2Rl
IHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1l
dGhvZCAzIC0gVGFpbC1lbmQgcmVsYXlpbmcgOjxicj4NCiZndDsmZ3Q7IFdoZW4gYW4gZWdyZXNz
IG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsDQp0
aGUgbm9kZSB3aWxsIHJlbGF5IHRoZSByZWNlaXZlZCBzaWduYWxpbmcgZXJyb3IgbWVzc2FnZSBv
biB0aGUgcmV2ZXJzZQ0KTFNQIHRvIHRoZSBpbml0aWFsaXppbmcgaW5ncmVzcyBub2RlLiBUaGUg
ZWdyZXNzIG5vZGUgY29waWVzIHRoZSByZWNlaXZlZA0KJnF1b3Q7RVJST1JfU1BFQyZxdW90OyBv
YmplY3QgaW50byBhIE5PVElGWSBbUkZDMzQ3Mywgc2VjdGlvbiA0LjNdIG1lc3NhZ2UNCmFuZCBz
aWduYWxzIGl0IHRvIHRoZSBpbmdyZXNzIG5vZGUuIEluIHRoaXMgY2FzZSwgTk9USUZZX1JFUSBt
ZXNzYWdlIGlzDQpub3QgcmVxdWlyZWQuIDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGxl
YXNlIGFkdmlzZSB5b3VyIHRob3VnaHRzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhh
bmtzLDxicj4NCiZndDsmZ3Q7IFJha2VzaDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K
Jmd0OyZndDsgRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPGJyPg0K
Jmd0OyZndDsgU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA0LCAyMDEyIDExOjM1IEFNPGJyPg0K
Jmd0OyZndDsgVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpPGJyPg0KJmd0OyZndDsgQ2M6IHpo
YW5nLmZlaTNAenRlLmNvbS5jbjsgY2NhbXBAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0
OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gPGJyPg0KJmd0OyZndDsgZHJhZnQtaWV0
Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyBBcyBJIHJlYWQgdGhlIGN1cnJlbnQgcmV2LCBubyBzdWNoIG5v
dGlmaWNhdGlvbiBtZWNoYW5pc20gaXMgc3BlY2lmaWVkLjxicj4NCiZndDsmZ3Q7ICZuYnNwO0xv
b2tzIGxpa2UgeW91IGdldCB0byBwcm9wb3NlIG9uZSE8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IExvdSAoYXMgV0cgcGFydGljaXBhbnQpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
T24gOC8zMS8yMDEyIDk6NDkgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOjxicj4N
CiZndDsmZ3Q7Jmd0OyBIaSBMb3UsIEZlaSw8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsgV2hlbiBhbiAob3JpZ2luYXRpbmcpIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3
aXRoICZxdW90OzUNCihUQkQpICZuYnNwO1NpbmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0
aW9uYWwgTFNQcyAmbmJzcDsoQSkmcXVvdDsNCmFuZCB3aXNoZXMgdG8gY29udHJvbCBib3RoIGZv
cndhcmQgYW5kIHJldmVyc2UgJm5ic3A7TFNQcyBieSBhZGRpbmcgJnF1b3Q7UkVWRVJTRV9MU1Am
cXVvdDsNCm9iamVjdCwgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBpbmdyZXNzIG5vZGUgbmVlZHMg
dG8ga25vdyBhYm91dCB0aGUgc2lnbmFsaW5nDQoocGF0aCkgZXJyb3JzIChzdWNoIGFzIHNvZnQg
cHJlZW1wdGlvbiBvciBhZG1pc3Npb24gZmFpbHVyZSkgb24gdGhlIHJldmVyc2UNCkxTUC4gJm5i
c3A7SXMgdGhlcmUgYW55IHRleHQgc29tZXdoZXJlIGluIGFuIFJGQy9kcmFmdCB0aGF0IGRlc2Ny
aWJlcyBob3cNCmEgbWlkLXBvaW50IG5vZGUgY2FuIHNlbmQgdGhlIHNpZ25hbGluZyAocGF0aCkg
ZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nDQppbmdyZXNzIG5vZGUgZm9yIHRoZSByZXZlcnNlIExT
UD8gSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2UgUlNWUF9OT1RJRlkNCm1lc3NhZ2U/IFNv
cnJ5IGlmIEkgaGFkIG1pc3NlZCBhbnkgcHJldmlvdXMgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGlj
Ljxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZn
dDsmZ3Q7IFJha2VzaDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4N
Cjxicj4NCg==
--=_alternative 0003D24948257A78_=--


From rgandhi@cisco.com  Wed Sep 12 17:53: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 1986821F865C for ; Wed, 12 Sep 2012 17:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.497
X-Spam-Level: 
X-Spam-Status: No, score=-8.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_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGystg5H8G+b for ; Wed, 12 Sep 2012 17:53:10 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 362F521F8648 for ; Wed, 12 Sep 2012 17:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31943; q=dns/txt; s=iport; t=1347497589; x=1348707189; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TLOnchAbBk2J33DzK6dfXPTGYRqlkFboRvx7/uZyrys=; b=cDe8VrguqFxHFbgjUPjDCA1Cnd89pS+kfjOx2EvnoWzTABsotiXISBPY MgfCRyScNdsFZv1VX/QnTworHi9UmMUlILnDZBC/UY6Sgr6CLOzCqO/+D c7V5PNZWYN8x/yLjdAuQ8w/xULOhpyG2TeggdFFjL+lPRpCnG2yE7tj/X I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAHUtUVCtJV2c/2dsb2JhbABFgkuDPLRwc4EHgiABAQEDARIBFAZMBQcEAgEGAhEEAQEBChYHBQICMBQJCAIEDgUIEweHZQabZ40TCJMfixCFLDZgA6QVgWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,413,1344211200";  d="scan'208,217";a="121056075"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 13 Sep 2012 00:53:08 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8D0r8lg021896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 00:53:08 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 19:53:07 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: "zhang.fei3@zte.com.cn" 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObAAASWMgAAIiywQAAku1IAACmMi4A==
Date: Thu, 13 Sep 2012 00:53:07 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.004
x-tm-as-result: No--55.402900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C2409895Exmbalnx07ciscocom_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 00:53:23 -0000

--_000_B7D2A316AA32B6469D9670B6A81B7C2409895Exmbalnx07ciscocom_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgRmVpLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4uPFJHPi4uDQoNCkZyb206IHpoYW5nLmZlaTNA
enRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0NClNlbnQ6IFdlZG5lc2Rh
eSwgU2VwdGVtYmVyIDEyLCAyMDEyIDg6NDIgUE0NClRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhp
KQ0KQ2M6IGNjYW1wQGlldGYub3JnOyBMb3UgQmVyZ2VyDQpTdWJqZWN0OiBSRTogUXVlc3Rpb24g
b24gTFNQIGNvbnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNz
b2NpYXRlZC1sc3AtMDQudHh0DQoNCg0KSGkgUmFrZXNoDQoNCiBJbiB0aGUgYWJzZW5jZSBvZiBz
dWNoIG5vdGlmaWNhdGlvbiByZXF1ZXN0LCBlZ3Jlc3Mgbm9kZSBTSE9VTEQgcmVsYXkgdGhlIHJl
Y2VpdmVkIHNpZ25hbGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mg
bm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UuIg0KDQo8ZmVpPiAiTm90ZSB0aGF0IGEgTm90
aWZ5IG1lc3NhZ2UgTVVTVCBOT1QgYmUgZ2VuZXJhdGVkIHVubGVzcyBhbiBhcHByb3ByaWF0ZSBO
b3RpZnkgUmVxdWVzdCBvYmplY3QgaGFzIGJlZW4gcmVjZWl2ZWQuIg0KDQogICAgICAgSWYgbXkg
dW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB5b3VyIHByb3Bvc2VkIHJlbGF5IG1lY2hhbmlzbSBk
b2VzIG5vdCBkZXBlbmQgb24gdGhlIGV4aXN0aW5nIG9mIHRoZSBOb3RpZnkgUmVxdWVzdCBvYmpl
Y3QsIHdoaWNoIG1heSBjb25mbGljdCB3aXRoIHRoZQ0KICAgICAgIGRlc2NyaXBpdG9ucyBpbiBS
RkMzNDczLg0KDQogICAgICAgRG8geW91IHdhbnQgdG8gY2hhbmdlIHRoaXMgb3IgZG8gSSBoYXZl
IHNvbWUgbWlzdW5kZXJzdGFuZGluZz8NCg0KPFJHPiBZZXMgeW91ciB1bmRlcnN0YW5kaW5nIGlz
IGNvcnJlY3QuICBOT1RJRlkgbWVzc2FnZSBpbiB0aGlzIGNhc2UgaXMgZ2VuZXJhdGVkIGJhc2Vk
IG9uIHRoZSBwcmVzZW5jZSBvZiB0aGUgobBSRVZFUlNFX0xTUKGxIG9iamVjdCBhbmQgYXNzb2Np
YXRpb24gdHlwZSChsFNpbmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcy4g
IEkgdW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nIHRob3VnaC4gRllJLCAgTG91IGhhZCBm
b2xsb3dpbmcgdGhvdWdodHMgb24gdGhpcy4gRG8geW91IHRoaW5rIHRoaXMgc2ltcGxpZmllcyB0
aGluZ3MgPw0KPiAgICAgICAgICBTcGVha2luZyBhcyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZlbid0
IHRob3VnaHQgYWJvdXQgdGhpcyB0b28gbXVjaCBzbyBtYXkgYmUgb2ZmLCBidXQgbWV0aG9kIDMg
c2VlbXMgdG8gYmUgbW9zdCBjb25zaXN0ZW50IHdpdGggdGhlIHVzYWdlIG9mIHRoZSBSRVZFUlNF
X0xTUCBPYmplY3QgaW4gdGhlIHBhdGggbWVzc2FnZS4gIFBlcmhhcHMgY29uc2lkZXIgdXNpbmcg
dGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24gdG8g
YWxsb3cgdGhlIGVncmVzcy90YWlsIHRvIHByb3ZpZGUgdGhlIGluZ3Jlc3MvaGVhZCB3aXRoIGFy
Yml0cmFyeSBpbmZvcm1hdGlvbi4uLi4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KDQpSZWdhcmRz
DQoNCkZlaQ0KDQoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2FuZGhpQGNpc2NvLmNvbTxt
YWlsdG86cmdhbmRoaUBjaXNjby5jb20+Pg0KDQoyMDEyLTA5LTEzIDAxOjIzDQoNCsrVvP7Iyw0K
DQpMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4N
Cg0Ks63LzQ0KDQoiemhhbmcuZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5j
b20uY24+IiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20u
Y24+PiwgImNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4iIDxjY2FtcEBpZXRm
Lm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJFOiBRdWVzdGlvbiBvbiBM
U1AgY29udHJvbCBpbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh
dGVkLWxzcC0wNC50eHQNCg0KDQoNCg0KDQoNCg0KSGkgTG91LCBGZWksIFdHLA0KDQpUaGFua3Mg
Zm9yIHlvdXIgcmVwbGllcy4gTWF5IEkgcHJvcG9zZSBmb2xsb3dpbmcgdGV4dCB0byBjb3ZlciB0
aGlzIGNhc2U/IFRoaXMgYWxsb3dzIHRoZSBtaWQtcG9pbnQgc29sdXRpb24gd2hpY2ggaGFzIGFk
dmFudGFnZXMgYnV0IGdpdmVuIHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgY2FuIGJlIG9wdGlv
bmFsLg0KDQpQbGVhc2UgYWR2aXNlLg0KDQoiV2hlbiBhbiBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9k
ZSBpcyBwcm92aXNpb25lZCB3aXRoICJTaW5nbGUgU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlv
bmFsIExTUHMiIGFuZCB3aXNoZXMgdG8gY29udHJvbCBib3RoIGZvcndhcmQgYW5kIHJldmVyc2Ug
IExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIgb2JqZWN0LCB0aGUgaW5ncmVzcyBub2RlIFNI
T1VMRCBrbm93IHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyBvbiB0aGUgcmV2ZXJzZSBMU1Au
ICBBIHRyYW5zaXQgbm9kZSBNQVkgYmUgcmVxdWVzdGVkIHRvIG5vdGlmeSB0aGUgc2lnbmFsaW5n
IGVycm9yIG9uIHRoZSByZXZlcnNlIExTUCBieSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UgYW5k
IHByb2NlZHVyZXMgZGVmaW5lZCBpbiBSRkNbMzQ3M10uIEluIHRoZSBhYnNlbmNlIG9mIHN1Y2gg
bm90aWZpY2F0aW9uIHJlcXVlc3QsIGVncmVzcyBub2RlIFNIT1VMRCByZWxheSB0aGUgcmVjZWl2
ZWQgc2lnbmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNlIExTUCB0byB0aGUgaW5ncmVzcyBub2Rl
IHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS4iDQoNClRoYW5rcywNClJha2VzaA0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBs
YWJuLm5ldF08bWFpbHRvOlttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0+DQpTZW50OiBXZWRuZXNk
YXksIFNlcHRlbWJlciAxMiwgMjAxMiAxMjoxNCBQTQ0KVG86IFJha2VzaCBHYW5kaGkgKHJnYW5k
aGkpDQpDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20u
Y24+OyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog
UXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0
ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNClJha2VzaCwNCg0KDQpPbiA5LzEyLzIwMTIg
MTE6NTIgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPiBUaGFua3MgTG91Lg0K
Pg0KPiBBcmUgd2Ugb2sgaW4gZ2VuZXJhbCB0byB1c2UgTk9USUZZIG1lc3NhZ2UgW1JGQzM0NzNd
IGZvciB0aGlzPw0KDQpJJ20gbm90IHNwZWFraW5nIGZvciB0aGUgV0csIGFzIG5vdGVkIG15IGNv
bW1lbnRzIHdlcmUgYXMgYSBwYXJ0aWNpcGFudC4NCklNTyB5b3UnbGwgbmVlZCB0byBmdWxseSBk
b2N1bWVudCB0aGUgcHJvcG9zYWwsIHBlcmhhcHMgZGlzY3VzcyBhbHRlcm5hdGl2ZXMgY29uc2lk
ZXJlZCwgYW5kIHRoZW4gYXNrIHRoZSBXRyBmb3IgY29uY3VycmVuY2UuDQoNCj4NCj4gT25lIGFk
dmFudGFnZSB3aXRoIHRoZSBtaWQtcG9pbnQgc2VuZGluZyBub3RpZmljYXRpb24gZm9yIHRoZSBy
ZXZlcnNlDQo+IExTUCBpcyB0aGF0IHNpZ25hbGluZyBlcnJvciBwcm9wYWdhdGlvbiB0aW1lDQo+
IChtaWQtPmVncmVzcy1ub2RlLT5pbmdyZXNzLW5vZGUpIGlzIHNpZ25pZmljYW50bHkgcmVkdWNl
ZCAodG8NCj4gbWlkLT5pbmdyZXNzLW5vZGUpIHdoaWNoIG1heSBiZSBwcmVmZXJyZWQgaW4gc29t
ZSBjYXNlcy4NCg0KRnJvbSBteSAocGVyc29uYWwpIHBlcnNwZWN0aXZlLCB0aGUgYWRkZWQgY29t
cGxleGl0eSBpc24ndCB3b3J0aCB0aGUgZWZmb3J0LiAgT2YgY291cnNlLCBhIGRldGFpbGVkIHBy
b3Bvc2FsIG1heSBzaG93IG90aGVyd2lzZS4NCg0KTG91DQoNCj4NCj4gVGhhbmtzLA0KPiBSYWtl
c2gNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG91IEJlcmdl
ciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPG1haWx0bzpbbWFpbHRvOmxiZXJnZXJAbGFibi5u
ZXRdPg0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA5OjE1IEFNDQo+IFRv
OiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuPG1h
aWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+OyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBA
aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbg0KPiBk
cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQN
Cj4NCj4gUmFrZXNoLA0KPiAgICAgICAgICAgICAgICAgIFNwZWFraW5nIGFzIFdHIHBhcnRpY2lw
YW50LCBJIGhhdmVuJ3QgdGhvdWdodCBhYm91dCB0aGlzIHRvbyBtdWNoIHNvIG1heSBiZSBvZmYs
IGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBtb3N0IGNvbnNpc3RlbnQgd2l0aCB0aGUgdXNhZ2Ug
b2YgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgcGF0aCBtZXNzYWdlLiAgUGVyaGFwcyBj
b25zaWRlciB1c2luZyB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2
IGRpcmVjdGlvbiB0byBhbGxvdyB0aGUgZWdyZXNzL3RhaWwgdG8gcHJvdmlkZSB0aGUgaW5ncmVz
cy9oZWFkIHdpdGggYXJiaXRyYXJ5IGluZm9ybWF0aW9uLi4uLg0KPg0KPiBMb3UNCj4NCj4gT24g
OS8xMS8yMDEyIDk6MjIgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4gSGkg
V0csDQo+Pg0KPj4gQW55IHRob3VnaHRzIG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9zYWw/DQo+Pg0K
Pj4gVGhhbmtzLA0KPj4gUmFrZXNoDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQo+PiBGcm9tOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4gU2VudDogVHVlc2RheSwg
U2VwdGVtYmVyIDA0LCAyMDEyIDE6MzYgUE0NCj4+IFRvOiAnTG91IEJlcmdlcicNCj4+IENjOiB6
aGFuZy5mZWkzQHp0ZS5jb20uY248bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj47IGNjYW1w
QGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJFOiBRdWVzdGlv
biBvbiBMU1AgY29udHJvbCBpbg0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l
eHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pg0KPj4NCj4+IFRoYW5rcyBMb3UgZm9yIHlvdXIg
cmVwbHkuDQo+Pg0KPj4gUkZDIDM0NzMgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJRlkgcmVx
dWVzdCBhbmQgcmVwbHkuIFdlIGNvdWxkIHVzZSB0aGlzIGZvciByZXZlcnNlIExTUCBzaWduYWxp
bmcgZXJyb3Igbm90aWZpY2F0aW9uIHRvIHRoZSBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZS4NCj4+
DQo+PiA8Tm90aWZ5IG1lc3NhZ2U+IDo6PSA8Q29tbW9uIEhlYWRlcj4gWzxJTlRFR1JJVFk+XSBb
IFs8TUVTU0FHRV9JRF9BQ0s+IHwgPE1FU1NBR0VfSURfTkFDSz5dIC4uLiBdDQo+PiA8RVJST1Jf
U1BFQz4NCj4+IDxub3RpZnkgc2Vzc2lvbiBsaXN0IDo6PSA8dXBzdHJlYW0gc2Vzc2lvbj4gPGRv
d25zdHJlYW0gc2Vzc2lvbj4gID4NCj4+DQo+PiBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB3ZSBj
YW4gdXNlIHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4+DQo+PiBNZXRob2QgMSAtIE1pZC1wb2ludCBh
d2FyZSB3aXRoIFBhdGggbWVzc2FnZSByZXF1ZXN0Og0KPj4gV2hlbiBhbiBlZ3Jlc3Mgbm9kZSBy
ZWNlaXZlcyBhIFBhdGggbWVzc2FnZSB3aXRoIFJFVkVSU0VfTFNQIG9iamVjdCwgdGhlIG5vZGUg
d2lsbCBpbnNlcnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNlIExTUCBwYXRoIG1l
c3NhZ2Ugd2l0aCBub2RlIElEIG9mIHRoZSBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZS4gQSBtaWQt
cG9pbnQgbm9kZSB3aWxsIHNlbmQgIGEgY29weSBvZiB0aGUgc2lnbmFsaW5nIGVycm9yIHRvIHRo
ZSBpbml0aWF0aW5nIG5vZGUgdXNpbmcgdGhlIE5PVElGWSBtZXNzYWdlLg0KPj4NCj4+IElQdjQg
Tm90aWZ5IFJlcXVlc3QgT2JqZWN0DQo+PiAgICBJUHY0IE5vdGlmeSBOb2RlIEFkZHJlc3M6IDMy
IGJpdHMNCj4+ICAgICAgIFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIHRoYXQgc2hvdWxkIGJl
IG5vdGlmaWVkIHdoZW4gZ2VuZXJhdGluZyBhbiBlcnJvciBtZXNzYWdlLg0KPj4NCj4+IE1ldGhv
ZCAyIC0gTWlkLXBvaW50IGF3YXJlIHdpdGggUmVzdiBtZXNzYWdlIHJlcXVlc3Q6DQo+PiBXaGVu
IGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIGZvciBh
IHJldmVyc2UgTFNQLCB0aGUgbm9kZSB3aWxsIGluc2VydCBOT1RJRllfUkVRIG1lc3NhZ2UgaW4g
dGhlIHJldmVyc2UgTFNQIFJlc3YgbWVzc2FnZSB3aXRoIGl0cyBvd24gbm9kZSBJRC4gQSBtaWQt
cG9pbnQgbm9kZSB3aWxsIHNlbmQgYSBjb3B5IG9mIHRoZSBzaWduYWxpbmcgZXJyb3IgdG8gdGhl
IGluaXRpYXRpbmcgbm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UuDQo+Pg0KPj4gTWV0aG9k
IDMgLSBUYWlsLWVuZCByZWxheWluZyA6DQo+PiBXaGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVz
IGEgUGF0aCBtZXNzYWdlIHdpdGggUkVWRVJTRV9MU1Agb2JqZWN0LCB0aGUgbm9kZSB3aWxsIHJl
bGF5IHRoZSByZWNlaXZlZCBzaWduYWxpbmcgZXJyb3IgbWVzc2FnZSBvbiB0aGUgcmV2ZXJzZSBM
U1AgdG8gdGhlIGluaXRpYWxpemluZyBpbmdyZXNzIG5vZGUuIFRoZSBlZ3Jlc3Mgbm9kZSBjb3Bp
ZXMgdGhlIHJlY2VpdmVkICJFUlJPUl9TUEVDIiBvYmplY3QgaW50byBhIE5PVElGWSBbUkZDMzQ3
Mywgc2VjdGlvbiA0LjNdIG1lc3NhZ2UgYW5kIHNpZ25hbHMgaXQgdG8gdGhlIGluZ3Jlc3Mgbm9k
ZS4gSW4gdGhpcyBjYXNlLCBOT1RJRllfUkVRIG1lc3NhZ2UgaXMgbm90IHJlcXVpcmVkLg0KPj4N
Cj4+IFBsZWFzZSBhZHZpc2UgeW91ciB0aG91Z2h0cy4NCj4+DQo+PiBUaGFua3MsDQo+PiBSYWtl
c2gNCj4+DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBM
b3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF08bWFpbHRvOlttYWlsdG86bGJlcmdl
ckBsYWJuLm5ldF0+DQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTIgMTE6MzUg
QU0NCj4+IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4gQ2M6IHpoYW5nLmZlaTNAenRl
LmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjsgY2NhbXBAaWV0Zi5vcmc8bWFp
bHRvOmNjYW1wQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250
cm9sIGluDQo+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVk
LWxzcC0wNC50eHQNCj4+DQo+PiBBcyBJIHJlYWQgdGhlIGN1cnJlbnQgcmV2LCBubyBzdWNoIG5v
dGlmaWNhdGlvbiBtZWNoYW5pc20gaXMgc3BlY2lmaWVkLg0KPj4gIExvb2tzIGxpa2UgeW91IGdl
dCB0byBwcm9wb3NlIG9uZSENCj4+DQo+PiBMb3UgKGFzIFdHIHBhcnRpY2lwYW50KS4NCj4+DQo+
PiBPbiA4LzMxLzIwMTIgOTo0OSBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+
Pj4gSGkgTG91LCBGZWksDQo+Pj4NCj4+PiBXaGVuIGFuIChvcmlnaW5hdGluZykgaW5ncmVzcyBu
b2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggIjUgKFRCRCkgIFNpbmdsZSBTaWRlZCBBc3NvY2lhdGVk
IEJpZGlyZWN0aW9uYWwgTFNQcyAgKEEpIiBhbmQgd2lzaGVzIHRvIGNvbnRyb2wgYm90aCBmb3J3
YXJkIGFuZCByZXZlcnNlICBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9MU1AiIG9iamVjdCwgSSB3
b3VsZCB0aGluayB0aGF0IHRoZSBpbmdyZXNzIG5vZGUgbmVlZHMgdG8ga25vdyBhYm91dCB0aGUg
c2lnbmFsaW5nIChwYXRoKSBlcnJvcnMgKHN1Y2ggYXMgc29mdCBwcmVlbXB0aW9uIG9yIGFkbWlz
c2lvbiBmYWlsdXJlKSBvbiB0aGUgcmV2ZXJzZSBMU1AuICBJcyB0aGVyZSBhbnkgdGV4dCBzb21l
d2hlcmUgaW4gYW4gUkZDL2RyYWZ0IHRoYXQgZGVzY3JpYmVzIGhvdyBhIG1pZC1wb2ludCBub2Rl
IGNhbiBzZW5kIHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9yIHRvIHRoZSBvcmlnaW5hdGluZyBp
bmdyZXNzIG5vZGUgZm9yIHRoZSByZXZlcnNlIExTUD8gSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0
byB1c2UgUlNWUF9OT1RJRlkgbWVzc2FnZT8gU29ycnkgaWYgSSBoYWQgbWlzc2VkIGFueSBwcmV2
aW91cyBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gUmFr
ZXNoDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4NCj4NCj4NCj4N
Cg0K

--_000_B7D2A316AA32B6469D9670B6A81B7C2409895Exmbalnx07ciscocom_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Fei,=



 <=
/p>

Please see inline..<RG=
>..


 <=
/p>

From: zhang.fe=
i3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]


Sent: Wednesday, September 12, 2012 8:42 PM

To: Rakesh Gandhi (rgandhi)

Cc: ccamp@ietf.org; Lou Berger

Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsv=
pte-ext-associated-lsp-04.txt


 




Hi Rakesh 



 In the absence of such notificat=
ion request, egress node SHOULD relay the received signaling error on the r=
everse LSP to the ingress node using the NOTIFY message."




<fei> "Note that=
 a Notify message MUST NOT be generated unless an appropriate Notify Reques=
t object has been received."




       =
If my understanding is correct, your proposed relay mechanism does not depe=
nd on the existing of the Notify Request object, which may conflict with th=
e


       =
descripitons in RFC3473. 




       =
Do you want to change this or do I have some misunderstanding?  







<RG> Yes your understanding is correct.  NOTIFY message in=
 this case is generated based on the presence of the =A1=B0REVERSE_LSP=A1=
=B1 object
 and association type =A1=B0Single Sided Associated Bidirectional LSPs.&nbs=
p; I understand what you are saying though. FYI,  Lou had following th=
oughts on this. Do you think this simplifies things ?


>          Speaking as WG particip=
ant, I haven't thought about this too much so may be off, but method 3 seem=
s to be most
 consistent with the usage of the REVERSE_LSP Object in the path message. &=
nbsp;Perhaps consider using the REVERSE_LSP Object in the upstream/Resv dir=
ection to allow the egress/tail to provide the ingress/head with arbitrary =
information....






Thanks,


Rakesh


 


 




Regards 



Fei 












"Rakesh Gandhi (rgandhi)" <=
;rgandhi@cisco.com><=
span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri=
f"">



2012-09-13 01:23











=CA=D5=BC=FE=C8=CB<=
/p>




Lou Berger <lberger@labn.net>









=B3=AD=CB=CD




"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>, "ccamp@ietf.org"
 <ccamp@ietf.org> <=
/o:p>








=D6=F7=CC=E2




RE: Question on LSP control in draft-ietf-=
ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt








 


























Hi Lou, Fei, WG,



Thanks for your replies. May I propose following text to cover this cas=
e? This allows the mid-point solution which has advantages but given the ad=
ditional complexity can be optional.



Please advise. 



"When an initiating ingress node is provisioned with "Single =
Sided Associated Bidirectional LSPs" and wishes to control both forwar=
d and reverse  LSPs by adding "REVERSE_LSP" object, the ingr=
ess node SHOULD know the signaling (path) errors on the reverse
 LSP.  A transit node MAY be requested to notify the signaling error o=
n the reverse LSP by using the NOTIFY message and procedures defined in RFC=
[3473]. In the absence of such notification request, egress node SHOULD rel=
ay the received signaling error on the
 reverse LSP to the ingress node using the NOTIFY message."



Thanks,

Rakesh





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

From: Lou Berger [mailto:l=
berger@labn.net]


Sent: Wednesday, September 12, 2012 12:14 PM

To: Rakesh Gandhi (rgandhi)

Cc: zhang.fei3@zte.com.cn;=
 
ccamp@ietf.org

Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte=
-ext-associated-lsp-04.txt



Rakesh,





On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:

> Thanks Lou.

> 

> Are we ok in general to use NOTIFY message [RFC3473] for this?



I'm not speaking for the WG, as noted my comments were as a participant=
.

IMO you'll need to fully document the proposal, perhaps discuss alterna=
tives considered, and then ask the WG for concurrence.



> 

> One advantage with the mid-point sending notification for the reve=
rse 


> LSP is that signaling error propagation time

> (mid->egress-node->ingress-node) is significantly reduced (t=
o

> mid->ingress-node) which may be preferred in some cases.


From my (personal) perspective, the added complexity isn't worth the ef=
fort.  Of course, a detailed proposal may show otherwise.



Lou



> 

> Thanks,

> Rakesh

> 

> 

> -----Original Message-----

> From: Lou Berger [mai=
lto:lberger@labn.net]

> Sent: Wednesday, September 12, 2012 9:15 AM

> To: Rakesh Gandhi (rgandhi)

> Cc: zhang.fei3@zte.com.cn=
; 
ccamp@ietf.org

> Subject: Re: Question on LSP control in 

> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

> 

> Rakesh,

>                  Spea=
king as WG participant, I haven't thought about this too much so may be off=
, but method 3 seems to be most consistent with the usage of the REVERSE_LS=
P Object in the path message.  Perhaps consider using the REVERSE_LSP =
Object in
 the upstream/Resv direction to allow the egress/tail to provide the ingres=
s/head with arbitrary information....

> 

> Lou

> 

> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:

>> Hi WG,

>>

>> Any thoughts on the following proposal?

>>

>> Thanks,

>> Rakesh

>>

>>

>> -----Original Message-----

>> From: Rakesh Gandhi (rgandhi)

>> Sent: Tuesday, September 04, 2012 1:36 PM

>> To: 'Lou Berger'

>> Cc: zhang.fei3@zte.co=
m.cn; 
ccamp@ietf.org

>> Subject: RE: Question on LSP control in 

>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=


>>

>>

>> Thanks Lou for your reply.

>>

>> RFC 3473 defines procedures for NOTIFY request and reply. We c=
ould use this for reverse LSP signaling error notification to the initiatin=
g ingress node.

>>

>> <Notify message> ::=3D <Common Header> [<INTEGR=
ITY>] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
>> <ERROR_SPEC>   

>> <notify session list ::=3D <upstream session> <dow=
nstream session>  >

>>

>> There are multiple ways we can use the NOTIFY message.
>>

>> Method 1 - Mid-point aware with Path message request:

>> When an egress node receives a Path message with REVERSE_LSP o=
bject, the node will insert NOTIFY_REQ message in the reverse LSP path mess=
age with node ID of the initiating ingress node. A mid-point node will send=
  a copy of the signaling error to the
 initiating node using the NOTIFY message.

>>

>> IPv4 Notify Request Object

>>    IPv4 Notify Node Address: 32 bits

>>       The IP address of the node that should be=
 notified when generating an error message.

>>

>> Method 2 - Mid-point aware with Resv message request:

>> When an initiating ingress node receives a Path message for a =
reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Res=
v message with its own node ID. A mid-point node will send a copy of the si=
gnaling error to the initiating node using
 the NOTIFY message.

>>

>> Method 3 - Tail-end relaying :

>> When an egress node receives a Path message with REVERSE_LSP o=
bject, the node will relay the received signaling error message on the reve=
rse LSP to the initializing ingress node. The egress node copies the receiv=
ed "ERROR_SPEC" object into a NOTIFY [RFC3473,
 section 4.3] message and signals it to the ingress node. In this case, NOT=
IFY_REQ message is not required.


>>

>> Please advise your thoughts.

>>

>> Thanks,

>> Rakesh

>>

>>

>>

>> -----Original Message-----

>> From: Lou Berger =
[mailto:lberger@labn.net]

>> Sent: Tuesday, September 04, 2012 11:35 AM

>> To: Rakesh Gandhi (rgandhi)

>> Cc: zhang.fei3@zte.co=
m.cn; 
ccamp@ietf.org

>> Subject: Re: Question on LSP control in 

>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt=


>>

>> As I read the current rev, no such notification mechanism is s=
pecified.

>>  Looks like you get to propose one!

>>

>> Lou (as WG participant).

>>

>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:

>>> Hi Lou, Fei,

>>>

>>> When an (originating) ingress node is provisioned with &qu=
ot;5 (TBD)  Single Sided Associated Bidirectional LSPs  (A)"=
 and wishes to control both forward and reverse  LSPs by adding "=
REVERSE_LSP" object, I would think that the ingress node needs to know
 about the signaling (path) errors (such as soft preemption or admission fa=
ilure) on the reverse LSP.  Is there any text somewhere in an RFC/draf=
t that describes how a mid-point node can send the signaling (path) error t=
o the originating ingress node for the
 reverse LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I=
 had missed any previous discussion on this topic.

>>>

>>> Thanks,

>>> Rakesh

>>>

>>>

>>>

>>>

>>>

>>

>>

>>

>>

> 

> 

> 

> 










--_000_B7D2A316AA32B6469D9670B6A81B7C2409895Exmbalnx07ciscocom_--

From zhang.fei3@zte.com.cn  Wed Sep 12 18:40: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 6AE6521F8584 for ; Wed, 12 Sep 2012 18:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.267
X-Spam-Level: 
X-Spam-Status: No, score=-96.267 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_BAD_ID=2.837, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oZc-je7SIVm for ; Wed, 12 Sep 2012 18:40:15 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 140B221F8582 for ; Wed, 12 Sep 2012 18:40:13 -0700 (PDT)
Received: from [10.30.3.21] by mx5.zte.com.cn with surfront esmtp id 232552685115152(version=TLSv1/SSLv3 cipher=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA bits=128 verify=NO);  Thu, 13 Sep 2012 09:32:41 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q8D1dv6x086352; Thu, 13 Sep 2012 09:39:57 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: 
To: "Rakesh Gandhi (rgandhi)" 
MIME-Version: 1.0
X-KeepSent: F0A17BBD:DF3CC958-48257A78:00085C95; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhang.fei3@zte.com.cn
Date: Thu, 13 Sep 2012 09:39:52 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-09-13 09:39:50, Serialize complete at 2012-09-13 09:39:50
Content-Type: multipart/alternative; boundary="=_alternative 000926A748257A78_="
X-MAIL: mse02.zte.com.cn q8D1dv6x086352
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 01:40:16 -0000

This is a multipart message in MIME format.
--=_alternative 000926A748257A78_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGkgUmVrZXNoLCBMb3UNCg0KID4gICAgICAgICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQs
IEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRoaXMgdG9vIA0KbXVjaCBzbyBtYXkgYmUgb2ZmLCBi
dXQgbWV0aG9kIDMgc2VlbXMgdG8gYmUgbW9zdCBjb25zaXN0ZW50IHdpdGggdGhlIA0KdXNhZ2Ug
b2YgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgcGF0aCBtZXNzYWdlLiAgUGVyaGFwcyBj
b25zaWRlciANCnVzaW5nIHRoZSBSRVZFUlNFX0xTUCBPYmplY3QgaW4gdGhlIHVwc3RyZWFtL1Jl
c3YgZGlyZWN0aW9uIHRvIGFsbG93IHRoZSANCmVncmVzcy90YWlsIHRvIHByb3ZpZGUgdGhlIGlu
Z3Jlc3MvaGVhZCB3aXRoIGFyYml0cmFyeSBpbmZvcm1hdGlvbi4uLi4NCg0KPGZlaT5XZWxsLCBJ
IGNhbiBzZWUgb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgcHJvcG9zYWwgaXMgdGhhdCBp
dCANCmFsbG93cyB0aGUgcG9saWN5IGNvbnRyb2wgaW4gdGhlIGVncmVzcy90YWlsLCB3aGVyZSBh
IGRlY2lzaW9uIGNhbiBiZSBtYWRlIA0KdGhhdCB3aGV0aGVyIHRoZSBzaWduYWxpbmcgZXJyb3Ig
c2hvdWxkIGJlIHBhc3NlZCB0byB0aGUgaW5ncmVzcy9oZWFkLiBCdXQgDQppdCBjaGFuZ2VzIHRo
ZSBydWxlcyBkZWZpbmVkIGluIFJGQzM0NzMuLi4uDQoNCiAgICAgVGhlIG90aGVyIHByb3Bvc2Fs
IGtlZXBzIGFsaWdubWVudCB3aXRoIFJGQzM0NzMsIGFuZCBJIHByZWZlciBpdCBpZiANCnRoZSBM
U1AgY29udHJvbCBpcyB0b3RhbGx5IGluIGhhbmQgb2YgdGhlIGluZ3Jlc3MvaGVhZCAoaW4gb3Ro
ZXIgd29yZHMsIA0KdGhlcmUgaXMgbm8gbW9yZSBpbmZvcm1hdGlvbiBuZWVkcyB0aGUgZWdyZXMv
dGFpbCB0byBpbmZvcm0gdGhlIA0KaW5ncmVzcy9oZWFkKS4NCg0KDQoNCiJSYWtlc2ggR2FuZGhp
IChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPiANCjIwMTItMDktMTMgMDg6NTMNCg0KytW8
/sjLDQoiemhhbmcuZmVpM0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNuPg0Ks63L
zQ0KImNjYW1wQGlldGYub3JnIiA8Y2NhbXBAaWV0Zi5vcmc+LCBMb3UgQmVyZ2VyIDxsYmVyZ2Vy
QGxhYm4ubmV0Pg0K1vfM4g0KUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KZHJhZnQt
aWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCg0K
DQoNCg0KDQpIaSBGZWksDQogDQpQbGVhc2Ugc2VlIGlubGluZS4uPFJHPi4uDQogDQpGcm9tOiB6
aGFuZy5mZWkzQHp0ZS5jb20uY24gW21haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY25dIA0KU2Vu
dDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgODo0MiBQTQ0KVG86IFJha2VzaCBHYW5k
aGkgKHJnYW5kaGkpDQpDYzogY2NhbXBAaWV0Zi5vcmc7IExvdSBCZXJnZXINClN1YmplY3Q6IFJF
OiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiANCmRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1y
c3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KIA0KDQpIaSBSYWtlc2ggDQoNCiBJbiB0
aGUgYWJzZW5jZSBvZiBzdWNoIG5vdGlmaWNhdGlvbiByZXF1ZXN0LCBlZ3Jlc3Mgbm9kZSBTSE9V
TEQgcmVsYXkgdGhlIA0KcmVjZWl2ZWQgc2lnbmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNlIExT
UCB0byB0aGUgaW5ncmVzcyBub2RlIHVzaW5nIHRoZSANCk5PVElGWSBtZXNzYWdlLiIgDQoNCjxm
ZWk+ICJOb3RlIHRoYXQgYSBOb3RpZnkgbWVzc2FnZSBNVVNUIE5PVCBiZSBnZW5lcmF0ZWQgdW5s
ZXNzIGFuIA0KYXBwcm9wcmlhdGUgTm90aWZ5IFJlcXVlc3Qgb2JqZWN0IGhhcyBiZWVuIHJlY2Vp
dmVkLiIgDQoNCiAgICAgICBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIHlvdXIgcHJv
cG9zZWQgcmVsYXkgbWVjaGFuaXNtIGRvZXMgDQpub3QgZGVwZW5kIG9uIHRoZSBleGlzdGluZyBv
ZiB0aGUgTm90aWZ5IFJlcXVlc3Qgb2JqZWN0LCB3aGljaCBtYXkgDQpjb25mbGljdCB3aXRoIHRo
ZSANCiAgICAgICBkZXNjcmlwaXRvbnMgaW4gUkZDMzQ3My4gDQoNCiAgICAgICBEbyB5b3Ugd2Fu
dCB0byBjaGFuZ2UgdGhpcyBvciBkbyBJIGhhdmUgc29tZSBtaXN1bmRlcnN0YW5kaW5nPyAgIA0K
DQo8Ukc+IFllcyB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4gIE5PVElGWSBtZXNzYWdl
IGluIHRoaXMgY2FzZSBpcyANCmdlbmVyYXRlZCBiYXNlZCBvbiB0aGUgcHJlc2VuY2Ugb2YgdGhl
IKGwUkVWRVJTRV9MU1ChsSBvYmplY3QgYW5kIA0KYXNzb2NpYXRpb24gdHlwZSChsFNpbmdsZSBT
aWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcy4gIEkgDQp1bmRlcnN0YW5kIHdoYXQg
eW91IGFyZSBzYXlpbmcgdGhvdWdoLiBGWUksICBMb3UgaGFkIGZvbGxvd2luZyB0aG91Z2h0cyBv
biANCnRoaXMuIERvIHlvdSB0aGluayB0aGlzIHNpbXBsaWZpZXMgdGhpbmdzID8NCj4gICAgICAg
ICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRo
aXMgdG9vIA0KbXVjaCBzbyBtYXkgYmUgb2ZmLCBidXQgbWV0aG9kIDMgc2VlbXMgdG8gYmUgbW9z
dCBjb25zaXN0ZW50IHdpdGggdGhlIA0KdXNhZ2Ugb2YgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBp
biB0aGUgcGF0aCBtZXNzYWdlLiAgUGVyaGFwcyBjb25zaWRlciANCnVzaW5nIHRoZSBSRVZFUlNF
X0xTUCBPYmplY3QgaW4gdGhlIHVwc3RyZWFtL1Jlc3YgZGlyZWN0aW9uIHRvIGFsbG93IHRoZSAN
CmVncmVzcy90YWlsIHRvIHByb3ZpZGUgdGhlIGluZ3Jlc3MvaGVhZCB3aXRoIGFyYml0cmFyeSBp
bmZvcm1hdGlvbi4uLi4NCg0KVGhhbmtzLA0KUmFrZXNoDQogDQogDQoNClJlZ2FyZHMgDQoNCkZl
aSANCg0KDQoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2FuZGhpQGNpc2NvLmNvbT4gDQoy
MDEyLTA5LTEzIDAxOjIzIA0KDQoNCsrVvP7Iyw0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5l
dD4gDQqzrcvNDQoiemhhbmcuZmVpM0B6dGUuY29tLmNuIiA8emhhbmcuZmVpM0B6dGUuY29tLmNu
PiwgImNjYW1wQGlldGYub3JnIiA8DQpjY2FtcEBpZXRmLm9yZz4gDQrW98ziDQpSRTogUXVlc3Rp
b24gb24gTFNQIGNvbnRyb2wgaW4gDQpkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4
dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCiANCg0KDQoNCg0KDQoNCg0KDQpIaSBMb3UsIEZlaSwg
V0csDQoNClRoYW5rcyBmb3IgeW91ciByZXBsaWVzLiBNYXkgSSBwcm9wb3NlIGZvbGxvd2luZyB0
ZXh0IHRvIGNvdmVyIHRoaXMgY2FzZT8gDQpUaGlzIGFsbG93cyB0aGUgbWlkLXBvaW50IHNvbHV0
aW9uIHdoaWNoIGhhcyBhZHZhbnRhZ2VzIGJ1dCBnaXZlbiB0aGUgDQphZGRpdGlvbmFsIGNvbXBs
ZXhpdHkgY2FuIGJlIG9wdGlvbmFsLg0KDQpQbGVhc2UgYWR2aXNlLiANCg0KIldoZW4gYW4gaW5p
dGlhdGluZyBpbmdyZXNzIG5vZGUgaXMgcHJvdmlzaW9uZWQgd2l0aCAiU2luZ2xlIFNpZGVkIA0K
QXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMiIGFuZCB3aXNoZXMgdG8gY29udHJvbCBib3Ro
IGZvcndhcmQgYW5kIA0KcmV2ZXJzZSAgTFNQcyBieSBhZGRpbmcgIlJFVkVSU0VfTFNQIiBvYmpl
Y3QsIHRoZSBpbmdyZXNzIG5vZGUgU0hPVUxEIGtub3cgDQp0aGUgc2lnbmFsaW5nIChwYXRoKSBl
cnJvcnMgb24gdGhlIHJldmVyc2UgTFNQLiAgQSB0cmFuc2l0IG5vZGUgTUFZIGJlIA0KcmVxdWVz
dGVkIHRvIG5vdGlmeSB0aGUgc2lnbmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNlIExTUCBieSB1
c2luZyB0aGUgDQpOT1RJRlkgbWVzc2FnZSBhbmQgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFJGQ1sz
NDczXS4gSW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCANCm5vdGlmaWNhdGlvbiByZXF1ZXN0LCBlZ3Jl
c3Mgbm9kZSBTSE9VTEQgcmVsYXkgdGhlIHJlY2VpdmVkIHNpZ25hbGluZyANCmVycm9yIG9uIHRo
ZSByZXZlcnNlIExTUCB0byB0aGUgaW5ncmVzcyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2Fn
ZS4iDQoNClRoYW5rcywNClJha2VzaA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBXZWRuZXNk
YXksIFNlcHRlbWJlciAxMiwgMjAxMiAxMjoxNCBQTQ0KVG86IFJha2VzaCBHYW5kaGkgKHJnYW5k
aGkpDQpDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDog
UmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRw
LXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNClJha2VzaCwNCg0KDQpPbiA5LzEy
LzIwMTIgMTE6NTIgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPiBUaGFua3Mg
TG91Lg0KPiANCj4gQXJlIHdlIG9rIGluIGdlbmVyYWwgdG8gdXNlIE5PVElGWSBtZXNzYWdlIFtS
RkMzNDczXSBmb3IgdGhpcz8NCg0KSSdtIG5vdCBzcGVha2luZyBmb3IgdGhlIFdHLCBhcyBub3Rl
ZCBteSBjb21tZW50cyB3ZXJlIGFzIGEgcGFydGljaXBhbnQuDQpJTU8geW91J2xsIG5lZWQgdG8g
ZnVsbHkgZG9jdW1lbnQgdGhlIHByb3Bvc2FsLCBwZXJoYXBzIGRpc2N1c3MgDQphbHRlcm5hdGl2
ZXMgY29uc2lkZXJlZCwgYW5kIHRoZW4gYXNrIHRoZSBXRyBmb3IgY29uY3VycmVuY2UuDQoNCj4g
DQo+IE9uZSBhZHZhbnRhZ2Ugd2l0aCB0aGUgbWlkLXBvaW50IHNlbmRpbmcgbm90aWZpY2F0aW9u
IGZvciB0aGUgcmV2ZXJzZSANCj4gTFNQIGlzIHRoYXQgc2lnbmFsaW5nIGVycm9yIHByb3BhZ2F0
aW9uIHRpbWUNCj4gKG1pZC0+ZWdyZXNzLW5vZGUtPmluZ3Jlc3Mtbm9kZSkgaXMgc2lnbmlmaWNh
bnRseSByZWR1Y2VkICh0bw0KPiBtaWQtPmluZ3Jlc3Mtbm9kZSkgd2hpY2ggbWF5IGJlIHByZWZl
cnJlZCBpbiBzb21lIGNhc2VzLg0KDQpGcm9tIG15IChwZXJzb25hbCkgcGVyc3BlY3RpdmUsIHRo
ZSBhZGRlZCBjb21wbGV4aXR5IGlzbid0IHdvcnRoIHRoZSANCmVmZm9ydC4gIE9mIGNvdXJzZSwg
YSBkZXRhaWxlZCBwcm9wb3NhbCBtYXkgc2hvdyBvdGhlcndpc2UuDQoNCkxvdQ0KDQo+IA0KPiBU
aGFua3MsDQo+IFJha2VzaA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiBTZW50OiBXZWRu
ZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA5OjE1IEFNDQo+IFRvOiBSYWtlc2ggR2FuZGhpIChy
Z2FuZGhpKQ0KPiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuOyBjY2FtcEBpZXRmLm9yZw0KPiBT
dWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gDQo+IGRyYWZ0LWlldGYtY2Nh
bXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPiANCj4gUmFrZXNo
LA0KPiAgICAgICAgICAgICAgICAgIFNwZWFraW5nIGFzIFdHIHBhcnRpY2lwYW50LCBJIGhhdmVu
J3QgdGhvdWdodCBhYm91dCANCnRoaXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhv
ZCAzIHNlZW1zIHRvIGJlIG1vc3QgY29uc2lzdGVudCB3aXRoIA0KdGhlIHVzYWdlIG9mIHRoZSBS
RVZFUlNFX0xTUCBPYmplY3QgaW4gdGhlIHBhdGggbWVzc2FnZS4gIFBlcmhhcHMgY29uc2lkZXIg
DQp1c2luZyB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2IGRpcmVj
dGlvbiB0byBhbGxvdyB0aGUgDQplZ3Jlc3MvdGFpbCB0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hl
YWQgd2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24uLi4uDQo+IA0KPiBMb3UNCj4gDQo+IE9uIDkv
MTEvMjAxMiA5OjIyIEFNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+IEhpIFdH
LA0KPj4NCj4+IEFueSB0aG91Z2h0cyBvbiB0aGUgZm9sbG93aW5nIHByb3Bvc2FsPw0KPj4NCj4+
IFRoYW5rcywNCj4+IFJha2VzaA0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPj4gRnJvbTogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+IFNlbnQ6IFR1ZXNkYXksIFNl
cHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNDQo+PiBUbzogJ0xvdSBCZXJnZXInDQo+PiBDYzogemhh
bmcuZmVpM0B6dGUuY29tLmNuOyBjY2FtcEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUkU6IFF1ZXN0
aW9uIG9uIExTUCBjb250cm9sIGluIA0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0
ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pg0KPj4NCj4+IFRoYW5rcyBMb3UgZm9yIHlv
dXIgcmVwbHkuDQo+Pg0KPj4gUkZDIDM0NzMgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJRlkg
cmVxdWVzdCBhbmQgcmVwbHkuIFdlIGNvdWxkIHVzZSANCnRoaXMgZm9yIHJldmVyc2UgTFNQIHNp
Z25hbGluZyBlcnJvciBub3RpZmljYXRpb24gdG8gdGhlIGluaXRpYXRpbmcgDQppbmdyZXNzIG5v
ZGUuDQo+Pg0KPj4gPE5vdGlmeSBtZXNzYWdlPiA6Oj0gPENvbW1vbiBIZWFkZXI+IFs8SU5URUdS
SVRZPl0gWyBbPE1FU1NBR0VfSURfQUNLPiANCnwgPE1FU1NBR0VfSURfTkFDSz5dIC4uLiBdDQo+
PiA8RVJST1JfU1BFQz4gDQo+PiA8bm90aWZ5IHNlc3Npb24gbGlzdCA6Oj0gPHVwc3RyZWFtIHNl
c3Npb24+IDxkb3duc3RyZWFtIHNlc3Npb24+ICA+DQo+Pg0KPj4gVGhlcmUgYXJlIG11bHRpcGxl
IHdheXMgd2UgY2FuIHVzZSB0aGUgTk9USUZZIG1lc3NhZ2UuDQo+Pg0KPj4gTWV0aG9kIDEgLSBN
aWQtcG9pbnQgYXdhcmUgd2l0aCBQYXRoIG1lc3NhZ2UgcmVxdWVzdDoNCj4+IFdoZW4gYW4gZWdy
ZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3Qs
IA0KdGhlIG5vZGUgd2lsbCBpbnNlcnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNl
IExTUCBwYXRoIG1lc3NhZ2UgDQp3aXRoIG5vZGUgSUQgb2YgdGhlIGluaXRpYXRpbmcgaW5ncmVz
cyBub2RlLiBBIG1pZC1wb2ludCBub2RlIHdpbGwgc2VuZCAgYSANCmNvcHkgb2YgdGhlIHNpZ25h
bGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgDQptZXNz
YWdlLg0KPj4NCj4+IElQdjQgTm90aWZ5IFJlcXVlc3QgT2JqZWN0DQo+PiAgICBJUHY0IE5vdGlm
eSBOb2RlIEFkZHJlc3M6IDMyIGJpdHMNCj4+ICAgICAgIFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBu
b2RlIHRoYXQgc2hvdWxkIGJlIG5vdGlmaWVkIHdoZW4gDQpnZW5lcmF0aW5nIGFuIGVycm9yIG1l
c3NhZ2UuDQo+Pg0KPj4gTWV0aG9kIDIgLSBNaWQtcG9pbnQgYXdhcmUgd2l0aCBSZXN2IG1lc3Nh
Z2UgcmVxdWVzdDoNCj4+IFdoZW4gYW4gaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUgcmVjZWl2ZXMg
YSBQYXRoIG1lc3NhZ2UgZm9yIGEgcmV2ZXJzZSANCkxTUCwgdGhlIG5vZGUgd2lsbCBpbnNlcnQg
Tk9USUZZX1JFUSBtZXNzYWdlIGluIHRoZSByZXZlcnNlIExTUCBSZXN2IA0KbWVzc2FnZSB3aXRo
IGl0cyBvd24gbm9kZSBJRC4gQSBtaWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQgYSBjb3B5IG9mIHRo
ZSANCnNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJ
RlkgbWVzc2FnZS4NCj4+DQo+PiBNZXRob2QgMyAtIFRhaWwtZW5kIHJlbGF5aW5nIDoNCj4+IFdo
ZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xT
UCBvYmplY3QsIA0KdGhlIG5vZGUgd2lsbCByZWxheSB0aGUgcmVjZWl2ZWQgc2lnbmFsaW5nIGVy
cm9yIG1lc3NhZ2Ugb24gdGhlIHJldmVyc2UgDQpMU1AgdG8gdGhlIGluaXRpYWxpemluZyBpbmdy
ZXNzIG5vZGUuIFRoZSBlZ3Jlc3Mgbm9kZSBjb3BpZXMgdGhlIHJlY2VpdmVkIA0KIkVSUk9SX1NQ
RUMiIG9iamVjdCBpbnRvIGEgTk9USUZZIFtSRkMzNDczLCBzZWN0aW9uIDQuM10gbWVzc2FnZSBh
bmQgDQpzaWduYWxzIGl0IHRvIHRoZSBpbmdyZXNzIG5vZGUuIEluIHRoaXMgY2FzZSwgTk9USUZZ
X1JFUSBtZXNzYWdlIGlzIG5vdCANCnJlcXVpcmVkLiANCj4+DQo+PiBQbGVhc2UgYWR2aXNlIHlv
dXIgdGhvdWdodHMuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gUmFrZXNoDQo+Pg0KPj4NCj4+DQo+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxi
ZXJnZXJAbGFibi5uZXRdDQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTIgMTE6
MzUgQU0NCj4+IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4gQ2M6IHpoYW5nLmZlaTNA
enRlLmNvbS5jbjsgY2NhbXBAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBM
U1AgY29udHJvbCBpbiANCj4+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFz
c29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4NCj4+IEFzIEkgcmVhZCB0aGUgY3VycmVudCByZXYsIG5v
IHN1Y2ggbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBpcyBzcGVjaWZpZWQuDQo+PiAgTG9va3MgbGlr
ZSB5b3UgZ2V0IHRvIHByb3Bvc2Ugb25lIQ0KPj4NCj4+IExvdSAoYXMgV0cgcGFydGljaXBhbnQp
Lg0KPj4NCj4+IE9uIDgvMzEvMjAxMiA5OjQ5IEFNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3
cm90ZToNCj4+PiBIaSBMb3UsIEZlaSwNCj4+Pg0KPj4+IFdoZW4gYW4gKG9yaWdpbmF0aW5nKSBp
bmdyZXNzIG5vZGUgaXMgcHJvdmlzaW9uZWQgd2l0aCAiNSAoVEJEKSBTaW5nbGUgDQpTaWRlZCBB
c3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyAgKEEpIiBhbmQgd2lzaGVzIHRvIGNvbnRyb2wg
Ym90aCANCmZvcndhcmQgYW5kIHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIg
b2JqZWN0LCBJIHdvdWxkIHRoaW5rIA0KdGhhdCB0aGUgaW5ncmVzcyBub2RlIG5lZWRzIHRvIGtu
b3cgYWJvdXQgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3JzIA0KKHN1Y2ggYXMgc29mdCBwcmVl
bXB0aW9uIG9yIGFkbWlzc2lvbiBmYWlsdXJlKSBvbiB0aGUgcmV2ZXJzZSBMU1AuICBJcyANCnRo
ZXJlIGFueSB0ZXh0IHNvbWV3aGVyZSBpbiBhbiBSRkMvZHJhZnQgdGhhdCBkZXNjcmliZXMgaG93
IGEgbWlkLXBvaW50IA0Kbm9kZSBjYW4gc2VuZCB0aGUgc2lnbmFsaW5nIChwYXRoKSBlcnJvciB0
byB0aGUgb3JpZ2luYXRpbmcgaW5ncmVzcyBub2RlIA0KZm9yIHRoZSByZXZlcnNlIExTUD8gSXMg
dGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2UgUlNWUF9OT1RJRlkgbWVzc2FnZT8gDQpTb3JyeSBp
ZiBJIGhhZCBtaXNzZWQgYW55IHByZXZpb3VzIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NCj4+
Pg0KPj4+IFRoYW5rcywNCj4+PiBSYWtlc2gNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pg0K
Pj4NCj4+DQo+Pg0KPiANCj4gDQo+IA0KPiANCg0KDQo=
--=_alternative 000926A748257A78_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFJla2VzaCwgTG91PC9mb250
Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pjxmb250
IHNpemU9MiBjb2xvcj0jNGY4MWJkIGZhY2U9IkNhbGlicmkiPjxpPiZndDsNCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTcGVha2luZyBhcyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZl
bid0DQp0aG91Z2h0IGFib3V0IHRoaXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhv
ZCAzIHNlZW1zIHRvIGJlIG1vc3QNCmNvbnNpc3RlbnQgd2l0aCB0aGUgdXNhZ2Ugb2YgdGhlIFJF
VkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgcGF0aCBtZXNzYWdlLg0KJm5ic3A7UGVyaGFwcyBjb25z
aWRlciB1c2luZyB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2DQpk
aXJlY3Rpb24gdG8gYWxsb3cgdGhlIGVncmVzcy90YWlsIHRvIHByb3ZpZGUgdGhlIGluZ3Jlc3Mv
aGVhZCB3aXRoIGFyYml0cmFyeQ0KaW5mb3JtYXRpb24uLi4uPC9pPjwvZm9udD4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0O2ZlaSZndDtXZWxsLCBJIGNhbiBz
ZWUgb25lIG9mIHRoZQ0KYWR2YW50YWdlcyBvZiB0aGlzIHByb3Bvc2FsIGlzIHRoYXQgaXQgYWxs
b3dzIHRoZSBwb2xpY3kgY29udHJvbCBpbiB0aGUNCmVncmVzcy90YWlsLCB3aGVyZSBhIGRlY2lz
aW9uIGNhbiBiZSBtYWRlIHRoYXQgd2hldGhlciB0aGUgc2lnbmFsaW5nIGVycm9yDQpzaG91bGQg
YmUgcGFzc2VkIHRvIHRoZSBpbmdyZXNzL2hlYWQuIEJ1dCBpdCBjaGFuZ2VzIHRoZSBydWxlcyBk
ZWZpbmVkDQppbiBSRkMzNDczLi4uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgb3RoZXIgcHJvcG9zYWwNCmtl
ZXBzIGFsaWdubWVudCB3aXRoIFJGQzM0NzMsIGFuZCBJIHByZWZlciBpdCBpZiB0aGUgTFNQIGNv
bnRyb2wgaXMgdG90YWxseQ0KaW4gaGFuZCBvZiB0aGUgaW5ncmVzcy9oZWFkIChpbiBvdGhlciB3
b3JkcywgdGhlcmUgaXMgbm8gbW9yZSBpbmZvcm1hdGlvbg0KbmVlZHMgdGhlIGVncmVzL3RhaWwg
dG8gaW5mb3JtIHRoZSBpbmdyZXNzL2hlYWQpLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0
YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNp
emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSZx
dW90Ow0KJmx0O3JnYW5kaGlAY2lzY28uY29tJmd0OzwvYj4gPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDktMTMgMDg6NTM8L2ZvbnQ+DQo8dGQgd2lkdGg9
NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp
Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp
dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7emhhbmcuZmVpM0B6
dGUuY29tLmNuJnF1b3Q7ICZsdDt6aGFuZy5mZWkzQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRy
IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz
YW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z
LXNlcmlmIj4mcXVvdDtjY2FtcEBpZXRmLm9yZyZxdW90OyAmbHQ7Y2NhbXBAaWV0Zi5vcmcmZ3Q7
LA0KTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2ZvbnQ+DQo8dHIgdmFsaWdu
PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy
aWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi
PlJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAt
cnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0
YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N
Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJp
Ij5IaSBGZWksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNh
bGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNl
PSJDYWxpYnJpIj5QbGVhc2Ugc2VlIGlubGluZS4uJmx0O1JHJmd0Oy4uPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gemhhbmcuZmVpM0B6dGUu
Y29tLmNuIFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXQ0KPGI+PGJyPg0KU2VudDo8L2I+
IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDg6NDIgUE08Yj48YnI+DQpUbzo8L2I+IFJh
a2VzaCBHYW5kaGkgKHJnYW5kaGkpPGI+PGJyPg0KQ2M6PC9iPiBjY2FtcEBpZXRmLm9yZzsgTG91
IEJlcmdlcjxiPjxicj4NClN1YmplY3Q6PC9iPiBSRTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wg
aW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQu
dHh0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBSYWtlc2ggPC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiBJbiB0aGUgYWJzZW5jZSBvZiBzdWNoIG5vdGlmaWNh
dGlvbiByZXF1ZXN0LCBlZ3Jlc3Mgbm9kZSBTSE9VTEQgcmVsYXkNCnRoZSByZWNlaXZlZCBzaWdu
YWxpbmcgZXJyb3Igb24gdGhlIHJldmVyc2UgTFNQIHRvIHRoZSBpbmdyZXNzIG5vZGUgdXNpbmcN
CnRoZSBOT1RJRlkgbWVzc2FnZS4mcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt
c2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z
ZXJpZiI+PGJyPg0KJmx0O2ZlaSZndDsgJnF1b3Q7Tm90ZSB0aGF0IGEgTm90aWZ5IG1lc3NhZ2Ug
TVVTVCBOT1QgYmUgZ2VuZXJhdGVkIHVubGVzcw0KYW4gYXBwcm9wcmlhdGUgTm90aWZ5IFJlcXVl
c3Qgb2JqZWN0IGhhcyBiZWVuIHJlY2VpdmVkLiZxdW90OzwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj
ZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIG15IHVuZGVyc3Rh
bmRpbmcgaXMgY29ycmVjdCwgeW91ciBwcm9wb3NlZCByZWxheQ0KbWVjaGFuaXNtIGRvZXMgbm90
IGRlcGVuZCBvbiB0aGUgZXhpc3Rpbmcgb2YgdGhlIE5vdGlmeSBSZXF1ZXN0IG9iamVjdCwNCndo
aWNoIG1heSBjb25mbGljdCB3aXRoIHRoZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z
ZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48
YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVzY3JpcGl0b25zIGluIFJGQzM0NzMuIDwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9
MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw
OyBEbyB5b3Ugd2FudCB0byBjaGFuZ2UgdGhpcyBvciBkbyBJIGhhdmUgc29tZSBtaXN1bmRlcnN0
YW5kaW5nPw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJy
Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jNGY4MWJkIGZhY2U9IkNhbGlicmki
PiZsdDtSRyZndDsgWWVzIHlvdXIgdW5kZXJzdGFuZGluZw0KaXMgY29ycmVjdC4gJm5ic3A7Tk9U
SUZZIG1lc3NhZ2UgaW4gdGhpcyBjYXNlIGlzIGdlbmVyYXRlZCBiYXNlZCBvbiB0aGUNCnByZXNl
bmNlIG9mIHRoZSChsFJFVkVSU0VfTFNQobEgb2JqZWN0IGFuZCBhc3NvY2lhdGlvbiB0eXBlIKGw
U2luZ2xlDQpTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcy4gJm5ic3A7SSB1bmRl
cnN0YW5kIHdoYXQgeW91IGFyZSBzYXlpbmcNCnRob3VnaC4gRllJLCAmbmJzcDtMb3UgaGFkIGZv
bGxvd2luZyB0aG91Z2h0cyBvbiB0aGlzLiBEbyB5b3UgdGhpbmsgdGhpcw0Kc2ltcGxpZmllcyB0
aGluZ3MgPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzRmODFiZCBmYWNlPSJDYWxp
YnJpIj48aT4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7U3BlYWtpbmcg
YXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRoaXMgdG9vDQptdWNo
IHNvIG1heSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBtb3N0IGNvbnNpc3RlbnQg
d2l0aCB0aGUgdXNhZ2UNCm9mIHRoZSBSRVZFUlNFX0xTUCBPYmplY3QgaW4gdGhlIHBhdGggbWVz
c2FnZS4gJm5ic3A7UGVyaGFwcyBjb25zaWRlciB1c2luZw0KdGhlIFJFVkVSU0VfTFNQIE9iamVj
dCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24gdG8gYWxsb3cgdGhlIGVncmVzcy90YWls
DQp0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hlYWQgd2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24u
Li4uPGJyPg0KPC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzRmODFiZCBmYWNl
PSJDYWxpYnJpIj5UaGFua3MsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jNGY4MWJk
IGZhY2U9IkNhbGlicmkiPlJha2VzaDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9IzFm
NDk3ZCBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv
bG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSZWdhcmRzPC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij48YnI+DQpGZWk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8
L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk
dGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+JnF1b3Q7UmFrZXNoIEdhbmRoaSAo
cmdhbmRoaSkmcXVvdDsNCiZsdDs8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOnJnYW5kaGlAY2lz
Y28uY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48dT5yZ2FuZGhp
QGNpc2NvLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxi
PiZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjIwMTItMDkt
MTMgMDE6MjM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0K
PHRkIHdpZHRoPTYzJT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+
DQo8dGQgd2lkdGg9NiU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z
LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTMlPjxmb250IHNpemU9MSBm
YWNlPSJBcmlhbCI+TG91IEJlcmdlciAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmxiZXJnZXJA
bGFibi5uZXQ+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmxiZXJnZXJA
bGFibi5uZXQ8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZndDs8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10
b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm
Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7
PC9mb250PjxhIGhyZWY9bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj48Zm9udCBzaXplPTEg
Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9u
dD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDsNCiZsdDs8L2ZvbnQ+PGEgaHJl
Zj1tYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZh
Y2U9IkFyaWFsIj48dT56aGFuZy5mZWkzQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBz
aXplPTEgZmFjZT0iQXJpYWwiPiZndDssDQomcXVvdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2Nh
bXBAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmNjYW1w
QGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDsN
CiZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNv
bG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PmNjYW1wQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv
bnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z
LXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo
dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48
Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPlJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBk
cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQ8
L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
PC9mb250Pg0KPHA+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K
PHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy
Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIExvdSwgRmVpLCBXRyw8YnI+DQo8YnI+
DQpUaGFua3MgZm9yIHlvdXIgcmVwbGllcy4gTWF5IEkgcHJvcG9zZSBmb2xsb3dpbmcgdGV4dCB0
byBjb3ZlciB0aGlzIGNhc2U/DQpUaGlzIGFsbG93cyB0aGUgbWlkLXBvaW50IHNvbHV0aW9uIHdo
aWNoIGhhcyBhZHZhbnRhZ2VzIGJ1dCBnaXZlbiB0aGUgYWRkaXRpb25hbA0KY29tcGxleGl0eSBj
YW4gYmUgb3B0aW9uYWwuPGJyPg0KPGJyPg0KUGxlYXNlIGFkdmlzZS4gPGJyPg0KPGJyPg0KJnF1
b3Q7V2hlbiBhbiBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICZx
dW90O1NpbmdsZQ0KU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMmcXVvdDsgYW5k
IHdpc2hlcyB0byBjb250cm9sIGJvdGggZm9yd2FyZA0KYW5kIHJldmVyc2UgJm5ic3A7TFNQcyBi
eSBhZGRpbmcgJnF1b3Q7UkVWRVJTRV9MU1AmcXVvdDsgb2JqZWN0LCB0aGUgaW5ncmVzcw0Kbm9k
ZSBTSE9VTEQga25vdyB0aGUgc2lnbmFsaW5nIChwYXRoKSBlcnJvcnMgb24gdGhlIHJldmVyc2Ug
TFNQLiAmbmJzcDtBDQp0cmFuc2l0IG5vZGUgTUFZIGJlIHJlcXVlc3RlZCB0byBub3RpZnkgdGhl
IHNpZ25hbGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZQ0KTFNQIGJ5IHVzaW5nIHRoZSBOT1RJRlkg
bWVzc2FnZSBhbmQgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFJGQ1szNDczXS4gSW4NCnRoZSBhYnNl
bmNlIG9mIHN1Y2ggbm90aWZpY2F0aW9uIHJlcXVlc3QsIGVncmVzcyBub2RlIFNIT1VMRCByZWxh
eSB0aGUNCnJlY2VpdmVkIHNpZ25hbGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhl
IGluZ3Jlc3Mgbm9kZSB1c2luZyB0aGUNCk5PVElGWSBtZXNzYWdlLiZxdW90Ozxicj4NCjxicj4N
ClRoYW5rcyw8YnI+DQpSYWtlc2g8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTxicj4NCkZyb206IExvdSBCZXJnZXIgPC9mb250PjxhIGhyZWY9bWFpbHRvOlttYWls
dG86bGJlcmdlckBsYWJuLm5ldF0+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z
ZXJpZiI+PHU+W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XTwvdT48L2ZvbnQ+PC9hPjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy
IDEyLCAyMDEyIDEyOjE0IFBNPGJyPg0KVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpPGJyPg0K
Q2M6IDwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+PGZvbnQgc2l6
ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNu
PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjsNCjwvZm9udD48
YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl
PSJzYW5zLXNlcmlmIj48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNv
bnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s
c3AtMDQudHh0PGJyPg0KPGJyPg0KUmFrZXNoLDxicj4NCjxicj4NCjxicj4NCk9uIDkvMTIvMjAx
MiAxMTo1MiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6PGJyPg0KJmd0OyBUaGFu
a3MgTG91Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBBcmUgd2Ugb2sgaW4gZ2VuZXJhbCB0byB1c2Ug
Tk9USUZZIG1lc3NhZ2UgW1JGQzM0NzNdIGZvciB0aGlzPzxicj4NCjxicj4NCkknbSBub3Qgc3Bl
YWtpbmcgZm9yIHRoZSBXRywgYXMgbm90ZWQgbXkgY29tbWVudHMgd2VyZSBhcyBhIHBhcnRpY2lw
YW50Ljxicj4NCklNTyB5b3UnbGwgbmVlZCB0byBmdWxseSBkb2N1bWVudCB0aGUgcHJvcG9zYWws
IHBlcmhhcHMgZGlzY3VzcyBhbHRlcm5hdGl2ZXMNCmNvbnNpZGVyZWQsIGFuZCB0aGVuIGFzayB0
aGUgV0cgZm9yIGNvbmN1cnJlbmNlLjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbmUgYWR2
YW50YWdlIHdpdGggdGhlIG1pZC1wb2ludCBzZW5kaW5nIG5vdGlmaWNhdGlvbiBmb3IgdGhlIHJl
dmVyc2UNCjxicj4NCiZndDsgTFNQIGlzIHRoYXQgc2lnbmFsaW5nIGVycm9yIHByb3BhZ2F0aW9u
IHRpbWU8YnI+DQomZ3Q7IChtaWQtJmd0O2VncmVzcy1ub2RlLSZndDtpbmdyZXNzLW5vZGUpIGlz
IHNpZ25pZmljYW50bHkgcmVkdWNlZCAodG88YnI+DQomZ3Q7IG1pZC0mZ3Q7aW5ncmVzcy1ub2Rl
KSB3aGljaCBtYXkgYmUgcHJlZmVycmVkIGluIHNvbWUgY2FzZXMuPGJyPg0KPGJyPg0KRnJvbSBt
eSAocGVyc29uYWwpIHBlcnNwZWN0aXZlLCB0aGUgYWRkZWQgY29tcGxleGl0eSBpc24ndCB3b3J0
aCB0aGUgZWZmb3J0Lg0KJm5ic3A7T2YgY291cnNlLCBhIGRldGFpbGVkIHByb3Bvc2FsIG1heSBz
aG93IG90aGVyd2lzZS48YnI+DQo8YnI+DQpMb3U8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsg
VGhhbmtzLDxicj4NCiZndDsgUmFrZXNoPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IExvdSBCZXJnZXIgPC9m
b250PjxhIGhyZWY9bWFpbHRvOlttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0+PGZvbnQgc2l6ZT0y
IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0
XTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7
IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDk6MTUgQU08YnI+DQomZ3Q7IFRv
OiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKTxicj4NCiZndDsgQ2M6IDwvZm9udD48YSBocmVmPW1h
aWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i
c2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjsNCjwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBp
ZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5jY2Ft
cEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48
YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiA8YnI+DQom
Z3Q7IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0
LnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBSYWtlc2gsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NwZWFraW5n
DQphcyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQgdGhpcyB0b28gbXVj
aCBzbyBtYXkgYmUgb2ZmLA0KYnV0IG1ldGhvZCAzIHNlZW1zIHRvIGJlIG1vc3QgY29uc2lzdGVu
dCB3aXRoIHRoZSB1c2FnZSBvZiB0aGUgUkVWRVJTRV9MU1ANCk9iamVjdCBpbiB0aGUgcGF0aCBt
ZXNzYWdlLiAmbmJzcDtQZXJoYXBzIGNvbnNpZGVyIHVzaW5nIHRoZSBSRVZFUlNFX0xTUA0KT2Jq
ZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2IGRpcmVjdGlvbiB0byBhbGxvdyB0aGUgZWdyZXNzL3Rh
aWwgdG8gcHJvdmlkZQ0KdGhlIGluZ3Jlc3MvaGVhZCB3aXRoIGFyYml0cmFyeSBpbmZvcm1hdGlv
bi4uLi48YnI+DQomZ3Q7IDxicj4NCiZndDsgTG91PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDkv
MTEvMjAxMiA5OjIyIEFNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZTo8YnI+DQomZ3Q7
Jmd0OyBIaSBXRyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFueSB0aG91Z2h0cyBvbiB0
aGUgZm9sbG93aW5nIHByb3Bvc2FsPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtz
LDxicj4NCiZndDsmZ3Q7IFJha2VzaDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7IEZyb206IFJh
a2VzaCBHYW5kaGkgKHJnYW5kaGkpPGJyPg0KJmd0OyZndDsgU2VudDogVHVlc2RheSwgU2VwdGVt
YmVyIDA0LCAyMDEyIDE6MzYgUE08YnI+DQomZ3Q7Jmd0OyBUbzogJ0xvdSBCZXJnZXInPGJyPg0K
Jmd0OyZndDsgQ2M6IDwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+
PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhhbmcuZmVpM0B6
dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjsN
CjwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9
Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSRTog
UXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gPGJyPg0KJmd0OyZndDsgZHJhZnQtaWV0Zi1jY2Ft
cC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyBMb3UgZm9yIHlvdXIgcmVwbHkuPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBSRkMgMzQ3MyBkZWZpbmVzIHByb2NlZHVyZXMgZm9y
IE5PVElGWSByZXF1ZXN0IGFuZCByZXBseS4gV2UgY291bGQNCnVzZSB0aGlzIGZvciByZXZlcnNl
IExTUCBzaWduYWxpbmcgZXJyb3Igbm90aWZpY2F0aW9uIHRvIHRoZSBpbml0aWF0aW5nDQppbmdy
ZXNzIG5vZGUuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbHQ7Tm90aWZ5IG1lc3NhZ2Um
Z3Q7IDo6PSAmbHQ7Q29tbW9uIEhlYWRlciZndDsgWyZsdDtJTlRFR1JJVFkmZ3Q7XQ0KWyBbJmx0
O01FU1NBR0VfSURfQUNLJmd0OyB8ICZsdDtNRVNTQUdFX0lEX05BQ0smZ3Q7XSAuLi4gXTxicj4N
CiZndDsmZ3Q7ICZsdDtFUlJPUl9TUEVDJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyZndDsgJmx0O25v
dGlmeSBzZXNzaW9uIGxpc3QgOjo9ICZsdDt1cHN0cmVhbSBzZXNzaW9uJmd0OyAmbHQ7ZG93bnN0
cmVhbQ0Kc2Vzc2lvbiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgd2UgY2FuIHVzZSB0aGUgTk9USUZZIG1lc3NhZ2UuPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBNZXRob2QgMSAtIE1pZC1wb2ludCBhd2FyZSB3aXRo
IFBhdGggbWVzc2FnZSByZXF1ZXN0Ojxicj4NCiZndDsmZ3Q7IFdoZW4gYW4gZWdyZXNzIG5vZGUg
cmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsDQp0aGUgbm9k
ZSB3aWxsIGluc2VydCBOT1RJRllfUkVRIG1lc3NhZ2UgaW4gdGhlIHJldmVyc2UgTFNQIHBhdGgg
bWVzc2FnZQ0Kd2l0aCBub2RlIElEIG9mIHRoZSBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZS4gQSBt
aWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQNCiZuYnNwO2EgY29weSBvZiB0aGUgc2lnbmFsaW5nIGVy
cm9yIHRvIHRoZSBpbml0aWF0aW5nIG5vZGUgdXNpbmcgdGhlIE5PVElGWQ0KbWVzc2FnZS48YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElQdjQgTm90aWZ5IFJlcXVlc3QgT2JqZWN0PGJyPg0K
Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0lQdjQgTm90aWZ5IE5vZGUgQWRkcmVzczogMzIgYml0czxi
cj4NCiZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBu
b2RlIHRoYXQgc2hvdWxkIGJlDQpub3RpZmllZCB3aGVuIGdlbmVyYXRpbmcgYW4gZXJyb3IgbWVz
c2FnZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1ldGhvZCAyIC0gTWlkLXBvaW50IGF3
YXJlIHdpdGggUmVzdiBtZXNzYWdlIHJlcXVlc3Q6PGJyPg0KJmd0OyZndDsgV2hlbiBhbiBpbml0
aWF0aW5nIGluZ3Jlc3Mgbm9kZSByZWNlaXZlcyBhIFBhdGggbWVzc2FnZSBmb3IgYQ0KcmV2ZXJz
ZSBMU1AsIHRoZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUgcmV2
ZXJzZSBMU1ANClJlc3YgbWVzc2FnZSB3aXRoIGl0cyBvd24gbm9kZSBJRC4gQSBtaWQtcG9pbnQg
bm9kZSB3aWxsIHNlbmQgYSBjb3B5IG9mDQp0aGUgc2lnbmFsaW5nIGVycm9yIHRvIHRoZSBpbml0
aWF0aW5nIG5vZGUgdXNpbmcgdGhlIE5PVElGWSBtZXNzYWdlLjxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgTWV0aG9kIDMgLSBUYWlsLWVuZCByZWxheWluZyA6PGJyPg0KJmd0OyZndDsgV2hl
biBhbiBlZ3Jlc3Mgbm9kZSByZWNlaXZlcyBhIFBhdGggbWVzc2FnZSB3aXRoIFJFVkVSU0VfTFNQ
IG9iamVjdCwNCnRoZSBub2RlIHdpbGwgcmVsYXkgdGhlIHJlY2VpdmVkIHNpZ25hbGluZyBlcnJv
ciBtZXNzYWdlIG9uIHRoZSByZXZlcnNlDQpMU1AgdG8gdGhlIGluaXRpYWxpemluZyBpbmdyZXNz
IG5vZGUuIFRoZSBlZ3Jlc3Mgbm9kZSBjb3BpZXMgdGhlIHJlY2VpdmVkDQomcXVvdDtFUlJPUl9T
UEVDJnF1b3Q7IG9iamVjdCBpbnRvIGEgTk9USUZZIFtSRkMzNDczLCBzZWN0aW9uIDQuM10gbWVz
c2FnZQ0KYW5kIHNpZ25hbHMgaXQgdG8gdGhlIGluZ3Jlc3Mgbm9kZS4gSW4gdGhpcyBjYXNlLCBO
T1RJRllfUkVRIG1lc3NhZ2UgaXMNCm5vdCByZXF1aXJlZC4gPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyBQbGVhc2UgYWR2aXNlIHlvdXIgdGhvdWdodHMuPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsgUmFrZXNoPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9tOiBMb3UgQmVyZ2VyIDwvZm9udD48YSBocmVmPW1haWx0
bzpbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9
InNhbnMtc2VyaWYiPjx1PlttYWlsdG86bGJlcmdlckBsYWJuLm5ldF08L3U+PC9mb250PjwvYT48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KJmd0OyZndDsgU2VudDogVHVlc2Rh
eSwgU2VwdGVtYmVyIDA0LCAyMDEyIDExOjM1IEFNPGJyPg0KJmd0OyZndDsgVG86IFJha2VzaCBH
YW5kaGkgKHJnYW5kaGkpPGJyPg0KJmd0OyZndDsgQ2M6IDwvZm9udD48YSBocmVmPW1haWx0bzp6
aGFuZy5mZWkzQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z
ZXJpZiI+PHU+emhhbmcuZmVpM0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPjsNCjwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9y
Zz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5jY2FtcEBpZXRm
Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQom
Z3Q7Jmd0OyBTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gPGJyPg0KJmd0
OyZndDsgZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3At
MDQudHh0PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBcyBJIHJlYWQgdGhlIGN1cnJlbnQg
cmV2LCBubyBzdWNoIG5vdGlmaWNhdGlvbiBtZWNoYW5pc20gaXMgc3BlY2lmaWVkLjxicj4NCiZn
dDsmZ3Q7ICZuYnNwO0xvb2tzIGxpa2UgeW91IGdldCB0byBwcm9wb3NlIG9uZSE8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IExvdSAoYXMgV0cgcGFydGljaXBhbnQpLjxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgT24gOC8zMS8yMDEyIDk6NDkgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5k
aGkpIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyBIaSBMb3UsIEZlaSw8YnI+DQomZ3Q7Jmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZndDsgV2hlbiBhbiAob3JpZ2luYXRpbmcpIGluZ3Jlc3Mgbm9kZSBp
cyBwcm92aXNpb25lZCB3aXRoICZxdW90OzUNCihUQkQpICZuYnNwO1NpbmdsZSBTaWRlZCBBc3Nv
Y2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyAmbmJzcDsoQSkmcXVvdDsNCmFuZCB3aXNoZXMgdG8g
Y29udHJvbCBib3RoIGZvcndhcmQgYW5kIHJldmVyc2UgJm5ic3A7TFNQcyBieSBhZGRpbmcgJnF1
b3Q7UkVWRVJTRV9MU1AmcXVvdDsNCm9iamVjdCwgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBpbmdy
ZXNzIG5vZGUgbmVlZHMgdG8ga25vdyBhYm91dCB0aGUgc2lnbmFsaW5nDQoocGF0aCkgZXJyb3Jz
IChzdWNoIGFzIHNvZnQgcHJlZW1wdGlvbiBvciBhZG1pc3Npb24gZmFpbHVyZSkgb24gdGhlIHJl
dmVyc2UNCkxTUC4gJm5ic3A7SXMgdGhlcmUgYW55IHRleHQgc29tZXdoZXJlIGluIGFuIFJGQy9k
cmFmdCB0aGF0IGRlc2NyaWJlcyBob3cNCmEgbWlkLXBvaW50IG5vZGUgY2FuIHNlbmQgdGhlIHNp
Z25hbGluZyAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nDQppbmdyZXNzIG5vZGUgZm9y
IHRoZSByZXZlcnNlIExTUD8gSXMgdGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2UgUlNWUF9OT1RJ
RlkNCm1lc3NhZ2U/IFNvcnJ5IGlmIEkgaGFkIG1pc3NlZCBhbnkgcHJldmlvdXMgZGlzY3Vzc2lv
biBvbiB0aGlzIHRvcGljLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFu
a3MsPGJyPg0KJmd0OyZndDsmZ3Q7IFJha2VzaDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2Zv
bnQ+DQo8YnI+DQo=
--=_alternative 000926A748257A78_=--


From rgandhi@cisco.com  Wed Sep 12 18:57:22 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 B567221F863F for ; Wed, 12 Sep 2012 18:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.971
X-Spam-Level: 
X-Spam-Status: No, score=-7.971 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LajJ3SkCY-Sa for ; Wed, 12 Sep 2012 18:57:21 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8F21F863C for ; Wed, 12 Sep 2012 18:57:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45510; q=dns/txt; s=iport; t=1347501440; x=1348711040; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=04eEpdIyM2le5yM4tE13TyBixbetT0YrQS0UgpVvKIA=; b=LkJist73IAj1WeS+lq40HlaQQ7Vc3QytbOXK2J3VfcccOV0ZBbTtWMHA Ccf6lNXMHvlpxUXbtzFBPg4EhT/KzcCT/YjuUyM0UWImT7QSfbts3XD9v 1gQYaRMHrRhMYuKB86IzHYj/Kjn8uaNQMKqeGMo6cm0hx6lmcDKWBb0h4 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAEs8UVCtJV2Z/2dsb2JhbABFgkuDPLR1dIEHgiABAQEDARIBFAZMDAQCAQYCEQQBAQEKFgEGBQICMBQJCAIEDgUIEweHZQabYI0TCJMdixCFLDZgA6QVgWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,413,1344211200";  d="scan'208,217";a="121075221"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 13 Sep 2012 01:57:19 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8D1vJt2015792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 01:57:19 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 20:57:19 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: "zhang.fei3@zte.com.cn" 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObAAASWMgAAIiywQAAku1IAACmMi4P//vSoAgABP6SA=
Date: Thu, 13 Sep 2012 01:57:18 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.000
x-tm-as-result: No--58.694000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_B7D2A316AA32B6469D9670B6A81B7C24098A1Exmbalnx07ciscocom_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 01:57:22 -0000

--_000_B7D2A316AA32B6469D9670B6A81B7C24098A1Exmbalnx07ciscocom_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgRmVpLA0KDQpJIHNlZSB3aGF0IHlvdSBhcmUgc2F5aW5nLiBSZXdvcmRpbmcgdGhlIHRleHQg
dG8gcmVmbGVjdCB0aGlzIChub3Qgc3VyZSBhYm91dCChsFNIT1VMRKGxIHdvcmQgdXNhZ2UpOg0K
DQpXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggIlNp
bmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyIgYW5kIHdpc2hlcyB0byBj
b250cm9sIGJvdGggZm9yd2FyZCBhbmQgcmV2ZXJzZSBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9M
U1AiIG9iamVjdCwgdGhlIGluZ3Jlc3Mgbm9kZSBTSE9VTEQga25vdyB0aGUgc2lnbmFsaW5nIChw
YXRoKSBlcnJvcnMgb24gdGhlIHJldmVyc2UgTFNQLiBUcmFuc2l0IGFuZCBlZ3Jlc3Mgbm9kZXMg
U0hPVUxEIGJlIHJlcXVlc3RlZCB0byBub3RpZnkgdGhlIHNpZ25hbGluZyBlcnJvciBvbiB0aGUg
cmV2ZXJzZSBMU1AgYnkgdXNpbmcgdGhlIE5PVElGWSBtZXNzYWdlIGFuZCBwcm9jZWR1cmVzIGRl
ZmluZWQgaW4gUkZDWzM0NzNdLg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCkZyb206IHpoYW5n
LmZlaTNAenRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0NClNlbnQ6IFdl
ZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDk6NDAgUE0NClRvOiBSYWtlc2ggR2FuZGhpIChy
Z2FuZGhpKQ0KQ2M6IGNjYW1wQGlldGYub3JnOyBMb3UgQmVyZ2VyDQpTdWJqZWN0OiBSRTogUXVl
c3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1l
eHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQoNCg0KSGkgUmVrZXNoLCBMb3UNCg0KID4gICAgICAg
ICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRo
aXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhvZCAzIHNlZW1zIHRvIGJlIG1vc3Qg
Y29uc2lzdGVudCB3aXRoIHRoZSB1c2FnZSBvZiB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRo
ZSBwYXRoIG1lc3NhZ2UuICBQZXJoYXBzIGNvbnNpZGVyIHVzaW5nIHRoZSBSRVZFUlNFX0xTUCBP
YmplY3QgaW4gdGhlIHVwc3RyZWFtL1Jlc3YgZGlyZWN0aW9uIHRvIGFsbG93IHRoZSBlZ3Jlc3Mv
dGFpbCB0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hlYWQgd2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRp
b24uLi4uDQoNCjxmZWk+V2VsbCwgSSBjYW4gc2VlIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0
aGlzIHByb3Bvc2FsIGlzIHRoYXQgaXQgYWxsb3dzIHRoZSBwb2xpY3kgY29udHJvbCBpbiB0aGUg
ZWdyZXNzL3RhaWwsIHdoZXJlIGEgZGVjaXNpb24gY2FuIGJlIG1hZGUgdGhhdCB3aGV0aGVyIHRo
ZSBzaWduYWxpbmcgZXJyb3Igc2hvdWxkIGJlIHBhc3NlZCB0byB0aGUgaW5ncmVzcy9oZWFkLiBC
dXQgaXQgY2hhbmdlcyB0aGUgcnVsZXMgZGVmaW5lZCBpbiBSRkMzNDczLi4uLg0KDQogICAgIFRo
ZSBvdGhlciBwcm9wb3NhbCBrZWVwcyBhbGlnbm1lbnQgd2l0aCBSRkMzNDczLCBhbmQgSSBwcmVm
ZXIgaXQgaWYgdGhlIExTUCBjb250cm9sIGlzIHRvdGFsbHkgaW4gaGFuZCBvZiB0aGUgaW5ncmVz
cy9oZWFkIChpbiBvdGhlciB3b3JkcywgdGhlcmUgaXMgbm8gbW9yZSBpbmZvcm1hdGlvbiBuZWVk
cyB0aGUgZWdyZXMvdGFpbCB0byBpbmZvcm0gdGhlIGluZ3Jlc3MvaGVhZCkuDQoNCiJSYWtlc2gg
R2FuZGhpIChyZ2FuZGhpKSIgPHJnYW5kaGlAY2lzY28uY29tPG1haWx0bzpyZ2FuZGhpQGNpc2Nv
LmNvbT4+DQoNCjIwMTItMDktMTMgMDg6NTMNCg0KytW8/sjLDQoNCiJ6aGFuZy5mZWkzQHp0ZS5j
b20uY248bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4iIDx6aGFuZy5mZWkzQHp0ZS5jb20u
Y248bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4+DQoNCrOty80NCg0KImNjYW1wQGlldGYu
b3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4iIDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBA
aWV0Zi5vcmc+PiwgTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldDxtYWlsdG86bGJlcmdlckBs
YWJuLm5ldD4+DQoNCtb3zOINCg0KUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIGRyYWZ0
LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KDQoN
Cg0KDQoNCg0KDQpIaSBGZWksDQoNClBsZWFzZSBzZWUgaW5saW5lLi48Ukc+Li4NCg0KRnJvbTog
emhhbmcuZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+IFttYWls
dG86emhhbmcuZmVpM0B6dGUuY29tLmNuXTxtYWlsdG86W21haWx0bzp6aGFuZy5mZWkzQHp0ZS5j
b20uY25dPg0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgODo0MiBQTQ0KVG86
IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1w
QGlldGYub3JnPjsgTG91IEJlcmdlcg0KU3ViamVjdDogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250
cm9sIGluIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw
LTA0LnR4dA0KDQoNCkhpIFJha2VzaA0KDQpJbiB0aGUgYWJzZW5jZSBvZiBzdWNoIG5vdGlmaWNh
dGlvbiByZXF1ZXN0LCBlZ3Jlc3Mgbm9kZSBTSE9VTEQgcmVsYXkgdGhlIHJlY2VpdmVkIHNpZ25h
bGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mgbm9kZSB1c2luZyB0
aGUgTk9USUZZIG1lc3NhZ2UuIg0KDQo8ZmVpPiAiTm90ZSB0aGF0IGEgTm90aWZ5IG1lc3NhZ2Ug
TVVTVCBOT1QgYmUgZ2VuZXJhdGVkIHVubGVzcyBhbiBhcHByb3ByaWF0ZSBOb3RpZnkgUmVxdWVz
dCBvYmplY3QgaGFzIGJlZW4gcmVjZWl2ZWQuIg0KDQogICAgICBJZiBteSB1bmRlcnN0YW5kaW5n
IGlzIGNvcnJlY3QsIHlvdXIgcHJvcG9zZWQgcmVsYXkgbWVjaGFuaXNtIGRvZXMgbm90IGRlcGVu
ZCBvbiB0aGUgZXhpc3Rpbmcgb2YgdGhlIE5vdGlmeSBSZXF1ZXN0IG9iamVjdCwgd2hpY2ggbWF5
IGNvbmZsaWN0IHdpdGggdGhlDQogICAgICBkZXNjcmlwaXRvbnMgaW4gUkZDMzQ3My4NCg0KICAg
ICAgRG8geW91IHdhbnQgdG8gY2hhbmdlIHRoaXMgb3IgZG8gSSBoYXZlIHNvbWUgbWlzdW5kZXJz
dGFuZGluZz8NCg0KPFJHPiBZZXMgeW91ciB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QuICBOT1RJ
RlkgbWVzc2FnZSBpbiB0aGlzIGNhc2UgaXMgZ2VuZXJhdGVkIGJhc2VkIG9uIHRoZSBwcmVzZW5j
ZSBvZiB0aGUgobBSRVZFUlNFX0xTUKGxIG9iamVjdCBhbmQgYXNzb2NpYXRpb24gdHlwZSChsFNp
bmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcy4gIEkgdW5kZXJzdGFuZCB3
aGF0IHlvdSBhcmUgc2F5aW5nIHRob3VnaC4gRllJLCAgTG91IGhhZCBmb2xsb3dpbmcgdGhvdWdo
dHMgb24gdGhpcy4gRG8geW91IHRoaW5rIHRoaXMgc2ltcGxpZmllcyB0aGluZ3MgPw0KPiAgICAg
ICAgICBTcGVha2luZyBhcyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQg
dGhpcyB0b28gbXVjaCBzbyBtYXkgYmUgb2ZmLCBidXQgbWV0aG9kIDMgc2VlbXMgdG8gYmUgbW9z
dCBjb25zaXN0ZW50IHdpdGggdGhlIHVzYWdlIG9mIHRoZSBSRVZFUlNFX0xTUCBPYmplY3QgaW4g
dGhlIHBhdGggbWVzc2FnZS4gIFBlcmhhcHMgY29uc2lkZXIgdXNpbmcgdGhlIFJFVkVSU0VfTFNQ
IE9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24gdG8gYWxsb3cgdGhlIGVncmVz
cy90YWlsIHRvIHByb3ZpZGUgdGhlIGluZ3Jlc3MvaGVhZCB3aXRoIGFyYml0cmFyeSBpbmZvcm1h
dGlvbi4uLi4NCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KDQpSZWdhcmRzDQoNCkZlaQ0KIlJha2Vz
aCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNjby5jb208bWFpbHRvOnJnYW5kaGlAY2lz
Y28uY29tPj4NCg0KMjAxMi0wOS0xMyAwMToyMw0KDQoNCsrVvP7Iyw0KDQpMb3UgQmVyZ2VyIDxs
YmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4NCg0Ks63LzQ0KDQoiemhh
bmcuZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+IiA8emhhbmcu
ZmVpM0B6dGUuY29tLmNuPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+PiwgImNjYW1wQGll
dGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4iIDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2Nh
bXBAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBk
cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIaSBMb3UsIEZlaSwgV0csDQoNClRoYW5rcyBmb3IgeW91
ciByZXBsaWVzLiBNYXkgSSBwcm9wb3NlIGZvbGxvd2luZyB0ZXh0IHRvIGNvdmVyIHRoaXMgY2Fz
ZT8gVGhpcyBhbGxvd3MgdGhlIG1pZC1wb2ludCBzb2x1dGlvbiB3aGljaCBoYXMgYWR2YW50YWdl
cyBidXQgZ2l2ZW4gdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0eSBjYW4gYmUgb3B0aW9uYWwuDQoN
ClBsZWFzZSBhZHZpc2UuDQoNCiJXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIGlzIHBy
b3Zpc2lvbmVkIHdpdGggIlNpbmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQ
cyIgYW5kIHdpc2hlcyB0byBjb250cm9sIGJvdGggZm9yd2FyZCBhbmQgcmV2ZXJzZSAgTFNQcyBi
eSBhZGRpbmcgIlJFVkVSU0VfTFNQIiBvYmplY3QsIHRoZSBpbmdyZXNzIG5vZGUgU0hPVUxEIGtu
b3cgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZlcnNlIExTUC4gIEEgdHJh
bnNpdCBub2RlIE1BWSBiZSByZXF1ZXN0ZWQgdG8gbm90aWZ5IHRoZSBzaWduYWxpbmcgZXJyb3Ig
b24gdGhlIHJldmVyc2UgTFNQIGJ5IHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZSBhbmQgcHJvY2Vk
dXJlcyBkZWZpbmVkIGluIFJGQ1szNDczXS4gSW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBub3RpZmlj
YXRpb24gcmVxdWVzdCwgZWdyZXNzIG5vZGUgU0hPVUxEIHJlbGF5IHRoZSByZWNlaXZlZCBzaWdu
YWxpbmcgZXJyb3Igb24gdGhlIHJldmVyc2UgTFNQIHRvIHRoZSBpbmdyZXNzIG5vZGUgdXNpbmcg
dGhlIE5PVElGWSBtZXNzYWdlLiINCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0
XTxtYWlsdG86W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XT4NClNlbnQ6IFdlZG5lc2RheSwgU2Vw
dGVtYmVyIDEyLCAyMDEyIDEyOjE0IFBNDQpUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCkNj
OiB6aGFuZy5mZWkzQHp0ZS5jb20uY248bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj47IGNj
YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBRdWVzdGlv
biBvbiBMU1AgY29udHJvbCBpbiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1h
c3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KUmFrZXNoLA0KDQoNCk9uIDkvMTIvMjAxMiAxMTo1MiBB
TSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+IFRoYW5rcyBMb3UuDQo+DQo+IEFy
ZSB3ZSBvayBpbiBnZW5lcmFsIHRvIHVzZSBOT1RJRlkgbWVzc2FnZSBbUkZDMzQ3M10gZm9yIHRo
aXM/DQoNCkknbSBub3Qgc3BlYWtpbmcgZm9yIHRoZSBXRywgYXMgbm90ZWQgbXkgY29tbWVudHMg
d2VyZSBhcyBhIHBhcnRpY2lwYW50Lg0KSU1PIHlvdSdsbCBuZWVkIHRvIGZ1bGx5IGRvY3VtZW50
IHRoZSBwcm9wb3NhbCwgcGVyaGFwcyBkaXNjdXNzIGFsdGVybmF0aXZlcyBjb25zaWRlcmVkLCBh
bmQgdGhlbiBhc2sgdGhlIFdHIGZvciBjb25jdXJyZW5jZS4NCg0KPg0KPiBPbmUgYWR2YW50YWdl
IHdpdGggdGhlIG1pZC1wb2ludCBzZW5kaW5nIG5vdGlmaWNhdGlvbiBmb3IgdGhlIHJldmVyc2UN
Cj4gTFNQIGlzIHRoYXQgc2lnbmFsaW5nIGVycm9yIHByb3BhZ2F0aW9uIHRpbWUNCj4gKG1pZC0+
ZWdyZXNzLW5vZGUtPmluZ3Jlc3Mtbm9kZSkgaXMgc2lnbmlmaWNhbnRseSByZWR1Y2VkICh0bw0K
PiBtaWQtPmluZ3Jlc3Mtbm9kZSkgd2hpY2ggbWF5IGJlIHByZWZlcnJlZCBpbiBzb21lIGNhc2Vz
Lg0KDQpGcm9tIG15IChwZXJzb25hbCkgcGVyc3BlY3RpdmUsIHRoZSBhZGRlZCBjb21wbGV4aXR5
IGlzbid0IHdvcnRoIHRoZSBlZmZvcnQuICBPZiBjb3Vyc2UsIGEgZGV0YWlsZWQgcHJvcG9zYWwg
bWF5IHNob3cgb3RoZXJ3aXNlLg0KDQpMb3UNCg0KPg0KPiBUaGFua3MsDQo+IFJha2VzaA0KPg0K
Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWls
dG86bGJlcmdlckBsYWJuLm5ldF08bWFpbHRvOlttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0+DQo+
IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDk6MTUgQU0NCj4gVG86IFJha2Vz
aCBHYW5kaGkgKHJnYW5kaGkpDQo+IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY248bWFpbHRvOnpo
YW5nLmZlaTNAenRlLmNvbS5jbj47IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9y
Zz4NCj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluDQo+IGRyYWZ0LWll
dGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPg0KPiBS
YWtlc2gsDQo+ICAgICAgICAgICAgICAgICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQsIEkg
aGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRoaXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1l
dGhvZCAzIHNlZW1zIHRvIGJlIG1vc3QgY29uc2lzdGVudCB3aXRoIHRoZSB1c2FnZSBvZiB0aGUg
UkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSBwYXRoIG1lc3NhZ2UuICBQZXJoYXBzIGNvbnNpZGVy
IHVzaW5nIHRoZSBSRVZFUlNFX0xTUCBPYmplY3QgaW4gdGhlIHVwc3RyZWFtL1Jlc3YgZGlyZWN0
aW9uIHRvIGFsbG93IHRoZSBlZ3Jlc3MvdGFpbCB0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hlYWQg
d2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24uLi4uDQo+DQo+IExvdQ0KPg0KPiBPbiA5LzExLzIw
MTIgOToyMiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+PiBIaSBXRywNCj4+
DQo+PiBBbnkgdGhvdWdodHMgb24gdGhlIGZvbGxvd2luZyBwcm9wb3NhbD8NCj4+DQo+PiBUaGFu
a3MsDQo+PiBSYWtlc2gNCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+
IEZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1i
ZXIgMDQsIDIwMTIgMTozNiBQTQ0KPj4gVG86ICdMb3UgQmVyZ2VyJw0KPj4gQ2M6IHpoYW5nLmZl
aTNAenRlLmNvbS5jbjxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjsgY2NhbXBAaWV0Zi5v
cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIG9uIExT
UCBjb250cm9sIGluDQo+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3Nv
Y2lhdGVkLWxzcC0wNC50eHQNCj4+DQo+Pg0KPj4gVGhhbmtzIExvdSBmb3IgeW91ciByZXBseS4N
Cj4+DQo+PiBSRkMgMzQ3MyBkZWZpbmVzIHByb2NlZHVyZXMgZm9yIE5PVElGWSByZXF1ZXN0IGFu
ZCByZXBseS4gV2UgY291bGQgdXNlIHRoaXMgZm9yIHJldmVyc2UgTFNQIHNpZ25hbGluZyBlcnJv
ciBub3RpZmljYXRpb24gdG8gdGhlIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlLg0KPj4NCj4+IDxO
b3RpZnkgbWVzc2FnZT4gOjo9IDxDb21tb24gSGVhZGVyPiBbPElOVEVHUklUWT5dIFsgWzxNRVNT
QUdFX0lEX0FDSz4gfCA8TUVTU0FHRV9JRF9OQUNLPl0gLi4uIF0NCj4+IDxFUlJPUl9TUEVDPg0K
Pj4gPG5vdGlmeSBzZXNzaW9uIGxpc3QgOjo9IDx1cHN0cmVhbSBzZXNzaW9uPiA8ZG93bnN0cmVh
bSBzZXNzaW9uPiAgPg0KPj4NCj4+IFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHdlIGNhbiB1c2Ug
dGhlIE5PVElGWSBtZXNzYWdlLg0KPj4NCj4+IE1ldGhvZCAxIC0gTWlkLXBvaW50IGF3YXJlIHdp
dGggUGF0aCBtZXNzYWdlIHJlcXVlc3Q6DQo+PiBXaGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVz
IGEgUGF0aCBtZXNzYWdlIHdpdGggUkVWRVJTRV9MU1Agb2JqZWN0LCB0aGUgbm9kZSB3aWxsIGlu
c2VydCBOT1RJRllfUkVRIG1lc3NhZ2UgaW4gdGhlIHJldmVyc2UgTFNQIHBhdGggbWVzc2FnZSB3
aXRoIG5vZGUgSUQgb2YgdGhlIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlLiBBIG1pZC1wb2ludCBu
b2RlIHdpbGwgc2VuZCAgYSBjb3B5IG9mIHRoZSBzaWduYWxpbmcgZXJyb3IgdG8gdGhlIGluaXRp
YXRpbmcgbm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UuDQo+Pg0KPj4gSVB2NCBOb3RpZnkg
UmVxdWVzdCBPYmplY3QNCj4+ICAgIElQdjQgTm90aWZ5IE5vZGUgQWRkcmVzczogMzIgYml0cw0K
Pj4gICAgICAgVGhlIElQIGFkZHJlc3Mgb2YgdGhlIG5vZGUgdGhhdCBzaG91bGQgYmUgbm90aWZp
ZWQgd2hlbiBnZW5lcmF0aW5nIGFuIGVycm9yIG1lc3NhZ2UuDQo+Pg0KPj4gTWV0aG9kIDIgLSBN
aWQtcG9pbnQgYXdhcmUgd2l0aCBSZXN2IG1lc3NhZ2UgcmVxdWVzdDoNCj4+IFdoZW4gYW4gaW5p
dGlhdGluZyBpbmdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2UgZm9yIGEgcmV2ZXJz
ZSBMU1AsIHRoZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUgcmV2
ZXJzZSBMU1AgUmVzdiBtZXNzYWdlIHdpdGggaXRzIG93biBub2RlIElELiBBIG1pZC1wb2ludCBu
b2RlIHdpbGwgc2VuZCBhIGNvcHkgb2YgdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5pdGlh
dGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4+DQo+PiBNZXRob2QgMyAtIFRh
aWwtZW5kIHJlbGF5aW5nIDoNCj4+IFdoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRo
IG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsIHRoZSBub2RlIHdpbGwgcmVsYXkgdGhl
IHJlY2VpdmVkIHNpZ25hbGluZyBlcnJvciBtZXNzYWdlIG9uIHRoZSByZXZlcnNlIExTUCB0byB0
aGUgaW5pdGlhbGl6aW5nIGluZ3Jlc3Mgbm9kZS4gVGhlIGVncmVzcyBub2RlIGNvcGllcyB0aGUg
cmVjZWl2ZWQgIkVSUk9SX1NQRUMiIG9iamVjdCBpbnRvIGEgTk9USUZZIFtSRkMzNDczLCBzZWN0
aW9uIDQuM10gbWVzc2FnZSBhbmQgc2lnbmFscyBpdCB0byB0aGUgaW5ncmVzcyBub2RlLiBJbiB0
aGlzIGNhc2UsIE5PVElGWV9SRVEgbWVzc2FnZSBpcyBub3QgcmVxdWlyZWQuDQo+Pg0KPj4gUGxl
YXNlIGFkdmlzZSB5b3VyIHRob3VnaHRzLg0KPj4NCj4+IFRoYW5rcywNCj4+IFJha2VzaA0KPj4N
Cj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IExvdSBCZXJn
ZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XTxtYWlsdG86W21haWx0bzpsYmVyZ2VyQGxhYm4u
bmV0XT4NCj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMTozNSBBTQ0KPj4g
VG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+PiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNu
PG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+OyBjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2Nh
bXBAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4N
Cj4+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0
LnR4dA0KPj4NCj4+IEFzIEkgcmVhZCB0aGUgY3VycmVudCByZXYsIG5vIHN1Y2ggbm90aWZpY2F0
aW9uIG1lY2hhbmlzbSBpcyBzcGVjaWZpZWQuDQo+PiAgTG9va3MgbGlrZSB5b3UgZ2V0IHRvIHBy
b3Bvc2Ugb25lIQ0KPj4NCj4+IExvdSAoYXMgV0cgcGFydGljaXBhbnQpLg0KPj4NCj4+IE9uIDgv
MzEvMjAxMiA5OjQ5IEFNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+PiBIaSBM
b3UsIEZlaSwNCj4+Pg0KPj4+IFdoZW4gYW4gKG9yaWdpbmF0aW5nKSBpbmdyZXNzIG5vZGUgaXMg
cHJvdmlzaW9uZWQgd2l0aCAiNSAoVEJEKSAgU2luZ2xlIFNpZGVkIEFzc29jaWF0ZWQgQmlkaXJl
Y3Rpb25hbCBMU1BzICAoQSkiIGFuZCB3aXNoZXMgdG8gY29udHJvbCBib3RoIGZvcndhcmQgYW5k
IHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIgb2JqZWN0LCBJIHdvdWxkIHRo
aW5rIHRoYXQgdGhlIGluZ3Jlc3Mgbm9kZSBuZWVkcyB0byBrbm93IGFib3V0IHRoZSBzaWduYWxp
bmcgKHBhdGgpIGVycm9ycyAoc3VjaCBhcyBzb2Z0IHByZWVtcHRpb24gb3IgYWRtaXNzaW9uIGZh
aWx1cmUpIG9uIHRoZSByZXZlcnNlIExTUC4gIElzIHRoZXJlIGFueSB0ZXh0IHNvbWV3aGVyZSBp
biBhbiBSRkMvZHJhZnQgdGhhdCBkZXNjcmliZXMgaG93IGEgbWlkLXBvaW50IG5vZGUgY2FuIHNl
bmQgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nIGluZ3Jlc3Mg
bm9kZSBmb3IgdGhlIHJldmVyc2UgTFNQPyBJcyB0aGVyZSBhbiBhc3N1bXB0aW9uIHRvIHVzZSBS
U1ZQX05PVElGWSBtZXNzYWdlPyBTb3JyeSBpZiBJIGhhZCBtaXNzZWQgYW55IHByZXZpb3VzIGRp
c2N1c3Npb24gb24gdGhpcyB0b3BpYy4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBSYWtlc2gNCj4+
Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPg0KPg0KPg0KPg0K

--_000_B7D2A316AA32B6469D9670B6A81B7C24098A1Exmbalnx07ciscocom_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Fei,=



 <=
/p>

I see what you are saying=
. Rewording the text to reflect this (not sure about =A1=B0SHOULD=A1=B1 wor=
d usage):


 <=
/p>

When an initiating ingress node is provis=
ioned with "Single Sided Associated Bidirectional LSPs" and wishe=
s to control both forward and reverse LSPs by adding "REVERSE_LSP"=
;
 object, the ingress node SHOULD know the signaling (path) errors on the re=
verse LSP. Transit and egress nodes SHOULD be requested to notify the signa=
ling error on the reverse LSP by using the NOTIFY message and procedures de=
fined in RFC[3473].


 


 <=
/p>

Thanks,=



Rakesh<=
/p>

 <=
/p>

 <=
/p>

From: zhang.fe=
i3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]


Sent: Wednesday, September 12, 2012 9:40 PM

To: Rakesh Gandhi (rgandhi)

Cc: ccamp@ietf.org; Lou Berger

Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsv=
pte-ext-associated-lsp-04.txt


 




Hi Rekesh, Lou




 >     &nb=
sp;    Speaking as WG participant, I haven't thought about this t=
oo much so may be off, but method
 3 seems to be most consistent with the usage of the REVERSE_LSP Object in =
the path message.  Perhaps consider using the REVERSE_LSP Object in th=
e upstream/Resv direction to allow the egress/tail to provide the ingress/h=
ead with arbitrary information....




<fei>Well, I can see one of the advantages of this proposa=
l is that it allows the policy control in the egress/tail, where a decision=
 can be made that whether the signaling error should be passed
 to the ingress/head. But it changes the rules defined in RFC3473.... 



     The other proposal keeps alignment with RFC3=
473, and I prefer it if the LSP control is totally in hand of the ingress/h=
ead (in other words, there is no more information needs the egres/tail
 to inform the ingress/head). 












"Rakesh Gandhi (rgandhi)" <=
;rgandhi@cisco.com><=
span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri=
f"">



2012-09-13 08:53











=CA=D5=BC=FE=C8=CB<=
/p>




"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>









=B3=AD=CB=CD




"cc=
amp@ietf.org" <ccamp@ietf.org=
>, Lou Berger <lberger@labn.n=
et>









=D6=F7=CC=E2




RE: Question on LSP control in draft-ietf-=
ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt








 


























Hi Fei,


 


Please see inline..<RG>..


 


From:
zhang.fei3@zte.com.cn 
[mailto:zhang.fei3@zte.com.cn] 

Sent: Wednesday, September 12, 2012 8:42 PM

To: Rakesh Gandhi (rgandhi)

Cc: ccamp@ietf.org; Lou Berger=


Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte=
-ext-associated-lsp-04.txt


 =
 



Hi Rakesh 



In the absence of such notification request, egress node SHOULD relay the r=
eceived signaling error on the reverse LSP to the ingress node using the NO=
TIFY message."




<fei> "Note that a Notify message MUST NOT be generated unless a=
n appropriate Notify Request object has been received."




      If my understanding is correct, your proposed relay me=
chanism does not depend on the existing of the Notify Request object, which=
 may conflict with the


      descripitons in RFC3473. 



      Do you want to change this or do I have some misunders=
tanding?  




<RG> Yes your understanding is correct. &n=
bsp;NOTIFY message in this case is generated based on the presence of the =
=A1=B0REVERSE_LSP=A1=B1 object and association type =A1=B0Single Sided Asso=
ciated
 Bidirectional LSPs.  I understand what you are saying though. FYI, &n=
bsp;Lou had following thoughts on this. Do you think this simplifies things=
 ?


>          Speaki=
ng as WG participant, I haven't thought about this too much so may be off, =
but method 3 seems to be most consistent with the usage of the REVERSE_LSP =
Object
 in the path message.  Perhaps consider using the REVERSE_LSP Object i=
n the upstream/Resv direction to allow the egress/tail to provide the ingre=
ss/head with arbitrary information....



Thanks,


Rakesh


  

 




Regards 



Fei 








"Rakesh Gandhi (rgandhi)" <=
;rgandhi@cisco=
.com>



2012-09-13 01:23





 








=CA=D5=BC=FE=C8=CB<=
/p>




Lou Berger <lberger@labn.net><=
span style=3D"font-family:"Arial","sans-serif"">









=B3=AD=CB=CD




"zhang.fei3@zte.com.cn"
 <zhang.fei3@z=
te.com.cn>, "ccamp@ietf.org"
 <ccamp@ietf.org>









=D6=F7=CC=E2




RE: Question on LSP control in draft-ietf-=
ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt










 =
 


 






























Hi Lou, Fei, WG,



Thanks for your replies. May I propose following text to cover this case? T=
his allows the mid-point solution which has advantages but given the additi=
onal complexity can be optional.



Please advise. 



"When an initiating ingress node is provisioned with "Single Side=
d Associated Bidirectional LSPs" and wishes to control both forward an=
d reverse  LSPs by adding "REVERSE_LSP" object, the ingress =
node SHOULD know the signaling (path) errors on the reverse LSP.
  A transit node MAY be requested to notify the signaling error on the=
 reverse LSP by using the NOTIFY message and procedures defined in RFC[3473=
]. In the absence of such notification request, egress node SHOULD relay th=
e received signaling error on the reverse
 LSP to the ingress node using the NOTIFY message."



Thanks,

Rakesh





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

From: Lou Berger [mailto:lberger@labn.net]


Sent: Wednesday, September 12, 2012 12:14 PM

To: Rakesh Gandhi (rgandhi)

Cc: zhang.fei3@z=
te.com.cn;
ccamp@ietf.org

Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext=
-associated-lsp-04.txt



Rakesh,





On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:

> Thanks Lou.

> 

> Are we ok in general to use NOTIFY message [RFC3473] for this?



I'm not speaking for the WG, as noted my comments were as a participant.
IMO you'll need to fully document the proposal, perhaps discuss alternative=
s considered, and then ask the WG for concurrence.



> 

> One advantage with the mid-point sending notification for the reverse =


> LSP is that signaling error propagation time

> (mid->egress-node->ingress-node) is significantly reduced (to
> mid->ingress-node) which may be preferred in some cases.



>From my (personal) perspective, the added complexity isn't worth the effort=
.  Of course, a detailed proposal may show otherwise.



Lou



> 

> Thanks,

> Rakesh

> 

> 

> -----Original Message-----

> From: Lou Berger <=
span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser=
if"">[mailto:lberger@labn.net]

> Sent: Wednesday, September 12, 2012 9:15 AM

> To: Rakesh Gandhi (rgandhi)

> Cc: zhang.f=
ei3@zte.com.cn;
ccamp@ietf.org

> Subject: Re: Question on LSP control in 

> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

> 

> Rakesh,

>                  Speaking=
 as WG participant, I haven't thought about this too much so may be off, bu=
t method 3 seems to be most consistent with the usage of the REVERSE_LSP Ob=
ject in the path message.  Perhaps consider using the REVERSE_LSP Obje=
ct in the
 upstream/Resv direction to allow the egress/tail to provide the ingress/he=
ad with arbitrary information....

> 

> Lou

> 

> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:

>> Hi WG,

>>

>> Any thoughts on the following proposal?

>>

>> Thanks,

>> Rakesh

>>

>>

>> -----Original Message-----

>> From: Rakesh Gandhi (rgandhi)

>> Sent: Tuesday, September 04, 2012 1:36 PM

>> To: 'Lou Berger'

>> Cc: zha=
ng.fei3@zte.com.cn;
ccamp@ietf.org

>> Subject: RE: Question on LSP control in 

>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

>>

>>

>> Thanks Lou for your reply.

>>

>> RFC 3473 defines procedures for NOTIFY request and reply. We could=
 use this for reverse LSP signaling error notification to the initiating in=
gress node.

>>

>> <Notify message> ::=3D <Common Header> [<INTEGRITY&=
gt;] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]

>> <ERROR_SPEC>   

>> <notify session list ::=3D <upstream session> <downstr=
eam session>  >

>>

>> There are multiple ways we can use the NOTIFY message.

>>

>> Method 1 - Mid-point aware with Path message request:

>> When an egress node receives a Path message with REVERSE_LSP objec=
t, the node will insert NOTIFY_REQ message in the reverse LSP path message =
with node ID of the initiating ingress node. A mid-point node will send &nb=
sp;a copy of the signaling error to the initiating
 node using the NOTIFY message.

>>

>> IPv4 Notify Request Object

>>    IPv4 Notify Node Address: 32 bits

>>       The IP address of the node that should be not=
ified when generating an error message.

>>

>> Method 2 - Mid-point aware with Resv message request:

>> When an initiating ingress node receives a Path message for a reve=
rse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv me=
ssage with its own node ID. A mid-point node will send a copy of the signal=
ing error to the initiating node using
 the NOTIFY message.

>>

>> Method 3 - Tail-end relaying :

>> When an egress node receives a Path message with REVERSE_LSP objec=
t, the node will relay the received signaling error message on the reverse =
LSP to the initializing ingress node. The egress node copies the received &=
quot;ERROR_SPEC" object into a NOTIFY [RFC3473,
 section 4.3] message and signals it to the ingress node. In this case, NOT=
IFY_REQ message is not required.


>>

>> Please advise your thoughts.

>>

>> Thanks,

>> Rakesh

>>

>>

>>

>> -----Original Message-----

>> From: Lou Berger [mailto:lberger@labn.net]

>> Sent: Tuesday, September 04, 2012 11:35 AM

>> To: Rakesh Gandhi (rgandhi)

>> Cc: zha=
ng.fei3@zte.com.cn;
ccamp@ietf.org

>> Subject: Re: Question on LSP control in 

>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt

>>

>> As I read the current rev, no such notification mechanism is speci=
fied.

>>  Looks like you get to propose one!

>>

>> Lou (as WG participant).

>>

>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:

>>> Hi Lou, Fei,

>>>

>>> When an (originating) ingress node is provisioned with "5=
 (TBD)  Single Sided Associated Bidirectional LSPs  (A)" and=
 wishes to control both forward and reverse  LSPs by adding "REVE=
RSE_LSP" object, I would think that the ingress node needs to know abo=
ut
 the signaling (path) errors (such as soft preemption or admission failure)=
 on the reverse LSP.  Is there any text somewhere in an RFC/draft that=
 describes how a mid-point node can send the signaling (path) error to the =
originating ingress node for the reverse
 LSP? Is there an assumption to use RSVP_NOTIFY message? Sorry if I had mis=
sed any previous discussion on this topic.

>>>

>>> Thanks,

>>> Rakesh

>>>

>>>

>>>

>>>

>>>

>>

>>

>>

>>

> 

> 

> 

> 






--_000_B7D2A316AA32B6469D9670B6A81B7C24098A1Exmbalnx07ciscocom_--

From lberger@labn.net  Thu Sep 13 06:02: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 B6EE421F8421 for ; Thu, 13 Sep 2012 06:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.871
X-Spam-Level: 
X-Spam-Status: No, score=-98.871 tagged_above=-999 required=5 tests=[AWL=-1.160, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGgO-dLbL5bj for ; Thu, 13 Sep 2012 06:02:25 -0700 (PDT)
Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 8FBA121F85D5 for ; Thu, 13 Sep 2012 06:02:25 -0700 (PDT)
Received: (qmail 32759 invoked by uid 0); 13 Sep 2012 13:02:20 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 13 Sep 2012 13:02:20 -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=euLnJXODv0nIcgVYJPlJxweQusDDRE/SCGSU+0BiO5s=;  b=dfPJbXyvJ/8bwHRqjSCbDlmtlRFHJ7gYsWjQcFVBXosE1lMcwyWMbs7EaDDp56aB/+BAnxzDgs7DhWbs2IuMEliGWla+iFHTa73CARWq4p28SrTOmalVXj/RrLNPQPGD;
Received: from box313.bluehost.com ([69.89.31.113]:55882 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TC93k-0007ZV-Fx; Thu, 13 Sep 2012 07:02:20 -0600
Message-ID: <5051D959.2010809@labn.net>
Date: Thu, 13 Sep 2012 09:02:17 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" 
References:   
In-Reply-To: 
X-Enigmail-Version: 1.4.4
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] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 13:02:26 -0000

Rakesh,
	This seems really complicated.  Why allow for the optional notification
from the egress?  There is precedent for use of notify messages without
notify requests (see RFC4974).

Also, as it stands Associated Bidirectional really only requires support
by the end nodes. (I think of it as almost an application overlay on top
of normal LSP signaling.  I'd even consider using the RFC4974 call
approach if it wasn't for requirement 11 in RFC6373.)  I think placing
processing requirements on transit nodes, such as sending reverse_lsp
notifications adds unnecessary complexity and should be avoided unless
absolutely necessary.

Lou (as participant)

On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
> Hi Fei,
> 
>  
> 
> I see what you are saying. Rewording the text to reflect this (not sure
> about ¡°SHOULD¡± word usage):
> 
>  
> 
> When an initiating ingress node is provisioned with "Single Sided
> Associated Bidirectional LSPs" and wishes to control both forward and
> reverse LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD
> know the signaling (path) errors on the reverse LSP. Transit and egress
> nodes SHOULD be requested to notify the signaling error on the reverse
> LSP by using the NOTIFY message and procedures defined in RFC[3473].
> 
>  
> 
>  
> 
> Thanks,
> 
> Rakesh
> 
>  
> 
>  
> 
> *From:*zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
> *Sent:* Wednesday, September 12, 2012 9:40 PM
> *To:* Rakesh Gandhi (rgandhi)
> *Cc:* ccamp@ietf.org; Lou Berger
> *Subject:* RE: Question on LSP control in
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
>  
> 
> 
> Hi Rekesh, Lou
> 
>  />          Speaking as WG participant, I haven't thought about this
> too much so may be off, but method 3 seems to be most consistent with
> the usage of the REVERSE_LSP Object in the path message.  Perhaps
> consider using the REVERSE_LSP Object in the upstream/Resv direction to
> allow the egress/tail to provide the ingress/head with arbitrary
> information..../
> 
> Well, I can see one of the advantages of this proposal is that it
> allows the policy control in the egress/tail, where a decision can be
> made that whether the signaling error should be passed to the
> ingress/head. But it changes the rules defined in RFC3473....
> 
>      The other proposal keeps alignment with RFC3473, and I prefer it if
> the LSP control is totally in hand of the ingress/head (in other words,
> there is no more information needs the egres/tail to inform the
> ingress/head).
> 
> *"Rakesh Gandhi (rgandhi)" >*
> 
> 2012-09-13 08:53
> 
> 	
> 
> ÊÕ¼þÈË
> 
> 	
> 
> "zhang.fei3@zte.com.cn "
> >
> 
> ³­ËÍ
> 
> 	
> 
> "ccamp@ietf.org "  >, Lou Berger  >
> 
> Ö÷Ìâ
> 
> 	
> 
> RE: Question on LSP control in
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
>  
> 
> 	
> 
> 
> 
> 
> Hi Fei,
>  
> Please see inline....
>  
> *From:*zhang.fei3@zte.com.cn 
> [mailto:zhang.fei3@zte.com.cn]  *
> Sent:* Wednesday, September 12, 2012 8:42 PM*
> To:* Rakesh Gandhi (rgandhi)*
> Cc:* ccamp@ietf.org ; Lou Berger*
> Subject:* RE: Question on LSP control in
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>  
> 
> Hi Rakesh
> 
> In the absence of such notification request, egress node SHOULD relay
> the received signaling error on the reverse LSP to the ingress node
> using the NOTIFY message."
> 
>  "Note that a Notify message MUST NOT be generated unless an
> appropriate Notify Request object has been received."
> 
>       If my understanding is correct, your proposed relay mechanism does
> not depend on the existing of the Notify Request object, which may
> conflict with the
>       descripitons in RFC3473.
> 
>       Do you want to change this or do I have some misunderstanding?  
> 
>  Yes your understanding is correct.  NOTIFY message in this case is
> generated based on the presence of the ¡°REVERSE_LSP¡± object and
> association type ¡°Single Sided Associated Bidirectional LSPs.  I
> understand what you are saying though. FYI,  Lou had following thoughts
> on this. Do you think this simplifies things ?
> />          Speaking as WG participant, I haven't thought about this too
> much so may be off, but method 3 seems to be most consistent with the
> usage of the REVERSE_LSP Object in the path message.  Perhaps consider
> using the REVERSE_LSP Object in the upstream/Resv direction to allow the
> egress/tail to provide the ingress/head with arbitrary information....
> /
> Thanks,
> Rakesh
>  
>  
> 
> Regards
> 
> Fei
> 
> *"Rakesh Gandhi (rgandhi)" <**rgandhi@cisco.com*
> *>*
> 
> 2012-09-13 01:23
> 
> 	
> 
>  
> 
> ÊÕ¼þÈË
> 
> 	
> 
> Lou Berger >
> 
> ³­ËÍ
> 
> 	
> 
> "zhang.fei3@zte.com.cn "
> >, "ccamp@ietf.org
> " >
> 
> Ö÷Ìâ
> 
> 	
> 
> RE: Question on LSP control in
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> 
>  
> 
>  
> 
> 	
> 
> 
> 
> 
> 
> Hi Lou, Fei, WG,
> 
> Thanks for your replies. May I propose following text to cover this
> case? This allows the mid-point solution which has advantages but given
> the additional complexity can be optional.
> 
> Please advise.
> 
> "When an initiating ingress node is provisioned with "Single Sided
> Associated Bidirectional LSPs" and wishes to control both forward and
> reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD
> know the signaling (path) errors on the reverse LSP.  A transit node MAY
> be requested to notify the signaling error on the reverse LSP by using
> the NOTIFY message and procedures defined in RFC[3473]. In the absence
> of such notification request, egress node SHOULD relay the received
> signaling error on the reverse LSP to the ingress node using the NOTIFY
> message."
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> 
> Sent: Wednesday, September 12, 2012 12:14 PM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn ; ccamp@ietf.org
> 
> Subject: Re: Question on LSP control in
> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 
> 
> On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
>> Thanks Lou.
>> 
>> Are we ok in general to use NOTIFY message [RFC3473] for this?
> 
> I'm not speaking for the WG, as noted my comments were as a participant.
> IMO you'll need to fully document the proposal, perhaps discuss
> alternatives considered, and then ask the WG for concurrence.
> 
>> 
>> One advantage with the mid-point sending notification for the reverse 
>> LSP is that signaling error propagation time
>> (mid->egress-node->ingress-node) is significantly reduced (to
>> mid->ingress-node) which may be preferred in some cases.
> 
>>From my (personal) perspective, the added complexity isn't worth the effort.  Of course, a detailed proposal may show otherwise.
> 
> Lou
> 
>> 
>> Thanks,
>> Rakesh
>> 
>> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net] 
>> Sent: Wednesday, September 12, 2012 9:15 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn ; ccamp@ietf.org
> 
>> Subject: Re: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>> 
>> Rakesh,
>>                  Speaking as WG participant, I haven't thought about this too much so may be off, but method 3 seems to be most consistent with the usage of the REVERSE_LSP Object in the path message.  Perhaps consider using the REVERSE_LSP Object in the upstream/Resv direction to allow the egress/tail to provide the
> ingress/head with arbitrary information....
>> 
>> Lou
>> 
>> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi WG,
>>>
>>> Any thoughts on the following proposal?
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> -----Original Message-----
>>> From: Rakesh Gandhi (rgandhi)
>>> Sent: Tuesday, September 04, 2012 1:36 PM
>>> To: 'Lou Berger'
>>> Cc: zhang.fei3@zte.com.cn ; ccamp@ietf.org
> 
>>> Subject: RE: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>
>>> Thanks Lou for your reply.
>>>
>>> RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node.
>>>
>>>  ::=  [] [ [ | ] ... ]
>>>    
>>>    >
>>>
>>> There are multiple ways we can use the NOTIFY message.
>>>
>>> Method 1 - Mid-point aware with Path message request:
>>> When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send  a copy of the signaling error to the initiating node using the NOTIFY message.
>>>
>>> IPv4 Notify Request Object
>>>    IPv4 Notify Node Address: 32 bits
>>>       The IP address of the node that should be notified when generating an error message.
>>>
>>> Method 2 - Mid-point aware with Resv message request:
>>> When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message.
>>>
>>> Method 3 - Tail-end relaying :
>>> When an egress node receives a Path message with REVERSE_LSP object, the node will relay the received signaling error message on the reverse LSP to the initializing ingress node. The egress node copies the received "ERROR_SPEC" object into a NOTIFY [RFC3473, section 4.3] message and signals it to the ingress node. In this case,
> NOTIFY_REQ message is not required.
>>>
>>> Please advise your thoughts.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net] 
>>> Sent: Tuesday, September 04, 2012 11:35 AM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: zhang.fei3@zte.com.cn ; ccamp@ietf.org
> 
>>> Subject: Re: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>> As I read the current rev, no such notification mechanism is specified.
>>>  Looks like you get to propose one!
>>>
>>> Lou (as WG participant).
>>>
>>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi Lou, Fei,
>>>>
>>>> When an (originating) ingress node is provisioned with "5 (TBD)  Single Sided Associated Bidirectional LSPs  (A)" and wishes to control both forward and reverse  LSPs by adding "REVERSE_LSP" object, I would think that the ingress node needs to know about the signaling (path) errors (such as soft preemption or admission
> failure) on the reverse LSP.  Is there any text somewhere in an
> RFC/draft that describes how a mid-point node can send the signaling
> (path) error to the originating ingress node for the reverse LSP? Is
> there an assumption to use RSVP_NOTIFY message? Sorry if I had missed
> any previous discussion on this topic.
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>> 
>> 
>> 
>> 
> 

From jdrake@juniper.net  Thu Sep 13 06:11:05 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 229B121F8518 for ; Thu, 13 Sep 2012 06:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.498
X-Spam-Level: 
X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrC2662BItcR for ; Thu, 13 Sep 2012 06:11:00 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3C21F8508 for ; Thu, 13 Sep 2012 06:10:56 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUFHbXtA1f5LLHxOYzu4zDwBcRpSTMDtR@postini.com; Thu, 13 Sep 2012 06:10:56 PDT
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; Thu, 13 Sep 2012 06:04:17 -0700
From: John E Drake 
To: Lou Berger , "Rakesh Gandhi (rgandhi)" 
Date: Thu, 13 Sep 2012 06:04:14 -0700
Thread-Topic: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2RsAnX1M1IKg7pQOe9BRkx0f7qowAABqYA
Message-ID: <5E893DB832F57341992548CDBB333163A6330D5A1A@EMBX01-HQ.jnpr.net>
References:    <5051D959.2010809@labn.net>
In-Reply-To: <5051D959.2010809@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in	draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 13:11:05 -0000

QXMgYSBwYXJ0aWNpcGFudCwgSSBhZ3JlZSB3aXRoIExvdS4NCg0KWW91cnMgaXJyZXNwZWN0aXZl
bHksDQoNCkpvaG4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNj
YW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYNCj4gT2YgTG91IEJlcmdlcg0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAy
MDEyIDY6MDIgQU0NCj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+IENjOiBjY2FtcEBp
ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0NDQU1QXSBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBp
biBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtDQo+IHRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3At
MDQudHh0DQo+IA0KPiBSYWtlc2gsDQo+IAlUaGlzIHNlZW1zIHJlYWxseSBjb21wbGljYXRlZC4g
IFdoeSBhbGxvdyBmb3IgdGhlIG9wdGlvbmFsDQo+IG5vdGlmaWNhdGlvbiBmcm9tIHRoZSBlZ3Jl
c3M/ICBUaGVyZSBpcyBwcmVjZWRlbnQgZm9yIHVzZSBvZiBub3RpZnkNCj4gbWVzc2FnZXMgd2l0
aG91dCBub3RpZnkgcmVxdWVzdHMgKHNlZSBSRkM0OTc0KS4NCj4gDQo+IEFsc28sIGFzIGl0IHN0
YW5kcyBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgcmVhbGx5IG9ubHkgcmVxdWlyZXMNCj4gc3Vw
cG9ydCBieSB0aGUgZW5kIG5vZGVzLiAoSSB0aGluayBvZiBpdCBhcyBhbG1vc3QgYW4gYXBwbGlj
YXRpb24NCj4gb3ZlcmxheSBvbiB0b3Agb2Ygbm9ybWFsIExTUCBzaWduYWxpbmcuICBJJ2QgZXZl
biBjb25zaWRlciB1c2luZyB0aGUNCj4gUkZDNDk3NCBjYWxsIGFwcHJvYWNoIGlmIGl0IHdhc24n
dCBmb3IgcmVxdWlyZW1lbnQgMTEgaW4gUkZDNjM3My4pICBJDQo+IHRoaW5rIHBsYWNpbmcgcHJv
Y2Vzc2luZyByZXF1aXJlbWVudHMgb24gdHJhbnNpdCBub2Rlcywgc3VjaCBhcyBzZW5kaW5nDQo+
IHJldmVyc2VfbHNwIG5vdGlmaWNhdGlvbnMgYWRkcyB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5IGFu
ZCBzaG91bGQgYmUNCj4gYXZvaWRlZCB1bmxlc3MgYWJzb2x1dGVseSBuZWNlc3NhcnkuDQo+IA0K
PiBMb3UgKGFzIHBhcnRpY2lwYW50KQ0KPiANCj4gT24gOS8xMi8yMDEyIDk6NTcgUE0sIFJha2Vz
aCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPiA+IEhpIEZlaSwNCj4gPg0KPiA+DQo+ID4NCj4g
PiBJIHNlZSB3aGF0IHlvdSBhcmUgc2F5aW5nLiBSZXdvcmRpbmcgdGhlIHRleHQgdG8gcmVmbGVj
dCB0aGlzIChub3QNCj4gPiBzdXJlIGFib3V0IKGwU0hPVUxEobEgd29yZCB1c2FnZSk6DQo+ID4N
Cj4gPg0KPiA+DQo+ID4gV2hlbiBhbiBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNp
b25lZCB3aXRoICJTaW5nbGUgU2lkZWQNCj4gPiBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQ
cyIgYW5kIHdpc2hlcyB0byBjb250cm9sIGJvdGggZm9yd2FyZCBhbmQNCj4gPiByZXZlcnNlIExT
UHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIgb2JqZWN0LCB0aGUgaW5ncmVzcyBub2RlIFNIT1VM
RA0KPiA+IGtub3cgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZlcnNlIExT
UC4gVHJhbnNpdCBhbmQNCj4gPiBlZ3Jlc3Mgbm9kZXMgU0hPVUxEIGJlIHJlcXVlc3RlZCB0byBu
b3RpZnkgdGhlIHNpZ25hbGluZyBlcnJvciBvbiB0aGUNCj4gPiByZXZlcnNlIExTUCBieSB1c2lu
ZyB0aGUgTk9USUZZIG1lc3NhZ2UgYW5kIHByb2NlZHVyZXMgZGVmaW5lZCBpbg0KPiBSRkNbMzQ3
M10uDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IFJha2Vz
aA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiAqRnJvbToqemhhbmcuZmVpM0B6dGUuY29t
LmNuIFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXQ0KPiA+ICpTZW50OiogV2VkbmVzZGF5
LCBTZXB0ZW1iZXIgMTIsIDIwMTIgOTo0MCBQTQ0KPiA+ICpUbzoqIFJha2VzaCBHYW5kaGkgKHJn
YW5kaGkpDQo+ID4gKkNjOiogY2NhbXBAaWV0Zi5vcmc7IExvdSBCZXJnZXINCj4gPiAqU3ViamVj
dDoqIFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbg0KPiA+IGRyYWZ0LWlldGYtY2NhbXAt
bXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPiA+DQo+ID4NCj4gPg0K
PiA+DQo+ID4gSGkgUmVrZXNoLCBMb3UNCj4gPg0KPiA+ICAvPiAgICAgICAgICBTcGVha2luZyBh
cyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQgdGhpcw0KPiA+IHRvbyBt
dWNoIHNvIG1heSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBtb3N0IGNvbnNpc3Rl
bnQgd2l0aA0KPiA+IHRoZSB1c2FnZSBvZiB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSBw
YXRoIG1lc3NhZ2UuICBQZXJoYXBzDQo+ID4gY29uc2lkZXIgdXNpbmcgdGhlIFJFVkVSU0VfTFNQ
IE9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24NCj4gPiB0byBhbGxvdyB0aGUg
ZWdyZXNzL3RhaWwgdG8gcHJvdmlkZSB0aGUgaW5ncmVzcy9oZWFkIHdpdGggYXJiaXRyYXJ5DQo+
ID4gaW5mb3JtYXRpb24uLi4uLw0KPiA+DQo+ID4gPGZlaT5XZWxsLCBJIGNhbiBzZWUgb25lIG9m
IHRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgcHJvcG9zYWwgaXMgdGhhdA0KPiBpdA0KPiA+IGFsbG93
cyB0aGUgcG9saWN5IGNvbnRyb2wgaW4gdGhlIGVncmVzcy90YWlsLCB3aGVyZSBhIGRlY2lzaW9u
IGNhbiBiZQ0KPiA+IG1hZGUgdGhhdCB3aGV0aGVyIHRoZSBzaWduYWxpbmcgZXJyb3Igc2hvdWxk
IGJlIHBhc3NlZCB0byB0aGUNCj4gPiBpbmdyZXNzL2hlYWQuIEJ1dCBpdCBjaGFuZ2VzIHRoZSBy
dWxlcyBkZWZpbmVkIGluIFJGQzM0NzMuLi4uDQo+ID4NCj4gPiAgICAgIFRoZSBvdGhlciBwcm9w
b3NhbCBrZWVwcyBhbGlnbm1lbnQgd2l0aCBSRkMzNDczLCBhbmQgSSBwcmVmZXIgaXQNCj4gPiBp
ZiB0aGUgTFNQIGNvbnRyb2wgaXMgdG90YWxseSBpbiBoYW5kIG9mIHRoZSBpbmdyZXNzL2hlYWQg
KGluIG90aGVyDQo+ID4gd29yZHMsIHRoZXJlIGlzIG5vIG1vcmUgaW5mb3JtYXRpb24gbmVlZHMg
dGhlIGVncmVzL3RhaWwgdG8gaW5mb3JtDQo+IHRoZQ0KPiA+IGluZ3Jlc3MvaGVhZCkuDQo+ID4N
Cj4gPiAqIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNjby5jb20NCj4gPiA8
bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj4qDQo+ID4NCj4gPiAyMDEyLTA5LTEzIDA4OjUzDQo+
ID4NCj4gPg0KPiA+DQo+ID4gytW8/sjLDQo+ID4NCj4gPg0KPiA+DQo+ID4gInpoYW5nLmZlaTNA
enRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4iDQo+ID4gPHpoYW5nLmZl
aTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4+DQo+ID4NCj4gPiCz
rcvNDQo+ID4NCj4gPg0KPiA+DQo+ID4gImNjYW1wQGlldGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0
Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmcNCj4gPiA8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4sIExv
dSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQNCj4gPiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+
Pg0KPiA+DQo+ID4g1vfM4g0KPiA+DQo+ID4NCj4gPg0KPiA+IFJFOiBRdWVzdGlvbiBvbiBMU1Ag
Y29udHJvbCBpbg0KPiA+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29j
aWF0ZWQtbHNwLTA0LnR4dA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4N
Cj4gPiBIaSBGZWksDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4uPFJHPi4uDQo+ID4NCj4g
PiAqRnJvbToqemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29t
LmNuPg0KPiA+IFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXQ0KPiA8bWFpbHRvOlttYWls
dG86emhhbmcuZmVpM0B6dGUuY29tLmNuXT4NCj4gPiAqDQo+ID4gU2VudDoqIFdlZG5lc2RheSwg
U2VwdGVtYmVyIDEyLCAyMDEyIDg6NDIgUE0qDQo+ID4gVG86KiBSYWtlc2ggR2FuZGhpIChyZ2Fu
ZGhpKSoNCj4gPiBDYzoqIGNjYW1wQGlldGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBM
b3UgQmVyZ2VyKg0KPiA+IFN1YmplY3Q6KiBSRTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4N
Cj4gPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0w
NC50eHQNCj4gPg0KPiA+DQo+ID4gSGkgUmFrZXNoDQo+ID4NCj4gPiBJbiB0aGUgYWJzZW5jZSBv
ZiBzdWNoIG5vdGlmaWNhdGlvbiByZXF1ZXN0LCBlZ3Jlc3Mgbm9kZSBTSE9VTEQgcmVsYXkNCj4g
PiB0aGUgcmVjZWl2ZWQgc2lnbmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNlIExTUCB0byB0aGUg
aW5ncmVzcyBub2RlDQo+ID4gdXNpbmcgdGhlIE5PVElGWSBtZXNzYWdlLiINCj4gPg0KPiA+IDxm
ZWk+ICJOb3RlIHRoYXQgYSBOb3RpZnkgbWVzc2FnZSBNVVNUIE5PVCBiZSBnZW5lcmF0ZWQgdW5s
ZXNzIGFuDQo+ID4gYXBwcm9wcmlhdGUgTm90aWZ5IFJlcXVlc3Qgb2JqZWN0IGhhcyBiZWVuIHJl
Y2VpdmVkLiINCj4gPg0KPiA+ICAgICAgIElmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwg
eW91ciBwcm9wb3NlZCByZWxheSBtZWNoYW5pc20NCj4gPiBkb2VzIG5vdCBkZXBlbmQgb24gdGhl
IGV4aXN0aW5nIG9mIHRoZSBOb3RpZnkgUmVxdWVzdCBvYmplY3QsIHdoaWNoDQo+ID4gbWF5IGNv
bmZsaWN0IHdpdGggdGhlDQo+ID4gICAgICAgZGVzY3JpcGl0b25zIGluIFJGQzM0NzMuDQo+ID4N
Cj4gPiAgICAgICBEbyB5b3Ugd2FudCB0byBjaGFuZ2UgdGhpcyBvciBkbyBJIGhhdmUgc29tZSBt
aXN1bmRlcnN0YW5kaW5nPw0KPiA+DQo+ID4gPFJHPiBZZXMgeW91ciB1bmRlcnN0YW5kaW5nIGlz
IGNvcnJlY3QuICBOT1RJRlkgbWVzc2FnZSBpbiB0aGlzIGNhc2UNCj4gPiBpcyBnZW5lcmF0ZWQg
YmFzZWQgb24gdGhlIHByZXNlbmNlIG9mIHRoZSChsFJFVkVSU0VfTFNQobEgb2JqZWN0IGFuZA0K
PiA+IGFzc29jaWF0aW9uIHR5cGUgobBTaW5nbGUgU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlv
bmFsIExTUHMuICBJDQo+ID4gdW5kZXJzdGFuZCB3aGF0IHlvdSBhcmUgc2F5aW5nIHRob3VnaC4g
RllJLCAgTG91IGhhZCBmb2xsb3dpbmcNCj4gPiB0aG91Z2h0cyBvbiB0aGlzLiBEbyB5b3UgdGhp
bmsgdGhpcyBzaW1wbGlmaWVzIHRoaW5ncyA/DQo+ID4gLz4gICAgICAgICAgU3BlYWtpbmcgYXMg
V0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRoaXMNCj4gdG9vDQo+ID4g
bXVjaCBzbyBtYXkgYmUgb2ZmLCBidXQgbWV0aG9kIDMgc2VlbXMgdG8gYmUgbW9zdCBjb25zaXN0
ZW50IHdpdGggdGhlDQo+ID4gdXNhZ2Ugb2YgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUg
cGF0aCBtZXNzYWdlLiAgUGVyaGFwcw0KPiBjb25zaWRlcg0KPiA+IHVzaW5nIHRoZSBSRVZFUlNF
X0xTUCBPYmplY3QgaW4gdGhlIHVwc3RyZWFtL1Jlc3YgZGlyZWN0aW9uIHRvIGFsbG93DQo+ID4g
dGhlIGVncmVzcy90YWlsIHRvIHByb3ZpZGUgdGhlIGluZ3Jlc3MvaGVhZCB3aXRoIGFyYml0cmFy
eQ0KPiBpbmZvcm1hdGlvbi4uLi4NCj4gPiAvDQo+ID4gVGhhbmtzLA0KPiA+IFJha2VzaA0KPiA+
DQo+ID4NCj4gPg0KPiA+IFJlZ2FyZHMNCj4gPg0KPiA+IEZlaQ0KPiA+DQo+ID4gKiJSYWtlc2gg
R2FuZGhpIChyZ2FuZGhpKSIgPCoqcmdhbmRoaUBjaXNjby5jb20qDQo+ID4gPG1haWx0bzpyZ2Fu
ZGhpQGNpc2NvLmNvbT4qPioNCj4gPg0KPiA+IDIwMTItMDktMTMgMDE6MjMNCj4gPg0KPiA+DQo+
ID4NCj4gPg0KPiA+DQo+ID4gytW8/sjLDQo+ID4NCj4gPg0KPiA+DQo+ID4gTG91IEJlcmdlciA8
bGJlcmdlckBsYWJuLm5ldCA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPiA+DQo+ID4gs63L
zQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICJ6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFu
Zy5mZWkzQHp0ZS5jb20uY24+Ig0KPiA+IDx6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6
aGFuZy5mZWkzQHp0ZS5jb20uY24+PiwNCj4gPiAiY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2Ft
cEBpZXRmLm9yZz4iIDxjY2FtcEBpZXRmLm9yZw0KPiA+IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+
Pg0KPiA+DQo+ID4g1vfM4g0KPiA+DQo+ID4NCj4gPg0KPiA+IFJFOiBRdWVzdGlvbiBvbiBMU1Ag
Y29udHJvbCBpbg0KPiA+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29j
aWF0ZWQtbHNwLTA0LnR4dA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4N
Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEhpIExvdSwgRmVpLCBXRywNCj4gPg0KPiA+IFRoYW5r
cyBmb3IgeW91ciByZXBsaWVzLiBNYXkgSSBwcm9wb3NlIGZvbGxvd2luZyB0ZXh0IHRvIGNvdmVy
IHRoaXMNCj4gPiBjYXNlPyBUaGlzIGFsbG93cyB0aGUgbWlkLXBvaW50IHNvbHV0aW9uIHdoaWNo
IGhhcyBhZHZhbnRhZ2VzIGJ1dA0KPiA+IGdpdmVuIHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkg
Y2FuIGJlIG9wdGlvbmFsLg0KPiA+DQo+ID4gUGxlYXNlIGFkdmlzZS4NCj4gPg0KPiA+ICJXaGVu
IGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggIlNpbmdsZSBT
aWRlZA0KPiA+IEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzIiBhbmQgd2lzaGVzIHRvIGNv
bnRyb2wgYm90aCBmb3J3YXJkIGFuZA0KPiA+IHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZF
UlNFX0xTUCIgb2JqZWN0LCB0aGUgaW5ncmVzcyBub2RlIFNIT1VMRA0KPiA+IGtub3cgdGhlIHNp
Z25hbGluZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZlcnNlIExTUC4gIEEgdHJhbnNpdCBub2Rl
DQo+ID4gTUFZIGJlIHJlcXVlc3RlZCB0byBub3RpZnkgdGhlIHNpZ25hbGluZyBlcnJvciBvbiB0
aGUgcmV2ZXJzZSBMU1AgYnkNCj4gPiB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UgYW5kIHByb2Nl
ZHVyZXMgZGVmaW5lZCBpbiBSRkNbMzQ3M10uIEluIHRoZQ0KPiA+IGFic2VuY2Ugb2Ygc3VjaCBu
b3RpZmljYXRpb24gcmVxdWVzdCwgZWdyZXNzIG5vZGUgU0hPVUxEIHJlbGF5IHRoZQ0KPiA+IHJl
Y2VpdmVkIHNpZ25hbGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mg
bm9kZSB1c2luZw0KPiA+IHRoZSBOT1RJRlkgbWVzc2FnZS4iDQo+ID4NCj4gPiBUaGFua3MsDQo+
ID4gUmFrZXNoDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
RnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdDQo+ID4gPG1haWx0bzpb
bWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPg0KPiA+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVy
IDEyLCAyMDEyIDEyOjE0IFBNDQo+ID4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+ID4g
Q2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj47
DQo+ID4gY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0
OiBSZTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4NCj4gPiBkcmFmdC1pZXRmLWNjYW1wLW1w
bHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gPg0KPiA+IFJha2VzaCwN
Cj4gPg0KPiA+DQo+ID4gT24gOS8xMi8yMDEyIDExOjUyIEFNLCBSYWtlc2ggR2FuZGhpIChyZ2Fu
ZGhpKSB3cm90ZToNCj4gPj4gVGhhbmtzIExvdS4NCj4gPj4NCj4gPj4gQXJlIHdlIG9rIGluIGdl
bmVyYWwgdG8gdXNlIE5PVElGWSBtZXNzYWdlIFtSRkMzNDczXSBmb3IgdGhpcz8NCj4gPg0KPiA+
IEknbSBub3Qgc3BlYWtpbmcgZm9yIHRoZSBXRywgYXMgbm90ZWQgbXkgY29tbWVudHMgd2VyZSBh
cyBhDQo+IHBhcnRpY2lwYW50Lg0KPiA+IElNTyB5b3UnbGwgbmVlZCB0byBmdWxseSBkb2N1bWVu
dCB0aGUgcHJvcG9zYWwsIHBlcmhhcHMgZGlzY3Vzcw0KPiA+IGFsdGVybmF0aXZlcyBjb25zaWRl
cmVkLCBhbmQgdGhlbiBhc2sgdGhlIFdHIGZvciBjb25jdXJyZW5jZS4NCj4gPg0KPiA+Pg0KPiA+
PiBPbmUgYWR2YW50YWdlIHdpdGggdGhlIG1pZC1wb2ludCBzZW5kaW5nIG5vdGlmaWNhdGlvbiBm
b3IgdGhlDQo+IHJldmVyc2UNCj4gPj4gTFNQIGlzIHRoYXQgc2lnbmFsaW5nIGVycm9yIHByb3Bh
Z2F0aW9uIHRpbWUNCj4gPj4gKG1pZC0+ZWdyZXNzLW5vZGUtPmluZ3Jlc3Mtbm9kZSkgaXMgc2ln
bmlmaWNhbnRseSByZWR1Y2VkICh0bw0KPiA+PiBtaWQtPmluZ3Jlc3Mtbm9kZSkgd2hpY2ggbWF5
IGJlIHByZWZlcnJlZCBpbiBzb21lIGNhc2VzLg0KPiA+DQo+ID4+RnJvbSBteSAocGVyc29uYWwp
IHBlcnNwZWN0aXZlLCB0aGUgYWRkZWQgY29tcGxleGl0eSBpc24ndCB3b3J0aCB0aGUNCj4gZWZm
b3J0LiAgT2YgY291cnNlLCBhIGRldGFpbGVkIHByb3Bvc2FsIG1heSBzaG93IG90aGVyd2lzZS4N
Cj4gPg0KPiA+IExvdQ0KPiA+DQo+ID4+DQo+ID4+IFRoYW5rcywNCj4gPj4gUmFrZXNoDQo+ID4+
DQo+ID4+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IExvdSBC
ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPiA+PiA8bWFpbHRvOlttYWlsdG86bGJl
cmdlckBsYWJuLm5ldF0+DQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEy
IDk6MTUgQU0NCj4gPj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+ID4+IENjOiB6aGFu
Zy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+Ow0KPiA+PiBj
Y2FtcEBpZXRmLm9yZw0KPiA+IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6
IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbg0KPiA+PiBkcmFmdC1pZXRmLWNjYW1wLW1w
bHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gPj4NCj4gPj4gUmFrZXNo
LA0KPiA+PiAgICAgICAgICAgICAgICAgIFNwZWFraW5nIGFzIFdHIHBhcnRpY2lwYW50LCBJIGhh
dmVuJ3QgdGhvdWdodCBhYm91dA0KPiA+PiB0aGlzIHRvbyBtdWNoIHNvIG1heSBiZSBvZmYsIGJ1
dCBtZXRob2QgMyBzZWVtcyB0byBiZSBtb3N0DQo+IGNvbnNpc3RlbnQNCj4gPj4gd2l0aCB0aGUg
dXNhZ2Ugb2YgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgcGF0aCBtZXNzYWdlLg0KPiA+
PiBQZXJoYXBzIGNvbnNpZGVyIHVzaW5nIHRoZSBSRVZFUlNFX0xTUCBPYmplY3QgaW4gdGhlIHVw
c3RyZWFtL1Jlc3YNCj4gPj4gZGlyZWN0aW9uIHRvIGFsbG93IHRoZSBlZ3Jlc3MvdGFpbCB0byBw
cm92aWRlIHRoZQ0KPiA+IGluZ3Jlc3MvaGVhZCB3aXRoIGFyYml0cmFyeSBpbmZvcm1hdGlvbi4u
Li4NCj4gPj4NCj4gPj4gTG91DQo+ID4+DQo+ID4+IE9uIDkvMTEvMjAxMiA5OjIyIEFNLCBSYWtl
c2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4gPj4+IEhpIFdHLA0KPiA+Pj4NCj4gPj4+IEFu
eSB0aG91Z2h0cyBvbiB0aGUgZm9sbG93aW5nIHByb3Bvc2FsPw0KPiA+Pj4NCj4gPj4+IFRoYW5r
cywNCj4gPj4+IFJha2VzaA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiA+Pj4gRnJvbTogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4gPj4+IFNlbnQ6
IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNDQo+ID4+PiBUbzogJ0xvdSBCZXJn
ZXInDQo+ID4+PiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVpM0B6
dGUuY29tLmNuPjsNCj4gPj4+IGNjYW1wQGlldGYub3JnDQo+ID4gPG1haWx0bzpjY2FtcEBpZXRm
Lm9yZz4NCj4gPj4+IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbg0KPiA+
Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQu
dHh0DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5rcyBMb3UgZm9yIHlvdXIgcmVwbHkuDQo+ID4+
Pg0KPiA+Pj4gUkZDIDM0NzMgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJRlkgcmVxdWVzdCBh
bmQgcmVwbHkuIFdlIGNvdWxkDQo+IHVzZSB0aGlzIGZvciByZXZlcnNlIExTUCBzaWduYWxpbmcg
ZXJyb3Igbm90aWZpY2F0aW9uIHRvIHRoZSBpbml0aWF0aW5nDQo+IGluZ3Jlc3Mgbm9kZS4NCj4g
Pj4+DQo+ID4+PiA8Tm90aWZ5IG1lc3NhZ2U+IDo6PSA8Q29tbW9uIEhlYWRlcj4gWzxJTlRFR1JJ
VFk+XSBbDQo+IFs8TUVTU0FHRV9JRF9BQ0s+IHwgPE1FU1NBR0VfSURfTkFDSz5dIC4uLiBdDQo+
ID4+PiA8RVJST1JfU1BFQz4NCj4gPj4+IDxub3RpZnkgc2Vzc2lvbiBsaXN0IDo6PSA8dXBzdHJl
YW0gc2Vzc2lvbj4gPGRvd25zdHJlYW0gc2Vzc2lvbj4gID4NCj4gPj4+DQo+ID4+PiBUaGVyZSBh
cmUgbXVsdGlwbGUgd2F5cyB3ZSBjYW4gdXNlIHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4gPj4+DQo+
ID4+PiBNZXRob2QgMSAtIE1pZC1wb2ludCBhd2FyZSB3aXRoIFBhdGggbWVzc2FnZSByZXF1ZXN0
Og0KPiA+Pj4gV2hlbiBhbiBlZ3Jlc3Mgbm9kZSByZWNlaXZlcyBhIFBhdGggbWVzc2FnZSB3aXRo
IFJFVkVSU0VfTFNQDQo+IG9iamVjdCwgdGhlIG5vZGUgd2lsbCBpbnNlcnQgTk9USUZZX1JFUSBt
ZXNzYWdlIGluIHRoZSByZXZlcnNlIExTUCBwYXRoDQo+IG1lc3NhZ2Ugd2l0aCBub2RlIElEIG9m
IHRoZSBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZS4gQSBtaWQtcG9pbnQgbm9kZQ0KPiB3aWxsIHNl
bmQgIGEgY29weSBvZiB0aGUgc2lnbmFsaW5nIGVycm9yIHRvIHRoZSBpbml0aWF0aW5nIG5vZGUg
dXNpbmcNCj4gdGhlIE5PVElGWSBtZXNzYWdlLg0KPiA+Pj4NCj4gPj4+IElQdjQgTm90aWZ5IFJl
cXVlc3QgT2JqZWN0DQo+ID4+PiAgICBJUHY0IE5vdGlmeSBOb2RlIEFkZHJlc3M6IDMyIGJpdHMN
Cj4gPj4+ICAgICAgIFRoZSBJUCBhZGRyZXNzIG9mIHRoZSBub2RlIHRoYXQgc2hvdWxkIGJlIG5v
dGlmaWVkIHdoZW4NCj4gZ2VuZXJhdGluZyBhbiBlcnJvciBtZXNzYWdlLg0KPiA+Pj4NCj4gPj4+
IE1ldGhvZCAyIC0gTWlkLXBvaW50IGF3YXJlIHdpdGggUmVzdiBtZXNzYWdlIHJlcXVlc3Q6DQo+
ID4+PiBXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNz
YWdlIGZvciBhDQo+IHJldmVyc2UgTFNQLCB0aGUgbm9kZSB3aWxsIGluc2VydCBOT1RJRllfUkVR
IG1lc3NhZ2UgaW4gdGhlIHJldmVyc2UgTFNQDQo+IFJlc3YgbWVzc2FnZSB3aXRoIGl0cyBvd24g
bm9kZSBJRC4gQSBtaWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQgYSBjb3B5IG9mDQo+IHRoZSBzaWdu
YWxpbmcgZXJyb3IgdG8gdGhlIGluaXRpYXRpbmcgbm9kZSB1c2luZyB0aGUgTk9USUZZIG1lc3Nh
Z2UuDQo+ID4+Pg0KPiA+Pj4gTWV0aG9kIDMgLSBUYWlsLWVuZCByZWxheWluZyA6DQo+ID4+PiBX
aGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIHdpdGggUkVWRVJTRV9M
U1ANCj4gb2JqZWN0LA0KPiA+Pj4gdGhlIG5vZGUgd2lsbCByZWxheSB0aGUgcmVjZWl2ZWQgc2ln
bmFsaW5nIGVycm9yIG1lc3NhZ2Ugb24gdGhlDQo+ID4+PiByZXZlcnNlIExTUCB0byB0aGUgaW5p
dGlhbGl6aW5nIGluZ3Jlc3Mgbm9kZS4gVGhlIGVncmVzcyBub2RlDQo+IGNvcGllcw0KPiA+Pj4g
dGhlIHJlY2VpdmVkICJFUlJPUl9TUEVDIiBvYmplY3QgaW50byBhIE5PVElGWSBbUkZDMzQ3Mywg
c2VjdGlvbg0KPiA+Pj4gNC4zXSBtZXNzYWdlIGFuZCBzaWduYWxzIGl0IHRvIHRoZSBpbmdyZXNz
IG5vZGUuIEluIHRoaXMgY2FzZSwNCj4gPiBOT1RJRllfUkVRIG1lc3NhZ2UgaXMgbm90IHJlcXVp
cmVkLg0KPiA+Pj4NCj4gPj4+IFBsZWFzZSBhZHZpc2UgeW91ciB0aG91Z2h0cy4NCj4gPj4+DQo+
ID4+PiBUaGFua3MsDQo+ID4+PiBSYWtlc2gNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86
bGJlcmdlckBsYWJuLm5ldF0NCj4gPj4+IDxtYWlsdG86W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0
XT4NCj4gPj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMTozNSBBTQ0KPiA+
Pj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+ID4+PiBDYzogemhhbmcuZmVpM0B6dGUu
Y29tLmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjsNCj4gPj4+IGNjYW1wQGlldGYu
b3JnDQo+ID4gPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4gPj4+IFN1YmplY3Q6IFJlOiBRdWVz
dGlvbiBvbiBMU1AgY29udHJvbCBpbg0KPiA+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJz
dnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+ID4+Pg0KPiA+Pj4gQXMgSSByZWFkIHRo
ZSBjdXJyZW50IHJldiwgbm8gc3VjaCBub3RpZmljYXRpb24gbWVjaGFuaXNtIGlzDQo+IHNwZWNp
ZmllZC4NCj4gPj4+ICBMb29rcyBsaWtlIHlvdSBnZXQgdG8gcHJvcG9zZSBvbmUhDQo+ID4+Pg0K
PiA+Pj4gTG91IChhcyBXRyBwYXJ0aWNpcGFudCkuDQo+ID4+Pg0KPiA+Pj4gT24gOC8zMS8yMDEy
IDk6NDkgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPiA+Pj4+IEhpIExvdSwg
RmVpLA0KPiA+Pj4+DQo+ID4+Pj4gV2hlbiBhbiAob3JpZ2luYXRpbmcpIGluZ3Jlc3Mgbm9kZSBp
cyBwcm92aXNpb25lZCB3aXRoICI1IChUQkQpDQo+ID4+Pj4gU2luZ2xlIFNpZGVkIEFzc29jaWF0
ZWQgQmlkaXJlY3Rpb25hbCBMU1BzICAoQSkiIGFuZCB3aXNoZXMgdG8NCj4gPj4+PiBjb250cm9s
IGJvdGggZm9yd2FyZCBhbmQgcmV2ZXJzZSAgTFNQcyBieSBhZGRpbmcgIlJFVkVSU0VfTFNQIg0K
PiA+Pj4+IG9iamVjdCwgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBpbmdyZXNzIG5vZGUgbmVlZHMg
dG8ga25vdyBhYm91dA0KPiB0aGUNCj4gPj4+PiBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyAoc3Vj
aCBhcyBzb2Z0IHByZWVtcHRpb24gb3IgYWRtaXNzaW9uDQo+ID4gZmFpbHVyZSkgb24gdGhlIHJl
dmVyc2UgTFNQLiAgSXMgdGhlcmUgYW55IHRleHQgc29tZXdoZXJlIGluIGFuDQo+ID4gUkZDL2Ry
YWZ0IHRoYXQgZGVzY3JpYmVzIGhvdyBhIG1pZC1wb2ludCBub2RlIGNhbiBzZW5kIHRoZSBzaWdu
YWxpbmcNCj4gPiAocGF0aCkgZXJyb3IgdG8gdGhlIG9yaWdpbmF0aW5nIGluZ3Jlc3Mgbm9kZSBm
b3IgdGhlIHJldmVyc2UgTFNQPyBJcw0KPiA+IHRoZXJlIGFuIGFzc3VtcHRpb24gdG8gdXNlIFJT
VlBfTk9USUZZIG1lc3NhZ2U/IFNvcnJ5IGlmIEkgaGFkIG1pc3NlZA0KPiA+IGFueSBwcmV2aW91
cyBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMuDQo+ID4+Pj4NCj4gPj4+PiBUaGFua3MsDQo+ID4+
Pj4gUmFrZXNoDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4N
Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPg0KPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWls
aW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9jY2FtcA0K

From rgandhi@cisco.com  Thu Sep 13 06:15: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 A3C1221F859C for ; Thu, 13 Sep 2012 06:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.657
X-Spam-Level: 
X-Spam-Status: No, score=-7.657 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNOiKGI+ujJg for ; Thu, 13 Sep 2012 06:15:51 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1493321F859B for ; Thu, 13 Sep 2012 06:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18368; q=dns/txt; s=iport; t=1347542151; x=1348751751; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EYO5XM+1zrFJNhZiK5xYd/ttodAxjeeqY9lW76QP18g=; b=T4K89YAz5PyybKvJxGjYrdDI5AhgxcEjqcxwf8iBJ2+BS49RHeYoivDT BhMvSxVBGMpBug1/ey90mXJkoE+YuWou5Xlp/k7VvasH4lviRbQXzx92F OjSygh1kPg2gDjmZ6oi3ggAoA4EKwkP2H3cqZ/b+ekpGgGaQ35jkZJ863 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFADXcUVCtJV2d/2dsb2JhbABFhge0eW+BB4IgAQEBBBIBFA1FDAQCAQYCDgMEAQEBBAYdBQICMBQJCAIEDgUIEweHa5wEjRMIkxiBHYlzhSE2YAOkFYFpgmaCFw
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="121235272"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 13 Sep 2012 13:15:50 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8DDFo92003215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 13:15:50 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Thu, 13 Sep 2012 08:15:49 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Lou Berger 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObAAASWMgAAIiywQAAku1IAACmMi4P//vSoAgABP6SCAAG7CgIAAUrMg
Date: Thu, 13 Sep 2012 13:15:49 +0000
Message-ID: 
References:    <5051D959.2010809@labn.net>
In-Reply-To: <5051D959.2010809@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005
x-tm-as-result: No--67.084000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 13:15:54 -0000

VGhhbmtzIExvdSBmb3IgeW91ciByZXBseS4NCg0KR29vZCB0byBrbm93IHRoYXQgTk9USUZZIG1l
c3NhZ2VzIGNhbiBiZSBnZW5lcmF0ZWQgd2l0aG91dCBOT1RJRlkgcmVxdWVzdCBtZXNzYWdlcy4g
VGhhbmtzIGZvciB0aGlzIGluZm8uIFNvIEkgYWdyZWUgdGhhdCBlZ3Jlc3Mgbm9kZSBTSE9VTEQg
cmVsYXkgdGhlIHNpZ25hbGluZyBlcnJvcnMgYmFzZWQgb24gYXNzb2NpYXRpb24gdHlwZSBvZiAi
U2luZ2xlIFNpZGVkIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzIiBhbmQgcHJlc2VuY2Ug
b2YgIlJFVkVSU0VfTFNQIiBvYmplY3QuDQoNCkhhdmluZyBzYWlkIHRoYXQsIGlmIGFuIGluZ3Jl
c3Mgbm9kZSBzdXBwb3J0cyBSRkMzNDczIGFuZCBtYWtlcyByZXF1ZXN0IGJ5IHNlbmRpbmcgTk9U
SUZZIHJlcXVlc3QgbWVzc2FnZSB0byBhIHRyYW5zaXQgbm9kZSwgYW5kIHRyYW5zaXQgbm9kZSBh
bHNvIHN1cHBvcnRzIFJGQzM0NzMgYW5kIHRoZSBOT1RJRlkgcmVwbHksIHRoZSByZXZlcnNlIExT
UCBzaWduYWxpbmcgbm90aWZpY2F0aW9uIGZyb20gdGhpcyB0cmFuc2l0IG5vZGUgY2FuIHdvcmsg
YXMgd2VsbCBpbmRlcGVuZGVudCBvZiBlZ3Jlc3MgcmVsYXlpbmcgdGhlIG1lc3NhZ2VzLiBEbyB5
b3UgYWdyZWU/IA0KDQpUaGFua3MsDQpSYWtlc2gNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50
OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAyMDEyIDk6MDIgQU0NClRvOiBSYWtlc2ggR2FuZGhp
IChyZ2FuZGhpKQ0KQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbjsgY2NhbXBAaWV0Zi5vcmcNClN1
YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBkcmFmdC1pZXRmLWNjYW1wLW1w
bHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KUmFrZXNoLA0KCVRoaXMg
c2VlbXMgcmVhbGx5IGNvbXBsaWNhdGVkLiAgV2h5IGFsbG93IGZvciB0aGUgb3B0aW9uYWwgbm90
aWZpY2F0aW9uIGZyb20gdGhlIGVncmVzcz8gIFRoZXJlIGlzIHByZWNlZGVudCBmb3IgdXNlIG9m
IG5vdGlmeSBtZXNzYWdlcyB3aXRob3V0IG5vdGlmeSByZXF1ZXN0cyAoc2VlIFJGQzQ5NzQpLg0K
DQpBbHNvLCBhcyBpdCBzdGFuZHMgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIHJlYWxseSBvbmx5
IHJlcXVpcmVzIHN1cHBvcnQgYnkgdGhlIGVuZCBub2Rlcy4gKEkgdGhpbmsgb2YgaXQgYXMgYWxt
b3N0IGFuIGFwcGxpY2F0aW9uIG92ZXJsYXkgb24gdG9wIG9mIG5vcm1hbCBMU1Agc2lnbmFsaW5n
LiAgSSdkIGV2ZW4gY29uc2lkZXIgdXNpbmcgdGhlIFJGQzQ5NzQgY2FsbCBhcHByb2FjaCBpZiBp
dCB3YXNuJ3QgZm9yIHJlcXVpcmVtZW50IDExIGluIFJGQzYzNzMuKSAgSSB0aGluayBwbGFjaW5n
IHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzIG9uIHRyYW5zaXQgbm9kZXMsIHN1Y2ggYXMgc2VuZGlu
ZyByZXZlcnNlX2xzcCBub3RpZmljYXRpb25zIGFkZHMgdW5uZWNlc3NhcnkgY29tcGxleGl0eSBh
bmQgc2hvdWxkIGJlIGF2b2lkZWQgdW5sZXNzIGFic29sdXRlbHkgbmVjZXNzYXJ5Lg0KDQpMb3Ug
KGFzIHBhcnRpY2lwYW50KQ0KDQpPbiA5LzEyLzIwMTIgOTo1NyBQTSwgUmFrZXNoIEdhbmRoaSAo
cmdhbmRoaSkgd3JvdGU6DQo+IEhpIEZlaSwNCj4gDQo+ICANCj4gDQo+IEkgc2VlIHdoYXQgeW91
IGFyZSBzYXlpbmcuIFJld29yZGluZyB0aGUgdGV4dCB0byByZWZsZWN0IHRoaXMgKG5vdCANCj4g
c3VyZSBhYm91dCChsFNIT1VMRKGxIHdvcmQgdXNhZ2UpOg0KPiANCj4gIA0KPiANCj4gV2hlbiBh
biBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICJTaW5nbGUgU2lk
ZWQgDQo+IEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzIiBhbmQgd2lzaGVzIHRvIGNvbnRy
b2wgYm90aCBmb3J3YXJkIGFuZCANCj4gcmV2ZXJzZSBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9M
U1AiIG9iamVjdCwgdGhlIGluZ3Jlc3Mgbm9kZSBTSE9VTEQgDQo+IGtub3cgdGhlIHNpZ25hbGlu
ZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZlcnNlIExTUC4gVHJhbnNpdCBhbmQgDQo+IGVncmVz
cyBub2RlcyBTSE9VTEQgYmUgcmVxdWVzdGVkIHRvIG5vdGlmeSB0aGUgc2lnbmFsaW5nIGVycm9y
IG9uIHRoZSANCj4gcmV2ZXJzZSBMU1AgYnkgdXNpbmcgdGhlIE5PVElGWSBtZXNzYWdlIGFuZCBw
cm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDWzM0NzNdLg0KPiANCj4gIA0KPiANCj4gIA0KPiANCj4g
VGhhbmtzLA0KPiANCj4gUmFrZXNoDQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiAqRnJvbToqemhh
bmcuZmVpM0B6dGUuY29tLmNuIFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuXQ0KPiAqU2Vu
dDoqIFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDk6NDAgUE0NCj4gKlRvOiogUmFrZXNo
IEdhbmRoaSAocmdhbmRoaSkNCj4gKkNjOiogY2NhbXBAaWV0Zi5vcmc7IExvdSBCZXJnZXINCj4g
KlN1YmplY3Q6KiBSRTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4gDQo+IGRyYWZ0LWlldGYt
Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPiANCj4gIA0K
PiANCj4gDQo+IEhpIFJla2VzaCwgTG91DQo+IA0KPiAgLz4gICAgICAgICAgU3BlYWtpbmcgYXMg
V0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRoaXMNCj4gdG9vIG11Y2gg
c28gbWF5IGJlIG9mZiwgYnV0IG1ldGhvZCAzIHNlZW1zIHRvIGJlIG1vc3QgY29uc2lzdGVudCB3
aXRoIA0KPiB0aGUgdXNhZ2Ugb2YgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgcGF0aCBt
ZXNzYWdlLiAgUGVyaGFwcyANCj4gY29uc2lkZXIgdXNpbmcgdGhlIFJFVkVSU0VfTFNQIE9iamVj
dCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24gDQo+IHRvIGFsbG93IHRoZSBlZ3Jlc3Mv
dGFpbCB0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hlYWQgd2l0aCBhcmJpdHJhcnkgDQo+IGluZm9y
bWF0aW9uLi4uLi8NCj4gDQo+IDxmZWk+V2VsbCwgSSBjYW4gc2VlIG9uZSBvZiB0aGUgYWR2YW50
YWdlcyBvZiB0aGlzIHByb3Bvc2FsIGlzIHRoYXQgaXQgDQo+IGFsbG93cyB0aGUgcG9saWN5IGNv
bnRyb2wgaW4gdGhlIGVncmVzcy90YWlsLCB3aGVyZSBhIGRlY2lzaW9uIGNhbiBiZSANCj4gbWFk
ZSB0aGF0IHdoZXRoZXIgdGhlIHNpZ25hbGluZyBlcnJvciBzaG91bGQgYmUgcGFzc2VkIHRvIHRo
ZSANCj4gaW5ncmVzcy9oZWFkLiBCdXQgaXQgY2hhbmdlcyB0aGUgcnVsZXMgZGVmaW5lZCBpbiBS
RkMzNDczLi4uLg0KPiANCj4gICAgICBUaGUgb3RoZXIgcHJvcG9zYWwga2VlcHMgYWxpZ25tZW50
IHdpdGggUkZDMzQ3MywgYW5kIEkgcHJlZmVyIGl0IA0KPiBpZiB0aGUgTFNQIGNvbnRyb2wgaXMg
dG90YWxseSBpbiBoYW5kIG9mIHRoZSBpbmdyZXNzL2hlYWQgKGluIG90aGVyIA0KPiB3b3Jkcywg
dGhlcmUgaXMgbm8gbW9yZSBpbmZvcm1hdGlvbiBuZWVkcyB0aGUgZWdyZXMvdGFpbCB0byBpbmZv
cm0gdGhlIA0KPiBpbmdyZXNzL2hlYWQpLg0KPiANCj4gKiJSYWtlc2ggR2FuZGhpIChyZ2FuZGhp
KSIgPHJnYW5kaGlAY2lzY28uY29tIA0KPiA8bWFpbHRvOnJnYW5kaGlAY2lzY28uY29tPj4qDQo+
IA0KPiAyMDEyLTA5LTEzIDA4OjUzDQo+IA0KPiAJDQo+IA0KPiDK1bz+yMsNCj4gDQo+IAkNCj4g
DQo+ICJ6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+
Ig0KPiA8emhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNu
Pj4NCj4gDQo+ILOty80NCj4gDQo+IAkNCj4gDQo+ICJjY2FtcEBpZXRmLm9yZyA8bWFpbHRvOmNj
YW1wQGlldGYub3JnPiIgPGNjYW1wQGlldGYub3JnIA0KPiA8bWFpbHRvOmNjYW1wQGlldGYub3Jn
Pj4sIExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQgDQo+IDxtYWlsdG86bGJlcmdlckBsYWJu
Lm5ldD4+DQo+IA0KPiDW98ziDQo+IA0KPiAJDQo+IA0KPiBSRTogUXVlc3Rpb24gb24gTFNQIGNv
bnRyb2wgaW4NCj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl
ZC1sc3AtMDQudHh0DQo+IA0KPiAgDQo+IA0KPiAJDQo+IA0KPiANCj4gDQo+IA0KPiBIaSBGZWks
DQo+ICANCj4gUGxlYXNlIHNlZSBpbmxpbmUuLjxSRz4uLg0KPiAgDQo+ICpGcm9tOip6aGFuZy5m
ZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+IA0KPiBbbWFpbHRv
OnpoYW5nLmZlaTNAenRlLmNvbS5jbl0gPG1haWx0bzpbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNv
bS5jbl0+IA0KPiAqDQo+IFNlbnQ6KiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA4OjQy
IFBNKg0KPiBUbzoqIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpKg0KPiBDYzoqIGNjYW1wQGlldGYu
b3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBMb3UgQmVyZ2VyKg0KPiBTdWJqZWN0OiogUkU6
IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAt
cnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gIA0KPiANCj4gSGkgUmFrZXNoDQo+
IA0KPiBJbiB0aGUgYWJzZW5jZSBvZiBzdWNoIG5vdGlmaWNhdGlvbiByZXF1ZXN0LCBlZ3Jlc3Mg
bm9kZSBTSE9VTEQgcmVsYXkgDQo+IHRoZSByZWNlaXZlZCBzaWduYWxpbmcgZXJyb3Igb24gdGhl
IHJldmVyc2UgTFNQIHRvIHRoZSBpbmdyZXNzIG5vZGUgDQo+IHVzaW5nIHRoZSBOT1RJRlkgbWVz
c2FnZS4iDQo+IA0KPiA8ZmVpPiAiTm90ZSB0aGF0IGEgTm90aWZ5IG1lc3NhZ2UgTVVTVCBOT1Qg
YmUgZ2VuZXJhdGVkIHVubGVzcyBhbiANCj4gYXBwcm9wcmlhdGUgTm90aWZ5IFJlcXVlc3Qgb2Jq
ZWN0IGhhcyBiZWVuIHJlY2VpdmVkLiINCj4gDQo+ICAgICAgIElmIG15IHVuZGVyc3RhbmRpbmcg
aXMgY29ycmVjdCwgeW91ciBwcm9wb3NlZCByZWxheSBtZWNoYW5pc20gDQo+IGRvZXMgbm90IGRl
cGVuZCBvbiB0aGUgZXhpc3Rpbmcgb2YgdGhlIE5vdGlmeSBSZXF1ZXN0IG9iamVjdCwgd2hpY2gg
DQo+IG1heSBjb25mbGljdCB3aXRoIHRoZQ0KPiAgICAgICBkZXNjcmlwaXRvbnMgaW4gUkZDMzQ3
My4NCj4gDQo+ICAgICAgIERvIHlvdSB3YW50IHRvIGNoYW5nZSB0aGlzIG9yIGRvIEkgaGF2ZSBz
b21lIG1pc3VuZGVyc3RhbmRpbmc/ICANCj4gDQo+IDxSRz4gWWVzIHlvdXIgdW5kZXJzdGFuZGlu
ZyBpcyBjb3JyZWN0LiAgTk9USUZZIG1lc3NhZ2UgaW4gdGhpcyBjYXNlIA0KPiBpcyBnZW5lcmF0
ZWQgYmFzZWQgb24gdGhlIHByZXNlbmNlIG9mIHRoZSChsFJFVkVSU0VfTFNQobEgb2JqZWN0IGFu
ZCANCj4gYXNzb2NpYXRpb24gdHlwZSChsFNpbmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0
aW9uYWwgTFNQcy4gIEkgDQo+IHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNheWluZyB0aG91Z2gu
IEZZSSwgIExvdSBoYWQgZm9sbG93aW5nIA0KPiB0aG91Z2h0cyBvbiB0aGlzLiBEbyB5b3UgdGhp
bmsgdGhpcyBzaW1wbGlmaWVzIHRoaW5ncyA/DQo+IC8+ICAgICAgICAgIFNwZWFraW5nIGFzIFdH
IHBhcnRpY2lwYW50LCBJIGhhdmVuJ3QgdGhvdWdodCBhYm91dCB0aGlzIHRvbw0KPiBtdWNoIHNv
IG1heSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBtb3N0IGNvbnNpc3RlbnQgd2l0
aCB0aGUgDQo+IHVzYWdlIG9mIHRoZSBSRVZFUlNFX0xTUCBPYmplY3QgaW4gdGhlIHBhdGggbWVz
c2FnZS4gIFBlcmhhcHMgY29uc2lkZXIgDQo+IHVzaW5nIHRoZSBSRVZFUlNFX0xTUCBPYmplY3Qg
aW4gdGhlIHVwc3RyZWFtL1Jlc3YgZGlyZWN0aW9uIHRvIGFsbG93IA0KPiB0aGUgZWdyZXNzL3Rh
aWwgdG8gcHJvdmlkZSB0aGUgaW5ncmVzcy9oZWFkIHdpdGggYXJiaXRyYXJ5IGluZm9ybWF0aW9u
Li4uLg0KPiAvDQo+IFRoYW5rcywNCj4gUmFrZXNoDQo+ICANCj4gIA0KPiANCj4gUmVnYXJkcw0K
PiANCj4gRmVpDQo+IA0KPiAqIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8KipyZ2FuZGhpQGNp
c2NvLmNvbSoNCj4gPG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4qPioNCj4gDQo+IDIwMTItMDkt
MTMgMDE6MjMNCj4gDQo+IAkNCj4gDQo+ICANCj4gDQo+IMrVvP7Iyw0KPiANCj4gCQ0KPiANCj4g
TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldCA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0K
PiANCj4gs63LzQ0KPiANCj4gCQ0KPiANCj4gInpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRv
OnpoYW5nLmZlaTNAenRlLmNvbS5jbj4iDQo+IDx6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0
bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+PiwgDQo+ICJjY2FtcEBpZXRmLm9yZyA8bWFpbHRvOmNj
YW1wQGlldGYub3JnPiIgPGNjYW1wQGlldGYub3JnIA0KPiA8bWFpbHRvOmNjYW1wQGlldGYub3Jn
Pj4NCj4gDQo+INb3zOINCj4gDQo+IAkNCj4gDQo+IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJv
bCBpbg0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxz
cC0wNC50eHQNCj4gDQo+IA0KPiAgDQo+IA0KPiAgDQo+IA0KPiAJDQo+IA0KPiANCj4gDQo+IA0K
PiANCj4gSGkgTG91LCBGZWksIFdHLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHJlcGxpZXMuIE1h
eSBJIHByb3Bvc2UgZm9sbG93aW5nIHRleHQgdG8gY292ZXIgdGhpcyANCj4gY2FzZT8gVGhpcyBh
bGxvd3MgdGhlIG1pZC1wb2ludCBzb2x1dGlvbiB3aGljaCBoYXMgYWR2YW50YWdlcyBidXQgDQo+
IGdpdmVuIHRoZSBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgY2FuIGJlIG9wdGlvbmFsLg0KPiANCj4g
UGxlYXNlIGFkdmlzZS4NCj4gDQo+ICJXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIGlz
IHByb3Zpc2lvbmVkIHdpdGggIlNpbmdsZSBTaWRlZCANCj4gQXNzb2NpYXRlZCBCaWRpcmVjdGlv
bmFsIExTUHMiIGFuZCB3aXNoZXMgdG8gY29udHJvbCBib3RoIGZvcndhcmQgYW5kIA0KPiByZXZl
cnNlICBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9MU1AiIG9iamVjdCwgdGhlIGluZ3Jlc3Mgbm9k
ZSBTSE9VTEQgDQo+IGtub3cgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZl
cnNlIExTUC4gIEEgdHJhbnNpdCBub2RlIA0KPiBNQVkgYmUgcmVxdWVzdGVkIHRvIG5vdGlmeSB0
aGUgc2lnbmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNlIExTUCBieSANCj4gdXNpbmcgdGhlIE5P
VElGWSBtZXNzYWdlIGFuZCBwcm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDWzM0NzNdLiBJbiB0aGUg
DQo+IGFic2VuY2Ugb2Ygc3VjaCBub3RpZmljYXRpb24gcmVxdWVzdCwgZWdyZXNzIG5vZGUgU0hP
VUxEIHJlbGF5IHRoZSANCj4gcmVjZWl2ZWQgc2lnbmFsaW5nIGVycm9yIG9uIHRoZSByZXZlcnNl
IExTUCB0byB0aGUgaW5ncmVzcyBub2RlIHVzaW5nIA0KPiB0aGUgTk9USUZZIG1lc3NhZ2UuIg0K
PiANCj4gVGhhbmtzLA0KPiBSYWtlc2gNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQo+IDxt
YWlsdG86W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XT4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0
ZW1iZXIgMTIsIDIwMTIgMTI6MTQgUE0NCj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+
IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+
OyANCj4gY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4gU3ViamVjdDog
UmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMt
dHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4gDQo+IFJha2VzaCwNCj4gDQo+
IA0KPiBPbiA5LzEyLzIwMTIgMTE6NTIgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3Rl
Og0KPj4gVGhhbmtzIExvdS4NCj4+IA0KPj4gQXJlIHdlIG9rIGluIGdlbmVyYWwgdG8gdXNlIE5P
VElGWSBtZXNzYWdlIFtSRkMzNDczXSBmb3IgdGhpcz8NCj4gDQo+IEknbSBub3Qgc3BlYWtpbmcg
Zm9yIHRoZSBXRywgYXMgbm90ZWQgbXkgY29tbWVudHMgd2VyZSBhcyBhIHBhcnRpY2lwYW50Lg0K
PiBJTU8geW91J2xsIG5lZWQgdG8gZnVsbHkgZG9jdW1lbnQgdGhlIHByb3Bvc2FsLCBwZXJoYXBz
IGRpc2N1c3MgDQo+IGFsdGVybmF0aXZlcyBjb25zaWRlcmVkLCBhbmQgdGhlbiBhc2sgdGhlIFdH
IGZvciBjb25jdXJyZW5jZS4NCj4gDQo+PiANCj4+IE9uZSBhZHZhbnRhZ2Ugd2l0aCB0aGUgbWlk
LXBvaW50IHNlbmRpbmcgbm90aWZpY2F0aW9uIGZvciB0aGUgcmV2ZXJzZSANCj4+IExTUCBpcyB0
aGF0IHNpZ25hbGluZyBlcnJvciBwcm9wYWdhdGlvbiB0aW1lDQo+PiAobWlkLT5lZ3Jlc3Mtbm9k
ZS0+aW5ncmVzcy1ub2RlKSBpcyBzaWduaWZpY2FudGx5IHJlZHVjZWQgKHRvDQo+PiBtaWQtPmlu
Z3Jlc3Mtbm9kZSkgd2hpY2ggbWF5IGJlIHByZWZlcnJlZCBpbiBzb21lIGNhc2VzLg0KPiANCj4+
RnJvbSBteSAocGVyc29uYWwpIHBlcnNwZWN0aXZlLCB0aGUgYWRkZWQgY29tcGxleGl0eSBpc24n
dCB3b3J0aCB0aGUgZWZmb3J0LiAgT2YgY291cnNlLCBhIGRldGFpbGVkIHByb3Bvc2FsIG1heSBz
aG93IG90aGVyd2lzZS4NCj4gDQo+IExvdQ0KPiANCj4+IA0KPj4gVGhhbmtzLA0KPj4gUmFrZXNo
DQo+PiANCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IExvdSBC
ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANCj4+IDxtYWlsdG86W21haWx0bzpsYmVy
Z2VyQGxhYm4ubmV0XT4NCj4+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDk6
MTUgQU0NCj4+IFRvOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4gQ2M6IHpoYW5nLmZlaTNA
enRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj47IA0KPj4gY2NhbXBAaWV0
Zi5vcmcNCj4gPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlv
biBvbiBMU1AgY29udHJvbCBpbiANCj4+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUt
ZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4gDQo+PiBSYWtlc2gsDQo+PiAgICAgICAgICAg
ICAgICAgIFNwZWFraW5nIGFzIFdHIHBhcnRpY2lwYW50LCBJIGhhdmVuJ3QgdGhvdWdodCBhYm91
dCANCj4+IHRoaXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhvZCAzIHNlZW1zIHRv
IGJlIG1vc3QgY29uc2lzdGVudCANCj4+IHdpdGggdGhlIHVzYWdlIG9mIHRoZSBSRVZFUlNFX0xT
UCBPYmplY3QgaW4gdGhlIHBhdGggbWVzc2FnZS4gIA0KPj4gUGVyaGFwcyBjb25zaWRlciB1c2lu
ZyB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2IA0KPj4gZGlyZWN0
aW9uIHRvIGFsbG93IHRoZSBlZ3Jlc3MvdGFpbCB0byBwcm92aWRlIHRoZQ0KPiBpbmdyZXNzL2hl
YWQgd2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24uLi4uDQo+PiANCj4+IExvdQ0KPj4gDQo+PiBP
biA5LzExLzIwMTIgOToyMiBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+Pj4g
SGkgV0csDQo+Pj4NCj4+PiBBbnkgdGhvdWdodHMgb24gdGhlIGZvbGxvd2luZyBwcm9wb3NhbD8N
Cj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBSYWtlc2gNCj4+Pg0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4+IFNl
bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNDQo+Pj4gVG86ICdMb3UgQmVy
Z2VyJw0KPj4+IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0
ZS5jb20uY24+OyANCj4+PiBjY2FtcEBpZXRmLm9yZw0KPiA8bWFpbHRvOmNjYW1wQGlldGYub3Jn
Pg0KPj4+IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiANCj4+PiBkcmFm
dC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4+
Pg0KPj4+DQo+Pj4gVGhhbmtzIExvdSBmb3IgeW91ciByZXBseS4NCj4+Pg0KPj4+IFJGQyAzNDcz
IGRlZmluZXMgcHJvY2VkdXJlcyBmb3IgTk9USUZZIHJlcXVlc3QgYW5kIHJlcGx5LiBXZSBjb3Vs
ZCB1c2UgdGhpcyBmb3IgcmV2ZXJzZSBMU1Agc2lnbmFsaW5nIGVycm9yIG5vdGlmaWNhdGlvbiB0
byB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUuDQo+Pj4NCj4+PiA8Tm90aWZ5IG1lc3NhZ2U+
IDo6PSA8Q29tbW9uIEhlYWRlcj4gWzxJTlRFR1JJVFk+XSBbIFs8TUVTU0FHRV9JRF9BQ0s+IHwg
PE1FU1NBR0VfSURfTkFDSz5dIC4uLiBdDQo+Pj4gPEVSUk9SX1NQRUM+ICAgDQo+Pj4gPG5vdGlm
eSBzZXNzaW9uIGxpc3QgOjo9IDx1cHN0cmVhbSBzZXNzaW9uPiA8ZG93bnN0cmVhbSBzZXNzaW9u
PiAgPg0KPj4+DQo+Pj4gVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgd2UgY2FuIHVzZSB0aGUgTk9U
SUZZIG1lc3NhZ2UuDQo+Pj4NCj4+PiBNZXRob2QgMSAtIE1pZC1wb2ludCBhd2FyZSB3aXRoIFBh
dGggbWVzc2FnZSByZXF1ZXN0Og0KPj4+IFdoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQ
YXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsIHRoZSBub2RlIHdpbGwgaW5zZXJ0
IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUgcmV2ZXJzZSBMU1AgcGF0aCBtZXNzYWdlIHdpdGgg
bm9kZSBJRCBvZiB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUuIEEgbWlkLXBvaW50IG5vZGUg
d2lsbCBzZW5kICBhIGNvcHkgb2YgdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGlu
ZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4+Pg0KPj4+IElQdjQgTm90aWZ5IFJl
cXVlc3QgT2JqZWN0DQo+Pj4gICAgSVB2NCBOb3RpZnkgTm9kZSBBZGRyZXNzOiAzMiBiaXRzDQo+
Pj4gICAgICAgVGhlIElQIGFkZHJlc3Mgb2YgdGhlIG5vZGUgdGhhdCBzaG91bGQgYmUgbm90aWZp
ZWQgd2hlbiBnZW5lcmF0aW5nIGFuIGVycm9yIG1lc3NhZ2UuDQo+Pj4NCj4+PiBNZXRob2QgMiAt
IE1pZC1wb2ludCBhd2FyZSB3aXRoIFJlc3YgbWVzc2FnZSByZXF1ZXN0Og0KPj4+IFdoZW4gYW4g
aW5pdGlhdGluZyBpbmdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2UgZm9yIGEgcmV2
ZXJzZSBMU1AsIHRoZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUg
cmV2ZXJzZSBMU1AgUmVzdiBtZXNzYWdlIHdpdGggaXRzIG93biBub2RlIElELiBBIG1pZC1wb2lu
dCBub2RlIHdpbGwgc2VuZCBhIGNvcHkgb2YgdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5p
dGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4+Pg0KPj4+IE1ldGhvZCAz
IC0gVGFpbC1lbmQgcmVsYXlpbmcgOg0KPj4+IFdoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMg
YSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xTUCBvYmplY3QsIA0KPj4+IHRoZSBub2RlIHdp
bGwgcmVsYXkgdGhlIHJlY2VpdmVkIHNpZ25hbGluZyBlcnJvciBtZXNzYWdlIG9uIHRoZSANCj4+
PiByZXZlcnNlIExTUCB0byB0aGUgaW5pdGlhbGl6aW5nIGluZ3Jlc3Mgbm9kZS4gVGhlIGVncmVz
cyBub2RlIGNvcGllcyANCj4+PiB0aGUgcmVjZWl2ZWQgIkVSUk9SX1NQRUMiIG9iamVjdCBpbnRv
IGEgTk9USUZZIFtSRkMzNDczLCBzZWN0aW9uIA0KPj4+IDQuM10gbWVzc2FnZSBhbmQgc2lnbmFs
cyBpdCB0byB0aGUgaW5ncmVzcyBub2RlLiBJbiB0aGlzIGNhc2UsDQo+IE5PVElGWV9SRVEgbWVz
c2FnZSBpcyBub3QgcmVxdWlyZWQuDQo+Pj4NCj4+PiBQbGVhc2UgYWR2aXNlIHlvdXIgdGhvdWdo
dHMuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gUmFrZXNoDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJl
cmdlckBsYWJuLm5ldF0gDQo+Pj4gPG1haWx0bzpbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPg0K
Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMTozNSBBTQ0KPj4+IFRvOiBS
YWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4+IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1h
aWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+OyANCj4+PiBjY2FtcEBpZXRmLm9yZw0KPiA8bWFp
bHRvOmNjYW1wQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29u
dHJvbCBpbiANCj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh
dGVkLWxzcC0wNC50eHQNCj4+Pg0KPj4+IEFzIEkgcmVhZCB0aGUgY3VycmVudCByZXYsIG5vIHN1
Y2ggbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBpcyBzcGVjaWZpZWQuDQo+Pj4gIExvb2tzIGxpa2Ug
eW91IGdldCB0byBwcm9wb3NlIG9uZSENCj4+Pg0KPj4+IExvdSAoYXMgV0cgcGFydGljaXBhbnQp
Lg0KPj4+DQo+Pj4gT24gOC8zMS8yMDEyIDk6NDkgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkp
IHdyb3RlOg0KPj4+PiBIaSBMb3UsIEZlaSwNCj4+Pj4NCj4+Pj4gV2hlbiBhbiAob3JpZ2luYXRp
bmcpIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICI1IChUQkQpICANCj4+Pj4gU2lu
Z2xlIFNpZGVkIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzICAoQSkiIGFuZCB3aXNoZXMg
dG8gDQo+Pj4+IGNvbnRyb2wgYm90aCBmb3J3YXJkIGFuZCByZXZlcnNlICBMU1BzIGJ5IGFkZGlu
ZyAiUkVWRVJTRV9MU1AiIA0KPj4+PiBvYmplY3QsIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgaW5n
cmVzcyBub2RlIG5lZWRzIHRvIGtub3cgYWJvdXQgdGhlIA0KPj4+PiBzaWduYWxpbmcgKHBhdGgp
IGVycm9ycyAoc3VjaCBhcyBzb2Z0IHByZWVtcHRpb24gb3IgYWRtaXNzaW9uDQo+IGZhaWx1cmUp
IG9uIHRoZSByZXZlcnNlIExTUC4gIElzIHRoZXJlIGFueSB0ZXh0IHNvbWV3aGVyZSBpbiBhbiAN
Cj4gUkZDL2RyYWZ0IHRoYXQgZGVzY3JpYmVzIGhvdyBhIG1pZC1wb2ludCBub2RlIGNhbiBzZW5k
IHRoZSBzaWduYWxpbmcNCj4gKHBhdGgpIGVycm9yIHRvIHRoZSBvcmlnaW5hdGluZyBpbmdyZXNz
IG5vZGUgZm9yIHRoZSByZXZlcnNlIExTUD8gSXMgDQo+IHRoZXJlIGFuIGFzc3VtcHRpb24gdG8g
dXNlIFJTVlBfTk9USUZZIG1lc3NhZ2U/IFNvcnJ5IGlmIEkgaGFkIG1pc3NlZCANCj4gYW55IHBy
ZXZpb3VzIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYy4NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+
PiBSYWtlc2gNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+
Pg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+IA0K

From lberger@labn.net  Thu Sep 13 06:32: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 DBCF321F8533 for ; Thu, 13 Sep 2012 06:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.819
X-Spam-Level: 
X-Spam-Status: No, score=-98.819 tagged_above=-999 required=5 tests=[AWL=-1.108, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g9OTxH0VAWp for ; Thu, 13 Sep 2012 06:32:45 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 9FE5121F8498 for ; Thu, 13 Sep 2012 06:32:45 -0700 (PDT)
Received: (qmail 27209 invoked by uid 0); 13 Sep 2012 13:32:45 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 13 Sep 2012 13:32:45 -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=TzuqWDOkOWo1jKmTLmZz+QI9NuTyYj7RprP/jRew9dY=;  b=0tXcdWAvlzZgBWprjCJQtgwfXUcEOuQZQUAx9Ulv/fIBjdeUW3pKAekKYFLHQw8ItJEk0WHka838jN0stBtLGxdO4XOnbKsUzD1YvlDfcfRCABiHFtkxmLIw/bB87Hva;
Received: from box313.bluehost.com ([69.89.31.113]:58791 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TC9XA-00020q-P6; Thu, 13 Sep 2012 07:32:45 -0600
Message-ID: <5051E07A.40505@labn.net>
Date: Thu, 13 Sep 2012 09:32:42 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" 
References:    <5051D959.2010809@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
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] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 13:32:47 -0000

If one wanted to be cute, an ingress could include a NOTIFY_REQUEST
containing the ingress' address in the REVERSE_LSP object as well as the
Resv messages of incoming associated bidirectional LSPs.  Of course,
this means that the ingress would be notified of path errors for an LSP
for which it doesn't have path state...

Do you really want to go down the path of document all possible
uses/combination of objects carried in REVERSE_LSP objects?

Lou

On 9/13/2012 9:15 AM, Rakesh Gandhi (rgandhi) wrote:
> Thanks Lou for your reply.
> 
> Good to know that NOTIFY messages can be generated without NOTIFY request messages. Thanks for this info. So I agree that egress node SHOULD relay the signaling errors based on association type of "Single Sided Associated Bidirectional LSPs" and presence of "REVERSE_LSP" object.
> 
> Having said that, if an ingress node supports RFC3473 and makes request by sending NOTIFY request message to a transit node, and transit node also supports RFC3473 and the NOTIFY reply, the reverse LSP signaling notification from this transit node can work as well independent of egress relaying the messages. Do you agree? 
> 
> Thanks,
> Rakesh
> 
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Thursday, September 13, 2012 9:02 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Rakesh,
> 	This seems really complicated.  Why allow for the optional notification from the egress?  There is precedent for use of notify messages without notify requests (see RFC4974).
> 
> Also, as it stands Associated Bidirectional really only requires support by the end nodes. (I think of it as almost an application overlay on top of normal LSP signaling.  I'd even consider using the RFC4974 call approach if it wasn't for requirement 11 in RFC6373.)  I think placing processing requirements on transit nodes, such as sending reverse_lsp notifications adds unnecessary complexity and should be avoided unless absolutely necessary.
> 
> Lou (as participant)
> 
> On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
>> Hi Fei,
>>
>>  
>>
>> I see what you are saying. Rewording the text to reflect this (not 
>> sure about ¡°SHOULD¡± word usage):
>>
>>  
>>
>> When an initiating ingress node is provisioned with "Single Sided 
>> Associated Bidirectional LSPs" and wishes to control both forward and 
>> reverse LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD 
>> know the signaling (path) errors on the reverse LSP. Transit and 
>> egress nodes SHOULD be requested to notify the signaling error on the 
>> reverse LSP by using the NOTIFY message and procedures defined in RFC[3473].
>>
>>  
>>
>>  
>>
>> Thanks,
>>
>> Rakesh
>>
>>  
>>
>>  
>>
>> *From:*zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
>> *Sent:* Wednesday, September 12, 2012 9:40 PM
>> *To:* Rakesh Gandhi (rgandhi)
>> *Cc:* ccamp@ietf.org; Lou Berger
>> *Subject:* RE: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>  
>>
>>
>> Hi Rekesh, Lou
>>
>>  />          Speaking as WG participant, I haven't thought about this
>> too much so may be off, but method 3 seems to be most consistent with 
>> the usage of the REVERSE_LSP Object in the path message.  Perhaps 
>> consider using the REVERSE_LSP Object in the upstream/Resv direction 
>> to allow the egress/tail to provide the ingress/head with arbitrary 
>> information..../
>>
>> Well, I can see one of the advantages of this proposal is that it 
>> allows the policy control in the egress/tail, where a decision can be 
>> made that whether the signaling error should be passed to the 
>> ingress/head. But it changes the rules defined in RFC3473....
>>
>>      The other proposal keeps alignment with RFC3473, and I prefer it 
>> if the LSP control is totally in hand of the ingress/head (in other 
>> words, there is no more information needs the egres/tail to inform the 
>> ingress/head).
>>
>> *"Rakesh Gandhi (rgandhi)" > >*
>>
>> 2012-09-13 08:53
>>
>> 	
>>
>> ÊÕ¼þÈË
>>
>> 	
>>
>> "zhang.fei3@zte.com.cn "
>> >
>>
>> ³­ËÍ
>>
>> 	
>>
>> "ccamp@ietf.org " > >, Lou Berger > >
>>
>> Ö÷Ìâ
>>
>> 	
>>
>> RE: Question on LSP control in
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>  
>>
>> 	
>>
>>
>>
>>
>> Hi Fei,
>>  
>> Please see inline....
>>  
>> *From:*zhang.fei3@zte.com.cn  
>> [mailto:zhang.fei3@zte.com.cn]  
>> *
>> Sent:* Wednesday, September 12, 2012 8:42 PM*
>> To:* Rakesh Gandhi (rgandhi)*
>> Cc:* ccamp@ietf.org ; Lou Berger*
>> Subject:* RE: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>  
>>
>> Hi Rakesh
>>
>> In the absence of such notification request, egress node SHOULD relay 
>> the received signaling error on the reverse LSP to the ingress node 
>> using the NOTIFY message."
>>
>>  "Note that a Notify message MUST NOT be generated unless an 
>> appropriate Notify Request object has been received."
>>
>>       If my understanding is correct, your proposed relay mechanism 
>> does not depend on the existing of the Notify Request object, which 
>> may conflict with the
>>       descripitons in RFC3473.
>>
>>       Do you want to change this or do I have some misunderstanding?  
>>
>>  Yes your understanding is correct.  NOTIFY message in this case 
>> is generated based on the presence of the ¡°REVERSE_LSP¡± object and 
>> association type ¡°Single Sided Associated Bidirectional LSPs.  I 
>> understand what you are saying though. FYI,  Lou had following 
>> thoughts on this. Do you think this simplifies things ?
>> />          Speaking as WG participant, I haven't thought about this too
>> much so may be off, but method 3 seems to be most consistent with the 
>> usage of the REVERSE_LSP Object in the path message.  Perhaps consider 
>> using the REVERSE_LSP Object in the upstream/Resv direction to allow 
>> the egress/tail to provide the ingress/head with arbitrary information....
>> /
>> Thanks,
>> Rakesh
>>  
>>  
>>
>> Regards
>>
>> Fei
>>
>> *"Rakesh Gandhi (rgandhi)" <**rgandhi@cisco.com*
>> *>*
>>
>> 2012-09-13 01:23
>>
>> 	
>>
>>  
>>
>> ÊÕ¼þÈË
>>
>> 	
>>
>> Lou Berger >
>>
>> ³­ËÍ
>>
>> 	
>>
>> "zhang.fei3@zte.com.cn "
>> >, 
>> "ccamp@ietf.org " > >
>>
>> Ö÷Ìâ
>>
>> 	
>>
>> RE: Question on LSP control in
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>>
>>  
>>
>>  
>>
>> 	
>>
>>
>>
>>
>>
>> Hi Lou, Fei, WG,
>>
>> Thanks for your replies. May I propose following text to cover this 
>> case? This allows the mid-point solution which has advantages but 
>> given the additional complexity can be optional.
>>
>> Please advise.
>>
>> "When an initiating ingress node is provisioned with "Single Sided 
>> Associated Bidirectional LSPs" and wishes to control both forward and 
>> reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD 
>> know the signaling (path) errors on the reverse LSP.  A transit node 
>> MAY be requested to notify the signaling error on the reverse LSP by 
>> using the NOTIFY message and procedures defined in RFC[3473]. In the 
>> absence of such notification request, egress node SHOULD relay the 
>> received signaling error on the reverse LSP to the ingress node using 
>> the NOTIFY message."
>>
>> Thanks,
>> Rakesh
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net] 
>> 
>> Sent: Wednesday, September 12, 2012 12:14 PM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn ; 
>> ccamp@ietf.org 
>> Subject: Re: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> Rakesh,
>>
>>
>> On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
>>> Thanks Lou.
>>>
>>> Are we ok in general to use NOTIFY message [RFC3473] for this?
>>
>> I'm not speaking for the WG, as noted my comments were as a participant.
>> IMO you'll need to fully document the proposal, perhaps discuss 
>> alternatives considered, and then ask the WG for concurrence.
>>
>>>
>>> One advantage with the mid-point sending notification for the reverse 
>>> LSP is that signaling error propagation time
>>> (mid->egress-node->ingress-node) is significantly reduced (to
>>> mid->ingress-node) which may be preferred in some cases.
>>
>> >From my (personal) perspective, the added complexity isn't worth the effort.  Of course, a detailed proposal may show otherwise.
>>
>> Lou
>>
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net] 
>>> 
>>> Sent: Wednesday, September 12, 2012 9:15 AM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: zhang.fei3@zte.com.cn ; 
>>> ccamp@ietf.org
>> 
>>> Subject: Re: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>> Rakesh,
>>>                  Speaking as WG participant, I haven't thought about 
>>> this too much so may be off, but method 3 seems to be most consistent 
>>> with the usage of the REVERSE_LSP Object in the path message.  
>>> Perhaps consider using the REVERSE_LSP Object in the upstream/Resv 
>>> direction to allow the egress/tail to provide the
>> ingress/head with arbitrary information....
>>>
>>> Lou
>>>
>>> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
>>>> Hi WG,
>>>>
>>>> Any thoughts on the following proposal?
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Rakesh Gandhi (rgandhi)
>>>> Sent: Tuesday, September 04, 2012 1:36 PM
>>>> To: 'Lou Berger'
>>>> Cc: zhang.fei3@zte.com.cn ; 
>>>> ccamp@ietf.org
>> 
>>>> Subject: RE: Question on LSP control in 
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>>
>>>> Thanks Lou for your reply.
>>>>
>>>> RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node.
>>>>
>>>>  ::=  [] [ [ | ] ... ]
>>>>    
>>>>    >
>>>>
>>>> There are multiple ways we can use the NOTIFY message.
>>>>
>>>> Method 1 - Mid-point aware with Path message request:
>>>> When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send  a copy of the signaling error to the initiating node using the NOTIFY message.
>>>>
>>>> IPv4 Notify Request Object
>>>>    IPv4 Notify Node Address: 32 bits
>>>>       The IP address of the node that should be notified when generating an error message.
>>>>
>>>> Method 2 - Mid-point aware with Resv message request:
>>>> When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message.
>>>>
>>>> Method 3 - Tail-end relaying :
>>>> When an egress node receives a Path message with REVERSE_LSP object, 
>>>> the node will relay the received signaling error message on the 
>>>> reverse LSP to the initializing ingress node. The egress node copies 
>>>> the received "ERROR_SPEC" object into a NOTIFY [RFC3473, section 
>>>> 4.3] message and signals it to the ingress node. In this case,
>> NOTIFY_REQ message is not required.
>>>>
>>>> Please advise your thoughts.
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net] 
>>>> 
>>>> Sent: Tuesday, September 04, 2012 11:35 AM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: zhang.fei3@zte.com.cn ; 
>>>> ccamp@ietf.org
>> 
>>>> Subject: Re: Question on LSP control in 
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> As I read the current rev, no such notification mechanism is specified.
>>>>  Looks like you get to propose one!
>>>>
>>>> Lou (as WG participant).
>>>>
>>>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>>>>> Hi Lou, Fei,
>>>>>
>>>>> When an (originating) ingress node is provisioned with "5 (TBD)  
>>>>> Single Sided Associated Bidirectional LSPs  (A)" and wishes to 
>>>>> control both forward and reverse  LSPs by adding "REVERSE_LSP" 
>>>>> object, I would think that the ingress node needs to know about the 
>>>>> signaling (path) errors (such as soft preemption or admission
>> failure) on the reverse LSP.  Is there any text somewhere in an 
>> RFC/draft that describes how a mid-point node can send the signaling
>> (path) error to the originating ingress node for the reverse LSP? Is 
>> there an assumption to use RSVP_NOTIFY message? Sorry if I had missed 
>> any previous discussion on this topic.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>

From rgandhi@cisco.com  Thu Sep 13 06:51: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 9657221F8564 for ; Thu, 13 Sep 2012 06:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.447
X-Spam-Level: 
X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj+h1jqhFJom for ; Thu, 13 Sep 2012 06:51:25 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 799C921F85A2 for ; Thu, 13 Sep 2012 06:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21000; q=dns/txt; s=iport; t=1347544284; x=1348753884; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8ziilnZD/GpUJhPxcPVB8Eh6Ou7KXtCLWy2tWurO4LA=; b=A+qHIbmqeWwYfsgZWzfpHqu8RlOh3wWWJxCGRt8wHy6N1RO64d5H6NZC UkvCKrtlys1hoaHJMI6bu3AuH66YfJegIYAp/QMmch0iZNGCyeODM7QEJ mstpJTNHVVAsFNLGU3EKkUnX2h6T04VEUmeFhTfEWWeRcsYplktDtRjjZ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJbjUVCtJV2a/2dsb2JhbABFhge0eW+BB4IgAQEBBBIBFA0zEgwEAgEGAg4DBAEBAQQGHQUCAjAUCQgCBA4FCBMHh2ubb40TCJMZgR2Jc4UhNmADpBWBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,417,1344211200"; d="scan'208";a="121221374"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 13 Sep 2012 13:51:21 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8DDpLtX002589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 13:51:21 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Thu, 13 Sep 2012 08:51:21 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Lou Berger 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2Hf3Os+VLHAQPjT0mEShgHpTx4wgDXVW4AAAiZetABSEkbsAA8itKAAAUdObAAASWMgAAIiywQAAku1IAACmMi4P//vSoAgABP6SCAAG7CgIAAUrMg//+1zACAAFG0wA==
Date: Thu, 13 Sep 2012 13:51:20 +0000
Message-ID: 
References:    <5051D959.2010809@labn.net>  <5051E07A.40505@labn.net>
In-Reply-To: <5051E07A.40505@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.005
x-tm-as-result: No--68.475100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 13:51:27 -0000

SGkgTG91LA0KDQpUaGUgTk9USUZZIHJlcXVlc3QgYW5kIHJlcGx5IHByb2NlZHVyZXMgYXJlIGRl
ZmluZWQgaW4gUkZDMzQ3MyBhbmQgY2FuIGJlIHVzZWQgYnkgYW55IG5vZGUgd2hvIHN1cHBvcnRz
IHRoaXMgUkZDIGFuZCB0aGlzIGRyYWZ0IGRvZXMgbm90IGFkZC9yZW1vdmUvbW9kaWZ5IGFueSBi
ZWhhdmlvci9yZXF1aXJlbWVudCBpbiB0aGF0IHJlZ2FyZC4gDQoNCkkgZGlkbid0IG1lYW4gdG8g
aW5jbHVkZSB0aGUgTk9USUZZIHJlcXVlc3Qgb2JqZWN0IGluIHRoZSBSRVZFUlNFX0xTUCBvYmpl
Y3RzIGVpdGhlci4NCg0KQXJlIHdlIG9rIHRvIGFkZCBmb2xsb3dpbmcgdGV4dD8gDQoNCiAiV2hl
biBhbiBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICJTaW5nbGUg
U2lkZWQgDQogQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMiIGFuZCB3aXNoZXMgdG8gY29u
dHJvbCBib3RoIGZvcndhcmQgYW5kIA0KIHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZFUlNF
X0xTUCIgb2JqZWN0LCB0aGUgaW5ncmVzcyBub2RlIFNIT1VMRCANCiBrbm93IHRoZSBzaWduYWxp
bmcgKHBhdGgpIGVycm9ycyBvbiB0aGUgcmV2ZXJzZSBMU1AuICANCiBBbiBlZ3Jlc3Mgbm9kZSBN
QVkgdXNlIE5PVElGWSBtZXNzYWdlIGFuZCBwcm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDWzM0NzNd
IGZvciByZWxheWluZyANCiBzaWduYWxpbmcgZXJyb3Igb24gdGhlIHJldmVyc2UgTFNQIHRvIHRo
ZSBpbmdyZXNzIG5vZGUuIg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0g
DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAyMDEyIDk6MzMgQU0NClRvOiBSYWtlc2gg
R2FuZGhpIChyZ2FuZGhpKQ0KQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbjsgY2NhbXBAaWV0Zi5v
cmcNClN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiBkcmFmdC1pZXRmLWNj
YW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCg0KSWYgb25lIHdh
bnRlZCB0byBiZSBjdXRlLCBhbiBpbmdyZXNzIGNvdWxkIGluY2x1ZGUgYSBOT1RJRllfUkVRVUVT
VCBjb250YWluaW5nIHRoZSBpbmdyZXNzJyBhZGRyZXNzIGluIHRoZSBSRVZFUlNFX0xTUCBvYmpl
Y3QgYXMgd2VsbCBhcyB0aGUgUmVzdiBtZXNzYWdlcyBvZiBpbmNvbWluZyBhc3NvY2lhdGVkIGJp
ZGlyZWN0aW9uYWwgTFNQcy4gIE9mIGNvdXJzZSwgdGhpcyBtZWFucyB0aGF0IHRoZSBpbmdyZXNz
IHdvdWxkIGJlIG5vdGlmaWVkIG9mIHBhdGggZXJyb3JzIGZvciBhbiBMU1AgZm9yIHdoaWNoIGl0
IGRvZXNuJ3QgaGF2ZSBwYXRoIHN0YXRlLi4uDQoNCkRvIHlvdSByZWFsbHkgd2FudCB0byBnbyBk
b3duIHRoZSBwYXRoIG9mIGRvY3VtZW50IGFsbCBwb3NzaWJsZSB1c2VzL2NvbWJpbmF0aW9uIG9m
IG9iamVjdHMgY2FycmllZCBpbiBSRVZFUlNFX0xTUCBvYmplY3RzPw0KDQpMb3UNCg0KT24gOS8x
My8yMDEyIDk6MTUgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPiBUaGFua3Mg
TG91IGZvciB5b3VyIHJlcGx5Lg0KPiANCj4gR29vZCB0byBrbm93IHRoYXQgTk9USUZZIG1lc3Nh
Z2VzIGNhbiBiZSBnZW5lcmF0ZWQgd2l0aG91dCBOT1RJRlkgcmVxdWVzdCBtZXNzYWdlcy4gVGhh
bmtzIGZvciB0aGlzIGluZm8uIFNvIEkgYWdyZWUgdGhhdCBlZ3Jlc3Mgbm9kZSBTSE9VTEQgcmVs
YXkgdGhlIHNpZ25hbGluZyBlcnJvcnMgYmFzZWQgb24gYXNzb2NpYXRpb24gdHlwZSBvZiAiU2lu
Z2xlIFNpZGVkIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzIiBhbmQgcHJlc2VuY2Ugb2Yg
IlJFVkVSU0VfTFNQIiBvYmplY3QuDQo+IA0KPiBIYXZpbmcgc2FpZCB0aGF0LCBpZiBhbiBpbmdy
ZXNzIG5vZGUgc3VwcG9ydHMgUkZDMzQ3MyBhbmQgbWFrZXMgcmVxdWVzdCBieSBzZW5kaW5nIE5P
VElGWSByZXF1ZXN0IG1lc3NhZ2UgdG8gYSB0cmFuc2l0IG5vZGUsIGFuZCB0cmFuc2l0IG5vZGUg
YWxzbyBzdXBwb3J0cyBSRkMzNDczIGFuZCB0aGUgTk9USUZZIHJlcGx5LCB0aGUgcmV2ZXJzZSBM
U1Agc2lnbmFsaW5nIG5vdGlmaWNhdGlvbiBmcm9tIHRoaXMgdHJhbnNpdCBub2RlIGNhbiB3b3Jr
IGFzIHdlbGwgaW5kZXBlbmRlbnQgb2YgZWdyZXNzIHJlbGF5aW5nIHRoZSBtZXNzYWdlcy4gRG8g
eW91IGFncmVlPyANCj4gDQo+IFRoYW5rcywNCj4gUmFrZXNoDQo+IA0KPiANCj4gDQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2Vy
QGxhYm4ubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAyMDEyIDk6MDIgQU0N
Cj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20u
Y247IGNjYW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJv
bCBpbiANCj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1s
c3AtMDQudHh0DQo+IA0KPiBSYWtlc2gsDQo+IAlUaGlzIHNlZW1zIHJlYWxseSBjb21wbGljYXRl
ZC4gIFdoeSBhbGxvdyBmb3IgdGhlIG9wdGlvbmFsIG5vdGlmaWNhdGlvbiBmcm9tIHRoZSBlZ3Jl
c3M/ICBUaGVyZSBpcyBwcmVjZWRlbnQgZm9yIHVzZSBvZiBub3RpZnkgbWVzc2FnZXMgd2l0aG91
dCBub3RpZnkgcmVxdWVzdHMgKHNlZSBSRkM0OTc0KS4NCj4gDQo+IEFsc28sIGFzIGl0IHN0YW5k
cyBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgcmVhbGx5IG9ubHkgcmVxdWlyZXMgc3VwcG9ydCBi
eSB0aGUgZW5kIG5vZGVzLiAoSSB0aGluayBvZiBpdCBhcyBhbG1vc3QgYW4gYXBwbGljYXRpb24g
b3ZlcmxheSBvbiB0b3Agb2Ygbm9ybWFsIExTUCBzaWduYWxpbmcuICBJJ2QgZXZlbiBjb25zaWRl
ciB1c2luZyB0aGUgUkZDNDk3NCBjYWxsIGFwcHJvYWNoIGlmIGl0IHdhc24ndCBmb3IgcmVxdWly
ZW1lbnQgMTEgaW4gUkZDNjM3My4pICBJIHRoaW5rIHBsYWNpbmcgcHJvY2Vzc2luZyByZXF1aXJl
bWVudHMgb24gdHJhbnNpdCBub2Rlcywgc3VjaCBhcyBzZW5kaW5nIHJldmVyc2VfbHNwIG5vdGlm
aWNhdGlvbnMgYWRkcyB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5IGFuZCBzaG91bGQgYmUgYXZvaWRl
ZCB1bmxlc3MgYWJzb2x1dGVseSBuZWNlc3NhcnkuDQo+IA0KPiBMb3UgKGFzIHBhcnRpY2lwYW50
KQ0KPiANCj4gT24gOS8xMi8yMDEyIDk6NTcgUE0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdy
b3RlOg0KPj4gSGkgRmVpLA0KPj4NCj4+ICANCj4+DQo+PiBJIHNlZSB3aGF0IHlvdSBhcmUgc2F5
aW5nLiBSZXdvcmRpbmcgdGhlIHRleHQgdG8gcmVmbGVjdCB0aGlzIChub3QgDQo+PiBzdXJlIGFi
b3V0IKGwU0hPVUxEobEgd29yZCB1c2FnZSk6DQo+Pg0KPj4gIA0KPj4NCj4+IFdoZW4gYW4gaW5p
dGlhdGluZyBpbmdyZXNzIG5vZGUgaXMgcHJvdmlzaW9uZWQgd2l0aCAiU2luZ2xlIFNpZGVkIA0K
Pj4gQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMiIGFuZCB3aXNoZXMgdG8gY29udHJvbCBi
b3RoIGZvcndhcmQgYW5kIA0KPj4gcmV2ZXJzZSBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9MU1Ai
IG9iamVjdCwgdGhlIGluZ3Jlc3Mgbm9kZSBTSE9VTEQgDQo+PiBrbm93IHRoZSBzaWduYWxpbmcg
KHBhdGgpIGVycm9ycyBvbiB0aGUgcmV2ZXJzZSBMU1AuIFRyYW5zaXQgYW5kIA0KPj4gZWdyZXNz
IG5vZGVzIFNIT1VMRCBiZSByZXF1ZXN0ZWQgdG8gbm90aWZ5IHRoZSBzaWduYWxpbmcgZXJyb3Ig
b24gdGhlIA0KPj4gcmV2ZXJzZSBMU1AgYnkgdXNpbmcgdGhlIE5PVElGWSBtZXNzYWdlIGFuZCBw
cm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDWzM0NzNdLg0KPj4NCj4+ICANCj4+DQo+PiAgDQo+Pg0K
Pj4gVGhhbmtzLA0KPj4NCj4+IFJha2VzaA0KPj4NCj4+ICANCj4+DQo+PiAgDQo+Pg0KPj4gKkZy
b206KnpoYW5nLmZlaTNAenRlLmNvbS5jbiBbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbl0N
Cj4+ICpTZW50OiogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgOTo0MCBQTQ0KPj4gKlRv
OiogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+ICpDYzoqIGNjYW1wQGlldGYub3JnOyBMb3Ug
QmVyZ2VyDQo+PiAqU3ViamVjdDoqIFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiANCj4+
IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4
dA0KPj4NCj4+ICANCj4+DQo+Pg0KPj4gSGkgUmVrZXNoLCBMb3UNCj4+DQo+PiAgLz4gICAgICAg
ICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IHRo
aXMNCj4+IHRvbyBtdWNoIHNvIG1heSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBt
b3N0IGNvbnNpc3RlbnQgd2l0aCANCj4+IHRoZSB1c2FnZSBvZiB0aGUgUkVWRVJTRV9MU1AgT2Jq
ZWN0IGluIHRoZSBwYXRoIG1lc3NhZ2UuICBQZXJoYXBzIA0KPj4gY29uc2lkZXIgdXNpbmcgdGhl
IFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24gDQo+PiB0
byBhbGxvdyB0aGUgZWdyZXNzL3RhaWwgdG8gcHJvdmlkZSB0aGUgaW5ncmVzcy9oZWFkIHdpdGgg
YXJiaXRyYXJ5IA0KPj4gaW5mb3JtYXRpb24uLi4uLw0KPj4NCj4+IDxmZWk+V2VsbCwgSSBjYW4g
c2VlIG9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGlzIHByb3Bvc2FsIGlzIHRoYXQgDQo+PiBp
dCBhbGxvd3MgdGhlIHBvbGljeSBjb250cm9sIGluIHRoZSBlZ3Jlc3MvdGFpbCwgd2hlcmUgYSBk
ZWNpc2lvbiBjYW4gDQo+PiBiZSBtYWRlIHRoYXQgd2hldGhlciB0aGUgc2lnbmFsaW5nIGVycm9y
IHNob3VsZCBiZSBwYXNzZWQgdG8gdGhlIA0KPj4gaW5ncmVzcy9oZWFkLiBCdXQgaXQgY2hhbmdl
cyB0aGUgcnVsZXMgZGVmaW5lZCBpbiBSRkMzNDczLi4uLg0KPj4NCj4+ICAgICAgVGhlIG90aGVy
IHByb3Bvc2FsIGtlZXBzIGFsaWdubWVudCB3aXRoIFJGQzM0NzMsIGFuZCBJIHByZWZlciBpdCAN
Cj4+IGlmIHRoZSBMU1AgY29udHJvbCBpcyB0b3RhbGx5IGluIGhhbmQgb2YgdGhlIGluZ3Jlc3Mv
aGVhZCAoaW4gb3RoZXIgDQo+PiB3b3JkcywgdGhlcmUgaXMgbm8gbW9yZSBpbmZvcm1hdGlvbiBu
ZWVkcyB0aGUgZWdyZXMvdGFpbCB0byBpbmZvcm0gDQo+PiB0aGUgaW5ncmVzcy9oZWFkKS4NCj4+
DQo+PiAqIlJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIiA8cmdhbmRoaUBjaXNjby5jb20NCj4+IDxt
YWlsdG86cmdhbmRoaUBjaXNjby5jb20+PioNCj4+DQo+PiAyMDEyLTA5LTEzIDA4OjUzDQo+Pg0K
Pj4gCQ0KPj4NCj4+IMrVvP7Iyw0KPj4NCj4+IAkNCj4+DQo+PiAiemhhbmcuZmVpM0B6dGUuY29t
LmNuIDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPiINCj4+IDx6aGFuZy5mZWkzQHp0ZS5j
b20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+Pg0KPj4NCj4+ILOty80NCj4+DQo+
PiAJDQo+Pg0KPj4gImNjYW1wQGlldGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2Nh
bXBAaWV0Zi5vcmcgDQo+PiA8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4sIExvdSBCZXJnZXIgPGxi
ZXJnZXJAbGFibi5uZXQgDQo+PiA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPj4NCj4+INb3
zOINCj4+DQo+PiAJDQo+Pg0KPj4gUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluDQo+PiBk
cmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQN
Cj4+DQo+PiAgDQo+Pg0KPj4gCQ0KPj4NCj4+DQo+Pg0KPj4NCj4+IEhpIEZlaSwNCj4+ICANCj4+
IFBsZWFzZSBzZWUgaW5saW5lLi48Ukc+Li4NCj4+ICANCj4+ICpGcm9tOip6aGFuZy5mZWkzQHp0
ZS5jb20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+IA0KPj4gW21haWx0bzp6aGFu
Zy5mZWkzQHp0ZS5jb20uY25dIA0KPj4gPG1haWx0bzpbbWFpbHRvOnpoYW5nLmZlaTNAenRlLmNv
bS5jbl0+DQo+PiAqDQo+PiBTZW50OiogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgODo0
MiBQTSoNCj4+IFRvOiogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkqDQo+PiBDYzoqIGNjYW1wQGll
dGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+OyBMb3UgQmVyZ2VyKg0KPj4gU3ViamVjdDoq
IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiANCj4+IGRyYWZ0LWlldGYtY2NhbXAtbXBs
cy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4gIA0KPj4NCj4+IEhpIFJh
a2VzaA0KPj4NCj4+IEluIHRoZSBhYnNlbmNlIG9mIHN1Y2ggbm90aWZpY2F0aW9uIHJlcXVlc3Qs
IGVncmVzcyBub2RlIFNIT1VMRCByZWxheSANCj4+IHRoZSByZWNlaXZlZCBzaWduYWxpbmcgZXJy
b3Igb24gdGhlIHJldmVyc2UgTFNQIHRvIHRoZSBpbmdyZXNzIG5vZGUgDQo+PiB1c2luZyB0aGUg
Tk9USUZZIG1lc3NhZ2UuIg0KPj4NCj4+IDxmZWk+ICJOb3RlIHRoYXQgYSBOb3RpZnkgbWVzc2Fn
ZSBNVVNUIE5PVCBiZSBnZW5lcmF0ZWQgdW5sZXNzIGFuIA0KPj4gYXBwcm9wcmlhdGUgTm90aWZ5
IFJlcXVlc3Qgb2JqZWN0IGhhcyBiZWVuIHJlY2VpdmVkLiINCj4+DQo+PiAgICAgICBJZiBteSB1
bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIHlvdXIgcHJvcG9zZWQgcmVsYXkgbWVjaGFuaXNtIA0K
Pj4gZG9lcyBub3QgZGVwZW5kIG9uIHRoZSBleGlzdGluZyBvZiB0aGUgTm90aWZ5IFJlcXVlc3Qg
b2JqZWN0LCB3aGljaCANCj4+IG1heSBjb25mbGljdCB3aXRoIHRoZQ0KPj4gICAgICAgZGVzY3Jp
cGl0b25zIGluIFJGQzM0NzMuDQo+Pg0KPj4gICAgICAgRG8geW91IHdhbnQgdG8gY2hhbmdlIHRo
aXMgb3IgZG8gSSBoYXZlIHNvbWUgbWlzdW5kZXJzdGFuZGluZz8gIA0KPj4NCj4+IDxSRz4gWWVz
IHlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LiAgTk9USUZZIG1lc3NhZ2UgaW4gdGhpcyBj
YXNlIA0KPj4gaXMgZ2VuZXJhdGVkIGJhc2VkIG9uIHRoZSBwcmVzZW5jZSBvZiB0aGUgobBSRVZF
UlNFX0xTUKGxIG9iamVjdCBhbmQgDQo+PiBhc3NvY2lhdGlvbiB0eXBlIKGwU2luZ2xlIFNpZGVk
IEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCBMU1BzLiAgSSANCj4+IHVuZGVyc3RhbmQgd2hhdCB5
b3UgYXJlIHNheWluZyB0aG91Z2guIEZZSSwgIExvdSBoYWQgZm9sbG93aW5nIA0KPj4gdGhvdWdo
dHMgb24gdGhpcy4gRG8geW91IHRoaW5rIHRoaXMgc2ltcGxpZmllcyB0aGluZ3MgPw0KPj4gLz4g
ICAgICAgICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFi
b3V0IHRoaXMgdG9vDQo+PiBtdWNoIHNvIG1heSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0
byBiZSBtb3N0IGNvbnNpc3RlbnQgd2l0aCB0aGUgDQo+PiB1c2FnZSBvZiB0aGUgUkVWRVJTRV9M
U1AgT2JqZWN0IGluIHRoZSBwYXRoIG1lc3NhZ2UuICBQZXJoYXBzIA0KPj4gY29uc2lkZXIgdXNp
bmcgdGhlIFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiBkaXJlY3Rpb24g
DQo+PiB0byBhbGxvdyB0aGUgZWdyZXNzL3RhaWwgdG8gcHJvdmlkZSB0aGUgaW5ncmVzcy9oZWFk
IHdpdGggYXJiaXRyYXJ5IGluZm9ybWF0aW9uLi4uLg0KPj4gLw0KPj4gVGhhbmtzLA0KPj4gUmFr
ZXNoDQo+PiAgDQo+PiAgDQo+Pg0KPj4gUmVnYXJkcw0KPj4NCj4+IEZlaQ0KPj4NCj4+ICoiUmFr
ZXNoIEdhbmRoaSAocmdhbmRoaSkiIDwqKnJnYW5kaGlAY2lzY28uY29tKg0KPj4gPG1haWx0bzpy
Z2FuZGhpQGNpc2NvLmNvbT4qPioNCj4+DQo+PiAyMDEyLTA5LTEzIDAxOjIzDQo+Pg0KPj4gCQ0K
Pj4NCj4+ICANCj4+DQo+PiDK1bz+yMsNCj4+DQo+PiAJDQo+Pg0KPj4gTG91IEJlcmdlciA8bGJl
cmdlckBsYWJuLm5ldCA8bWFpbHRvOmxiZXJnZXJAbGFibi5uZXQ+Pg0KPj4NCj4+ILOty80NCj4+
DQo+PiAJDQo+Pg0KPj4gInpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNA
enRlLmNvbS5jbj4iDQo+PiA8emhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVp
M0B6dGUuY29tLmNuPj4sIA0KPj4gImNjYW1wQGlldGYub3JnIDxtYWlsdG86Y2NhbXBAaWV0Zi5v
cmc+IiA8Y2NhbXBAaWV0Zi5vcmcgDQo+PiA8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4NCj4+DQo+
PiDW98ziDQo+Pg0KPj4gCQ0KPj4NCj4+IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbg0K
Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQu
dHh0DQo+Pg0KPj4NCj4+ICANCj4+DQo+PiAgDQo+Pg0KPj4gCQ0KPj4NCj4+DQo+Pg0KPj4NCj4+
DQo+PiBIaSBMb3UsIEZlaSwgV0csDQo+Pg0KPj4gVGhhbmtzIGZvciB5b3VyIHJlcGxpZXMuIE1h
eSBJIHByb3Bvc2UgZm9sbG93aW5nIHRleHQgdG8gY292ZXIgdGhpcyANCj4+IGNhc2U/IFRoaXMg
YWxsb3dzIHRoZSBtaWQtcG9pbnQgc29sdXRpb24gd2hpY2ggaGFzIGFkdmFudGFnZXMgYnV0IA0K
Pj4gZ2l2ZW4gdGhlIGFkZGl0aW9uYWwgY29tcGxleGl0eSBjYW4gYmUgb3B0aW9uYWwuDQo+Pg0K
Pj4gUGxlYXNlIGFkdmlzZS4NCj4+DQo+PiAiV2hlbiBhbiBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9k
ZSBpcyBwcm92aXNpb25lZCB3aXRoICJTaW5nbGUgU2lkZWQgDQo+PiBBc3NvY2lhdGVkIEJpZGly
ZWN0aW9uYWwgTFNQcyIgYW5kIHdpc2hlcyB0byBjb250cm9sIGJvdGggZm9yd2FyZCBhbmQgDQo+
PiByZXZlcnNlICBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9MU1AiIG9iamVjdCwgdGhlIGluZ3Jl
c3Mgbm9kZSBTSE9VTEQgDQo+PiBrbm93IHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyBvbiB0
aGUgcmV2ZXJzZSBMU1AuICBBIHRyYW5zaXQgbm9kZSANCj4+IE1BWSBiZSByZXF1ZXN0ZWQgdG8g
bm90aWZ5IHRoZSBzaWduYWxpbmcgZXJyb3Igb24gdGhlIHJldmVyc2UgTFNQIGJ5IA0KPj4gdXNp
bmcgdGhlIE5PVElGWSBtZXNzYWdlIGFuZCBwcm9jZWR1cmVzIGRlZmluZWQgaW4gUkZDWzM0NzNd
LiBJbiB0aGUgDQo+PiBhYnNlbmNlIG9mIHN1Y2ggbm90aWZpY2F0aW9uIHJlcXVlc3QsIGVncmVz
cyBub2RlIFNIT1VMRCByZWxheSB0aGUgDQo+PiByZWNlaXZlZCBzaWduYWxpbmcgZXJyb3Igb24g
dGhlIHJldmVyc2UgTFNQIHRvIHRoZSBpbmdyZXNzIG5vZGUgdXNpbmcgDQo+PiB0aGUgTk9USUZZ
IG1lc3NhZ2UuIg0KPj4NCj4+IFRoYW5rcywNCj4+IFJha2VzaA0KPj4NCj4+DQo+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJA
bGFibi5uZXRdIA0KPj4gPG1haWx0bzpbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdPg0KPj4gU2Vu
dDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgMTI6MTQgUE0NCj4+IFRvOiBSYWtlc2gg
R2FuZGhpIChyZ2FuZGhpKQ0KPj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRvOnpo
YW5nLmZlaTNAenRlLmNvbS5jbj47IA0KPj4gY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcEBp
ZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1AgY29udHJvbCBpbiANCj4+
IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4
dA0KPj4NCj4+IFJha2VzaCwNCj4+DQo+Pg0KPj4gT24gOS8xMi8yMDEyIDExOjUyIEFNLCBSYWtl
c2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+PiBUaGFua3MgTG91Lg0KPj4+DQo+Pj4gQXJl
IHdlIG9rIGluIGdlbmVyYWwgdG8gdXNlIE5PVElGWSBtZXNzYWdlIFtSRkMzNDczXSBmb3IgdGhp
cz8NCj4+DQo+PiBJJ20gbm90IHNwZWFraW5nIGZvciB0aGUgV0csIGFzIG5vdGVkIG15IGNvbW1l
bnRzIHdlcmUgYXMgYSBwYXJ0aWNpcGFudC4NCj4+IElNTyB5b3UnbGwgbmVlZCB0byBmdWxseSBk
b2N1bWVudCB0aGUgcHJvcG9zYWwsIHBlcmhhcHMgZGlzY3VzcyANCj4+IGFsdGVybmF0aXZlcyBj
b25zaWRlcmVkLCBhbmQgdGhlbiBhc2sgdGhlIFdHIGZvciBjb25jdXJyZW5jZS4NCj4+DQo+Pj4N
Cj4+PiBPbmUgYWR2YW50YWdlIHdpdGggdGhlIG1pZC1wb2ludCBzZW5kaW5nIG5vdGlmaWNhdGlv
biBmb3IgdGhlIA0KPj4+IHJldmVyc2UgTFNQIGlzIHRoYXQgc2lnbmFsaW5nIGVycm9yIHByb3Bh
Z2F0aW9uIHRpbWUNCj4+PiAobWlkLT5lZ3Jlc3Mtbm9kZS0+aW5ncmVzcy1ub2RlKSBpcyBzaWdu
aWZpY2FudGx5IHJlZHVjZWQgKHRvDQo+Pj4gbWlkLT5pbmdyZXNzLW5vZGUpIHdoaWNoIG1heSBi
ZSBwcmVmZXJyZWQgaW4gc29tZSBjYXNlcy4NCj4+DQo+PiA+RnJvbSBteSAocGVyc29uYWwpIHBl
cnNwZWN0aXZlLCB0aGUgYWRkZWQgY29tcGxleGl0eSBpc24ndCB3b3J0aCB0aGUgZWZmb3J0LiAg
T2YgY291cnNlLCBhIGRldGFpbGVkIHByb3Bvc2FsIG1heSBzaG93IG90aGVyd2lzZS4NCj4+DQo+
PiBMb3UNCj4+DQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gUmFrZXNoDQo+Pj4NCj4+Pg0KPj4+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxi
ZXJnZXJAbGFibi5uZXRdIA0KPj4+IDxtYWlsdG86W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XT4N
Cj4+PiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA5OjE1IEFNDQo+Pj4gVG86
IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+Pj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8
bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj47IA0KPj4+IGNjYW1wQGlldGYub3JnDQo+PiA8
bWFpbHRvOmNjYW1wQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBvbiBMU1Ag
Y29udHJvbCBpbiANCj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3Nv
Y2lhdGVkLWxzcC0wNC50eHQNCj4+Pg0KPj4+IFJha2VzaCwNCj4+PiAgICAgICAgICAgICAgICAg
IFNwZWFraW5nIGFzIFdHIHBhcnRpY2lwYW50LCBJIGhhdmVuJ3QgdGhvdWdodCBhYm91dCANCj4+
PiB0aGlzIHRvbyBtdWNoIHNvIG1heSBiZSBvZmYsIGJ1dCBtZXRob2QgMyBzZWVtcyB0byBiZSBt
b3N0IA0KPj4+IGNvbnNpc3RlbnQgd2l0aCB0aGUgdXNhZ2Ugb2YgdGhlIFJFVkVSU0VfTFNQIE9i
amVjdCBpbiB0aGUgcGF0aCBtZXNzYWdlLg0KPj4+IFBlcmhhcHMgY29uc2lkZXIgdXNpbmcgdGhl
IFJFVkVSU0VfTFNQIE9iamVjdCBpbiB0aGUgdXBzdHJlYW0vUmVzdiANCj4+PiBkaXJlY3Rpb24g
dG8gYWxsb3cgdGhlIGVncmVzcy90YWlsIHRvIHByb3ZpZGUgdGhlDQo+PiBpbmdyZXNzL2hlYWQg
d2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24uLi4uDQo+Pj4NCj4+PiBMb3UNCj4+Pg0KPj4+IE9u
IDkvMTEvMjAxMiA5OjIyIEFNLCBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+Pj4g
SGkgV0csDQo+Pj4+DQo+Pj4+IEFueSB0aG91Z2h0cyBvbiB0aGUgZm9sbG93aW5nIHByb3Bvc2Fs
Pw0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+IFJha2VzaA0KPj4+Pg0KPj4+Pg0KPj4+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhp
KQ0KPj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTIgMTozNiBQTQ0KPj4+PiBU
bzogJ0xvdSBCZXJnZXInDQo+Pj4+IENjOiB6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6
aGFuZy5mZWkzQHp0ZS5jb20uY24+OyANCj4+Pj4gY2NhbXBAaWV0Zi5vcmcNCj4+IDxtYWlsdG86
Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJFOiBRdWVzdGlvbiBvbiBMU1AgY29udHJv
bCBpbiANCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRl
ZC1sc3AtMDQudHh0DQo+Pj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcyBMb3UgZm9yIHlvdXIgcmVwbHku
DQo+Pj4+DQo+Pj4+IFJGQyAzNDczIGRlZmluZXMgcHJvY2VkdXJlcyBmb3IgTk9USUZZIHJlcXVl
c3QgYW5kIHJlcGx5LiBXZSBjb3VsZCB1c2UgdGhpcyBmb3IgcmV2ZXJzZSBMU1Agc2lnbmFsaW5n
IGVycm9yIG5vdGlmaWNhdGlvbiB0byB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUuDQo+Pj4+
DQo+Pj4+IDxOb3RpZnkgbWVzc2FnZT4gOjo9IDxDb21tb24gSGVhZGVyPiBbPElOVEVHUklUWT5d
IFsgWzxNRVNTQUdFX0lEX0FDSz4gfCA8TUVTU0FHRV9JRF9OQUNLPl0gLi4uIF0NCj4+Pj4gPEVS
Uk9SX1NQRUM+ICAgDQo+Pj4+IDxub3RpZnkgc2Vzc2lvbiBsaXN0IDo6PSA8dXBzdHJlYW0gc2Vz
c2lvbj4gPGRvd25zdHJlYW0gc2Vzc2lvbj4gID4NCj4+Pj4NCj4+Pj4gVGhlcmUgYXJlIG11bHRp
cGxlIHdheXMgd2UgY2FuIHVzZSB0aGUgTk9USUZZIG1lc3NhZ2UuDQo+Pj4+DQo+Pj4+IE1ldGhv
ZCAxIC0gTWlkLXBvaW50IGF3YXJlIHdpdGggUGF0aCBtZXNzYWdlIHJlcXVlc3Q6DQo+Pj4+IFdo
ZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ugd2l0aCBSRVZFUlNFX0xT
UCBvYmplY3QsIHRoZSBub2RlIHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUg
cmV2ZXJzZSBMU1AgcGF0aCBtZXNzYWdlIHdpdGggbm9kZSBJRCBvZiB0aGUgaW5pdGlhdGluZyBp
bmdyZXNzIG5vZGUuIEEgbWlkLXBvaW50IG5vZGUgd2lsbCBzZW5kICBhIGNvcHkgb2YgdGhlIHNp
Z25hbGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGluZyBub2RlIHVzaW5nIHRoZSBOT1RJRlkgbWVz
c2FnZS4NCj4+Pj4NCj4+Pj4gSVB2NCBOb3RpZnkgUmVxdWVzdCBPYmplY3QNCj4+Pj4gICAgSVB2
NCBOb3RpZnkgTm9kZSBBZGRyZXNzOiAzMiBiaXRzDQo+Pj4+ICAgICAgIFRoZSBJUCBhZGRyZXNz
IG9mIHRoZSBub2RlIHRoYXQgc2hvdWxkIGJlIG5vdGlmaWVkIHdoZW4gZ2VuZXJhdGluZyBhbiBl
cnJvciBtZXNzYWdlLg0KPj4+Pg0KPj4+PiBNZXRob2QgMiAtIE1pZC1wb2ludCBhd2FyZSB3aXRo
IFJlc3YgbWVzc2FnZSByZXF1ZXN0Og0KPj4+PiBXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBu
b2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIGZvciBhIHJldmVyc2UgTFNQLCB0aGUgbm9kZSB3
aWxsIGluc2VydCBOT1RJRllfUkVRIG1lc3NhZ2UgaW4gdGhlIHJldmVyc2UgTFNQIFJlc3YgbWVz
c2FnZSB3aXRoIGl0cyBvd24gbm9kZSBJRC4gQSBtaWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQgYSBj
b3B5IG9mIHRoZSBzaWduYWxpbmcgZXJyb3IgdG8gdGhlIGluaXRpYXRpbmcgbm9kZSB1c2luZyB0
aGUgTk9USUZZIG1lc3NhZ2UuDQo+Pj4+DQo+Pj4+IE1ldGhvZCAzIC0gVGFpbC1lbmQgcmVsYXlp
bmcgOg0KPj4+PiBXaGVuIGFuIGVncmVzcyBub2RlIHJlY2VpdmVzIGEgUGF0aCBtZXNzYWdlIHdp
dGggUkVWRVJTRV9MU1AgDQo+Pj4+IG9iamVjdCwgdGhlIG5vZGUgd2lsbCByZWxheSB0aGUgcmVj
ZWl2ZWQgc2lnbmFsaW5nIGVycm9yIG1lc3NhZ2Ugb24gDQo+Pj4+IHRoZSByZXZlcnNlIExTUCB0
byB0aGUgaW5pdGlhbGl6aW5nIGluZ3Jlc3Mgbm9kZS4gVGhlIGVncmVzcyBub2RlIA0KPj4+PiBj
b3BpZXMgdGhlIHJlY2VpdmVkICJFUlJPUl9TUEVDIiBvYmplY3QgaW50byBhIE5PVElGWSBbUkZD
MzQ3MywgDQo+Pj4+IHNlY3Rpb24gNC4zXSBtZXNzYWdlIGFuZCBzaWduYWxzIGl0IHRvIHRoZSBp
bmdyZXNzIG5vZGUuIEluIHRoaXMgDQo+Pj4+IGNhc2UsDQo+PiBOT1RJRllfUkVRIG1lc3NhZ2Ug
aXMgbm90IHJlcXVpcmVkLg0KPj4+Pg0KPj4+PiBQbGVhc2UgYWR2aXNlIHlvdXIgdGhvdWdodHMu
DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gUmFrZXNoDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IExvdSBCZXJnZXIgW21haWx0
bzpsYmVyZ2VyQGxhYm4ubmV0XSANCj4+Pj4gPG1haWx0bzpbbWFpbHRvOmxiZXJnZXJAbGFibi5u
ZXRdPg0KPj4+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDQsIDIwMTIgMTE6MzUgQU0NCj4+
Pj4gVG86IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpDQo+Pj4+IENjOiB6aGFuZy5mZWkzQHp0ZS5j
b20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+OyANCj4+Pj4gY2NhbXBAaWV0Zi5v
cmcNCj4+IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFJlOiBRdWVzdGlv
biBvbiBMU1AgY29udHJvbCBpbiANCj4+Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0
ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+Pj4+DQo+Pj4+IEFzIEkgcmVhZCB0aGUgY3Vy
cmVudCByZXYsIG5vIHN1Y2ggbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBpcyBzcGVjaWZpZWQuDQo+
Pj4+ICBMb29rcyBsaWtlIHlvdSBnZXQgdG8gcHJvcG9zZSBvbmUhDQo+Pj4+DQo+Pj4+IExvdSAo
YXMgV0cgcGFydGljaXBhbnQpLg0KPj4+Pg0KPj4+PiBPbiA4LzMxLzIwMTIgOTo0OSBBTSwgUmFr
ZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+Pj4+PiBIaSBMb3UsIEZlaSwNCj4+Pj4+DQo+
Pj4+PiBXaGVuIGFuIChvcmlnaW5hdGluZykgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdp
dGggIjUgKFRCRCkgDQo+Pj4+PiBTaW5nbGUgU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFs
IExTUHMgIChBKSIgYW5kIHdpc2hlcyB0byANCj4+Pj4+IGNvbnRyb2wgYm90aCBmb3J3YXJkIGFu
ZCByZXZlcnNlICBMU1BzIGJ5IGFkZGluZyAiUkVWRVJTRV9MU1AiDQo+Pj4+PiBvYmplY3QsIEkg
d291bGQgdGhpbmsgdGhhdCB0aGUgaW5ncmVzcyBub2RlIG5lZWRzIHRvIGtub3cgYWJvdXQgDQo+
Pj4+PiB0aGUgc2lnbmFsaW5nIChwYXRoKSBlcnJvcnMgKHN1Y2ggYXMgc29mdCBwcmVlbXB0aW9u
IG9yIGFkbWlzc2lvbg0KPj4gZmFpbHVyZSkgb24gdGhlIHJldmVyc2UgTFNQLiAgSXMgdGhlcmUg
YW55IHRleHQgc29tZXdoZXJlIGluIGFuIA0KPj4gUkZDL2RyYWZ0IHRoYXQgZGVzY3JpYmVzIGhv
dyBhIG1pZC1wb2ludCBub2RlIGNhbiBzZW5kIHRoZSBzaWduYWxpbmcNCj4+IChwYXRoKSBlcnJv
ciB0byB0aGUgb3JpZ2luYXRpbmcgaW5ncmVzcyBub2RlIGZvciB0aGUgcmV2ZXJzZSBMU1A/IElz
IA0KPj4gdGhlcmUgYW4gYXNzdW1wdGlvbiB0byB1c2UgUlNWUF9OT1RJRlkgbWVzc2FnZT8gU29y
cnkgaWYgSSBoYWQgbWlzc2VkIA0KPj4gYW55IHByZXZpb3VzIGRpc2N1c3Npb24gb24gdGhpcyB0
b3BpYy4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MsDQo+Pj4+PiBSYWtlc2gNCj4+Pj4+DQo+Pj4+Pg0K
Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+DQo+Pj4NCj4+
Pg0KPj4+DQo+Pg0K

From rgandhi@cisco.com  Thu Sep 13 12:20: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 CB3AC21F84AE for ; Thu, 13 Sep 2012 12:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level: 
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKYkw0X3T-8D for ; Thu, 13 Sep 2012 12:20:02 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA9E21F84A7 for ; Thu, 13 Sep 2012 12:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22330; q=dns/txt; s=iport; t=1347564002; x=1348773602; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=LTIw8uHcrw5abr1w3sBMPqKisUXuR3/iVbLVxLsbglQ=; b=JCwl3N2+/mxcfbuShenb2AJHJS7tXeNkk+8kTLo+c9zyBqLhQH3A9cU7 pANugJ86aYx2r2nu06UGymxU77aDIp/XN7++c7JKxWIVTAsOr9sz/06np pubvhtgiPh6LoJCG1Zn+0GeUO06dX0OE0/0mFhd7bDyC3yU/bCJrGlpI5 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAPIwUlCtJV2a/2dsb2JhbABFhge1A26BB4IgAQEBBBIBFA0zEgwGAQYCDgMEAQEBBAYdBQQwFAkJAQQOBQgTB4drm06NEwiTFIEdiXOFITZgA6QYgWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,418,1344211200"; d="scan'208";a="121401803"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 13 Sep 2012 19:20:01 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8DJK1k6009636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Sep 2012 19:20:01 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Thu, 13 Sep 2012 14:20:00 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: Lou Berger 
Thread-Topic: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
Thread-Index: Ac2R5LDfutJ8LfESQtqIxv7vLi8wnQ==
Date: Thu, 13 Sep 2012 19:20:00 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.213.162]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.001
x-tm-as-result: No--65.572900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 19:20:04 -0000

SGkgTG91LCBXRywNCg0KV2UgbGlrZSB0byBwb3N0IHRoZSByZXZpc2VkIGRyYWZ0IGFuZCBtaWdo
dCBiZSBhbiBpZGVhIHRvIGluY2x1ZGUgZm9sbG93aW5nIHRleHQuIENhbiB5b3UgcGxlYXNlIHJl
dmlldyBhbmQgYWR2aXNlPyANCg0KIldoZW4gYW4gaW5pdGlhdGluZyBpbmdyZXNzIG5vZGUgaXMg
cHJvdmlzaW9uZWQgd2l0aCAiU2luZ2xlIFNpZGVkICBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwg
TFNQcyIgYW5kIHdpc2hlcyB0byBjb250cm9sIGJvdGggZm9yd2FyZCBhbmQgIHJldmVyc2UgTFNQ
cyBieSBhZGRpbmcgUkVWRVJTRV9MU1Agb2JqZWN0LCB0aGUgaW5pdGlhdGluZyBpbmdyZXNzIG5v
ZGUgU0hPVUxEICBrbm93IHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyBvbiB0aGUgcmV2ZXJz
ZSBMU1AuICBBbiBlZ3Jlc3Mgbm9kZSByZWNlaXZpbmcgQXNzb2NpYXRpb24gb2JqZWN0IHdpdGgg
YXNzb2NpYXRpb24gdHlwZSAiU2luZ2xlIFNpZGVkICBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwg
TFNQcyIgYW5kIFJFVkVSU0VfTFNQIG9iamVjdCBTSE9VTEQgdXNlIHRoZSBOT1RJRlkgbWVzc2Fn
ZSBhbmQgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFJGQ1szNDczXSBmb3IgcmVsYXlpbmcgIHNpZ25h
bGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluaXRpYXRpbmcgaW5ncmVzcyBu
b2RlLiINCg0KVGhhbmtzLA0KUmFrZXNoDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
CkZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJl
ciAxMywgMjAxMiA5OjUxIEFNDQpUbzogJ0xvdSBCZXJnZXInDQpDYzogemhhbmcuZmVpM0B6dGUu
Y29tLmNuOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250
cm9sIGluIGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNw
LTA0LnR4dA0KDQpIaSBMb3UsDQoNClRoZSBOT1RJRlkgcmVxdWVzdCBhbmQgcmVwbHkgcHJvY2Vk
dXJlcyBhcmUgZGVmaW5lZCBpbiBSRkMzNDczIGFuZCBjYW4gYmUgdXNlZCBieSBhbnkgbm9kZSB3
aG8gc3VwcG9ydHMgdGhpcyBSRkMgYW5kIHRoaXMgZHJhZnQgZG9lcyBub3QgYWRkL3JlbW92ZS9t
b2RpZnkgYW55IGJlaGF2aW9yL3JlcXVpcmVtZW50IGluIHRoYXQgcmVnYXJkLiANCg0KSSBkaWRu
J3QgbWVhbiB0byBpbmNsdWRlIHRoZSBOT1RJRlkgcmVxdWVzdCBvYmplY3QgaW4gdGhlIFJFVkVS
U0VfTFNQIG9iamVjdHMgZWl0aGVyLg0KDQpBcmUgd2Ugb2sgdG8gYWRkIGZvbGxvd2luZyB0ZXh0
PyANCg0KICJXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBub2RlIGlzIHByb3Zpc2lvbmVkIHdp
dGggIlNpbmdsZSBTaWRlZCAgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMiIGFuZCB3aXNo
ZXMgdG8gY29udHJvbCBib3RoIGZvcndhcmQgYW5kICByZXZlcnNlICBMU1BzIGJ5IGFkZGluZyAi
UkVWRVJTRV9MU1AiIG9iamVjdCwgdGhlIGluZ3Jlc3Mgbm9kZSBTSE9VTEQgIGtub3cgdGhlIHNp
Z25hbGluZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZlcnNlIExTUC4gIA0KIEFuIGVncmVzcyBu
b2RlIE1BWSB1c2UgTk9USUZZIG1lc3NhZ2UgYW5kIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBSRkNb
MzQ3M10gZm9yIHJlbGF5aW5nICBzaWduYWxpbmcgZXJyb3Igb24gdGhlIHJldmVyc2UgTFNQIHRv
IHRoZSBpbmdyZXNzIG5vZGUuIg0KDQoNClRoYW5rcywNClJha2VzaA0KDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5l
dF0NClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTIgOTozMyBBTQ0KVG86IFJha2Vz
aCBHYW5kaGkgKHJnYW5kaGkpDQpDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuOyBjY2FtcEBpZXRm
Lm9yZw0KU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIGRyYWZ0LWlldGYt
Y2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4dA0KDQpJZiBvbmUg
d2FudGVkIHRvIGJlIGN1dGUsIGFuIGluZ3Jlc3MgY291bGQgaW5jbHVkZSBhIE5PVElGWV9SRVFV
RVNUIGNvbnRhaW5pbmcgdGhlIGluZ3Jlc3MnIGFkZHJlc3MgaW4gdGhlIFJFVkVSU0VfTFNQIG9i
amVjdCBhcyB3ZWxsIGFzIHRoZSBSZXN2IG1lc3NhZ2VzIG9mIGluY29taW5nIGFzc29jaWF0ZWQg
YmlkaXJlY3Rpb25hbCBMU1BzLiAgT2YgY291cnNlLCB0aGlzIG1lYW5zIHRoYXQgdGhlIGluZ3Jl
c3Mgd291bGQgYmUgbm90aWZpZWQgb2YgcGF0aCBlcnJvcnMgZm9yIGFuIExTUCBmb3Igd2hpY2gg
aXQgZG9lc24ndCBoYXZlIHBhdGggc3RhdGUuLi4NCg0KRG8geW91IHJlYWxseSB3YW50IHRvIGdv
IGRvd24gdGhlIHBhdGggb2YgZG9jdW1lbnQgYWxsIHBvc3NpYmxlIHVzZXMvY29tYmluYXRpb24g
b2Ygb2JqZWN0cyBjYXJyaWVkIGluIFJFVkVSU0VfTFNQIG9iamVjdHM/DQoNCkxvdQ0KDQpPbiA5
LzEzLzIwMTIgOToxNSBBTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkgd3JvdGU6DQo+IFRoYW5r
cyBMb3UgZm9yIHlvdXIgcmVwbHkuDQo+IA0KPiBHb29kIHRvIGtub3cgdGhhdCBOT1RJRlkgbWVz
c2FnZXMgY2FuIGJlIGdlbmVyYXRlZCB3aXRob3V0IE5PVElGWSByZXF1ZXN0IG1lc3NhZ2VzLiBU
aGFua3MgZm9yIHRoaXMgaW5mby4gU28gSSBhZ3JlZSB0aGF0IGVncmVzcyBub2RlIFNIT1VMRCBy
ZWxheSB0aGUgc2lnbmFsaW5nIGVycm9ycyBiYXNlZCBvbiBhc3NvY2lhdGlvbiB0eXBlIG9mICJT
aW5nbGUgU2lkZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMiIGFuZCBwcmVzZW5jZSBv
ZiAiUkVWRVJTRV9MU1AiIG9iamVjdC4NCj4gDQo+IEhhdmluZyBzYWlkIHRoYXQsIGlmIGFuIGlu
Z3Jlc3Mgbm9kZSBzdXBwb3J0cyBSRkMzNDczIGFuZCBtYWtlcyByZXF1ZXN0IGJ5IHNlbmRpbmcg
Tk9USUZZIHJlcXVlc3QgbWVzc2FnZSB0byBhIHRyYW5zaXQgbm9kZSwgYW5kIHRyYW5zaXQgbm9k
ZSBhbHNvIHN1cHBvcnRzIFJGQzM0NzMgYW5kIHRoZSBOT1RJRlkgcmVwbHksIHRoZSByZXZlcnNl
IExTUCBzaWduYWxpbmcgbm90aWZpY2F0aW9uIGZyb20gdGhpcyB0cmFuc2l0IG5vZGUgY2FuIHdv
cmsgYXMgd2VsbCBpbmRlcGVuZGVudCBvZiBlZ3Jlc3MgcmVsYXlpbmcgdGhlIG1lc3NhZ2VzLiBE
byB5b3UgYWdyZWU/IA0KPiANCj4gVGhhbmtzLA0KPiBSYWtlc2gNCj4gDQo+IA0KPiANCj4gLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJn
ZXJAbGFibi5uZXRdDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTIgOTowMiBB
TQ0KPiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNv
bS5jbjsgY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250
cm9sIGluIA0KPiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVk
LWxzcC0wNC50eHQNCj4gDQo+IFJha2VzaCwNCj4gCVRoaXMgc2VlbXMgcmVhbGx5IGNvbXBsaWNh
dGVkLiAgV2h5IGFsbG93IGZvciB0aGUgb3B0aW9uYWwgbm90aWZpY2F0aW9uIGZyb20gdGhlIGVn
cmVzcz8gIFRoZXJlIGlzIHByZWNlZGVudCBmb3IgdXNlIG9mIG5vdGlmeSBtZXNzYWdlcyB3aXRo
b3V0IG5vdGlmeSByZXF1ZXN0cyAoc2VlIFJGQzQ5NzQpLg0KPiANCj4gQWxzbywgYXMgaXQgc3Rh
bmRzIEFzc29jaWF0ZWQgQmlkaXJlY3Rpb25hbCByZWFsbHkgb25seSByZXF1aXJlcyBzdXBwb3J0
IGJ5IHRoZSBlbmQgbm9kZXMuIChJIHRoaW5rIG9mIGl0IGFzIGFsbW9zdCBhbiBhcHBsaWNhdGlv
biBvdmVybGF5IG9uIHRvcCBvZiBub3JtYWwgTFNQIHNpZ25hbGluZy4gIEknZCBldmVuIGNvbnNp
ZGVyIHVzaW5nIHRoZSBSRkM0OTc0IGNhbGwgYXBwcm9hY2ggaWYgaXQgd2Fzbid0IGZvciByZXF1
aXJlbWVudCAxMSBpbiBSRkM2MzczLikgIEkgdGhpbmsgcGxhY2luZyBwcm9jZXNzaW5nIHJlcXVp
cmVtZW50cyBvbiB0cmFuc2l0IG5vZGVzLCBzdWNoIGFzIHNlbmRpbmcgcmV2ZXJzZV9sc3Agbm90
aWZpY2F0aW9ucyBhZGRzIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkgYW5kIHNob3VsZCBiZSBhdm9p
ZGVkIHVubGVzcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS4NCj4gDQo+IExvdSAoYXMgcGFydGljaXBh
bnQpDQo+IA0KPiBPbiA5LzEyLzIwMTIgOTo1NyBQTSwgUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkg
d3JvdGU6DQo+PiBIaSBGZWksDQo+Pg0KPj4gIA0KPj4NCj4+IEkgc2VlIHdoYXQgeW91IGFyZSBz
YXlpbmcuIFJld29yZGluZyB0aGUgdGV4dCB0byByZWZsZWN0IHRoaXMgKG5vdCANCj4+IHN1cmUg
YWJvdXQgobBTSE9VTEShsSB3b3JkIHVzYWdlKToNCj4+DQo+PiAgDQo+Pg0KPj4gV2hlbiBhbiBp
bml0aWF0aW5nIGluZ3Jlc3Mgbm9kZSBpcyBwcm92aXNpb25lZCB3aXRoICJTaW5nbGUgU2lkZWQg
DQo+PiBBc3NvY2lhdGVkIEJpZGlyZWN0aW9uYWwgTFNQcyIgYW5kIHdpc2hlcyB0byBjb250cm9s
IGJvdGggZm9yd2FyZCBhbmQgDQo+PiByZXZlcnNlIExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xT
UCIgb2JqZWN0LCB0aGUgaW5ncmVzcyBub2RlIFNIT1VMRCANCj4+IGtub3cgdGhlIHNpZ25hbGlu
ZyAocGF0aCkgZXJyb3JzIG9uIHRoZSByZXZlcnNlIExTUC4gVHJhbnNpdCBhbmQgDQo+PiBlZ3Jl
c3Mgbm9kZXMgU0hPVUxEIGJlIHJlcXVlc3RlZCB0byBub3RpZnkgdGhlIHNpZ25hbGluZyBlcnJv
ciBvbiB0aGUgDQo+PiByZXZlcnNlIExTUCBieSB1c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UgYW5k
IHByb2NlZHVyZXMgZGVmaW5lZCBpbiBSRkNbMzQ3M10uDQo+Pg0KPj4gIA0KPj4NCj4+ICANCj4+
DQo+PiBUaGFua3MsDQo+Pg0KPj4gUmFrZXNoDQo+Pg0KPj4gIA0KPj4NCj4+ICANCj4+DQo+PiAq
RnJvbToqemhhbmcuZmVpM0B6dGUuY29tLmNuIFttYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNu
XQ0KPj4gKlNlbnQ6KiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA5OjQwIFBNDQo+PiAq
VG86KiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKQ0KPj4gKkNjOiogY2NhbXBAaWV0Zi5vcmc7IExv
dSBCZXJnZXINCj4+ICpTdWJqZWN0OiogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0K
Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQu
dHh0DQo+Pg0KPj4gIA0KPj4NCj4+DQo+PiBIaSBSYWtlc2gsIExvdQ0KPj4NCj4+ICAvPiAgICAg
ICAgICBTcGVha2luZyBhcyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQg
dGhpcw0KPj4gdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhvZCAzIHNlZW1zIHRvIGJl
IG1vc3QgY29uc2lzdGVudCB3aXRoIA0KPj4gdGhlIHVzYWdlIG9mIHRoZSBSRVZFUlNFX0xTUCBP
YmplY3QgaW4gdGhlIHBhdGggbWVzc2FnZS4gIFBlcmhhcHMgDQo+PiBjb25zaWRlciB1c2luZyB0
aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2IGRpcmVjdGlvbiANCj4+
IHRvIGFsbG93IHRoZSBlZ3Jlc3MvdGFpbCB0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hlYWQgd2l0
aCBhcmJpdHJhcnkgDQo+PiBpbmZvcm1hdGlvbi4uLi4vDQo+Pg0KPj4gPGZlaT5XZWxsLCBJIGNh
biBzZWUgb25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRoaXMgcHJvcG9zYWwgaXMgdGhhdCANCj4+
IGl0IGFsbG93cyB0aGUgcG9saWN5IGNvbnRyb2wgaW4gdGhlIGVncmVzcy90YWlsLCB3aGVyZSBh
IGRlY2lzaW9uIGNhbiANCj4+IGJlIG1hZGUgdGhhdCB3aGV0aGVyIHRoZSBzaWduYWxpbmcgZXJy
b3Igc2hvdWxkIGJlIHBhc3NlZCB0byB0aGUgDQo+PiBpbmdyZXNzL2hlYWQuIEJ1dCBpdCBjaGFu
Z2VzIHRoZSBydWxlcyBkZWZpbmVkIGluIFJGQzM0NzMuLi4uDQo+Pg0KPj4gICAgICBUaGUgb3Ro
ZXIgcHJvcG9zYWwga2VlcHMgYWxpZ25tZW50IHdpdGggUkZDMzQ3MywgYW5kIEkgcHJlZmVyIGl0
IA0KPj4gaWYgdGhlIExTUCBjb250cm9sIGlzIHRvdGFsbHkgaW4gaGFuZCBvZiB0aGUgaW5ncmVz
cy9oZWFkIChpbiBvdGhlciANCj4+IHdvcmRzLCB0aGVyZSBpcyBubyBtb3JlIGluZm9ybWF0aW9u
IG5lZWRzIHRoZSBlZ3Jlcy90YWlsIHRvIGluZm9ybSANCj4+IHRoZSBpbmdyZXNzL2hlYWQpLg0K
Pj4NCj4+ICoiUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkiIDxyZ2FuZGhpQGNpc2NvLmNvbQ0KPj4g
PG1haWx0bzpyZ2FuZGhpQGNpc2NvLmNvbT4+Kg0KPj4NCj4+IDIwMTItMDktMTMgMDg6NTMNCj4+
DQo+PiAJDQo+Pg0KPj4gytW8/sjLDQo+Pg0KPj4gCQ0KPj4NCj4+ICJ6aGFuZy5mZWkzQHp0ZS5j
b20uY24gPG1haWx0bzp6aGFuZy5mZWkzQHp0ZS5jb20uY24+Ig0KPj4gPHpoYW5nLmZlaTNAenRl
LmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4+DQo+Pg0KPj4gs63LzQ0KPj4N
Cj4+IAkNCj4+DQo+PiAiY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4iIDxj
Y2FtcEBpZXRmLm9yZyANCj4+IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+PiwgTG91IEJlcmdlciA8
bGJlcmdlckBsYWJuLm5ldCANCj4+IDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQo+Pg0KPj4g
1vfM4g0KPj4NCj4+IAkNCj4+DQo+PiBSRTogUXVlc3Rpb24gb24gTFNQIGNvbnRyb2wgaW4NCj4+
IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFzc29jaWF0ZWQtbHNwLTA0LnR4
dA0KPj4NCj4+ICANCj4+DQo+PiAJDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gSGkgRmVpLA0KPj4gIA0K
Pj4gUGxlYXNlIHNlZSBpbmxpbmUuLjxSRz4uLg0KPj4gIA0KPj4gKkZyb206KnpoYW5nLmZlaTNA
enRlLmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj4gDQo+PiBbbWFpbHRvOnpo
YW5nLmZlaTNAenRlLmNvbS5jbl0gDQo+PiA8bWFpbHRvOlttYWlsdG86emhhbmcuZmVpM0B6dGUu
Y29tLmNuXT4NCj4+ICoNCj4+IFNlbnQ6KiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiA4
OjQyIFBNKg0KPj4gVG86KiBSYWtlc2ggR2FuZGhpIChyZ2FuZGhpKSoNCj4+IENjOiogY2NhbXBA
aWV0Zi5vcmcgPG1haWx0bzpjY2FtcEBpZXRmLm9yZz47IExvdSBCZXJnZXIqDQo+PiBTdWJqZWN0
OiogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0KPj4gZHJhZnQtaWV0Zi1jY2FtcC1t
cGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQudHh0DQo+PiAgDQo+Pg0KPj4gSGkg
UmFrZXNoDQo+Pg0KPj4gSW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBub3RpZmljYXRpb24gcmVxdWVz
dCwgZWdyZXNzIG5vZGUgU0hPVUxEIHJlbGF5IA0KPj4gdGhlIHJlY2VpdmVkIHNpZ25hbGluZyBl
cnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mgbm9kZSANCj4+IHVzaW5nIHRo
ZSBOT1RJRlkgbWVzc2FnZS4iDQo+Pg0KPj4gPGZlaT4gIk5vdGUgdGhhdCBhIE5vdGlmeSBtZXNz
YWdlIE1VU1QgTk9UIGJlIGdlbmVyYXRlZCB1bmxlc3MgYW4gDQo+PiBhcHByb3ByaWF0ZSBOb3Rp
ZnkgUmVxdWVzdCBvYmplY3QgaGFzIGJlZW4gcmVjZWl2ZWQuIg0KPj4NCj4+ICAgICAgIElmIG15
IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgeW91ciBwcm9wb3NlZCByZWxheSBtZWNoYW5pc20g
DQo+PiBkb2VzIG5vdCBkZXBlbmQgb24gdGhlIGV4aXN0aW5nIG9mIHRoZSBOb3RpZnkgUmVxdWVz
dCBvYmplY3QsIHdoaWNoIA0KPj4gbWF5IGNvbmZsaWN0IHdpdGggdGhlDQo+PiAgICAgICBkZXNj
cmlwaXRvbnMgaW4gUkZDMzQ3My4NCj4+DQo+PiAgICAgICBEbyB5b3Ugd2FudCB0byBjaGFuZ2Ug
dGhpcyBvciBkbyBJIGhhdmUgc29tZSBtaXN1bmRlcnN0YW5kaW5nPyAgDQo+Pg0KPj4gPFJHPiBZ
ZXMgeW91ciB1bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QuICBOT1RJRlkgbWVzc2FnZSBpbiB0aGlz
IGNhc2UgDQo+PiBpcyBnZW5lcmF0ZWQgYmFzZWQgb24gdGhlIHByZXNlbmNlIG9mIHRoZSChsFJF
VkVSU0VfTFNQobEgb2JqZWN0IGFuZCANCj4+IGFzc29jaWF0aW9uIHR5cGUgobBTaW5nbGUgU2lk
ZWQgQXNzb2NpYXRlZCBCaWRpcmVjdGlvbmFsIExTUHMuICBJIA0KPj4gdW5kZXJzdGFuZCB3aGF0
IHlvdSBhcmUgc2F5aW5nIHRob3VnaC4gRllJLCAgTG91IGhhZCBmb2xsb3dpbmcgDQo+PiB0aG91
Z2h0cyBvbiB0aGlzLiBEbyB5b3UgdGhpbmsgdGhpcyBzaW1wbGlmaWVzIHRoaW5ncyA/DQo+PiAv
PiAgICAgICAgICBTcGVha2luZyBhcyBXRyBwYXJ0aWNpcGFudCwgSSBoYXZlbid0IHRob3VnaHQg
YWJvdXQgdGhpcyB0b28NCj4+IG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhvZCAzIHNlZW1z
IHRvIGJlIG1vc3QgY29uc2lzdGVudCB3aXRoIHRoZSANCj4+IHVzYWdlIG9mIHRoZSBSRVZFUlNF
X0xTUCBPYmplY3QgaW4gdGhlIHBhdGggbWVzc2FnZS4gIFBlcmhhcHMgDQo+PiBjb25zaWRlciB1
c2luZyB0aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2IGRpcmVjdGlv
biANCj4+IHRvIGFsbG93IHRoZSBlZ3Jlc3MvdGFpbCB0byBwcm92aWRlIHRoZSBpbmdyZXNzL2hl
YWQgd2l0aCBhcmJpdHJhcnkgaW5mb3JtYXRpb24uLi4uDQo+PiAvDQo+PiBUaGFua3MsDQo+PiBS
YWtlc2gNCj4+ICANCj4+ICANCj4+DQo+PiBSZWdhcmRzDQo+Pg0KPj4gRmVpDQo+Pg0KPj4gKiJS
YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSIgPCoqcmdhbmRoaUBjaXNjby5jb20qDQo+PiA8bWFpbHRv
OnJnYW5kaGlAY2lzY28uY29tPio+Kg0KPj4NCj4+IDIwMTItMDktMTMgMDE6MjMNCj4+DQo+PiAJ
DQo+Pg0KPj4gIA0KPj4NCj4+IMrVvP7Iyw0KPj4NCj4+IAkNCj4+DQo+PiBMb3UgQmVyZ2VyIDxs
YmVyZ2VyQGxhYm4ubmV0IDxtYWlsdG86bGJlcmdlckBsYWJuLm5ldD4+DQo+Pg0KPj4gs63LzQ0K
Pj4NCj4+IAkNCj4+DQo+PiAiemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86emhhbmcuZmVp
M0B6dGUuY29tLmNuPiINCj4+IDx6aGFuZy5mZWkzQHp0ZS5jb20uY24gPG1haWx0bzp6aGFuZy5m
ZWkzQHp0ZS5jb20uY24+PiwgDQo+PiAiY2NhbXBAaWV0Zi5vcmcgPG1haWx0bzpjY2FtcEBpZXRm
Lm9yZz4iIDxjY2FtcEBpZXRmLm9yZyANCj4+IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Pg0KPj4N
Cj4+INb3zOINCj4+DQo+PiAJDQo+Pg0KPj4gUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGlu
DQo+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0w
NC50eHQNCj4+DQo+Pg0KPj4gIA0KPj4NCj4+ICANCj4+DQo+PiAJDQo+Pg0KPj4NCj4+DQo+Pg0K
Pj4NCj4+IEhpIExvdSwgRmVpLCBXRywNCj4+DQo+PiBUaGFua3MgZm9yIHlvdXIgcmVwbGllcy4g
TWF5IEkgcHJvcG9zZSBmb2xsb3dpbmcgdGV4dCB0byBjb3ZlciB0aGlzIA0KPj4gY2FzZT8gVGhp
cyBhbGxvd3MgdGhlIG1pZC1wb2ludCBzb2x1dGlvbiB3aGljaCBoYXMgYWR2YW50YWdlcyBidXQg
DQo+PiBnaXZlbiB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IGNhbiBiZSBvcHRpb25hbC4NCj4+
DQo+PiBQbGVhc2UgYWR2aXNlLg0KPj4NCj4+ICJXaGVuIGFuIGluaXRpYXRpbmcgaW5ncmVzcyBu
b2RlIGlzIHByb3Zpc2lvbmVkIHdpdGggIlNpbmdsZSBTaWRlZCANCj4+IEFzc29jaWF0ZWQgQmlk
aXJlY3Rpb25hbCBMU1BzIiBhbmQgd2lzaGVzIHRvIGNvbnRyb2wgYm90aCBmb3J3YXJkIGFuZCAN
Cj4+IHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCIgb2JqZWN0LCB0aGUgaW5n
cmVzcyBub2RlIFNIT1VMRCANCj4+IGtub3cgdGhlIHNpZ25hbGluZyAocGF0aCkgZXJyb3JzIG9u
IHRoZSByZXZlcnNlIExTUC4gIEEgdHJhbnNpdCBub2RlIA0KPj4gTUFZIGJlIHJlcXVlc3RlZCB0
byBub3RpZnkgdGhlIHNpZ25hbGluZyBlcnJvciBvbiB0aGUgcmV2ZXJzZSBMU1AgYnkgDQo+PiB1
c2luZyB0aGUgTk9USUZZIG1lc3NhZ2UgYW5kIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBSRkNbMzQ3
M10uIEluIHRoZSANCj4+IGFic2VuY2Ugb2Ygc3VjaCBub3RpZmljYXRpb24gcmVxdWVzdCwgZWdy
ZXNzIG5vZGUgU0hPVUxEIHJlbGF5IHRoZSANCj4+IHJlY2VpdmVkIHNpZ25hbGluZyBlcnJvciBv
biB0aGUgcmV2ZXJzZSBMU1AgdG8gdGhlIGluZ3Jlc3Mgbm9kZSB1c2luZyANCj4+IHRoZSBOT1RJ
RlkgbWVzc2FnZS4iDQo+Pg0KPj4gVGhhbmtzLA0KPj4gUmFrZXNoDQo+Pg0KPj4NCj4+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdl
ckBsYWJuLm5ldF0gDQo+PiA8bWFpbHRvOlttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0+DQo+PiBT
ZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxMiAxMjoxNCBQTQ0KPj4gVG86IFJha2Vz
aCBHYW5kaGkgKHJnYW5kaGkpDQo+PiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNuIDxtYWlsdG86
emhhbmcuZmVpM0B6dGUuY29tLmNuPjsgDQo+PiBjY2FtcEBpZXRmLm9yZyA8bWFpbHRvOmNjYW1w
QGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExTUCBjb250cm9sIGluIA0K
Pj4gZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLXJzdnB0ZS1leHQtYXNzb2NpYXRlZC1sc3AtMDQu
dHh0DQo+Pg0KPj4gUmFrZXNoLA0KPj4NCj4+DQo+PiBPbiA5LzEyLzIwMTIgMTE6NTIgQU0sIFJh
a2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4+IFRoYW5rcyBMb3UuDQo+Pj4NCj4+PiBB
cmUgd2Ugb2sgaW4gZ2VuZXJhbCB0byB1c2UgTk9USUZZIG1lc3NhZ2UgW1JGQzM0NzNdIGZvciB0
aGlzPw0KPj4NCj4+IEknbSBub3Qgc3BlYWtpbmcgZm9yIHRoZSBXRywgYXMgbm90ZWQgbXkgY29t
bWVudHMgd2VyZSBhcyBhIHBhcnRpY2lwYW50Lg0KPj4gSU1PIHlvdSdsbCBuZWVkIHRvIGZ1bGx5
IGRvY3VtZW50IHRoZSBwcm9wb3NhbCwgcGVyaGFwcyBkaXNjdXNzIA0KPj4gYWx0ZXJuYXRpdmVz
IGNvbnNpZGVyZWQsIGFuZCB0aGVuIGFzayB0aGUgV0cgZm9yIGNvbmN1cnJlbmNlLg0KPj4NCj4+
Pg0KPj4+IE9uZSBhZHZhbnRhZ2Ugd2l0aCB0aGUgbWlkLXBvaW50IHNlbmRpbmcgbm90aWZpY2F0
aW9uIGZvciB0aGUgDQo+Pj4gcmV2ZXJzZSBMU1AgaXMgdGhhdCBzaWduYWxpbmcgZXJyb3IgcHJv
cGFnYXRpb24gdGltZQ0KPj4+IChtaWQtPmVncmVzcy1ub2RlLT5pbmdyZXNzLW5vZGUpIGlzIHNp
Z25pZmljYW50bHkgcmVkdWNlZCAodG8NCj4+PiBtaWQtPmluZ3Jlc3Mtbm9kZSkgd2hpY2ggbWF5
IGJlIHByZWZlcnJlZCBpbiBzb21lIGNhc2VzLg0KPj4NCj4+ID5Gcm9tIG15IChwZXJzb25hbCkg
cGVyc3BlY3RpdmUsIHRoZSBhZGRlZCBjb21wbGV4aXR5IGlzbid0IHdvcnRoIHRoZSBlZmZvcnQu
ICBPZiBjb3Vyc2UsIGEgZGV0YWlsZWQgcHJvcG9zYWwgbWF5IHNob3cgb3RoZXJ3aXNlLg0KPj4N
Cj4+IExvdQ0KPj4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBSYWtlc2gNCj4+Pg0KPj4+DQo+Pj4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86
bGJlcmdlckBsYWJuLm5ldF0gDQo+Pj4gPG1haWx0bzpbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRd
Pg0KPj4+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEyLCAyMDEyIDk6MTUgQU0NCj4+PiBU
bzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+PiBDYzogemhhbmcuZmVpM0B6dGUuY29tLmNu
IDxtYWlsdG86emhhbmcuZmVpM0B6dGUuY29tLmNuPjsgDQo+Pj4gY2NhbXBAaWV0Zi5vcmcNCj4+
IDxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDogUmU6IFF1ZXN0aW9uIG9uIExT
UCBjb250cm9sIGluIA0KPj4+IGRyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1yc3ZwdGUtZXh0LWFz
c29jaWF0ZWQtbHNwLTA0LnR4dA0KPj4+DQo+Pj4gUmFrZXNoLA0KPj4+ICAgICAgICAgICAgICAg
ICAgU3BlYWtpbmcgYXMgV0cgcGFydGljaXBhbnQsIEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IA0K
Pj4+IHRoaXMgdG9vIG11Y2ggc28gbWF5IGJlIG9mZiwgYnV0IG1ldGhvZCAzIHNlZW1zIHRvIGJl
IG1vc3QgDQo+Pj4gY29uc2lzdGVudCB3aXRoIHRoZSB1c2FnZSBvZiB0aGUgUkVWRVJTRV9MU1Ag
T2JqZWN0IGluIHRoZSBwYXRoIG1lc3NhZ2UuDQo+Pj4gUGVyaGFwcyBjb25zaWRlciB1c2luZyB0
aGUgUkVWRVJTRV9MU1AgT2JqZWN0IGluIHRoZSB1cHN0cmVhbS9SZXN2IA0KPj4+IGRpcmVjdGlv
biB0byBhbGxvdyB0aGUgZWdyZXNzL3RhaWwgdG8gcHJvdmlkZSB0aGUNCj4+IGluZ3Jlc3MvaGVh
ZCB3aXRoIGFyYml0cmFyeSBpbmZvcm1hdGlvbi4uLi4NCj4+Pg0KPj4+IExvdQ0KPj4+DQo+Pj4g
T24gOS8xMS8yMDEyIDk6MjIgQU0sIFJha2VzaCBHYW5kaGkgKHJnYW5kaGkpIHdyb3RlOg0KPj4+
PiBIaSBXRywNCj4+Pj4NCj4+Pj4gQW55IHRob3VnaHRzIG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9z
YWw/DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gUmFrZXNoDQo+Pj4+DQo+Pj4+DQo+Pj4+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFJha2VzaCBHYW5kaGkgKHJnYW5k
aGkpDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxOjM2IFBNDQo+Pj4+
IFRvOiAnTG91IEJlcmdlcicNCj4+Pj4gQ2M6IHpoYW5nLmZlaTNAenRlLmNvbS5jbiA8bWFpbHRv
OnpoYW5nLmZlaTNAenRlLmNvbS5jbj47IA0KPj4+PiBjY2FtcEBpZXRmLm9yZw0KPj4gPG1haWx0
bzpjY2FtcEBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUkU6IFF1ZXN0aW9uIG9uIExTUCBjb250
cm9sIGluIA0KPj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2cHRlLWV4dC1hc3NvY2lh
dGVkLWxzcC0wNC50eHQNCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhhbmtzIExvdSBmb3IgeW91ciByZXBs
eS4NCj4+Pj4NCj4+Pj4gUkZDIDM0NzMgZGVmaW5lcyBwcm9jZWR1cmVzIGZvciBOT1RJRlkgcmVx
dWVzdCBhbmQgcmVwbHkuIFdlIGNvdWxkIHVzZSB0aGlzIGZvciByZXZlcnNlIExTUCBzaWduYWxp
bmcgZXJyb3Igbm90aWZpY2F0aW9uIHRvIHRoZSBpbml0aWF0aW5nIGluZ3Jlc3Mgbm9kZS4NCj4+
Pj4NCj4+Pj4gPE5vdGlmeSBtZXNzYWdlPiA6Oj0gPENvbW1vbiBIZWFkZXI+IFs8SU5URUdSSVRZ
Pl0gWyBbPE1FU1NBR0VfSURfQUNLPiB8IDxNRVNTQUdFX0lEX05BQ0s+XSAuLi4gXQ0KPj4+PiA8
RVJST1JfU1BFQz4gICANCj4+Pj4gPG5vdGlmeSBzZXNzaW9uIGxpc3QgOjo9IDx1cHN0cmVhbSBz
ZXNzaW9uPiA8ZG93bnN0cmVhbSBzZXNzaW9uPiAgPg0KPj4+Pg0KPj4+PiBUaGVyZSBhcmUgbXVs
dGlwbGUgd2F5cyB3ZSBjYW4gdXNlIHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4+Pj4NCj4+Pj4gTWV0
aG9kIDEgLSBNaWQtcG9pbnQgYXdhcmUgd2l0aCBQYXRoIG1lc3NhZ2UgcmVxdWVzdDoNCj4+Pj4g
V2hlbiBhbiBlZ3Jlc3Mgbm9kZSByZWNlaXZlcyBhIFBhdGggbWVzc2FnZSB3aXRoIFJFVkVSU0Vf
TFNQIG9iamVjdCwgdGhlIG5vZGUgd2lsbCBpbnNlcnQgTk9USUZZX1JFUSBtZXNzYWdlIGluIHRo
ZSByZXZlcnNlIExTUCBwYXRoIG1lc3NhZ2Ugd2l0aCBub2RlIElEIG9mIHRoZSBpbml0aWF0aW5n
IGluZ3Jlc3Mgbm9kZS4gQSBtaWQtcG9pbnQgbm9kZSB3aWxsIHNlbmQgIGEgY29weSBvZiB0aGUg
c2lnbmFsaW5nIGVycm9yIHRvIHRoZSBpbml0aWF0aW5nIG5vZGUgdXNpbmcgdGhlIE5PVElGWSBt
ZXNzYWdlLg0KPj4+Pg0KPj4+PiBJUHY0IE5vdGlmeSBSZXF1ZXN0IE9iamVjdA0KPj4+PiAgICBJ
UHY0IE5vdGlmeSBOb2RlIEFkZHJlc3M6IDMyIGJpdHMNCj4+Pj4gICAgICAgVGhlIElQIGFkZHJl
c3Mgb2YgdGhlIG5vZGUgdGhhdCBzaG91bGQgYmUgbm90aWZpZWQgd2hlbiBnZW5lcmF0aW5nIGFu
IGVycm9yIG1lc3NhZ2UuDQo+Pj4+DQo+Pj4+IE1ldGhvZCAyIC0gTWlkLXBvaW50IGF3YXJlIHdp
dGggUmVzdiBtZXNzYWdlIHJlcXVlc3Q6DQo+Pj4+IFdoZW4gYW4gaW5pdGlhdGluZyBpbmdyZXNz
IG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2UgZm9yIGEgcmV2ZXJzZSBMU1AsIHRoZSBub2Rl
IHdpbGwgaW5zZXJ0IE5PVElGWV9SRVEgbWVzc2FnZSBpbiB0aGUgcmV2ZXJzZSBMU1AgUmVzdiBt
ZXNzYWdlIHdpdGggaXRzIG93biBub2RlIElELiBBIG1pZC1wb2ludCBub2RlIHdpbGwgc2VuZCBh
IGNvcHkgb2YgdGhlIHNpZ25hbGluZyBlcnJvciB0byB0aGUgaW5pdGlhdGluZyBub2RlIHVzaW5n
IHRoZSBOT1RJRlkgbWVzc2FnZS4NCj4+Pj4NCj4+Pj4gTWV0aG9kIDMgLSBUYWlsLWVuZCByZWxh
eWluZyA6DQo+Pj4+IFdoZW4gYW4gZWdyZXNzIG5vZGUgcmVjZWl2ZXMgYSBQYXRoIG1lc3NhZ2Ug
d2l0aCBSRVZFUlNFX0xTUCANCj4+Pj4gb2JqZWN0LCB0aGUgbm9kZSB3aWxsIHJlbGF5IHRoZSBy
ZWNlaXZlZCBzaWduYWxpbmcgZXJyb3IgbWVzc2FnZSBvbiANCj4+Pj4gdGhlIHJldmVyc2UgTFNQ
IHRvIHRoZSBpbml0aWFsaXppbmcgaW5ncmVzcyBub2RlLiBUaGUgZWdyZXNzIG5vZGUgDQo+Pj4+
IGNvcGllcyB0aGUgcmVjZWl2ZWQgIkVSUk9SX1NQRUMiIG9iamVjdCBpbnRvIGEgTk9USUZZIFtS
RkMzNDczLCANCj4+Pj4gc2VjdGlvbiA0LjNdIG1lc3NhZ2UgYW5kIHNpZ25hbHMgaXQgdG8gdGhl
IGluZ3Jlc3Mgbm9kZS4gSW4gdGhpcyANCj4+Pj4gY2FzZSwNCj4+IE5PVElGWV9SRVEgbWVzc2Fn
ZSBpcyBub3QgcmVxdWlyZWQuDQo+Pj4+DQo+Pj4+IFBsZWFzZSBhZHZpc2UgeW91ciB0aG91Z2h0
cy4NCj4+Pj4NCj4+Pj4gVGhhbmtzLA0KPj4+PiBSYWtlc2gNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+
Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogTG91IEJlcmdlciBbbWFp
bHRvOmxiZXJnZXJAbGFibi5uZXRdIA0KPj4+PiA8bWFpbHRvOlttYWlsdG86bGJlcmdlckBsYWJu
Lm5ldF0+DQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNCwgMjAxMiAxMTozNSBBTQ0K
Pj4+PiBUbzogUmFrZXNoIEdhbmRoaSAocmdhbmRoaSkNCj4+Pj4gQ2M6IHpoYW5nLmZlaTNAenRl
LmNvbS5jbiA8bWFpbHRvOnpoYW5nLmZlaTNAenRlLmNvbS5jbj47IA0KPj4+PiBjY2FtcEBpZXRm
Lm9yZw0KPj4gPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFF1ZXN0
aW9uIG9uIExTUCBjb250cm9sIGluIA0KPj4+PiBkcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtcnN2
cHRlLWV4dC1hc3NvY2lhdGVkLWxzcC0wNC50eHQNCj4+Pj4NCj4+Pj4gQXMgSSByZWFkIHRoZSBj
dXJyZW50IHJldiwgbm8gc3VjaCBub3RpZmljYXRpb24gbWVjaGFuaXNtIGlzIHNwZWNpZmllZC4N
Cj4+Pj4gIExvb2tzIGxpa2UgeW91IGdldCB0byBwcm9wb3NlIG9uZSENCj4+Pj4NCj4+Pj4gTG91
IChhcyBXRyBwYXJ0aWNpcGFudCkuDQo+Pj4+DQo+Pj4+IE9uIDgvMzEvMjAxMiA5OjQ5IEFNLCBS
YWtlc2ggR2FuZGhpIChyZ2FuZGhpKSB3cm90ZToNCj4+Pj4+IEhpIExvdSwgRmVpLA0KPj4+Pj4N
Cj4+Pj4+IFdoZW4gYW4gKG9yaWdpbmF0aW5nKSBpbmdyZXNzIG5vZGUgaXMgcHJvdmlzaW9uZWQg
d2l0aCAiNSAoVEJEKSANCj4+Pj4+IFNpbmdsZSBTaWRlZCBBc3NvY2lhdGVkIEJpZGlyZWN0aW9u
YWwgTFNQcyAgKEEpIiBhbmQgd2lzaGVzIHRvIA0KPj4+Pj4gY29udHJvbCBib3RoIGZvcndhcmQg
YW5kIHJldmVyc2UgIExTUHMgYnkgYWRkaW5nICJSRVZFUlNFX0xTUCINCj4+Pj4+IG9iamVjdCwg
SSB3b3VsZCB0aGluayB0aGF0IHRoZSBpbmdyZXNzIG5vZGUgbmVlZHMgdG8ga25vdyBhYm91dCAN
Cj4+Pj4+IHRoZSBzaWduYWxpbmcgKHBhdGgpIGVycm9ycyAoc3VjaCBhcyBzb2Z0IHByZWVtcHRp
b24gb3IgYWRtaXNzaW9uDQo+PiBmYWlsdXJlKSBvbiB0aGUgcmV2ZXJzZSBMU1AuICBJcyB0aGVy
ZSBhbnkgdGV4dCBzb21ld2hlcmUgaW4gYW4gDQo+PiBSRkMvZHJhZnQgdGhhdCBkZXNjcmliZXMg
aG93IGEgbWlkLXBvaW50IG5vZGUgY2FuIHNlbmQgdGhlIHNpZ25hbGluZw0KPj4gKHBhdGgpIGVy
cm9yIHRvIHRoZSBvcmlnaW5hdGluZyBpbmdyZXNzIG5vZGUgZm9yIHRoZSByZXZlcnNlIExTUD8g
SXMgDQo+PiB0aGVyZSBhbiBhc3N1bXB0aW9uIHRvIHVzZSBSU1ZQX05PVElGWSBtZXNzYWdlPyBT
b3JyeSBpZiBJIGhhZCBtaXNzZWQgDQo+PiBhbnkgcHJldmlvdXMgZGlzY3Vzc2lvbiBvbiB0aGlz
IHRvcGljLg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywNCj4+Pj4+IFJha2VzaA0KPj4+Pj4NCj4+Pj4+
DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+Pg0K
Pj4+DQo+Pj4NCj4+DQo=

From lberger@labn.net  Thu Sep 13 12:32:12 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 4F29421F852D for ; Thu, 13 Sep 2012 12:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.768
X-Spam-Level: 
X-Spam-Status: No, score=-98.768 tagged_above=-999 required=5 tests=[AWL=-1.057, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PUJJKmUQyoH for ; Thu, 13 Sep 2012 12:32:10 -0700 (PDT)
Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id B4B2E21F8501 for ; Thu, 13 Sep 2012 12:32:10 -0700 (PDT)
Received: (qmail 16733 invoked by uid 0); 13 Sep 2012 19:32:10 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 13 Sep 2012 19:32: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=H/mLJfz1eq2t0lfYw38NHFM1sg1IZtXIbR+uMLDP+pc=;  b=V1anjUKHGiEG8IHNDnhz+hkhUTeEobV9h2yMxbveg/lCgJT02Me1wiDnb8GTusHs4niVg80AFcmh9j5Va38XgM6g2X5gV+h2DsyaUdxoWs1KmTJGFgbg3KPLSPxKP4wY;
Received: from box313.bluehost.com ([69.89.31.113]:39312 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TCF8z-0007lW-Vr; Thu, 13 Sep 2012 13:32:10 -0600
Message-ID: <505234B6.8080203@labn.net>
Date: Thu, 13 Sep 2012 15:32:06 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Rakesh Gandhi (rgandhi)" 
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
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] Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.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, 13 Sep 2012 19:32:12 -0000

My suggestion would be to leave this language out for now and include it
once it's fully formed/edited and discussed.

Lou

On 9/13/2012 3:20 PM, Rakesh Gandhi (rgandhi) wrote:
> Hi Lou, WG,
> 
> We like to post the revised draft and might be an idea to include following text. Can you please review and advise? 
> 
> "When an initiating ingress node is provisioned with "Single Sided  Associated Bidirectional LSPs" and wishes to control both forward and  reverse LSPs by adding REVERSE_LSP object, the initiating ingress node SHOULD  know the signaling (path) errors on the reverse LSP.  An egress node receiving Association object with association type "Single Sided  Associated Bidirectional LSPs" and REVERSE_LSP object SHOULD use the NOTIFY message and procedures defined in RFC[3473] for relaying  signaling error on the reverse LSP to the initiating ingress node."
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) 
> Sent: Thursday, September 13, 2012 9:51 AM
> To: 'Lou Berger'
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: RE: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> Hi Lou,
> 
> The NOTIFY request and reply procedures are defined in RFC3473 and can be used by any node who supports this RFC and this draft does not add/remove/modify any behavior/requirement in that regard. 
> 
> I didn't mean to include the NOTIFY request object in the REVERSE_LSP objects either.
> 
> Are we ok to add following text? 
> 
>  "When an initiating ingress node is provisioned with "Single Sided  Associated Bidirectional LSPs" and wishes to control both forward and  reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD  know the signaling (path) errors on the reverse LSP.  
>  An egress node MAY use NOTIFY message and procedures defined in RFC[3473] for relaying  signaling error on the reverse LSP to the ingress node."
> 
> 
> Thanks,
> Rakesh
> 
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Thursday, September 13, 2012 9:33 AM
> To: Rakesh Gandhi (rgandhi)
> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
> Subject: Re: Question on LSP control in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
> 
> If one wanted to be cute, an ingress could include a NOTIFY_REQUEST containing the ingress' address in the REVERSE_LSP object as well as the Resv messages of incoming associated bidirectional LSPs.  Of course, this means that the ingress would be notified of path errors for an LSP for which it doesn't have path state...
> 
> Do you really want to go down the path of document all possible uses/combination of objects carried in REVERSE_LSP objects?
> 
> Lou
> 
> On 9/13/2012 9:15 AM, Rakesh Gandhi (rgandhi) wrote:
>> Thanks Lou for your reply.
>>
>> Good to know that NOTIFY messages can be generated without NOTIFY request messages. Thanks for this info. So I agree that egress node SHOULD relay the signaling errors based on association type of "Single Sided Associated Bidirectional LSPs" and presence of "REVERSE_LSP" object.
>>
>> Having said that, if an ingress node supports RFC3473 and makes request by sending NOTIFY request message to a transit node, and transit node also supports RFC3473 and the NOTIFY reply, the reverse LSP signaling notification from this transit node can work as well independent of egress relaying the messages. Do you agree? 
>>
>> Thanks,
>> Rakesh
>>
>>
>>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Thursday, September 13, 2012 9:02 AM
>> To: Rakesh Gandhi (rgandhi)
>> Cc: zhang.fei3@zte.com.cn; ccamp@ietf.org
>> Subject: Re: Question on LSP control in 
>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>
>> Rakesh,
>> 	This seems really complicated.  Why allow for the optional notification from the egress?  There is precedent for use of notify messages without notify requests (see RFC4974).
>>
>> Also, as it stands Associated Bidirectional really only requires support by the end nodes. (I think of it as almost an application overlay on top of normal LSP signaling.  I'd even consider using the RFC4974 call approach if it wasn't for requirement 11 in RFC6373.)  I think placing processing requirements on transit nodes, such as sending reverse_lsp notifications adds unnecessary complexity and should be avoided unless absolutely necessary.
>>
>> Lou (as participant)
>>
>> On 9/12/2012 9:57 PM, Rakesh Gandhi (rgandhi) wrote:
>>> Hi Fei,
>>>
>>>  
>>>
>>> I see what you are saying. Rewording the text to reflect this (not 
>>> sure about ¡°SHOULD¡± word usage):
>>>
>>>  
>>>
>>> When an initiating ingress node is provisioned with "Single Sided 
>>> Associated Bidirectional LSPs" and wishes to control both forward and 
>>> reverse LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD 
>>> know the signaling (path) errors on the reverse LSP. Transit and 
>>> egress nodes SHOULD be requested to notify the signaling error on the 
>>> reverse LSP by using the NOTIFY message and procedures defined in RFC[3473].
>>>
>>>  
>>>
>>>  
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>  
>>>
>>>  
>>>
>>> *From:*zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn]
>>> *Sent:* Wednesday, September 12, 2012 9:40 PM
>>> *To:* Rakesh Gandhi (rgandhi)
>>> *Cc:* ccamp@ietf.org; Lou Berger
>>> *Subject:* RE: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>  
>>>
>>>
>>> Hi Rakesh, Lou
>>>
>>>  />          Speaking as WG participant, I haven't thought about this
>>> too much so may be off, but method 3 seems to be most consistent with 
>>> the usage of the REVERSE_LSP Object in the path message.  Perhaps 
>>> consider using the REVERSE_LSP Object in the upstream/Resv direction 
>>> to allow the egress/tail to provide the ingress/head with arbitrary 
>>> information..../
>>>
>>> Well, I can see one of the advantages of this proposal is that 
>>> it allows the policy control in the egress/tail, where a decision can 
>>> be made that whether the signaling error should be passed to the 
>>> ingress/head. But it changes the rules defined in RFC3473....
>>>
>>>      The other proposal keeps alignment with RFC3473, and I prefer it 
>>> if the LSP control is totally in hand of the ingress/head (in other 
>>> words, there is no more information needs the egres/tail to inform 
>>> the ingress/head).
>>>
>>> *"Rakesh Gandhi (rgandhi)" >> >*
>>>
>>> 2012-09-13 08:53
>>>
>>> 	
>>>
>>> ÊÕ¼þÈË
>>>
>>> 	
>>>
>>> "zhang.fei3@zte.com.cn "
>>> >
>>>
>>> ³­ËÍ
>>>
>>> 	
>>>
>>> "ccamp@ietf.org " >> >, Lou Berger >> >
>>>
>>> Ö÷Ìâ
>>>
>>> 	
>>>
>>> RE: Question on LSP control in
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>  
>>>
>>> 	
>>>
>>>
>>>
>>>
>>> Hi Fei,
>>>  
>>> Please see inline....
>>>  
>>> *From:*zhang.fei3@zte.com.cn  
>>> [mailto:zhang.fei3@zte.com.cn] 
>>> 
>>> *
>>> Sent:* Wednesday, September 12, 2012 8:42 PM*
>>> To:* Rakesh Gandhi (rgandhi)*
>>> Cc:* ccamp@ietf.org ; Lou Berger*
>>> Subject:* RE: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>  
>>>
>>> Hi Rakesh
>>>
>>> In the absence of such notification request, egress node SHOULD relay 
>>> the received signaling error on the reverse LSP to the ingress node 
>>> using the NOTIFY message."
>>>
>>>  "Note that a Notify message MUST NOT be generated unless an 
>>> appropriate Notify Request object has been received."
>>>
>>>       If my understanding is correct, your proposed relay mechanism 
>>> does not depend on the existing of the Notify Request object, which 
>>> may conflict with the
>>>       descripitons in RFC3473.
>>>
>>>       Do you want to change this or do I have some misunderstanding?  
>>>
>>>  Yes your understanding is correct.  NOTIFY message in this case 
>>> is generated based on the presence of the ¡°REVERSE_LSP¡± object and 
>>> association type ¡°Single Sided Associated Bidirectional LSPs.  I 
>>> understand what you are saying though. FYI,  Lou had following 
>>> thoughts on this. Do you think this simplifies things ?
>>> />          Speaking as WG participant, I haven't thought about this too
>>> much so may be off, but method 3 seems to be most consistent with the 
>>> usage of the REVERSE_LSP Object in the path message.  Perhaps 
>>> consider using the REVERSE_LSP Object in the upstream/Resv direction 
>>> to allow the egress/tail to provide the ingress/head with arbitrary information....
>>> /
>>> Thanks,
>>> Rakesh
>>>  
>>>  
>>>
>>> Regards
>>>
>>> Fei
>>>
>>> *"Rakesh Gandhi (rgandhi)" <**rgandhi@cisco.com*
>>> *>*
>>>
>>> 2012-09-13 01:23
>>>
>>> 	
>>>
>>>  
>>>
>>> ÊÕ¼þÈË
>>>
>>> 	
>>>
>>> Lou Berger >
>>>
>>> ³­ËÍ
>>>
>>> 	
>>>
>>> "zhang.fei3@zte.com.cn "
>>> >, 
>>> "ccamp@ietf.org " >> >
>>>
>>> Ö÷Ìâ
>>>
>>> 	
>>>
>>> RE: Question on LSP control in
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>>
>>>  
>>>
>>>  
>>>
>>> 	
>>>
>>>
>>>
>>>
>>>
>>> Hi Lou, Fei, WG,
>>>
>>> Thanks for your replies. May I propose following text to cover this 
>>> case? This allows the mid-point solution which has advantages but 
>>> given the additional complexity can be optional.
>>>
>>> Please advise.
>>>
>>> "When an initiating ingress node is provisioned with "Single Sided 
>>> Associated Bidirectional LSPs" and wishes to control both forward and 
>>> reverse  LSPs by adding "REVERSE_LSP" object, the ingress node SHOULD 
>>> know the signaling (path) errors on the reverse LSP.  A transit node 
>>> MAY be requested to notify the signaling error on the reverse LSP by 
>>> using the NOTIFY message and procedures defined in RFC[3473]. In the 
>>> absence of such notification request, egress node SHOULD relay the 
>>> received signaling error on the reverse LSP to the ingress node using 
>>> the NOTIFY message."
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net] 
>>> 
>>> Sent: Wednesday, September 12, 2012 12:14 PM
>>> To: Rakesh Gandhi (rgandhi)
>>> Cc: zhang.fei3@zte.com.cn ; 
>>> ccamp@ietf.org 
>>> Subject: Re: Question on LSP control in 
>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>
>>> Rakesh,
>>>
>>>
>>> On 9/12/2012 11:52 AM, Rakesh Gandhi (rgandhi) wrote:
>>>> Thanks Lou.
>>>>
>>>> Are we ok in general to use NOTIFY message [RFC3473] for this?
>>>
>>> I'm not speaking for the WG, as noted my comments were as a participant.
>>> IMO you'll need to fully document the proposal, perhaps discuss 
>>> alternatives considered, and then ask the WG for concurrence.
>>>
>>>>
>>>> One advantage with the mid-point sending notification for the 
>>>> reverse LSP is that signaling error propagation time
>>>> (mid->egress-node->ingress-node) is significantly reduced (to
>>>> mid->ingress-node) which may be preferred in some cases.
>>>
>>> >From my (personal) perspective, the added complexity isn't worth the effort.  Of course, a detailed proposal may show otherwise.
>>>
>>> Lou
>>>
>>>>
>>>> Thanks,
>>>> Rakesh
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net] 
>>>> 
>>>> Sent: Wednesday, September 12, 2012 9:15 AM
>>>> To: Rakesh Gandhi (rgandhi)
>>>> Cc: zhang.fei3@zte.com.cn ; 
>>>> ccamp@ietf.org
>>> 
>>>> Subject: Re: Question on LSP control in 
>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>
>>>> Rakesh,
>>>>                  Speaking as WG participant, I haven't thought about 
>>>> this too much so may be off, but method 3 seems to be most 
>>>> consistent with the usage of the REVERSE_LSP Object in the path message.
>>>> Perhaps consider using the REVERSE_LSP Object in the upstream/Resv 
>>>> direction to allow the egress/tail to provide the
>>> ingress/head with arbitrary information....
>>>>
>>>> Lou
>>>>
>>>> On 9/11/2012 9:22 AM, Rakesh Gandhi (rgandhi) wrote:
>>>>> Hi WG,
>>>>>
>>>>> Any thoughts on the following proposal?
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rakesh Gandhi (rgandhi)
>>>>> Sent: Tuesday, September 04, 2012 1:36 PM
>>>>> To: 'Lou Berger'
>>>>> Cc: zhang.fei3@zte.com.cn ; 
>>>>> ccamp@ietf.org
>>> 
>>>>> Subject: RE: Question on LSP control in 
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>>>>>
>>>>> Thanks Lou for your reply.
>>>>>
>>>>> RFC 3473 defines procedures for NOTIFY request and reply. We could use this for reverse LSP signaling error notification to the initiating ingress node.
>>>>>
>>>>>  ::=  [] [ [ | ] ... ]
>>>>>    
>>>>>    >
>>>>>
>>>>> There are multiple ways we can use the NOTIFY message.
>>>>>
>>>>> Method 1 - Mid-point aware with Path message request:
>>>>> When an egress node receives a Path message with REVERSE_LSP object, the node will insert NOTIFY_REQ message in the reverse LSP path message with node ID of the initiating ingress node. A mid-point node will send  a copy of the signaling error to the initiating node using the NOTIFY message.
>>>>>
>>>>> IPv4 Notify Request Object
>>>>>    IPv4 Notify Node Address: 32 bits
>>>>>       The IP address of the node that should be notified when generating an error message.
>>>>>
>>>>> Method 2 - Mid-point aware with Resv message request:
>>>>> When an initiating ingress node receives a Path message for a reverse LSP, the node will insert NOTIFY_REQ message in the reverse LSP Resv message with its own node ID. A mid-point node will send a copy of the signaling error to the initiating node using the NOTIFY message.
>>>>>
>>>>> Method 3 - Tail-end relaying :
>>>>> When an egress node receives a Path message with REVERSE_LSP 
>>>>> object, the node will relay the received signaling error message on 
>>>>> the reverse LSP to the initializing ingress node. The egress node 
>>>>> copies the received "ERROR_SPEC" object into a NOTIFY [RFC3473, 
>>>>> section 4.3] message and signals it to the ingress node. In this 
>>>>> case,
>>> NOTIFY_REQ message is not required.
>>>>>
>>>>> Please advise your thoughts.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:lberger@labn.net] 
>>>>> 
>>>>> Sent: Tuesday, September 04, 2012 11:35 AM
>>>>> To: Rakesh Gandhi (rgandhi)
>>>>> Cc: zhang.fei3@zte.com.cn ; 
>>>>> ccamp@ietf.org
>>> 
>>>>> Subject: Re: Question on LSP control in 
>>>>> draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-04.txt
>>>>>
>>>>> As I read the current rev, no such notification mechanism is specified.
>>>>>  Looks like you get to propose one!
>>>>>
>>>>> Lou (as WG participant).
>>>>>
>>>>> On 8/31/2012 9:49 AM, Rakesh Gandhi (rgandhi) wrote:
>>>>>> Hi Lou, Fei,
>>>>>>
>>>>>> When an (originating) ingress node is provisioned with "5 (TBD) 
>>>>>> Single Sided Associated Bidirectional LSPs  (A)" and wishes to 
>>>>>> control both forward and reverse  LSPs by adding "REVERSE_LSP"
>>>>>> object, I would think that the ingress node needs to know about 
>>>>>> the signaling (path) errors (such as soft preemption or admission
>>> failure) on the reverse LSP.  Is there any text somewhere in an 
>>> RFC/draft that describes how a mid-point node can send the signaling
>>> (path) error to the originating ingress node for the reverse LSP? Is 
>>> there an assumption to use RSVP_NOTIFY message? Sorry if I had missed 
>>> any previous discussion on this topic.
>>>>>>
>>>>>> Thanks,
>>>>>> Rakesh
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>

From internet-drafts@ietf.org  Thu Sep 13 18:32: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 490F221F86B6; Thu, 13 Sep 2012 18:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WL9Z298UFZg; Thu, 13 Sep 2012 18:32:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD9221F8618; Thu, 13 Sep 2012 18:32:58 -0700 (PDT)
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: 4.34
Message-ID: <20120914013258.26516.96019.idtracker@ietfa.amsl.com>
Date: Thu, 13 Sep 2012 18:32:58 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-05.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, 14 Sep 2012 01:32:59 -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 Work=
ing Group of the IETF.

	Title           : RSVP-TE Extensions for Associated Bidirectional LSPs
	Author(s)       : Fei Zhang
                          Ruiquan Jing
                          Rakesh Gandhi
	Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-05.txt
	Pages           : 15
	Date            : 2012-09-13

Abstract:
   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
   describes that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.

   This document provides a method to bind two unidirectional Label
   Switched Paths (LSPs) into an associated bidirectional LSP.  The
   association is achieved by defining the new Association Types in the
   Extended ASSOCIATION object.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ=
ated-lsp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-l=
sp-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext-asso=
ciated-lsp-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From rgandhi@cisco.com  Fri Sep 14 05:25:28 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 A453021F84B5 for ; Fri, 14 Sep 2012 05:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.098
X-Spam-Level: 
X-Spam-Status: No, score=-9.098 tagged_above=-999 required=5 tests=[AWL=1.501,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rhh7waMiB91O for ; Fri, 14 Sep 2012 05:25:27 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id ACBAA21F8504 for ; Fri, 14 Sep 2012 05:25:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2517; q=dns/txt; s=iport; t=1347625527; x=1348835127; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Amjhr97UyOAjZF0TAoABK6T5BiW9CR5fKRvkVgjdahA=; b=C/oD/2f889fu9rqh0jC53GNyQ6YY4Lsn7uHaSsUyiXXK840laTyy71xH pe+4fBSphDPmJhYK/58766NEtwkXTDBLlqtjvDtChpjoEqzxe/vggDm6e Qfiz2rFugxzqQe8f4LkD7B9DhJsjD4lXkhVOm9wXgHtCP7SR8LKqhhyFw w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGshU1CtJV2Z/2dsb2JhbABFu3yBB4IgAQEBBAEBAQ8BJzQXBgEZBAEBCxQJLgsUCQkBBAESCAEZh2sLmwmgE4sVhghgA5Z1jSSBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,422,1344211200"; d="scan'208";a="121381944"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 14 Sep 2012 12:25:27 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8ECPRXx014286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 12:25:27 GMT
Received: from xmb-aln-x07.cisco.com ([169.254.2.196]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 07:25:27 -0500
From: "Rakesh Gandhi (rgandhi)" 
To: "ccamp@ietf.org" , "zhang.fei3@zte.com.cn" , "jingrq@ctbri.com.cn" 
Thread-Topic: Updates in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-05.txt
Thread-Index: Ac2SdAQZ1t9kzvLDQbabIteqJRNkNA==
Date: Fri, 14 Sep 2012 12:25:26 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.215.95]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004
x-tm-as-result: No--31.604500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CCAMP] Updates in draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-05.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, 14 Sep 2012 12:25:28 -0000

Dear WG,

Based on the WG review and consensus, following changes have been made in t=
his version [05] of the draft.=20

-	Restore association types for single sided and double sided LSPs (revert =
association flags)
-	Revise text for Associated Bidirectional LSPs and LSP Recovery
-	Revise text for Associated Bidirectional LSPs and TE Mesh-Groups
-	Revise text for MPLS-TP Associated Bidirectional LSP Identifiers
-	Revert co-routed LSPs=20
-	Update definition and usage of the association object=20
-	Minor editorial changes =20

Please review and provide your comments.

Thanks,
Rakesh=09

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Thursday, September 13, 2012 9:33 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated=
-lsp-05.txt


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 Work=
ing Group of the IETF.

	Title           : RSVP-TE Extensions for Associated Bidirectional LSPs
	Author(s)       : Fei Zhang
                          Ruiquan Jing
                          Rakesh Gandhi
	Filename        : draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-05.tx=
t
	Pages           : 15
	Date            : 2012-09-13

Abstract:
   The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654],
   describes that MPLS-TP MUST support associated bidirectional point-
   to-point LSPs.

   This document provides a method to bind two unidirectional Label
   Switched Paths (LSPs) into an associated bidirectional LSP.  The
   association is achieved by defining the new Association Types in the
   Extended ASSOCIATION object.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associ=
ated-lsp

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-l=
sp-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-mpls-tp-rsvpte-ext-asso=
ciated-lsp-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From swallow@cisco.com  Fri Sep 14 14:34: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 DF43021F84D2 for ; Fri, 14 Sep 2012 14:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGujvzCI04QA for ; Fri, 14 Sep 2012 14:34:32 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4883B21F84B9 for ; Fri, 14 Sep 2012 14:34:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1606; q=dns/txt; s=iport; t=1347658472; x=1348868072; h=from:to:cc:subject:date:message-id:mime-version; bh=BabJjUpDFnrBXK8NT5ud7fsJHMV3/SSlC++Qndnd2CU=; b=g2oNkskgsgj6cBlNv6kFB6fUq3pNEWt3N7xPhhnnobl1B7OpVjQm4bCa KfHoAVZJmc3pQkJOgeWXybI7Jh0GAd7Eil9zxqeMg+CoI7NnGT26t8je8 tb3M6LkuNuCNlm1Rc0AYvlkHGE7JSRtMC2FEikDd0sqClbGWoCJLsQdCO 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AswHAHKiU1CtJXG+/2dsb2JhbABFgkuIULBvgQeCFxASAWYSAQsBdCcEDieHa5sOoBqSBwOVYY44gWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,424,1344211200";  d="scan'208,217";a="121791835"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 14 Sep 2012 21:34:32 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8ELYV1m024275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 21:34:31 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 16:34:31 -0500
From: "George Swallow (swallow)" 
To: "ccamp@ietf.org" 
Thread-Topic: Request for a WG adoption poll on draft-ali-ccamp-te-metric-recording-02.txt
Thread-Index: AQHNksC52lMT7q/UWk+TApFGMHmaHg==
Date: Fri, 14 Sep 2012 21:34:30 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.32.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004
x-tm-as-result: No--26.927600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC791B23D895swallowciscocom_"
MIME-Version: 1.0
Subject: [CCAMP] Request for a WG adoption poll on draft-ali-ccamp-te-metric-recording-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, 14 Sep 2012 21:34:33 -0000

--_000_CC791B23D895swallowciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Lou, Deborah,

At the last meeting I proposed to merge this draft with the SRLG recording =
draft.  There seemed to be good support for that in the room.  However Lou =
recommended that we keep them separate as the subject draft has dependencie=
s on work in ISIS and future work in OSPF.

I therefore am requesting that you poll this draft for WG adoption .

Thanks,

=85George

--_000_CC791B23D895swallowciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Lou, Deborah,







At the last meeting I proposed to merge this draft with the SRLG recor=
ding draft.  There seemed to be good support for that in the room. &nb=
sp;However Lou recommended that we keep them separate as the subject draft =
has dependencies on work in ISIS and future
 work in OSPF.







I therefore am requesting that you poll this draft for WG adoption&nbs=
p;.







Thanks,







=85George




--_000_CC791B23D895swallowciscocom_--

From swallow@cisco.com  Fri Sep 14 14:41: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 B409321F8568 for ; Fri, 14 Sep 2012 14:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q46WzesipjWZ for ; Fri, 14 Sep 2012 14:41:49 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 36C2B21F8554 for ; Fri, 14 Sep 2012 14:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1347658909; x=1348868509; h=from:to:cc:subject:date:message-id:mime-version; bh=JUovtw1WXHSTIPvuKhRhC+byxywhZ7gy7Ek9YSsSbm0=; b=NuHiKWY70yqt+Z/+KkFuicQifVn9sJTuptwrFbX2ZmKhbJjWON2SlT5W BnCYp+GqDvbI3qvAjO7sMZJ4AYgGqP5gqtgTu9zKAxObXa1PzOmyRhMvk cAm4Z7g8+bsl9ABqAO1iKD7uoBVeX6QRnbCSgRCvfaOwtvCMnBwWXeOdt k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AswHAGqkU1CtJV2Z/2dsb2JhbABFgkuIULBvgQeCJxIBZhIBCwECcicEDieHa5sLoBqSBwOVYY44gWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,424,1344211200";  d="scan'208,217";a="121569707"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 14 Sep 2012 21:41:47 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8ELflrY012610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 21:41:47 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 16:41:46 -0500
From: "George Swallow (swallow)" 
To: "ccamp@ietf.org" 
Thread-Topic: Request for a WG adoption poll on draft-ali-ccamp-rc-objective-function-metric-bound-02
Thread-Index: AQHNksG934bLeTsmcEO4vyUEovSmMQ==
Date: Fri, 14 Sep 2012 21:41:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.32.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004
x-tm-as-result: No--25.644200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC791CD7D8A5swallowciscocom_"
MIME-Version: 1.0
Subject: [CCAMP] Request for a WG adoption poll on draft-ali-ccamp-rc-objective-function-metric-bound-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: Fri, 14 Sep 2012 21:41:49 -0000

--_000_CC791CD7D8A5swallowciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Lou, Deborah,

Please poll the subject draft for WG adoption.

Thanks!

=85George

--_000_CC791CD7D8A5swallowciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <98EC2CECC998D4409821DA30533F5C0C@cisco.com>
Content-Transfer-Encoding: quoted-printable







Lou, Deborah,







Please poll the subject draft for WG adoption.







Thanks!







=85George




--_000_CC791CD7D8A5swallowciscocom_--

From db3546@att.com  Mon Sep 17 03:21: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 7A46221F85D5 for ; Mon, 17 Sep 2012 03:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+HEB4eUHdfY for ; Mon, 17 Sep 2012 03:21:55 -0700 (PDT)
Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD221F85BB for ; Mon, 17 Sep 2012 03:21:48 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id cb9f6505.0.215697.00-364.577950.nbfkord-smmo04.seg.att.com (envelope-from );  Mon, 17 Sep 2012 10:21:49 +0000 (UTC)
X-MXL-Hash: 5056f9bd5dee8939-234e64a9cc23fe2d1ed2d61cd0e3af534157f938
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 q8HALm8l027092 for ; Mon, 17 Sep 2012 06:21:48 -0400
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 q8HALhKJ027069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 17 Sep 2012 06:21:44 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Mon, 17 Sep 2012 06:21:28 -0400
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0318.001; Mon, 17 Sep 2012 06:21:28 -0400
From: "BRUNGARD, DEBORAH A" 
To: "ccamp@ietf.org" 
Thread-Topic: WG Last Call on draft-ietf-ccamp-lmp-behavior-negotiation
Thread-Index: Ac2GEmcNhEdnElFZQr2X0TGuCZZzqgOqxtjw
Date: Mon, 17 Sep 2012 10:21:28 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.8.218]
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-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=2.0 cv=f8D/8pOM c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a]
X-AnalysisOut: [=iKPE9fZjNmwA:10 a=2hEuOskOL2EA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Dx06-bgnpGwA:10 a=48vgC7mUAAAA:8 a=6Bm7JtxVbH0hLS]
X-AnalysisOut: [WiCSQA:9 a=CjuIK1q_8ugA:10 a=2TSDkfqdCjIA:10 a=lZB815dzVvQ]
X-AnalysisOut: [A:10]
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-lmp-behavior-negotiation
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, 17 Sep 2012 10:21:56 -0000

All,

This ends the Last Call. I'll prepare the request for publication.
Thanks,
Deborah

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of B=
RUNGARD, DEBORAH A
Sent: Wednesday, August 29, 2012 2:16 PM
To: ccamp@ietf.org
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-lmp-behavior-negotiation

*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

CCAMP,

This starts a two-week (ends Sept. 13th) working group last call on draft-i=
etf-ccamp-lmp-behavior-negotiation.

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

From julien.meuric@orange.com  Mon Sep 17 06:37: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 A192521F84C2 for ; Mon, 17 Sep 2012 06:37:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wH0i2IpxsoP for ; Mon, 17 Sep 2012 06:37:28 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01721F846E for ; Mon, 17 Sep 2012 06:37:28 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A39AF1074003; Mon, 17 Sep 2012 15:40:02 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9C9B81074002; Mon, 17 Sep 2012 15:40:02 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Sep 2012 15:37:27 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 17 Sep 2012 15:37:26 +0200
Message-ID: <50572795.20005@orange.com>
Date: Mon, 17 Sep 2012 15:37:25 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: "George Swallow (swallow)" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 17 Sep 2012 13:37:26.0678 (UTC) FILETIME=[937BA360:01CD94D9]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 17 Sep 2012 13:37:29 -0000

Hi George.

Sorry for the late response. You are right: the minutes are not enough 
to trace the full discussion (which we also resumed right after the 
meeting). Let us start by thanking Adrian (as AD? former PCE co-chair? 
author of... ;-) ) for bringing the PCE-associated vocabulary to a 
common understanding.

Actually my concern is sustained by 2 points:

1- The scope of the draft is about giving control of the routing 
objective function to the client node facing a transport layer. I see 
already several existing solution to achieve it:
- a PCEP request from the signaling head node is an option (which is 
associated to the advertisement of the supported objectives in PCEP);
- building IGP adjacencies between client and transport edge nodes 
(a.k.a. "border model") is another one.
In this context, it do not think extending RSVP-TE for this kind of 
application is worth the effort, since the requirement can already be 
addressed.

2- There are cases when previous options are ruled out of a given 
deployment. I do believe that it is not simply due to protocol 
exclusion, but rather to the fact that the SP wants transport routing 
decisions to remain entirely within the transport network (in order to 
fully leave the routing policy in the hands of people doing the layer 
dimensioning). Thus, I feel this trade-off in path selection tuning is 
rather unlikely to happen and I fear we may be talking about RSVP-TE 
over-engineering here. (That is also why I preferred to consider your 
I-Ds separately during the CCAMP meeting.)

However, my comments are mostly related to the client/transport 
relationship. If the I-D is extended to cover more use cases with wider 
scopes (Adrian has made interesting suggestions), turning the overlay 
interconnection into one among a longer list, then my conclusion may be 
different.

Regards,

Julien


Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
> Julien -
>
> Reading the CCAMP notes (which capture little of the actual 
> discussion) I see that there may have been a perception in the room 
> that PCE functionality at the UNI-N was assumed (actual or proxy).
>
> This is not the case. The reason for our draft is that with the UNI, 
> much of the functionality that resides at the headend is moved to the 
> UNI-N. So the UNI-C needs a way to express an objective function even 
> if there is no PCE.
>
> Operationally it seems burdensome to require a PCEP at the UNI-C and a 
> PCEP at the UNI-N, when all that is being done is enabling the UNI-N 
> to perform what the client would do if it were connected to the 
> network via a normal link.
>
> Do you still object to the draft?
>
> Thanks,
>
> …George



From swallow@cisco.com  Mon Sep 17 09:19: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 F0CD521F86E1 for ; Mon, 17 Sep 2012 09:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP-Xrzb0Hqgn for ; Mon, 17 Sep 2012 09:19:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 186D721F8539 for ; Mon, 17 Sep 2012 09:19:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3747; q=dns/txt; s=iport; t=1347898763; x=1349108363; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=T1+METpShyVGuXDrjurijNtVhRUsJ6/ohW6JgaHrD24=; b=FvAeMPQ+52xyRTAoB3D1zj88fibAt2J6p6M8kG+fjTs9gtW0FrqX9cO4 zKbcWHaLJpTUDDupHeyhsScMcIyoTDObjYf5moBxSlRcGX5yu1uc/SB3q 4nhq3YarGfAFLZH6LzLzxK6V7NbrIVBlBo7gxWFjD8+iuMyGLqmsVIUMK M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EALRMV1CtJXHA/2dsb2JhbABEvBaBB4InEgFfBxIBCHglAgQOBRsHh16adp9riyGGaAOSMYMxjjiBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,437,1344211200"; d="scan'208";a="122385556"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 17 Sep 2012 16:19:22 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8HGJMRw019524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Sep 2012 16:19:22 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 11:19:21 -0500
From: "George Swallow (swallow)" 
To: Julien Meuric 
Thread-Topic: Objective function draft
Thread-Index: AQHNkFOv4OOKfbxolEe2spFvFX1LfJeO5k+A///qLAA=
Date: Mon, 17 Sep 2012 16:19:21 +0000
Message-ID: 
In-Reply-To: <50572795.20005@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.32.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19188.004
x-tm-as-result: No--47.350300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 17 Sep 2012 16:19:24 -0000

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric"  wrote:

>Hi George.
>
>Sorry for the late response. You are right: the minutes are not enough
>to trace the full discussion (which we also resumed right after the
>meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>author of... ;-) ) for bringing the PCE-associated vocabulary to a
>common understanding.
>
>Actually my concern is sustained by 2 points:
>
>1- The scope of the draft is about giving control of the routing
>objective function to the client node facing a transport layer. I see
>already several existing solution to achieve it:
>- a PCEP request from the signaling head node is an option (which is
>associated to the advertisement of the supported objectives in PCEP);
>- building IGP adjacencies between client and transport edge nodes
>(a.k.a. "border model") is another one.
>In this context, it do not think extending RSVP-TE for this kind of
>application is worth the effort, since the requirement can already be
>addressed.

As I understand it, in the optical and OTN cases, the border model would
not be popular=20
as in many organizations this crosses political boundaries.

The point of the draft is to keep the UNI implementation simple and not
require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
format aligned so if the UNI-N needs to make a request of a PCS, it can do
so rather simply.
>
>2- There are cases when previous options are ruled out of a given
>deployment. I do believe that it is not simply due to protocol
>exclusion, but rather to the fact that the SP wants transport routing
>decisions to remain entirely within the transport network (in order to
>fully leave the routing policy in the hands of people doing the layer
>dimensioning). Thus, I feel this trade-off in path selection tuning is
>rather unlikely to happen and I fear we may be talking about RSVP-TE
>over-engineering here.

The idea is simply to allow the client to express its needs/wishes.  The
UNI-N remains in control.  By policy it can use the objective function or
not.  Further if it does use the objective function and fails to find a
path it can either say that there was no path or it
proceed to setup what it can.

>(That is also why I preferred to consider your
>I-Ds separately during the CCAMP meeting.)

Agreed.  I will ask for separate slots.  The discussion at the end was
rather disjointed.

>
>However, my comments are mostly related to the client/transport
>relationship. If the I-D is extended to cover more use cases with wider
>scopes (Adrian has made interesting suggestions), turning the overlay
>interconnection into one among a longer list, then my conclusion may be
>different.

I'm happy to widen the scope in this way.

...George

>Regards,
>
>Julien
>
>
>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>> Julien -
>>
>> Reading the CCAMP notes (which capture little of the actual
>> discussion) I see that there may have been a perception in the room
>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>
>> This is not the case. The reason for our draft is that with the UNI,
>> much of the functionality that resides at the headend is moved to the
>> UNI-N. So the UNI-C needs a way to express an objective function even
>> if there is no PCE.
>>
>> Operationally it seems burdensome to require a PCEP at the UNI-C and a
>> PCEP at the UNI-N, when all that is being done is enabling the UNI-N
>> to perform what the client would do if it were connected to the
>> network via a normal link.
>>
>> Do you still object to the draft?
>>
>> Thanks,
>>
>> =8AGeorge
>
>


From dieter.beller@alcatel-lucent.com  Mon Sep 17 13:11: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 9667521E8037 for ; Mon, 17 Sep 2012 13:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.791
X-Spam-Level: 
X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4EqgnJb3-HR for ; Mon, 17 Sep 2012 13:11:46 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB3D21F8616 for ; Mon, 17 Sep 2012 13:11:45 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8HKBfli003664 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 17 Sep 2012 22:11:41 +0200
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 17 Sep 2012 22:11:41 +0200
Received: from [138.120.161.200] (135.5.27.17) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 17 Sep 2012 16:11:38 -0400
Message-ID: <505783F8.50901@alcatel-lucent.com>
Date: Mon, 17 Sep 2012 22:11:36 +0200
From: Dieter Beller 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "George Swallow (swallow)" 
References: 
In-Reply-To: 
Content-Type: multipart/related; boundary="------------050902010300070005060504"
X-Originating-IP: [135.5.27.17]
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 17 Sep 2012 20:11:47 -0000

--------------050902010300070005060504
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi George,

      

      I tend to agree that the object function carried in RSVP signaling
      can be used

      whenever path computation is invoked. This should be pretty much
      independent

      whether path computation is done by a CP instance (UNI-N node or
      E-NNI node)

      or a PCE instance. In case a PCE approach is used, the
    objective function needs

    to be forwarded to the PCE instance using the PCEP.

    

    

    Thanks,

    Dieter

    

    On 17.09.2012 18:19, George Swallow (swallow) wrote:

    

      
Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <julien.meuric@orange.com> wrote:



      

        
Hi George.

Sorry for the late response. You are right: the minutes are not enough
to trace the full discussion (which we also resumed right after the
meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
author of... ;-) ) for bringing the PCE-associated vocabulary to a
common understanding.

Actually my concern is sustained by 2 points:

1- The scope of the draft is about giving control of the routing
objective function to the client node facing a transport layer. I see
already several existing solution to achieve it:
- a PCEP request from the signaling head node is an option (which is
associated to the advertisement of the supported objectives in PCEP);
- building IGP adjacencies between client and transport edge nodes
(a.k.a. "border model") is another one.
In this context, it do not think extending RSVP-TE for this kind of
application is worth the effort, since the requirement can already be
addressed.


      

      
As I understand it, in the optical and OTN cases, the border model would
not be popular 
as in many organizations this crosses political boundaries.

The point of the draft is to keep the UNI implementation simple and not
require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
format aligned so if the UNI-N needs to make a request of a PCS, it can do
so rather simply.


      

        
2- There are cases when previous options are ruled out of a given
deployment. I do believe that it is not simply due to protocol
exclusion, but rather to the fact that the SP wants transport routing
decisions to remain entirely within the transport network (in order to
fully leave the routing policy in the hands of people doing the layer
dimensioning). Thus, I feel this trade-off in path selection tuning is
rather unlikely to happen and I fear we may be talking about RSVP-TE
over-engineering here.


      

      
The idea is simply to allow the client to express its needs/wishes.  The
UNI-N remains in control.  By policy it can use the objective function or
not.  Further if it does use the objective function and fails to find a
path it can either say that there was no path or it
proceed to setup what it can.



      

        
(That is also why I preferred to consider your
I-Ds separately during the CCAMP meeting.)


      

      
Agreed.  I will ask for separate slots.  The discussion at the end was
rather disjointed.



      

        
However, my comments are mostly related to the client/transport
relationship. If the I-D is extended to cover more use cases with wider
scopes (Adrian has made interesting suggestions), turning the overlay
interconnection into one among a longer list, then my conclusion may be
different.


      

      
I'm happy to widen the scope in this way.

...George



      

        
Regards,

Julien


Le 11/09/2012 21:28, George Swallow (swallow) a écrit :


        

          
Julien -

Reading the CCAMP notes (which capture little of the actual
discussion) I see that there may have been a perception in the room
that PCE functionality at the UNI-N was assumed (actual or proxy).

This is not the case. The reason for our draft is that with the UNI,
much of the functionality that resides at the headend is moved to the
UNI-N. So the UNI-C needs a way to express an objective function even
if there is no PCE.

Operationally it seems burdensome to require a PCEP at the UNI-C and a
PCEP at the UNI-N, when all that is being done is enabling the UNI-N
to perform what the client would do if it were connected to the
network via a normal link.

Do you still object to the draft?

Thanks,

ŠGeorge


        

        



      

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


    

    

    
-- 

      
      

        

          

            
            
            

            

              
DIETER




                      BELLER

                

                  

                    
 ALCATEL-LUCENT

                          DEUTSCHLAND AG

                        PROJECT MANAGER ASON/GMPLS
                          CONTROL PLANE

                          NETWORKS GROUP, OPTICS DIVISION

                          TERRESTRIAL OPTICS UNIT

                          

                          Lorenzstrasse 10

                          70435 Stuttgart, Germany

                        T: +49 711 821 43125

                          M: +49 175 7266874

                        Dieter.Beller@alcatel-lucent.com

                            

                          Alcatel-Lucent
                            Deutschland AG

                            Domicile of the Company: Stuttgart · Local
                            Court Stuttgart HRB 4026

                            Chairman of the Supervisory Board: Michael
                            Oppenhoff

                            Board of Management: Wilhelm Dresselhaus
                            (Chairman) · Hans-Jörg Daub ·

                          Dr. Rainer Fechner ·
                            Andreas Gehe

                            

                          This e-mail and its
                            attachments, if any, may contain
                            confidential information.

                            If you have received this e-mail in error,
                            please notify us and delete or destroy the

                            e-mail and its attachments, if any,
                            immediately. If you have received this
                            e-mail in

                            error, you must not forward or make use of
                            the e-mail and its attachments, if any.

                    

                  

                

              

            

          

        

      

    

  


--------------050902010300070005060504
Content-Type: image/jpeg; name="Corporate-sig-logo.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline; filename="Corporate-sig-logo.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA
Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC
AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG
AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL
EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh
sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5
OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX
2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx
CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW
N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI
mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P
pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09
bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS
t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO
xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q
XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ
7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN
KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3
PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT
51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7
jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1
+i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K
Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp
jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i
yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d
L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R
1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ
PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN
t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0
E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo
JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox
q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv
utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr
KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD
bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y
8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm
1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr
5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3
10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH
yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW
YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq
0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t
fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9
5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti
z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn
ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H
urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N
PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf
4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R
HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR
Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh
7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f
If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd
WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D
2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q
iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox
c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0
6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f
Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z
9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c
FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F
/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0
w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu
LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK
KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI
pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o
NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3
vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c
Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi
8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY
8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/
EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V
MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl
pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w
8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN
z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63
rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3
FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP
2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i
fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/
g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1
XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70
m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p
4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np
T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY
pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo
6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV
BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x
HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3
b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U
49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN
25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi
apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h
/wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN
WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697
917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r
3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X
uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/
ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A
N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z
--------------050902010300070005060504--

From ggrammel@juniper.net  Mon Sep 17 14:26:42 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 9AE5021F85EF for ; Mon, 17 Sep 2012 14:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level: 
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-qZfqHAfIFl for ; Mon, 17 Sep 2012 14:26:41 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id BAB4C21F85C6 for ; Mon, 17 Sep 2012 14:26:41 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUFeVkaBgV9LYe5EYZrw0TLeZzm2Y7bm6@postini.com; Mon, 17 Sep 2012 14:26:41 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 17 Sep 2012 14:22:31 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 17 Sep 2012 14:22:31 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 17 Sep 2012 14:24:03 -0700
Received: from mail66-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Sep 2012 21:22:30 +0000
Received: from mail66-va3 (localhost [127.0.0.1])	by mail66-va3-R.bigfish.com (Postfix) with ESMTP id 1B28A4400B1	for ; Mon, 17 Sep 2012 21:22:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -33
X-BigFish: PS-33(zzbb2dI98dI9371Ic89bhec9Q1432I4015Id6f1izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h946hd25hf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail66-va3 (localhost.localdomain [127.0.0.1]) by mail66-va3 (MessageSwitch) id 1347916948119164_705; Mon, 17 Sep 2012 21:22:28 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.245])	by mail66-va3.bigfish.com (Postfix) with ESMTP id 0FFD5400C6; Mon, 17 Sep 2012 21:22:28 +0000 (UTC)
Received: from CH1PRD0511HT005.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Sep 2012 21:22:24 +0000
Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.4.151]) by CH1PRD0511HT005.namprd05.prod.outlook.com ([10.255.159.40]) with mapi id 14.16.0190.008; Mon, 17 Sep 2012 21:22:23 +0000
From: Gert Grammel 
To: "George Swallow (swallow)" , Julien Meuric 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGKyfc7fsst0WOjIXQZVY+Ww==
Date: Mon, 17 Sep 2012 21:22:22 +0000
Message-ID: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.159.4]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 17 Sep 2012 21:26:42 -0000

Hi George,

The objective function is in the end a routing information. Mixing routing =
and signaling in one protocol is something I don't feel comfortable with.

In other words, if routing is needed between client and server, UNI is the =
wrong choice. ENNI should be considered instead and
Draft-beeram-ccamp-gmpls-enni would be a good starting point.


Gert



________________________________________
From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
Sent: Monday, September 17, 2012 12:19:21 PM
To: Julien Meuric
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric"  wrote:

>Hi George.
>
>Sorry for the late response. You are right: the minutes are not enough
>to trace the full discussion (which we also resumed right after the
>meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>author of... ;-) ) for bringing the PCE-associated vocabulary to a
>common understanding.
>
>Actually my concern is sustained by 2 points:
>
>1- The scope of the draft is about giving control of the routing
>objective function to the client node facing a transport layer. I see
>already several existing solution to achieve it:
>- a PCEP request from the signaling head node is an option (which is
>associated to the advertisement of the supported objectives in PCEP);
>- building IGP adjacencies between client and transport edge nodes
>(a.k.a. "border model") is another one.
>In this context, it do not think extending RSVP-TE for this kind of
>application is worth the effort, since the requirement can already be
>addressed.

As I understand it, in the optical and OTN cases, the border model would
not be popular
as in many organizations this crosses political boundaries.

The point of the draft is to keep the UNI implementation simple and not
require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
format aligned so if the UNI-N needs to make a request of a PCS, it can do
so rather simply.
>
>2- There are cases when previous options are ruled out of a given
>deployment. I do believe that it is not simply due to protocol
>exclusion, but rather to the fact that the SP wants transport routing
>decisions to remain entirely within the transport network (in order to
>fully leave the routing policy in the hands of people doing the layer
>dimensioning). Thus, I feel this trade-off in path selection tuning is
>rather unlikely to happen and I fear we may be talking about RSVP-TE
>over-engineering here.

The idea is simply to allow the client to express its needs/wishes.  The
UNI-N remains in control.  By policy it can use the objective function or
not.  Further if it does use the objective function and fails to find a
path it can either say that there was no path or it
proceed to setup what it can.

>(That is also why I preferred to consider your
>I-Ds separately during the CCAMP meeting.)

Agreed.  I will ask for separate slots.  The discussion at the end was
rather disjointed.

>
>However, my comments are mostly related to the client/transport
>relationship. If the I-D is extended to cover more use cases with wider
>scopes (Adrian has made interesting suggestions), turning the overlay
>interconnection into one among a longer list, then my conclusion may be
>different.

I'm happy to widen the scope in this way.

...George

>Regards,
>
>Julien
>
>
>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>> Julien -
>>
>> Reading the CCAMP notes (which capture little of the actual
>> discussion) I see that there may have been a perception in the room
>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>
>> This is not the case. The reason for our draft is that with the UNI,
>> much of the functionality that resides at the headend is moved to the
>> UNI-N. So the UNI-C needs a way to express an objective function even
>> if there is no PCE.
>>
>> Operationally it seems burdensome to require a PCEP at the UNI-C and a
>> PCEP at the UNI-N, when all that is being done is enabling the UNI-N
>> to perform what the client would do if it were connected to the
>> network via a normal link.
>>
>> Do you still object to the draft?
>>
>> Thanks,
>>
>> =8AGeorge
>
>

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



From daniele.ceccarelli@ericsson.com  Tue Sep 18 00:19: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 2C55421E8064 for ; Tue, 18 Sep 2012 00:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76DLCGJ-70OH for ; Tue, 18 Sep 2012 00:19:17 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C3D2321E8043 for ; Tue, 18 Sep 2012 00:19:16 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-24-50582073780a
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 04.3B.25676.37028505; Tue, 18 Sep 2012 09:19:15 +0200 (CEST)
Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 18 Sep 2012 09:19:15 +0200
From: Daniele Ceccarelli 
To: Gert Grammel , "George Swallow (swallow)" , Julien Meuric 
Date: Tue, 18 Sep 2012 09:19:13 +0200
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGKyfc7fsst0WOjIXQZVY+W5ePrzgg
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>
In-Reply-To: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: it-IT, en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrW6xQkSAQccSDYsnc26wWCzZtYzF 4s/pv0wWt6c0MTqweEz5vZHVY8mSn0we15uusnu0PDvJFsASxWWTkpqTWZZapG+XwJXR97WV tWCXfcWqF53sDYwvbLsYOTkkBEwk9k88wghhi0lcuLeerYuRi0NI4BSjxNOGe4wQzgJGiekd l9m7GDk42ASsJJ4c8gGJiwg0M0ps+n+UHaSbWUBVou36KVYQmwXIvrPoPzOILSygK/FzfycT iC0ioCfxePcSdgjbSOLMxftsIDavQLjEu1PbwXqFBGIkLj28AFbPKRArMX3pdLAaRgFZiQm7 FzFC7BKXuPVkPhPE1QISS/acZ4awRSVePv7HClEvI/Fr0zdWkJuZBTQl1u/Sh2hVlJjS/ZAd Yq2gxMmZT1gmMIrNQjJ1FkLHLCQds5B0LGBkWcUonJuYmZNebqSXWpSZXFycn6dXnLqJERhh B7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwNq/K3uvw +vX93mObHy1MfvzL8dP2Y6dkF3t1HvpbcOjk+j4BP76epNzJaaHR7baSfXO2rKrZqLau0u+3 x6yyzn9/JzEeFeneytTUHxLq0FW9p2da4Iv3L69tFJV4FfYiIP502fw5tyNXN01akn9j62Vt va5zjKu+OZ6yX2OkbLypOqX3s8NWZyWW4oxEQy3mouJEAKrA859+AgAA
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 07:19:18 -0000

KzAuNQ0KDQpGdWxseSBhZ3JlZSBvbiB0aGUgc2Vjb25kIHBhcnQgb2YgeW91ciBzdGF0ZW1lbnQu
IEF0IHRoZSB0aW1lIG9mIFJGQzQyMDggdGhlIFVOSSBhbGxvd2VkIHRoZSBleGNoYW5nZSBvZiBz
aWduYWxpbmcgYW5kIHJvdXRpbmcgbWVzc2FnZXMuIE5vdyB0aGF0IHdlJ3JlIGRlZmluaW5nIGFs
c28gdGhlIEUtTk5JIGkgd291bGQgcHJlZmVyIHRvIGhhdmU6DQoNCi0gVU5JOiBzaWduYWxpbmcg
b25seQ0KLSBFLU5OSTogc2lnbmFsaW5nIEFORCByb3V0aW5nIChpIHdvdWxkIHByZWZlciB0byBj
YWxsIGl0IHJlYWNoYWJpbGl0eSByYXRoZXIgdGhhbiByb3V0aW5nLCBiZWNhdXNlIGl0IGlzIG5v
dCBhIHRvcG9sb2d5IGluZm8pDQoNClRoYXQgc2FpZCwgaSB0aGluayB0aGF0IG9iamVjdGl2ZSBm
dW5jdGlvbiAoZGVzcGl0ZSB0aGUgY29ycmVjdCBjb21tZW50cyBmcm9tIEp1bGllbikgaXMgbm90
IHJvdXRpbmcgYnV0IGEgY29uc3RyYWludC4gVGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgb3Zlcmxh
eSBuZXR3b3JrIGFza3MgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgY29yZSBuZXR3b3JrIGZvciBh
IHBhdGggY29tcHV0YXRpb24gd2l0aCBnaXZlbiBjb25zdHJhaW50cy4gDQoNClZpY2V2ZXJzYSBp
biB0aGUgY2FzZSBvZiBFLU5OSSBpZiB0aGUgb2JqZWN0aXZlIGZ1bmN0aW9uIHdhcyBleHBvcnRl
ZCB0byB0aGUgb3ZlcmxheSBuZXR3b3JrIGFzIGEgInByb3BlcnR5IiBvZiBhIHZpcnR1YWwgbGlu
aywgdGhlbiBpIGFncmVlIGl0IHdhcyByb3V0aW5nIChyZWFjaGFiaWxpdHkpIGluZm9ybWF0aW9u
Lg0KDQpDaGVlcnMsDQpEYW5pZWxlDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZy
b206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3Jn
XSANCj5PbiBCZWhhbGYgT2YgR2VydCBHcmFtbWVsDQo+U2VudDogbHVuZWTDrCAxNyBzZXR0ZW1i
cmUgMjAxMiAyMy4yMg0KPlRvOiBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk7IEp1bGllbiBNZXVy
aWMNCj5DYzogY2NhbXBAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTogW0NDQU1QXSBPYmplY3RpdmUg
ZnVuY3Rpb24gZHJhZnQNCj4NCj5IaSBHZW9yZ2UsDQo+DQo+VGhlIG9iamVjdGl2ZSBmdW5jdGlv
biBpcyBpbiB0aGUgZW5kIGEgcm91dGluZyBpbmZvcm1hdGlvbi4gDQo+TWl4aW5nIHJvdXRpbmcg
YW5kIHNpZ25hbGluZyBpbiBvbmUgcHJvdG9jb2wgaXMgc29tZXRoaW5nIEkgDQo+ZG9uJ3QgZmVl
bCBjb21mb3J0YWJsZSB3aXRoLg0KPg0KPkluIG90aGVyIHdvcmRzLCBpZiByb3V0aW5nIGlzIG5l
ZWRlZCBiZXR3ZWVuIGNsaWVudCBhbmQgDQo+c2VydmVyLCBVTkkgaXMgdGhlIHdyb25nIGNob2lj
ZS4gRU5OSSBzaG91bGQgYmUgY29uc2lkZXJlZCANCj5pbnN0ZWFkIGFuZCBEcmFmdC1iZWVyYW0t
Y2NhbXAtZ21wbHMtZW5uaSB3b3VsZCBiZSBhIGdvb2QgDQo+c3RhcnRpbmcgcG9pbnQuDQo+DQo+
DQo+R2VydA0KPg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj5Gcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBHZW9yZ2UgU3dh
bGxvdyAoc3dhbGxvdykNCj5TZW50OiBNb25kYXksIFNlcHRlbWJlciAxNywgMjAxMiAxMjoxOToy
MSBQTQ0KPlRvOiBKdWxpZW4gTWV1cmljDQo+Q2M6IGNjYW1wQGlldGYub3JnDQo+U3ViamVjdDog
UmU6IFtDQ0FNUF0gT2JqZWN0aXZlIGZ1bmN0aW9uIGRyYWZ0DQo+DQo+SGkgSnVsaWVuIC0NCj4N
Cj5PbiA5LzE3LzEyIDk6MzcgQU0sICJKdWxpZW4gTWV1cmljIiA8anVsaWVuLm1ldXJpY0BvcmFu
Z2UuY29tPiB3cm90ZToNCj4NCj4+SGkgR2VvcmdlLg0KPj4NCj4+U29ycnkgZm9yIHRoZSBsYXRl
IHJlc3BvbnNlLiBZb3UgYXJlIHJpZ2h0OiB0aGUgbWludXRlcyBhcmUgDQo+bm90IGVub3VnaCAN
Cj4+dG8gdHJhY2UgdGhlIGZ1bGwgZGlzY3Vzc2lvbiAod2hpY2ggd2UgYWxzbyByZXN1bWVkIHJp
Z2h0IGFmdGVyIHRoZSANCj4+bWVldGluZykuIExldCB1cyBzdGFydCBieSB0aGFua2luZyBBZHJp
YW4gKGFzIEFEPyBmb3JtZXIgUENFIGNvLWNoYWlyPw0KPj5hdXRob3Igb2YuLi4gOy0pICkgZm9y
IGJyaW5naW5nIHRoZSBQQ0UtYXNzb2NpYXRlZCB2b2NhYnVsYXJ5IHRvIGEgDQo+PmNvbW1vbiB1
bmRlcnN0YW5kaW5nLg0KPj4NCj4+QWN0dWFsbHkgbXkgY29uY2VybiBpcyBzdXN0YWluZWQgYnkg
MiBwb2ludHM6DQo+Pg0KPj4xLSBUaGUgc2NvcGUgb2YgdGhlIGRyYWZ0IGlzIGFib3V0IGdpdmlu
ZyBjb250cm9sIG9mIHRoZSByb3V0aW5nIA0KPj5vYmplY3RpdmUgZnVuY3Rpb24gdG8gdGhlIGNs
aWVudCBub2RlIGZhY2luZyBhIHRyYW5zcG9ydCBsYXllci4gSSBzZWUgDQo+PmFscmVhZHkgc2V2
ZXJhbCBleGlzdGluZyBzb2x1dGlvbiB0byBhY2hpZXZlIGl0Og0KPj4tIGEgUENFUCByZXF1ZXN0
IGZyb20gdGhlIHNpZ25hbGluZyBoZWFkIG5vZGUgaXMgYW4gb3B0aW9uICh3aGljaCBpcyANCj4+
YXNzb2NpYXRlZCB0byB0aGUgYWR2ZXJ0aXNlbWVudCBvZiB0aGUgc3VwcG9ydGVkIG9iamVjdGl2
ZXMgaW4gUENFUCk7DQo+Pi0gYnVpbGRpbmcgSUdQIGFkamFjZW5jaWVzIGJldHdlZW4gY2xpZW50
IGFuZCB0cmFuc3BvcnQgZWRnZSBub2RlcyANCj4+KGEuay5hLiAiYm9yZGVyIG1vZGVsIikgaXMg
YW5vdGhlciBvbmUuDQo+PkluIHRoaXMgY29udGV4dCwgaXQgZG8gbm90IHRoaW5rIGV4dGVuZGlu
ZyBSU1ZQLVRFIGZvciB0aGlzIGtpbmQgb2YgDQo+PmFwcGxpY2F0aW9uIGlzIHdvcnRoIHRoZSBl
ZmZvcnQsIHNpbmNlIHRoZSByZXF1aXJlbWVudCBjYW4gYWxyZWFkeSBiZSANCj4+YWRkcmVzc2Vk
Lg0KPg0KPkFzIEkgdW5kZXJzdGFuZCBpdCwgaW4gdGhlIG9wdGljYWwgYW5kIE9UTiBjYXNlcywg
dGhlIGJvcmRlciANCj5tb2RlbCB3b3VsZCBub3QgYmUgcG9wdWxhciBhcyBpbiBtYW55IG9yZ2Fu
aXphdGlvbnMgdGhpcyANCj5jcm9zc2VzIHBvbGl0aWNhbCBib3VuZGFyaWVzLg0KPg0KPlRoZSBw
b2ludCBvZiB0aGUgZHJhZnQgaXMgdG8ga2VlcCB0aGUgVU5JIGltcGxlbWVudGF0aW9uIA0KPnNp
bXBsZSBhbmQgbm90IHJlcXVpcmUgYSBQQ0VQIG9uIHRoZSB1bmktYyBvciBuZWNlc3NhcmlseSBv
biANCj50aGUgdW5pLW4uICBXZSB3aWxsIGtlZXAgdGhlIGZvcm1hdCBhbGlnbmVkIHNvIGlmIHRo
ZSBVTkktTiANCj5uZWVkcyB0byBtYWtlIGEgcmVxdWVzdCBvZiBhIFBDUywgaXQgY2FuIGRvIHNv
IHJhdGhlciBzaW1wbHkuDQo+Pg0KPj4yLSBUaGVyZSBhcmUgY2FzZXMgd2hlbiBwcmV2aW91cyBv
cHRpb25zIGFyZSBydWxlZCBvdXQgb2YgYSBnaXZlbiANCj4+ZGVwbG95bWVudC4gSSBkbyBiZWxp
ZXZlIHRoYXQgaXQgaXMgbm90IHNpbXBseSBkdWUgdG8gcHJvdG9jb2wgDQo+PmV4Y2x1c2lvbiwg
YnV0IHJhdGhlciB0byB0aGUgZmFjdCB0aGF0IHRoZSBTUCB3YW50cyB0cmFuc3BvcnQgcm91dGlu
ZyANCj4+ZGVjaXNpb25zIHRvIHJlbWFpbiBlbnRpcmVseSB3aXRoaW4gdGhlIHRyYW5zcG9ydCBu
ZXR3b3JrIChpbiANCj5vcmRlciB0byANCj4+ZnVsbHkgbGVhdmUgdGhlIHJvdXRpbmcgcG9saWN5
IGluIHRoZSBoYW5kcyBvZiBwZW9wbGUgZG9pbmcgdGhlIGxheWVyIA0KPj5kaW1lbnNpb25pbmcp
LiBUaHVzLCBJIGZlZWwgdGhpcyB0cmFkZS1vZmYgaW4gcGF0aCBzZWxlY3Rpb24gDQo+dHVuaW5n
IGlzIA0KPj5yYXRoZXIgdW5saWtlbHkgdG8gaGFwcGVuIGFuZCBJIGZlYXIgd2UgbWF5IGJlIHRh
bGtpbmcgYWJvdXQgUlNWUC1URSANCj4+b3Zlci1lbmdpbmVlcmluZyBoZXJlLg0KPg0KPlRoZSBp
ZGVhIGlzIHNpbXBseSB0byBhbGxvdyB0aGUgY2xpZW50IHRvIGV4cHJlc3MgaXRzIA0KPm5lZWRz
L3dpc2hlcy4gIFRoZSBVTkktTiByZW1haW5zIGluIGNvbnRyb2wuICBCeSBwb2xpY3kgaXQgY2Fu
IA0KPnVzZSB0aGUgb2JqZWN0aXZlIGZ1bmN0aW9uIG9yIG5vdC4gIEZ1cnRoZXIgaWYgaXQgZG9l
cyB1c2UgdGhlIA0KPm9iamVjdGl2ZSBmdW5jdGlvbiBhbmQgZmFpbHMgdG8gZmluZCBhIHBhdGgg
aXQgY2FuIGVpdGhlciBzYXkgDQo+dGhhdCB0aGVyZSB3YXMgbm8gcGF0aCBvciBpdCBwcm9jZWVk
IHRvIHNldHVwIHdoYXQgaXQgY2FuLg0KPg0KPj4oVGhhdCBpcyBhbHNvIHdoeSBJIHByZWZlcnJl
ZCB0byBjb25zaWRlciB5b3VyIEktRHMgc2VwYXJhdGVseSBkdXJpbmcgDQo+PnRoZSBDQ0FNUCBt
ZWV0aW5nLikNCj4NCj5BZ3JlZWQuICBJIHdpbGwgYXNrIGZvciBzZXBhcmF0ZSBzbG90cy4gIFRo
ZSBkaXNjdXNzaW9uIGF0IHRoZSANCj5lbmQgd2FzIHJhdGhlciBkaXNqb2ludGVkLg0KPg0KPj4N
Cj4+SG93ZXZlciwgbXkgY29tbWVudHMgYXJlIG1vc3RseSByZWxhdGVkIHRvIHRoZSBjbGllbnQv
dHJhbnNwb3J0IA0KPj5yZWxhdGlvbnNoaXAuIElmIHRoZSBJLUQgaXMgZXh0ZW5kZWQgdG8gY292
ZXIgbW9yZSB1c2UgY2FzZXMgDQo+d2l0aCB3aWRlciANCj4+c2NvcGVzIChBZHJpYW4gaGFzIG1h
ZGUgaW50ZXJlc3Rpbmcgc3VnZ2VzdGlvbnMpLCB0dXJuaW5nIHRoZSBvdmVybGF5IA0KPj5pbnRl
cmNvbm5lY3Rpb24gaW50byBvbmUgYW1vbmcgYSBsb25nZXIgbGlzdCwgdGhlbiBteSANCj5jb25j
bHVzaW9uIG1heSBiZSANCj4+ZGlmZmVyZW50Lg0KPg0KPkknbSBoYXBweSB0byB3aWRlbiB0aGUg
c2NvcGUgaW4gdGhpcyB3YXkuDQo+DQo+Li4uR2VvcmdlDQo+DQo+PlJlZ2FyZHMsDQo+Pg0KPj5K
dWxpZW4NCj4+DQo+Pg0KPj5MZSAxMS8wOS8yMDEyIDIxOjI4LCBHZW9yZ2UgU3dhbGxvdyAoc3dh
bGxvdykgYSDDqWNyaXQgOg0KPj4+IEp1bGllbiAtDQo+Pj4NCj4+PiBSZWFkaW5nIHRoZSBDQ0FN
UCBub3RlcyAod2hpY2ggY2FwdHVyZSBsaXR0bGUgb2YgdGhlIGFjdHVhbA0KPj4+IGRpc2N1c3Np
b24pIEkgc2VlIHRoYXQgdGhlcmUgbWF5IGhhdmUgYmVlbiBhIHBlcmNlcHRpb24gaW4gdGhlIHJv
b20gDQo+Pj4gdGhhdCBQQ0UgZnVuY3Rpb25hbGl0eSBhdCB0aGUgVU5JLU4gd2FzIGFzc3VtZWQg
KGFjdHVhbCBvciBwcm94eSkuDQo+Pj4NCj4+PiBUaGlzIGlzIG5vdCB0aGUgY2FzZS4gVGhlIHJl
YXNvbiBmb3Igb3VyIGRyYWZ0IGlzIHRoYXQgd2l0aCANCj50aGUgVU5JLCANCj4+PiBtdWNoIG9m
IHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQgcmVzaWRlcyBhdCB0aGUgaGVhZGVuZCBpcyANCj5tb3Zl
ZCB0byB0aGUgDQo+Pj4gVU5JLU4uIFNvIHRoZSBVTkktQyBuZWVkcyBhIHdheSB0byBleHByZXNz
IGFuIG9iamVjdGl2ZSANCj5mdW5jdGlvbiBldmVuIA0KPj4+IGlmIHRoZXJlIGlzIG5vIFBDRS4N
Cj4+Pg0KPj4+IE9wZXJhdGlvbmFsbHkgaXQgc2VlbXMgYnVyZGVuc29tZSB0byByZXF1aXJlIGEg
UENFUCBhdCB0aGUgDQo+VU5JLUMgYW5kIA0KPj4+IGEgUENFUCBhdCB0aGUgVU5JLU4sIHdoZW4g
YWxsIHRoYXQgaXMgYmVpbmcgZG9uZSBpcyBlbmFibGluZyB0aGUgDQo+Pj4gVU5JLU4gdG8gcGVy
Zm9ybSB3aGF0IHRoZSBjbGllbnQgd291bGQgZG8gaWYgaXQgd2VyZSANCj5jb25uZWN0ZWQgdG8g
dGhlIA0KPj4+IG5ldHdvcmsgdmlhIGEgbm9ybWFsIGxpbmsuDQo+Pj4NCj4+PiBEbyB5b3Ugc3Rp
bGwgb2JqZWN0IHRvIHRoZSBkcmFmdD8NCj4+Pg0KPj4+IFRoYW5rcywNCj4+Pg0KPj4+IMWgR2Vv
cmdlDQo+Pg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPkNDQU1QIG1haWxpbmcgbGlzdA0KPkNDQU1QQGlldGYub3JnDQo+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPg0KPg0KPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Q0NBTVAgbWFpbGluZyBsaXN0DQo+
Q0NBTVBAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj
YW1wDQo+

From dieter.beller@alcatel-lucent.com  Tue Sep 18 02:54: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 0B51721F85C0 for ; Tue, 18 Sep 2012 02:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.791
X-Spam-Level: 
X-Spam-Status: No, score=-8.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3+DVeClVHW2 for ; Tue, 18 Sep 2012 02:54:07 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 888C721F8744 for ; Tue, 18 Sep 2012 02:54:05 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8I9mL2B014713 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Sep 2012 11:53:55 +0200
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 18 Sep 2012 11:53:15 +0200
Received: from [135.244.34.90] (135.5.27.18) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 18 Sep 2012 05:53:12 -0400
Message-ID: <50584485.8050100@alcatel-lucent.com>
Date: Tue, 18 Sep 2012 11:53:09 +0200
From: Dieter Beller 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Daniele Ceccarelli 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> 
In-Reply-To: 
X-SubSwitch: [CCAMP]; [CCAMP] 
Content-Type: multipart/related; boundary="------------030404030103080906030607"
X-Originating-IP: [135.5.27.18]
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 09:54:08 -0000

--------------030404030103080906030607
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Daniele, all,

    

    +1

    

    I fully agree with your comments/clarifications.

    

    

    Thanks,

    Dieter

    

    
On 18.09.2012 09:19, Daniele Ceccarelli
      wrote:

    

    

      
+0.5

Fully agree on the second part of your statement. At the time of RFC4208 the UNI allowed the exchange of signaling and routing messages. Now that we're defining also the E-NNI i would prefer to have:

- UNI: signaling only
- E-NNI: signaling AND routing (i would prefer to call it reachability rather than routing, because it is not a topology info)

That said, i think that objective function (despite the correct comments from Julien) is not routing but a constraint. The ingress node of the overlay network asks the ingress node of the core network for a path computation with given constraints. 

Viceversa in the case of E-NNI if the objective function was exported to the overlay network as a "property" of a virtual link, then i agree it was routing (reachability) information.

Cheers,
Daniele



      

        
-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 
On Behalf Of Gert Grammel
Sent: lunedì 17 settembre 2012 23.22
To: George Swallow (swallow); Julien Meuric
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi George,

The objective function is in the end a routing information. 
Mixing routing and signaling in one protocol is something I 
don't feel comfortable with.

In other words, if routing is needed between client and 
server, UNI is the wrong choice. ENNI should be considered 
instead and Draft-beeram-ccamp-gmpls-enni would be a good 
starting point.


Gert



________________________________________
From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
Sent: Monday, September 17, 2012 12:19:21 PM
To: Julien Meuric
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <julien.meuric@orange.com> wrote:



        

          
Hi George.

Sorry for the late response. You are right: the minutes are 


        

        
not enough 


        

          
to trace the full discussion (which we also resumed right after the 
meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
author of... ;-) ) for bringing the PCE-associated vocabulary to a 
common understanding.

Actually my concern is sustained by 2 points:

1- The scope of the draft is about giving control of the routing 
objective function to the client node facing a transport layer. I see 
already several existing solution to achieve it:
- a PCEP request from the signaling head node is an option (which is 
associated to the advertisement of the supported objectives in PCEP);
- building IGP adjacencies between client and transport edge nodes 
(a.k.a. "border model") is another one.
In this context, it do not think extending RSVP-TE for this kind of 
application is worth the effort, since the requirement can already be 
addressed.


        

        
As I understand it, in the optical and OTN cases, the border 
model would not be popular as in many organizations this 
crosses political boundaries.

The point of the draft is to keep the UNI implementation 
simple and not require a PCEP on the uni-c or necessarily on 
the uni-n.  We will keep the format aligned so if the UNI-N 
needs to make a request of a PCS, it can do so rather simply.


        

          
2- There are cases when previous options are ruled out of a given 
deployment. I do believe that it is not simply due to protocol 
exclusion, but rather to the fact that the SP wants transport routing 
decisions to remain entirely within the transport network (in 


        

        
order to 


        

          
fully leave the routing policy in the hands of people doing the layer 
dimensioning). Thus, I feel this trade-off in path selection 


        

        
tuning is 


        

          
rather unlikely to happen and I fear we may be talking about RSVP-TE 
over-engineering here.


        

        
The idea is simply to allow the client to express its 
needs/wishes.  The UNI-N remains in control.  By policy it can 
use the objective function or not.  Further if it does use the 
objective function and fails to find a path it can either say 
that there was no path or it proceed to setup what it can.



        

          
(That is also why I preferred to consider your I-Ds separately during 
the CCAMP meeting.)


        

        
Agreed.  I will ask for separate slots.  The discussion at the 
end was rather disjointed.



        

          
However, my comments are mostly related to the client/transport 
relationship. If the I-D is extended to cover more use cases 


        

        
with wider 


        

          
scopes (Adrian has made interesting suggestions), turning the overlay 
interconnection into one among a longer list, then my 


        

        
conclusion may be 


        

          
different.


        

        
I'm happy to widen the scope in this way.

...George



        

          
Regards,

Julien


Le 11/09/2012 21:28, George Swallow (swallow) a écrit :


          

            
Julien -

Reading the CCAMP notes (which capture little of the actual
discussion) I see that there may have been a perception in the room 
that PCE functionality at the UNI-N was assumed (actual or proxy).

This is not the case. The reason for our draft is that with 


          

        

        
the UNI, 


        

          

            
much of the functionality that resides at the headend is 


          

        

        
moved to the 


        

          

            
UNI-N. So the UNI-C needs a way to express an objective 


          

        

        
function even 


        

          

            
if there is no PCE.

Operationally it seems burdensome to require a PCEP at the 


          

        

        
UNI-C and 


        

          

            
a PCEP at the UNI-N, when all that is being done is enabling the 
UNI-N to perform what the client would do if it were 


          

        

        
connected to the 


        

          

            
network via a normal link.

Do you still object to the draft?

Thanks,

Å George


          

          



        

        
_______________________________________________
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


    

    

    
-- 

      
      

        

          

            
            
            

            

              
DIETER




                      BELLER

                

                  

                    
 ALCATEL-LUCENT

                          DEUTSCHLAND AG

                        PROJECT MANAGER ASON/GMPLS
                          CONTROL PLANE

                          NETWORKS GROUP, OPTICS DIVISION

                          TERRESTRIAL OPTICS UNIT

                          

                          Lorenzstrasse 10

                          70435 Stuttgart, Germany

                        T: +49 711 821 43125

                          M: +49 175 7266874

                        Dieter.Beller@alcatel-lucent.com

                            

                          Alcatel-Lucent
                            Deutschland AG

                            Domicile of the Company: Stuttgart · Local
                            Court Stuttgart HRB 4026

                            Chairman of the Supervisory Board: Michael
                            Oppenhoff

                            Board of Management: Wilhelm Dresselhaus
                            (Chairman) · Hans-Jörg Daub ·

                          Dr. Rainer Fechner ·
                            Andreas Gehe

                            

                          This e-mail and its
                            attachments, if any, may contain
                            confidential information.

                            If you have received this e-mail in error,
                            please notify us and delete or destroy the

                            e-mail and its attachments, if any,
                            immediately. If you have received this
                            e-mail in

                            error, you must not forward or make use of
                            the e-mail and its attachments, if any.

                    

                  

                

              

            

          

        

      

    

  


--------------030404030103080906030607
Content-Type: image/jpeg; name="Corporate-sig-logo.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline; filename="Corporate-sig-logo.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA
Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC
AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG
AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL
EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh
sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5
OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX
2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx
CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW
N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI
mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P
pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09
bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS
t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO
xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q
XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ
7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN
KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3
PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT
51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7
jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1
+i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K
Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp
jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i
yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d
L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R
1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ
PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN
t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0
E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo
JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox
q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv
utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr
KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD
bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y
8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm
1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr
5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3
10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH
yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW
YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq
0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t
fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9
5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti
z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn
ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H
urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N
PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf
4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R
HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR
Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh
7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f
If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd
WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D
2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q
iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox
c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0
6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f
Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z
9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c
FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F
/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0
w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu
LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK
KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI
pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o
NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3
vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c
Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi
8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY
8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/
EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V
MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl
pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w
8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN
z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63
rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3
FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP
2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i
fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/
g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1
XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70
m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p
4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np
T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY
pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo
6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV
BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x
HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3
b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U
49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN
25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi
apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h
/wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN
WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697
917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r
3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X
uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/
ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A
N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z
--------------030404030103080906030607--

From julien.meuric@orange.com  Tue Sep 18 03:32: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 CF06021F84F3 for ; Tue, 18 Sep 2012 03:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iWvVrwjCcqq for ; Tue, 18 Sep 2012 03:32:51 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29021F841D for ; Tue, 18 Sep 2012 03:32:51 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6972E5D89D9; Tue, 18 Sep 2012 12:32:49 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5AD975D894A; Tue, 18 Sep 2012 12:32:49 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Sep 2012 12:32:48 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Sep 2012 12:32:48 +0200
Message-ID: <50584DCE.5090407@orange.com>
Date: Tue, 18 Sep 2012 12:32:46 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniele Ceccarelli 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Sep 2012 10:32:48.0882 (UTC) FILETIME=[F303DD20:01CD9588]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 10:32:51 -0000

Hi Daniele.

That is a good idea to bring back this issue we did not have time to 
discuss in details in Vancouver.

As far as I used to understand:
- UNI stands for User-to-Network, which refers to client-server 
relationship;
- NNI stands for Network-to-Network, which refers to inter-domain 
relationship within a common technology.

I believe the protocols we use on those interfaces is orthogonal to 
their type. E.g. one can do signaling only over an E-NNI; building an 
IGP-TE adjacency on the tributary links (UNI) of my WDM network does not 
transmute my UNI into an NNI. Boundaries are not defined with respect to 
control protocols, in CCAMP we put protocols between network nodes, 
including boundaries, we do not change boundary names...
That is also why I prefer to use accurate phrases such as "signaling 
protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms, which 
are sometimes too loose for a protocol specification context like CCAMP.

Cheers,

Julien


On 09/18/2012 09:19, Daniele Ceccarelli wrote:
> Fully agree on the second part of your statement. At the time of RFC4208 the UNI allowed the exchange of signaling and routing messages. Now that we're defining also the E-NNI i would prefer to have:
>
> - UNI: signaling only
> - E-NNI: signaling AND routing (i would prefer to call it reachability rather than routing, because it is not a topology info)



From daniele.ceccarelli@ericsson.com  Tue Sep 18 05:12: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 6FA0F21E80BF for ; Tue, 18 Sep 2012 05:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Nq582Wc8XIz for ; Tue, 18 Sep 2012 05:12:52 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7616E21F8459 for ; Tue, 18 Sep 2012 05:12:52 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-54-5058653f3f02
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 1C.01.11467.F3568505; Tue, 18 Sep 2012 14:12:48 +0200 (CEST)
Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 18 Sep 2012 14:12:47 +0200
From: Daniele Ceccarelli 
To: Julien Meuric 
Date: Tue, 18 Sep 2012 14:12:45 +0200
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2ViPOhJMkJXyGYTMStcjFZG+YUXAAC1BaQ
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  <50584DCE.5090407@orange.com>
In-Reply-To: <50584DCE.5090407@orange.com>
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: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvra5DakSAwdnLTBZP5txgsViyaxmL xZ/Tf5ksbk9pYnRg8ZjyeyOrx5IlP5k8rjddZfdoeXaSLYAlissmJTUnsyy1SN8ugSvj4Uqj gn6Rij2vV7M0MG4T6GLk5JAQMJE4sXAiE4QtJnHh3nq2LkYuDiGBU4wS8w6uYYdwFjBK3Gl8 BVTFwcEmYCXx5JAPSIOIgI7E+fdn2EFsZoEaieuzzrKC2CwCqhI3Fk0BGyosoCvxc38nE0S9 nsTj3UvYIWwjiVf3HrKA2LwC4RK7Th9iglv85EA7M0iCU0BL4vvR7YwgNqOArMSE3YsYIZaJ S9x6Mh/qagGJJXvOM0PYohIvH/9jhaiXkfi16RsrRL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJ ywRGsVlIxs5C0jILScssJC0LGFlWMQrnJmbmpJcb6qUWZSYXF+fn6RWnbmIExtjBLb91dzCe OidyiFGag0VJnJcrab+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYDgZqlEV0TNO59TGZb dSpznbjXy4TrtXICv4/E7WCouPt5mvMN9zDFm6qzVx68tZpHScQ4h6/dsWGXZXHdpJwey/fL z7ter/g4e4mYyvt5NW92GuSxT5ktN89BSMBQnHn+FYX7bB8k5gVaf3746Mpcl5jpyRPehOl0 vRZ6pX/sSMqpSfys8nJKLMUZiYZazEXFiQDWoVyhfwIAAA==
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 12:12:53 -0000

Hi Julien,

Your argument is flawless, but if the only difference between UNI and NNI i=
s the relationship between the two domains is it worth defining two differe=
nt types of interface?

My attempt (a bit clumpy) was to associate to each type of interface a give=
n set of properties and functionalities. This also solves the problem of us=
ing unappropriate or not well defined language.
E.g.
- UNI: functionalies supported: A, B, C, -- Interface Properties: X, Y, Z
- E-NNI: functionalities supported: A, D, E -- Interface Properties: X, W

So that when you say UNI you automatically indentify certain properties and=
 functionalities and when you say E-NNI different ones (not necessarily ful=
ly disjoint...A and X, for example, are in common)

Cheers,
Daniele

>-----Original Message-----
>From: Julien Meuric [mailto:julien.meuric@orange.com]=20
>Sent: marted=EC 18 settembre 2012 12.33
>To: Daniele Ceccarelli
>Cc: Gert Grammel; George Swallow (swallow); ccamp@ietf.org
>Subject: Re: [CCAMP] Objective function draft
>
>Hi Daniele.
>
>That is a good idea to bring back this issue we did not have=20
>time to discuss in details in Vancouver.
>
>As far as I used to understand:
>- UNI stands for User-to-Network, which refers to=20
>client-server relationship;
>- NNI stands for Network-to-Network, which refers to=20
>inter-domain relationship within a common technology.
>
>I believe the protocols we use on those interfaces is=20
>orthogonal to their type. E.g. one can do signaling only over=20
>an E-NNI; building an IGP-TE adjacency on the tributary links=20
>(UNI) of my WDM network does not transmute my UNI into an NNI.=20
>Boundaries are not defined with respect to control protocols,=20
>in CCAMP we put protocols between network nodes, including=20
>boundaries, we do not change boundary names...
>That is also why I prefer to use accurate phrases such as=20
>"signaling protocol/RSVP-TE" and "IGP", rather than "UNI" or=20
>"NNI" acronyms, which are sometimes too loose for a protocol=20
>specification context like CCAMP.
>
>Cheers,
>
>Julien
>
>
>On 09/18/2012 09:19, Daniele Ceccarelli wrote:
>> Fully agree on the second part of your statement. At the=20
>time of RFC4208 the UNI allowed the exchange of signaling and=20
>routing messages. Now that we're defining also the E-NNI i=20
>would prefer to have:
>>
>> - UNI: signaling only
>> - E-NNI: signaling AND routing (i would prefer to call it=20
>reachability=20
>> rather than routing, because it is not a topology info)
>
>
>=

From julien.meuric@orange.com  Tue Sep 18 05:27: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 D03B521F8770 for ; Tue, 18 Sep 2012 05:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpW8PJeZIfZp for ; Tue, 18 Sep 2012 05:27:26 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id C374D21F8735 for ; Tue, 18 Sep 2012 05:27:25 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F690410E49; Tue, 18 Sep 2012 14:27:24 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 856EE4110D6; Tue, 18 Sep 2012 14:27:24 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Sep 2012 14:27:24 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Sep 2012 14:27:22 +0200
Message-ID: <505868A4.6020802@orange.com>
Date: Tue, 18 Sep 2012 14:27:16 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Gert Grammel 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>
In-Reply-To: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 18 Sep 2012 12:27:23.0122 (UTC) FILETIME=[F461A520:01CD9598]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 12:27:26 -0000

Hi Gert.

As Daniele has just said, almost all the information in an inter-layer 
signaling can be seen as input/constraints to the routing process. The 
IGP-TE brings some link-state information to some network nodes so as to 
achieve path computation; the result is used in the signaling protocol, 
on a per LSP basis. I would said that:
- the routing task involves both the IGP and the signaling protocol, 
especially in case of loose hops or crankbacks;
- the objective function only makes sense per LSP, which allows to 
consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to 
IGPs or LMP).

I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some 
great confusion in the vocabulary: it is a superset of 
draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the 
ITU-T reference point. A possible option is just to avoid those terms 
and stick to protocols, namely RSVP-TE and IGP-TE.

Regards,

Julien


Le 17/09/2012 23:22, Gert Grammel a écrit :
> Hi George,
>
> The objective function is in the end a routing information. Mixing routing and signaling in one protocol is something I don't feel comfortable with.
>
> In other words, if routing is needed between client and server, UNI is the wrong choice. ENNI should be considered instead and
> Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>
>
> Gert
>
>
>
> ________________________________________
> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>
> Hi Julien -
>
> On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>
>> Hi George.
>>
>> Sorry for the late response. You are right: the minutes are not enough
>> to trace the full discussion (which we also resumed right after the
>> meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>> author of... ;-) ) for bringing the PCE-associated vocabulary to a
>> common understanding.
>>
>> Actually my concern is sustained by 2 points:
>>
>> 1- The scope of the draft is about giving control of the routing
>> objective function to the client node facing a transport layer. I see
>> already several existing solution to achieve it:
>> - a PCEP request from the signaling head node is an option (which is
>> associated to the advertisement of the supported objectives in PCEP);
>> - building IGP adjacencies between client and transport edge nodes
>> (a.k.a. "border model") is another one.
>> In this context, it do not think extending RSVP-TE for this kind of
>> application is worth the effort, since the requirement can already be
>> addressed.
> As I understand it, in the optical and OTN cases, the border model would
> not be popular
> as in many organizations this crosses political boundaries.
>
> The point of the draft is to keep the UNI implementation simple and not
> require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
> format aligned so if the UNI-N needs to make a request of a PCS, it can do
> so rather simply.
>> 2- There are cases when previous options are ruled out of a given
>> deployment. I do believe that it is not simply due to protocol
>> exclusion, but rather to the fact that the SP wants transport routing
>> decisions to remain entirely within the transport network (in order to
>> fully leave the routing policy in the hands of people doing the layer
>> dimensioning). Thus, I feel this trade-off in path selection tuning is
>> rather unlikely to happen and I fear we may be talking about RSVP-TE
>> over-engineering here.
> The idea is simply to allow the client to express its needs/wishes.  The
> UNI-N remains in control.  By policy it can use the objective function or
> not.  Further if it does use the objective function and fails to find a
> path it can either say that there was no path or it
> proceed to setup what it can.
>
>> (That is also why I preferred to consider your
>> I-Ds separately during the CCAMP meeting.)
> Agreed.  I will ask for separate slots.  The discussion at the end was
> rather disjointed.
>
>> However, my comments are mostly related to the client/transport
>> relationship. If the I-D is extended to cover more use cases with wider
>> scopes (Adrian has made interesting suggestions), turning the overlay
>> interconnection into one among a longer list, then my conclusion may be
>> different.
> I'm happy to widen the scope in this way.
>
> ...George
>
>> Regards,
>>
>> Julien
>>
>>
>> Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
>>> Julien -
>>>
>>> Reading the CCAMP notes (which capture little of the actual
>>> discussion) I see that there may have been a perception in the room
>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>
>>> This is not the case. The reason for our draft is that with the UNI,
>>> much of the functionality that resides at the headend is moved to the
>>> UNI-N. So the UNI-C needs a way to express an objective function even
>>> if there is no PCE.
>>>
>>> Operationally it seems burdensome to require a PCEP at the UNI-C and a
>>> PCEP at the UNI-N, when all that is being done is enabling the UNI-N
>>> to perform what the client would do if it were connected to the
>>> network via a normal link.
>>>
>>> Do you still object to the draft?
>>>
>>> Thanks,
>>>
>>> ŠGeorge
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
>


From jvasseur@cisco.com  Tue Sep 18 05:29: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 A464221E80C6 for ; Tue, 18 Sep 2012 05:29:40 -0700 (PDT)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5skaflUitwB4 for ; Tue, 18 Sep 2012 05:29:39 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9221E80CC for ; Tue, 18 Sep 2012 05:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6143; q=dns/txt; s=iport; t=1347971379; x=1349180979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iozB3h6iCNlUH2ecIyOw3IaFEW1JF94otARw1ybVQ3U=; b=LdBwNmMO7VeHl6ZSd8gQavs5H//AIEI3tM6XT0KLE9wv+h23YMAW7pci gTGmk61Bdokuje86Ta+3rcsILeqpLMDBczPJygmVYWzKQmWVGuYPaUQNA jq3XX20rFRMhh2PDJwA4nIPEd7IFrTxAZ4K1DE4+40N2yDu3vKJm6TR0N Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EACBoWFCtJV2d/2dsb2JhbABFvDOBB4IgAQEBAwEBAQEPAVsEBwULAgEIFQMuJwslAgQOBRsHh1gGC5l7oDAEiyGGCGADkjGDMY44gWmCZg
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122502607"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 18 Sep 2012 12:29:38 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8ICTc9E006603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 12:29:38 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.209]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 07:29:37 -0500
From: "JP Vasseur (jvasseur)" 
To: Julien Meuric 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlZjwJMkJXyGYTMStcjFZG+YUXJeQB1f0
Date: Tue, 18 Sep 2012 12:29:37 +0000
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>
In-Reply-To: <505868A4.6020802@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004
x-tm-as-result: No--59.681300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 12:29:40 -0000

I an completely sharing Julien's point of view.=20

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric"  wrot=
e:

> Hi Gert.
>=20
> As Daniele has just said, almost all the information in an inter-layer si=
gnaling can be seen as input/constraints to the routing process. The IGP-TE=
 brings some link-state information to some network nodes so as to achieve =
path computation; the result is used in the signaling protocol, on a per LS=
P basis. I would said that:
> - the routing task involves both the IGP and the signaling protocol, espe=
cially in case of loose hops or crankbacks;
> - the objective function only makes sense per LSP, which allows to consid=
er it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP)=
.
>=20
> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some g=
reat confusion in the vocabulary: it is a superset of draft-beeram-ccamp-gm=
pls-_uni_-bcp while removing the pointer to the ITU-T reference point. A po=
ssible option is just to avoid those terms and stick to protocols, namely R=
SVP-TE and IGP-TE.
>=20
> Regards,
>=20
> Julien
>=20
>=20
> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
>> Hi George,
>>=20
>> The objective function is in the end a routing information. Mixing routi=
ng and signaling in one protocol is something I don't feel comfortable with=
.
>>=20
>> In other words, if routing is needed between client and server, UNI is t=
he wrong choice. ENNI should be considered instead and
>> Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>>=20
>>=20
>> Gert
>>=20
>>=20
>>=20
>> ________________________________________
>> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>>=20
>> Hi Julien -
>>=20
>> On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>>=20
>>> Hi George.
>>>=20
>>> Sorry for the late response. You are right: the minutes are not enough
>>> to trace the full discussion (which we also resumed right after the
>>> meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>>> author of... ;-) ) for bringing the PCE-associated vocabulary to a
>>> common understanding.
>>>=20
>>> Actually my concern is sustained by 2 points:
>>>=20
>>> 1- The scope of the draft is about giving control of the routing
>>> objective function to the client node facing a transport layer. I see
>>> already several existing solution to achieve it:
>>> - a PCEP request from the signaling head node is an option (which is
>>> associated to the advertisement of the supported objectives in PCEP);
>>> - building IGP adjacencies between client and transport edge nodes
>>> (a.k.a. "border model") is another one.
>>> In this context, it do not think extending RSVP-TE for this kind of
>>> application is worth the effort, since the requirement can already be
>>> addressed.
>> As I understand it, in the optical and OTN cases, the border model would
>> not be popular
>> as in many organizations this crosses political boundaries.
>>=20
>> The point of the draft is to keep the UNI implementation simple and not
>> require a PCEP on the uni-c or necessarily on the uni-n.  We will keep t=
he
>> format aligned so if the UNI-N needs to make a request of a PCS, it can =
do
>> so rather simply.
>>> 2- There are cases when previous options are ruled out of a given
>>> deployment. I do believe that it is not simply due to protocol
>>> exclusion, but rather to the fact that the SP wants transport routing
>>> decisions to remain entirely within the transport network (in order to
>>> fully leave the routing policy in the hands of people doing the layer
>>> dimensioning). Thus, I feel this trade-off in path selection tuning is
>>> rather unlikely to happen and I fear we may be talking about RSVP-TE
>>> over-engineering here.
>> The idea is simply to allow the client to express its needs/wishes.  The
>> UNI-N remains in control.  By policy it can use the objective function o=
r
>> not.  Further if it does use the objective function and fails to find a
>> path it can either say that there was no path or it
>> proceed to setup what it can.
>>=20
>>> (That is also why I preferred to consider your
>>> I-Ds separately during the CCAMP meeting.)
>> Agreed.  I will ask for separate slots.  The discussion at the end was
>> rather disjointed.
>>=20
>>> However, my comments are mostly related to the client/transport
>>> relationship. If the I-D is extended to cover more use cases with wider
>>> scopes (Adrian has made interesting suggestions), turning the overlay
>>> interconnection into one among a longer list, then my conclusion may be
>>> different.
>> I'm happy to widen the scope in this way.
>>=20
>> ...George
>>=20
>>> Regards,
>>>=20
>>> Julien
>>>=20
>>>=20
>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>>> Julien -
>>>>=20
>>>> Reading the CCAMP notes (which capture little of the actual
>>>> discussion) I see that there may have been a perception in the room
>>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>>=20
>>>> This is not the case. The reason for our draft is that with the UNI,
>>>> much of the functionality that resides at the headend is moved to the
>>>> UNI-N. So the UNI-C needs a way to express an objective function even
>>>> if there is no PCE.
>>>>=20
>>>> Operationally it seems burdensome to require a PCEP at the UNI-C and a
>>>> PCEP at the UNI-N, when all that is being done is enabling the UNI-N
>>>> to perform what the client would do if it were connected to the
>>>> network via a normal link.
>>>>=20
>>>> Do you still object to the draft?
>>>>=20
>>>> Thanks,
>>>>=20
>>>> =8AGeorge
>>>=20
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>=20
>>=20
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From sergio.belotti@alcatel-lucent.com  Tue Sep 18 06:23: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 DF22921F8743 for ; Tue, 18 Sep 2012 06:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.248
X-Spam-Level: 
X-Spam-Status: No, score=-9.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beLGLGsaykMS for ; Tue, 18 Sep 2012 06:23:07 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id BC68421F8713 for ; Tue, 18 Sep 2012 06:23:06 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8IDN0cC032472 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 18 Sep 2012 15:23:03 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 18 Sep 2012 15:22:38 +0200
From: "BELOTTI, SERGIO (SERGIO)" 
To: "Beller, Dieter (Dieter)" , Daniele Ceccarelli 
Date: Tue, 18 Sep 2012 15:22:32 +0200
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2Vg5T7tWNWOiYiTmm0XNo3D+zmTwAHPgZw
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  <50584485.8050100@alcatel-lucent.com>
In-Reply-To: <50584485.8050100@alcatel-lucent.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: it-IT, en-US
Content-Type: multipart/related; boundary="_004_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_"; type="multipart/alternative"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: "ccamp@ietf.org" 
Subject: [CCAMP] R:  Objective function draft
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, 18 Sep 2012 13:23:09 -0000

--_004_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_
Content-Type: multipart/alternative;
	boundary="_000_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_"

--_000_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

KzENCg0KRnVsbHkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzIHRvby4NCg0KVGhhbmtzDQoNClNl
cmdpbw0KDQpCZWxvdHRpIFNlcmdpbyAtIFN5c3RlbSBBcmNoaXRlY3QNCkFMQ0FURUwtTFVDRU5U
ICBPcHRpY3MgRGl2aXNpb24NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEYTog
Y2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIFBl
ciBjb250byBkaSBEaWV0ZXIgQmVsbGVyDQpJbnZpYXRvOiBtYXJ0ZWTDrCAxOCBzZXR0ZW1icmUg
MjAxMiAxMS41Mw0KQTogRGFuaWVsZSBDZWNjYXJlbGxpDQpDYzogY2NhbXBAaWV0Zi5vcmcNCk9n
Z2V0dG86IFJlOiBbQ0NBTVBdIE9iamVjdGl2ZSBmdW5jdGlvbiBkcmFmdA0KDQpIaSBEYW5pZWxl
LCBhbGwsDQoNCisxDQoNCkkgZnVsbHkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzL2NsYXJpZmlj
YXRpb25zLg0KDQoNClRoYW5rcywNCkRpZXRlcg0KT24gMTguMDkuMjAxMiAwOToxOSwgRGFuaWVs
ZSBDZWNjYXJlbGxpIHdyb3RlOg0KDQorMC41DQoNCg0KDQpGdWxseSBhZ3JlZSBvbiB0aGUgc2Vj
b25kIHBhcnQgb2YgeW91ciBzdGF0ZW1lbnQuIEF0IHRoZSB0aW1lIG9mIFJGQzQyMDggdGhlIFVO
SSBhbGxvd2VkIHRoZSBleGNoYW5nZSBvZiBzaWduYWxpbmcgYW5kIHJvdXRpbmcgbWVzc2FnZXMu
IE5vdyB0aGF0IHdlJ3JlIGRlZmluaW5nIGFsc28gdGhlIEUtTk5JIGkgd291bGQgcHJlZmVyIHRv
IGhhdmU6DQoNCg0KDQotIFVOSTogc2lnbmFsaW5nIG9ubHkNCg0KLSBFLU5OSTogc2lnbmFsaW5n
IEFORCByb3V0aW5nIChpIHdvdWxkIHByZWZlciB0byBjYWxsIGl0IHJlYWNoYWJpbGl0eSByYXRo
ZXIgdGhhbiByb3V0aW5nLCBiZWNhdXNlIGl0IGlzIG5vdCBhIHRvcG9sb2d5IGluZm8pDQoNCg0K
DQpUaGF0IHNhaWQsIGkgdGhpbmsgdGhhdCBvYmplY3RpdmUgZnVuY3Rpb24gKGRlc3BpdGUgdGhl
IGNvcnJlY3QgY29tbWVudHMgZnJvbSBKdWxpZW4pIGlzIG5vdCByb3V0aW5nIGJ1dCBhIGNvbnN0
cmFpbnQuIFRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIG92ZXJsYXkgbmV0d29yayBhc2tzIHRoZSBp
bmdyZXNzIG5vZGUgb2YgdGhlIGNvcmUgbmV0d29yayBmb3IgYSBwYXRoIGNvbXB1dGF0aW9uIHdp
dGggZ2l2ZW4gY29uc3RyYWludHMuDQoNCg0KDQpWaWNldmVyc2EgaW4gdGhlIGNhc2Ugb2YgRS1O
TkkgaWYgdGhlIG9iamVjdGl2ZSBmdW5jdGlvbiB3YXMgZXhwb3J0ZWQgdG8gdGhlIG92ZXJsYXkg
bmV0d29yayBhcyBhICJwcm9wZXJ0eSIgb2YgYSB2aXJ0dWFsIGxpbmssIHRoZW4gaSBhZ3JlZSBp
dCB3YXMgcm91dGluZyAocmVhY2hhYmlsaXR5KSBpbmZvcm1hdGlvbi4NCg0KDQoNCkNoZWVycywN
Cg0KRGFuaWVsZQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogY2Nh
bXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0
bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXQ0KDQpPbiBCZWhhbGYgT2YgR2VydCBHcmFtbWVsDQoN
ClNlbnQ6IGx1bmVkw6wgMTcgc2V0dGVtYnJlIDIwMTIgMjMuMjINCg0KVG86IEdlb3JnZSBTd2Fs
bG93IChzd2FsbG93KTsgSnVsaWVuIE1ldXJpYw0KDQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRv
OmNjYW1wQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBPYmplY3RpdmUgZnVuY3Rp
b24gZHJhZnQNCg0KDQoNCkhpIEdlb3JnZSwNCg0KDQoNClRoZSBvYmplY3RpdmUgZnVuY3Rpb24g
aXMgaW4gdGhlIGVuZCBhIHJvdXRpbmcgaW5mb3JtYXRpb24uDQoNCk1peGluZyByb3V0aW5nIGFu
ZCBzaWduYWxpbmcgaW4gb25lIHByb3RvY29sIGlzIHNvbWV0aGluZyBJDQoNCmRvbid0IGZlZWwg
Y29tZm9ydGFibGUgd2l0aC4NCg0KDQoNCkluIG90aGVyIHdvcmRzLCBpZiByb3V0aW5nIGlzIG5l
ZWRlZCBiZXR3ZWVuIGNsaWVudCBhbmQNCg0Kc2VydmVyLCBVTkkgaXMgdGhlIHdyb25nIGNob2lj
ZS4gRU5OSSBzaG91bGQgYmUgY29uc2lkZXJlZA0KDQppbnN0ZWFkIGFuZCBEcmFmdC1iZWVyYW0t
Y2NhbXAtZ21wbHMtZW5uaSB3b3VsZCBiZSBhIGdvb2QNCg0Kc3RhcnRpbmcgcG9pbnQuDQoNCg0K
DQoNCg0KR2VydA0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQoNCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJv
dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdykNCg0K
U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTIgMTI6MTk6MjEgUE0NCg0KVG86IEp1bGll
biBNZXVyaWMNCg0KQ2M6IGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4NCg0K
U3ViamVjdDogUmU6IFtDQ0FNUF0gT2JqZWN0aXZlIGZ1bmN0aW9uIGRyYWZ0DQoNCg0KDQpIaSBK
dWxpZW4gLQ0KDQoNCg0KT24gOS8xNy8xMiA5OjM3IEFNLCAiSnVsaWVuIE1ldXJpYyIgPGp1bGll
bi5tZXVyaWNAb3JhbmdlLmNvbT48bWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbT4gd3Jv
dGU6DQoNCg0KDQpIaSBHZW9yZ2UuDQoNCg0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2Uu
IFlvdSBhcmUgcmlnaHQ6IHRoZSBtaW51dGVzIGFyZQ0KDQpub3QgZW5vdWdoDQoNCnRvIHRyYWNl
IHRoZSBmdWxsIGRpc2N1c3Npb24gKHdoaWNoIHdlIGFsc28gcmVzdW1lZCByaWdodCBhZnRlciB0
aGUNCg0KbWVldGluZykuIExldCB1cyBzdGFydCBieSB0aGFua2luZyBBZHJpYW4gKGFzIEFEPyBm
b3JtZXIgUENFIGNvLWNoYWlyPw0KDQphdXRob3Igb2YuLi4gOy0pICkgZm9yIGJyaW5naW5nIHRo
ZSBQQ0UtYXNzb2NpYXRlZCB2b2NhYnVsYXJ5IHRvIGENCg0KY29tbW9uIHVuZGVyc3RhbmRpbmcu
DQoNCg0KDQpBY3R1YWxseSBteSBjb25jZXJuIGlzIHN1c3RhaW5lZCBieSAyIHBvaW50czoNCg0K
DQoNCjEtIFRoZSBzY29wZSBvZiB0aGUgZHJhZnQgaXMgYWJvdXQgZ2l2aW5nIGNvbnRyb2wgb2Yg
dGhlIHJvdXRpbmcNCg0Kb2JqZWN0aXZlIGZ1bmN0aW9uIHRvIHRoZSBjbGllbnQgbm9kZSBmYWNp
bmcgYSB0cmFuc3BvcnQgbGF5ZXIuIEkgc2VlDQoNCmFscmVhZHkgc2V2ZXJhbCBleGlzdGluZyBz
b2x1dGlvbiB0byBhY2hpZXZlIGl0Og0KDQotIGEgUENFUCByZXF1ZXN0IGZyb20gdGhlIHNpZ25h
bGluZyBoZWFkIG5vZGUgaXMgYW4gb3B0aW9uICh3aGljaCBpcw0KDQphc3NvY2lhdGVkIHRvIHRo
ZSBhZHZlcnRpc2VtZW50IG9mIHRoZSBzdXBwb3J0ZWQgb2JqZWN0aXZlcyBpbiBQQ0VQKTsNCg0K
LSBidWlsZGluZyBJR1AgYWRqYWNlbmNpZXMgYmV0d2VlbiBjbGllbnQgYW5kIHRyYW5zcG9ydCBl
ZGdlIG5vZGVzDQoNCihhLmsuYS4gImJvcmRlciBtb2RlbCIpIGlzIGFub3RoZXIgb25lLg0KDQpJ
biB0aGlzIGNvbnRleHQsIGl0IGRvIG5vdCB0aGluayBleHRlbmRpbmcgUlNWUC1URSBmb3IgdGhp
cyBraW5kIG9mDQoNCmFwcGxpY2F0aW9uIGlzIHdvcnRoIHRoZSBlZmZvcnQsIHNpbmNlIHRoZSBy
ZXF1aXJlbWVudCBjYW4gYWxyZWFkeSBiZQ0KDQphZGRyZXNzZWQuDQoNCg0KDQpBcyBJIHVuZGVy
c3RhbmQgaXQsIGluIHRoZSBvcHRpY2FsIGFuZCBPVE4gY2FzZXMsIHRoZSBib3JkZXINCg0KbW9k
ZWwgd291bGQgbm90IGJlIHBvcHVsYXIgYXMgaW4gbWFueSBvcmdhbml6YXRpb25zIHRoaXMNCg0K
Y3Jvc3NlcyBwb2xpdGljYWwgYm91bmRhcmllcy4NCg0KDQoNClRoZSBwb2ludCBvZiB0aGUgZHJh
ZnQgaXMgdG8ga2VlcCB0aGUgVU5JIGltcGxlbWVudGF0aW9uDQoNCnNpbXBsZSBhbmQgbm90IHJl
cXVpcmUgYSBQQ0VQIG9uIHRoZSB1bmktYyBvciBuZWNlc3NhcmlseSBvbg0KDQp0aGUgdW5pLW4u
ICBXZSB3aWxsIGtlZXAgdGhlIGZvcm1hdCBhbGlnbmVkIHNvIGlmIHRoZSBVTkktTg0KDQpuZWVk
cyB0byBtYWtlIGEgcmVxdWVzdCBvZiBhIFBDUywgaXQgY2FuIGRvIHNvIHJhdGhlciBzaW1wbHku
DQoNCg0KDQoyLSBUaGVyZSBhcmUgY2FzZXMgd2hlbiBwcmV2aW91cyBvcHRpb25zIGFyZSBydWxl
ZCBvdXQgb2YgYSBnaXZlbg0KDQpkZXBsb3ltZW50LiBJIGRvIGJlbGlldmUgdGhhdCBpdCBpcyBu
b3Qgc2ltcGx5IGR1ZSB0byBwcm90b2NvbA0KDQpleGNsdXNpb24sIGJ1dCByYXRoZXIgdG8gdGhl
IGZhY3QgdGhhdCB0aGUgU1Agd2FudHMgdHJhbnNwb3J0IHJvdXRpbmcNCg0KZGVjaXNpb25zIHRv
IHJlbWFpbiBlbnRpcmVseSB3aXRoaW4gdGhlIHRyYW5zcG9ydCBuZXR3b3JrIChpbg0KDQpvcmRl
ciB0bw0KDQpmdWxseSBsZWF2ZSB0aGUgcm91dGluZyBwb2xpY3kgaW4gdGhlIGhhbmRzIG9mIHBl
b3BsZSBkb2luZyB0aGUgbGF5ZXINCg0KZGltZW5zaW9uaW5nKS4gVGh1cywgSSBmZWVsIHRoaXMg
dHJhZGUtb2ZmIGluIHBhdGggc2VsZWN0aW9uDQoNCnR1bmluZyBpcw0KDQpyYXRoZXIgdW5saWtl
bHkgdG8gaGFwcGVuIGFuZCBJIGZlYXIgd2UgbWF5IGJlIHRhbGtpbmcgYWJvdXQgUlNWUC1URQ0K
DQpvdmVyLWVuZ2luZWVyaW5nIGhlcmUuDQoNCg0KDQpUaGUgaWRlYSBpcyBzaW1wbHkgdG8gYWxs
b3cgdGhlIGNsaWVudCB0byBleHByZXNzIGl0cw0KDQpuZWVkcy93aXNoZXMuICBUaGUgVU5JLU4g
cmVtYWlucyBpbiBjb250cm9sLiAgQnkgcG9saWN5IGl0IGNhbg0KDQp1c2UgdGhlIG9iamVjdGl2
ZSBmdW5jdGlvbiBvciBub3QuICBGdXJ0aGVyIGlmIGl0IGRvZXMgdXNlIHRoZQ0KDQpvYmplY3Rp
dmUgZnVuY3Rpb24gYW5kIGZhaWxzIHRvIGZpbmQgYSBwYXRoIGl0IGNhbiBlaXRoZXIgc2F5DQoN
CnRoYXQgdGhlcmUgd2FzIG5vIHBhdGggb3IgaXQgcHJvY2VlZCB0byBzZXR1cCB3aGF0IGl0IGNh
bi4NCg0KDQoNCihUaGF0IGlzIGFsc28gd2h5IEkgcHJlZmVycmVkIHRvIGNvbnNpZGVyIHlvdXIg
SS1EcyBzZXBhcmF0ZWx5IGR1cmluZw0KDQp0aGUgQ0NBTVAgbWVldGluZy4pDQoNCg0KDQpBZ3Jl
ZWQuICBJIHdpbGwgYXNrIGZvciBzZXBhcmF0ZSBzbG90cy4gIFRoZSBkaXNjdXNzaW9uIGF0IHRo
ZQ0KDQplbmQgd2FzIHJhdGhlciBkaXNqb2ludGVkLg0KDQoNCg0KDQoNCkhvd2V2ZXIsIG15IGNv
bW1lbnRzIGFyZSBtb3N0bHkgcmVsYXRlZCB0byB0aGUgY2xpZW50L3RyYW5zcG9ydA0KDQpyZWxh
dGlvbnNoaXAuIElmIHRoZSBJLUQgaXMgZXh0ZW5kZWQgdG8gY292ZXIgbW9yZSB1c2UgY2FzZXMN
Cg0Kd2l0aCB3aWRlcg0KDQpzY29wZXMgKEFkcmlhbiBoYXMgbWFkZSBpbnRlcmVzdGluZyBzdWdn
ZXN0aW9ucyksIHR1cm5pbmcgdGhlIG92ZXJsYXkNCg0KaW50ZXJjb25uZWN0aW9uIGludG8gb25l
IGFtb25nIGEgbG9uZ2VyIGxpc3QsIHRoZW4gbXkNCg0KY29uY2x1c2lvbiBtYXkgYmUNCg0KZGlm
ZmVyZW50Lg0KDQoNCg0KSSdtIGhhcHB5IHRvIHdpZGVuIHRoZSBzY29wZSBpbiB0aGlzIHdheS4N
Cg0KDQoNCi4uLkdlb3JnZQ0KDQoNCg0KUmVnYXJkcywNCg0KDQoNCkp1bGllbg0KDQoNCg0KDQoN
CkxlIDExLzA5LzIwMTIgMjE6MjgsIEdlb3JnZSBTd2FsbG93IChzd2FsbG93KSBhIMOpY3JpdCA6
DQoNCkp1bGllbiAtDQoNCg0KDQpSZWFkaW5nIHRoZSBDQ0FNUCBub3RlcyAod2hpY2ggY2FwdHVy
ZSBsaXR0bGUgb2YgdGhlIGFjdHVhbA0KDQpkaXNjdXNzaW9uKSBJIHNlZSB0aGF0IHRoZXJlIG1h
eSBoYXZlIGJlZW4gYSBwZXJjZXB0aW9uIGluIHRoZSByb29tDQoNCnRoYXQgUENFIGZ1bmN0aW9u
YWxpdHkgYXQgdGhlIFVOSS1OIHdhcyBhc3N1bWVkIChhY3R1YWwgb3IgcHJveHkpLg0KDQoNCg0K
VGhpcyBpcyBub3QgdGhlIGNhc2UuIFRoZSByZWFzb24gZm9yIG91ciBkcmFmdCBpcyB0aGF0IHdp
dGgNCg0KdGhlIFVOSSwNCg0KbXVjaCBvZiB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IHJlc2lkZXMg
YXQgdGhlIGhlYWRlbmQgaXMNCg0KbW92ZWQgdG8gdGhlDQoNClVOSS1OLiBTbyB0aGUgVU5JLUMg
bmVlZHMgYSB3YXkgdG8gZXhwcmVzcyBhbiBvYmplY3RpdmUNCg0KZnVuY3Rpb24gZXZlbg0KDQpp
ZiB0aGVyZSBpcyBubyBQQ0UuDQoNCg0KDQpPcGVyYXRpb25hbGx5IGl0IHNlZW1zIGJ1cmRlbnNv
bWUgdG8gcmVxdWlyZSBhIFBDRVAgYXQgdGhlDQoNClVOSS1DIGFuZA0KDQphIFBDRVAgYXQgdGhl
IFVOSS1OLCB3aGVuIGFsbCB0aGF0IGlzIGJlaW5nIGRvbmUgaXMgZW5hYmxpbmcgdGhlDQoNClVO
SS1OIHRvIHBlcmZvcm0gd2hhdCB0aGUgY2xpZW50IHdvdWxkIGRvIGlmIGl0IHdlcmUNCg0KY29u
bmVjdGVkIHRvIHRoZQ0KDQpuZXR3b3JrIHZpYSBhIG5vcm1hbCBsaW5rLg0KDQoNCg0KRG8geW91
IHN0aWxsIG9iamVjdCB0byB0aGUgZHJhZnQ/DQoNCg0KDQpUaGFua3MsDQoNCg0KDQrFoEdlb3Jn
ZQ0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCg0KQ0NBTVBAaWV0Zi5vcmc8bWFpbHRvOkND
QU1QQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj
YW1wDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCg0KQ0NBTVAgbWFpbGluZyBsaXN0DQoNCkNDQU1QQGlldGYub3JnPG1haWx0bzpDQ0FN
UEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2Ft
cA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cg0KQ0NBTVAgbWFpbGluZyBsaXN0DQoNCkNDQU1QQGlldGYub3JnPG1haWx0bzpDQ0FNUEBpZXRm
Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQot
LQ0KW2NpZDppbWFnZTAwMS5qcGdAMDFDRDk1QjEuNkM2MDY4QTBdDQpESUVURVIgQkVMTEVSDQpB
TENBVEVMLUxVQ0VOVCBERVVUU0NITEFORCBBRw0KUFJPSkVDVCBNQU5BR0VSIEFTT04vR01QTFMg
Q09OVFJPTCBQTEFORQ0KTkVUV09SS1MgR1JPVVAsIE9QVElDUyBESVZJU0lPTg0KVEVSUkVTVFJJ
QUwgT1BUSUNTIFVOSVQNCg0KTG9yZW56c3RyYXNzZSAxMA0KNzA0MzUgU3R1dHRnYXJ0LCBHZXJt
YW55DQpUOiArNDkgNzExIDgyMSA0MzEyNQ0KTTogKzQ5IDE3NSA3MjY2ODc0DQpEaWV0ZXIuQmVs
bGVyQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86RGlldGVyLkJlbGxlckBhbGNhdGVsLWx1Y2Vu
dC5jb20+DQoNCkFsY2F0ZWwtTHVjZW50IERldXRzY2hsYW5kIEFHDQpEb21pY2lsZSBvZiB0aGUg
Q29tcGFueTogU3R1dHRnYXJ0IMK3IExvY2FsIENvdXJ0IFN0dXR0Z2FydCBIUkIgNDAyNg0KQ2hh
aXJtYW4gb2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBNaWNoYWVsIE9wcGVuaG9mZg0KQm9hcmQg
b2YgTWFuYWdlbWVudDogV2lsaGVsbSBEcmVzc2VsaGF1cyAoQ2hhaXJtYW4pIMK3IEhhbnMtSsO2
cmcgRGF1YiDCtw0KRHIuIFJhaW5lciBGZWNobmVyIMK3IEFuZHJlYXMgR2VoZQ0KDQpUaGlzIGUt
bWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzLCBpZiBhbnksIG1heSBjb250YWluIGNvbmZpZGVudGlh
bCBpbmZvcm1hdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZS1tYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHVzIGFuZCBkZWxldGUgb3IgZGVzdHJveSB0aGUNCmUtbWFpbCBhbmQg
aXRzIGF0dGFjaG1lbnRzLCBpZiBhbnksIGltbWVkaWF0ZWx5LiBJZiB5b3UgaGF2ZSByZWNlaXZl
ZCB0aGlzIGUtbWFpbCBpbg0KZXJyb3IsIHlvdSBtdXN0IG5vdCBmb3J3YXJkIG9yIG1ha2UgdXNl
IG9mIHRoZSBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55Lg0K

--_000_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS
L1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNv
bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxMSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFt
c29dPg0KPHN0eWxlPg0Kdlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPg0K
PCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0
IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut
MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1T
IE1pbmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOmJs
dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bWFyZ2luOjBjbTsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uU3RpbGVNZXNzYWdnaW9EaVBvc3Rh
RWxldHRyb25pY2ExOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NTk1LjNw
dCA4NDEuOXB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNl
Y3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBl
bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+
DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBi
Z2NvbG9yPXdoaXRlIGxhbmc9SVQgbGluaz1ibHVlIHZsaW5rPWJsdWU+DQoNCjxkaXYgY2xhc3M9
U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBm
YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp
YWw7Y29sb3I6bmF2eSc+KzE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz
cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u
dCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPkZ1bGx5IGFncmVl
IHdpdGggeW91cg0KY29tbWVudHMgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN
CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxz
cGFuIGxhbmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs
O2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs
YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxh
bmc9RU4tR0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y
Om5hdnknPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z
b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4t
R0INCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkn
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h
bD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0
eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlNlcmdp
bzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u
dCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIGxhbmc9RU4tR0INCnN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48
Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+QmVsb3R0aSBTZXJnaW8gLSBT
eXN0ZW0gQXJjaGl0ZWN0PC9zcGFuPjwvZm9udD48c3Bhbg0KbGFuZz1FTi1HQj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymxh
Y2sgZmFjZT1BcmlhbD48c3BhbiBsYW5nPUVOLUdCDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpBcmlhbCc+QUxDQVRFTC1MVUNFTlQmbmJzcDsgT3B0aWNzIERpdmlzaW9uPC9z
cGFuPjwvZm9udD48c3Bhbg0KbGFuZz1FTi1HQj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwv
ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9
J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmNvbG9yPWJsYWNrIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6d2luZG93dGV4
dCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4N
Cg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPVRhaG9tYT48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOndpbmRvd3RleHQ7Zm9udC13ZWlnaHQ6Ym9sZCc+
RGE6PC9zcGFuPjwvZm9udD48L2I+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPVRhaG9t
YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7DQpjb2xv
cjp3aW5kb3d0ZXh0Jz4gY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5j
ZXNAaWV0Zi5vcmddIDxiPjxzcGFuDQpzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+UGVyIGNvbnRv
IGRpIDwvc3Bhbj48L2I+RGlldGVyIEJlbGxlcjxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdl
aWdodDpib2xkJz5JbnZpYXRvOjwvc3Bhbj48L2I+IG1hcnRlZMOsIDE4IHNldHRlbWJyZSAyMDEy
DQoxMS41Mzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5BOjwvc3Bhbj48
L2I+IERhbmllbGUgQ2VjY2FyZWxsaTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpi
b2xkJz5DYzo8L3NwYW4+PC9iPiBjY2FtcEBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSdm
b250LXdlaWdodDpib2xkJz5PZ2dldHRvOjwvc3Bhbj48L2I+IFJlOiBbQ0NBTVBdIE9iamVjdGl2
ZQ0KZnVuY3Rpb24gZHJhZnQ8L3NwYW4+PC9mb250Pjxmb250IGNvbG9yPWJsYWNrPjxzcGFuIHN0
eWxlPSdjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8
L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl
PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsYWNrDQpmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5IaSBEYW5pZWxl
LCBhbGwsPGJyPg0KPGJyPg0KKzE8YnI+DQo8YnI+DQpJIGZ1bGx5IGFncmVlIHdpdGggeW91ciBj
b21tZW50cy9jbGFyaWZpY2F0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KRGll
dGVyPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv
Tm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz
cGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+T24gMTguMDkuMjAxMiAwOToxOSwgRGFuaWVs
ZSBDZWNjYXJlbGxpIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2
Pg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Jw0KY2l0ZT0ibWlkOkI1NjMwQTk1RDgwMzc0NEE4MUM1MUFENDA0MEE2REFBMjZFMEM1QjQ5
NUBFU0VTU0NNUzAzNjAuZWVtZWEuZXJpY3Nzb24uc2UiDQp0eXBlPWNpdGU+PHByZSB3cmFwPSIi
Pjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz4rMC41PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw
cmU+PGZvbnQgc2l6ZT0yDQpjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5GdWxseSBhZ3JlZSBvbiB0aGUgc2Vjb25kIHBhcnQg
b2YgeW91ciBzdGF0ZW1lbnQuIEF0IHRoZSB0aW1lIG9mIFJGQzQyMDggdGhlIFVOSSBhbGxvd2Vk
IHRoZSBleGNoYW5nZSBvZiBzaWduYWxpbmcgYW5kIHJvdXRpbmcgbWVzc2FnZXMuIE5vdyB0aGF0
IHdlJ3JlIGRlZmluaW5nIGFsc28gdGhlIEUtTk5JIGkgd291bGQgcHJlZmVyIHRvIGhhdmU6PG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFj
ayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9
YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4t
IFVOSTogc2lnbmFsaW5nIG9ubHk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdCc+LSBFLU5OSTogc2lnbmFsaW5nIEFORCByb3V0aW5nIChpIHdvdWxk
IHByZWZlciB0byBjYWxsIGl0IHJlYWNoYWJpbGl0eSByYXRoZXIgdGhhbiByb3V0aW5nLCBiZWNh
dXNlIGl0IGlzIG5vdCBhIHRvcG9sb2d5IGluZm8pPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXci
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5UaGF0IHNhaWQsIGkgdGhpbmsgdGhhdCBv
YmplY3RpdmUgZnVuY3Rpb24gKGRlc3BpdGUgdGhlIGNvcnJlY3QgY29tbWVudHMgZnJvbSBKdWxp
ZW4pIGlzIG5vdCByb3V0aW5nIGJ1dCBhIGNvbnN0cmFpbnQuIFRoZSBpbmdyZXNzIG5vZGUgb2Yg
dGhlIG92ZXJsYXkgbmV0d29yayBhc2tzIHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIGNvcmUgbmV0
d29yayBmb3IgYSBwYXRoIGNvbXB1dGF0aW9uIHdpdGggZ2l2ZW4gY29uc3RyYWludHMuIDxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJs
YWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Vmlj
ZXZlcnNhIGluIHRoZSBjYXNlIG9mIEUtTk5JIGlmIHRoZSBvYmplY3RpdmUgZnVuY3Rpb24gd2Fz
IGV4cG9ydGVkIHRvIHRoZSBvdmVybGF5IG5ldHdvcmsgYXMgYSAmcXVvdDtwcm9wZXJ0eSZxdW90
OyBvZiBhIHZpcnR1YWwgbGluaywgdGhlbiBpIGFncmVlIGl0IHdhcyByb3V0aW5nIChyZWFjaGFi
aWxpdHkpIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdCc+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5EYW5pZWxlPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
Zm9udD48L3ByZT4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCcgdHlwZT1jaXRlPjxwcmUgd3JhcD0iIj48Zm9udA0Kc2l6ZT0yIGNvbG9y
PWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+RnJvbTogPGENCmhyZWY9Im1haWx0bzpjY2FtcC1ib3Vu
Y2VzQGlldGYub3JnIj5jY2FtcC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGENCmhyZWY9Im1haWx0
bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZzwv
YT5dIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29s
b3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
Jz5PbiBCZWhhbGYgT2YgR2VydCBHcmFtbWVsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl
PjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlNlbnQ6IGx1bmVkw6wgMTcgc2V0dGVtYnJlIDIwMTIg
MjMuMjI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNv
bG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dCc+VG86IEdlb3JnZSBTd2FsbG93IChzd2FsbG93KTsgSnVsaWVuIE1ldXJpYzxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5DYzogPGENCmhyZWY9
Im1haWx0bzpjY2FtcEBpZXRmLm9yZyI+Y2NhbXBAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlN1YmplY3Q6IFJlOiBbQ0NB
TVBdIE9iamVjdGl2ZSBmdW5jdGlvbiBkcmFmdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SGkgR2VvcmdlLDxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmll
ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNv
dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+VGhlIG9iamVjdGl2ZSBm
dW5jdGlvbiBpcyBpbiB0aGUgZW5kIGEgcm91dGluZyBpbmZvcm1hdGlvbi4gPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPk1peGluZyByb3V0aW5n
IGFuZCBzaWduYWxpbmcgaW4gb25lIHByb3RvY29sIGlzIHNvbWV0aGluZyBJIDxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5kb24ndCBmZWVsIGNv
bWZvcnRhYmxlIHdpdGguPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0Jz5JbiBvdGhlciB3b3JkcywgaWYgcm91dGluZyBpcyBuZWVkZWQgYmV0
d2VlbiBjbGllbnQgYW5kIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250
DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0Jz5zZXJ2ZXIsIFVOSSBpcyB0aGUgd3JvbmcgY2hvaWNlLiBFTk5JIHNob3Vs
ZCBiZSBjb25zaWRlcmVkIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250
DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0Jz5pbnN0ZWFkIGFuZCBEcmFmdC1iZWVyYW0tY2NhbXAtZ21wbHMtZW5uaSB3
b3VsZCBiZSBhIGdvb2QgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQnPnN0YXJ0aW5nIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m
b250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkdlcnQ8bzpwPjwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIg
TmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5Gcm9tOiA8YQ0KaHJlZj0ibWFpbHRvOmNjYW1w
LWJvdW5jZXNAaWV0Zi5vcmciPmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBv
ZiBHZW9yZ2UgU3dhbGxvdyAoc3dhbGxvdyk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTIg
MTI6MTk6MjEgUE08bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6
ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdCc+VG86IEp1bGllbiBNZXVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+
PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Q2M6IDxhDQpocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5v
cmciPmNjYW1wQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJl
Pjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz5TdWJqZWN0OiBSZTogW0NDQU1QXSBPYmplY3RpdmUgZnVuY3Rp
b24gZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0y
IGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPkhpIEp1bGllbiAtPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48
cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz5PbiA5LzE3LzEyIDk6MzcgQU0sICZxdW90O0p1bGllbiBN
ZXVyaWMmcXVvdDsgPGENCmhyZWY9Im1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20iPiZs
dDtqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXpl
PTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0Jz5IaSBHZW9yZ2UuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZv
bnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJl
Pjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz5Tb3JyeSBmb3IgdGhlIGxhdGUgcmVzcG9uc2UuIFlvdSBhcmUg
cmlnaHQ6IHRoZSBtaW51dGVzIGFyZSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9i
bG9ja3F1b3RlPg0KDQo8cHJlIHdyYXA9IiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9
IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPm5vdCBlbm91Z2gg
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIi
Pjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz50byB0cmFjZSB0aGUgZnVsbCBkaXNjdXNzaW9uICh3aGljaCB3
ZSBhbHNvIHJlc3VtZWQgcmlnaHQgYWZ0ZXIgdGhlIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5tZWV0aW5nKS4gTGV0IHVzIHN0YXJ0IGJ5IHRo
YW5raW5nIEFkcmlhbiAoYXMgQUQ/IGZvcm1lciBQQ0UgY28tY2hhaXI/PG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmF1dGhvciBvZi4uLiA7LSkg
KSBmb3IgYnJpbmdpbmcgdGhlIFBDRS1hc3NvY2lhdGVkIHZvY2FidWxhcnkgdG8gYSA8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Y29tbW9uIHVu
ZGVyc3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250
DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0Jz5BY3R1YWxseSBteSBjb25jZXJuIGlzIHN1c3RhaW5lZCBieSAyIHBvaW50
czo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9y
PWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBj
b2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQnPjEtIFRoZSBzY29wZSBvZiB0aGUgZHJhZnQgaXMgYWJvdXQgZ2l2aW5nIGNvbnRyb2wgb2Yg
dGhlIHJvdXRpbmcgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPm9iamVjdGl2ZSBmdW5jdGlvbiB0byB0aGUgY2xpZW50IG5vZGUgZmFjaW5nIGEg
dHJhbnNwb3J0IGxheWVyLiBJIHNlZSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdCc+YWxyZWFkeSBzZXZlcmFsIGV4aXN0aW5nIHNvbHV0aW9uIHRv
IGFjaGlldmUgaXQ6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPi0gYSBQQ0VQIHJlcXVlc3QgZnJvbSB0aGUgc2lnbmFsaW5nIGhlYWQgbm9kZSBp
cyBhbiBvcHRpb24gKHdoaWNoIGlzIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJl
Pjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0Jz5hc3NvY2lhdGVkIHRvIHRoZSBhZHZlcnRpc2VtZW50IG9mIHRo
ZSBzdXBwb3J0ZWQgb2JqZWN0aXZlcyBpbiBQQ0VQKTs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+LSBidWlsZGluZyBJR1AgYWRqYWNlbmNpZXMg
YmV0d2VlbiBjbGllbnQgYW5kIHRyYW5zcG9ydCBlZGdlIG5vZGVzIDxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmll
ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4oYS5rLmEuICZxdW90O2JvcmRl
ciBtb2RlbCZxdW90OykgaXMgYW5vdGhlciBvbmUuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkluIHRoaXMgY29udGV4dCwgaXQgZG8gbm90IHRo
aW5rIGV4dGVuZGluZyBSU1ZQLVRFIGZvciB0aGlzIGtpbmQgb2YgPG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVy
IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmFwcGxpY2F0aW9uIGlzIHdvcnRo
IHRoZSBlZmZvcnQsIHNpbmNlIHRoZSByZXF1aXJlbWVudCBjYW4gYWxyZWFkeSBiZSA8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+YWRkcmVzc2Vk
LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmUgd3Jh
cD0iIj48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuDQpz
dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkFzIEkgdW5kZXJzdGFuZCBpdCwgaW4gdGhlIG9w
dGljYWwgYW5kIE9UTiBjYXNlcywgdGhlIGJvcmRlciA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+
PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+bW9kZWwgd291bGQgbm90IGJlIHBvcHVsYXIg
YXMgaW4gbWFueSBvcmdhbml6YXRpb25zIHRoaXMgPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv
cHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmNyb3NzZXMgcG9saXRpY2FsIGJvdW5kYXJpZXMu
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1i
bGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29s
b3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
Jz5UaGUgcG9pbnQgb2YgdGhlIGRyYWZ0IGlzIHRvIGtlZXAgdGhlIFVOSSBpbXBsZW1lbnRhdGlv
biA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9y
PWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+
c2ltcGxlIGFuZCBub3QgcmVxdWlyZSBhIFBDRVAgb24gdGhlIHVuaS1jIG9yIG5lY2Vzc2FyaWx5
IG9uIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29s
b3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
Jz50aGUgdW5pLW4uwqAgV2Ugd2lsbCBrZWVwIHRoZSBmb3JtYXQgYWxpZ25lZCBzbyBpZiB0aGUg
VU5JLU4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBj
b2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQnPm5lZWRzIHRvIG1ha2UgYSByZXF1ZXN0IG9mIGEgUENTLCBpdCBjYW4gZG8gc28gcmF0aGVy
IHNpbXBseS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQoNCjxibG9ja3F1b3RlIHN0
eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnIHR5cGU9Y2l0ZT48cHJl
IHdyYXA9IiI+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXci
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4yLSBUaGVyZSBhcmUgY2FzZXMgd2hlbiBw
cmV2aW91cyBvcHRpb25zIGFyZSBydWxlZCBvdXQgb2YgYSBnaXZlbiA8bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ZGVwbG95bWVudC4gSSBkbyBi
ZWxpZXZlIHRoYXQgaXQgaXMgbm90IHNpbXBseSBkdWUgdG8gcHJvdG9jb2wgPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmV4Y2x1c2lvbiwgYnV0
IHJhdGhlciB0byB0aGUgZmFjdCB0aGF0IHRoZSBTUCB3YW50cyB0cmFuc3BvcnQgcm91dGluZyA8
bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJs
YWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ZGVj
aXNpb25zIHRvIHJlbWFpbiBlbnRpcmVseSB3aXRoaW4gdGhlIHRyYW5zcG9ydCBuZXR3b3JrIChp
biA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9ibG9ja3F1b3RlPg0KDQo8cHJlIHdy
YXA9IiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0K
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPm9yZGVyIHRvIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u
dD48L3ByZT4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCcgdHlwZT1jaXRlPjxwcmUgd3JhcD0iIj48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJs
YWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ZnVs
bHkgbGVhdmUgdGhlIHJvdXRpbmcgcG9saWN5IGluIHRoZSBoYW5kcyBvZiBwZW9wbGUgZG9pbmcg
dGhlIGxheWVyIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl
PTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0Jz5kaW1lbnNpb25pbmcpLiBUaHVzLCBJIGZlZWwgdGhpcyB0cmFkZS1vZmYgaW4gcGF0
aCBzZWxlY3Rpb24gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjwvYmxvY2txdW90ZT4N
Cg0KPHByZSB3cmFwPSIiPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5l
dyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz50dW5pbmcgaXMgPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXpl
PTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0Jz5yYXRoZXIgdW5saWtlbHkgdG8gaGFwcGVuIGFuZCBJIGZlYXIgd2UgbWF5IGJlIHRh
bGtpbmcgYWJvdXQgUlNWUC1URSA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdCc+b3Zlci1lbmdpbmVlcmluZyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmUgd3JhcD0iIj48Zm9udCBzaXplPTIg
Y29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw
LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPlRoZSBpZGVhIGlzIHNpbXBseSB0byBhbGxvdyB0aGUgY2xpZW50IHRvIGV4cHJl
c3MgaXRzIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIg
Y29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu
MHB0Jz5uZWVkcy93aXNoZXMuwqAgVGhlIFVOSS1OIHJlbWFpbnMgaW4gY29udHJvbC7CoCBCeSBw
b2xpY3kgaXQgY2FuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz
aXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTAuMHB0Jz51c2UgdGhlIG9iamVjdGl2ZSBmdW5jdGlvbiBvciBub3QuwqAgRnVydGhlciBp
ZiBpdCBkb2VzIHVzZSB0aGUgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZv
bnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQnPm9iamVjdGl2ZSBmdW5jdGlvbiBhbmQgZmFpbHMgdG8gZmluZCBhIHBh
dGggaXQgY2FuIGVpdGhlciBzYXkgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+
PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQnPnRoYXQgdGhlcmUgd2FzIG5vIHBhdGggb3IgaXQgcHJvY2VlZCB0
byBzZXR1cCB3aGF0IGl0IGNhbi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0K
DQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4oVGhhdCBpcyBhbHNv
IHdoeSBJIHByZWZlcnJlZCB0byBjb25zaWRlciB5b3VyIEktRHMgc2VwYXJhdGVseSBkdXJpbmcg
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1i
bGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPnRo
ZSBDQ0FNUCBtZWV0aW5nLik8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9ibG9ja3F1
b3RlPg0KDQo8cHJlIHdyYXA9IiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0i
Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5BZ3JlZWQuwqAgSSB3
aWxsIGFzayBmb3Igc2VwYXJhdGUgc2xvdHMuwqAgVGhlIGRpc2N1c3Npb24gYXQgdGhlIDxvOnA+
PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5lbmQgd2Fz
IHJhdGhlciBkaXNqb2ludGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+DQoN
CjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQn
IHR5cGU9Y2l0ZT48cHJlIHdyYXA9IiI+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJD
b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFj
ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5Ib3dldmVyLCBt
eSBjb21tZW50cyBhcmUgbW9zdGx5IHJlbGF0ZWQgdG8gdGhlIGNsaWVudC90cmFuc3BvcnQgPG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFj
ayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPnJlbGF0
aW9uc2hpcC4gSWYgdGhlIEktRCBpcyBleHRlbmRlZCB0byBjb3ZlciBtb3JlIHVzZSBjYXNlcyA8
bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9ibG9ja3F1b3RlPg0KDQo8cHJlIHdyYXA9
IiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPndpdGggd2lkZXIgPG86cD48L286cD48L3NwYW4+PC9mb250
PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXplPTIgY29sb3I9Ymxh
Y2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5zY29w
ZXMgKEFkcmlhbiBoYXMgbWFkZSBpbnRlcmVzdGluZyBzdWdnZXN0aW9ucyksIHR1cm5pbmcgdGhl
IG92ZXJsYXkgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9
MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MC4wcHQnPmludGVyY29ubmVjdGlvbiBpbnRvIG9uZSBhbW9uZyBhIGxvbmdlciBsaXN0LCB0aGVu
IG15IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Jsb2NrcXVvdGU+DQoNCjxwcmUg
d3JhcD0iIj48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFu
DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Y29uY2x1c2lvbiBtYXkgYmUgPG86cD48L286cD48
L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXpl
PTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0Jz5kaWZmZXJlbnQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjwvYmxvY2tx
dW90ZT4NCg0KPHByZSB3cmFwPSIiPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9
IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SSdtIGhhcHB5IHRv
IHdpZGVuIHRoZSBzY29wZSBpbiB0aGlzIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPi4uLkdlb3JnZTxvOnA+PC9vOnA+PC9zcGFu
PjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmll
ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L2ZvbnQ+PC9wcmU+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQnIHR5cGU9Y2l0ZT48cHJlIHdyYXA9IiI+PGZvbnQNCnNpemU9
MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox
MC4wcHQnPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0Jz5KdWxpZW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJl
PjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5MZSAxMS8wOS8yMDEyIDIxOjI4LCBHZW9yZ2Ug
U3dhbGxvdyAoc3dhbGxvdykgYSDDqWNyaXQgOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3By
ZT4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCcgdHlwZT1jaXRlPjxwcmUgd3JhcD0iIj48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SnVsaWVuIC08
bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJs
YWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xv
cj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn
PlJlYWRpbmcgdGhlIENDQU1QIG5vdGVzICh3aGljaCBjYXB0dXJlIGxpdHRsZSBvZiB0aGUgYWN0
dWFsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xv
cj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn
PmRpc2N1c3Npb24pIEkgc2VlIHRoYXQgdGhlcmUgbWF5IGhhdmUgYmVlbiBhIHBlcmNlcHRpb24g
aW4gdGhlIHJvb20gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNp
emU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQnPnRoYXQgUENFIGZ1bmN0aW9uYWxpdHkgYXQgdGhlIFVOSS1OIHdhcyBhc3N1bWVk
IChhY3R1YWwgb3IgcHJveHkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy
ZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdCc+VGhpcyBpcyBub3QgdGhlIGNhc2UuIFRoZSByZWFzb24gZm9y
IG91ciBkcmFmdCBpcyB0aGF0IHdpdGggPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjwv
YmxvY2txdW90ZT4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8cHJlIHdyYXA9IiI+PGZvbnQgc2l6ZT0y
IGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZTox
MC4wcHQnPnRoZSBVTkksIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCg0KPGJsb2Nr
cXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCcgdHlwZT1j
aXRlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sg
ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5tdWNoIG9m
IHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQgcmVzaWRlcyBhdCB0aGUgaGVhZGVuZCBpcyA8bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PC9ibG9ja3F1b3RlPg0KDQo8L2Jsb2NrcXVvdGU+DQoN
CjxwcmUgd3JhcD0iIj48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXci
PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+bW92ZWQgdG8gdGhlIDxvOnA+PC9vOnA+
PC9zcGFuPjwvZm9udD48L3ByZT4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCcgdHlwZT1jaXRlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0n
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFw
PSIiPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz5VTkktTi4gU28gdGhlIFVOSS1DIG5lZWRzIGEgd2F5IHRv
IGV4cHJlc3MgYW4gb2JqZWN0aXZlIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Js
b2NrcXVvdGU+DQoNCjwvYmxvY2txdW90ZT4NCg0KPHByZSB3cmFwPSIiPjxmb250IHNpemU9MiBj
b2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu
MHB0Jz5mdW5jdGlvbiBldmVuIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCg0KPGJs
b2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCcgdHlw
ZT1jaXRlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0JyB0eXBlPWNpdGU+PHByZSB3cmFwPSIiPjxmb250DQpzaXplPTIgY29sb3I9Ymxh
Y2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5pZiB0
aGVyZSBpcyBubyBQQ0UuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN
CnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxm
b250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0Jz5PcGVyYXRpb25hbGx5IGl0IHNlZW1zIGJ1cmRlbnNvbWUgdG8gcmVx
dWlyZSBhIFBDRVAgYXQgdGhlIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48L2Jsb2Nr
cXVvdGU+DQoNCjwvYmxvY2txdW90ZT4NCg0KPHByZSB3cmFwPSIiPjxmb250IHNpemU9MiBjb2xv
cj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0
Jz5VTkktQyBhbmQgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90
ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+
DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQnIHR5cGU9Y2l0ZT48cHJlIHdyYXA9IiI+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmEgUENFUCBhdCB0
aGUgVU5JLU4sIHdoZW4gYWxsIHRoYXQgaXMgYmVpbmcgZG9uZSBpcyBlbmFibGluZyB0aGUgPG86
cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFj
ayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlVOSS1O
IHRvIHBlcmZvcm0gd2hhdCB0aGUgY2xpZW50IHdvdWxkIGRvIGlmIGl0IHdlcmUgPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcHJlPjwvYmxvY2txdW90ZT4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8
cHJlIHdyYXA9IiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48
c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPmNvbm5lY3RlZCB0byB0aGUgPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0JyB0eXBlPWNpdGU+DQoNCjxibG9ja3F1b3RlIHN0eWxl
PSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnIHR5cGU9Y2l0ZT48cHJlIHdy
YXA9IiI+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPm5ldHdvcmsgdmlhIGEgbm9ybWFsIGxpbmsuPG86cD48
L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBm
YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9Ymxh
Y2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5EbyB5
b3Ugc3RpbGwgb2JqZWN0IHRvIHRoZSBkcmFmdD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250
PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48
L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIg
TmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsWgR2VvcmdlPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcHJlPjwvYmxvY2txdW90ZT4NCg0KPHByZSB3cmFwPSIiPjxmb250
IHNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250
LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48
Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjwv
YmxvY2txdW90ZT4NCg0KPHByZSB3cmFwPSIiPjxmb250IHNpemU9MiBjb2xvcj1ibGFjayBmYWNl
PSJDb3VyaWVyIE5ldyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNr
IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Q0NBTVAgbWFpbGluZyBsaXN0
PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1i
bGFjayBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxh
DQpocmVmPSJtYWlsdG86Q0NBTVBAaWV0Zi5vcmciPkNDQU1QQGlldGYub3JnPC9hPjxvOnA+PC9v
OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFj
ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48YQ0KaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcCI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv
bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9IkNvdXJpZXIgTmV3
Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVy
IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291
cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48
L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5DQ0FNUCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpw
Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZhY2U9
IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGENCmhyZWY9Im1h
aWx0bzpDQ0FNUEBpZXRmLm9yZyI+Q0NBTVBAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+
PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3VyaWVy
IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxhDQpocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2NjYW1wPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48
cHJlPjxmb250DQpzaXplPTIgY29sb3I9YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w
cmU+PC9ibG9ja3F1b3RlPg0KDQo8cHJlIHdyYXA9IiI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsYWNr
IGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3Nw
YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBjb2xvcj1ibGFjayBmYWNlPSJDb3Vy
aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkNDQU1QIG1haWxpbmcgbGlz
dDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgY29sb3I9
YmxhY2sgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48
YQ0KaHJlZj0ibWFpbHRvOkNDQU1QQGlldGYub3JnIj5DQ0FNUEBpZXRmLm9yZzwvYT48bzpwPjwv
bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsYWNrIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PGENCmhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXAiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L2E+PG86cD48L286cD48L3NwYW4+PC9m
b250PjwvcHJlPjwvYmxvY2txdW90ZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9
MyBjb2xvcj1ibGFjayBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1z
aXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4N
Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJUaW1l
cyBOZXcgUm9tYW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+LS0gPG86cD48L286
cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xh
c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1ibGFjayBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PGltZyBib3JkZXI9MCB3aWR0aD0y
NzYgaGVpZ2h0PTI2IGlkPSJfeDAwMDBfaTEwMjUiDQpzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFD
RDk1QjEuNkM2MDY4QTAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoN
CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgY29sb3I9YmxhY2sg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC13ZWlnaHQ6Ym9sZCc+RElFVEVSIEJFTExFUjwvc3Bhbj48L2ZvbnQ+PC9iPjxvOnA+PC9vOnA+
PC9wPg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv
bnQgc2l6ZT0yIGNvbG9yPSIjNjYzOWI3IiBmYWNlPVRhaG9tYT48c3Bhbg0Kc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOiM2NjM5QjcnPkFMQ0FURUwtTFVD
RU5UDQpERVVUU0NITEFORCBBRzxicj4NClBST0pFQ1QgTUFOQUdFUiBBU09OL0dNUExTIENPTlRS
T0wgUExBTkU8YnI+DQpORVRXT1JLUyBHUk9VUCwgT1BUSUNTIERJVklTSU9OPGJyPg0KVEVSUkVT
VFJJQUwgT1BUSUNTIFVOSVQ8YnI+DQo8YnI+DQpMb3JlbnpzdHJhc3NlIDEwPGJyPg0KNzA0MzUg
U3R1dHRnYXJ0LCBHZXJtYW55PGJyPg0KVDogKzQ5IDcxMSA4MjEgNDMxMjU8YnI+DQpNOiArNDkg
MTc1IDcyNjY4NzQ8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+PGENCmhy
ZWY9Im1haWx0bzpEaWV0ZXIuQmVsbGVyQGFsY2F0ZWwtbHVjZW50LmNvbSI+RGlldGVyLkJlbGxl
ckBhbGNhdGVsLWx1Y2VudC5jb208L2E+PGJyPg0KPGJyPg0KPC9zcGFuPjwvYj48L3NwYW4+PC9m
b250Pjxmb250IHNpemU9MSBjb2xvcj0iIzY2MzliNyIgZmFjZT1UYWhvbWE+PHNwYW4NCnN0eWxl
PSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6VGFob21hO2NvbG9yOiM2NjM5QjcnPkFsY2F0
ZWwtTHVjZW50DQpEZXV0c2NobGFuZCBBRzxicj4NCkRvbWljaWxlIG9mIHRoZSBDb21wYW55OiBT
dHV0dGdhcnQgwrcgTG9jYWwgQ291cnQgU3R1dHRnYXJ0IEhSQiA0MDI2PGJyPg0KQ2hhaXJtYW4g
b2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBNaWNoYWVsIE9wcGVuaG9mZjxicj4NCkJvYXJkIG9m
IE1hbmFnZW1lbnQ6IFdpbGhlbG0gRHJlc3NlbGhhdXMgKENoYWlybWFuKSDCtyBIYW5zLUrDtnJn
IERhdWIgwrc8YnI+DQpEci4gUmFpbmVyIEZlY2huZXIgwrcgQW5kcmVhcyBHZWhlPGJyPg0KPGJy
Pg0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55LCBtYXkgY29udGFpbiBj
b25maWRlbnRpYWwgaW5mb3JtYXRpb24uPGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl
LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgYW5kIGRlbGV0ZSBvcg0KZGVzdHJveSB0
aGU8YnI+DQplLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cywgaWYgYW55LCBpbW1lZGlhdGVseS4g
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcw0KZS1tYWlsIGluPGJyPg0KZXJyb3IsIHlvdSBtdXN0
IG5vdCBmb3J3YXJkIG9yIG1ha2UgdXNlIG9mIHRoZSBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50
cywgaWYNCmFueS48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9k
aXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0K
PC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo=

--_000_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_--

--_004_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=5715;
	creation-date="Tue, 18 Sep 2012 13:22:35 GMT";
	modification-date="Tue, 18 Sep 2012 13:22:35 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b
AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC
AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAGAgMBAAAAAAAAAAAA
AAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAACAQMEAQMDAgMDAwIG
CXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIKGcHRNSfhUzaC8ZKi
RFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdoaWp2d3h5eoWGh4iJ
ipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT19vf4+foRAAIBAwIE
BAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMY
Y0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4
doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq
+v/aAAwDAQACEQMRAD8A3+Pfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvn
sm0T1ExVp4aKgx+PpIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBV
RQWdjhVBPl09bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnD
snYeNhlSt353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs
6eNOxxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q
XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ7Acj
e43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BINKHjT7QSP
l1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3PH4/Pq/b0eT0
e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT51rSnRWch3x82aXq
D5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7jxFdV1j4TJaq6J6L7a/l
kQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1+i9/YvC0VVt7r6j2f9umY7C/
jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4KYys7u617g3DtL45dIN8iev44/kN1
HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWpjPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN
0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72iyUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfP
qn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0dL3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkF
WRjEDeM1aInut0WtK46Hyr7F+REPyX2R1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvW
b0i7jz1LWYYx1K5iFkpWMrKQhgZZPdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh
1/HTdgdV0u+MRhIO0YOz5aBNt4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0H
FV/Gyr6SrN75T5Mnsfb0E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/I
n5+r8YMp2ZT/AAAoJPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6P
fut0WtK4+zoxq9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNE
SRCCZCQvutUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9pp
iTtrKyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD
bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y8h8B
8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm1HVSyx+/
dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr5+uzTrn9ttja
eJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b310AfkPsCeDoPqKv3
bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaHyVl787t2HP8AGeli6R2R
1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoWYI8c6BPdaoKcc9BLi++PnVU9
IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq0W8o6WTC9mVWJ29j8dkP4JjmWtL5
E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11tfcXx07THcm1UqPkPv7J7Xq8luHYNbtE0
L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q95/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2
M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Tiz91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx
8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZnObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8A
Y6S1D3l8yKjY/wAOs3UfC+Cm3h3HurA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0z
OT4L+V1ce63Rc5+zrXk/m+/NPFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27
fkrt/dO69n7RzOydsQYf4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQv
eG1+kG+YX8475J7RHyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWq
qJI09+69QUqRWi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou
3N0bl7bh7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP
/n3fIf4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd
WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D2f1j
uzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1qiUOe2or5
06MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7oxc9PgMzNkcNHF
kIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi06hgjpyeOGOR0t38S
EEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2fUz/7L/2dlPieazAU9AaO
T+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z9H8DvlB/M/h762NkqPau5e3u
v9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7cFNU1VJjK2i/ap6emp5EqT7reldQT
+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM
/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+
SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cuLyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7
/hQ7W75qfjn8beq9vy1mal7A7yo6KvpKKlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+
8sfulw7fFzVu283xVTabWSHbgiNIpkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt74
2fyrYqvMb7+RvyK33s7fPy0oNgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHk
q9o6Srnp8od3vMvNvOF3vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXb
S7xhbWJSI9Qr8u0cKk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5
Jtr9LVf9/cbi8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WV
oZGuKSXY8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv
/u5/EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V
MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7AhlpnTdC5HaVFFj
pVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w8FNt+u3vjtqYfY2O
3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjNz7Oqcl8PuhpZthbewm09
sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63rb1PSw3N8BfhPvPcvbe8N2fF
force5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3FUlcKtl+7NZSQTmQywxuvuvam9Tj
pWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2
MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7ifx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/
AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSx
HX2Dx22tgxYlkpBTRVmx9vYejosPVtG1XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+
3Oz9uZ/aXY2+JuvduT5TfO392U70m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnT
L13/AC+vhL1NjosR1z8Yen9p4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4
o8aaiT7dYw7X91ssx4npT9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ3
3Xzz0xqTuyh2hQxYpK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7L
VQlpsPg947Zo6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBco
tNTQuQSVBoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ
2D2xHndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3
b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U49O+
U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN25jcvXfa
4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMiapnXUqqFLJEr
N1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h/wANi+4/0ufxn++n
9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sNWPpdHg+Bq4avB/Hpp4v6
mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697917r3v3Xuve/de697917r3v3
Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6
97917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3XugA+RP/AB59D/zI
D/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9
J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8AN3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/a
n4/9v8X59C17IumOv//Z

--_004_F050945A8D8E9A44A71039532BA344D80578EC3BCFFRMRSSXCHMBSB_--

From swallow@cisco.com  Tue Sep 18 06:45: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 576BD21F865C for ; Tue, 18 Sep 2012 06:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltKDul8NepyX for ; Tue, 18 Sep 2012 06:45:12 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E961A21F865B for ; Tue, 18 Sep 2012 06:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5031; q=dns/txt; s=iport; t=1347975912; x=1349185512; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aHdA87ApjGEn5+158p2EKUNfLC8LmVm/YA726j4j7F4=; b=iQUlYz6seyVNDsb+LDds55pL5sh8XttwDIl413fCAK7Kl3bZc/iQTft2 iFeD5Ogi05OsDltrWibNldkQ2sRMr4fGNcytB25eiwWcB9MmZuTp8Heny OZJwDZTmQlWRcGq99J72h3oQuXJbJH2kKxQxTDTavqDsxd4QqCMAz753a Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAJV5WFCtJV2c/2dsb2JhbABFvDSBB4IgAQEBBAEBAQ8BWwQHEgEIDgMEAQEBVQsdCAIEAQ0FGweHXguaAqAqBIshhmgDkjGDMY44gWmCZoIX
X-IronPort-AV: E=Sophos;i="4.80,442,1344211200"; d="scan'208";a="122763159"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 18 Sep 2012 13:45:05 +0000
Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8IDj48E021945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 13:45:04 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 08:45:04 -0500
From: "George Swallow (swallow)" 
To: Gert Grammel , Julien Meuric 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqG4OOKfbxolEe2spFvFX1LfJeQLiYA
Date: Tue, 18 Sep 2012 13:45:04 +0000
Message-ID: 
In-Reply-To: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.32.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004
x-tm-as-result: No--52.086500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <74E32C7D3B36C74596451ED1D12F5E68@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 13:45:13 -0000

Gert -

Agreed.  I was loose in my terminology.  The Objective function is
information that is signaled to the routing function as a constraint.
There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-hop
in an ERO.  Another example would be Resource Affinities signaled in the
Session Attribute object.

...George

On 9/17/12 5:22 PM, "Gert Grammel"  wrote:

>Hi George,
>
>The objective function is in the end a routing information. Mixing
>routing and signaling in one protocol is something I don't feel
>comfortable with.
>
>In other words, if routing is needed between client and server, UNI is
>the wrong choice. ENNI should be considered instead and
>Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>
>
>Gert
>
>
>
>________________________________________
>From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>Sent: Monday, September 17, 2012 12:19:21 PM
>To: Julien Meuric
>Cc: ccamp@ietf.org
>Subject: Re: [CCAMP] Objective function draft
>
>Hi Julien -
>
>On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>
>>Hi George.
>>
>>Sorry for the late response. You are right: the minutes are not enough
>>to trace the full discussion (which we also resumed right after the
>>meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>>author of... ;-) ) for bringing the PCE-associated vocabulary to a
>>common understanding.
>>
>>Actually my concern is sustained by 2 points:
>>
>>1- The scope of the draft is about giving control of the routing
>>objective function to the client node facing a transport layer. I see
>>already several existing solution to achieve it:
>>- a PCEP request from the signaling head node is an option (which is
>>associated to the advertisement of the supported objectives in PCEP);
>>- building IGP adjacencies between client and transport edge nodes
>>(a.k.a. "border model") is another one.
>>In this context, it do not think extending RSVP-TE for this kind of
>>application is worth the effort, since the requirement can already be
>>addressed.
>
>As I understand it, in the optical and OTN cases, the border model would
>not be popular
>as in many organizations this crosses political boundaries.
>
>The point of the draft is to keep the UNI implementation simple and not
>require a PCEP on the uni-c or necessarily on the uni-n.  We will keep the
>format aligned so if the UNI-N needs to make a request of a PCS, it can do
>so rather simply.
>>
>>2- There are cases when previous options are ruled out of a given
>>deployment. I do believe that it is not simply due to protocol
>>exclusion, but rather to the fact that the SP wants transport routing
>>decisions to remain entirely within the transport network (in order to
>>fully leave the routing policy in the hands of people doing the layer
>>dimensioning). Thus, I feel this trade-off in path selection tuning is
>>rather unlikely to happen and I fear we may be talking about RSVP-TE
>>over-engineering here.
>
>The idea is simply to allow the client to express its needs/wishes.  The
>UNI-N remains in control.  By policy it can use the objective function or
>not.  Further if it does use the objective function and fails to find a
>path it can either say that there was no path or it
>proceed to setup what it can.
>
>>(That is also why I preferred to consider your
>>I-Ds separately during the CCAMP meeting.)
>
>Agreed.  I will ask for separate slots.  The discussion at the end was
>rather disjointed.
>
>>
>>However, my comments are mostly related to the client/transport
>>relationship. If the I-D is extended to cover more use cases with wider
>>scopes (Adrian has made interesting suggestions), turning the overlay
>>interconnection into one among a longer list, then my conclusion may be
>>different.
>
>I'm happy to widen the scope in this way.
>
>...George
>
>>Regards,
>>
>>Julien
>>
>>
>>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>> Julien -
>>>
>>> Reading the CCAMP notes (which capture little of the actual
>>> discussion) I see that there may have been a perception in the room
>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>
>>> This is not the case. The reason for our draft is that with the UNI,
>>> much of the functionality that resides at the headend is moved to the
>>> UNI-N. So the UNI-C needs a way to express an objective function even
>>> if there is no PCE.
>>>
>>> Operationally it seems burdensome to require a PCEP at the UNI-C and a
>>> PCEP at the UNI-N, when all that is being done is enabling the UNI-N
>>> to perform what the client would do if it were connected to the
>>> network via a normal link.
>>>
>>> Do you still object to the draft?
>>>
>>> Thanks,
>>>
>>> =A9George
>>
>>
>
>_______________________________________________
>CCAMP mailing list
>CCAMP@ietf.org
>https://www.ietf.org/mailman/listinfo/ccamp
>
>


From vishnupavan@gmail.com  Tue Sep 18 06:50: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 E540121F860D for ; Tue, 18 Sep 2012 06:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCmrjwoSR4oQ for ; Tue, 18 Sep 2012 06:50:19 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D67921F8608 for ; Tue, 18 Sep 2012 06:50:19 -0700 (PDT)
Received: by qafi29 with SMTP id i29so2566324qaf.10 for ; Tue, 18 Sep 2012 06:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LocIzuyh1oEnaGj3lRGbLXHhbWxVOlVFlgd7TDul2H0=; b=SOgfB2z12gH4IK9C9WkFH+UwOSauMIatYisE/6FRuyZnKBfBKHEgW1626AHJGIUxmS 0r8kMd+6FzIJQ9ChKZ4YR+5lXOzLP0hCm6yXvLc5M/LKcnOe4heGgNaR8DUqGlB02c09 SUibdcHueqAhuwkQhNlhoN7h3husTxGyGPO065zDvS+21dN62WRJbrczwS/V+7B9NJR7 KYOq1AEbVHR/Oq9LuWWyVSEW9w0+DZglWcXBKL0FGxCueKrG4+K6NsBTxcenkR35ehQk onF5ZYWxxTtDe17cH2vvEgi2AnuMiFx0lInKIscxezuEi92PKjQi7pK/p53yjVQkFfqh STaA==
MIME-Version: 1.0
Received: by 10.229.136.17 with SMTP id p17mr80991qct.139.1347976218876; Tue, 18 Sep 2012 06:50:18 -0700 (PDT)
Received: by 10.49.51.197 with HTTP; Tue, 18 Sep 2012 06:50:18 -0700 (PDT)
In-Reply-To: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> 
Date: Tue, 18 Sep 2012 09:50:18 -0400
Message-ID: 
From: Vishnu Pavan Beeram 
To: Daniele Ceccarelli 
Content-Type: multipart/alternative; boundary=00248c70f9f1b11ac604c9fa2b85
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 13:50:21 -0000

--00248c70f9f1b11ac604c9fa2b85
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Totally agree with Daniele.

On a side note, I think it is time we defined within CCAMP what we really
mean by the terms "GMPLS-UNI" and "GMPLS-ENNI". I wouldn't want to avoid
using these terms -- would rather want to see the confusion around these
terms lifted once and for all.

Regards,
-Vishnu

On Tue, Sep 18, 2012 at 3:19 AM, Daniele Ceccarelli <
daniele.ceccarelli@ericsson.com> wrote:

> +0.5
>
> Fully agree on the second part of your statement. At the time of RFC4208
> the UNI allowed the exchange of signaling and routing messages. Now that
> we're defining also the E-NNI i would prefer to have:
>
> - UNI: signaling only
> - E-NNI: signaling AND routing (i would prefer to call it reachability
> rather than routing, because it is not a topology info)
>
> That said, i think that objective function (despite the correct comments
> from Julien) is not routing but a constraint. The ingress node of the
> overlay network asks the ingress node of the core network for a path
> computation with given constraints.
>
> Viceversa in the case of E-NNI if the objective function was exported to
> the overlay network as a "property" of a virtual link, then i agree it wa=
s
> routing (reachability) information.
>
> Cheers,
> Daniele
>
> >-----Original Message-----
> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
> >On Behalf Of Gert Grammel
> >Sent: luned=C3=AC 17 settembre 2012 23.22
> >To: George Swallow (swallow); Julien Meuric
> >Cc: ccamp@ietf.org
> >Subject: Re: [CCAMP] Objective function draft
> >
> >Hi George,
> >
> >The objective function is in the end a routing information.
> >Mixing routing and signaling in one protocol is something I
> >don't feel comfortable with.
> >
> >In other words, if routing is needed between client and
> >server, UNI is the wrong choice. ENNI should be considered
> >instead and Draft-beeram-ccamp-gmpls-enni would be a good
> >starting point.
> >
> >
> >Gert
> >
> >
> >
> >________________________________________
> >From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
> >Sent: Monday, September 17, 2012 12:19:21 PM
> >To: Julien Meuric
> >Cc: ccamp@ietf.org
> >Subject: Re: [CCAMP] Objective function draft
> >
> >Hi Julien -
> >
> >On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
> >
> >>Hi George.
> >>
> >>Sorry for the late response. You are right: the minutes are
> >not enough
> >>to trace the full discussion (which we also resumed right after the
> >>meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
> >>author of... ;-) ) for bringing the PCE-associated vocabulary to a
> >>common understanding.
> >>
> >>Actually my concern is sustained by 2 points:
> >>
> >>1- The scope of the draft is about giving control of the routing
> >>objective function to the client node facing a transport layer. I see
> >>already several existing solution to achieve it:
> >>- a PCEP request from the signaling head node is an option (which is
> >>associated to the advertisement of the supported objectives in PCEP);
> >>- building IGP adjacencies between client and transport edge nodes
> >>(a.k.a. "border model") is another one.
> >>In this context, it do not think extending RSVP-TE for this kind of
> >>application is worth the effort, since the requirement can already be
> >>addressed.
> >
> >As I understand it, in the optical and OTN cases, the border
> >model would not be popular as in many organizations this
> >crosses political boundaries.
> >
> >The point of the draft is to keep the UNI implementation
> >simple and not require a PCEP on the uni-c or necessarily on
> >the uni-n.  We will keep the format aligned so if the UNI-N
> >needs to make a request of a PCS, it can do so rather simply.
> >>
> >>2- There are cases when previous options are ruled out of a given
> >>deployment. I do believe that it is not simply due to protocol
> >>exclusion, but rather to the fact that the SP wants transport routing
> >>decisions to remain entirely within the transport network (in
> >order to
> >>fully leave the routing policy in the hands of people doing the layer
> >>dimensioning). Thus, I feel this trade-off in path selection
> >tuning is
> >>rather unlikely to happen and I fear we may be talking about RSVP-TE
> >>over-engineering here.
> >
> >The idea is simply to allow the client to express its
> >needs/wishes.  The UNI-N remains in control.  By policy it can
> >use the objective function or not.  Further if it does use the
> >objective function and fails to find a path it can either say
> >that there was no path or it proceed to setup what it can.
> >
> >>(That is also why I preferred to consider your I-Ds separately during
> >>the CCAMP meeting.)
> >
> >Agreed.  I will ask for separate slots.  The discussion at the
> >end was rather disjointed.
> >
> >>
> >>However, my comments are mostly related to the client/transport
> >>relationship. If the I-D is extended to cover more use cases
> >with wider
> >>scopes (Adrian has made interesting suggestions), turning the overlay
> >>interconnection into one among a longer list, then my
> >conclusion may be
> >>different.
> >
> >I'm happy to widen the scope in this way.
> >
> >...George
> >
> >>Regards,
> >>
> >>Julien
> >>
> >>
> >>Le 11/09/2012 21:28, George Swallow (swallow) a =C3=A9crit :
> >>> Julien -
> >>>
> >>> Reading the CCAMP notes (which capture little of the actual
> >>> discussion) I see that there may have been a perception in the room
> >>> that PCE functionality at the UNI-N was assumed (actual or proxy).
> >>>
> >>> This is not the case. The reason for our draft is that with
> >the UNI,
> >>> much of the functionality that resides at the headend is
> >moved to the
> >>> UNI-N. So the UNI-C needs a way to express an objective
> >function even
> >>> if there is no PCE.
> >>>
> >>> Operationally it seems burdensome to require a PCEP at the
> >UNI-C and
> >>> a PCEP at the UNI-N, when all that is being done is enabling the
> >>> UNI-N to perform what the client would do if it were
> >connected to the
> >>> network via a normal link.
> >>>
> >>> Do you still object to the draft?
> >>>
> >>> Thanks,
> >>>
> >>> =C5=A0George
> >>
> >>
> >
> >_______________________________________________
> >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
>

--00248c70f9f1b11ac604c9fa2b85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Totally agree with Daniele.

On a side note, I think it i=
s time we defined within CCAMP what we really mean by the terms "GMPLS=
-UNI" and "GMPLS-ENNI". I wouldn't want to avoid using t=
hese terms -- would rather want to see the confusion around these terms lif=
ted once and for all.



Regards,
-Vishnu

On Tue, Sep 18, 2012 at 3:19 AM, Daniele Ceccarelli <d=
aniele.ceccarelli@ericsson.com> wrote:


+0.5



Fully agree on the second part of your statement. At the time of RFC4208 th=
e UNI allowed the exchange of signaling and routing messages. Now that we&#=
39;re defining also the E-NNI i would prefer to have:



- UNI: signaling only

- E-NNI: signaling AND routing (i would prefer to call it reachability rath=
er than routing, because it is not a topology info)



That said, i think that objective function (despite the correct comments fr=
om Julien) is not routing but a constraint. The ingress node of the overlay=
 network asks the ingress node of the core network for a path computation w=
ith given constraints.




Viceversa in the case of E-NNI if the objective function was exported to th=
e overlay network as a "property" of a virtual link, then i agree=
 it was routing (reachability) information.



Cheers,

Daniele




>-----Original Message-----

>From: ccamp-bounces@ietf.org<=
/a> [mailto:ccamp-bounces@ietf.or=
g]


>On Behalf Of Gert Grammel=


>Sent: luned=C3=AC 17 settembre 2012 23.22

>To: George Swallow (swallow); Julien Meuric

>Cc: ccamp@ietf.org

>Subject: Re: [CCAMP] Objective function draft

>

>Hi George,

>

>The objective function is in the end a routing information.

>Mixing routing and signaling in one protocol is something I

>don't feel comfortable with.

>

>In other words, if routing is needed between client and

>server, UNI is the wrong choice. ENNI should be considered

>instead and Draft-beeram-ccamp-gmpls-enni would be a good

>starting point.

>

>

>Gert

>

>

>

>________________________________________

>From: ccamp-bounces@ietf.org<=
/a> on behalf of George Swallow (swallow)

>Sent: Monday, September 17, 2012 12:19:21 PM

>To: Julien Meuric

>Cc: ccamp@ietf.org

>Subject: Re: [CCAMP] Objective function draft

>

>Hi Julien -

>

>On 9/17/12 9:37 AM, "Julien Meuric" <julien.meuric@orange.com> wrote:

>

>>Hi George.

>>

>>Sorry for the late response. You are right: the minutes are

>not enough

>>to trace the full discussion (which we also resumed right after the=


>>meeting). Let us start by thanking Adrian (as AD? former PCE co-cha=
ir?

>>author of... ;-) ) for bringing the PCE-associated vocabulary to a<=
br>
>>common understanding.

>>

>>Actually my concern is sustained by 2 points:

>>

>>1- The scope of the draft is about giving control of the routing
>>objective function to the client node facing a transport layer. I s=
ee

>>already several existing solution to achieve it:

>>- a PCEP request from the signaling head node is an option (which i=
s

>>associated to the advertisement of the supported objectives in PCEP=
);

>>- building IGP adjacencies between client and transport edge nodes<=
br>
>>(a.k.a. "border model") is another one.

>>In this context, it do not think extending RSVP-TE for this kind of=


>>application is worth the effort, since the requirement can already =
be

>>addressed.

>

>As I understand it, in the optical and OTN cases, the border

>model would not be popular as in many organizations this

>crosses political boundaries.

>

>The point of the draft is to keep the UNI implementation

>simple and not require a PCEP on the uni-c or necessarily on

>the uni-n. =C2=A0We will keep the format aligned so if the UNI-N

>needs to make a request of a PCS, it can do so rather simply.

>>

>>2- There are cases when previous options are ruled out of a given
>>deployment. I do believe that it is not simply due to protocol

>>exclusion, but rather to the fact that the SP wants transport routi=
ng

>>decisions to remain entirely within the transport network (in

>order to

>>fully leave the routing policy in the hands of people doing the lay=
er

>>dimensioning). Thus, I feel this trade-off in path selection

>tuning is

>>rather unlikely to happen and I fear we may be talking about RSVP-T=
E

>>over-engineering here.

>

>The idea is simply to allow the client to express its

>needs/wishes. =C2=A0The UNI-N remains in control. =C2=A0By policy it ca=
n

>use the objective function or not. =C2=A0Further if it does use the

>objective function and fails to find a path it can either say

>that there was no path or it proceed to setup what it can.

>

>>(That is also why I preferred to consider your I-Ds separately duri=
ng

>>the CCAMP meeting.)

>

>Agreed. =C2=A0I will ask for separate slots. =C2=A0The discussion at th=
e

>end was rather disjointed.

>

>>

>>However, my comments are mostly related to the client/transport

>>relationship. If the I-D is extended to cover more use cases

>with wider

>>scopes (Adrian has made interesting suggestions), turning the overl=
ay

>>interconnection into one among a longer list, then my

>conclusion may be

>>different.

>

>I'm happy to widen the scope in this way.

>

>...George

>

>>Regards,

>>

>>Julien

>>

>>

>>Le 11/09/2012 21:28, George Swallow (swallow) a =C3=A9crit :

>>> Julien -

>>>

>>> Reading the CCAMP notes (which capture little of the actual
>>> discussion) I see that there may have been a perception in the=
 room

>>> that PCE functionality at the UNI-N was assumed (actual or pro=
xy).

>>>

>>> This is not the case. The reason for our draft is that with
>the UNI,

>>> much of the functionality that resides at the headend is

>moved to the

>>> UNI-N. So the UNI-C needs a way to express an objective

>function even

>>> if there is no PCE.

>>>

>>> Operationally it seems burdensome to require a PCEP at the

>UNI-C and

>>> a PCEP at the UNI-N, when all that is being done is enabling t=
he

>>> UNI-N to perform what the client would do if it were

>connected to the

>>> network via a normal link.

>>>

>>> Do you still object to the draft?

>>>

>>> Thanks,

>>>

>>> =C5=A0George

>>

>>

>

>_______________________________________________

>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

h=
ttps://www.ietf.org/mailman/listinfo/ccamp





--00248c70f9f1b11ac604c9fa2b85--

From prvs=46084d3bd1=lyong@ciena.com  Tue Sep 18 07: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 5665E21F8611 for ; Tue, 18 Sep 2012 07:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.265
X-Spam-Level: 
X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI4GGPf0ghyr for ; Tue, 18 Sep 2012 07:27:31 -0700 (PDT)
Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id C067C21F860D for ; Tue, 18 Sep 2012 07:27:31 -0700 (PDT)
Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q8IEPB1Y025339; Tue, 18 Sep 2012 10:27:29 -0400
Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 17erny0dyp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Sep 2012 10:27:29 -0400
Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 18 Sep 2012 10:27:29 -0400
Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXCHCGSIHT01.ciena.com ([::1]) with mapi; Tue, 18 Sep 2012 10:27:28 -0400
From: "Ong, Lyndon" 
To: Julien Meuric , Daniele Ceccarelli 
Date: Tue, 18 Sep 2012 10:27:27 -0400
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2ViPuHvajUZUi2QUqmNo1l59hqDgAIJrfA
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  <50584DCE.5090407@orange.com>
In-Reply-To: <50584DCE.5090407@orange.com>
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-7.000.1014-19190.007
X-TM-AS-Result: No--20.789800-8.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
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.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-18_01:2012-09-18, 2012-09-17, 1970-01-01 signatures=0
X-Proofpoint-Spam-Reason: safe
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 14:27:32 -0000

I agree with Julien.  (Sorry about the time zone delay)

Lyndon

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J=
ulien Meuric
Sent: Tuesday, September 18, 2012 3:33 AM
To: Daniele Ceccarelli
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi Daniele.

That is a good idea to bring back this issue we did not have time to discus=
s in details in Vancouver.

As far as I used to understand:
- UNI stands for User-to-Network, which refers to client-server relationshi=
p;
- NNI stands for Network-to-Network, which refers to inter-domain relations=
hip within a common technology.

I believe the protocols we use on those interfaces is orthogonal to their t=
ype. E.g. one can do signaling only over an E-NNI; building an IGP-TE adjac=
ency on the tributary links (UNI) of my WDM network does not transmute my U=
NI into an NNI. Boundaries are not defined with respect to control protocol=
s, in CCAMP we put protocols between network nodes, including boundaries, w=
e do not change boundary names...
That is also why I prefer to use accurate phrases such as "signaling protoc=
ol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms, which are somet=
imes too loose for a protocol specification context like CCAMP.

Cheers,

Julien


On 09/18/2012 09:19, Daniele Ceccarelli wrote:
> Fully agree on the second part of your statement. At the time of RFC4208 =
the UNI allowed the exchange of signaling and routing messages. Now that we=
're defining also the E-NNI i would prefer to have:
>
> - UNI: signaling only
> - E-NNI: signaling AND routing (i would prefer to call it reachability=20
> rather than routing, because it is not a topology info)


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

From IBryskin@advaoptical.com  Tue Sep 18 08:04: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 4B81621E80D2 for ; Tue, 18 Sep 2012 08:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Dy2Dzz-3KO0 for ; Tue, 18 Sep 2012 08:04:45 -0700 (PDT)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE1921E80D3 for ; Tue, 18 Sep 2012 08:04:43 -0700 (PDT)
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 q8IF4aOc013653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 17:04:37 +0200
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.3.83.0; Tue, 18 Sep 2012 17:04:36 +0200
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.03.0083.000; Tue, 18 Sep 2012 11:04:33 -0400
From: Igor Bryskin 
To: "George Swallow (swallow)" , Gert Grammel , Julien Meuric 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGvMjYkYKv7UmMh7Ftclf6H5eQYHYA///NLzA=
Date: Tue, 18 Sep 2012 15:04:33 +0000
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-18_01:2012-09-18, 2012-09-17, 1970-01-01 signatures=0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 15:04:46 -0000

I completely agree with George. Signaling the objective function is no diff=
erent from signaling EROs or affinities, this is just another service speci=
fic policy, an instruction to the network as to how the service needs to be=
 routed across the network domain. I think Georges documents complement our=
 (GMPLS-ENNI) solution. We have the same objective but target different gro=
ups of clients. Specifically, George's clients are those who cannot or won'=
t deal with the routing information leaked by the network, but have certain=
 preferences' as to how their services need to be routed and rely fully on =
the network to do the routing. Our clients are those that are capable and w=
illing to process the network advertisements and to control the routing the=
mselves.

Cheers,
Igor

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G=
eorge Swallow (swallow)
Sent: Tuesday, September 18, 2012 9:45 AM
To: Gert Grammel; Julien Meuric
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Gert -

Agreed.  I was loose in my terminology.  The Objective function is informat=
ion that is signaled to the routing function as a constraint.
There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-hop in=
 an ERO.  Another example would be Resource Affinities signaled in the Sess=
ion Attribute object.

...George

On 9/17/12 5:22 PM, "Gert Grammel"  wrote:

>Hi George,
>
>The objective function is in the end a routing information. Mixing=20
>routing and signaling in one protocol is something I don't feel=20
>comfortable with.
>
>In other words, if routing is needed between client and server, UNI is=20
>the wrong choice. ENNI should be considered instead and=20
>Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>
>
>Gert
>
>
>
>________________________________________
>From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>Sent: Monday, September 17, 2012 12:19:21 PM
>To: Julien Meuric
>Cc: ccamp@ietf.org
>Subject: Re: [CCAMP] Objective function draft
>
>Hi Julien -
>
>On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>
>>Hi George.
>>
>>Sorry for the late response. You are right: the minutes are not enough=20
>>to trace the full discussion (which we also resumed right after the=20
>>meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>>author of... ;-) ) for bringing the PCE-associated vocabulary to a=20
>>common understanding.
>>
>>Actually my concern is sustained by 2 points:
>>
>>1- The scope of the draft is about giving control of the routing=20
>>objective function to the client node facing a transport layer. I see=20
>>already several existing solution to achieve it:
>>- a PCEP request from the signaling head node is an option (which is=20
>>associated to the advertisement of the supported objectives in PCEP);
>>- building IGP adjacencies between client and transport edge nodes=20
>>(a.k.a. "border model") is another one.
>>In this context, it do not think extending RSVP-TE for this kind of=20
>>application is worth the effort, since the requirement can already be=20
>>addressed.
>
>As I understand it, in the optical and OTN cases, the border model=20
>would not be popular as in many organizations this crosses political=20
>boundaries.
>
>The point of the draft is to keep the UNI implementation simple and not=20
>require a PCEP on the uni-c or necessarily on the uni-n.  We will keep=20
>the format aligned so if the UNI-N needs to make a request of a PCS, it=20
>can do so rather simply.
>>
>>2- There are cases when previous options are ruled out of a given=20
>>deployment. I do believe that it is not simply due to protocol=20
>>exclusion, but rather to the fact that the SP wants transport routing=20
>>decisions to remain entirely within the transport network (in order to=20
>>fully leave the routing policy in the hands of people doing the layer=20
>>dimensioning). Thus, I feel this trade-off in path selection tuning is=20
>>rather unlikely to happen and I fear we may be talking about RSVP-TE=20
>>over-engineering here.
>
>The idea is simply to allow the client to express its needs/wishes. =20
>The UNI-N remains in control.  By policy it can use the objective=20
>function or not.  Further if it does use the objective function and=20
>fails to find a path it can either say that there was no path or it=20
>proceed to setup what it can.
>
>>(That is also why I preferred to consider your I-Ds separately during=20
>>the CCAMP meeting.)
>
>Agreed.  I will ask for separate slots.  The discussion at the end was=20
>rather disjointed.
>
>>
>>However, my comments are mostly related to the client/transport=20
>>relationship. If the I-D is extended to cover more use cases with=20
>>wider scopes (Adrian has made interesting suggestions), turning the=20
>>overlay interconnection into one among a longer list, then my=20
>>conclusion may be different.
>
>I'm happy to widen the scope in this way.
>
>...George
>
>>Regards,
>>
>>Julien
>>
>>
>>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>> Julien -
>>>
>>> Reading the CCAMP notes (which capture little of the actual
>>> discussion) I see that there may have been a perception in the room=20
>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>
>>> This is not the case. The reason for our draft is that with the UNI,=20
>>> much of the functionality that resides at the headend is moved to=20
>>> the UNI-N. So the UNI-C needs a way to express an objective function=20
>>> even if there is no PCE.
>>>
>>> Operationally it seems burdensome to require a PCEP at the UNI-C and=20
>>> a PCEP at the UNI-N, when all that is being done is enabling the=20
>>> UNI-N to perform what the client would do if it were connected to=20
>>> the network via a normal link.
>>>
>>> Do you still object to the draft?
>>>
>>> Thanks,
>>>
>>> =A9George
>>
>>
>
>_______________________________________________
>CCAMP mailing list
>CCAMP@ietf.org
>https://www.ietf.org/mailman/listinfo/ccamp
>
>

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

From jdrake@juniper.net  Tue Sep 18 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 071F321F85F9 for ; Tue, 18 Sep 2012 08:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5WXa3rpQsta for ; Tue, 18 Sep 2012 08:08:16 -0700 (PDT)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4279B21F8527 for ; Tue, 18 Sep 2012 08:08:05 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUFiOUlvKg0DqntGsIWSzhp+yLXsupc3g@postini.com; Tue, 18 Sep 2012 08:08:10 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::3c95:ce07:f642:ecd2%10]) with mapi; Tue, 18 Sep 2012 08:07:27 -0700
From: John E Drake 
To: Igor Bryskin , "George Swallow (swallow)" , Gert Grammel , Julien Meuric 
Date: Tue, 18 Sep 2012 08:07:24 -0700
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGvMjYkYKv7UmMh7Ftclf6H5eQYHYA///NLzCAAAaD4A==
Message-ID: <5E893DB832F57341992548CDBB333163A6330D6666@EMBX01-HQ.jnpr.net>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 15:08:17 -0000

Is there a requirement that the objective function specified by the user be=
 acceptable to the network?

Yours irrespectively,

John


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Igor Bryskin
> Sent: Tuesday, September 18, 2012 8:05 AM
> To: George Swallow (swallow); Gert Grammel; Julien Meuric
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> I completely agree with George. Signaling the objective function is no
> different from signaling EROs or affinities, this is just another
> service specific policy, an instruction to the network as to how the
> service needs to be routed across the network domain. I think Georges
> documents complement our (GMPLS-ENNI) solution. We have the same
> objective but target different groups of clients. Specifically,
> George's clients are those who cannot or won't deal with the routing
> information leaked by the network, but have certain preferences' as to
> how their services need to be routed and rely fully on the network to
> do the routing. Our clients are those that are capable and willing to
> process the network advertisements and to control the routing
> themselves.
>=20
> Cheers,
> Igor
>=20
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of George Swallow (swallow)
> Sent: Tuesday, September 18, 2012 9:45 AM
> To: Gert Grammel; Julien Meuric
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> Gert -
>=20
> Agreed.  I was loose in my terminology.  The Objective function is
> information that is signaled to the routing function as a constraint.
> There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-
> hop in an ERO.  Another example would be Resource Affinities signaled
> in the Session Attribute object.
>=20
> ...George
>=20
> On 9/17/12 5:22 PM, "Gert Grammel"  wrote:
>=20
> >Hi George,
> >
> >The objective function is in the end a routing information. Mixing
> >routing and signaling in one protocol is something I don't feel
> >comfortable with.
> >
> >In other words, if routing is needed between client and server, UNI is
> >the wrong choice. ENNI should be considered instead and
> >Draft-beeram-ccamp-gmpls-enni would be a good starting point.
> >
> >
> >Gert
> >
> >
> >
> >________________________________________
> >From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
> >Sent: Monday, September 17, 2012 12:19:21 PM
> >To: Julien Meuric
> >Cc: ccamp@ietf.org
> >Subject: Re: [CCAMP] Objective function draft
> >
> >Hi Julien -
> >
> >On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
> >
> >>Hi George.
> >>
> >>Sorry for the late response. You are right: the minutes are not
> enough
> >>to trace the full discussion (which we also resumed right after the
> >>meeting). Let us start by thanking Adrian (as AD? former PCE co-
> chair?
> >>author of... ;-) ) for bringing the PCE-associated vocabulary to a
> >>common understanding.
> >>
> >>Actually my concern is sustained by 2 points:
> >>
> >>1- The scope of the draft is about giving control of the routing
> >>objective function to the client node facing a transport layer. I see
> >>already several existing solution to achieve it:
> >>- a PCEP request from the signaling head node is an option (which is
> >>associated to the advertisement of the supported objectives in PCEP);
> >>- building IGP adjacencies between client and transport edge nodes
> >>(a.k.a. "border model") is another one.
> >>In this context, it do not think extending RSVP-TE for this kind of
> >>application is worth the effort, since the requirement can already be
> >>addressed.
> >
> >As I understand it, in the optical and OTN cases, the border model
> >would not be popular as in many organizations this crosses political
> >boundaries.
> >
> >The point of the draft is to keep the UNI implementation simple and
> not
> >require a PCEP on the uni-c or necessarily on the uni-n.  We will keep
> >the format aligned so if the UNI-N needs to make a request of a PCS,
> it
> >can do so rather simply.
> >>
> >>2- There are cases when previous options are ruled out of a given
> >>deployment. I do believe that it is not simply due to protocol
> >>exclusion, but rather to the fact that the SP wants transport routing
> >>decisions to remain entirely within the transport network (in order
> to
> >>fully leave the routing policy in the hands of people doing the layer
> >>dimensioning). Thus, I feel this trade-off in path selection tuning
> is
> >>rather unlikely to happen and I fear we may be talking about RSVP-TE
> >>over-engineering here.
> >
> >The idea is simply to allow the client to express its needs/wishes.
> >The UNI-N remains in control.  By policy it can use the objective
> >function or not.  Further if it does use the objective function and
> >fails to find a path it can either say that there was no path or it
> >proceed to setup what it can.
> >
> >>(That is also why I preferred to consider your I-Ds separately during
> >>the CCAMP meeting.)
> >
> >Agreed.  I will ask for separate slots.  The discussion at the end was
> >rather disjointed.
> >
> >>
> >>However, my comments are mostly related to the client/transport
> >>relationship. If the I-D is extended to cover more use cases with
> >>wider scopes (Adrian has made interesting suggestions), turning the
> >>overlay interconnection into one among a longer list, then my
> >>conclusion may be different.
> >
> >I'm happy to widen the scope in this way.
> >
> >...George
> >
> >>Regards,
> >>
> >>Julien
> >>
> >>
> >>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
> >>> Julien -
> >>>
> >>> Reading the CCAMP notes (which capture little of the actual
> >>> discussion) I see that there may have been a perception in the room
> >>> that PCE functionality at the UNI-N was assumed (actual or proxy).
> >>>
> >>> This is not the case. The reason for our draft is that with the
> UNI,
> >>> much of the functionality that resides at the headend is moved to
> >>> the UNI-N. So the UNI-C needs a way to express an objective
> function
> >>> even if there is no PCE.
> >>>
> >>> Operationally it seems burdensome to require a PCEP at the UNI-C
> and
> >>> a PCEP at the UNI-N, when all that is being done is enabling the
> >>> UNI-N to perform what the client would do if it were connected to
> >>> the network via a normal link.
> >>>
> >>> Do you still object to the draft?
> >>>
> >>> Thanks,
> >>>
> >>> =A9George
> >>
> >>
> >
> >_______________________________________________
> >CCAMP mailing list
> >CCAMP@ietf.org
> >https://www.ietf.org/mailman/listinfo/ccamp
> >
> >
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From julien.meuric@orange.com  Tue Sep 18 08:53: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 EF5C321F8790 for ; Tue, 18 Sep 2012 08:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A04Jodn8D1ha for ; Tue, 18 Sep 2012 08:53:27 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5021F8783 for ; Tue, 18 Sep 2012 08:53:26 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EF861411106; Tue, 18 Sep 2012 17:53:25 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id E4AA84110C5; Tue, 18 Sep 2012 17:53:25 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Sep 2012 17:53:25 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 18 Sep 2012 17:53:25 +0200
Message-ID: <505898F4.3080004@orange.com>
Date: Tue, 18 Sep 2012 17:53:24 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniele Ceccarelli 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  <50584DCE.5090407@orange.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 18 Sep 2012 15:53:25.0422 (UTC) FILETIME=[BCE2ECE0:01CD95B5]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] UNI/NNI (was: Objective function draft)
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, 18 Sep 2012 15:53:28 -0000

Ciao Daniele.

Your intend to propose definitions was nice. I also believe that the 
ITU-T has identified some particular reference points which already have 
a functional definition (in G.8080?).

I think it is worth defining protocols that I can enable/disable/tune 
between my network elements.  I am not shocked if different reference 
points have protocols in common: I suspect this is the goal of common 
control...

Regards,

Julien


Le 18/09/2012 14:12, Daniele Ceccarelli a écrit :
> Hi Julien,
>
> Your argument is flawless, but if the only difference between UNI and NNI is the relationship between the two domains is it worth defining two different types of interface?
>
> My attempt (a bit clumpy) was to associate to each type of interface a given set of properties and functionalities. This also solves the problem of using unappropriate or not well defined language.
> E.g.
> - UNI: functionalies supported: A, B, C, -- Interface Properties: X, Y, Z
> - E-NNI: functionalities supported: A, D, E -- Interface Properties: X, W
>
> So that when you say UNI you automatically indentify certain properties and functionalities and when you say E-NNI different ones (not necessarily fully disjoint...A and X, for example, are in common)
>
> Cheers,
> Daniele
>
>> -----Original Message-----
>> From: Julien Meuric [mailto:julien.meuric@orange.com]
>>
>> Hi Daniele.
>>
>> That is a good idea to bring back this issue we did not have
>> time to discuss in details in Vancouver.
>>
>> As far as I used to understand:
>> - UNI stands for User-to-Network, which refers to
>> client-server relationship;
>> - NNI stands for Network-to-Network, which refers to
>> inter-domain relationship within a common technology.
>>
>> I believe the protocols we use on those interfaces is
>> orthogonal to their type. E.g. one can do signaling only over
>> an E-NNI; building an IGP-TE adjacency on the tributary links
>> (UNI) of my WDM network does not transmute my UNI into an NNI.
>> Boundaries are not defined with respect to control protocols,
>> in CCAMP we put protocols between network nodes, including
>> boundaries, we do not change boundary names...
>> That is also why I prefer to use accurate phrases such as
>> "signaling protocol/RSVP-TE" and "IGP", rather than "UNI" or
>> "NNI" acronyms, which are sometimes too loose for a protocol
>> specification context like CCAMP.
>>
>> Cheers,
>>
>> Julien
>>
>>
>> On 09/18/2012 09:19, Daniele Ceccarelli wrote:
>>> Fully agree on the second part of your statement. At the
>> time of RFC4208 the UNI allowed the exchange of signaling and
>> routing messages. Now that we're defining also the E-NNI i
>> would prefer to have:
>>> - UNI: signaling only
>>> - E-NNI: signaling AND routing (i would prefer to call it
>> reachability
>>> rather than routing, because it is not a topology info)
> >



From swallow@cisco.com  Tue Sep 18 13:47: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 E482621E8040 for ; Tue, 18 Sep 2012 13:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myEyBLGu2SkR for ; Tue, 18 Sep 2012 13:47:22 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B5A1B21E8037 for ; Tue, 18 Sep 2012 13:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7687; q=dns/txt; s=iport; t=1348001242; x=1349210842; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mppvNy4/o3jB2dUCoMlXLba6ZZX0uMmWZWtkYHM57es=; b=kUvPvi9B17XuPhnXJ4XSedrV9/nINbvd64dv5M0Hol0AnwlHYJ/nHvsb 5WDmE0sMWcv2aQuDPtnJaV5VLWd1sDfjPX9LJMoNPNa9YbJUiJ8gGYLKq a3y+xOwm5UWLP53bHVMrtDDI+0RrdEPYfeJUzb5IHEeRMlHfN0+RihugG k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGrdWFCtJV2c/2dsb2JhbABFvEKBCIIgAQEBBAEBAQ8BWwQHDAYBCBEEAQEBJy4LFAkIAgQBDQUbB4deC5ocoCYEixuGcAOSMoMxjjiBaYJmghc
X-IronPort-AV: E=Sophos;i="4.80,445,1344211200"; d="scan'208";a="122970682"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 18 Sep 2012 20:47:03 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8IKl3mP014883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Sep 2012 20:47:03 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Tue, 18 Sep 2012 15:47:03 -0500
From: "George Swallow (swallow)" 
To: John E Drake , Igor Bryskin , Gert Grammel , "Julien Meuric" 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqG4OOKfbxolEe2spFvFX1LfJeQLiYAgABZSICAAADMAIAAG88A
Date: Tue, 18 Sep 2012 20:47:02 +0000
Message-ID: 
In-Reply-To: <5E893DB832F57341992548CDBB333163A6330D6666@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.98.32.167]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19190.004
x-tm-as-result: No--50.040900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 18 Sep 2012 20:47:24 -0000

John -

The UNI-N can simply respond with no-route-to-destination.  Or would you
prefer a more policy specific error.  In any case the UNI-N has control.
AFAIK, that is the primary reason for a UNI in the first place!

//George


On 9/18/12 11:07 AM, "John E Drake"  wrote:

>Is there a requirement that the objective function specified by the user
>be acceptable to the network?
>
>Yours irrespectively,
>
>John
>
>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>> Of Igor Bryskin
>> Sent: Tuesday, September 18, 2012 8:05 AM
>> To: George Swallow (swallow); Gert Grammel; Julien Meuric
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Objective function draft
>>=20
>> I completely agree with George. Signaling the objective function is no
>> different from signaling EROs or affinities, this is just another
>> service specific policy, an instruction to the network as to how the
>> service needs to be routed across the network domain. I think Georges
>> documents complement our (GMPLS-ENNI) solution. We have the same
>> objective but target different groups of clients. Specifically,
>> George's clients are those who cannot or won't deal with the routing
>> information leaked by the network, but have certain preferences' as to
>> how their services need to be routed and rely fully on the network to
>> do the routing. Our clients are those that are capable and willing to
>> process the network advertisements and to control the routing
>> themselves.
>>=20
>> Cheers,
>> Igor
>>=20
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>> Of George Swallow (swallow)
>> Sent: Tuesday, September 18, 2012 9:45 AM
>> To: Gert Grammel; Julien Meuric
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Objective function draft
>>=20
>> Gert -
>>=20
>> Agreed.  I was loose in my terminology.  The Objective function is
>> information that is signaled to the routing function as a constraint.
>> There is a strong analogy and precedent for RSVP-TE/GMPLS of a loose-
>> hop in an ERO.  Another example would be Resource Affinities signaled
>> in the Session Attribute object.
>>=20
>> ...George
>>=20
>> On 9/17/12 5:22 PM, "Gert Grammel"  wrote:
>>=20
>> >Hi George,
>> >
>> >The objective function is in the end a routing information. Mixing
>> >routing and signaling in one protocol is something I don't feel
>> >comfortable with.
>> >
>> >In other words, if routing is needed between client and server, UNI is
>> >the wrong choice. ENNI should be considered instead and
>> >Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>> >
>> >
>> >Gert
>> >
>> >
>> >
>> >________________________________________
>> >From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>> >Sent: Monday, September 17, 2012 12:19:21 PM
>> >To: Julien Meuric
>> >Cc: ccamp@ietf.org
>> >Subject: Re: [CCAMP] Objective function draft
>> >
>> >Hi Julien -
>> >
>> >On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>> >
>> >>Hi George.
>> >>
>> >>Sorry for the late response. You are right: the minutes are not
>> enough
>> >>to trace the full discussion (which we also resumed right after the
>> >>meeting). Let us start by thanking Adrian (as AD? former PCE co-
>> chair?
>> >>author of... ;-) ) for bringing the PCE-associated vocabulary to a
>> >>common understanding.
>> >>
>> >>Actually my concern is sustained by 2 points:
>> >>
>> >>1- The scope of the draft is about giving control of the routing
>> >>objective function to the client node facing a transport layer. I see
>> >>already several existing solution to achieve it:
>> >>- a PCEP request from the signaling head node is an option (which is
>> >>associated to the advertisement of the supported objectives in PCEP);
>> >>- building IGP adjacencies between client and transport edge nodes
>> >>(a.k.a. "border model") is another one.
>> >>In this context, it do not think extending RSVP-TE for this kind of
>> >>application is worth the effort, since the requirement can already be
>> >>addressed.
>> >
>> >As I understand it, in the optical and OTN cases, the border model
>> >would not be popular as in many organizations this crosses political
>> >boundaries.
>> >
>> >The point of the draft is to keep the UNI implementation simple and
>> not
>> >require a PCEP on the uni-c or necessarily on the uni-n.  We will keep
>> >the format aligned so if the UNI-N needs to make a request of a PCS,
>> it
>> >can do so rather simply.
>> >>
>> >>2- There are cases when previous options are ruled out of a given
>> >>deployment. I do believe that it is not simply due to protocol
>> >>exclusion, but rather to the fact that the SP wants transport routing
>> >>decisions to remain entirely within the transport network (in order
>> to
>> >>fully leave the routing policy in the hands of people doing the layer
>> >>dimensioning). Thus, I feel this trade-off in path selection tuning
>> is
>> >>rather unlikely to happen and I fear we may be talking about RSVP-TE
>> >>over-engineering here.
>> >
>> >The idea is simply to allow the client to express its needs/wishes.
>> >The UNI-N remains in control.  By policy it can use the objective
>> >function or not.  Further if it does use the objective function and
>> >fails to find a path it can either say that there was no path or it
>> >proceed to setup what it can.
>> >
>> >>(That is also why I preferred to consider your I-Ds separately during
>> >>the CCAMP meeting.)
>> >
>> >Agreed.  I will ask for separate slots.  The discussion at the end was
>> >rather disjointed.
>> >
>> >>
>> >>However, my comments are mostly related to the client/transport
>> >>relationship. If the I-D is extended to cover more use cases with
>> >>wider scopes (Adrian has made interesting suggestions), turning the
>> >>overlay interconnection into one among a longer list, then my
>> >>conclusion may be different.
>> >
>> >I'm happy to widen the scope in this way.
>> >
>> >...George
>> >
>> >>Regards,
>> >>
>> >>Julien
>> >>
>> >>
>> >>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>> >>> Julien -
>> >>>
>> >>> Reading the CCAMP notes (which capture little of the actual
>> >>> discussion) I see that there may have been a perception in the room
>> >>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>> >>>
>> >>> This is not the case. The reason for our draft is that with the
>> UNI,
>> >>> much of the functionality that resides at the headend is moved to
>> >>> the UNI-N. So the UNI-C needs a way to express an objective
>> function
>> >>> even if there is no PCE.
>> >>>
>> >>> Operationally it seems burdensome to require a PCEP at the UNI-C
>> and
>> >>> a PCEP at the UNI-N, when all that is being done is enabling the
>> >>> UNI-N to perform what the client would do if it were connected to
>> >>> the network via a normal link.
>> >>>
>> >>> Do you still object to the draft?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> =A9George
>> >>
>> >>
>> >
>> >_______________________________________________
>> >CCAMP mailing list
>> >CCAMP@ietf.org
>> >https://www.ietf.org/mailman/listinfo/ccamp
>> >
>> >
>>=20
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp


From daniele.ceccarelli@ericsson.com  Wed Sep 19 00:12:22 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 BB07721F8629 for ; Wed, 19 Sep 2012 00:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zxgGTSTq968 for ; Wed, 19 Sep 2012 00:12:22 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9F05421F8644 for ; Wed, 19 Sep 2012 00:12:21 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-f3-505970536271
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.C9.17130.35079505; Wed, 19 Sep 2012 09:12:20 +0200 (CEST)
Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.2.59]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 19 Sep 2012 09:12:19 +0200
From: Daniele Ceccarelli 
To: Julien Meuric 
Date: Wed, 19 Sep 2012 09:12:18 +0200
Thread-Topic: [CCAMP] UNI/NNI (was: Objective function draft)
Thread-Index: Ac2Vtb248klpKt5zTqO5OibMqqLQWAAf1+ig
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  <50584DCE.5090407@orange.com>  <505898F4.3080004@orange.com>
In-Reply-To: <505898F4.3080004@orange.com>
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: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvrW5IQWSAwZLDrBZP5txgsViyaxmL xZ/Tf5ksbk9pYnRg8ZjyeyOrx5IlP5k8rjddZfdoeXaSLYAlissmJTUnsyy1SN8ugSvjxbt/ bAX9shUbdk5mbWC8Jd7FyMEhIWAisW2dVhcjJ5ApJnHh3nq2LkYuDiGBU4wSCxfOZ4dwFjBK 3Lu0mwWkgU3ASuLJIR+QBhEBHYnz78+wg9jMAjUS12edZQWxWQRUJd4194PFhQVsJBqmvmGH qLeV+LCxmQ3CNpLYtWw1C4jNKxAusa2rHWrxDiaJ5ae7mUESnAJaEk9PfmQCsRkFZCUm7F7E CLFMXOLWk/lMEFcLSCzZc54ZwhaVePn4HytEvYzEr03fWCHq9SRuTJ3CBmFrSyxb+JoZYrGg xMmZT1gmMIrNQjJ2FpKWWUhaZiFpWcDIsopRODcxMye93FwvtSgzubg4P0+vOHUTIzDGDm75 bbCDcdN9sUOM0hwsSuK8eqr7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw+vomSojM0NIx YlzmEvSgP/j++Q9CfBq/G/ukj++1zlnqdjXzgXlyCtfGDTfOqnLzHmcWbg4r/ro0/pjFm5rC BQe+m7z55CAmtWupn+gzuSD12ktHF13/nvql7Wh5vHeu38GWmXX7L6RfmZvm5ZKmUJkQcpV9 3r4vpS/fGZzcIWQbw5SVLnxLiaU4I9FQi7moOBEAucoCSX8CAAA=
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] UNI/NNI (was: Objective function draft)
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, 19 Sep 2012 07:12:22 -0000

Ciao Julien,

The key word in your reply is "tune". Ok, maybe having different protocols =
on different interface could be a too coarse distinction among interfaces, =
but at least i would expect different features for the same protocols on th=
e different interfaces. DO you agree with me?

Cheers,
Daniele

>-----Original Message-----
>From: Julien Meuric [mailto:julien.meuric@orange.com]=20
>Sent: marted=EC 18 settembre 2012 17.53
>To: Daniele Ceccarelli
>Cc: Gert Grammel; George Swallow (swallow); ccamp@ietf.org
>Subject: Re: [CCAMP] UNI/NNI (was: Objective function draft)
>
>Ciao Daniele.
>
>Your intend to propose definitions was nice. I also believe=20
>that the ITU-T has identified some particular reference points=20
>which already have a functional definition (in G.8080?).
>
>I think it is worth defining protocols that I can=20
>enable/disable/tune between my network elements.  I am not=20
>shocked if different reference points have protocols in=20
>common: I suspect this is the goal of common control...
>
>Regards,
>
>Julien
>
>
>Le 18/09/2012 14:12, Daniele Ceccarelli a =E9crit :
>> Hi Julien,
>>
>> Your argument is flawless, but if the only difference=20
>between UNI and NNI is the relationship between the two=20
>domains is it worth defining two different types of interface?
>>
>> My attempt (a bit clumpy) was to associate to each type of=20
>interface a given set of properties and functionalities. This=20
>also solves the problem of using unappropriate or not well=20
>defined language.
>> E.g.
>> - UNI: functionalies supported: A, B, C, -- Interface Properties: X,=20
>> Y, Z
>> - E-NNI: functionalities supported: A, D, E -- Interface Properties:=20
>> X, W
>>
>> So that when you say UNI you automatically indentify certain=20
>> properties and functionalities and when you say E-NNI different ones=20
>> (not necessarily fully disjoint...A and X, for example, are=20
>in common)
>>
>> Cheers,
>> Daniele
>>
>>> -----Original Message-----
>>> From: Julien Meuric [mailto:julien.meuric@orange.com]
>>>
>>> Hi Daniele.
>>>
>>> That is a good idea to bring back this issue we did not=20
>have time to=20
>>> discuss in details in Vancouver.
>>>
>>> As far as I used to understand:
>>> - UNI stands for User-to-Network, which refers to client-server=20
>>> relationship;
>>> - NNI stands for Network-to-Network, which refers to inter-domain=20
>>> relationship within a common technology.
>>>
>>> I believe the protocols we use on those interfaces is orthogonal to=20
>>> their type. E.g. one can do signaling only over an E-NNI;=20
>building an=20
>>> IGP-TE adjacency on the tributary links
>>> (UNI) of my WDM network does not transmute my UNI into an NNI.
>>> Boundaries are not defined with respect to control protocols, in=20
>>> CCAMP we put protocols between network nodes, including boundaries,=20
>>> we do not change boundary names...
>>> That is also why I prefer to use accurate phrases such as=20
>"signaling=20
>>> protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms,=20
>>> which are sometimes too loose for a protocol specification context=20
>>> like CCAMP.
>>>
>>> Cheers,
>>>
>>> Julien
>>>
>>>
>>> On 09/18/2012 09:19, Daniele Ceccarelli wrote:
>>>> Fully agree on the second part of your statement. At the
>>> time of RFC4208 the UNI allowed the exchange of signaling=20
>and routing=20
>>> messages. Now that we're defining also the E-NNI i would prefer to=20
>>> have:
>>>> - UNI: signaling only
>>>> - E-NNI: signaling AND routing (i would prefer to call it
>>> reachability
>>>> rather than routing, because it is not a topology info)
>> >
>
>
>=

From ggrammel@juniper.net  Wed Sep 19 00:17:43 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 D654E21F8616 for ; Wed, 19 Sep 2012 00:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level: 
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N39wO0LWOekC for ; Wed, 19 Sep 2012 00:17:42 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id AB77821F8611 for ; Wed, 19 Sep 2012 00:17:42 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUFlxlj66wmHP04pVj2yZqoPxeEYfWSqG@postini.com; Wed, 19 Sep 2012 00:17:42 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Sep 2012 00:15:03 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Sep 2012 00:15:02 -0700
Received: from am1outboundpool.messaging.microsoft.com (213.199.154.204) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Sep 2012 00:20:43 -0700
Received: from mail39-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 07:15:00 +0000
Received: from mail39-am1 (localhost [127.0.0.1])	by mail39-am1-R.bigfish.com (Postfix) with ESMTP id B1ED12C0280	for ; Wed, 19 Sep 2012 07:15:00 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -38
X-BigFish: PS-38(zzbb2dI98dI9371Ic89bh542Mec9Q1432Id6eah4015Id6f1izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1 (MessageSwitch) id 1348038898412276_16836; Wed, 19 Sep 2012 07:14:58 +0000 (UTC)
Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.242])	by mail39-am1.bigfish.com (Postfix) with ESMTP id 61D80E0048; Wed, 19 Sep 2012 07:14:58 +0000 (UTC)
Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 07:14:56 +0000
Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.4.151]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 07:14:49 +0000
From: Gert Grammel 
To: "JP Vasseur (jvasseur)" , Julien Meuric 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGKyfc7fsst0WOjIXQZVY+W5eQB6sAgAAAqICAAAIGwA==
Date: Wed, 19 Sep 2012 07:14:48 +0000
Message-ID: <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [193.110.54.36]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 07:17:44 -0000

Hi Julien,

Most of the discussions about UNI/ENNI are confusing. Let's start with the =
remark that UNI/ENNI are terms defined in G.709 and do not relate to layers=
. They are reference points. You can think to place them in the middle of t=
he fiber between a router and a ROADM. Since it is just fiber, it is pretty=
 clear that no layer crossing is happening there.
In IETF we have the overlay concept which also doesn't relate to layers but=
 to an administrative domain. Hence an operator can choose to place a 'GMPL=
S-UNI' where he wants.
Admittedly common wisdom places UNI as inter-layer communication and here i=
s where confusion starts. AFAIK the terms UNI-C and UNI-N as well as the no=
tion of a 'UNI-protocol' have been brought up in OIF. For whatever it is or=
 was, initial UNI was from SDH/SONET client to SDH/SONET server, hence agai=
n no layer crossing even at the protocol level.

If different layer switching is involved on both sides of an interface, the=
 best reference is RFC5212 (requirements) and RFC6001. They define a consis=
tent multi-layer switching and adaptation model.

So in order to stay inside a consistent terminology we decided to go strict=
ly with IETF terminology. That's the best we can do for now.=20

To your points:
- the routing task involves both the IGP and the signaling protocol, especi=
ally in case of loose hops or crankbacks;
--> what you mean with routing task? Is it the routing process itself or so=
mething more?

- the objective function only makes sense per LSP, which allows to consider=
 it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
--> an objective function could make sense per LSP if routing information i=
s insufficient. It starts with the assumption that a router down the road m=
ay be able to find a better path than what the ingress router does. Given t=
hat the ingress has no means to verify if the objective has been followed t=
his may turn out to become a debugging nightmare.

Gert




-----Original Message-----
From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]=20
Sent: Tuesday, September 18, 2012 2:30 PM
To: Julien Meuric
Cc: Gert Grammel; ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

I an completely sharing Julien's point of view.=20

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric"  wrot=
e:

> Hi Gert.
>=20
> As Daniele has just said, almost all the information in an inter-layer si=
gnaling can be seen as input/constraints to the routing process. The IGP-TE=
 brings some link-state information to some network nodes so as to achieve =
path computation; the result is used in the signaling protocol, on a per LS=
P basis. I would said that:
> - the routing task involves both the IGP and the signaling protocol,=20
> especially in case of loose hops or crankbacks;
> - the objective function only makes sense per LSP, which allows to consid=
er it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP)=
.
>=20
> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some g=
reat confusion in the vocabulary: it is a superset of draft-beeram-ccamp-gm=
pls-_uni_-bcp while removing the pointer to the ITU-T reference point. A po=
ssible option is just to avoid those terms and stick to protocols, namely R=
SVP-TE and IGP-TE.
>=20
> Regards,
>=20
> Julien
>=20
>=20
> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
>> Hi George,
>>=20
>> The objective function is in the end a routing information. Mixing routi=
ng and signaling in one protocol is something I don't feel comfortable with=
.
>>=20
>> In other words, if routing is needed between client and server, UNI=20
>> is the wrong choice. ENNI should be considered instead and Draft-beeram-=
ccamp-gmpls-enni would be a good starting point.
>>=20
>>=20
>> Gert
>>=20
>>=20
>>=20
>> ________________________________________
>> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>>=20
>> Hi Julien -
>>=20
>> On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>>=20
>>> Hi George.
>>>=20
>>> Sorry for the late response. You are right: the minutes are not=20
>>> enough to trace the full discussion (which we also resumed right=20
>>> after the meeting). Let us start by thanking Adrian (as AD? former PCE =
co-chair?
>>> author of... ;-) ) for bringing the PCE-associated vocabulary to a=20
>>> common understanding.
>>>=20
>>> Actually my concern is sustained by 2 points:
>>>=20
>>> 1- The scope of the draft is about giving control of the routing=20
>>> objective function to the client node facing a transport layer. I=20
>>> see already several existing solution to achieve it:
>>> - a PCEP request from the signaling head node is an option (which is=20
>>> associated to the advertisement of the supported objectives in=20
>>> PCEP);
>>> - building IGP adjacencies between client and transport edge nodes=20
>>> (a.k.a. "border model") is another one.
>>> In this context, it do not think extending RSVP-TE for this kind of=20
>>> application is worth the effort, since the requirement can already=20
>>> be addressed.
>> As I understand it, in the optical and OTN cases, the border model=20
>> would not be popular as in many organizations this crosses political=20
>> boundaries.
>>=20
>> The point of the draft is to keep the UNI implementation simple and=20
>> not require a PCEP on the uni-c or necessarily on the uni-n.  We will=20
>> keep the format aligned so if the UNI-N needs to make a request of a=20
>> PCS, it can do so rather simply.
>>> 2- There are cases when previous options are ruled out of a given=20
>>> deployment. I do believe that it is not simply due to protocol=20
>>> exclusion, but rather to the fact that the SP wants transport=20
>>> routing decisions to remain entirely within the transport network=20
>>> (in order to fully leave the routing policy in the hands of people=20
>>> doing the layer dimensioning). Thus, I feel this trade-off in path=20
>>> selection tuning is rather unlikely to happen and I fear we may be=20
>>> talking about RSVP-TE over-engineering here.
>> The idea is simply to allow the client to express its needs/wishes. =20
>> The UNI-N remains in control.  By policy it can use the objective=20
>> function or not.  Further if it does use the objective function and=20
>> fails to find a path it can either say that there was no path or it=20
>> proceed to setup what it can.
>>=20
>>> (That is also why I preferred to consider your I-Ds separately=20
>>> during the CCAMP meeting.)
>> Agreed.  I will ask for separate slots.  The discussion at the end=20
>> was rather disjointed.
>>=20
>>> However, my comments are mostly related to the client/transport=20
>>> relationship. If the I-D is extended to cover more use cases with=20
>>> wider scopes (Adrian has made interesting suggestions), turning the=20
>>> overlay interconnection into one among a longer list, then my=20
>>> conclusion may be different.
>> I'm happy to widen the scope in this way.
>>=20
>> ...George
>>=20
>>> Regards,
>>>=20
>>> Julien
>>>=20
>>>=20
>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>>> Julien -
>>>>=20
>>>> Reading the CCAMP notes (which capture little of the actual
>>>> discussion) I see that there may have been a perception in the room=20
>>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>>=20
>>>> This is not the case. The reason for our draft is that with the=20
>>>> UNI, much of the functionality that resides at the headend is moved=20
>>>> to the UNI-N. So the UNI-C needs a way to express an objective=20
>>>> function even if there is no PCE.
>>>>=20
>>>> Operationally it seems burdensome to require a PCEP at the UNI-C=20
>>>> and a PCEP at the UNI-N, when all that is being done is enabling=20
>>>> the UNI-N to perform what the client would do if it were connected=20
>>>> to the network via a normal link.
>>>>=20
>>>> Do you still object to the draft?
>>>>=20
>>>> Thanks,
>>>>=20
>>>> =A9George
>>>=20
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>=20
>>=20
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp



From jdrake@juniper.net  Wed Sep 19 01:14: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 4021621F860F for ; Wed, 19 Sep 2012 01:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.366
X-Spam-Level: 
X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8PXnx6sCEgr for ; Wed, 19 Sep 2012 01:14:54 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB121F8600 for ; Wed, 19 Sep 2012 01:14:52 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUFl++deinDWeFG4StEuLRD7+8+0pQgMf@postini.com; Wed, 19 Sep 2012 01:14:54 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 19 Sep 2012 01:13:14 -0700
From: John E Drake 
To: "George Swallow (swallow)" , Igor Bryskin , Gert Grammel , Julien Meuric 
Date: Wed, 19 Sep 2012 01:13:12 -0700
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqG4OOKfbxolEe2spFvFX1LfJeQLiYAgABZSICAAADMAIAAG88AgACutaA=
Message-ID: <5E893DB832F57341992548CDBB333163A63321B504@EMBX01-HQ.jnpr.net>
References: <5E893DB832F57341992548CDBB333163A6330D6666@EMBX01-HQ.jnpr.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 08:14:56 -0000

George,

It was simply a question for clarification.  A framework document is defini=
tely needed.

Yours irrespectively,

John


> -----Original Message-----
> From: George Swallow (swallow) [mailto:swallow@cisco.com]
> Sent: Tuesday, September 18, 2012 1:47 PM
> To: John E Drake; Igor Bryskin; Gert Grammel; Julien Meuric
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> John -
>=20
> The UNI-N can simply respond with no-route-to-destination.  Or would
> you prefer a more policy specific error.  In any case the UNI-N has
> control.
> AFAIK, that is the primary reason for a UNI in the first place!
>=20
> //George
>=20
>=20
> On 9/18/12 11:07 AM, "John E Drake"  wrote:
>=20
> >Is there a requirement that the objective function specified by the
> >user be acceptable to the network?
> >
> >Yours irrespectively,
> >
> >John
> >
> >
> >> -----Original Message-----
> >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> >> Behalf Of Igor Bryskin
> >> Sent: Tuesday, September 18, 2012 8:05 AM
> >> To: George Swallow (swallow); Gert Grammel; Julien Meuric
> >> Cc: ccamp@ietf.org
> >> Subject: Re: [CCAMP] Objective function draft
> >>
> >> I completely agree with George. Signaling the objective function is
> >> no different from signaling EROs or affinities, this is just another
> >> service specific policy, an instruction to the network as to how the
> >> service needs to be routed across the network domain. I think
> Georges
> >> documents complement our (GMPLS-ENNI) solution. We have the same
> >> objective but target different groups of clients. Specifically,
> >> George's clients are those who cannot or won't deal with the routing
> >> information leaked by the network, but have certain preferences' as
> >> to how their services need to be routed and rely fully on the
> network
> >> to do the routing. Our clients are those that are capable and
> willing
> >> to process the network advertisements and to control the routing
> >> themselves.
> >>
> >> Cheers,
> >> Igor
> >>
> >> -----Original Message-----
> >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> >> Behalf Of George Swallow (swallow)
> >> Sent: Tuesday, September 18, 2012 9:45 AM
> >> To: Gert Grammel; Julien Meuric
> >> Cc: ccamp@ietf.org
> >> Subject: Re: [CCAMP] Objective function draft
> >>
> >> Gert -
> >>
> >> Agreed.  I was loose in my terminology.  The Objective function is
> >> information that is signaled to the routing function as a
> constraint.
> >> There is a strong analogy and precedent for RSVP-TE/GMPLS of a
> loose-
> >> hop in an ERO.  Another example would be Resource Affinities
> signaled
> >> in the Session Attribute object.
> >>
> >> ...George
> >>
> >> On 9/17/12 5:22 PM, "Gert Grammel"  wrote:
> >>
> >> >Hi George,
> >> >
> >> >The objective function is in the end a routing information. Mixing
> >> >routing and signaling in one protocol is something I don't feel
> >> >comfortable with.
> >> >
> >> >In other words, if routing is needed between client and server, UNI
> >> >is the wrong choice. ENNI should be considered instead and
> >> >Draft-beeram-ccamp-gmpls-enni would be a good starting point.
> >> >
> >> >
> >> >Gert
> >> >
> >> >
> >> >
> >> >________________________________________
> >> >From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
> >> >Sent: Monday, September 17, 2012 12:19:21 PM
> >> >To: Julien Meuric
> >> >Cc: ccamp@ietf.org
> >> >Subject: Re: [CCAMP] Objective function draft
> >> >
> >> >Hi Julien -
> >> >
> >> >On 9/17/12 9:37 AM, "Julien Meuric" 
> wrote:
> >> >
> >> >>Hi George.
> >> >>
> >> >>Sorry for the late response. You are right: the minutes are not
> >> enough
> >> >>to trace the full discussion (which we also resumed right after
> the
> >> >>meeting). Let us start by thanking Adrian (as AD? former PCE co-
> >> chair?
> >> >>author of... ;-) ) for bringing the PCE-associated vocabulary to a
> >> >>common understanding.
> >> >>
> >> >>Actually my concern is sustained by 2 points:
> >> >>
> >> >>1- The scope of the draft is about giving control of the routing
> >> >>objective function to the client node facing a transport layer. I
> >> >>see already several existing solution to achieve it:
> >> >>- a PCEP request from the signaling head node is an option (which
> >> >>is associated to the advertisement of the supported objectives in
> >> >>PCEP);
> >> >>- building IGP adjacencies between client and transport edge nodes
> >> >>(a.k.a. "border model") is another one.
> >> >>In this context, it do not think extending RSVP-TE for this kind
> of
> >> >>application is worth the effort, since the requirement can already
> >> >>be addressed.
> >> >
> >> >As I understand it, in the optical and OTN cases, the border model
> >> >would not be popular as in many organizations this crosses
> political
> >> >boundaries.
> >> >
> >> >The point of the draft is to keep the UNI implementation simple and
> >> not
> >> >require a PCEP on the uni-c or necessarily on the uni-n.  We will
> >> >keep the format aligned so if the UNI-N needs to make a request of
> a
> >> >PCS,
> >> it
> >> >can do so rather simply.
> >> >>
> >> >>2- There are cases when previous options are ruled out of a given
> >> >>deployment. I do believe that it is not simply due to protocol
> >> >>exclusion, but rather to the fact that the SP wants transport
> >> >>routing decisions to remain entirely within the transport network
> >> >>(in order
> >> to
> >> >>fully leave the routing policy in the hands of people doing the
> >> >>layer dimensioning). Thus, I feel this trade-off in path selection
> >> >>tuning
> >> is
> >> >>rather unlikely to happen and I fear we may be talking about
> >> >>RSVP-TE over-engineering here.
> >> >
> >> >The idea is simply to allow the client to express its needs/wishes.
> >> >The UNI-N remains in control.  By policy it can use the objective
> >> >function or not.  Further if it does use the objective function and
> >> >fails to find a path it can either say that there was no path or it
> >> >proceed to setup what it can.
> >> >
> >> >>(That is also why I preferred to consider your I-Ds separately
> >> >>during the CCAMP meeting.)
> >> >
> >> >Agreed.  I will ask for separate slots.  The discussion at the end
> >> >was rather disjointed.
> >> >
> >> >>
> >> >>However, my comments are mostly related to the client/transport
> >> >>relationship. If the I-D is extended to cover more use cases with
> >> >>wider scopes (Adrian has made interesting suggestions), turning
> the
> >> >>overlay interconnection into one among a longer list, then my
> >> >>conclusion may be different.
> >> >
> >> >I'm happy to widen the scope in this way.
> >> >
> >> >...George
> >> >
> >> >>Regards,
> >> >>
> >> >>Julien
> >> >>
> >> >>
> >> >>Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
> >> >>> Julien -
> >> >>>
> >> >>> Reading the CCAMP notes (which capture little of the actual
> >> >>> discussion) I see that there may have been a perception in the
> >> >>> room that PCE functionality at the UNI-N was assumed (actual or
> proxy).
> >> >>>
> >> >>> This is not the case. The reason for our draft is that with the
> >> UNI,
> >> >>> much of the functionality that resides at the headend is moved
> to
> >> >>> the UNI-N. So the UNI-C needs a way to express an objective
> >> function
> >> >>> even if there is no PCE.
> >> >>>
> >> >>> Operationally it seems burdensome to require a PCEP at the UNI-C
> >> and
> >> >>> a PCEP at the UNI-N, when all that is being done is enabling the
> >> >>> UNI-N to perform what the client would do if it were connected
> to
> >> >>> the network via a normal link.
> >> >>>
> >> >>> Do you still object to the draft?
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> =A9George
> >> >>
> >> >>
> >> >
> >> >_______________________________________________
> >> >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 julien.meuric@orange.com  Wed Sep 19 02:08: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 AA05221F872D for ; Wed, 19 Sep 2012 02:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HScZ02taCMjr for ; Wed, 19 Sep 2012 02:08:57 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id CFDE321F871A for ; Wed, 19 Sep 2012 02:08:56 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C70E41074004; Wed, 19 Sep 2012 11:11:32 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id BE1B2E301B3; Wed, 19 Sep 2012 11:11:32 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 19 Sep 2012 11:08:55 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 19 Sep 2012 11:08:54 +0200
Message-ID: <50598BA6.9030002@orange.com>
Date: Wed, 19 Sep 2012 11:08:54 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Daniele Ceccarelli 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>  <50584DCE.5090407@orange.com>  <505898F4.3080004@orange.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Sep 2012 09:08:54.0844 (UTC) FILETIME=[64E85FC0:01CD9646]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] UNI/NNI
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, 19 Sep 2012 09:08:57 -0000

Hi Daniele.

The phrase "different features (for the same protocol)" covers protocol 
fields and policies, which seems reasonable. I believe we agree on that.

Julien


On 09/19/2012 09:12, Daniele Ceccarelli wrote:
> Ciao Julien,
>
> The key word in your reply is "tune". Ok, maybe having different protocols on different interface could be a too coarse distinction among interfaces, but at least i would expect different features for the same protocols on the different interfaces. DO you agree with me?
>
> Cheers,
> Daniele
>
>> -----Original Message-----
>> From: Julien Meuric [mailto:julien.meuric@orange.com]
>>
>> Ciao Daniele.
>>
>> Your intend to propose definitions was nice. I also believe
>> that the ITU-T has identified some particular reference points
>> which already have a functional definition (in G.8080?).
>>
>> I think it is worth defining protocols that I can
>> enable/disable/tune between my network elements.  I am not
>> shocked if different reference points have protocols in
>> common: I suspect this is the goal of common control...
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 18/09/2012 14:12, Daniele Ceccarelli a écrit :
>>> Hi Julien,
>>>
>>> Your argument is flawless, but if the only difference
>> between UNI and NNI is the relationship between the two
>> domains is it worth defining two different types of interface?
>>> My attempt (a bit clumpy) was to associate to each type of
>> interface a given set of properties and functionalities. This
>> also solves the problem of using unappropriate or not well
>> defined language.
>>> E.g.
>>> - UNI: functionalies supported: A, B, C, -- Interface Properties: X,
>>> Y, Z
>>> - E-NNI: functionalities supported: A, D, E -- Interface Properties:
>>> X, W
>>>
>>> So that when you say UNI you automatically indentify certain
>>> properties and functionalities and when you say E-NNI different ones
>>> (not necessarily fully disjoint...A and X, for example, are
>> in common)
>>> Cheers,
>>> Daniele
>>>
>>>> -----Original Message-----
>>>> From: Julien Meuric [mailto:julien.meuric@orange.com]
>>>>
>>>> Hi Daniele.
>>>>
>>>> That is a good idea to bring back this issue we did not
>> have time to
>>>> discuss in details in Vancouver.
>>>>
>>>> As far as I used to understand:
>>>> - UNI stands for User-to-Network, which refers to client-server
>>>> relationship;
>>>> - NNI stands for Network-to-Network, which refers to inter-domain
>>>> relationship within a common technology.
>>>>
>>>> I believe the protocols we use on those interfaces is orthogonal to
>>>> their type. E.g. one can do signaling only over an E-NNI;
>> building an
>>>> IGP-TE adjacency on the tributary links
>>>> (UNI) of my WDM network does not transmute my UNI into an NNI.
>>>> Boundaries are not defined with respect to control protocols, in
>>>> CCAMP we put protocols between network nodes, including boundaries,
>>>> we do not change boundary names...
>>>> That is also why I prefer to use accurate phrases such as
>> "signaling
>>>> protocol/RSVP-TE" and "IGP", rather than "UNI" or "NNI" acronyms,
>>>> which are sometimes too loose for a protocol specification context
>>>> like CCAMP.
>>>>
>>>> Cheers,
>>>>
>>>> Julien
>>>>
>>>>
>>>> On 09/18/2012 09:19, Daniele Ceccarelli wrote:
>>>>> Fully agree on the second part of your statement. At the
>>>> time of RFC4208 the UNI allowed the exchange of signaling
>> and routing
>>>> messages. Now that we're defining also the E-NNI i would prefer to
>>>> have:
>>>>> - UNI: signaling only
>>>>> - E-NNI: signaling AND routing (i would prefer to call it
>>>> reachability
>>>>> rather than routing, because it is not a topology info)
>>
> >


From lberger@labn.net  Wed Sep 19 04:46:42 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 163F221F864A for ; Wed, 19 Sep 2012 04:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.947
X-Spam-Level: 
X-Spam-Status: No, score=-99.947 tagged_above=-999 required=5 tests=[AWL=0.214, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbWjSWq-Jg-A for ; Wed, 19 Sep 2012 04:46:41 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id E6B7C21F860E for ; Wed, 19 Sep 2012 04:46:40 -0700 (PDT)
Received: (qmail 2617 invoked by uid 0); 19 Sep 2012 11:46:37 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 19 Sep 2012 11:46:36 -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=Pk9Y1zDxy755GCGaOLKpwPooHQmYVTQAQ9SaWIsbff4=;  b=xlKQBPV3C2Bz+TsArqR3w2q4cSXmJQxhxvhHhlGuxEv+T/w/ppBeM2MNbpTp5CFvNrm3ph9i4nou4MdY30LKm4mmEaNdg8ZG4UPtW4FIA4HkYW7cAr5BV+rgeNKTTqBe;
Received: from box313.bluehost.com ([69.89.31.113]:37352 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TEIjk-00052i-3N; Wed, 19 Sep 2012 05:46:36 -0600
Message-ID: <5059B09B.3050005@labn.net>
Date: Wed, 19 Sep 2012 07:46:35 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "JP Vasseur (jvasseur)" ,  Julien Meuric 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com>
In-Reply-To: <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-2
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] Objective function draft
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, 19 Sep 2012 11:46:42 -0000

Julien,
	Just to add to Gert's point about UNI/ENNI not being related to layers;
you can find the same terminology in the context of MPLS-TP, see RFCs
6215 and 5921.  We already have RFC4208 which provides the foundation of
a GMPLS UNI, and the related RFC5787(bis) work.

I personally see this as the foundation and context for this (and the
beeram) discussion.

Lou

On 9/19/2012 3:14 AM, Gert Grammel wrote:
> Hi Julien,
> 
> Most of the discussions about UNI/ENNI are confusing. Let's start with the remark that UNI/ENNI are terms defined in G.709 and do not relate to layers. They are reference points. You can think to place them in the middle of the fiber between a router and a ROADM. Since it is just fiber, it is pretty clear that no layer crossing is happening there.
> In IETF we have the overlay concept which also doesn't relate to layers but to an administrative domain. Hence an operator can choose to place a 'GMPLS-UNI' where he wants.
> Admittedly common wisdom places UNI as inter-layer communication and here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well as the notion of a 'UNI-protocol' have been brought up in OIF. For whatever it is or was, initial UNI was from SDH/SONET client to SDH/SONET server, hence again no layer crossing even at the protocol level.
> 
> If different layer switching is involved on both sides of an interface, the best reference is RFC5212 (requirements) and RFC6001. They define a consistent multi-layer switching and adaptation model.
> 
> So in order to stay inside a consistent terminology we decided to go strictly with IETF terminology. That's the best we can do for now. 
> 
> To your points:
> - the routing task involves both the IGP and the signaling protocol, especially in case of loose hops or crankbacks;
> --> what you mean with routing task? Is it the routing process itself or something more?
> 
> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
> --> an objective function could make sense per LSP if routing information is insufficient. It starts with the assumption that a router down the road may be able to find a better path than what the ingress router does. Given that the ingress has no means to verify if the objective has been followed this may turn out to become a debugging nightmare.
> 
> Gert
> 
> 
> 
> 
> -----Original Message-----
> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com] 
> Sent: Tuesday, September 18, 2012 2:30 PM
> To: Julien Meuric
> Cc: Gert Grammel; ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
> 
> I an completely sharing Julien's point of view. 
> 
> JP Vasseur
> Cisco Fellow
> 
> Sent from my iPhone
> 
> On 18 sept. 2012, at 05:27, "Julien Meuric"  wrote:
> 
>> Hi Gert.
>>
>> As Daniele has just said, almost all the information in an inter-layer signaling can be seen as input/constraints to the routing process. The IGP-TE brings some link-state information to some network nodes so as to achieve path computation; the result is used in the signaling protocol, on a per LSP basis. I would said that:
>> - the routing task involves both the IGP and the signaling protocol, 
>> especially in case of loose hops or crankbacks;
>> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
>>
>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some great confusion in the vocabulary: it is a superset of draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T reference point. A possible option is just to avoid those terms and stick to protocols, namely RSVP-TE and IGP-TE.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 17/09/2012 23:22, Gert Grammel a écrit :
>>> Hi George,
>>>
>>> The objective function is in the end a routing information. Mixing routing and signaling in one protocol is something I don't feel comfortable with.
>>>
>>> In other words, if routing is needed between client and server, UNI 
>>> is the wrong choice. ENNI should be considered instead and Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>>>
>>>
>>> Gert
>>>
>>>
>>>
>>> ________________________________________
>>> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>>>
>>> Hi Julien -
>>>
>>> On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>>>
>>>> Hi George.
>>>>
>>>> Sorry for the late response. You are right: the minutes are not 
>>>> enough to trace the full discussion (which we also resumed right 
>>>> after the meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to a 
>>>> common understanding.
>>>>
>>>> Actually my concern is sustained by 2 points:
>>>>
>>>> 1- The scope of the draft is about giving control of the routing 
>>>> objective function to the client node facing a transport layer. I 
>>>> see already several existing solution to achieve it:
>>>> - a PCEP request from the signaling head node is an option (which is 
>>>> associated to the advertisement of the supported objectives in 
>>>> PCEP);
>>>> - building IGP adjacencies between client and transport edge nodes 
>>>> (a.k.a. "border model") is another one.
>>>> In this context, it do not think extending RSVP-TE for this kind of 
>>>> application is worth the effort, since the requirement can already 
>>>> be addressed.
>>> As I understand it, in the optical and OTN cases, the border model 
>>> would not be popular as in many organizations this crosses political 
>>> boundaries.
>>>
>>> The point of the draft is to keep the UNI implementation simple and 
>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We will 
>>> keep the format aligned so if the UNI-N needs to make a request of a 
>>> PCS, it can do so rather simply.
>>>> 2- There are cases when previous options are ruled out of a given 
>>>> deployment. I do believe that it is not simply due to protocol 
>>>> exclusion, but rather to the fact that the SP wants transport 
>>>> routing decisions to remain entirely within the transport network 
>>>> (in order to fully leave the routing policy in the hands of people 
>>>> doing the layer dimensioning). Thus, I feel this trade-off in path 
>>>> selection tuning is rather unlikely to happen and I fear we may be 
>>>> talking about RSVP-TE over-engineering here.
>>> The idea is simply to allow the client to express its needs/wishes.  
>>> The UNI-N remains in control.  By policy it can use the objective 
>>> function or not.  Further if it does use the objective function and 
>>> fails to find a path it can either say that there was no path or it 
>>> proceed to setup what it can.
>>>
>>>> (That is also why I preferred to consider your I-Ds separately 
>>>> during the CCAMP meeting.)
>>> Agreed.  I will ask for separate slots.  The discussion at the end 
>>> was rather disjointed.
>>>
>>>> However, my comments are mostly related to the client/transport 
>>>> relationship. If the I-D is extended to cover more use cases with 
>>>> wider scopes (Adrian has made interesting suggestions), turning the 
>>>> overlay interconnection into one among a longer list, then my 
>>>> conclusion may be different.
>>> I'm happy to widen the scope in this way.
>>>
>>> ...George
>>>
>>>> Regards,
>>>>
>>>> Julien
>>>>
>>>>
>>>> Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
>>>>> Julien -
>>>>>
>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>> discussion) I see that there may have been a perception in the room 
>>>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>>>
>>>>> This is not the case. The reason for our draft is that with the 
>>>>> UNI, much of the functionality that resides at the headend is moved 
>>>>> to the UNI-N. So the UNI-C needs a way to express an objective 
>>>>> function even if there is no PCE.
>>>>>
>>>>> Operationally it seems burdensome to require a PCEP at the UNI-C 
>>>>> and a PCEP at the UNI-N, when all that is being done is enabling 
>>>>> the UNI-N to perform what the client would do if it were connected 
>>>>> to the network via a normal link.
>>>>>
>>>>> Do you still object to the draft?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> ©George
>>>>
>>> _______________________________________________
>>> 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 julien.meuric@orange.com  Wed Sep 19 06:54: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 AEF3F21F8644 for ; Wed, 19 Sep 2012 06:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh-oNRFfxGcX for ; Wed, 19 Sep 2012 06:53:59 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 518A321F861D for ; Wed, 19 Sep 2012 06:53:59 -0700 (PDT)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1CE715D8A02; Wed, 19 Sep 2012 15:53:58 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0DD5C5D89FE; Wed, 19 Sep 2012 15:53:58 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 19 Sep 2012 15:53:57 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 19 Sep 2012 15:53:57 +0200
Message-ID: <5059CE74.6030803@orange.com>
Date: Wed, 19 Sep 2012 15:53:56 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: Lou Berger 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net>
In-Reply-To: <5059B09B.3050005@labn.net>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Sep 2012 13:53:57.0317 (UTC) FILETIME=[36C6A750:01CD966E]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 13:54:00 -0000

Lou, Gert,

You are right: my previous 1st sentence was too specific, "inter-layer 
signaling" should be replaced by "client-server signaling". We agree on 
that, it was not my intention to question that part.

Regards,

Julien


Le 19/09/2012 13:46, Lou Berger a écrit :
> Julien,
> 	Just to add to Gert's point about UNI/ENNI not being related to layers;
> you can find the same terminology in the context of MPLS-TP, see RFCs
> 6215 and 5921.  We already have RFC4208 which provides the foundation of
> a GMPLS UNI, and the related RFC5787(bis) work.
>
> I personally see this as the foundation and context for this (and the
> beeram) discussion.
>
> Lou
>
> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>> Hi Julien,
>>
>> Most of the discussions about UNI/ENNI are confusing. Let's start with the remark that UNI/ENNI are terms defined in G.709 and do not relate to layers. They are reference points. You can think to place them in the middle of the fiber between a router and a ROADM. Since it is just fiber, it is pretty clear that no layer crossing is happening there.
>> In IETF we have the overlay concept which also doesn't relate to layers but to an administrative domain. Hence an operator can choose to place a 'GMPLS-UNI' where he wants.
>> Admittedly common wisdom places UNI as inter-layer communication and here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well as the notion of a 'UNI-protocol' have been brought up in OIF. For whatever it is or was, initial UNI was from SDH/SONET client to SDH/SONET server, hence again no layer crossing even at the protocol level.
>>
>> If different layer switching is involved on both sides of an interface, the best reference is RFC5212 (requirements) and RFC6001. They define a consistent multi-layer switching and adaptation model.
>>
>> So in order to stay inside a consistent terminology we decided to go strictly with IETF terminology. That's the best we can do for now.
>>
>> To your points:
>> - the routing task involves both the IGP and the signaling protocol, especially in case of loose hops or crankbacks;
>> --> what you mean with routing task? Is it the routing process itself or something more?
>>
>> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
>> --> an objective function could make sense per LSP if routing information is insufficient. It starts with the assumption that a router down the road may be able to find a better path than what the ingress router does. Given that the ingress has no means to verify if the objective has been followed this may turn out to become a debugging nightmare.
>>
>> Gert
>>
>>
>>
>>
>> -----Original Message-----
>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>
>> I an completely sharing Julien's point of view.
>>
>> JP Vasseur
>> Cisco Fellow
>>
>> Sent from my iPhone
>>
>> On 18 sept. 2012, at 05:27, "Julien Meuric"  wrote:
>>
>>> Hi Gert.
>>>
>>> As Daniele has just said, almost all the information in an inter-layer signaling can be seen as input/constraints to the routing process. The IGP-TE brings some link-state information to some network nodes so as to achieve path computation; the result is used in the signaling protocol, on a per LSP basis. I would said that:
>>> - the routing task involves both the IGP and the signaling protocol,
>>> especially in case of loose hops or crankbacks;
>>> - the objective function only makes sense per LSP, which allows to consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to IGPs or LMP).
>>>
>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing some great confusion in the vocabulary: it is a superset of draft-beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T reference point. A possible option is just to avoid those terms and stick to protocols, namely RSVP-TE and IGP-TE.
>>>
>>> Regards,
>>>
>>> Julien
>>>
>>>
>>> Le 17/09/2012 23:22, Gert Grammel a écrit :
>>>> Hi George,
>>>>
>>>> The objective function is in the end a routing information. Mixing routing and signaling in one protocol is something I don't feel comfortable with.
>>>>
>>>> In other words, if routing is needed between client and server, UNI
>>>> is the wrong choice. ENNI should be considered instead and Draft-beeram-ccamp-gmpls-enni would be a good starting point.
>>>>
>>>>
>>>> Gert
>>>>
>>>>
>>>>
>>>> ________________________________________
>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>>>>
>>>> Hi Julien -
>>>>
>>>> On 9/17/12 9:37 AM, "Julien Meuric"  wrote:
>>>>
>>>>> Hi George.
>>>>>
>>>>> Sorry for the late response. You are right: the minutes are not
>>>>> enough to trace the full discussion (which we also resumed right
>>>>> after the meeting). Let us start by thanking Adrian (as AD? former PCE co-chair?
>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to a
>>>>> common understanding.
>>>>>
>>>>> Actually my concern is sustained by 2 points:
>>>>>
>>>>> 1- The scope of the draft is about giving control of the routing
>>>>> objective function to the client node facing a transport layer. I
>>>>> see already several existing solution to achieve it:
>>>>> - a PCEP request from the signaling head node is an option (which is
>>>>> associated to the advertisement of the supported objectives in
>>>>> PCEP);
>>>>> - building IGP adjacencies between client and transport edge nodes
>>>>> (a.k.a. "border model") is another one.
>>>>> In this context, it do not think extending RSVP-TE for this kind of
>>>>> application is worth the effort, since the requirement can already
>>>>> be addressed.
>>>> As I understand it, in the optical and OTN cases, the border model
>>>> would not be popular as in many organizations this crosses political
>>>> boundaries.
>>>>
>>>> The point of the draft is to keep the UNI implementation simple and
>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We will
>>>> keep the format aligned so if the UNI-N needs to make a request of a
>>>> PCS, it can do so rather simply.
>>>>> 2- There are cases when previous options are ruled out of a given
>>>>> deployment. I do believe that it is not simply due to protocol
>>>>> exclusion, but rather to the fact that the SP wants transport
>>>>> routing decisions to remain entirely within the transport network
>>>>> (in order to fully leave the routing policy in the hands of people
>>>>> doing the layer dimensioning). Thus, I feel this trade-off in path
>>>>> selection tuning is rather unlikely to happen and I fear we may be
>>>>> talking about RSVP-TE over-engineering here.
>>>> The idea is simply to allow the client to express its needs/wishes.
>>>> The UNI-N remains in control.  By policy it can use the objective
>>>> function or not.  Further if it does use the objective function and
>>>> fails to find a path it can either say that there was no path or it
>>>> proceed to setup what it can.
>>>>
>>>>> (That is also why I preferred to consider your I-Ds separately
>>>>> during the CCAMP meeting.)
>>>> Agreed.  I will ask for separate slots.  The discussion at the end
>>>> was rather disjointed.
>>>>
>>>>> However, my comments are mostly related to the client/transport
>>>>> relationship. If the I-D is extended to cover more use cases with
>>>>> wider scopes (Adrian has made interesting suggestions), turning the
>>>>> overlay interconnection into one among a longer list, then my
>>>>> conclusion may be different.
>>>> I'm happy to widen the scope in this way.
>>>>
>>>> ...George
>>>>
>>>>> Regards,
>>>>>
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
>>>>>> Julien -
>>>>>>
>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>> discussion) I see that there may have been a perception in the room
>>>>>> that PCE functionality at the UNI-N was assumed (actual or proxy).
>>>>>>
>>>>>> This is not the case. The reason for our draft is that with the
>>>>>> UNI, much of the functionality that resides at the headend is moved
>>>>>> to the UNI-N. So the UNI-C needs a way to express an objective
>>>>>> function even if there is no PCE.
>>>>>>
>>>>>> Operationally it seems burdensome to require a PCEP at the UNI-C
>>>>>> and a PCEP at the UNI-N, when all that is being done is enabling
>>>>>> the UNI-N to perform what the client would do if it were connected
>>>>>> to the network via a normal link.
>>>>>>
>>>>>> Do you still object to the draft?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> ©George
>>>> _______________________________________________
>>>> 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 jdrake@juniper.net  Wed Sep 19 07:04: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 02A7421F872D for ; Wed, 19 Sep 2012 07:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.408
X-Spam-Level: 
X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=0.191,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUu7BDgbGEyF for ; Wed, 19 Sep 2012 07:04:11 -0700 (PDT)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91E21F8569 for ; Wed, 19 Sep 2012 07:04:11 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUFnQ11zBKGeQ62/D19GYo1fasgNzmwym@postini.com; Wed, 19 Sep 2012 07:04:11 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 19 Sep 2012 07:03:05 -0700
From: John E Drake 
To: Julien Meuric , Lou Berger 
Date: Wed, 19 Sep 2012 07:03:03 -0700
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2WbjwMfI3CVE5hQf+0m47v9f+sCwAAR2SQ
Message-ID: <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com>
In-Reply-To: <5059CE74.6030803@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 14:04:13 -0000

Julien,

This is the terminology we have been using in draft-beeram.

Yours irrespectively,

John


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Julien Meuric
> Sent: Wednesday, September 19, 2012 6:54 AM
> To: Lou Berger
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> Lou, Gert,
>=20
> You are right: my previous 1st sentence was too specific, "inter-layer
> signaling" should be replaced by "client-server signaling". We agree on
> that, it was not my intention to question that part.
>=20
> Regards,
>=20
> Julien
>=20
>=20
> Le 19/09/2012 13:46, Lou Berger a =E9crit :
> > Julien,
> > 	Just to add to Gert's point about UNI/ENNI not being related to
> > layers; you can find the same terminology in the context of MPLS-TP,
> > see RFCs
> > 6215 and 5921.  We already have RFC4208 which provides the foundation
> > of a GMPLS UNI, and the related RFC5787(bis) work.
> >
> > I personally see this as the foundation and context for this (and the
> > beeram) discussion.
> >
> > Lou
> >
> > On 9/19/2012 3:14 AM, Gert Grammel wrote:
> >> Hi Julien,
> >>
> >> Most of the discussions about UNI/ENNI are confusing. Let's start
> with the remark that UNI/ENNI are terms defined in G.709 and do not
> relate to layers. They are reference points. You can think to place
> them in the middle of the fiber between a router and a ROADM. Since it
> is just fiber, it is pretty clear that no layer crossing is happening
> there.
> >> In IETF we have the overlay concept which also doesn't relate to
> layers but to an administrative domain. Hence an operator can choose to
> place a 'GMPLS-UNI' where he wants.
> >> Admittedly common wisdom places UNI as inter-layer communication and
> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well
> as the notion of a 'UNI-protocol' have been brought up in OIF. For
> whatever it is or was, initial UNI was from SDH/SONET client to
> SDH/SONET server, hence again no layer crossing even at the protocol
> level.
> >>
> >> If different layer switching is involved on both sides of an
> interface, the best reference is RFC5212 (requirements) and RFC6001.
> They define a consistent multi-layer switching and adaptation model.
> >>
> >> So in order to stay inside a consistent terminology we decided to go
> strictly with IETF terminology. That's the best we can do for now.
> >>
> >> To your points:
> >> - the routing task involves both the IGP and the signaling protocol,
> >> especially in case of loose hops or crankbacks;
> >> --> what you mean with routing task? Is it the routing process
> itself or something more?
> >>
> >> - the objective function only makes sense per LSP, which allows to
> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
> IGPs or LMP).
> >> --> an objective function could make sense per LSP if routing
> information is insufficient. It starts with the assumption that a
> router down the road may be able to find a better path than what the
> ingress router does. Given that the ingress has no means to verify if
> the objective has been followed this may turn out to become a debugging
> nightmare.
> >>
> >> Gert
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
> >>
> >> I an completely sharing Julien's point of view.
> >>
> >> JP Vasseur
> >> Cisco Fellow
> >>
> >> Sent from my iPhone
> >>
> >> On 18 sept. 2012, at 05:27, "Julien Meuric"
>  wrote:
> >>
> >>> Hi Gert.
> >>>
> >>> As Daniele has just said, almost all the information in an inter-
> layer signaling can be seen as input/constraints to the routing
> process. The IGP-TE brings some link-state information to some network
> nodes so as to achieve path computation; the result is used in the
> signaling protocol, on a per LSP basis. I would said that:
> >>> - the routing task involves both the IGP and the signaling
> protocol,
> >>> especially in case of loose hops or crankbacks;
> >>> - the objective function only makes sense per LSP, which allows to
> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
> IGPs or LMP).
> >>>
> >>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing
> some great confusion in the vocabulary: it is a superset of draft-
> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
> reference point. A possible option is just to avoid those terms and
> stick to protocols, namely RSVP-TE and IGP-TE.
> >>>
> >>> Regards,
> >>>
> >>> Julien
> >>>
> >>>
> >>> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
> >>>> Hi George,
> >>>>
> >>>> The objective function is in the end a routing information. Mixing
> routing and signaling in one protocol is something I don't feel
> comfortable with.
> >>>>
> >>>> In other words, if routing is needed between client and server,
> UNI
> >>>> is the wrong choice. ENNI should be considered instead and Draft-
> beeram-ccamp-gmpls-enni would be a good starting point.
> >>>>
> >>>>
> >>>> Gert
> >>>>
> >>>>
> >>>>
> >>>> ________________________________________
> >>>> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
> >>>>
> >>>> Hi Julien -
> >>>>
> >>>> On 9/17/12 9:37 AM, "Julien Meuric" 
> wrote:
> >>>>
> >>>>> Hi George.
> >>>>>
> >>>>> Sorry for the late response. You are right: the minutes are not
> >>>>> enough to trace the full discussion (which we also resumed right
> >>>>> after the meeting). Let us start by thanking Adrian (as AD?
> former PCE co-chair?
> >>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to
> a
> >>>>> common understanding.
> >>>>>
> >>>>> Actually my concern is sustained by 2 points:
> >>>>>
> >>>>> 1- The scope of the draft is about giving control of the routing
> >>>>> objective function to the client node facing a transport layer. I
> >>>>> see already several existing solution to achieve it:
> >>>>> - a PCEP request from the signaling head node is an option (which
> >>>>> is associated to the advertisement of the supported objectives in
> >>>>> PCEP);
> >>>>> - building IGP adjacencies between client and transport edge
> nodes
> >>>>> (a.k.a. "border model") is another one.
> >>>>> In this context, it do not think extending RSVP-TE for this kind
> >>>>> of application is worth the effort, since the requirement can
> >>>>> already be addressed.
> >>>> As I understand it, in the optical and OTN cases, the border model
> >>>> would not be popular as in many organizations this crosses
> >>>> political boundaries.
> >>>>
> >>>> The point of the draft is to keep the UNI implementation simple
> and
> >>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We
> >>>> will keep the format aligned so if the UNI-N needs to make a
> >>>> request of a PCS, it can do so rather simply.
> >>>>> 2- There are cases when previous options are ruled out of a given
> >>>>> deployment. I do believe that it is not simply due to protocol
> >>>>> exclusion, but rather to the fact that the SP wants transport
> >>>>> routing decisions to remain entirely within the transport network
> >>>>> (in order to fully leave the routing policy in the hands of
> people
> >>>>> doing the layer dimensioning). Thus, I feel this trade-off in
> path
> >>>>> selection tuning is rather unlikely to happen and I fear we may
> be
> >>>>> talking about RSVP-TE over-engineering here.
> >>>> The idea is simply to allow the client to express its
> needs/wishes.
> >>>> The UNI-N remains in control.  By policy it can use the objective
> >>>> function or not.  Further if it does use the objective function
> and
> >>>> fails to find a path it can either say that there was no path or
> it
> >>>> proceed to setup what it can.
> >>>>
> >>>>> (That is also why I preferred to consider your I-Ds separately
> >>>>> during the CCAMP meeting.)
> >>>> Agreed.  I will ask for separate slots.  The discussion at the end
> >>>> was rather disjointed.
> >>>>
> >>>>> However, my comments are mostly related to the client/transport
> >>>>> relationship. If the I-D is extended to cover more use cases with
> >>>>> wider scopes (Adrian has made interesting suggestions), turning
> >>>>> the overlay interconnection into one among a longer list, then my
> >>>>> conclusion may be different.
> >>>> I'm happy to widen the scope in this way.
> >>>>
> >>>> ...George
> >>>>
> >>>>> Regards,
> >>>>>
> >>>>> Julien
> >>>>>
> >>>>>
> >>>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
> >>>>>> Julien -
> >>>>>>
> >>>>>> Reading the CCAMP notes (which capture little of the actual
> >>>>>> discussion) I see that there may have been a perception in the
> >>>>>> room that PCE functionality at the UNI-N was assumed (actual or
> proxy).
> >>>>>>
> >>>>>> This is not the case. The reason for our draft is that with the
> >>>>>> UNI, much of the functionality that resides at the headend is
> >>>>>> moved to the UNI-N. So the UNI-C needs a way to express an
> >>>>>> objective function even if there is no PCE.
> >>>>>>
> >>>>>> Operationally it seems burdensome to require a PCEP at the UNI-C
> >>>>>> and a PCEP at the UNI-N, when all that is being done is enabling
> >>>>>> the UNI-N to perform what the client would do if it were
> >>>>>> connected to the network via a normal link.
> >>>>>>
> >>>>>> Do you still object to the draft?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> =A9George
> >>>> _______________________________________________
> >>>> CCAMP mailing list
> >>>> CCAMP@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>
> >>>>
> >>> _______________________________________________
> >>> CCAMP mailing list
> >>> CCAMP@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/ccamp
> >>
> >> _______________________________________________
> >> CCAMP mailing list
> >> CCAMP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >>
> >>
> >>
> >>
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From julien.meuric@orange.com  Wed Sep 19 08:58: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 928EE21F86E3 for ; Wed, 19 Sep 2012 08:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjSgpynka97j for ; Wed, 19 Sep 2012 08:58:52 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 32C1821F86E1 for ; Wed, 19 Sep 2012 08:58:52 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AAEA01074002; Wed, 19 Sep 2012 18:01:28 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A276BE301B1; Wed, 19 Sep 2012 18:01:28 +0200 (CEST)
Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 19 Sep 2012 17:58:50 +0200
Received: from [10.193.71.236] ([10.193.71.236]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 19 Sep 2012 17:58:50 +0200
Message-ID: <5059EBB8.8010304@orange.com>
Date: Wed, 19 Sep 2012 17:58:48 +0200
From: Julien Meuric 
Organization: France Telecom
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: John E Drake 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Sep 2012 15:58:50.0351 (UTC) FILETIME=[A8F8E7F0:01CD967F]
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 15:58:53 -0000

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer 
network resources into a client layer network topology enhances client 
layer networking in the overlay model";
- "this document uses the term 'External Network Network Interface 
(E-NNI)' to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to 
get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to 
follow on this.)

Julien


On 09/19/2012 16:03, John E Drake wrote:
> Julien,
>
> This is the terminology we have been using in draft-beeram.
>
> Yours irrespectively,
>
> John
>
>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>> Of Julien Meuric
>>
>> Lou, Gert,
>>
>> You are right: my previous 1st sentence was too specific, "inter-layer
>> signaling" should be replaced by "client-server signaling". We agree on
>> that, it was not my intention to question that part.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 19/09/2012 13:46, Lou Berger a écrit :
>>> Julien,
>>> 	Just to add to Gert's point about UNI/ENNI not being related to
>>> layers; you can find the same terminology in the context of MPLS-TP,
>>> see RFCs
>>> 6215 and 5921.  We already have RFC4208 which provides the foundation
>>> of a GMPLS UNI, and the related RFC5787(bis) work.
>>>
>>> I personally see this as the foundation and context for this (and the
>>> beeram) discussion.
>>>
>>> Lou
>>>
>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>> Hi Julien,
>>>>
>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>> with the remark that UNI/ENNI are terms defined in G.709 and do not
>> relate to layers. They are reference points. You can think to place
>> them in the middle of the fiber between a router and a ROADM. Since it
>> is just fiber, it is pretty clear that no layer crossing is happening
>> there.
>>>> In IETF we have the overlay concept which also doesn't relate to
>> layers but to an administrative domain. Hence an operator can choose to
>> place a 'GMPLS-UNI' where he wants.
>>>> Admittedly common wisdom places UNI as inter-layer communication and
>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as well
>> as the notion of a 'UNI-protocol' have been brought up in OIF. For
>> whatever it is or was, initial UNI was from SDH/SONET client to
>> SDH/SONET server, hence again no layer crossing even at the protocol
>> level.
>>>> If different layer switching is involved on both sides of an
>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>> They define a consistent multi-layer switching and adaptation model.
>>>> So in order to stay inside a consistent terminology we decided to go
>> strictly with IETF terminology. That's the best we can do for now.
>>>> To your points:
>>>> - the routing task involves both the IGP and the signaling protocol,
>>>> especially in case of loose hops or crankbacks;
>>>> --> what you mean with routing task? Is it the routing process
>> itself or something more?
>>>> - the objective function only makes sense per LSP, which allows to
>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
>> IGPs or LMP).
>>>> --> an objective function could make sense per LSP if routing
>> information is insufficient. It starts with the assumption that a
>> router down the road may be able to find a better path than what the
>> ingress router does. Given that the ingress has no means to verify if
>> the objective has been followed this may turn out to become a debugging
>> nightmare.
>>>> Gert
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>
>>>> I an completely sharing Julien's point of view.
>>>>
>>>> JP Vasseur
>>>> Cisco Fellow
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>  wrote:
>>>>> Hi Gert.
>>>>>
>>>>> As Daniele has just said, almost all the information in an inter-
>> layer signaling can be seen as input/constraints to the routing
>> process. The IGP-TE brings some link-state information to some network
>> nodes so as to achieve path computation; the result is used in the
>> signaling protocol, on a per LSP basis. I would said that:
>>>>> - the routing task involves both the IGP and the signaling
>> protocol,
>>>>> especially in case of loose hops or crankbacks;
>>>>> - the objective function only makes sense per LSP, which allows to
>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
>> IGPs or LMP).
>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing
>> some great confusion in the vocabulary: it is a superset of draft-
>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
>> reference point. A possible option is just to avoid those terms and
>> stick to protocols, namely RSVP-TE and IGP-TE.
>>>>> Regards,
>>>>>
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 17/09/2012 23:22, Gert Grammel a écrit :
>>>>>> Hi George,
>>>>>>
>>>>>> The objective function is in the end a routing information. Mixing
>> routing and signaling in one protocol is something I don't feel
>> comfortable with.
>>>>>> In other words, if routing is needed between client and server,
>> UNI
>>>>>> is the wrong choice. ENNI should be considered instead and Draft-
>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________________
>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow (swallow)
>>>>>>
>>>>>> Hi Julien -
>>>>>>
>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>> wrote:
>>>>>>> Hi George.
>>>>>>>
>>>>>>> Sorry for the late response. You are right: the minutes are not
>>>>>>> enough to trace the full discussion (which we also resumed right
>>>>>>> after the meeting). Let us start by thanking Adrian (as AD?
>> former PCE co-chair?
>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to
>> a
>>>>>>> common understanding.
>>>>>>>
>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>
>>>>>>> 1- The scope of the draft is about giving control of the routing
>>>>>>> objective function to the client node facing a transport layer. I
>>>>>>> see already several existing solution to achieve it:
>>>>>>> - a PCEP request from the signaling head node is an option (which
>>>>>>> is associated to the advertisement of the supported objectives in
>>>>>>> PCEP);
>>>>>>> - building IGP adjacencies between client and transport edge
>> nodes
>>>>>>> (a.k.a. "border model") is another one.
>>>>>>> In this context, it do not think extending RSVP-TE for this kind
>>>>>>> of application is worth the effort, since the requirement can
>>>>>>> already be addressed.
>>>>>> As I understand it, in the optical and OTN cases, the border model
>>>>>> would not be popular as in many organizations this crosses
>>>>>> political boundaries.
>>>>>>
>>>>>> The point of the draft is to keep the UNI implementation simple
>> and
>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We
>>>>>> will keep the format aligned so if the UNI-N needs to make a
>>>>>> request of a PCS, it can do so rather simply.
>>>>>>> 2- There are cases when previous options are ruled out of a given
>>>>>>> deployment. I do believe that it is not simply due to protocol
>>>>>>> exclusion, but rather to the fact that the SP wants transport
>>>>>>> routing decisions to remain entirely within the transport network
>>>>>>> (in order to fully leave the routing policy in the hands of
>> people
>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>> path
>>>>>>> selection tuning is rather unlikely to happen and I fear we may
>> be
>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>> The idea is simply to allow the client to express its
>> needs/wishes.
>>>>>> The UNI-N remains in control.  By policy it can use the objective
>>>>>> function or not.  Further if it does use the objective function
>> and
>>>>>> fails to find a path it can either say that there was no path or
>> it
>>>>>> proceed to setup what it can.
>>>>>>
>>>>>>> (That is also why I preferred to consider your I-Ds separately
>>>>>>> during the CCAMP meeting.)
>>>>>> Agreed.  I will ask for separate slots.  The discussion at the end
>>>>>> was rather disjointed.
>>>>>>
>>>>>>> However, my comments are mostly related to the client/transport
>>>>>>> relationship. If the I-D is extended to cover more use cases with
>>>>>>> wider scopes (Adrian has made interesting suggestions), turning
>>>>>>> the overlay interconnection into one among a longer list, then my
>>>>>>> conclusion may be different.
>>>>>> I'm happy to widen the scope in this way.
>>>>>>
>>>>>> ...George
>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
>>>>>>>> Julien -
>>>>>>>>
>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>> discussion) I see that there may have been a perception in the
>>>>>>>> room that PCE functionality at the UNI-N was assumed (actual or
>> proxy).
>>>>>>>> This is not the case. The reason for our draft is that with the
>>>>>>>> UNI, much of the functionality that resides at the headend is
>>>>>>>> moved to the UNI-N. So the UNI-C needs a way to express an
>>>>>>>> objective function even if there is no PCE.
>>>>>>>>
>>>>>>>> Operationally it seems burdensome to require a PCEP at the UNI-C
>>>>>>>> and a PCEP at the UNI-N, when all that is being done is enabling
>>>>>>>> the UNI-N to perform what the client would do if it were
>>>>>>>> connected to the network via a normal link.
>>>>>>>>
>>>>>>>> Do you still object to the draft?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> ©George
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp


From IBryskin@advaoptical.com  Wed Sep 19 09:26: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 0749A21F85D5 for ; Wed, 19 Sep 2012 09:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsq9ohML8hHi for ; Wed, 19 Sep 2012 09:26:07 -0700 (PDT)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC2C21F875B for ; Wed, 19 Sep 2012 09:26:06 -0700 (PDT)
Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id q8JGQ25G017054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 18:26:02 +0200
Received: from MUC-SRV-MBX1.advaoptical.com (172.20.1.95) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.83.0; Wed, 19 Sep 2012 18:26:02 +0200
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX1.advaoptical.com (172.20.1.95) with Microsoft SMTP Server (TLS) id 15.0.508.9; Wed, 19 Sep 2012 18:26:01 +0200
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.03.0083.000; Wed, 19 Sep 2012 12:25:59 -0400
From: Igor Bryskin 
To: Julien Meuric , John E Drake 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGvMjYkYKv7UmMh7Ftclf6H5eQSrkAgAAAqICAATpfAIAAS/CAgAAjlQCAAAKMgIAAIFcA///BdEA=
Date: Wed, 19 Sep 2012 16:25:58 +0000
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>
In-Reply-To: <5059EBB8.8010304@orange.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-19_04:2012-09-19, 2012-09-19, 1970-01-01 signatures=0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 16:26:08 -0000

Hi Julien,

This should say:
- "this document uses the term 'External Network Network Interface (E-NNI)'=
 to describe this interface between a client and server network domains".

The important thing is that there is a TE domain demarcation between networ=
k and its client. The similar demarcation exists between adjacent network d=
omains in a multi-domain environment. In either case the domains are inter-=
connected via access/inter-domain links in the data plane and GMPLS-ENNI in=
 the control plane.

Hope this helps.
Igor



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J=
ulien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer net=
work resources into a client layer network topology enhances client layer n=
etworking in the overlay model";
- "this document uses the term 'External Network Network Interface (E-NNI)'=
 to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to get=
 confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to follow =
on this.)

Julien


On 09/19/2012 16:03, John E Drake wrote:
> Julien,
>
> This is the terminology we have been using in draft-beeram.
>
> Yours irrespectively,
>
> John
>
>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20
>> Behalf Of Julien Meuric
>>
>> Lou, Gert,
>>
>> You are right: my previous 1st sentence was too specific,=20
>> "inter-layer signaling" should be replaced by "client-server=20
>> signaling". We agree on that, it was not my intention to question that p=
art.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 19/09/2012 13:46, Lou Berger a =E9crit :
>>> Julien,
>>> 	Just to add to Gert's point about UNI/ENNI not being related to=20
>>> layers; you can find the same terminology in the context of MPLS-TP,=20
>>> see RFCs
>>> 6215 and 5921.  We already have RFC4208 which provides the=20
>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>
>>> I personally see this as the foundation and context for this (and=20
>>> the
>>> beeram) discussion.
>>>
>>> Lou
>>>
>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>> Hi Julien,
>>>>
>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>> with the remark that UNI/ENNI are terms defined in G.709 and do not=20
>> relate to layers. They are reference points. You can think to place=20
>> them in the middle of the fiber between a router and a ROADM. Since=20
>> it is just fiber, it is pretty clear that no layer crossing is=20
>> happening there.
>>>> In IETF we have the overlay concept which also doesn't relate to
>> layers but to an administrative domain. Hence an operator can choose=20
>> to place a 'GMPLS-UNI' where he wants.
>>>> Admittedly common wisdom places UNI as inter-layer communication=20
>>>> and
>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as=20
>> well as the notion of a 'UNI-protocol' have been brought up in OIF.=20
>> For whatever it is or was, initial UNI was from SDH/SONET client to=20
>> SDH/SONET server, hence again no layer crossing even at the protocol=20
>> level.
>>>> If different layer switching is involved on both sides of an
>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>> They define a consistent multi-layer switching and adaptation model.
>>>> So in order to stay inside a consistent terminology we decided to=20
>>>> go
>> strictly with IETF terminology. That's the best we can do for now.
>>>> To your points:
>>>> - the routing task involves both the IGP and the signaling=20
>>>> protocol, especially in case of loose hops or crankbacks;
>>>> --> what you mean with routing task? Is it the routing process
>> itself or something more?
>>>> - the objective function only makes sense per LSP, which allows to
>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to=20
>> IGPs or LMP).
>>>> --> an objective function could make sense per LSP if routing
>> information is insufficient. It starts with the assumption that a=20
>> router down the road may be able to find a better path than what the=20
>> ingress router does. Given that the ingress has no means to verify if=20
>> the objective has been followed this may turn out to become a=20
>> debugging nightmare.
>>>> Gert
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>
>>>> I an completely sharing Julien's point of view.
>>>>
>>>> JP Vasseur
>>>> Cisco Fellow
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>  wrote:
>>>>> Hi Gert.
>>>>>
>>>>> As Daniele has just said, almost all the information in an inter-
>> layer signaling can be seen as input/constraints to the routing=20
>> process. The IGP-TE brings some link-state information to some=20
>> network nodes so as to achieve path computation; the result is used=20
>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>> - the routing task involves both the IGP and the signaling
>> protocol,
>>>>> especially in case of loose hops or crankbacks;
>>>>> - the objective function only makes sense per LSP, which allows to
>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to=20
>> IGPs or LMP).
>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing
>> some great confusion in the vocabulary: it is a superset of draft-=20
>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T=20
>> reference point. A possible option is just to avoid those terms and=20
>> stick to protocols, namely RSVP-TE and IGP-TE.
>>>>> Regards,
>>>>>
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
>>>>>> Hi George,
>>>>>>
>>>>>> The objective function is in the end a routing information.=20
>>>>>> Mixing
>> routing and signaling in one protocol is something I don't feel=20
>> comfortable with.
>>>>>> In other words, if routing is needed between client and server,
>> UNI
>>>>>> is the wrong choice. ENNI should be considered instead and Draft-
>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________________
>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow=20
>>>>>> (swallow)
>>>>>>
>>>>>> Hi Julien -
>>>>>>
>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>> wrote:
>>>>>>> Hi George.
>>>>>>>
>>>>>>> Sorry for the late response. You are right: the minutes are not=20
>>>>>>> enough to trace the full discussion (which we also resumed right=20
>>>>>>> after the meeting). Let us start by thanking Adrian (as AD?
>> former PCE co-chair?
>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to
>> a
>>>>>>> common understanding.
>>>>>>>
>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>
>>>>>>> 1- The scope of the draft is about giving control of the routing=20
>>>>>>> objective function to the client node facing a transport layer.=20
>>>>>>> I see already several existing solution to achieve it:
>>>>>>> - a PCEP request from the signaling head node is an option=20
>>>>>>> (which is associated to the advertisement of the supported=20
>>>>>>> objectives in PCEP);
>>>>>>> - building IGP adjacencies between client and transport edge
>> nodes
>>>>>>> (a.k.a. "border model") is another one.
>>>>>>> In this context, it do not think extending RSVP-TE for this kind=20
>>>>>>> of application is worth the effort, since the requirement can=20
>>>>>>> already be addressed.
>>>>>> As I understand it, in the optical and OTN cases, the border=20
>>>>>> model would not be popular as in many organizations this crosses=20
>>>>>> political boundaries.
>>>>>>
>>>>>> The point of the draft is to keep the UNI implementation simple
>> and
>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We=20
>>>>>> will keep the format aligned so if the UNI-N needs to make a=20
>>>>>> request of a PCS, it can do so rather simply.
>>>>>>> 2- There are cases when previous options are ruled out of a=20
>>>>>>> given deployment. I do believe that it is not simply due to=20
>>>>>>> protocol exclusion, but rather to the fact that the SP wants=20
>>>>>>> transport routing decisions to remain entirely within the=20
>>>>>>> transport network (in order to fully leave the routing policy in=20
>>>>>>> the hands of
>> people
>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>> path
>>>>>>> selection tuning is rather unlikely to happen and I fear we may
>> be
>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>> The idea is simply to allow the client to express its
>> needs/wishes.
>>>>>> The UNI-N remains in control.  By policy it can use the objective=20
>>>>>> function or not.  Further if it does use the objective function
>> and
>>>>>> fails to find a path it can either say that there was no path or
>> it
>>>>>> proceed to setup what it can.
>>>>>>
>>>>>>> (That is also why I preferred to consider your I-Ds separately=20
>>>>>>> during the CCAMP meeting.)
>>>>>> Agreed.  I will ask for separate slots.  The discussion at the=20
>>>>>> end was rather disjointed.
>>>>>>
>>>>>>> However, my comments are mostly related to the client/transport=20
>>>>>>> relationship. If the I-D is extended to cover more use cases=20
>>>>>>> with wider scopes (Adrian has made interesting suggestions),=20
>>>>>>> turning the overlay interconnection into one among a longer=20
>>>>>>> list, then my conclusion may be different.
>>>>>> I'm happy to widen the scope in this way.
>>>>>>
>>>>>> ...George
>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>>>>>>> Julien -
>>>>>>>>
>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>> discussion) I see that there may have been a perception in the=20
>>>>>>>> room that PCE functionality at the UNI-N was assumed (actual or
>> proxy).
>>>>>>>> This is not the case. The reason for our draft is that with the=20
>>>>>>>> UNI, much of the functionality that resides at the headend is=20
>>>>>>>> moved to the UNI-N. So the UNI-C needs a way to express an=20
>>>>>>>> objective function even if there is no PCE.
>>>>>>>>
>>>>>>>> Operationally it seems burdensome to require a PCEP at the=20
>>>>>>>> UNI-C and a PCEP at the UNI-N, when all that is being done is=20
>>>>>>>> enabling the UNI-N to perform what the client would do if it=20
>>>>>>>> were connected to the network via a normal link.
>>>>>>>>
>>>>>>>> Do you still object to the draft?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> =A9George
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp

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

From ggrammel@juniper.net  Wed Sep 19 10:03: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 9265D21F861C for ; Wed, 19 Sep 2012 10:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level: 
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6415REO+9Vmh for ; Wed, 19 Sep 2012 10:03:14 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 402D721F8622 for ; Wed, 19 Sep 2012 10:03:14 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUFn60f9dLd5Y0upCBplOFy6C/NqFxG5C@postini.com; Wed, 19 Sep 2012 10:03:14 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Sep 2012 10:00:52 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Sep 2012 10:00:51 -0700
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Sep 2012 10:06:24 -0700
Received: from mail52-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 17:00:43 +0000
Received: from mail52-co1 (localhost [127.0.0.1])	by mail52-co1-R.bigfish.com (Postfix) with ESMTP id 5F0F660015F	for ; Wed, 19 Sep 2012 17:00:43 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -43
X-BigFish: PS-43(zzbb2dI98dI9371Ic89bh542Mec9Q1432Id6eah4015I328cMd6f1izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah107ah1288h12a5h12a9h12bdh1155h)
Received: from mail52-co1 (localhost.localdomain [127.0.0.1]) by mail52-co1 (MessageSwitch) id 1348074040652519_27690; Wed, 19 Sep 2012 17:00:40 +0000 (UTC)
Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.245])	by mail52-co1.bigfish.com (Postfix) with ESMTP id 90895A4004A; Wed, 19 Sep 2012 17:00:40 +0000 (UTC)
Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 17:00:14 +0000
Received: from CH1PRD0511MB431.namprd05.prod.outlook.com ([169.254.4.151]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 17:00:11 +0000
From: Gert Grammel 
To: Igor Bryskin , Julien Meuric , John E Drake 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGKyfc7fsst0WOjIXQZVY+W5eQB6sAgAAAqICAAAIGwIABhEmAgAAjlACAAAKNgIAAIFcAgAAHlwCAAAmPVQ==
Date: Wed, 19 Sep 2012 17:00:11 +0000
Message-ID: <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.159.4]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ORANGE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 17:03:15 -0000

Lets try to be more precise and write instead:

- "this document uses the term 'External Network Interface (E-NNI)' to desc=
ribe this interface between two network domains. Both domains may switch on=
 different layers and form a client/server relationship.

Although I agree with better readability of the BCP, we have to address the=
 concern of the WG and be precise. So let's try perfecting our language ...

Gert

________________________________________
From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
Sent: Wednesday, September 19, 2012 12:25:58 PM
To: Julien Meuric; John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi Julien,

This should say:
- "this document uses the term 'External Network Network Interface (E-NNI)'=
 to describe this interface between a client and server network domains".

The important thing is that there is a TE domain demarcation between networ=
k and its client. The similar demarcation exists between adjacent network d=
omains in a multi-domain environment. In either case the domains are inter-=
connected via access/inter-domain links in the data plane and GMPLS-ENNI in=
 the control plane.

Hope this helps.
Igor



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J=
ulien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer net=
work resources into a client layer network topology enhances client layer n=
etworking in the overlay model";
- "this document uses the term 'External Network Network Interface (E-NNI)'=
 to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to get=
 confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to follow =
on this.)

Julien


On 09/19/2012 16:03, John E Drake wrote:
> Julien,
>
> This is the terminology we have been using in draft-beeram.
>
> Yours irrespectively,
>
> John
>
>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>> Behalf Of Julien Meuric
>>
>> Lou, Gert,
>>
>> You are right: my previous 1st sentence was too specific,
>> "inter-layer signaling" should be replaced by "client-server
>> signaling". We agree on that, it was not my intention to question that p=
art.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le 19/09/2012 13:46, Lou Berger a =E9crit :
>>> Julien,
>>>     Just to add to Gert's point about UNI/ENNI not being related to
>>> layers; you can find the same terminology in the context of MPLS-TP,
>>> see RFCs
>>> 6215 and 5921.  We already have RFC4208 which provides the
>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>
>>> I personally see this as the foundation and context for this (and
>>> the
>>> beeram) discussion.
>>>
>>> Lou
>>>
>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>> Hi Julien,
>>>>
>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>> with the remark that UNI/ENNI are terms defined in G.709 and do not
>> relate to layers. They are reference points. You can think to place
>> them in the middle of the fiber between a router and a ROADM. Since
>> it is just fiber, it is pretty clear that no layer crossing is
>> happening there.
>>>> In IETF we have the overlay concept which also doesn't relate to
>> layers but to an administrative domain. Hence an operator can choose
>> to place a 'GMPLS-UNI' where he wants.
>>>> Admittedly common wisdom places UNI as inter-layer communication
>>>> and
>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as
>> well as the notion of a 'UNI-protocol' have been brought up in OIF.
>> For whatever it is or was, initial UNI was from SDH/SONET client to
>> SDH/SONET server, hence again no layer crossing even at the protocol
>> level.
>>>> If different layer switching is involved on both sides of an
>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>> They define a consistent multi-layer switching and adaptation model.
>>>> So in order to stay inside a consistent terminology we decided to
>>>> go
>> strictly with IETF terminology. That's the best we can do for now.
>>>> To your points:
>>>> - the routing task involves both the IGP and the signaling
>>>> protocol, especially in case of loose hops or crankbacks;
>>>> --> what you mean with routing task? Is it the routing process
>> itself or something more?
>>>> - the objective function only makes sense per LSP, which allows to
>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
>> IGPs or LMP).
>>>> --> an objective function could make sense per LSP if routing
>> information is insufficient. It starts with the assumption that a
>> router down the road may be able to find a better path than what the
>> ingress router does. Given that the ingress has no means to verify if
>> the objective has been followed this may turn out to become a
>> debugging nightmare.
>>>> Gert
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>
>>>> I an completely sharing Julien's point of view.
>>>>
>>>> JP Vasseur
>>>> Cisco Fellow
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>  wrote:
>>>>> Hi Gert.
>>>>>
>>>>> As Daniele has just said, almost all the information in an inter-
>> layer signaling can be seen as input/constraints to the routing
>> process. The IGP-TE brings some link-state information to some
>> network nodes so as to achieve path computation; the result is used
>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>> - the routing task involves both the IGP and the signaling
>> protocol,
>>>>> especially in case of loose hops or crankbacks;
>>>>> - the objective function only makes sense per LSP, which allows to
>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
>> IGPs or LMP).
>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing
>> some great confusion in the vocabulary: it is a superset of draft-
>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
>> reference point. A possible option is just to avoid those terms and
>> stick to protocols, namely RSVP-TE and IGP-TE.
>>>>> Regards,
>>>>>
>>>>> Julien
>>>>>
>>>>>
>>>>> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
>>>>>> Hi George,
>>>>>>
>>>>>> The objective function is in the end a routing information.
>>>>>> Mixing
>> routing and signaling in one protocol is something I don't feel
>> comfortable with.
>>>>>> In other words, if routing is needed between client and server,
>> UNI
>>>>>> is the wrong choice. ENNI should be considered instead and Draft-
>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________________
>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow
>>>>>> (swallow)
>>>>>>
>>>>>> Hi Julien -
>>>>>>
>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>> wrote:
>>>>>>> Hi George.
>>>>>>>
>>>>>>> Sorry for the late response. You are right: the minutes are not
>>>>>>> enough to trace the full discussion (which we also resumed right
>>>>>>> after the meeting). Let us start by thanking Adrian (as AD?
>> former PCE co-chair?
>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to
>> a
>>>>>>> common understanding.
>>>>>>>
>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>
>>>>>>> 1- The scope of the draft is about giving control of the routing
>>>>>>> objective function to the client node facing a transport layer.
>>>>>>> I see already several existing solution to achieve it:
>>>>>>> - a PCEP request from the signaling head node is an option
>>>>>>> (which is associated to the advertisement of the supported
>>>>>>> objectives in PCEP);
>>>>>>> - building IGP adjacencies between client and transport edge
>> nodes
>>>>>>> (a.k.a. "border model") is another one.
>>>>>>> In this context, it do not think extending RSVP-TE for this kind
>>>>>>> of application is worth the effort, since the requirement can
>>>>>>> already be addressed.
>>>>>> As I understand it, in the optical and OTN cases, the border
>>>>>> model would not be popular as in many organizations this crosses
>>>>>> political boundaries.
>>>>>>
>>>>>> The point of the draft is to keep the UNI implementation simple
>> and
>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We
>>>>>> will keep the format aligned so if the UNI-N needs to make a
>>>>>> request of a PCS, it can do so rather simply.
>>>>>>> 2- There are cases when previous options are ruled out of a
>>>>>>> given deployment. I do believe that it is not simply due to
>>>>>>> protocol exclusion, but rather to the fact that the SP wants
>>>>>>> transport routing decisions to remain entirely within the
>>>>>>> transport network (in order to fully leave the routing policy in
>>>>>>> the hands of
>> people
>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>> path
>>>>>>> selection tuning is rather unlikely to happen and I fear we may
>> be
>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>> The idea is simply to allow the client to express its
>> needs/wishes.
>>>>>> The UNI-N remains in control.  By policy it can use the objective
>>>>>> function or not.  Further if it does use the objective function
>> and
>>>>>> fails to find a path it can either say that there was no path or
>> it
>>>>>> proceed to setup what it can.
>>>>>>
>>>>>>> (That is also why I preferred to consider your I-Ds separately
>>>>>>> during the CCAMP meeting.)
>>>>>> Agreed.  I will ask for separate slots.  The discussion at the
>>>>>> end was rather disjointed.
>>>>>>
>>>>>>> However, my comments are mostly related to the client/transport
>>>>>>> relationship. If the I-D is extended to cover more use cases
>>>>>>> with wider scopes (Adrian has made interesting suggestions),
>>>>>>> turning the overlay interconnection into one among a longer
>>>>>>> list, then my conclusion may be different.
>>>>>> I'm happy to widen the scope in this way.
>>>>>>
>>>>>> ...George
>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>>>>>>> Julien -
>>>>>>>>
>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>> discussion) I see that there may have been a perception in the
>>>>>>>> room that PCE functionality at the UNI-N was assumed (actual or
>> proxy).
>>>>>>>> This is not the case. The reason for our draft is that with the
>>>>>>>> UNI, much of the functionality that resides at the headend is
>>>>>>>> moved to the UNI-N. So the UNI-C needs a way to express an
>>>>>>>> objective function even if there is no PCE.
>>>>>>>>
>>>>>>>> Operationally it seems burdensome to require a PCEP at the
>>>>>>>> UNI-C and a PCEP at the UNI-N, when all that is being done is
>>>>>>>> enabling the UNI-N to perform what the client would do if it
>>>>>>>> were connected to the network via a normal link.
>>>>>>>>
>>>>>>>> Do you still object to the draft?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> =A9George
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp

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



From lberger@labn.net  Wed Sep 19 11:22: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 8837021F8469 for ; Wed, 19 Sep 2012 11:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.964
X-Spam-Level: 
X-Spam-Status: No, score=-99.964 tagged_above=-999 required=5 tests=[AWL=0.197, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmz5DdQ2670A for ; Wed, 19 Sep 2012 11:22:45 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id E78C221F8468 for ; Wed, 19 Sep 2012 11:22:41 -0700 (PDT)
Received: (qmail 23899 invoked by uid 0); 19 Sep 2012 18:22:37 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 19 Sep 2012 18:22:37 -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=IE1TBn+Mv3NO/BIp+jpwc+9pOs6bNBz6aeay3o9CCPU=;  b=I6ENkmJZmzsal0HRyzT6WDGhultoy/wu5k9j14Ez+RCfQAsnyAIh2xp+PqMg8BiZDPVjIAfPz1S16eGgrzPWve+1YZLBudAtELc0hUGQ9oxuXPlT1eUMeTLjnfeM/He0;
Received: from box313.bluehost.com ([69.89.31.113]:49294 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TEOuz-00035d-Ay; Wed, 19 Sep 2012 12:22:37 -0600
Message-ID: <505A0D6C.5000402@labn.net>
Date: Wed, 19 Sep 2012 14:22:36 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Gert Grammel ,  Igor Bryskin , John E Drake 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>,  <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com>
In-Reply-To: <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-2
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] Objective function draft
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, 19 Sep 2012 18:22:49 -0000

Gert/Igor/John,
	I sympathize with Julien's comments.  It seems to me that the draft
intermingles the concepts of multi-domain (which includes UNI/ENNI) and
multi-layer (which includes, for example MPLS over optical).  While
there certainly is much commonality in mechanisms, I think the draft
could be clearer on the conceptual definitions and discussions...

Lou

On 9/19/2012 1:00 PM, Gert Grammel wrote:
> Lets try to be more precise and write instead:
> 
> - "this document uses the term 'External Network Interface (E-NNI)' to describe this interface between two network domains. Both domains may switch on different layers and form a client/server relationship.
> 
> Although I agree with better readability of the BCP, we have to address the concern of the WG and be precise. So let's try perfecting our language ...
> 
> Gert
> 
> ________________________________________
> From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
> Sent: Wednesday, September 19, 2012 12:25:58 PM
> To: Julien Meuric; John E Drake
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
> 
> Hi Julien,
> 
> This should say:
> - "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network domains".
> 
> The important thing is that there is a TE domain demarcation between network and its client. The similar demarcation exists between adjacent network domains in a multi-domain environment. In either case the domains are inter-connected via access/inter-domain links in the data plane and GMPLS-ENNI in the control plane.
> 
> Hope this helps.
> Igor
> 
> 
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Julien Meuric
> Sent: Wednesday, September 19, 2012 11:59 AM
> To: John E Drake
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
> 
> Hi John.
> 
> Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
> - "this memo describes how introducing a representation of server layer network resources into a client layer network topology enhances client layer networking in the overlay model";
> - "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network".
> 
> E-NNI for client-server (and overlay): this is exactly where I start to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to follow on this.)
> 
> Julien
> 
> 
> On 09/19/2012 16:03, John E Drake wrote:
>> Julien,
>>
>> This is the terminology we have been using in draft-beeram.
>>
>> Yours irrespectively,
>>
>> John
>>
>>
>>> -----Original Message-----
>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>> Behalf Of Julien Meuric
>>>
>>> Lou, Gert,
>>>
>>> You are right: my previous 1st sentence was too specific,
>>> "inter-layer signaling" should be replaced by "client-server
>>> signaling". We agree on that, it was not my intention to question that part.
>>>
>>> Regards,
>>>
>>> Julien
>>>
>>>
>>> Le 19/09/2012 13:46, Lou Berger a écrit :
>>>> Julien,
>>>>     Just to add to Gert's point about UNI/ENNI not being related to
>>>> layers; you can find the same terminology in the context of MPLS-TP,
>>>> see RFCs
>>>> 6215 and 5921.  We already have RFC4208 which provides the
>>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>>
>>>> I personally see this as the foundation and context for this (and
>>>> the
>>>> beeram) discussion.
>>>>
>>>> Lou
>>>>
>>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>>> Hi Julien,
>>>>>
>>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>>> with the remark that UNI/ENNI are terms defined in G.709 and do not
>>> relate to layers. They are reference points. You can think to place
>>> them in the middle of the fiber between a router and a ROADM. Since
>>> it is just fiber, it is pretty clear that no layer crossing is
>>> happening there.
>>>>> In IETF we have the overlay concept which also doesn't relate to
>>> layers but to an administrative domain. Hence an operator can choose
>>> to place a 'GMPLS-UNI' where he wants.
>>>>> Admittedly common wisdom places UNI as inter-layer communication
>>>>> and
>>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as
>>> well as the notion of a 'UNI-protocol' have been brought up in OIF.
>>> For whatever it is or was, initial UNI was from SDH/SONET client to
>>> SDH/SONET server, hence again no layer crossing even at the protocol
>>> level.
>>>>> If different layer switching is involved on both sides of an
>>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>>> They define a consistent multi-layer switching and adaptation model.
>>>>> So in order to stay inside a consistent terminology we decided to
>>>>> go
>>> strictly with IETF terminology. That's the best we can do for now.
>>>>> To your points:
>>>>> - the routing task involves both the IGP and the signaling
>>>>> protocol, especially in case of loose hops or crankbacks;
>>>>> --> what you mean with routing task? Is it the routing process
>>> itself or something more?
>>>>> - the objective function only makes sense per LSP, which allows to
>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
>>> IGPs or LMP).
>>>>> --> an objective function could make sense per LSP if routing
>>> information is insufficient. It starts with the assumption that a
>>> router down the road may be able to find a better path than what the
>>> ingress router does. Given that the ingress has no means to verify if
>>> the objective has been followed this may turn out to become a
>>> debugging nightmare.
>>>>> Gert
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>>
>>>>> I an completely sharing Julien's point of view.
>>>>>
>>>>> JP Vasseur
>>>>> Cisco Fellow
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>>  wrote:
>>>>>> Hi Gert.
>>>>>>
>>>>>> As Daniele has just said, almost all the information in an inter-
>>> layer signaling can be seen as input/constraints to the routing
>>> process. The IGP-TE brings some link-state information to some
>>> network nodes so as to achieve path computation; the result is used
>>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>>> - the routing task involves both the IGP and the signaling
>>> protocol,
>>>>>> especially in case of loose hops or crankbacks;
>>>>>> - the objective function only makes sense per LSP, which allows to
>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
>>> IGPs or LMP).
>>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing
>>> some great confusion in the vocabulary: it is a superset of draft-
>>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
>>> reference point. A possible option is just to avoid those terms and
>>> stick to protocols, namely RSVP-TE and IGP-TE.
>>>>>> Regards,
>>>>>>
>>>>>> Julien
>>>>>>
>>>>>>
>>>>>> Le 17/09/2012 23:22, Gert Grammel a écrit :
>>>>>>> Hi George,
>>>>>>>
>>>>>>> The objective function is in the end a routing information.
>>>>>>> Mixing
>>> routing and signaling in one protocol is something I don't feel
>>> comfortable with.
>>>>>>> In other words, if routing is needed between client and server,
>>> UNI
>>>>>>> is the wrong choice. ENNI should be considered instead and Draft-
>>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>>
>>>>>>> Gert
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow
>>>>>>> (swallow)
>>>>>>>
>>>>>>> Hi Julien -
>>>>>>>
>>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>>> wrote:
>>>>>>>> Hi George.
>>>>>>>>
>>>>>>>> Sorry for the late response. You are right: the minutes are not
>>>>>>>> enough to trace the full discussion (which we also resumed right
>>>>>>>> after the meeting). Let us start by thanking Adrian (as AD?
>>> former PCE co-chair?
>>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary to
>>> a
>>>>>>>> common understanding.
>>>>>>>>
>>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>>
>>>>>>>> 1- The scope of the draft is about giving control of the routing
>>>>>>>> objective function to the client node facing a transport layer.
>>>>>>>> I see already several existing solution to achieve it:
>>>>>>>> - a PCEP request from the signaling head node is an option
>>>>>>>> (which is associated to the advertisement of the supported
>>>>>>>> objectives in PCEP);
>>>>>>>> - building IGP adjacencies between client and transport edge
>>> nodes
>>>>>>>> (a.k.a. "border model") is another one.
>>>>>>>> In this context, it do not think extending RSVP-TE for this kind
>>>>>>>> of application is worth the effort, since the requirement can
>>>>>>>> already be addressed.
>>>>>>> As I understand it, in the optical and OTN cases, the border
>>>>>>> model would not be popular as in many organizations this crosses
>>>>>>> political boundaries.
>>>>>>>
>>>>>>> The point of the draft is to keep the UNI implementation simple
>>> and
>>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We
>>>>>>> will keep the format aligned so if the UNI-N needs to make a
>>>>>>> request of a PCS, it can do so rather simply.
>>>>>>>> 2- There are cases when previous options are ruled out of a
>>>>>>>> given deployment. I do believe that it is not simply due to
>>>>>>>> protocol exclusion, but rather to the fact that the SP wants
>>>>>>>> transport routing decisions to remain entirely within the
>>>>>>>> transport network (in order to fully leave the routing policy in
>>>>>>>> the hands of
>>> people
>>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>>> path
>>>>>>>> selection tuning is rather unlikely to happen and I fear we may
>>> be
>>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>>> The idea is simply to allow the client to express its
>>> needs/wishes.
>>>>>>> The UNI-N remains in control.  By policy it can use the objective
>>>>>>> function or not.  Further if it does use the objective function
>>> and
>>>>>>> fails to find a path it can either say that there was no path or
>>> it
>>>>>>> proceed to setup what it can.
>>>>>>>
>>>>>>>> (That is also why I preferred to consider your I-Ds separately
>>>>>>>> during the CCAMP meeting.)
>>>>>>> Agreed.  I will ask for separate slots.  The discussion at the
>>>>>>> end was rather disjointed.
>>>>>>>
>>>>>>>> However, my comments are mostly related to the client/transport
>>>>>>>> relationship. If the I-D is extended to cover more use cases
>>>>>>>> with wider scopes (Adrian has made interesting suggestions),
>>>>>>>> turning the overlay interconnection into one among a longer
>>>>>>>> list, then my conclusion may be different.
>>>>>>> I'm happy to widen the scope in this way.
>>>>>>>
>>>>>>> ...George
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Julien
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
>>>>>>>>> Julien -
>>>>>>>>>
>>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>>> discussion) I see that there may have been a perception in the
>>>>>>>>> room that PCE functionality at the UNI-N was assumed (actual or
>>> proxy).
>>>>>>>>> This is not the case. The reason for our draft is that with the
>>>>>>>>> UNI, much of the functionality that resides at the headend is
>>>>>>>>> moved to the UNI-N. So the UNI-C needs a way to express an
>>>>>>>>> objective function even if there is no PCE.
>>>>>>>>>
>>>>>>>>> Operationally it seems burdensome to require a PCEP at the
>>>>>>>>> UNI-C and a PCEP at the UNI-N, when all that is being done is
>>>>>>>>> enabling the UNI-N to perform what the client would do if it
>>>>>>>>> were connected to the network via a normal link.
>>>>>>>>>
>>>>>>>>> Do you still object to the draft?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> ©George
>>>>>>> _______________________________________________
>>>>>>> CCAMP mailing list
>>>>>>> CCAMP@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> _______________________________________________
> 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 IBryskin@advaoptical.com  Wed Sep 19 11:36: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 3347A21F8471 for ; Wed, 19 Sep 2012 11:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e6Tcsw9P+lw for ; Wed, 19 Sep 2012 11:36:50 -0700 (PDT)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08821F846E for ; Wed, 19 Sep 2012 11:36:50 -0700 (PDT)
Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id q8JIahoW027542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Sep 2012 20:36:43 +0200
Received: from MUC-SRV-MBX2.advaoptical.com (172.20.1.96) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.83.0; Wed, 19 Sep 2012 20:36:43 +0200
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.508.9; Wed, 19 Sep 2012 20:36:42 +0200
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.03.0083.000; Wed, 19 Sep 2012 14:36:40 -0400
From: Igor Bryskin 
To: Lou Berger , Gert Grammel , "John E Drake" 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGvMjYkYKv7UmMh7Ftclf6H5eQSrkAgAAAqICAATpfAIAAS/CAgAAjlQCAAAKMgIAAIFcA///BdECAAE+ygIAAFwcA//++zHA=
Date: Wed, 19 Sep 2012 18:36:40 +0000
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>,  <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com> <505A0D6C.5000402@labn.net>
In-Reply-To: <505A0D6C.5000402@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-19_05:2012-09-19, 2012-09-19, 1970-01-01 signatures=0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 19 Sep 2012 18:36:52 -0000

Lou,

In the context of ENNI/UNI the multi-domain aspect is important, the multi-=
layer aspect is not important at all. Although, generally speaking, network=
 and client physically exist in different layers (which by the way not alwa=
ys the case) they always peer each other in the same (client) layer, virtua=
l topology exposed to the client also belongs to the same (client) layer.

Igor

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Wednesday, September 19, 2012 2:23 PM
To: Gert Grammel; Igor Bryskin; John E Drake
Cc: Julien Meuric; ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Gert/Igor/John,
	I sympathize with Julien's comments.  It seems to me that the draft interm=
ingles the concepts of multi-domain (which includes UNI/ENNI) and multi-lay=
er (which includes, for example MPLS over optical).  While there certainly =
is much commonality in mechanisms, I think the draft could be clearer on th=
e conceptual definitions and discussions...

Lou

On 9/19/2012 1:00 PM, Gert Grammel wrote:
> Lets try to be more precise and write instead:
>=20
> - "this document uses the term 'External Network Interface (E-NNI)' to de=
scribe this interface between two network domains. Both domains may switch =
on different layers and form a client/server relationship.
>=20
> Although I agree with better readability of the BCP, we have to address t=
he concern of the WG and be precise. So let's try perfecting our language .=
..
>=20
> Gert
>=20
> ________________________________________
> From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
> Sent: Wednesday, September 19, 2012 12:25:58 PM
> To: Julien Meuric; John E Drake
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> Hi Julien,
>=20
> This should say:
> - "this document uses the term 'External Network Network Interface (E-NNI=
)' to describe this interface between a client and server network domains".
>=20
> The important thing is that there is a TE domain demarcation between netw=
ork and its client. The similar demarcation exists between adjacent network=
 domains in a multi-domain environment. In either case the domains are inte=
r-connected via access/inter-domain links in the data plane and GMPLS-ENNI =
in the control plane.
>=20
> Hope this helps.
> Igor
>=20
>=20
>=20
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=20
> Of Julien Meuric
> Sent: Wednesday, September 19, 2012 11:59 AM
> To: John E Drake
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> Hi John.
>=20
> Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
> - "this memo describes how introducing a representation of server=20
> layer network resources into a client layer network topology enhances=20
> client layer networking in the overlay model";
> - "this document uses the term 'External Network Network Interface (E-NNI=
)' to describe this interface between a client and server network".
>=20
> E-NNI for client-server (and overlay): this is exactly where I start=20
> to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier=20
> to follow on this.)
>=20
> Julien
>=20
>=20
> On 09/19/2012 16:03, John E Drake wrote:
>> Julien,
>>
>> This is the terminology we have been using in draft-beeram.
>>
>> Yours irrespectively,
>>
>> John
>>
>>
>>> -----Original Message-----
>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20
>>> Behalf Of Julien Meuric
>>>
>>> Lou, Gert,
>>>
>>> You are right: my previous 1st sentence was too specific,=20
>>> "inter-layer signaling" should be replaced by "client-server=20
>>> signaling". We agree on that, it was not my intention to question that =
part.
>>>
>>> Regards,
>>>
>>> Julien
>>>
>>>
>>> Le 19/09/2012 13:46, Lou Berger a =E9crit :
>>>> Julien,
>>>>     Just to add to Gert's point about UNI/ENNI not being related to=20
>>>> layers; you can find the same terminology in the context of=20
>>>> MPLS-TP, see RFCs
>>>> 6215 and 5921.  We already have RFC4208 which provides the=20
>>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>>
>>>> I personally see this as the foundation and context for this (and=20
>>>> the
>>>> beeram) discussion.
>>>>
>>>> Lou
>>>>
>>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>>> Hi Julien,
>>>>>
>>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>>> with the remark that UNI/ENNI are terms defined in G.709 and do not=20
>>> relate to layers. They are reference points. You can think to place=20
>>> them in the middle of the fiber between a router and a ROADM. Since=20
>>> it is just fiber, it is pretty clear that no layer crossing is=20
>>> happening there.
>>>>> In IETF we have the overlay concept which also doesn't relate to
>>> layers but to an administrative domain. Hence an operator can choose=20
>>> to place a 'GMPLS-UNI' where he wants.
>>>>> Admittedly common wisdom places UNI as inter-layer communication=20
>>>>> and
>>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as=20
>>> well as the notion of a 'UNI-protocol' have been brought up in OIF.
>>> For whatever it is or was, initial UNI was from SDH/SONET client to=20
>>> SDH/SONET server, hence again no layer crossing even at the protocol=20
>>> level.
>>>>> If different layer switching is involved on both sides of an
>>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>>> They define a consistent multi-layer switching and adaptation model.
>>>>> So in order to stay inside a consistent terminology we decided to=20
>>>>> go
>>> strictly with IETF terminology. That's the best we can do for now.
>>>>> To your points:
>>>>> - the routing task involves both the IGP and the signaling=20
>>>>> protocol, especially in case of loose hops or crankbacks;
>>>>> --> what you mean with routing task? Is it the routing process
>>> itself or something more?
>>>>> - the objective function only makes sense per LSP, which allows to
>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to=20
>>> IGPs or LMP).
>>>>> --> an objective function could make sense per LSP if routing
>>> information is insufficient. It starts with the assumption that a=20
>>> router down the road may be able to find a better path than what the=20
>>> ingress router does. Given that the ingress has no means to verify=20
>>> if the objective has been followed this may turn out to become a=20
>>> debugging nightmare.
>>>>> Gert
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>>
>>>>> I an completely sharing Julien's point of view.
>>>>>
>>>>> JP Vasseur
>>>>> Cisco Fellow
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>>  wrote:
>>>>>> Hi Gert.
>>>>>>
>>>>>> As Daniele has just said, almost all the information in an inter-
>>> layer signaling can be seen as input/constraints to the routing=20
>>> process. The IGP-TE brings some link-state information to some=20
>>> network nodes so as to achieve path computation; the result is used=20
>>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>>> - the routing task involves both the IGP and the signaling
>>> protocol,
>>>>>> especially in case of loose hops or crankbacks;
>>>>>> - the objective function only makes sense per LSP, which allows=20
>>>>>> to
>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to=20
>>> IGPs or LMP).
>>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly=20
>>>>>> introducing
>>> some great confusion in the vocabulary: it is a superset of draft-=20
>>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T=20
>>> reference point. A possible option is just to avoid those terms and=20
>>> stick to protocols, namely RSVP-TE and IGP-TE.
>>>>>> Regards,
>>>>>>
>>>>>> Julien
>>>>>>
>>>>>>
>>>>>> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
>>>>>>> Hi George,
>>>>>>>
>>>>>>> The objective function is in the end a routing information.
>>>>>>> Mixing
>>> routing and signaling in one protocol is something I don't feel=20
>>> comfortable with.
>>>>>>> In other words, if routing is needed between client and server,
>>> UNI
>>>>>>> is the wrong choice. ENNI should be considered instead and=20
>>>>>>> Draft-
>>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>>
>>>>>>> Gert
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________________
>>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow
>>>>>>> (swallow)
>>>>>>>
>>>>>>> Hi Julien -
>>>>>>>
>>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>>> wrote:
>>>>>>>> Hi George.
>>>>>>>>
>>>>>>>> Sorry for the late response. You are right: the minutes are not=20
>>>>>>>> enough to trace the full discussion (which we also resumed=20
>>>>>>>> right after the meeting). Let us start by thanking Adrian (as AD?
>>> former PCE co-chair?
>>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary=20
>>>>>>>> to
>>> a
>>>>>>>> common understanding.
>>>>>>>>
>>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>>
>>>>>>>> 1- The scope of the draft is about giving control of the=20
>>>>>>>> routing objective function to the client node facing a transport l=
ayer.
>>>>>>>> I see already several existing solution to achieve it:
>>>>>>>> - a PCEP request from the signaling head node is an option=20
>>>>>>>> (which is associated to the advertisement of the supported=20
>>>>>>>> objectives in PCEP);
>>>>>>>> - building IGP adjacencies between client and transport edge
>>> nodes
>>>>>>>> (a.k.a. "border model") is another one.
>>>>>>>> In this context, it do not think extending RSVP-TE for this=20
>>>>>>>> kind of application is worth the effort, since the requirement=20
>>>>>>>> can already be addressed.
>>>>>>> As I understand it, in the optical and OTN cases, the border=20
>>>>>>> model would not be popular as in many organizations this crosses=20
>>>>>>> political boundaries.
>>>>>>>
>>>>>>> The point of the draft is to keep the UNI implementation simple
>>> and
>>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We=20
>>>>>>> will keep the format aligned so if the UNI-N needs to make a=20
>>>>>>> request of a PCS, it can do so rather simply.
>>>>>>>> 2- There are cases when previous options are ruled out of a=20
>>>>>>>> given deployment. I do believe that it is not simply due to=20
>>>>>>>> protocol exclusion, but rather to the fact that the SP wants=20
>>>>>>>> transport routing decisions to remain entirely within the=20
>>>>>>>> transport network (in order to fully leave the routing policy=20
>>>>>>>> in the hands of
>>> people
>>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>>> path
>>>>>>>> selection tuning is rather unlikely to happen and I fear we may
>>> be
>>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>>> The idea is simply to allow the client to express its
>>> needs/wishes.
>>>>>>> The UNI-N remains in control.  By policy it can use the=20
>>>>>>> objective function or not.  Further if it does use the objective=20
>>>>>>> function
>>> and
>>>>>>> fails to find a path it can either say that there was no path or
>>> it
>>>>>>> proceed to setup what it can.
>>>>>>>
>>>>>>>> (That is also why I preferred to consider your I-Ds separately=20
>>>>>>>> during the CCAMP meeting.)
>>>>>>> Agreed.  I will ask for separate slots.  The discussion at the=20
>>>>>>> end was rather disjointed.
>>>>>>>
>>>>>>>> However, my comments are mostly related to the client/transport=20
>>>>>>>> relationship. If the I-D is extended to cover more use cases=20
>>>>>>>> with wider scopes (Adrian has made interesting suggestions),=20
>>>>>>>> turning the overlay interconnection into one among a longer=20
>>>>>>>> list, then my conclusion may be different.
>>>>>>> I'm happy to widen the scope in this way.
>>>>>>>
>>>>>>> ...George
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Julien
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>>>>>>>> Julien -
>>>>>>>>>
>>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>>> discussion) I see that there may have been a perception in the=20
>>>>>>>>> room that PCE functionality at the UNI-N was assumed (actual=20
>>>>>>>>> or
>>> proxy).
>>>>>>>>> This is not the case. The reason for our draft is that with=20
>>>>>>>>> the UNI, much of the functionality that resides at the headend=20
>>>>>>>>> is moved to the UNI-N. So the UNI-C needs a way to express an=20
>>>>>>>>> objective function even if there is no PCE.
>>>>>>>>>
>>>>>>>>> Operationally it seems burdensome to require a PCEP at the=20
>>>>>>>>> UNI-C and a PCEP at the UNI-N, when all that is being done is=20
>>>>>>>>> enabling the UNI-N to perform what the client would do if it=20
>>>>>>>>> were connected to the network via a normal link.
>>>>>>>>>
>>>>>>>>> Do you still object to the draft?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> =A9George
>>>>>>> _______________________________________________
>>>>>>> CCAMP mailing list
>>>>>>> CCAMP@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>> _______________________________________________
>>>>> CCAMP mailing list
>>>>> CCAMP@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>=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
>=20
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>=20
>=20
>=20
>=20

From lberger@labn.net  Wed Sep 19 12:27:38 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 5C1F921E8064 for ; Wed, 19 Sep 2012 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.972
X-Spam-Level: 
X-Spam-Status: No, score=-99.972 tagged_above=-999 required=5 tests=[AWL=0.189, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3SgyPvvKChE for ; Wed, 19 Sep 2012 12:27:37 -0700 (PDT)
Received: from oproxy11-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 325EA21E805F for ; Wed, 19 Sep 2012 12:27:37 -0700 (PDT)
Received: (qmail 24546 invoked by uid 0); 19 Sep 2012 19:27:33 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy11.bluehost.com with SMTP; 19 Sep 2012 19:27:33 -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=sY9ELg94a9o4Im3e8H1w4GaLaaAOjjGibiw9C6lZqws=;  b=EpdpRUhg75xBOeMQffr6SDLcOHv1zUFIqpSAINAjnirqls/nEyCyQDHIHYGKAe6d9b3HITtAlcDFcmYxCA/jBpGALHd8D74wu3nk/PV/Qz9zf5yJ2o0Ij/3nC8CFypgK;
Received: from box313.bluehost.com ([69.89.31.113]:57299 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TEPvp-0003sa-7U; Wed, 19 Sep 2012 13:27:33 -0600
Message-ID: <505A1CA2.2050406@labn.net>
Date: Wed, 19 Sep 2012 15:27:30 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Igor Bryskin 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>,  <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com> <505A0D6C.5000402@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-2
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] Objective function draft
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, 19 Sep 2012 19:27:38 -0000

Igor,
	I completely agree, but don't see this clearly articulated in the
current draft.

Lou

On 9/19/2012 2:36 PM, Igor Bryskin wrote:
> Lou,
> 
> In the context of ENNI/UNI the multi-domain aspect is important, the
> multi-layer aspect is not important at all. Although, generally
> speaking, network and client physically exist in different layers
> (which by the way not always the case) they always peer each other in
> the same (client) layer, virtual topology exposed to the client also
> belongs to the same (client) layer.
> 
> Igor
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Wednesday, September 19, 2012 2:23 PM
> To: Gert Grammel; Igor Bryskin; John E Drake
> Cc: Julien Meuric; ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
> 
> Gert/Igor/John,
> 	I sympathize with Julien's comments.  It seems to me that the draft intermingles the concepts of multi-domain (which includes UNI/ENNI) and multi-layer (which includes, for example MPLS over optical).  While there certainly is much commonality in mechanisms, I think the draft could be clearer on the conceptual definitions and discussions...
> 
> Lou
> 
> On 9/19/2012 1:00 PM, Gert Grammel wrote:
>> Lets try to be more precise and write instead:
>>
>> - "this document uses the term 'External Network Interface (E-NNI)' to describe this interface between two network domains. Both domains may switch on different layers and form a client/server relationship.
>>
>> Although I agree with better readability of the BCP, we have to address the concern of the WG and be precise. So let's try perfecting our language ...
>>
>> Gert
>>
>> ________________________________________
>> From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
>> Sent: Wednesday, September 19, 2012 12:25:58 PM
>> To: Julien Meuric; John E Drake
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Objective function draft
>>
>> Hi Julien,
>>
>> This should say:
>> - "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network domains".
>>
>> The important thing is that there is a TE domain demarcation between network and its client. The similar demarcation exists between adjacent network domains in a multi-domain environment. In either case the domains are inter-connected via access/inter-domain links in the data plane and GMPLS-ENNI in the control plane.
>>
>> Hope this helps.
>> Igor
>>
>>
>>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 
>> Of Julien Meuric
>> Sent: Wednesday, September 19, 2012 11:59 AM
>> To: John E Drake
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Objective function draft
>>
>> Hi John.
>>
>> Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
>> - "this memo describes how introducing a representation of server 
>> layer network resources into a client layer network topology enhances 
>> client layer networking in the overlay model";
>> - "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network".
>>
>> E-NNI for client-server (and overlay): this is exactly where I start 
>> to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier 
>> to follow on this.)
>>
>> Julien
>>
>>
>> On 09/19/2012 16:03, John E Drake wrote:
>>> Julien,
>>>
>>> This is the terminology we have been using in draft-beeram.
>>>
>>> Yours irrespectively,
>>>
>>> John
>>>
>>>
>>>> -----Original Message-----
>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
>>>> Behalf Of Julien Meuric
>>>>
>>>> Lou, Gert,
>>>>
>>>> You are right: my previous 1st sentence was too specific, 
>>>> "inter-layer signaling" should be replaced by "client-server 
>>>> signaling". We agree on that, it was not my intention to question that part.
>>>>
>>>> Regards,
>>>>
>>>> Julien
>>>>
>>>>
>>>> Le 19/09/2012 13:46, Lou Berger a écrit :
>>>>> Julien,
>>>>>     Just to add to Gert's point about UNI/ENNI not being related to 
>>>>> layers; you can find the same terminology in the context of 
>>>>> MPLS-TP, see RFCs
>>>>> 6215 and 5921.  We already have RFC4208 which provides the 
>>>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>>>
>>>>> I personally see this as the foundation and context for this (and 
>>>>> the
>>>>> beeram) discussion.
>>>>>
>>>>> Lou
>>>>>
>>>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>>>> Hi Julien,
>>>>>>
>>>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>>>> with the remark that UNI/ENNI are terms defined in G.709 and do not 
>>>> relate to layers. They are reference points. You can think to place 
>>>> them in the middle of the fiber between a router and a ROADM. Since 
>>>> it is just fiber, it is pretty clear that no layer crossing is 
>>>> happening there.
>>>>>> In IETF we have the overlay concept which also doesn't relate to
>>>> layers but to an administrative domain. Hence an operator can choose 
>>>> to place a 'GMPLS-UNI' where he wants.
>>>>>> Admittedly common wisdom places UNI as inter-layer communication 
>>>>>> and
>>>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as 
>>>> well as the notion of a 'UNI-protocol' have been brought up in OIF.
>>>> For whatever it is or was, initial UNI was from SDH/SONET client to 
>>>> SDH/SONET server, hence again no layer crossing even at the protocol 
>>>> level.
>>>>>> If different layer switching is involved on both sides of an
>>>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>>>> They define a consistent multi-layer switching and adaptation model.
>>>>>> So in order to stay inside a consistent terminology we decided to 
>>>>>> go
>>>> strictly with IETF terminology. That's the best we can do for now.
>>>>>> To your points:
>>>>>> - the routing task involves both the IGP and the signaling 
>>>>>> protocol, especially in case of loose hops or crankbacks;
>>>>>> --> what you mean with routing task? Is it the routing process
>>>> itself or something more?
>>>>>> - the objective function only makes sense per LSP, which allows to
>>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to 
>>>> IGPs or LMP).
>>>>>> --> an objective function could make sense per LSP if routing
>>>> information is insufficient. It starts with the assumption that a 
>>>> router down the road may be able to find a better path than what the 
>>>> ingress router does. Given that the ingress has no means to verify 
>>>> if the objective has been followed this may turn out to become a 
>>>> debugging nightmare.
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>>>
>>>>>> I an completely sharing Julien's point of view.
>>>>>>
>>>>>> JP Vasseur
>>>>>> Cisco Fellow
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>>>  wrote:
>>>>>>> Hi Gert.
>>>>>>>
>>>>>>> As Daniele has just said, almost all the information in an inter-
>>>> layer signaling can be seen as input/constraints to the routing 
>>>> process. The IGP-TE brings some link-state information to some 
>>>> network nodes so as to achieve path computation; the result is used 
>>>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>>>> - the routing task involves both the IGP and the signaling
>>>> protocol,
>>>>>>> especially in case of loose hops or crankbacks;
>>>>>>> - the objective function only makes sense per LSP, which allows 
>>>>>>> to
>>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to 
>>>> IGPs or LMP).
>>>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly 
>>>>>>> introducing
>>>> some great confusion in the vocabulary: it is a superset of draft- 
>>>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T 
>>>> reference point. A possible option is just to avoid those terms and 
>>>> stick to protocols, namely RSVP-TE and IGP-TE.
>>>>>>> Regards,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le 17/09/2012 23:22, Gert Grammel a écrit :
>>>>>>>> Hi George,
>>>>>>>>
>>>>>>>> The objective function is in the end a routing information.
>>>>>>>> Mixing
>>>> routing and signaling in one protocol is something I don't feel 
>>>> comfortable with.
>>>>>>>> In other words, if routing is needed between client and server,
>>>> UNI
>>>>>>>> is the wrong choice. ENNI should be considered instead and 
>>>>>>>> Draft-
>>>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>>>
>>>>>>>> Gert
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________________
>>>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow
>>>>>>>> (swallow)
>>>>>>>>
>>>>>>>> Hi Julien -
>>>>>>>>
>>>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>>>> wrote:
>>>>>>>>> Hi George.
>>>>>>>>>
>>>>>>>>> Sorry for the late response. You are right: the minutes are not 
>>>>>>>>> enough to trace the full discussion (which we also resumed 
>>>>>>>>> right after the meeting). Let us start by thanking Adrian (as AD?
>>>> former PCE co-chair?
>>>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary 
>>>>>>>>> to
>>>> a
>>>>>>>>> common understanding.
>>>>>>>>>
>>>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>>>
>>>>>>>>> 1- The scope of the draft is about giving control of the 
>>>>>>>>> routing objective function to the client node facing a transport layer.
>>>>>>>>> I see already several existing solution to achieve it:
>>>>>>>>> - a PCEP request from the signaling head node is an option 
>>>>>>>>> (which is associated to the advertisement of the supported 
>>>>>>>>> objectives in PCEP);
>>>>>>>>> - building IGP adjacencies between client and transport edge
>>>> nodes
>>>>>>>>> (a.k.a. "border model") is another one.
>>>>>>>>> In this context, it do not think extending RSVP-TE for this 
>>>>>>>>> kind of application is worth the effort, since the requirement 
>>>>>>>>> can already be addressed.
>>>>>>>> As I understand it, in the optical and OTN cases, the border 
>>>>>>>> model would not be popular as in many organizations this crosses 
>>>>>>>> political boundaries.
>>>>>>>>
>>>>>>>> The point of the draft is to keep the UNI implementation simple
>>>> and
>>>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n.  We 
>>>>>>>> will keep the format aligned so if the UNI-N needs to make a 
>>>>>>>> request of a PCS, it can do so rather simply.
>>>>>>>>> 2- There are cases when previous options are ruled out of a 
>>>>>>>>> given deployment. I do believe that it is not simply due to 
>>>>>>>>> protocol exclusion, but rather to the fact that the SP wants 
>>>>>>>>> transport routing decisions to remain entirely within the 
>>>>>>>>> transport network (in order to fully leave the routing policy 
>>>>>>>>> in the hands of
>>>> people
>>>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>>>> path
>>>>>>>>> selection tuning is rather unlikely to happen and I fear we may
>>>> be
>>>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>>>> The idea is simply to allow the client to express its
>>>> needs/wishes.
>>>>>>>> The UNI-N remains in control.  By policy it can use the 
>>>>>>>> objective function or not.  Further if it does use the objective 
>>>>>>>> function
>>>> and
>>>>>>>> fails to find a path it can either say that there was no path or
>>>> it
>>>>>>>> proceed to setup what it can.
>>>>>>>>
>>>>>>>>> (That is also why I preferred to consider your I-Ds separately 
>>>>>>>>> during the CCAMP meeting.)
>>>>>>>> Agreed.  I will ask for separate slots.  The discussion at the 
>>>>>>>> end was rather disjointed.
>>>>>>>>
>>>>>>>>> However, my comments are mostly related to the client/transport 
>>>>>>>>> relationship. If the I-D is extended to cover more use cases 
>>>>>>>>> with wider scopes (Adrian has made interesting suggestions), 
>>>>>>>>> turning the overlay interconnection into one among a longer 
>>>>>>>>> list, then my conclusion may be different.
>>>>>>>> I'm happy to widen the scope in this way.
>>>>>>>>
>>>>>>>> ...George
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Julien
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a écrit :
>>>>>>>>>> Julien -
>>>>>>>>>>
>>>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>>>> discussion) I see that there may have been a perception in the 
>>>>>>>>>> room that PCE functionality at the UNI-N was assumed (actual 
>>>>>>>>>> or
>>>> proxy).
>>>>>>>>>> This is not the case. The reason for our draft is that with 
>>>>>>>>>> the UNI, much of the functionality that resides at the headend 
>>>>>>>>>> is moved to the UNI-N. So the UNI-C needs a way to express an 
>>>>>>>>>> objective function even if there is no PCE.
>>>>>>>>>>
>>>>>>>>>> Operationally it seems burdensome to require a PCEP at the 
>>>>>>>>>> UNI-C and a PCEP at the UNI-N, when all that is being done is 
>>>>>>>>>> enabling the UNI-N to perform what the client would do if it 
>>>>>>>>>> were connected to the network via a normal link.
>>>>>>>>>>
>>>>>>>>>> Do you still object to the draft?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> ©George
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> CCAMP@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> CCAMP mailing list
>>>>>>> CCAMP@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>> _______________________________________________
>> 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 dieter.beller@alcatel-lucent.com  Wed Sep 19 17:18: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 B956E21F84F5 for ; Wed, 19 Sep 2012 17:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.491
X-Spam-Level: 
X-Spam-Status: No, score=-8.491 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdznrctWlTkS for ; Wed, 19 Sep 2012 17:18:31 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id C783221F84F2 for ; Wed, 19 Sep 2012 17:18:30 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8K0IRsC020887 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Sep 2012 02:18:28 +0200
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 20 Sep 2012 02:18:27 +0200
Received: from [135.244.3.68] (135.5.27.16) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Sep 2012 20:18:24 -0400
Message-ID: <505A60CC.2080806@alcatel-lucent.com>
Date: Thu, 20 Sep 2012 02:18:20 +0200
From: Dieter Beller 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Lou Berger , Gert Grammel , Igor Bryskin , John E Drake , "ccamp@ietf.org" 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>,  <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com> <505A0D6C.5000402@labn.net>
In-Reply-To: <505A0D6C.5000402@labn.net>
Content-Type: multipart/related; boundary="------------030204010503080200050109"
X-Originating-IP: [135.5.27.16]
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: Re: [CCAMP] Objective function draft
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, 20 Sep 2012 00:18:32 -0000

--------------030204010503080200050109
Content-Type: text/html; charset="ISO-8859-2"
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi all,

    

    the terms UNI and E-NNI are defining reference points or boundaries
    if you will between

    a user (device) and a network (device) and between network domains,
    respectively

    (see RFC4208 or ITU-T G.8080). These reference points are located on
    data plane links

    between two network devices. Hence, the information that is
    exchanged across these

    reference points, ie.e, the infomation on either end of the link is
    exactly the same, which

    means that no network layer is crossed at these reference points!
    Therefore, these

    reference points are associated with a horizontal interface between
    the devices (same

    network layer).

    

    Now, orthogonal to that, we have layer transitions in the date plane
    if we are in a multi-layer

    environment which means that a client signal is encapsulated into a
    server layer signal and

    then carried transparently across the server layer network.

    This is a data plane client/server relationship and we better talk
    about data plane layer

    transitions and do not link these vertical inter-layer relationships
    to the terms UNI or E-NNI

    because they have a different meaning as described above. If we are
    sloppy regarding

    terminology we may end up creating a lot of confusion.

    

    I am in agreement with those who have posted similar messages.

    

    

    Thanks,

    Dieter

    

    
On 19.09.2012 20:22, Lou Berger wrote:

    

    

      
Gert/Igor/John,
        I sympathize with Julien's comments.  It seems to me that the draft
intermingles the concepts of multi-domain (which includes UNI/ENNI) and
multi-layer (which includes, for example MPLS over optical).  While
there certainly is much commonality in mechanisms, I think the draft
could be clearer on the conceptual definitions and discussions...

Lou

On 9/19/2012 1:00 PM, Gert Grammel wrote:


      

        
Lets try to be more precise and write instead:

- "this document uses the term 'External Network Interface (E-NNI)' to describe this interface between two network domains. Both domains may switch on different layers and form a client/server relationship.

Although I agree with better readability of the BCP, we have to address the concern of the WG and be precise. So let's try perfecting our language ...

Gert

________________________________________
From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
Sent: Wednesday, September 19, 2012 12:25:58 PM
To: Julien Meuric; John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi Julien,

This should say:
- "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network domains".

The important thing is that there is a TE domain demarcation between network and its client. The similar demarcation exists between adjacent network domains in a multi-domain environment. In either case the domains are inter-connected via access/inter-domain links in the data plane and GMPLS-ENNI in the control plane.

Hope this helps.
Igor



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Julien Meuric
Sent: Wednesday, September 19, 2012 11:59 AM
To: John E Drake
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi John.

Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
- "this memo describes how introducing a representation of server layer network resources into a client layer network topology enhances client layer networking in the overlay model";
- "this document uses the term 'External Network Network Interface (E-NNI)' to describe this interface between a client and server network".

E-NNI for client-server (and overlay): this is exactly where I start to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to follow on this.)

Julien


On 09/19/2012 16:03, John E Drake wrote:


        

          
Julien,

This is the terminology we have been using in draft-beeram.

Yours irrespectively,

John




          

            
-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
Behalf Of Julien Meuric

Lou, Gert,

You are right: my previous 1st sentence was too specific,
"inter-layer signaling" should be replaced by "client-server
signaling". We agree on that, it was not my intention to question that part.

Regards,

Julien


Le 19/09/2012 13:46, Lou Berger a écrit :


            

              
Julien,
    Just to add to Gert's point about UNI/ENNI not being related to
layers; you can find the same terminology in the context of MPLS-TP,
see RFCs
6215 and 5921.  We already have RFC4208 which provides the
foundation of a GMPLS UNI, and the related RFC5787(bis) work.

I personally see this as the foundation and context for this (and
the
beeram) discussion.

Lou

On 9/19/2012 3:14 AM, Gert Grammel wrote:


              

                
Hi Julien,

Most of the discussions about UNI/ENNI are confusing. Let's start


              

            

            
with the remark that UNI/ENNI are terms defined in G.709 and do not
relate to layers. They are reference points. You can think to place
them in the middle of the fiber between a router and a ROADM. Since
it is just fiber, it is pretty clear that no layer crossing is
happening there.


            

              

                
In IETF we have the overlay concept which also doesn't relate to


              

            

            
layers but to an administrative domain. Hence an operator can choose
to place a 'GMPLS-UNI' where he wants.


            

              

                
Admittedly common wisdom places UNI as inter-layer communication
and


              

            

            
here is where confusion starts. AFAIK the terms UNI-C and UNI-N as
well as the notion of a 'UNI-protocol' have been brought up in OIF.
For whatever it is or was, initial UNI was from SDH/SONET client to
SDH/SONET server, hence again no layer crossing even at the protocol
level.


            

              

                
If different layer switching is involved on both sides of an


              

            

            
interface, the best reference is RFC5212 (requirements) and RFC6001.
They define a consistent multi-layer switching and adaptation model.


            

              

                
So in order to stay inside a consistent terminology we decided to
go


              

            

            
strictly with IETF terminology. That's the best we can do for now.


            

              

                
To your points:
- the routing task involves both the IGP and the signaling
protocol, especially in case of loose hops or crankbacks;
--> what you mean with routing task? Is it the routing process


              

            

            
itself or something more?


            

              

                
- the objective function only makes sense per LSP, which allows to


              

            

            
consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
IGPs or LMP).


            

              

                
--> an objective function could make sense per LSP if routing


              

            

            
information is insufficient. It starts with the assumption that a
router down the road may be able to find a better path than what the
ingress router does. Given that the ingress has no means to verify if
the objective has been followed this may turn out to become a
debugging nightmare.


            

              

                
Gert




-----Original Message-----
From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]

I an completely sharing Julien's point of view.

JP Vasseur
Cisco Fellow

Sent from my iPhone

On 18 sept. 2012, at 05:27, "Julien Meuric"


              

            

            
<julien.meuric@orange.com> wrote:


            

              

                

                  
Hi Gert.

As Daniele has just said, almost all the information in an inter-


                

              

            

            
layer signaling can be seen as input/constraints to the routing
process. The IGP-TE brings some link-state information to some
network nodes so as to achieve path computation; the result is used
in the signaling protocol, on a per LSP basis. I would said that:


            

              

                

                  
- the routing task involves both the IGP and the signaling


                

              

            

            
protocol,


            

              

                

                  
especially in case of loose hops or crankbacks;
- the objective function only makes sense per LSP, which allows to


                

              

            

            
consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to
IGPs or LMP).


            

              

                

                  
I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing


                

              

            

            
some great confusion in the vocabulary: it is a superset of draft-
beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
reference point. A possible option is just to avoid those terms and
stick to protocols, namely RSVP-TE and IGP-TE.


            

              

                

                  
Regards,

Julien


Le 17/09/2012 23:22, Gert Grammel a écrit :


                  

                    
Hi George,

The objective function is in the end a routing information.
Mixing


                  

                

              

            

            
routing and signaling in one protocol is something I don't feel
comfortable with.


            

              

                

                  

                    
In other words, if routing is needed between client and server,


                  

                

              

            

            
UNI


            

              

                

                  

                    
is the wrong choice. ENNI should be considered instead and Draft-


                  

                

              

            

            
beeram-ccamp-gmpls-enni would be a good starting point.


            

              

                

                  

                    
Gert



________________________________________
From: ccamp-bounces@ietf.org on behalf of George Swallow
(swallow)

Hi Julien -

On 9/17/12 9:37 AM, "Julien Meuric" <julien.meuric@orange.com>


                  

                

              

            

            
wrote:


            

              

                

                  

                    

                      
Hi George.

Sorry for the late response. You are right: the minutes are not
enough to trace the full discussion (which we also resumed right
after the meeting). Let us start by thanking Adrian (as AD?


                    

                  

                

              

            

            
former PCE co-chair?


            

              

                

                  

                    

                      
author of... ;-) ) for bringing the PCE-associated vocabulary to


                    

                  

                

              

            

            
a


            

              

                

                  

                    

                      
common understanding.

Actually my concern is sustained by 2 points:

1- The scope of the draft is about giving control of the routing
objective function to the client node facing a transport layer.
I see already several existing solution to achieve it:
- a PCEP request from the signaling head node is an option
(which is associated to the advertisement of the supported
objectives in PCEP);
- building IGP adjacencies between client and transport edge


                    

                  

                

              

            

            
nodes


            

              

                

                  

                    

                      
(a.k.a. "border model") is another one.
In this context, it do not think extending RSVP-TE for this kind
of application is worth the effort, since the requirement can
already be addressed.


                    

                    
As I understand it, in the optical and OTN cases, the border
model would not be popular as in many organizations this crosses
political boundaries.

The point of the draft is to keep the UNI implementation simple


                  

                

              

            

            
and


            

              

                

                  

                    
not require a PCEP on the uni-c or necessarily on the uni-n.  We
will keep the format aligned so if the UNI-N needs to make a
request of a PCS, it can do so rather simply.


                    

                      
2- There are cases when previous options are ruled out of a
given deployment. I do believe that it is not simply due to
protocol exclusion, but rather to the fact that the SP wants
transport routing decisions to remain entirely within the
transport network (in order to fully leave the routing policy in
the hands of


                    

                  

                

              

            

            
people


            

              

                

                  

                    

                      
doing the layer dimensioning). Thus, I feel this trade-off in


                    

                  

                

              

            

            
path


            

              

                

                  

                    

                      
selection tuning is rather unlikely to happen and I fear we may


                    

                  

                

              

            

            
be


            

              

                

                  

                    

                      
talking about RSVP-TE over-engineering here.


                    

                    
The idea is simply to allow the client to express its


                  

                

              

            

            
needs/wishes.


            

              

                

                  

                    
The UNI-N remains in control.  By policy it can use the objective
function or not.  Further if it does use the objective function


                  

                

              

            

            
and


            

              

                

                  

                    
fails to find a path it can either say that there was no path or


                  

                

              

            

            
it


            

              

                

                  

                    
proceed to setup what it can.



                    

                      
(That is also why I preferred to consider your I-Ds separately
during the CCAMP meeting.)


                    

                    
Agreed.  I will ask for separate slots.  The discussion at the
end was rather disjointed.



                    

                      
However, my comments are mostly related to the client/transport
relationship. If the I-D is extended to cover more use cases
with wider scopes (Adrian has made interesting suggestions),
turning the overlay interconnection into one among a longer
list, then my conclusion may be different.


                    

                    
I'm happy to widen the scope in this way.

...George



                    

                      
Regards,

Julien


Le 11/09/2012 21:28, George Swallow (swallow) a écrit :


                      

                        
Julien -

Reading the CCAMP notes (which capture little of the actual
discussion) I see that there may have been a perception in the
room that PCE functionality at the UNI-N was assumed (actual or


                      

                    

                  

                

              

            

            
proxy).


            

              

                

                  

                    

                      

                        
This is not the case. The reason for our draft is that with the
UNI, much of the functionality that resides at the headend is
moved to the UNI-N. So the UNI-C needs a way to express an
objective function even if there is no PCE.

Operationally it seems burdensome to require a PCEP at the
UNI-C and a PCEP at the UNI-N, when all that is being done is
enabling the UNI-N to perform what the client would do if it
were connected to the network via a normal link.

Do you still object to the draft?

Thanks,

©George


                      

                    

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




                  

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


                

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






              

            

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


          

        

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


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






      

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


    

    

    
-- 

      
      

        

          

            
            
            

            

              
DIETER




                      BELLER

                

                  

                    
 ALCATEL-LUCENT

                          DEUTSCHLAND AG

                        PROJECT MANAGER ASON/GMPLS
                          CONTROL PLANE

                          NETWORKS GROUP, OPTICS DIVISION

                          TERRESTRIAL OPTICS UNIT

                          

                          Lorenzstrasse 10

                          70435 Stuttgart, Germany

                        T: +49 711 821 43125

                          M: +49 175 7266874

                        Dieter.Beller@alcatel-lucent.com

                            

                          Alcatel-Lucent
                            Deutschland AG

                            Domicile of the Company: Stuttgart · Local
                            Court Stuttgart HRB 4026

                            Chairman of the Supervisory Board: Michael
                            Oppenhoff

                            Board of Management: Wilhelm Dresselhaus
                            (Chairman) · Hans-Jörg Daub ·

                          Dr. Rainer Fechner ·
                            Andreas Gehe

                            

                          This e-mail and its
                            attachments, if any, may contain
                            confidential information.

                            If you have received this e-mail in error,
                            please notify us and delete or destroy the

                            e-mail and its attachments, if any,
                            immediately. If you have received this
                            e-mail in

                            error, you must not forward or make use of
                            the e-mail and its attachments, if any.

                    

                  

                

              

            

          

        

      

    

  


--------------030204010503080200050109
Content-Type: image/jpeg; name="Corporate-sig-logo.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline; filename="Corporate-sig-logo.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA
Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC
AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG
AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL
EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh
sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5
OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX
2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx
CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW
N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI
mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P
pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09
bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS
t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO
xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q
XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ
7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN
KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3
PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT
51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7
jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1
+i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K
Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp
jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i
yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d
L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R
1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ
PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN
t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0
E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo
JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox
q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv
utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr
KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD
bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y
8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm
1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr
5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3
10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH
yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW
YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq
0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t
fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9
5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti
z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn
ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H
urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N
PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf
4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R
HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR
Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh
7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f
If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd
WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D
2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q
iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox
c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0
6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f
Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z
9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c
FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F
/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0
w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu
LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK
KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI
pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o
NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3
vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c
Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi
8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY
8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/
EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V
MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl
pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w
8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN
z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63
rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3
FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP
2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i
fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/
g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1
XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70
m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p
4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np
T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY
pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo
6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV
BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x
HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3
b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U
49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN
25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi
apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h
/wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN
WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697
917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r
3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X
uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/
ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A
N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z
--------------030204010503080200050109--

From jdrake@juniper.net  Thu Sep 20 02:36: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 77E6A21F877B for ; Thu, 20 Sep 2012 02:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.682
X-Spam-Level: 
X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIrpig-TKZL0 for ; Thu, 20 Sep 2012 02:36:13 -0700 (PDT)
Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id C719121F877A for ; Thu, 20 Sep 2012 02:36:11 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUFrjhUXIA34L8uWWzaBv85xgOIyVW/rQ@postini.com; Thu, 20 Sep 2012 02:36:11 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::3c95:ce07:f642:ecd2%10]) with mapi; Thu, 20 Sep 2012 02:34:10 -0700
From: John E Drake 
To: Dieter Beller , Lou Berger , Gert Grammel , Igor Bryskin , "ccamp@ietf.org" 
Date: Thu, 20 Sep 2012 02:34:07 -0700
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: Ac2WxXo7onj/BPwgQWq/bM9nZixcxQATRNew
Message-ID: <5E893DB832F57341992548CDBB333163A63321B9B5@EMBX01-HQ.jnpr.net>
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>,  <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com> <505A0D6C.5000402@labn.net> <505A60CC.2080806@alcatel-lucent.com>
In-Reply-To: <505A60CC.2080806@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_004_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [CCAMP] Objective function draft
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, 20 Sep 2012 09:36:15 -0000

--_004_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_
Content-Type: multipart/alternative;
	boundary="_000_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_"

--_000_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Dieter,

I researched the terms when we made the switch from UNI to E-NNI and from w=
hat I recall, UNI is strictly signaling.  I think the terms are defined in =
G.8080 and I have copied Malcolm Betts in hope that he will provide a defin=
itive explanation of the terms.

Yours irrespectively,

John

From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com]
Sent: Wednesday, September 19, 2012 5:18 PM
To: Lou Berger; Gert Grammel; Igor Bryskin; John E Drake; ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Hi all,

the terms UNI and E-NNI are defining reference points or boundaries if you =
will between
a user (device) and a network (device) and between network domains, respect=
ively
(see RFC4208 or ITU-T G.8080). These reference points are located on data p=
lane links
between two network devices. Hence, the information that is exchanged acros=
s these
reference points, ie.e, the infomation on either end of the link is exactly=
 the same, which
means that no network layer is crossed at these reference points! Therefore=
, these
reference points are associated with a horizontal interface between the dev=
ices (same
network layer).

Now, orthogonal to that, we have layer transitions in the date plane if we =
are in a multi-layer
environment which means that a client signal is encapsulated into a server =
layer signal and
then carried transparently across the server layer network.
This is a data plane client/server relationship and we better talk about da=
ta plane layer
transitions and do not link these vertical inter-layer relationships to the=
 terms UNI or E-NNI
because they have a different meaning as described above. If we are sloppy =
regarding
terminology we may end up creating a lot of confusion.

I am in agreement with those who have posted similar messages.


Thanks,
Dieter
On 19.09.2012 20:22, Lou Berger wrote:

Gert/Igor/John,

        I sympathize with Julien's comments.  It seems to me that the draft

intermingles the concepts of multi-domain (which includes UNI/ENNI) and

multi-layer (which includes, for example MPLS over optical).  While

there certainly is much commonality in mechanisms, I think the draft

could be clearer on the conceptual definitions and discussions...



Lou



On 9/19/2012 1:00 PM, Gert Grammel wrote:

Lets try to be more precise and write instead:



- "this document uses the term 'External Network Interface (E-NNI)' to desc=
ribe this interface between two network domains. Both domains may switch on=
 different layers and form a client/server relationship.



Although I agree with better readability of the BCP, we have to address the=
 concern of the WG and be precise. So let's try perfecting our language ...



Gert



________________________________________

From: ccamp-bounces@ietf.org on behalf of Ig=
or Bryskin

Sent: Wednesday, September 19, 2012 12:25:58 PM

To: Julien Meuric; John E Drake

Cc: ccamp@ietf.org

Subject: Re: [CCAMP] Objective function draft



Hi Julien,



This should say:

- "this document uses the term 'External Network Network Interface (E-NNI)'=
 to describe this interface between a client and server network domains".



The important thing is that there is a TE domain demarcation between networ=
k and its client. The similar demarcation exists between adjacent network d=
omains in a multi-domain environment. In either case the domains are inter-=
connected via access/inter-domain links in the data plane and GMPLS-ENNI in=
 the control plane.



Hope this helps.

Igor







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

From: ccamp-bounces@ietf.org [mailto:ccamp-b=
ounces@ietf.org] On Behalf Of Julien Meuric

Sent: Wednesday, September 19, 2012 11:59 AM

To: John E Drake

Cc: ccamp@ietf.org

Subject: Re: [CCAMP] Objective function draft



Hi John.



Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:

- "this memo describes how introducing a representation of server layer net=
work resources into a client layer network topology enhances client layer n=
etworking in the overlay model";

- "this document uses the term 'External Network Network Interface (E-NNI)'=
 to describe this interface between a client and server network".



E-NNI for client-server (and overlay): this is exactly where I start to get=
 confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to follow =
on this.)



Julien





On 09/19/2012 16:03, John E Drake wrote:

Julien,



This is the terminology we have been using in draft-beeram.



Yours irrespectively,



John





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

From: ccamp-bounces@ietf.org [mailto:ccamp-b=
ounces@ietf.org] On

Behalf Of Julien Meuric



Lou, Gert,



You are right: my previous 1st sentence was too specific,

"inter-layer signaling" should be replaced by "client-server

signaling". We agree on that, it was not my intention to question that part=
.



Regards,



Julien





Le 19/09/2012 13:46, Lou Berger a =E9crit :

Julien,

    Just to add to Gert's point about UNI/ENNI not being related to

layers; you can find the same terminology in the context of MPLS-TP,

see RFCs

6215 and 5921.  We already have RFC4208 which provides the

foundation of a GMPLS UNI, and the related RFC5787(bis) work.



I personally see this as the foundation and context for this (and

the

beeram) discussion.



Lou



On 9/19/2012 3:14 AM, Gert Grammel wrote:

Hi Julien,



Most of the discussions about UNI/ENNI are confusing. Let's start

with the remark that UNI/ENNI are terms defined in G.709 and do not

relate to layers. They are reference points. You can think to place

them in the middle of the fiber between a router and a ROADM. Since

it is just fiber, it is pretty clear that no layer crossing is

happening there.

In IETF we have the overlay concept which also doesn't relate to

layers but to an administrative domain. Hence an operator can choose

to place a 'GMPLS-UNI' where he wants.

Admittedly common wisdom places UNI as inter-layer communication

and

here is where confusion starts. AFAIK the terms UNI-C and UNI-N as

well as the notion of a 'UNI-protocol' have been brought up in OIF.

For whatever it is or was, initial UNI was from SDH/SONET client to

SDH/SONET server, hence again no layer crossing even at the protocol

level.

If different layer switching is involved on both sides of an

interface, the best reference is RFC5212 (requirements) and RFC6001.

They define a consistent multi-layer switching and adaptation model.

So in order to stay inside a consistent terminology we decided to

go

strictly with IETF terminology. That's the best we can do for now.

To your points:

- the routing task involves both the IGP and the signaling

protocol, especially in case of loose hops or crankbacks;

--> what you mean with routing task? Is it the routing process

itself or something more?

- the objective function only makes sense per LSP, which allows to

consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to

IGPs or LMP).

--> an objective function could make sense per LSP if routing

information is insufficient. It starts with the assumption that a

router down the road may be able to find a better path than what the

ingress router does. Given that the ingress has no means to verify if

the objective has been followed this may turn out to become a

debugging nightmare.

Gert









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

From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]



I an completely sharing Julien's point of view.



JP Vasseur

Cisco Fellow



Sent from my iPhone



On 18 sept. 2012, at 05:27, "Julien Meuric"

 wrote:

Hi Gert.



As Daniele has just said, almost all the information in an inter-

layer signaling can be seen as input/constraints to the routing

process. The IGP-TE brings some link-state information to some

network nodes so as to achieve path computation; the result is used

in the signaling protocol, on a per LSP basis. I would said that:

- the routing task involves both the IGP and the signaling

protocol,

especially in case of loose hops or crankbacks;

- the objective function only makes sense per LSP, which allows to

consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed to

IGPs or LMP).

I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly introducing

some great confusion in the vocabulary: it is a superset of draft-

beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T

reference point. A possible option is just to avoid those terms and

stick to protocols, namely RSVP-TE and IGP-TE.

Regards,



Julien





Le 17/09/2012 23:22, Gert Grammel a =E9crit :

Hi George,



The objective function is in the end a routing information.

Mixing

routing and signaling in one protocol is something I don't feel

comfortable with.

In other words, if routing is needed between client and server,

UNI

is the wrong choice. ENNI should be considered instead and Draft-

beeram-ccamp-gmpls-enni would be a good starting point.



Gert







________________________________________

From: ccamp-bounces@ietf.org on behalf of Ge=
orge Swallow

(swallow)



Hi Julien -



On 9/17/12 9:37 AM, "Julien Meuric" 

wrote:

Hi George.



Sorry for the late response. You are right: the minutes are not

enough to trace the full discussion (which we also resumed right

after the meeting). Let us start by thanking Adrian (as AD?

former PCE co-chair?

author of... ;-) ) for bringing the PCE-associated vocabulary to

a

common understanding.



Actually my concern is sustained by 2 points:



1- The scope of the draft is about giving control of the routing

objective function to the client node facing a transport layer.

I see already several existing solution to achieve it:

- a PCEP request from the signaling head node is an option

(which is associated to the advertisement of the supported

objectives in PCEP);

- building IGP adjacencies between client and transport edge

nodes

(a.k.a. "border model") is another one.

In this context, it do not think extending RSVP-TE for this kind

of application is worth the effort, since the requirement can

already be addressed.

As I understand it, in the optical and OTN cases, the border

model would not be popular as in many organizations this crosses

political boundaries.



The point of the draft is to keep the UNI implementation simple

and

not require a PCEP on the uni-c or necessarily on the uni-n.  We

will keep the format aligned so if the UNI-N needs to make a

request of a PCS, it can do so rather simply.

2- There are cases when previous options are ruled out of a

given deployment. I do believe that it is not simply due to

protocol exclusion, but rather to the fact that the SP wants

transport routing decisions to remain entirely within the

transport network (in order to fully leave the routing policy in

the hands of

people

doing the layer dimensioning). Thus, I feel this trade-off in

path

selection tuning is rather unlikely to happen and I fear we may

be

talking about RSVP-TE over-engineering here.

The idea is simply to allow the client to express its

needs/wishes.

The UNI-N remains in control.  By policy it can use the objective

function or not.  Further if it does use the objective function

and

fails to find a path it can either say that there was no path or

it

proceed to setup what it can.



(That is also why I preferred to consider your I-Ds separately

during the CCAMP meeting.)

Agreed.  I will ask for separate slots.  The discussion at the

end was rather disjointed.



However, my comments are mostly related to the client/transport

relationship. If the I-D is extended to cover more use cases

with wider scopes (Adrian has made interesting suggestions),

turning the overlay interconnection into one among a longer

list, then my conclusion may be different.

I'm happy to widen the scope in this way.



...George



Regards,



Julien





Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :

Julien -



Reading the CCAMP notes (which capture little of the actual

discussion) I see that there may have been a perception in the

room that PCE functionality at the UNI-N was assumed (actual or

proxy).

This is not the case. The reason for our draft is that with the

UNI, much of the functionality that resides at the headend is

moved to the UNI-N. So the UNI-C needs a way to express an

objective function even if there is no PCE.



Operationally it seems burdensome to require a PCEP at the

UNI-C and a PCEP at the UNI-N, when all that is being done is

enabling the UNI-N to perform what the client would do if it

were connected to the network via a normal link.



Do you still object to the draft?



Thanks,



=A9George

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp





_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp









_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp





_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp









_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

--
[cid:image001.jpg@01CD96D8.68B3AB40]
DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
NETWORKS GROUP, OPTICS DIVISION
TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10
70435 Stuttgart, Germany
T: +49 711 821 43125
M: +49 175 7266874
Dieter.Beller@alcatel-lucent.com

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart * Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) * Hans-J=F6rg Daub *
Dr. Rainer Fechner * Andreas Gehe

This e-mail and its attachments, if any, may contain confidential informati=
on.
If you have received this e-mail in error, please notify us and delete or d=
estroy the
e-mail and its attachments, if any, immediately. If you have received this =
e-mail in
error, you must not forward or make use of the e-mail and its attachments, =
if any.

--_000_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable



=
Dieter,
 =

I researched the terms when we=
 made the switch from UNI to E-NNI and from what I recall, UNI is strictly =
signaling.=A0 I think the terms are defined in G.8080 and I have copied Mal=
colm Betts in hope that he will provide a definitive explanation of the ter=
ms.
 
Yours irrespectively,
 
John
 
<=
span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:wind=
owtext'>From: Dieter Beller [mailto:Dieter.Beller@alcat=
el-lucent.com] 
Sent: Wednesday, September 19, 2012 5:18 PM
To: Lou Berger; Gert Grammel; Igor Bryskin; John E Drake; ccamp@ietf.o=
rg
Subject: Re: [CCAMP] Objective function draft
 
Hi all,

the terms UNI and E-NNI =
are defining reference points or boundaries if you will between
a user (=
device) and a network (device) and between network domains, respectively(see RFC4208 or ITU-T G.8080). These reference points are located on data =
plane links
between two network devices. Hence, the information that is =
exchanged across these
reference points, ie.e, the infomation on either =
end of the link is exactly the same, which
means that no network layer i=
s crossed at these reference points! Therefore, these
reference points a=
re associated with a horizontal interface between the devices (same
netw=
ork layer).

Now, orthogonal to that, we have layer transitions in th=
e date plane if we are in a multi-layer
environment which means that a c=
lient signal is encapsulated into a server layer signal and
then carried=
 transparently across the server layer network.
This is a data plane cli=
ent/server relationship and we better talk about data plane layer
transi=
tions and do not link these vertical inter-layer relationships to the terms=
 UNI or E-NNI
because they have a different meaning as described above. =
If we are sloppy regarding
terminology we may end up creating a lot of c=
onfusion.

I am in agreement with those who have posted similar messa=
ges.


Thanks,
Dieter
O=
n 19.09.2012 20:22, Lou Berger wrote:
Gert/Igor/John,
=A0=A0=A0=A0=A0=A0=A0 I sympathize with Julien's comments.=A0 It s=
eems to me that the draft
intermingles the concepts of=
 multi-domain (which includes UNI/ENNI) and
multi-laye=
r (which includes, for example MPLS over optical).=A0 While
there certainly is much commonality in mechanisms, I think the draft<=
o:p>
could be clearer on the conceptual definitions and dis=
cussions...
 
Lou=

 
On 9/19/2012 1:00 PM, Gert Grammel w=
rote:
Lets try to be more precise and write instead:
<=
pre> 
- "this document uses the term 'Extern=
al Network Interface (E-NNI)' to describe this interface between two networ=
k domains. Both domains may switch on different layers and form a client/se=
rver relationship.
 
Althoug=
h I agree with better readability of the BCP, we have to address the concer=
n of the WG and be precise. So let's try perfecting our language ...
 
Gert
&=
nbsp;
________________________________________
From: ccamp-bounces@ietf=
.org on behalf of Igor Bryskin
Sent: Wednesday, Se=
ptember 19, 2012 12:25:58 PM
To: Julien Meuric; John E=
 Drake
Cc: ccamp@iet=
f.org
Subject: Re: [CCAMP] Objective function draf=
t
 
Hi Julien,
 
This should say:
-=
 "this document uses the term 'External Network Network Interface (E-N=
NI)' to describe this interface between a client and server network domains=
".
 
The important thin=
g is that there is a TE domain demarcation between network and its client. =
The similar demarcation exists between adjacent network domains in a multi-=
domain environment. In either case the domains are inter-connected via acce=
ss/inter-domain links in the data plane and GMPLS-ENNI in the control plane=
.
 
Hope this helps.
Igor
 
&n=
bsp;
 
-----Original Message-----=

From: ccamp=
-bounces@ietf.org [mailto:cca=
mp-bounces@ietf.org] On Behalf Of Julien Meuric
Se=
nt: Wednesday, September 19, 2012 11:59 AM
To: John E =
Drake
Cc: ccamp@ietf=
.org
Subject: Re: [CCAMP] Objective function draft=

 
Hi John.
=

 
Let me quote the introduction of draft-bee=
ram-ccamp-gmpls-enni:
- "this memo describes how =
introducing a representation of server layer network resources into a clien=
t layer network topology enhances client layer networking in the overlay mo=
del";
- "this document uses the term 'Extern=
al Network Network Interface (E-NNI)' to describe this interface between a =
client and server network".
 
E-NNI for client-server (and overlay): this is exactly where I start=
 to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be easier to =
follow on this.)
 
Julien
 
 
=
On 09/19/2012 16:03, John E Drake wrote:
Julien,
 
This is the terminology we have been using in =
draft-beeram.
 
Yours irresp=
ectively,
 
John<=
/pre>
 
 
-----Original Message----=
-
From: ccam=
p-bounces@ietf.org [mailto:cc=
amp-bounces@ietf.org] On
Behalf Of Julien Meuric
 
Lou, Gert,
=

 
You are right: my previous 1st sentence wa=
s too specific,
"inter-layer signaling" shou=
ld be replaced by "client-server
signaling".=
 We agree on that, it was not my intention to question that part.
 
Regards,
=
 
Julien
 
<=
pre> 
Le 19/09/2012 13:46, Lou Berger a =E9crit :=

Julien,
=A0=A0=A0 Just to add to Gert's point ab=
out UNI/ENNI not being related to
layers; you can find=
 the same terminology in the context of MPLS-TP,
see R=
FCs
6215 and 5921.=A0 We already have RFC4208 which pr=
ovides the
foundation of a GMPLS UNI, and the related =
RFC5787(bis) work.
 
I perso=
nally see this as the foundation and context for this (and
=

the
beeram) discussion.
 
Lou
 
On 9/19/2012 3:14 AM, Gert Grammel wrote:
Hi Julien,
 
Most of the discussions about UNI/ENNI ar=
e confusing. Let's start
wit=
h the remark that UNI/ENNI are terms defined in G.709 and do not=

relate to layers. They are reference points. You can think to pl=
ace
them in the middle of the fiber between a router a=
nd a ROADM. Since
it is just fiber, it is pretty clear=
 that no layer crossing is
happening there.=

In IETF we have the o=
verlay concept which also doesn't relate to
layers but to an administrative domain. Hence an operator c=
an choose
to place a 'GMPLS-UNI' where he wants.<=
/o:p>
Admittedly commo=
n wisdom places UNI as inter-layer communication
and
here is where confusion start=
s. AFAIK the terms UNI-C and UNI-N as
well as the noti=
on of a 'UNI-protocol' have been brought up in OIF.
Fo=
r whatever it is or was, initial UNI was from SDH/SONET client to
SDH/SONET server, hence again no layer crossing even at the pro=
tocol
level.
If different layer switching is involved on both sid=
es of an
interface, the best=
 reference is RFC5212 (requirements) and RFC6001.
They=
 define a consistent multi-layer switching and adaptation model.=

So in order to stay i=
nside a consistent terminology we decided to
go
strictly with IETF terminology. Th=
at's the best we can do for now.
To your points:
- the routing ta=
sk involves both the IGP and the signaling
protocol, e=
specially in case of loose hops or crankbacks;
--> =
what you mean with routing task? Is it the routing process
=

itself or something more?
- the objective function onl=
y makes sense per LSP, which allows to
consider it in LSP-related protocols (PCEP, RSVP-TE... as oppose=
d to
IGPs or LMP).
--> an objective function could make sens=
e per LSP if routing
informa=
tion is insufficient. It starts with the assumption that a
=

router down the road may be able to find a better path than what the
ingress router does. Given that the ingress has no mean=
s to verify if
the objective has been followed this ma=
y turn out to become a
debugging nightmare.=

Gert
=

 
 
 
 
-----Original Message-----
From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
 
I an completely sharing Julien's point of view.
 
JP Vasseur
Cisco Fel=
low
 
Sent from my iPhone
 
On 18 sept. 2012, at 05:27, =
"Julien Meuric"
<julien.meuric@orange.com><=
/a> wrote:
Hi Gert.
 
As Daniele has just said, almost =
all the information in an inter-
=

layer signaling can be seen as input/constraints to the r=
outing
process. The IGP-TE brings some link-state info=
rmation to some
network nodes so as to achieve path co=
mputation; the result is used
in the signaling protoco=
l, on a per LSP basis. I would said that:
- the routing task involves both the IGP and the signaling
protocol,
especially in case of loose hops =
or crankbacks;
- the objective function only makes sen=
se per LSP, which allows to
consider it in LSP-related protocols (PCEP, RSVP-TE... as oppo=
sed to
IGPs or LMP).
I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly intro=
ducing
some gre=
at confusion in the vocabulary: it is a superset of draft-
=

beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the ITU-T
reference point. A possible option is just to avoid tho=
se terms and
stick to protocols, namely RSVP-TE and IG=
P-TE.
Regards,
 
Julien
 =
;
 
Le 17/09/2012 23:22, Gert Gra=
mmel a =E9crit :
Hi George,
 
The objective function is in the end a routing information.
Mixing
=

routing and signaling in one protocol is something I don'=
t feel
comfortable with.
In other words, if routing is needed between client and server,
UNI
is the wrong choice. ENNI should be considered in=
stead and Draft-
beeram-ccamp-gmpls-enni would be a good starting point.=

 
Gert
 
 
 <=
/o:p>
________________________________________
From: ccamp-bounces@ietf.org on behalf of George Swallow
(swallow)
 
Hi Julien -
&=
nbsp;
On 9/17/12 9:37 AM, "Julien Meuric" <julien.meuric@orange.com>
wro=
te:
Hi George.
 
=

Sorry for the late response. You are right: the minutes are not
enough to trace the full discussion (which we also resumed r=
ight
after the meeting). Let us start by thanking Adri=
an (as AD?
former PCE co-chair?
author of... ;-)=
 ) for bringing the PCE-associated vocabulary to
a
common understanding.
 
A=
ctually my concern is sustained by 2 points:
&nbs=
p;
1- The scope of the draft is about giving control of the=
 routing
objective function to the client node facing =
a transport layer.
I see already several existing solu=
tion to achieve it:
- a PCEP request from the signalin=
g head node is an option
(which is associated to the a=
dvertisement of the supported
objectives in PCEP);
- building IGP adjacencies between client and transport e=
dge
nodes
(a.k.a. "border model") is a=
nother one.
In this context, it do not think extending=
 RSVP-TE for this kind
of application is worth the eff=
ort, since the requirement can
already be addressed.
As I understand it, in the optical and OTN=
 cases, the border
model would not be popular as in ma=
ny organizations this crosses
political boundaries.
 
The point of the draft is to=
 keep the UNI implementation simple
and
not r=
equire a PCEP on the uni-c or necessarily on the uni-n.=A0 We
will keep the format aligned so if the UNI-N needs to make a
request of a PCS, it can do so rather simply.
2- There =
are cases when previous options are ruled out of a
giv=
en deployment. I do believe that it is not simply due to
protocol exclusion, but rather to the fact that the SP wants<=
/pre>
transport routing decisions to remain entirely within the
transport network (in order to fully leave the routing policy=
 in
the hands of
people
d=
oing the layer dimensioning). Thus, I feel this trade-off in
pat=
h
selection tuning is rather unlikely to happen and I fear =
we may
=

be
talking about RSVP-TE over-engineering=
 here.
The idea is simply to allow the cl=
ient to express its
=

needs/wishes.
=

The UNI-N r=
emains in control.=A0 By policy it can use the objective
function or not.=A0 Further if it does use the objective function
and=

fails to find a path it can either say that the=
re was no path or
it
proceed to setup what it=
 can.
 
(That is also why I preferred to con=
sider your I-Ds separately
during the CCAMP meeting.)<=
o:p>
Agreed.=A0 I will ask for separate slots.=
=A0 The discussion at the
end was rather disjointed.
 
However, my comments are mostly related to =
the client/transport
relationship. If the I-D is exten=
ded to cover more use cases
with wider scopes (Adrian =
has made interesting suggestions),
turning the overlay=
 interconnection into one among a longer
list, then my=
 conclusion may be different.
I'm happy t=
o widen the scope in this way.
 
=

...George
 
Regards,
 
Julien
 
 
Le 11/09/2012 21:28, George Swallow=
 (swallow) a =E9crit :
Julien -
 =

Reading the CCAMP notes (which capture little of the actual=

discussion) I see that there may have been a perception in=
 the
room that PCE functionality at the UNI-N was assu=
med (actual or
proxy).
<=
blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>
This is not the case. The re=
ason for our draft is that with the
UNI, much of the f=
unctionality that resides at the headend is
moved to t=
he UNI-N. So the UNI-C needs a way to express an
objec=
tive function even if there is no PCE.
 
Operationally it seems burdensome to require a PCEP at the
UNI-C and a PCEP at the UNI-N, when all that is being don=
e is
enabling the UNI-N to perform what the client wou=
ld do if it
were connected to the network via a normal=
 link.
 
Do you still object=
 to the draft?
 
Thanks,
 
=A9George
_______________________________________________=

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

_____________________________________________=
__
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/li=
stinfo/ccamp
________________________=
_______________________
CCAMP mailing list<=
/pre>
CCAMP@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/ccamp
 
 
 
&n=
bsp;
____________________________=
___________________
CCAMP mailing list
CCAMP@ietf.org
=

https://www.ie=
tf.org/mailman/listinfo/ccamp
 
_________________________________________=
______
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailm=
an/listinfo/ccamp
________________________________=
_______________
CCAMP mailing list
CCAMP@ietf.orghttps://www.ietf.o=
rg/mailman/listinfo/ccamp
 
<=
pre> 
___________________________________________=
____
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailm=
an/listinfo/ccamp
 
 
 
 
=

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

 
-- 
DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND A=
G
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
NETWORKS GROUP, OPTICS DIV=
ISION
TERRESTRIAL OPTICS UNIT

Lorenzstrasse 10
70435 Stuttgart=
, Germany
T: +49 711 821 43125
M: +49 175 7266874
Dieter.Beller@alcatel-lucent.com=


Alcatel-Lucent Deutschland AG
Domicile of the Co=
mpany: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the=
 Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dress=
elhaus (Chairman) · Hans-J=F6rg Daub ·
Dr. Rainer Fechner =
· Andreas Gehe

This e-mail and its attachments, if any, may c=
ontain confidential information.
If you have received this e-mail in err=
or, please notify us and delete or destroy the
e-mail and its attachment=
s, if any, immediately. If you have received this e-mail in
error, you m=
ust not forward or make use of the e-mail and its attachments, if any.
=

--_000_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_--

--_004_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_
Content-Type: image/jpeg; name="image001.jpg"
Content-Description: image001.jpg
Content-Disposition: inline; filename="image001.jpg"; size=5715;
	creation-date="Thu, 20 Sep 2012 09:34:08 GMT";
	modification-date="Thu, 20 Sep 2012 09:34:08 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAAAf/b
AIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgIC
AwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAGAgMBAAAAAAAAAAAA
AAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAACAQMEAQMDAgMDAwIG
CXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIKGcHRNSfhUzaC8ZKi
RFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdoaWp2d3h5eoWGh4iJ
ipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT19vf4+foRAAIBAwIE
BAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMY
Y0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4
doaWprbG1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq
+v/aAAwDAQACEQMRAD8A3+Pfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfu
vde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691
737r3Xvfuvde9+691737r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvn
sm0T1ExVp4aKgx+PpIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBV
RQWdjhVBPl09bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnD
snYeNhlSt353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs
6eNOxxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q
XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ7Acj
e43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BINKHjT7QSP
l1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3PH4/Pq/b0eT0
e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT51rSnRWch3x82aXq
D5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7jxFdV1j4TJaq6J6L7a/l
kQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1+i9/YvC0VVt7r6j2f9umY7C/
jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4KYys7u617g3DtL45dIN8iev44/kN1
HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWpjPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN
0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72iyUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfP
qn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0dL3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkF
WRjEDeM1aInut0WtK46Hyr7F+REPyX2R1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvW
b0i7jz1LWYYx1K5iFkpWMrKQhgZZPdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh
1/HTdgdV0u+MRhIO0YOz5aBNt4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0H
FV/Gyr6SrN75T5Mnsfb0E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/I
n5+r8YMp2ZT/AAAoJPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6P
fut0WtK4+zoxq9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNE
SRCCZCQvutUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9pp
iTtrKyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD
bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y8h8B
8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm1HVSyx+/
dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr5+uzTrn9ttja
eJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b310AfkPsCeDoPqKv3
bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaHyVl787t2HP8AGeli6R2R
1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoWYI8c6BPdaoKcc9BLi++PnVU9
IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq0W8o6WTC9mVWJ29j8dkP4JjmWtL5
E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11tfcXx07THcm1UqPkPv7J7Xq8luHYNbtE0
L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q95/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2
M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Tiz91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx
8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZnObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8A
Y6S1D3l8yKjY/wAOs3UfC+Cm3h3HurA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0z
OT4L+V1ce63Rc5+zrXk/m+/NPFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27
fkrt/dO69n7RzOydsQYf4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQv
eG1+kG+YX8475J7RHyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWq
qJI09+69QUqRWi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou
3N0bl7bh7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP
/n3fIf4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd
WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D2f1j
uzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1qiUOe2or5
06MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7oxc9PgMzNkcNHF
kIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi06hgjpyeOGOR0t38S
EEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2fUz/7L/2dlPieazAU9AaO
T+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z9H8DvlB/M/h762NkqPau5e3u
v9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7cFNU1VJjK2i/ap6emp5EqT7reldQT
+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM
/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+
SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cuLyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7
/hQ7W75qfjn8beq9vy1mal7A7yo6KvpKKlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+
8sfulw7fFzVu283xVTabWSHbgiNIpkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt74
2fyrYqvMb7+RvyK33s7fPy0oNgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHk
q9o6Srnp8od3vMvNvOF3vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXb
S7xhbWJSI9Qr8u0cKk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5
Jtr9LVf9/cbi8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WV
oZGuKSXY8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv
/u5/EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V
MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7AhlpnTdC5HaVFFj
pVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w8FNt+u3vjtqYfY2O
3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjNz7Oqcl8PuhpZthbewm09
sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63rb1PSw3N8BfhPvPcvbe8N2fF
force5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3FUlcKtl+7NZSQTmQywxuvuvam9Tj
pWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2
MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7ifx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/
AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSx
HX2Dx22tgxYlkpBTRVmx9vYejosPVtG1XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+
3Oz9uZ/aXY2+JuvduT5TfO392U70m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnT
L13/AC+vhL1NjosR1z8Yen9p4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4
o8aaiT7dYw7X91ssx4npT9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ3
3Xzz0xqTuyh2hQxYpK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7L
VQlpsPg947Zo6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBco
tNTQuQSVBoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ
2D2xHndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3
b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U49O+
U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN25jcvXfa
4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMiapnXUqqFLJEr
N1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h/wANi+4/0ufxn++n
9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sNWPpdHg+Bq4avB/Hpp4v6
mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697917r3v3Xuve/de697917r3v3
Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de6
97917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3XugA+RP/AB59D/zI
D/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9
J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8AN3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/a
n4/9v8X59C17IumOv//Z

--_004_5E893DB832F57341992548CDBB333163A63321B9B5EMBX01HQjnprn_--

From IBryskin@advaoptical.com  Thu Sep 20 07:16: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 674E821F877E for ; Thu, 20 Sep 2012 07:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8guFfP+2Xuz1 for ; Thu, 20 Sep 2012 07:16:53 -0700 (PDT)
Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) by ietfa.amsl.com (Postfix) with ESMTP id A8FFF21F86E5 for ; Thu, 20 Sep 2012 07:16:52 -0700 (PDT)
Received: from MUC-SRV-MAIL10B.advaoptical.com ([172.20.1.60]) by muc-vsrv-fsmail.advaoptical.com (8.14.4/8.14.4) with ESMTP id q8KEGkmV011798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 16:16:46 +0200
Received: from MUC-SRV-MBX2.advaoptical.com (172.20.1.96) by MUC-SRV-MAIL10B.advaoptical.com (172.20.1.60) with Microsoft SMTP Server (TLS) id 14.3.83.0; Thu, 20 Sep 2012 16:16:46 +0200
Received: from ATL-SRV-MAIL10.atl.advaoptical.com (172.16.5.39) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.508.9; Thu, 20 Sep 2012 16:16:46 +0200
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.03.0083.000; Thu, 20 Sep 2012 10:16:43 -0400
From: Igor Bryskin 
To: Lou Berger 
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNlRqGvMjYkYKv7UmMh7Ftclf6H5eQSrkAgAAAqICAATpfAIAAS/CAgAAjlQCAAAKMgIAAIFcA///BdECAAE+ygIAAFwcA//++zHCAAFNWAIAA99QQ
Date: Thu, 20 Sep 2012 14:16:42 +0000
Message-ID: 
References: <305443B66F0CD946A3107753337A0311F533@CH1PRD0511MB431.namprd05.prod.outlook.com>, <505868A4.6020802@orange.com>  <305443B66F0CD946A3107753337A0311012339@CH1PRD0511MB431.namprd05.prod.outlook.com> <5059B09B.3050005@labn.net> <5059CE74.6030803@orange.com> <5E893DB832F57341992548CDBB333163A63321B55E@EMBX01-HQ.jnpr.net> <5059EBB8.8010304@orange.com>,  <305443B66F0CD946A3107753337A03110124E9@CH1PRD0511MB431.namprd05.prod.outlook.com> <505A0D6C.5000402@labn.net>  <505A1CA2.2050406@labn.net>
In-Reply-To: <505A1CA2.2050406@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.21.1.81]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-20_04:2012-09-20, 2012-09-19, 1970-01-01 signatures=0
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] Objective function draft
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, 20 Sep 2012 14:16:54 -0000

Lou,

We will take another round to make it clear. Also. The draft we are writing=
 with Daniele should help in this regard.

Igor

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Wednesday, September 19, 2012 3:28 PM
To: Igor Bryskin
Cc: Gert Grammel; John E Drake; Julien Meuric; ccamp@ietf.org
Subject: Re: [CCAMP] Objective function draft

Igor,
	I completely agree, but don't see this clearly articulated in the current =
draft.

Lou

On 9/19/2012 2:36 PM, Igor Bryskin wrote:
> Lou,
>=20
> In the context of ENNI/UNI the multi-domain aspect is important, the=20
> multi-layer aspect is not important at all. Although, generally=20
> speaking, network and client physically exist in different layers=20
> (which by the way not always the case) they always peer each other in=20
> the same (client) layer, virtual topology exposed to the client also=20
> belongs to the same (client) layer.
>=20
> Igor
>=20
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, September 19, 2012 2:23 PM
> To: Gert Grammel; Igor Bryskin; John E Drake
> Cc: Julien Meuric; ccamp@ietf.org
> Subject: Re: [CCAMP] Objective function draft
>=20
> Gert/Igor/John,
> 	I sympathize with Julien's comments.  It seems to me that the draft inte=
rmingles the concepts of multi-domain (which includes UNI/ENNI) and multi-l=
ayer (which includes, for example MPLS over optical).  While there certainl=
y is much commonality in mechanisms, I think the draft could be clearer on =
the conceptual definitions and discussions...
>=20
> Lou
>=20
> On 9/19/2012 1:00 PM, Gert Grammel wrote:
>> Lets try to be more precise and write instead:
>>
>> - "this document uses the term 'External Network Interface (E-NNI)' to d=
escribe this interface between two network domains. Both domains may switch=
 on different layers and form a client/server relationship.
>>
>> Although I agree with better readability of the BCP, we have to address =
the concern of the WG and be precise. So let's try perfecting our language =
...
>>
>> Gert
>>
>> ________________________________________
>> From: ccamp-bounces@ietf.org on behalf of Igor Bryskin
>> Sent: Wednesday, September 19, 2012 12:25:58 PM
>> To: Julien Meuric; John E Drake
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Objective function draft
>>
>> Hi Julien,
>>
>> This should say:
>> - "this document uses the term 'External Network Network Interface (E-NN=
I)' to describe this interface between a client and server network domains"=
.
>>
>> The important thing is that there is a TE domain demarcation between net=
work and its client. The similar demarcation exists between adjacent networ=
k domains in a multi-domain environment. In either case the domains are int=
er-connected via access/inter-domain links in the data plane and GMPLS-ENNI=
 in the control plane.
>>
>> Hope this helps.
>> Igor
>>
>>
>>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20
>> Behalf Of Julien Meuric
>> Sent: Wednesday, September 19, 2012 11:59 AM
>> To: John E Drake
>> Cc: ccamp@ietf.org
>> Subject: Re: [CCAMP] Objective function draft
>>
>> Hi John.
>>
>> Let me quote the introduction of draft-beeram-ccamp-gmpls-enni:
>> - "this memo describes how introducing a representation of server=20
>> layer network resources into a client layer network topology enhances=20
>> client layer networking in the overlay model";
>> - "this document uses the term 'External Network Network Interface (E-NN=
I)' to describe this interface between a client and server network".
>>
>> E-NNI for client-server (and overlay): this is exactly where I start=20
>> to get confused... (draft-beeram-ccamp-gmpls-uni-bcp used to be=20
>> easier to follow on this.)
>>
>> Julien
>>
>>
>> On 09/19/2012 16:03, John E Drake wrote:
>>> Julien,
>>>
>>> This is the terminology we have been using in draft-beeram.
>>>
>>> Yours irrespectively,
>>>
>>> John
>>>
>>>
>>>> -----Original Message-----
>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20
>>>> Behalf Of Julien Meuric
>>>>
>>>> Lou, Gert,
>>>>
>>>> You are right: my previous 1st sentence was too specific,=20
>>>> "inter-layer signaling" should be replaced by "client-server=20
>>>> signaling". We agree on that, it was not my intention to question that=
 part.
>>>>
>>>> Regards,
>>>>
>>>> Julien
>>>>
>>>>
>>>> Le 19/09/2012 13:46, Lou Berger a =E9crit :
>>>>> Julien,
>>>>>     Just to add to Gert's point about UNI/ENNI not being related=20
>>>>> to layers; you can find the same terminology in the context of=20
>>>>> MPLS-TP, see RFCs
>>>>> 6215 and 5921.  We already have RFC4208 which provides the=20
>>>>> foundation of a GMPLS UNI, and the related RFC5787(bis) work.
>>>>>
>>>>> I personally see this as the foundation and context for this (and=20
>>>>> the
>>>>> beeram) discussion.
>>>>>
>>>>> Lou
>>>>>
>>>>> On 9/19/2012 3:14 AM, Gert Grammel wrote:
>>>>>> Hi Julien,
>>>>>>
>>>>>> Most of the discussions about UNI/ENNI are confusing. Let's start
>>>> with the remark that UNI/ENNI are terms defined in G.709 and do not=20
>>>> relate to layers. They are reference points. You can think to place=20
>>>> them in the middle of the fiber between a router and a ROADM. Since=20
>>>> it is just fiber, it is pretty clear that no layer crossing is=20
>>>> happening there.
>>>>>> In IETF we have the overlay concept which also doesn't relate to
>>>> layers but to an administrative domain. Hence an operator can=20
>>>> choose to place a 'GMPLS-UNI' where he wants.
>>>>>> Admittedly common wisdom places UNI as inter-layer communication=20
>>>>>> and
>>>> here is where confusion starts. AFAIK the terms UNI-C and UNI-N as=20
>>>> well as the notion of a 'UNI-protocol' have been brought up in OIF.
>>>> For whatever it is or was, initial UNI was from SDH/SONET client to=20
>>>> SDH/SONET server, hence again no layer crossing even at the=20
>>>> protocol level.
>>>>>> If different layer switching is involved on both sides of an
>>>> interface, the best reference is RFC5212 (requirements) and RFC6001.
>>>> They define a consistent multi-layer switching and adaptation model.
>>>>>> So in order to stay inside a consistent terminology we decided to=20
>>>>>> go
>>>> strictly with IETF terminology. That's the best we can do for now.
>>>>>> To your points:
>>>>>> - the routing task involves both the IGP and the signaling=20
>>>>>> protocol, especially in case of loose hops or crankbacks;
>>>>>> --> what you mean with routing task? Is it the routing process
>>>> itself or something more?
>>>>>> - the objective function only makes sense per LSP, which allows=20
>>>>>> to
>>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed=20
>>>> to IGPs or LMP).
>>>>>> --> an objective function could make sense per LSP if routing
>>>> information is insufficient. It starts with the assumption that a=20
>>>> router down the road may be able to find a better path than what=20
>>>> the ingress router does. Given that the ingress has no means to=20
>>>> verify if the objective has been followed this may turn out to=20
>>>> become a debugging nightmare.
>>>>>> Gert
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
>>>>>>
>>>>>> I an completely sharing Julien's point of view.
>>>>>>
>>>>>> JP Vasseur
>>>>>> Cisco Fellow
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 18 sept. 2012, at 05:27, "Julien Meuric"
>>>>  wrote:
>>>>>>> Hi Gert.
>>>>>>>
>>>>>>> As Daniele has just said, almost all the information in an=20
>>>>>>> inter-
>>>> layer signaling can be seen as input/constraints to the routing=20
>>>> process. The IGP-TE brings some link-state information to some=20
>>>> network nodes so as to achieve path computation; the result is used=20
>>>> in the signaling protocol, on a per LSP basis. I would said that:
>>>>>>> - the routing task involves both the IGP and the signaling
>>>> protocol,
>>>>>>> especially in case of loose hops or crankbacks;
>>>>>>> - the objective function only makes sense per LSP, which allows=20
>>>>>>> to
>>>> consider it in LSP-related protocols (PCEP, RSVP-TE... as opposed=20
>>>> to IGPs or LMP).
>>>>>>> I feel that draft-beeram-ccamp-gmpls-_enni_ is clearly=20
>>>>>>> introducing
>>>> some great confusion in the vocabulary: it is a superset of draft-=20
>>>> beeram-ccamp-gmpls-_uni_-bcp while removing the pointer to the=20
>>>> ITU-T reference point. A possible option is just to avoid those=20
>>>> terms and stick to protocols, namely RSVP-TE and IGP-TE.
>>>>>>> Regards,
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le 17/09/2012 23:22, Gert Grammel a =E9crit :
>>>>>>>> Hi George,
>>>>>>>>
>>>>>>>> The objective function is in the end a routing information.
>>>>>>>> Mixing
>>>> routing and signaling in one protocol is something I don't feel=20
>>>> comfortable with.
>>>>>>>> In other words, if routing is needed between client and server,
>>>> UNI
>>>>>>>> is the wrong choice. ENNI should be considered instead and
>>>>>>>> Draft-
>>>> beeram-ccamp-gmpls-enni would be a good starting point.
>>>>>>>>
>>>>>>>> Gert
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ________________________________________
>>>>>>>> From: ccamp-bounces@ietf.org on behalf of George Swallow
>>>>>>>> (swallow)
>>>>>>>>
>>>>>>>> Hi Julien -
>>>>>>>>
>>>>>>>> On 9/17/12 9:37 AM, "Julien Meuric" 
>>>> wrote:
>>>>>>>>> Hi George.
>>>>>>>>>
>>>>>>>>> Sorry for the late response. You are right: the minutes are=20
>>>>>>>>> not enough to trace the full discussion (which we also resumed=20
>>>>>>>>> right after the meeting). Let us start by thanking Adrian (as AD?
>>>> former PCE co-chair?
>>>>>>>>> author of... ;-) ) for bringing the PCE-associated vocabulary=20
>>>>>>>>> to
>>>> a
>>>>>>>>> common understanding.
>>>>>>>>>
>>>>>>>>> Actually my concern is sustained by 2 points:
>>>>>>>>>
>>>>>>>>> 1- The scope of the draft is about giving control of the=20
>>>>>>>>> routing objective function to the client node facing a transport =
layer.
>>>>>>>>> I see already several existing solution to achieve it:
>>>>>>>>> - a PCEP request from the signaling head node is an option=20
>>>>>>>>> (which is associated to the advertisement of the supported=20
>>>>>>>>> objectives in PCEP);
>>>>>>>>> - building IGP adjacencies between client and transport edge
>>>> nodes
>>>>>>>>> (a.k.a. "border model") is another one.
>>>>>>>>> In this context, it do not think extending RSVP-TE for this=20
>>>>>>>>> kind of application is worth the effort, since the requirement=20
>>>>>>>>> can already be addressed.
>>>>>>>> As I understand it, in the optical and OTN cases, the border=20
>>>>>>>> model would not be popular as in many organizations this=20
>>>>>>>> crosses political boundaries.
>>>>>>>>
>>>>>>>> The point of the draft is to keep the UNI implementation simple
>>>> and
>>>>>>>> not require a PCEP on the uni-c or necessarily on the uni-n. =20
>>>>>>>> We will keep the format aligned so if the UNI-N needs to make a=20
>>>>>>>> request of a PCS, it can do so rather simply.
>>>>>>>>> 2- There are cases when previous options are ruled out of a=20
>>>>>>>>> given deployment. I do believe that it is not simply due to=20
>>>>>>>>> protocol exclusion, but rather to the fact that the SP wants=20
>>>>>>>>> transport routing decisions to remain entirely within the=20
>>>>>>>>> transport network (in order to fully leave the routing policy=20
>>>>>>>>> in the hands of
>>>> people
>>>>>>>>> doing the layer dimensioning). Thus, I feel this trade-off in
>>>> path
>>>>>>>>> selection tuning is rather unlikely to happen and I fear we=20
>>>>>>>>> may
>>>> be
>>>>>>>>> talking about RSVP-TE over-engineering here.
>>>>>>>> The idea is simply to allow the client to express its
>>>> needs/wishes.
>>>>>>>> The UNI-N remains in control.  By policy it can use the=20
>>>>>>>> objective function or not.  Further if it does use the=20
>>>>>>>> objective function
>>>> and
>>>>>>>> fails to find a path it can either say that there was no path=20
>>>>>>>> or
>>>> it
>>>>>>>> proceed to setup what it can.
>>>>>>>>
>>>>>>>>> (That is also why I preferred to consider your I-Ds separately=20
>>>>>>>>> during the CCAMP meeting.)
>>>>>>>> Agreed.  I will ask for separate slots.  The discussion at the=20
>>>>>>>> end was rather disjointed.
>>>>>>>>
>>>>>>>>> However, my comments are mostly related to the=20
>>>>>>>>> client/transport relationship. If the I-D is extended to cover=20
>>>>>>>>> more use cases with wider scopes (Adrian has made interesting=20
>>>>>>>>> suggestions), turning the overlay interconnection into one=20
>>>>>>>>> among a longer list, then my conclusion may be different.
>>>>>>>> I'm happy to widen the scope in this way.
>>>>>>>>
>>>>>>>> ...George
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Julien
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 11/09/2012 21:28, George Swallow (swallow) a =E9crit :
>>>>>>>>>> Julien -
>>>>>>>>>>
>>>>>>>>>> Reading the CCAMP notes (which capture little of the actual
>>>>>>>>>> discussion) I see that there may have been a perception in=20
>>>>>>>>>> the room that PCE functionality at the UNI-N was assumed=20
>>>>>>>>>> (actual or
>>>> proxy).
>>>>>>>>>> This is not the case. The reason for our draft is that with=20
>>>>>>>>>> the UNI, much of the functionality that resides at the=20
>>>>>>>>>> headend is moved to the UNI-N. So the UNI-C needs a way to=20
>>>>>>>>>> express an objective function even if there is no PCE.
>>>>>>>>>>
>>>>>>>>>> Operationally it seems burdensome to require a PCEP at the=20
>>>>>>>>>> UNI-C and a PCEP at the UNI-N, when all that is being done is=20
>>>>>>>>>> enabling the UNI-N to perform what the client would do if it=20
>>>>>>>>>> were connected to the network via a normal link.
>>>>>>>>>>
>>>>>>>>>> Do you still object to the draft?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> =A9George
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> CCAMP@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> CCAMP mailing list
>>>>>>> CCAMP@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
>=20
>=20
>=20
>=20

From internet-drafts@ietf.org  Fri Sep 21 06:44: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 B52EF21F8562; Fri, 21 Sep 2012 06:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.489
X-Spam-Level: 
X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urgBpFOkm7Nn; Fri, 21 Sep 2012 06:44:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EED721F8826; Fri, 21 Sep 2012 06:44:21 -0700 (PDT)
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: 4.34
Message-ID: <20120921134421.12520.2923.idtracker@ietfa.amsl.com>
Date: Fri, 21 Sep 2012 06:44:21 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 13:44:21 -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 Work=
ing Group of the IETF.

	Title           : RSVP Association Object Extensions
	Author(s)       : Lou Berger
                          Francois Le Faucheur
                          Ashok Narayanan
	Filename        : draft-ietf-ccamp-assoc-ext-06.txt
	Pages           : 17
	Date            : 2012-09-21

Abstract:
   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 the Transport Profile of Multiprotocol Label
   Switching (MPLS-TP).  This document updates RFC 2205, RFC 3209,
   and RFC 3473. It also generalizes the definition of the Association
   ID field defined in RFC 4872.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-assoc-ext-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From lberger@labn.net  Fri Sep 21 09:00: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 E011C21E803D for ; Fri, 21 Sep 2012 09:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.979
X-Spam-Level: 
X-Spam-Status: No, score=-99.979 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBFCJ2MTYlus for ; Fri, 21 Sep 2012 09:00:58 -0700 (PDT)
Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id DA0C121E8083 for ; Fri, 21 Sep 2012 09:00:57 -0700 (PDT)
Received: (qmail 6365 invoked by uid 0); 21 Sep 2012 16:00:53 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 21 Sep 2012 16:00: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:To:MIME-Version:From:Date:Message-ID; bh=cUJ0QReccycej2J6ofSF9Z7S1FQBXM8zxwKalSp04kU=;  b=zxtwjRZ0Rdd8lQ2Yn/QpUUk6HJk1a8fFNGbAk7O6IkA6v2/eHHMLoAE6M1M2r9CFRU36YmVupiOvCsFEkCM0fJnLnqm0tU7N3o5stAvLwx8+RovDZVvWm9HhrhY+35Ol;
Received: from box313.bluehost.com ([69.89.31.113]:57849 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TF5eu-0000oE-Kp for ccamp@ietf.org; Fri, 21 Sep 2012 10:00:52 -0600
Message-ID: <505C8F36.1040206@labn.net>
Date: Fri, 21 Sep 2012 12:00:54 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: ccamp@ietf.org
References: <20120921134421.12520.2923.idtracker@ietfa.amsl.com>
In-Reply-To: <20120921134421.12520.2923.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.4
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: Re: [CCAMP] I-D Action: draft-ietf-ccamp-assoc-ext-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Sep 2012 16:00:59 -0000

All,

This version captures text clarifications related to compatibility
requested during IESG review.

Lou

On 9/21/2012 9:44 AM, 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-06.txt
> 	Pages           : 17
> 	Date            : 2012-09-21
> 
> Abstract:
>    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 the Transport Profile of Multiprotocol Label
>    Switching (MPLS-TP).  This document updates RFC 2205, RFC 3209,
>    and RFC 3473. It also generalizes the definition of the Association
>    ID field defined in RFC 4872.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-06
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-assoc-ext-06
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 

From gregb@grotto-networking.com  Mon Sep 24 08:08: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 BA6C021F87CD for ; Mon, 24 Sep 2012 08:08:56 -0700 (PDT)
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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKoAcJ1bQj5S for ; Mon, 24 Sep 2012 08:08:56 -0700 (PDT)
Received: from smtp.webfaction.com (mail6.webfaction.com [74.55.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B58A921F87C4 for ; Mon, 24 Sep 2012 08:08:51 -0700 (PDT)
Received: from [192.168.0.124] (c-67-170-243-110.hsd1.ca.comcast.net [67.170.243.110]) by smtp.webfaction.com (Postfix) with ESMTP id 603EC21523C5 for ; Mon, 24 Sep 2012 10:08:50 -0500 (CDT)
Message-ID: <50607780.7020707@grotto-networking.com>
Date: Mon, 24 Sep 2012 08:08:48 -0700
From: Greg Bernstein 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "" 
Content-Type: multipart/alternative; boundary="------------000702020706000806000607"
Subject: [CCAMP] Request for last call on non-impairment WSON documents
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, 24 Sep 2012 15:08:56 -0000

This is a multi-part message in MIME format.
--------------000702020706000806000607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi CCAMPers, we'd like to request last call on the following 
non-impairment WSON documents:
(a) Routing and Wavelength Assignment Information Model for Wavelength 
Switched Optical Networks 
 (informational)
(b) General Network Element Constraint Encoding for GMPLS Controlled 
Networks
(c) 
Routing and Wavelength Assignment Information Encoding for Wavelength 
Switched Optical Networks 

(d) OSPF-TE Extensions for General Network Element Constraints 

(e) GMPLS OSPF Enhancement for Signal and Network Element Compatibility 
for Wavelength Switched Optical Networks

All requested modifications from the Vancouver IETF and list have been 
implemented and reviewed by the working group. Except for a few small 
changes these documents have been stable for many years now :-) .

Best Regards
Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237


--------------000702020706000806000607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi CCAMPers, we'd like to request last call on the following
    non-impairment WSON documents:

    (a) Routing
      and Wavelength Assignment Information Model for Wavelength
      Switched Optical Networks (informational)

    (b) General
      Network Element Constraint Encoding for GMPLS Controlled Networks

    (c) Routing
      and Wavelength Assignment Information Encoding for Wavelength
      Switched Optical Networks

    (d) OSPF-TE
      Extensions for General Network Element Constraints

    (e) GMPLS
      OSPF Enhancement for Signal and Network Element Compatibility for
      Wavelength Switched Optical Networks

    

    All requested modifications from the Vancouver IETF and list have
    been implemented and reviewed by the working group. Except for a few
    small changes these documents have been stable for many years now  :-) . 

    

    Best Regards

    Greg B.

    
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237



  


--------------000702020706000806000607--

From iesg-secretary@ietf.org  Tue Sep 25 09:15: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 2C8DD21F8847; Tue, 25 Sep 2012 09:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.533
X-Spam-Level: 
X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pp0arShplQ0; Tue, 25 Sep 2012 09:15:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776CD21F8853; Tue, 25 Sep 2012 09:15:17 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <20120925161517.22252.467.idtracker@ietfa.amsl.com>
Date: Tue, 25 Sep 2012 09:15:17 -0700
Cc: ccamp mailing list , ccamp chair , RFC Editor 
Subject: [CCAMP] Protocol Action: 'RSVP Association Object Extensions' to Proposed	Standard (draft-ietf-ccamp-assoc-ext-06.txt)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Sep 2012 16:15:18 -0000

The IESG has approved the following document:
- 'RSVP Association Object Extensions'
  (draft-ietf-ccamp-assoc-ext-06.txt) as Proposed Standard

This document is the product of the Common Control and Measurement Plane
Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ccamp-assoc-ext/




Technical Summary 

   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 the Transport Profile of Multiprotocol Label
   Switching (MPLS-TP).  This document updates RFC 2205, RFC 3209,
   and RFC 3473. It also generalizes the definition of the Association
   ID field defined in RFC 4872.

Working Group Summary 

   Good support by the WG. Nothing to note.

   Working group last call raised a few small issues that were fixed in a
   revision.

   The TSV Working group was involved in the discussion to take up this
   work and to place it in the CCAMP working group. A high percentage of
   the RSVP directorate have been involved in the work as authors or
   reviewers.

Document Quality 

  There have been no public statements related to implementations, though 
  significant interest was expressed by the working group. 

  IETF last call and Routing Directorate led to some small discussions and
  updates.

Personnel 

  Deborah Brungard is the Document Shepherd. 
  Adrian Farrel is the Area Director. 

From internet-drafts@ietf.org  Thu Sep 27 09:42: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 B954121F861B; Thu, 27 Sep 2012 09:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level: 
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsMabxZuH0mv; Thu, 27 Sep 2012 09:42:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5209821F857A; Thu, 27 Sep 2012 09:42:13 -0700 (PDT)
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: 4.34
Message-ID: <20120927164213.29229.35217.idtracker@ietfa.amsl.com>
Date: Thu, 27 Sep 2012 09:42:13 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-09.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, 27 Sep 2012 16:42:13 -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 Work=
ing Group of the IETF.

	Title           : General Network Element Constraint Encoding for GMPLS Co=
ntrolled Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-general-constraint-encode-09.txt
	Pages           : 31
	Date            : 2012-09-27

Abstract:
   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies. In some of these technologies network
   elements and links may impose additional routing constraints such as
   asymmetric switch connectivity, non-local label assignment, and
   label range limitations on links.

   This document provides efficient, protocol-agnostic encodings for
   general information elements representing connectivity and label
   constraints as well as label availability. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco=
de-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From leeyoung@huawei.com  Thu Sep 27 10:00: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 2749421F863B for ; Thu, 27 Sep 2012 10:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiXWr8y8R8pr for ; Thu, 27 Sep 2012 10:00:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1131421F8634 for ; Thu, 27 Sep 2012 10:00:11 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALC54134; Thu, 27 Sep 2012 17:00:10 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 17:57:54 +0100
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 17:58:48 +0100
Received: from dfweml511-mbx.china.huawei.com ([169.254.16.239]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 27 Sep 2012 09:58:44 -0700
From: Leeyoung 
To: CCAMP 
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-09.txt
Thread-Index: AQHNnM8SiEAZyVUKY0eCj/AtnBZpdpeeZKiQ
Date: Thu, 27 Sep 2012 16:58:42 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729079F4F@dfweml511-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [CCAMP] FW: I-D Action:	draft-ietf-ccamp-general-constraint-encode-09.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, 27 Sep 2012 17:00:13 -0000

Hi

This update reflects all the agreements made since the last IETF meeting.=20
Among the changes made in this version are:

- Switching Capability and Encoding applied to all sub-cases for Port
   Label Restriction sub-TLV in Section 2.6. (per Rajan's input)

- Eliminated A (Availability) Bit from Available Labels Sub-TLV and
   Shared Backup Labels Sub-TLV. (Per Rajan's input)

- Added Appendix for illustration of how to use Priority Flags (per Giovann=
i's input)
- Priority bit remains 8 bits to be consistent with TDM, PSC encoding (e.g.=
, RFC 4090, etc.)

As Greg indicated, this draft is ready to WG LC.=20

Thanks.
Young

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Thursday, September 27, 2012 11:42 AM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-09.=
txt


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 Work=
ing Group of the IETF.

	Title           : General Network Element Constraint Encoding for GMPLS Co=
ntrolled Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-general-constraint-encode-09.txt
	Pages           : 31
	Date            : 2012-09-27

Abstract:
   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies. In some of these technologies network
   elements and links may impose additional routing constraints such as
   asymmetric switch connectivity, non-local label assignment, and
   label range limitations on links.

   This document provides efficient, protocol-agnostic encodings for
   general information elements representing connectivity and label
   constraints as well as label availability. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco=
de-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From lberger@labn.net  Fri Sep 28 07:20: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 7CA4121F8610 for ; Fri, 28 Sep 2012 07:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.985
X-Spam-Level: 
X-Spam-Status: No, score=-99.985 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxMdW3UTdWu7 for ; Fri, 28 Sep 2012 07:20:35 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id EB98C21F8609 for ; Fri, 28 Sep 2012 07:20:34 -0700 (PDT)
Received: (qmail 2577 invoked by uid 0); 28 Sep 2012 14:20:32 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 28 Sep 2012 14:20: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:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=qfZ5s5Vgnp+RssOfa6cTHaDgJc/8GdXtZs14zW1xq50=;  b=DZaDfSNDQEokF+6Y2vZzhv6WgCbABVvofG7JytdfoJOgPNyLJNY369oWCmGA0tss35cgYbR1edgYCjBCD+cPmoYGNShgS232XwcbBVjy+xQ3nkfX44aHeGlm0uo5KZ49;
Received: from box313.bluehost.com ([69.89.31.113]:47454 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1THbQe-0004es-3f; Fri, 28 Sep 2012 08:20:32 -0600
Message-ID: <5065B22D.5050808@labn.net>
Date: Fri, 28 Sep 2012 10:20:29 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: sergio.belotti@alcatel-lucent.com,  pietro_vittorio.grandi@alcatel-lucent.com,  daniele.ceccarelli@ericsson.com, diego.caviglia@ericsson.com,  zhangfatai@huawei.com, danli@huawei.com
X-Enigmail-Version: 1.4.4
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: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
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, 28 Sep 2012 14:20:35 -0000

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to
draft-ietf-ccamp-otn-g709-info-model?

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 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

PS Please include all listed in the headers of this message in your
response.


From lberger@labn.net  Fri Sep 28 07: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 1243D21F8610 for ; Fri, 28 Sep 2012 07:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.992
X-Spam-Level: 
X-Spam-Status: No, score=-99.992 tagged_above=-999 required=5 tests=[AWL=0.169, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U8nKRfjGOUM for ; Fri, 28 Sep 2012 07:20:36 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 54B4E21F8609 for ; Fri, 28 Sep 2012 07:20:36 -0700 (PDT)
Received: (qmail 20122 invoked by uid 0); 28 Sep 2012 14:20:27 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 28 Sep 2012 14:20:27 -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=QcSHbJnp3PU5nZbQ+b4yIb7cMfk490CQuzsosblvgfI=;  b=qAFvNVgD7Zn2K59zp95w9MrQ11Cxqa2Xm7BowaCRk7askkXyJd0VqQcoaVXkcmI7r8vKWbSmaiTBmuIzuUQyFBp6WgUWiH2OcYSigehI6MV9ufCSmYJy0dcgoUh1zoL7;
Received: from box313.bluehost.com ([69.89.31.113]:47443 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1THbQZ-0004bq-JS; Fri, 28 Sep 2012 08:20:27 -0600
Message-ID: <5065B228.1070701@labn.net>
Date: Fri, 28 Sep 2012 10:20:24 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: zhangfatai@huawei.com, huawei.danli@huawei.com,  lihan@chinamobile.com, sergio.belotti@alcatel-lucent.it,  daniele.ceccarelli@ericsson.com, hanjianrui@huawei.com,  malcolm.betts@huawei.com
X-Enigmail-Version: 1.4.4
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: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 14:20:40 -0000

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to
draft-ietf-ccamp-gmpls-g709-framework?

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 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

PS Please include all listed in the headers of this message in your
response.

From lberger@labn.net  Fri Sep 28 07:20:41 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 3267421F8610 for ; Fri, 28 Sep 2012 07:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.997
X-Spam-Level: 
X-Spam-Status: No, score=-99.997 tagged_above=-999 required=5 tests=[AWL=0.164, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHBx3udRV9Zt for ; Fri, 28 Sep 2012 07:20:40 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 7064621F8609 for ; Fri, 28 Sep 2012 07:20:40 -0700 (PDT)
Received: (qmail 20902 invoked by uid 0); 28 Sep 2012 14:20:38 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 28 Sep 2012 14:20:37 -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=trRdyWFqoc9sU5g5deETXR3z2abx5HqRjm32AvXfPDw=;  b=foZFgIBLPo4lMbIptXIfr1Dzt7kJ5IEm3b4Km61OXaz6J/cHShEuZ8HgkovJuvCpYm+tKQxPQSRP5WMHJRcpDgrKES2/hBQfm+wxElMEyhMDns3e/KvFNGDZ3Zulq5nc;
Received: from box313.bluehost.com ([69.89.31.113]:47461 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1THbQi-0004gf-TD; Fri, 28 Sep 2012 08:20:37 -0600
Message-ID: <5065B232.1020908@labn.net>
Date: Fri, 28 Sep 2012 10:20:34 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: daniele.ceccarelli@ericsson.com, diego.caviglia@ericsson.com,  zhangfatai@huawei.com, danli@huawei.com,  sergio.belotti@alcatel-lucent.com,  pietro_vittorio.grandi@alcatel-lucent.com, rrao@infinera.com,  kpithewan@infinera.com, jdrake@juniper.net
X-Enigmail-Version: 1.4.4
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: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
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, 28 Sep 2012 14:20:41 -0000

-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-ccamp-gmpls-ospf-g709v3
-------------------------------------------------------------------------

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to
draft-ietf-ccamp-gmpls-ospf-g709v3?

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 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

PS Please include all listed in the headers of this message in your
response.


From lberger@labn.net  Fri Sep 28 07:20: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 278E021F865B for ; Fri, 28 Sep 2012 07:20:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.002
X-Spam-Level: 
X-Spam-Status: No, score=-100.002 tagged_above=-999 required=5 tests=[AWL=0.159, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eMvjceCyB17 for ; Fri, 28 Sep 2012 07:20:43 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 9155D21F864D for ; Fri, 28 Sep 2012 07:20:43 -0700 (PDT)
Received: (qmail 21282 invoked by uid 0); 28 Sep 2012 14:20:42 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 28 Sep 2012 14:20: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:CC:To:MIME-Version:From:Date:Message-ID; bh=ZAtsdazDuOX0q3I+jeiynOPJFfJ6fL4O+8dyF7xToBg=;  b=yuk48Fc0g1RJMfkXnlJfvWlRRGrM/m9PFh+/QH8HAS5qS2CyGyb/W0iD1Y8vfIn1SXu+i9anH4mxp+KU9+NcmtSBAEGVy1qUK7u15e6RIAMpFd+v2RwCEVdNw5VqRsrc;
Received: from box313.bluehost.com ([69.89.31.113]:47468 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1THbQo-0004ib-2V; Fri, 28 Sep 2012 08:20:42 -0600
Message-ID: <5065B236.9080009@labn.net>
Date: Fri, 28 Sep 2012 10:20:38 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: zhangfatai@huawei.com, zhangguoying@mail.ritt.com.cn,  sergio.belotti@alcatel-lucent.it, daniele.ceccarelli@ericsson.com,  kpithewan@infinera.com, yi.lin@huawei.com, xuyunbin@mail.ritt.com.cn,  pietro_vittorio.grandi@alcatel-lucent.it, diego.caviglia@ericsson.com,  rrao@infinera.com, jdrake@juniper.net, IBryskin@advaoptical.com
X-Enigmail-Version: 1.4.4
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: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
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, 28 Sep 2012 14:20:44 -0000

-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-ccamp-gmpls-signaling-g709v3
-------------------------------------------------------------------------

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to
draft-ietf-ccamp-gmpls-signaling-g709v3?

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 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

PS Please include all listed in the headers of this message in your
response.

From jdrake@juniper.net  Fri Sep 28 07:56: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 1060421F8645 for ; Fri, 28 Sep 2012 07:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.909
X-Spam-Level: 
X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[AWL=-1.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JENPw+vrSZy7 for ; Fri, 28 Sep 2012 07:56:20 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 484B721F863C for ; Fri, 28 Sep 2012 07:56:20 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUGW6k0I++qj4lB1V+r2AFODfzJZbOzq9@postini.com; Fri, 28 Sep 2012 07:56:20 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Sep 2012 07:55:47 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Sep 2012 07:55:47 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Sep 2012 08:01:20 -0700
Received: from mail67-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 14:55:45 +0000
Received: from mail67-va3 (localhost [127.0.0.1])	by mail67-va3-R.bigfish.com (Postfix) with ESMTP id 771E54200C5	for ; Fri, 28 Sep 2012 14:55:45 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -23
X-BigFish: PS-23(zz9371I542M1432Id6f1izz1202h1d1ah1d2ahz70kz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail67-va3 (localhost.localdomain [127.0.0.1]) by mail67-va3 (MessageSwitch) id 1348844143896072_4025; Fri, 28 Sep 2012 14:55:43 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.248])	by mail67-va3.bigfish.com (Postfix) with ESMTP id CAA4A20078; Fri, 28 Sep 2012 14:55:43 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 14:55:41 +0000
Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.12.53]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0190.008; Fri, 28 Sep 2012 14:55:41 +0000
From: John E Drake 
To: Lou Berger , "zhangfatai@huawei.com" , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" , "daniele.ceccarelli@ericsson.com" , "kpithewan@infinera.com" , "yi.lin@huawei.com" , "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , "diego.caviglia@ericsson.com" , "rrao@infinera.com" , John E Drake , "IBryskin@advaoptical.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: AQHNnYR8Nd2mXhKfEUeQIsEFy5FuX5ef15XA
Date: Fri, 28 Sep 2012 14:55:40 +0000
Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E02DE20@BL2PRD0510MB349.namprd05.prod.outlook.com>
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%MAIL.RITT.COM.CN$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.IT$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ADVAOPTICAL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
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, 28 Sep 2012 14:56:21 -0000

No IPR

Yours irrespectively,

John


> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, September 28, 2012 7:21 AM
> To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn;
> sergio.belotti@alcatel-lucent.it; daniele.ceccarelli@ericsson.com;
> kpithewan@infinera.com; yi.lin@huawei.com; xuyunbin@mail.ritt.com.cn;
> pietro_vittorio.grandi@alcatel-lucent.it; diego.caviglia@ericsson.com;
> rrao@infinera.com; John E Drake; IBryskin@advaoptical.com
> Cc: CCAMP
> Subject: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
>=20
> -----------------------------------------------------------------------
> --
> CCAMP: Please note there are IPR disclosures:
> https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&documen
> t_search=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3
> -----------------------------------------------------------------------
> --
>=20
> Authors, Contributors, (CCAMP)
>=20
> As part of the preparation for WG Last Call:
>=20
> Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-
> signaling-g709v3?
>=20
> 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.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>=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
> Thank you,
> CCAMP WG Chairs
>=20
> PS Please include all listed in the headers of this message in your
> response.



From jdrake@juniper.net  Fri Sep 28 07:56: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 0C81121F853B for ; Fri, 28 Sep 2012 07:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.88
X-Spam-Level: 
X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[AWL=-1.413,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y-4beacUKHk for ; Fri, 28 Sep 2012 07:56:46 -0700 (PDT)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7C21F85EA for ; Fri, 28 Sep 2012 07:56:46 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUGW6rUpGBZbwqz1K7WRQ0xoN4hTB8IIl@postini.com; Fri, 28 Sep 2012 07:56:46 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Sep 2012 07:55:45 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Sep 2012 07:55:45 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Sep 2012 07:57:45 -0700
Received: from mail24-va3-R.bigfish.com (10.7.14.240) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 14:55:36 +0000
Received: from mail24-va3 (localhost [127.0.0.1])	by mail24-va3-R.bigfish.com (Postfix) with ESMTP id 90B0B10015A	for ; Fri, 28 Sep 2012 14:55:36 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -26
X-BigFish: PS-26(zz9371I542M1432Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail24-va3 (localhost.localdomain [127.0.0.1]) by mail24-va3 (MessageSwitch) id 1348844133607433_4210; Fri, 28 Sep 2012 14:55:33 +0000 (UTC)
Received: from VA3EHSMHS039.bigfish.com (unknown [10.7.14.252])	by mail24-va3.bigfish.com (Postfix) with ESMTP id 8EE3A600A1; Fri, 28 Sep 2012 14:55:33 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS039.bigfish.com (10.7.99.49) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 14:55:30 +0000
Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.12.53]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0190.008; Fri, 28 Sep 2012 14:55:30 +0000
From: John E Drake 
To: Lou Berger , "zhangfatai@huawei.com" , "huawei.danli@huawei.com" ,  "lihan@chinamobile.com" , "sergio.belotti@alcatel-lucent.it" ,  "daniele.ceccarelli@ericsson.com" , "hanjianrui@huawei.com" , "malcolm.betts@huawei.com" 
Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
Thread-Index: AQHNnYR66mSx9bcEIEKnCQsFfzZvh5ef14iA
Date: Fri, 28 Sep 2012 14:55:29 +0000
Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E02DE12@BL2PRD0510MB349.namprd05.prod.outlook.com>
References: <5065B228.1070701@labn.net>
In-Reply-To: <5065B228.1070701@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%CHINAMOBILE.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.IT$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 14:56:47 -0000

No IPR

Yours irrespectively,

John


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Friday, September 28, 2012 7:20 AM
> To: zhangfatai@huawei.com; huawei.danli@huawei.com;
> lihan@chinamobile.com; sergio.belotti@alcatel-lucent.it;
> daniele.ceccarelli@ericsson.com; hanjianrui@huawei.com;
> malcolm.betts@huawei.com
> Cc: CCAMP
> Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
>=20
> Authors, Contributors, (CCAMP)
>=20
> As part of the preparation for WG Last Call:
>=20
> Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-g709-
> framework?
>=20
> 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.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>=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
> Thank you,
> CCAMP WG Chairs
>=20
> PS Please include all listed in the headers of this message in your
> response.
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp



From jdrake@juniper.net  Fri Sep 28 07:58: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 51CCF21F8628 for ; Fri, 28 Sep 2012 07:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.853
X-Spam-Level: 
X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-Jp+oej-ALX for ; Fri, 28 Sep 2012 07:58:00 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 66E4421F85EA for ; Fri, 28 Sep 2012 07:58:00 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUGW6+OYj8tcijHtNrxwS1jCcd50qxmd1@postini.com; Fri, 28 Sep 2012 07:58:00 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Sep 2012 07:55:25 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Sep 2012 07:55:24 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.11) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Sep 2012 08:00:50 -0700
Received: from mail28-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 14:55:16 +0000
Received: from mail28-va3 (localhost [127.0.0.1])	by mail28-va3-R.bigfish.com (Postfix) with ESMTP id 53F813C020D	for ; Fri, 28 Sep 2012 14:55:16 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -26
X-BigFish: PS-26(zz9371I542M1432Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail28-va3 (localhost.localdomain [127.0.0.1]) by mail28-va3 (MessageSwitch) id 1348844113756314_18686; Fri, 28 Sep 2012 14:55:13 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.246])	by mail28-va3.bigfish.com (Postfix) with ESMTP id B3E6240067; Fri, 28 Sep 2012 14:55:13 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 14:55:07 +0000
Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.12.53]) by BL2PRD0510HT005.namprd05.prod.outlook.com ([10.255.100.40]) with mapi id 14.16.0190.008; Fri, 28 Sep 2012 14:55:08 +0000
From: John E Drake 
To: Lou Berger , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , "zhangfatai@huawei.com" , "danli@huawei.com" , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "rrao@infinera.com" , "kpithewan@infinera.com" , John E Drake 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYR1Dw6l9RwMGkuclYf6foDHyZef12cQ
Date: Fri, 28 Sep 2012 14:55:07 +0000
Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E02DDF9@BL2PRD0510MB349.namprd05.prod.outlook.com>
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%INFINERA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
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, 28 Sep 2012 14:58:01 -0000

No IPR

Yours irrespectively,

John


> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, September 28, 2012 7:21 AM
> To: daniele.ceccarelli@ericsson.com; diego.caviglia@ericsson.com;
> zhangfatai@huawei.com; danli@huawei.com; sergio.belotti@alcatel-
> lucent.com; pietro_vittorio.grandi@alcatel-lucent.com;
> rrao@infinera.com; kpithewan@infinera.com; John E Drake
> Cc: CCAMP
> Subject: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
>=20
> -----------------------------------------------------------------------
> --
> CCAMP: Please note there are IPR disclosures:
> https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&documen
> t_search=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3
> -----------------------------------------------------------------------
> --
>=20
> Authors, Contributors, (CCAMP)
>=20
> As part of the preparation for WG Last Call:
>=20
> Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-ospf-
> g709v3?
>=20
> 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.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>=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
> Thank you,
> CCAMP WG Chairs
>=20
> PS Please include all listed in the headers of this message in your
> response.
>=20



From jdrake@juniper.net  Fri Sep 28 07:58: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 7FF3821F8499 for ; Fri, 28 Sep 2012 07:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.826
X-Spam-Level: 
X-Spam-Status: No, score=-4.826 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsJ4jIBFfUZY for ; Fri, 28 Sep 2012 07:58:18 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9276921F847C for ; Fri, 28 Sep 2012 07:58:18 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUGW7Cics+d9NKNrtlvOx76pwwy903aD4@postini.com; Fri, 28 Sep 2012 07:58:18 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 28 Sep 2012 07:55:41 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 28 Sep 2012 07:55:40 -0700
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 28 Sep 2012 07:57:35 -0700
Received: from mail202-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Sep 2012 14:55:26 +0000
Received: from mail202-co1 (localhost [127.0.0.1])	by mail202-co1-R.bigfish.com (Postfix) with ESMTP id 0175BD801CC	for ; Fri, 28 Sep 2012 14:55:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -26
X-BigFish: PS-26(zz9371I542M1432Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1155h)
Received: from mail202-co1 (localhost.localdomain [127.0.0.1]) by mail202-co1 (MessageSwitch) id 1348844124497935_29787; Fri, 28 Sep 2012 14:55:24 +0000 (UTC)
Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.245])	by mail202-co1.bigfish.com (Postfix) with ESMTP id 74E9E40251; Fri, 28 Sep 2012 14:55:24 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 28 Sep 2012 14:55:23 +0000
Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.12.53]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0190.008; Fri, 28 Sep 2012 14:55:18 +0000
From: John E Drake 
To: Lou Berger , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , "zhangfatai@huawei.com" , "danli@huawei.com" 
Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
Thread-Index: AQHNnYR3Oyw1owXvbkWMpOnQrtemW5ef13pQ
Date: Fri, 28 Sep 2012 14:55:18 +0000
Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E02DE04@BL2PRD0510MB349.namprd05.prod.outlook.com>
References: <5065B22D.5050808@labn.net>
In-Reply-To: <5065B22D.5050808@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.224.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%LABN.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
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, 28 Sep 2012 14:58:19 -0000

No IPR

Yours irrespectively,

John


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Friday, September 28, 2012 7:20 AM
> To: sergio.belotti@alcatel-lucent.com; pietro_vittorio.grandi@alcatel-
> lucent.com; daniele.ceccarelli@ericsson.com;
> diego.caviglia@ericsson.com; zhangfatai@huawei.com; danli@huawei.com
> Cc: CCAMP
> Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
>=20
> Authors, Contributors, (CCAMP)
>=20
> As part of the preparation for WG Last Call:
>=20
> Are you aware of any IPR that applies to draft-ietf-ccamp-otn-g709-
> info-model?
>=20
> 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.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>=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
> Thank you,
> CCAMP WG Chairs
>=20
> PS Please include all listed in the headers of this message in your
> response.
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp



From daniele.ceccarelli@ericsson.com  Fri Sep 28 08:06:36 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 0DC8421F863F for ; Fri, 28 Sep 2012 08:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3jMLdlW5wQn for ; Fri, 28 Sep 2012 08:06:35 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E1AF521F8528 for ; Fri, 28 Sep 2012 08:06:34 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-64-5065bcf95c1d
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 77.74.11467.9FCB5605; Fri, 28 Sep 2012 17:06:34 +0200 (CEST)
Received: from ESESSHC015.ericsson.se (153.88.183.63) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.264.1; Fri, 28 Sep 2012 17:06:33 +0200
Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 17:06:33 +0200
From: Daniele Ceccarelli 
To: Lou Berger , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , Diego Caviglia , "zhangfatai@huawei.com" , "danli@huawei.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
Thread-Index: AQHNnYRs14XxL8yCrUmA/QY1WrwBvZef2mqA
Date: Fri, 28 Sep 2012 15:06:32 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48CCE5@ESESSMB301.ericsson.se>
References: <5065B22D.5050808@labn.net>
In-Reply-To: <5065B22D.5050808@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvre6vPakBBj87WCyezLnBYvHq+QRG i47mtywWM/7cZbNYtvk3u0Vf83lWBzaP1md7WT1ajrxl9Viy5CeTx4dNzWwBLFFcNimpOZll qUX6dglcGe2vHrEXnOWt2PP/LVsD4xLuLkZODgkBE4mpPxazQdhiEhfurQeyuTiEBE4xSkx/ dRnK2cko8fbhHxYIZwmjxIOvi9i7GDk42ASsJJ4c8gGJiwhcZpI48/08K8goZgEpibu3uhhB bGEBJ4nlF06DxUUEnCXe/pnABmEbSUycepUdxGYRUJW4cmsJC4jNK+Ap0fOmF6xXSEBdYtbt JcwgNqeAhsTth4eYQGxGAVmJCbsXMULsEpe49WQ+E8QLAhJL9pxnhrBFJV4+/scKYStKfHy1 D6peT+LG1ClsELa2xLKFr5kh9gpKnJz5hAVir47EsT8NzBMYJWYhWTELSfssJO2zkLQvYGRZ xSicm5iZk15uqJdalJlcXJyfp1ecuokRGKsHt/zW3cF46pzIIUZpDhYlcV6upP3+QgLpiSWp 2ampBalF8UWlOanFhxiZODilGhiLXDot3lgY1AfwH2uz26jKz/LxdPbU7dq8D3ecF+UNve1h 73b4xc8sqaJ7iwLz1jadUWDbauuz/92x1Ocp7r7/JDsaDkSF7T1iv69y4hUOAT51q30ea0+m 6hUdd67eG307XvzhlafRc3lTJFQP6/y7dPEX65vdslveGW8omPo84KaN14RynzIlluKMREMt 5qLiRADjQ5fXowIAAA==
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
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, 28 Sep 2012 15:06:36 -0000

No IPR=20

BR
Daniele

>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net]=20
>Sent: venerd=EC 28 settembre 2012 16.20
>To: sergio.belotti@alcatel-lucent.com;=20
>pietro_vittorio.grandi@alcatel-lucent.com; Daniele Ceccarelli;=20
>Diego Caviglia; zhangfatai@huawei.com; danli@huawei.com
>Cc: CCAMP
>Subject: Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
>
>Authors, Contributors, (CCAMP)
>
>As part of the preparation for WG Last Call:
>
>Are you aware of any IPR that applies to=20
>draft-ietf-ccamp-otn-g709-info-model?
>
>If so, has this IPR been disclosed in compliance with IETF IPR=20
>rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
>
>If you are listed as a document author or contributor please=20
>answer the above by responding to this email regardless of=20
>whether or not you are aware of any relevant IPR.  This=20
>document will not advance to the next stage until a response=20
>has been received from each author and listed contributor. =20
>NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
>If you are on the CCAMP WG email list but are not listed as an=20
>author or contributor, we remind you of your obligations under=20
>the IETF IPR rules which encourages you to notify the IETF if=20
>you are aware of IPR of others on an IETF contribution, or to=20
>refrain from participating in any contribution or discussion=20
>related to your undisclosed IPR.  For more information, please=20
>see the RFCs listed above and=20
>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>Thank you,
>CCAMP WG Chairs
>
>PS Please include all listed in the headers of this message in=20
>your response.
>
>=

From daniele.ceccarelli@ericsson.com  Fri Sep 28 08:06: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 22A5121F8661 for ; Fri, 28 Sep 2012 08:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AkRO91606ta for ; Fri, 28 Sep 2012 08:06:46 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA5021F863F for ; Fri, 28 Sep 2012 08:06:45 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-9a-5065bd046f66
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F0.9A.25676.40DB5605; Fri, 28 Sep 2012 17:06:44 +0200 (CEST)
Received: from ESESSHC001.ericsson.se (153.88.183.21) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.264.1; Fri, 28 Sep 2012 17:06:42 +0200
Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 17:06:42 +0200
From: Daniele Ceccarelli 
To: Lou Berger , "zhangfatai@huawei.com" , "huawei.danli@huawei.com" ,  "lihan@chinamobile.com" , "sergio.belotti@alcatel-lucent.it" ,  "hanjianrui@huawei.com" , "malcolm.betts@huawei.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
Thread-Index: AQHNnYRu97Svm4ehzE2qieSY96n2I5ef2qmQ
Date: Fri, 28 Sep 2012 15:06:41 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48CCED@ESESSMB301.ericsson.se>
References: <5065B228.1070701@labn.net>
In-Reply-To: <5065B228.1070701@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM+JvrS7L3tQAg8tvdS2ezLnBYvFzfy+z xdEvB5ksOprfslhMe2xmsXd1N5NFy8sd7BZ9zedZHTg8zq5tYfOYd2Ehm0fLkbesHkuW/GTy +LCpmS2ANYrLJiU1J7MstUjfLoEr49fXHpaC+7wVrUeWsDYw7uDuYuTkkBAwkbjZc4wdwhaT uHBvPVsXIxeHkMApRoknq4+zQjg7GSUuv53HBOEsYZRYueA0UAsHB5uAlcSTQz4gcRGBj0wS J+7/YAYZxSwgJXH3VhcjiC0s4CyxvHcTG4gtIuAi8eXYbRYI20hiza7XYKtZBFQl2p/3gdm8 Ap4S2482M4HYQgLqEn2nj4DN4RTQkFj5+ROYzSggKzFh9yJGiF3iEreezGeCeEFAYsme88wQ tqjEy8f/WCFsRYmPr/ZB1etJ3Jg6hQ3C1pZYtvA1M8ReQYmTM5+wQOzVkTj2p4F5AqPELCQr ZiFpn4WkfRaS9gWMLKsYhXMTM3PSy430Uosyk4uL8/P0ilM3MQLj+OCW36o7GO+cEznEKM3B oiTOa711j7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxrKqi6cf1a3+5vX2+scLzjeWLJ67 w2q745204jtFNkfTvt9XWenlz8u7Y8vi3pk3+G8Z8x1I+iSWa9DwUn+CssansO8m0/ee1VmY Vbv2tnueeODSLZ6fznxX/3j+U5TlR1mXzWKy57fNOrfN4CTXi3ulmX+Nt89J0XwqO93i+fcN aQZVS0R3BQUpsRRnJBpqMRcVJwIAaS5aOrECAAA=
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Sep 2012 15:06:47 -0000

No IPR

BR
Daniele=20

>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net]=20
>Sent: venerd=EC 28 settembre 2012 16.20
>To: zhangfatai@huawei.com; huawei.danli@huawei.com;=20
>lihan@chinamobile.com; sergio.belotti@alcatel-lucent.it;=20
>Daniele Ceccarelli; hanjianrui@huawei.com; malcolm.betts@huawei.com
>Cc: CCAMP
>Subject: Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
>
>Authors, Contributors, (CCAMP)
>
>As part of the preparation for WG Last Call:
>
>Are you aware of any IPR that applies to=20
>draft-ietf-ccamp-gmpls-g709-framework?
>
>If so, has this IPR been disclosed in compliance with IETF IPR=20
>rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
>
>If you are listed as a document author or contributor please=20
>answer the above by responding to this email regardless of=20
>whether or not you are aware of any relevant IPR.  This=20
>document will not advance to the next stage until a response=20
>has been received from each author and listed contributor. =20
>NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
>If you are on the CCAMP WG email list but are not listed as an=20
>author or contributor, we remind you of your obligations under=20
>the IETF IPR rules which encourages you to notify the IETF if=20
>you are aware of IPR of others on an IETF contribution, or to=20
>refrain from participating in any contribution or discussion=20
>related to your undisclosed IPR.  For more information, please=20
>see the RFCs listed above and=20
>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>Thank you,
>CCAMP WG Chairs
>
>PS Please include all listed in the headers of this message in=20
>your response.
>=

From daniele.ceccarelli@ericsson.com  Fri Sep 28 08:06:58 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 142BD21F866B for ; Fri, 28 Sep 2012 08:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DilI6Q3wH9RI for ; Fri, 28 Sep 2012 08:06:56 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9D621F864D for ; Fri, 28 Sep 2012 08:06:54 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-af-5065bd0e26c3
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.9A.25676.E0DB5605; Fri, 28 Sep 2012 17:06:54 +0200 (CEST)
Received: from ESESSHC008.ericsson.se (153.88.183.42) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.264.1; Fri, 28 Sep 2012 17:06:53 +0200
Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 17:06:53 +0200
From: Daniele Ceccarelli 
To: Lou Berger , Diego Caviglia , "zhangfatai@huawei.com" , "danli@huawei.com" , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "rrao@infinera.com" , "kpithewan@infinera.com" ,  "jdrake@juniper.net" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYRxD2gChu9za06XrGU8VWnsnJef2rYQ
Date: Fri, 28 Sep 2012 15:06:52 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48CCF8@ESESSMB301.ericsson.se>
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM+JvrS7f3tQAg8MH+C2ezLnBYvHq+QRG izl3nS2+rea26Gh+y2Ix489dNovn194xWSzb/Jvdoq/5PKsDp0frs72sHi1H3rJ6LFnyk8nj 0otDbB7Xm66ye3zY1MwWwBbFZZOSmpNZllqkb5fAlbF58gzGglsCFVOvdLM0ME7n62Lk5JAQ MJFoWPeAHcIWk7hwbz1bFyMXh5DAKUaJ7tX3WSCcnYwSn++0sUM4Sxglduy4wNzFyMHBJmAl 8eSQD0hcROAes8Sppi+MIKOYBaQk7t7qArOFBRwkdm2+ygJiiwg4Sjztu80EYRtJLLzUwwYy h0VAVWLS0TSQMK+Ap8T7DW1gYSEBdYnTJ5xBTE4BDYmd1+RAKhgFZCUm7F4EtUhc4taT+UwQ 9wtILNlznhnCFpV4+fgfK4StKPHx1T6oej2JG1OnsEHY2hLLFr5mhtgqKHFy5hOwI4UEdCSO /WlgnsAoMQvJillI2mchaZ+FpH0BI8sqRuHcxMyc9HIjvdSizOTi4vw8veLUTYzAmD645bfq DsY750QOMUpzsCiJ81pv3eMvJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZEv6UBv85oP00QC UpL+f01Jaj54dPOk+qVT9rnGOkxl/lfI+/nZ2U1+RU+WPej9IFNaHBXK6bdAJPjYrMhpm2+e XJwVta1t31eW44fqhPv07GImtm26vGl++5Wg9bvaN6Yvd+iVNlZim5t643rmkaD/mWsqpr92 eCq1oMFDYNe2dLWIZzk6vVeVWIozEg21mIuKEwF4QkEqtwIAAA==
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
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, 28 Sep 2012 15:06:58 -0000

No IPR

BR
Daniele=20

>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net]=20
>Sent: venerd=EC 28 settembre 2012 16.21
>To: Daniele Ceccarelli; Diego Caviglia; zhangfatai@huawei.com;=20
>danli@huawei.com; sergio.belotti@alcatel-lucent.com;=20
>pietro_vittorio.grandi@alcatel-lucent.com; rrao@infinera.com;=20
>kpithewan@infinera.com; jdrake@juniper.net
>Cc: CCAMP
>Subject: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
>
>---------------------------------------------------------------
>----------
>CCAMP: Please note there are IPR disclosures:
>https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search
>&document_search=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3
>---------------------------------------------------------------
>----------
>
>Authors, Contributors, (CCAMP)
>
>As part of the preparation for WG Last Call:
>
>Are you aware of any IPR that applies to=20
>draft-ietf-ccamp-gmpls-ospf-g709v3?
>
>If so, has this IPR been disclosed in compliance with IETF IPR=20
>rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
>
>If you are listed as a document author or contributor please=20
>answer the above by responding to this email regardless of=20
>whether or not you are aware of any relevant IPR.  This=20
>document will not advance to the next stage until a response=20
>has been received from each author and listed contributor. =20
>NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
>If you are on the CCAMP WG email list but are not listed as an=20
>author or contributor, we remind you of your obligations under=20
>the IETF IPR rules which encourages you to notify the IETF if=20
>you are aware of IPR of others on an IETF contribution, or to=20
>refrain from participating in any contribution or discussion=20
>related to your undisclosed IPR.  For more information, please=20
>see the RFCs listed above and=20
>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>Thank you,
>CCAMP WG Chairs
>
>PS Please include all listed in the headers of this message in=20
>your response.
>
>=

From daniele.ceccarelli@ericsson.com  Fri Sep 28 08:07: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 9206021F8672 for ; Fri, 28 Sep 2012 08:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Fm9mqBhMxrh for ; Fri, 28 Sep 2012 08:07:02 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 74FFC21F864D for ; Fri, 28 Sep 2012 08:07:01 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-94-5065bd145216
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5E.74.11467.41DB5605; Fri, 28 Sep 2012 17:07:00 +0200 (CEST)
Received: from ESESSHC005.ericsson.se (153.88.183.33) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.264.1; Fri, 28 Sep 2012 17:06:59 +0200
Received: from ESESSMB301.ericsson.se ([169.254.1.169]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 17:06:59 +0200
From: Daniele Ceccarelli 
To: Lou Berger , "zhangfatai@huawei.com" , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" , "kpithewan@infinera.com" , "yi.lin@huawei.com" , "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , Diego Caviglia , "rrao@infinera.com" ,  "jdrake@juniper.net" , "IBryskin@advaoptical.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: AQHNnYR6mvw2ZIlUrEK6OvRem2deUZef2r9w
Date: Fri, 28 Sep 2012 15:06:58 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE48CD07@ESESSMB301.ericsson.se>
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@labn.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM+Jvra7I3tQAg/7dohZP5txgsTjV085o Meeus8W31dwWHc1vWSxOfJrFbvH82jsmi5aXO9gtvh6st/hx6T2zRV/zeVaL7S/WszvweJxd 8IfV4+zaFjaPliNvWT2WLPnJ5HHpxSE2j+tNV9k9PmxqZvPY838rWwBHFJdNSmpOZllqkb5d AlfGg+P3WQoOC1acPvCNtYHxL18XIyeHhICJxNVFWxkhbDGJC/fWs3UxcnEICZxilLh9+B8z hLOTUeLe1cNsIFVCAksYJXa9z+pi5OBgE7CSeHLIB6RGRGAyq8SE/mdgNcwCUhJ3b3WBTRUW cJV4PvMGUJwdqMhN4p4bSFREwEji7qUfYBUsAqoS284vYwaxeQU8JZoer2SB2KQuMf3XL7A4 p4CGxLXT3UwgNqOArMSE3YsYITaJS9x6Mp8J4n4BiSV7zjND2KISLx//Y4WwFSU+vtoHVa8n cWPqFKgrtSWWLXwNtVdQ4uTMJ1B7dSSO/WlgnsAoMQvJillI2mchaZ+FpH0BI8sqRuHcxMyc 9HJDvdSizOTi4vw8veLUTYzAFHBwy2/dHYynzokcYpTmYFES5+VK2u8vJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgdH6XRUbJ69tf2hoSXPHAdXQGcrmPpyrX9/O706U0F30/+q0ysyE98n1 yYWxuzom2u99o1u/2uCl3K1j2hfOfpjpdW9u7JNrsk9v/1lkm2Gp+Wd/xYSIv4GhJ56sXRbl q7gjwfOrfdiBHdv/lj3lW7154gb9zZ9MLcw2/Kiau+hc9Oec3X+6klcrsRRnJBpqMRcVJwIA 5rv+pM8CAAA=
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
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, 28 Sep 2012 15:07:02 -0000

No IPR

BR
Daniele=20

>-----Original Message-----
>From: Lou Berger [mailto:lberger@labn.net]=20
>Sent: venerd=EC 28 settembre 2012 16.21
>To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn;=20
>sergio.belotti@alcatel-lucent.it; Daniele Ceccarelli;=20
>kpithewan@infinera.com; yi.lin@huawei.com;=20
>xuyunbin@mail.ritt.com.cn;=20
>pietro_vittorio.grandi@alcatel-lucent.it; Diego Caviglia;=20
>rrao@infinera.com; jdrake@juniper.net; IBryskin@advaoptical.com
>Cc: CCAMP
>Subject: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
>
>---------------------------------------------------------------
>----------
>CCAMP: Please note there are IPR disclosures:
>https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search
>&document_search=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3
>---------------------------------------------------------------
>----------
>
>Authors, Contributors, (CCAMP)
>
>As part of the preparation for WG Last Call:
>
>Are you aware of any IPR that applies to=20
>draft-ietf-ccamp-gmpls-signaling-g709v3?
>
>If so, has this IPR been disclosed in compliance with IETF IPR=20
>rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
>
>If you are listed as a document author or contributor please=20
>answer the above by responding to this email regardless of=20
>whether or not you are aware of any relevant IPR.  This=20
>document will not advance to the next stage until a response=20
>has been received from each author and listed contributor. =20
>NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
>If you are on the CCAMP WG email list but are not listed as an=20
>author or contributor, we remind you of your obligations under=20
>the IETF IPR rules which encourages you to notify the IETF if=20
>you are aware of IPR of others on an IETF contribution, or to=20
>refrain from participating in any contribution or discussion=20
>related to your undisclosed IPR.  For more information, please=20
>see the RFCs listed above and=20
>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>Thank you,
>CCAMP WG Chairs
>
>PS Please include all listed in the headers of this message in=20
>your response.
>=

From diego.caviglia@ericsson.com  Fri Sep 28 08:08: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 2B59621F84FE for ; Fri, 28 Sep 2012 08:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m66BVvW1O+Rk for ; Fri, 28 Sep 2012 08:08:25 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2714121F84F1 for ; Fri, 28 Sep 2012 08:08:24 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-66-5065bd68a6d8
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 81.B4.11467.86DB5605; Fri, 28 Sep 2012 17:08:24 +0200 (CEST)
Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 28 Sep 2012 17:08:24 +0200
From: Diego Caviglia 
To: Lou Berger , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , Daniele Ceccarelli , "zhangfatai@huawei.com" , "danli@huawei.com" 
Date: Fri, 28 Sep 2012 17:08:26 +0200
Thread-Topic: Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
Thread-Index: Ac2dhGxNio78vA8/TTeVl0NJ1XvKXgABqqPA
Message-ID: <8BB4A0BBE54F3548A50D281C391C38E317165FC838@ESESSCMS0353.eemea.ericsson.se>
References: <5065B22D.5050808@labn.net>
In-Reply-To: <5065B22D.5050808@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: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvrW7G3tQAg5cHBC2ezLnBYvHq+QRG i47mtywWM/7cZbNYtvk3u0Vf83lWBzaP1md7WT1ajrxl9Viy5CeTx4dNzWwBLFFcNimpOZll qUX6dglcGVu3vWMraOetOPH8NFsD40WuLkZODgkBE4nDLY2sELaYxIV769m6GLk4hAROMUq0 f57NDOEsZJQ4fqQfrIpNwEhiV8dMFpCEiMBtJoll59qYQRLMAlISd291MYLYLAKqEufvrmYC sYUFnCSWXzgN1iwi4Czx9s8ENgjbSKJzQSuYzSsQLrF+ygkwW0hAXWLW7SVgMzkFNCRuPzwE NodRQFZiwu5FjBC7xCVuPZnPBHG2gMSSPeeZIWxRiZeP/7FC1MtI/Nr0jRWiXk/ixtQpbBC2 tsSyha+ZIfYKSpyc+YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYhXMTM3PSyw31Uosyk4uL8/P0 ilM3MQJj7+CW37o7GE+dEznEKM3BoiTOy5W0319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD I3/r97nMrgv+nogXOfvvAT/XilOc938sirDgr1wSovroWZSz762lphXRMzduu8Lf/PL0j291 ysyHDn73vzB7wX9/hTnrVxelzr39ymzpedvbCWWPaub/qeG8PudnhdGVa8/n6EqF8ZxUmSei qhD8fWLJAxGnAt208Hj/eyHKzV3N1TrM4X7tO5VYijMSDbWYi4oTAXHp9m2LAgAA
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
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, 28 Sep 2012 15:08:26 -0000

No IPR

Ciao

D=20

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: venerd=EC 28 settembre 2012 16.20
To: sergio.belotti@alcatel-lucent.com; pietro_vittorio.grandi@alcatel-lucen=
t.com; Daniele Ceccarelli; Diego Caviglia; zhangfatai@huawei.com; danli@hua=
wei.com
Cc: CCAMP
Subject: Regarding IPR on draft-ietf-ccamp-otn-g709-info-model

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to draft-ietf-ccamp-otn-g709-info-mod=
el?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please answer the abo=
ve by responding to this email regardless of whether or not you are aware o=
f any relevant IPR.  This document will not advance to the next stage until=
 a response has been received from each author and listed contributor.  NOT=
E: THIS APPLIES TO ALL 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 co=
ntributor, 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 s=
ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik=
i/IntellectualProperty.

Thank you,
CCAMP WG Chairs

PS Please include all listed in the headers of this message in your respons=
e.


From diego.caviglia@ericsson.com  Fri Sep 28 08:08: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 68F9C21F8466 for ; Fri, 28 Sep 2012 08:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUllyykv8bQf for ; Fri, 28 Sep 2012 08:08:34 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 647E521F84F1 for ; Fri, 28 Sep 2012 08:08:34 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-fc-5065bd71bd0b
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 59.5A.17130.17DB5605; Fri, 28 Sep 2012 17:08:33 +0200 (CEST)
Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 28 Sep 2012 17:08:33 +0200
From: Diego Caviglia 
To: Lou Berger , Daniele Ceccarelli , "zhangfatai@huawei.com" , "danli@huawei.com" , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "rrao@infinera.com" , "kpithewan@infinera.com" ,  "jdrake@juniper.net" 
Date: Fri, 28 Sep 2012 17:08:35 +0200
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: Ac2dhHCKdosavLOAQP6H0q/7Bf/L2gABqziw
Message-ID: <8BB4A0BBE54F3548A50D281C391C38E317165FC839@ESESSCMS0353.eemea.ericsson.se>
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@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: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Vrdwb2qAQe8tcYsnc26wWLx6PoHR Ys5dZ4tvq7ktOprfsljM+HOXzeL5tXdMFss2/2a36Gs+z+rA6dH6bC+rR8uRt6weS5b8ZPK4 9OIQm8f1pqvsHh82NbMFsEVx2aSk5mSWpRbp2yVwZWyc08RS0CJQ8fbzR5YGxp28XYwcHBIC JhKHHwl3MXICmWISF+6tZ+ti5OIQEjjFKDFn6kooZy6jxMHNz5hAqtgEjCR2dcxkAUmICDxj luj4sJ0NJMEsICVx91YXI4jNIqAqMW3GfjBbWMBBYtfmqywgtoiAo8TTvttMELaRxO9l18Bq eAXCJRY/P8EKcpGQgLrE6RPOICangIbEzmtyIBWMArISE3YvYoTYJC5x68l8JoijBSSW7DnP DGGLSrx8/I8Vol5G4temb6wQ9XoSN6ZOgbpSW2LZwtfMEFsFJU7OfMIygVFsFpKxs5C0zELS MgtJywJGllWMwrmJmTnp5eZ6qUWZycXF+Xl6xambGIExenDLb4MdjJvuix1ilOZgURLn1VPd 7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMSUzKstqZQRrzp9Z3Hrs9f57nvAayh8+lPU8 dffHX7oRXSuXzuo4Y6jrqeq097PeroY2j9oze3p2rHTqc9ofV9bleH8Hk1Vp9mRLqcKV2emz f00Lvbsg5mbR/7Sa+iUcb40+BXzaeNfUNTCihjVop4fvGrePMne6pgp/EzR6bLCi+uCtort8 SizFGYmGWsxFxYkAAE6OZZ8CAAA=
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
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, 28 Sep 2012 15:08:35 -0000

No IPR

Ciao

D=20

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: venerd=EC 28 settembre 2012 16.21
To: Daniele Ceccarelli; Diego Caviglia; zhangfatai@huawei.com; danli@huawei=
.com; sergio.belotti@alcatel-lucent.com; pietro_vittorio.grandi@alcatel-luc=
ent.com; rrao@infinera.com; kpithewan@infinera.com; jdrake@juniper.net
Cc: CCAMP
Subject: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3

-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_=
search=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3
-------------------------------------------------------------------------

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-ospf-g709v3=
?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please answer the abo=
ve by responding to this email regardless of whether or not you are aware o=
f any relevant IPR.  This document will not advance to the next stage until=
 a response has been received from each author and listed contributor.  NOT=
E: THIS APPLIES TO ALL 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 co=
ntributor, 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 s=
ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik=
i/IntellectualProperty.

Thank you,
CCAMP WG Chairs

PS Please include all listed in the headers of this message in your respons=
e.


From diego.caviglia@ericsson.com  Fri Sep 28 08:08: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 2260621F8678 for ; Fri, 28 Sep 2012 08:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlaFG4Cs7CNr for ; Fri, 28 Sep 2012 08:08:48 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9E921F8672 for ; Fri, 28 Sep 2012 08:08:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-c7-5065bd7ea328
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BC.CA.25676.E7DB5605; Fri, 28 Sep 2012 17:08:46 +0200 (CEST)
Received: from ESESSCMS0353.eemea.ericsson.se ([169.254.1.215]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Fri, 28 Sep 2012 17:08:46 +0200
From: Diego Caviglia 
To: Lou Berger , "zhangfatai@huawei.com" , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" , Daniele Ceccarelli , "kpithewan@infinera.com" , "yi.lin@huawei.com" , "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , "rrao@infinera.com" , "jdrake@juniper.net" , "IBryskin@advaoptical.com" 
Date: Fri, 28 Sep 2012 17:08:48 +0200
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: Ac2dhHKYJORWDltgQC+bT5rbwNxZXQABrCVQ
Message-ID: <8BB4A0BBE54F3548A50D281C391C38E317165FC83A@ESESSCMS0353.eemea.ericsson.se>
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@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: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM+JvrW7d3tQAg3lbtS2ezLnBYnGqp53R Ys5dZ4tvq7ktOprfslic+DSL3eL5tXdMFi0vd7BbfD1Yb/Hj0ntmi77m86wW21+sZ3fg8Ti7 4A+rx9m1LWweLUfesnosWfKTyePSi0NsHtebrrJ7fNjUzOax5/9WtgCOKC6blNSczLLUIn27 BK6M5q6QglcCFd/2v2RrYJzF18XIySEhYCKx9skBdghbTOLCvfVsXYxcHEICpxglTnQ8ZIVw FjJK3NvSxARSxSZgJLGrYyYLSEJEYDarxNR5T1lBEswCUhJ3b3UxgtgsAqoSD298BrOFBVwl ns+8ATSWHajBTeKeG0hUBGjMlKl3wUbyCoRL3Jpzng3EFhJQl5j+6xcziM0poCFx7XQ3WA2j gKzEhN2LGCE2iUvcejKfCeJoAYkle84zQ9iiEi8f/2OFqJeR+LXpG9RlehI3pk5hg7C1JZYt fM0MsVdQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUonJuYmZNebqSXWpSZXFycn6dXnLqJ ERjTB7f8Vt3BeOecyCFGaQ4WJXFe6617/IUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwro3i KwkIyF72IdHisVHZr2uClz58DmdrZbX7Hlf2R3btvzmrA5QmzFvK88+Sz86Jb+adLCk9+c+P VfuLqj9eKQnUTtmxZ/Z3dp30pg+iXs5nU9dPaNWvU3ZtS3X9UjvRUEkl/TcPr1fBlFoN5/Sn Czkz+e1uX7WIud2wxUVN438e6+MdC02VWIozEg21mIuKEwHczfYrtwIAAA==
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
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, 28 Sep 2012 15:08:49 -0000

No IPR

Ciao

D=20

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: venerd=EC 28 settembre 2012 16.21
To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn; sergio.belotti@al=
catel-lucent.it; Daniele Ceccarelli; kpithewan@infinera.com; yi.lin@huawei.=
com; xuyunbin@mail.ritt.com.cn; pietro_vittorio.grandi@alcatel-lucent.it; D=
iego Caviglia; rrao@infinera.com; jdrake@juniper.net; IBryskin@advaoptical.=
com
Cc: CCAMP
Subject: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3

-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_=
search=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3
-------------------------------------------------------------------------

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-signaling-g=
709v3?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please answer the abo=
ve by responding to this email regardless of whether or not you are aware o=
f any relevant IPR.  This document will not advance to the next stage until=
 a response has been received from each author and listed contributor.  NOT=
E: THIS APPLIES TO ALL 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 co=
ntributor, 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 s=
ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik=
i/IntellectualProperty.

Thank you,
CCAMP WG Chairs

PS Please include all listed in the headers of this message in your respons=
e.

From leeyoung@huawei.com  Fri Sep 28 09:15: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 1E3B321F84D2 for ; Fri, 28 Sep 2012 09:15:14 -0700 (PDT)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02rhOOGTpDJe for ; Fri, 28 Sep 2012 09:15:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7321F844F for ; Fri, 28 Sep 2012 09:15:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC74519; Fri, 28 Sep 2012 16:15:09 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 17:13:15 +0100
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 17:14:12 +0100
Received: from dfweml511-mbx.china.huawei.com ([169.254.16.239]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 09:14:06 -0700
From: Leeyoung 
To: Remi Theillaud 
Thread-Topic: [CCAMP] FW: I-D	Action: draft-ietf-ccamp-general-constraint-encode-09.txt
Thread-Index: AQHNnXz+rwOL33XCC0OQLtwlTLQtJ5ef7Exw
Date: Fri, 28 Sep 2012 16:14:05 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172907A30B@dfweml511-mbx.china.huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1729079F4F@dfweml511-mbx.china.huawei.com> <5065A596.5070407@marben-products.com>
In-Reply-To: <5065A596.5070407@marben-products.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.114]
Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E172907A30Bdfweml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Bruno Cabon , CCAMP 
Subject: Re: [CCAMP] FW: I-D	Action: draft-ietf-ccamp-general-constraint-encode-09.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, 28 Sep 2012 16:15:14 -0000

--_000_7AEB3D6833318045B4AE71C2C87E8E172907A30Bdfweml511mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Remi,

Thanks for your input.

Please see inline for my comment.

Best Regards,
Young

From: Remi Theillaud [mailto:remi.theillaud@marben-products.com]
Sent: Friday, September 28, 2012 8:27 AM
To: Leeyoung
Cc: Greg Bernstein; Bruno Cabon
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-general-constraint-en=
code-09.txt


Young,

Version -09 has not fixed the typo I reported earlier this week (minor issu=
e anyway):

  *   There is a typo in section 2.6.5: the first sentence says "In the cas=
e of the SIMPLE_LABEL & CHANNEL_COUNT the format is given by:". I believe i=
t should say "In the case of the LINK_LABEL_EXCLUSIVITY the format is given=
 by:"

YOUNG>> Yes, I agree and will correct this in v10.
Another typo I believe:

  *   In section 2.1 (Link Set Field). This section assigns value 1 to "Inc=
lusive Range" (Action field). Note that this is not really consistent with =
the value assigned to "Inclusive Range" (which is 2) for Label Set and RB S=
et (this one in draft-ietf-ccamp-rwa-wson-encode-17.txt). The true problem =
is that the text in section 2.1 says "Note that the Action field can
   be set to 0x02(Inclusive Range) only when unnumbered link identifier
   is used.
". It should says "... can be set to 0x01 (Inclusive Range) only ..."
YOUNG>> Yes, I agree. I can change "Inclusive Range" to be 1 in WSON-encodi=
ng (v.18) to be consistent with Generic-encoding and change the set value f=
or this to be 0x01... in Generic Encoding (v10). Would this make you happy?
Regards,
Remi
-------- Original Message --------
Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-general-constraint-encode=
-09.txt
From: Leeyoung 
To: CCAMP 
Date: 27/09/2012 18:58

Hi



This update reflects all the agreements made since the last IETF meeting.

Among the changes made in this version are:



- Switching Capability and Encoding applied to all sub-cases for Port

   Label Restriction sub-TLV in Section 2.6. (per Rajan's input)



- Eliminated A (Availability) Bit from Available Labels Sub-TLV and

   Shared Backup Labels Sub-TLV. (Per Rajan's input)



- Added Appendix for illustration of how to use Priority Flags (per Giovann=
i's input)

- Priority bit remains 8 bits to be consistent with TDM, PSC encoding (e.g.=
, RFC 4090, etc.)



As Greg indicated, this draft is ready to WG LC.



Thanks.

Young



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

From: ccamp-bounces@ietf.org [mailto:ccamp-b=
ounces@ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: Thursday, September 27, 2012 11:42 AM

To: i-d-announce@ietf.org

Cc: ccamp@ietf.org

Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-09.=
txt





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 Work=
ing Group of the IETF.



  Title           : General Network Element Constraint Encoding for GMPLS C=
ontrolled Networks

  Author(s)       : Greg M. Bernstein

                          Young Lee

                          Dan Li

                          Wataru Imajuku

  Filename        : draft-ietf-ccamp-general-constraint-encode-09.txt

  Pages           : 31

  Date            : 2012-09-27



Abstract:

   Generalized Multiprotocol Label Switching can be used to control a

   wide variety of technologies. In some of these technologies network

   elements and links may impose additional routing constraints such as

   asymmetric switch connectivity, non-local label assignment, and

   label range limitations on links.



   This document provides efficient, protocol-agnostic encodings for

   general information elements representing connectivity and label

   constraints as well as label availability. It is intended that

   protocol-specific documents will reference this memo to describe how

   information is carried for specific uses.











The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-09



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco=
de-09





Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp

.




--_000_7AEB3D6833318045B4AE71C2C87E8E172907A30Bdfweml511mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi Remi,


 <=
/p>

Thanks for your input.


 <=
/p>

Please see inline for my =
comment.



 <=
/p>

Best Regards,<=
/span>


Young

 <=
/p>





From: Remi Theillaud [mailto:remi.theillaud@marben-prod=
ucts.com]


Sent: Friday, September 28, 2012 8:27 AM

To: Leeyoung

Cc: Greg Bernstein; Bruno Cabon

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-general-constr=
aint-encode-09.txt






 




Young,



Version -09 has not fixed the typo I reported earlier this week (minor issu=
e anyway):


    

  • 
There is a typo in section 2.6.5: the first sentence says "In the case=
 of the SIMPLE_LABEL & CHANNEL_COUNT the format is given by:". I b=
elieve it should say "In the case of the LINK_LABEL_EXCLUSIVITY the fo=
rmat is given by:"


 


YOUNG>> Yes, I agree and will cor=
rect this in v10.



Another typo I believe:


    

  • 
In section 2.1 (Link Set Field). This section assigns value 1 to "Incl=
usive Range" (Action field). Note that this is not really consistent w=
ith the value assigned to "Inclusive Range" (which is 2) for Labe=
l Set and RB Set (this one in draft-ietf-ccamp-rwa-wson-encode-17.txt).
 The true problem is that the text in section 2.1 says "Note that the =
Action field can
    
   be set to 0x02(Inclusive Range) only when unnumbered link iden=
tifier
    
   is used.
    
". It should says "... can be set to 0x01 (Inclusive Range) only =
..."


YOUNG>> Yes, I agree. I can chang=
e “Inclusive Range” to be 1 in WSON-encoding (v.18) to be consi=
stent
 with Generic-encoding and change the set value for this to be 0x01… =
in Generic Encoding (v10). Would this make you happy?



Regards,

Remi




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

Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-general-constraint-encode=
-09.txt

From: Leeyoung <leeyoung@huawei.c=
om>

To: CCAMP <ccamp@ietf.org>

Date: 27/09/2012 18:58






Hi


 


This update reflects all the agreements made since the last IETF meeti=
ng. 


Among the changes made in this version are:


 


- Switching Capability and Encoding applied to all sub-cases for Port<=
o:p>


   Label Restriction sub-TLV in Section 2.6. (per Rajan's in=
put)


 


- Eliminated A (Availability) Bit from Available Labels Sub-TLV and


   Shared Backup Labels Sub-TLV. (Per Rajan's input)


 


- Added Appendix for illustration of how to use Priority Flags (per Gi=
ovanni's input)


- Priority bit remains 8 bits to be consistent with TDM, PSC encoding =
(e.g., RFC 4090, etc.)


 


As Greg indicated, this draft is ready to WG LC. 


 


Thanks.


Young


 


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


From: ccamp-bounces@ietf.org=
 [mailto:ccamp-bounces@ietf.o=
rg] On Behalf Of internet-d=
rafts@ietf.org


Sent: Thursday, September 27, 2012 11:42 AM


To: i-d-announce@ietf.org=



Cc: ccamp@ietf.org

Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encod=
e-09.txt


 


 


A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


 This draft is a work item of the Common Control and Measurement Plane=
 Working Group of the IETF.


 


  Title         &nbs=
p; : General Network Element Constraint Encoding for GMPLS Controlled Netwo=
rks


  Author(s)       : Greg M. Bernste=
in


           &nbs=
p;            &=
nbsp; Young Lee


           &nbs=
p;            &=
nbsp; Dan Li


           &nbs=
p;            &=
nbsp; Wataru Imajuku


  Filename        : draft-ietf=
-ccamp-general-constraint-encode-09.txt


  Pages         &nbs=
p; : 31


  Date          =
;  : 2012-09-27


 


Abstract:


   Generalized Multiprotocol Label Switching can be used to =
control a


   wide variety of technologies. In some of these technologi=
es network


   elements and links may impose additional routing constrai=
nts such as


   asymmetric switch connectivity, non-local label assignmen=
t, and


   label range limitations on links.


 


   This document provides efficient, protocol-agnostic encod=
ings for


   general information elements representing connectivity an=
d label


   constraints as well as label availability. It is intended=
 that


   protocol-specific documents will reference this memo to d=
escribe how


   information is carried for specific uses.

 


 


 


 


 


The IETF datatracker status page for this draft is:


https://datatracker.ietf.org/doc/draft-ietf-ccamp-general=
-constraint-encode


 


There's also a htmlized version available at:


http://tools.ietf.org/html/draft-ietf-ccamp-general-constrai=
nt-encode-09


 


A diff from the previous version is available at:


http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-=
general-constraint-encode-09


 


 


Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-drafts/


 


_______________________________________________


CCAMP mailing list


CCAMP@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ccamp


_______________________________________________


CCAMP mailing list


CCAMP@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ccamp


.


 




 






--_000_7AEB3D6833318045B4AE71C2C87E8E172907A30Bdfweml511mbxchi_--

From rrao@infinera.com  Fri Sep 28 09:45:43 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 6B95E21F8568 for ; Fri, 28 Sep 2012 09:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwCKXWAAwM0F for ; Fri, 28 Sep 2012 09:45:43 -0700 (PDT)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3BE21F855E for ; Fri, 28 Sep 2012 09:45:42 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 09:45:41 -0700
From: Rajan Rao 
To: Lou Berger , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , "zhangfatai@huawei.com" , "danli@huawei.com" , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , Khuzema Pithewan , "jdrake@juniper.net" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYRyLSXGG+ZDGUq1+nR+NXlvJZef9TOQ
Date: Fri, 28 Sep 2012 16:45:41 +0000
Message-ID: <650AA355E323C34D9D4AAEED952E053D3FA99405@SV-EXDB-PROD1.infinera.com>
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.100.96.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
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, 28 Sep 2012 16:45:43 -0000

Hi,

Yes;   IPR has been disclosed already.

Thanks
Rajan (co-author)

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Friday, September 28, 2012 7:21 AM
To: daniele.ceccarelli@ericsson.com; diego.caviglia@ericsson.com; zhangfata=
i@huawei.com; danli@huawei.com; sergio.belotti@alcatel-lucent.com; pietro_v=
ittorio.grandi@alcatel-lucent.com; Rajan Rao; Khuzema Pithewan; jdrake@juni=
per.net
Cc: CCAMP
Subject: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3

-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_=
search=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3
-------------------------------------------------------------------------

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-ospf-g709v3=
?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please answer the abo=
ve by responding to this email regardless of whether or not you are aware o=
f any relevant IPR.  This document will not advance to the next stage until=
 a response has been received from each author and listed contributor.  NOT=
E: THIS APPLIES TO ALL 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 co=
ntributor, 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 s=
ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik=
i/IntellectualProperty.

Thank you,
CCAMP WG Chairs

PS Please include all listed in the headers of this message in your respons=
e.


From rrao@infinera.com  Fri Sep 28 09:52:12 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 1802E21F85A3 for ; Fri, 28 Sep 2012 09:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2tOZR+5Bz7l for ; Fri, 28 Sep 2012 09:52:08 -0700 (PDT)
Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id F0E9121F8456 for ; Fri, 28 Sep 2012 09:52:06 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 09:52:06 -0700
From: Rajan Rao 
To: Lou Berger , "zhangfatai@huawei.com" , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" , "daniele.ceccarelli@ericsson.com" , Khuzema Pithewan ,  "yi.lin@huawei.com" , "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , "diego.caviglia@ericsson.com" , "jdrake@juniper.net" , "IBryskin@advaoptical.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: AQHNnYRzsb81HhN6u0Kwhbv8a+42A5ef9sIQ
Date: Fri, 28 Sep 2012 16:52:05 +0000
Message-ID: <650AA355E323C34D9D4AAEED952E053D3FA99427@SV-EXDB-PROD1.infinera.com>
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.100.96.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
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, 28 Sep 2012 16:52:12 -0000

Hi,

Yes;   IPR has been disclosed already.

Thanks
Rajan (co-author)

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: Friday, September 28, 2012 7:21 AM
To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn; sergio.belotti@al=
catel-lucent.it; daniele.ceccarelli@ericsson.com; Khuzema Pithewan; yi.lin@=
huawei.com; xuyunbin@mail.ritt.com.cn; pietro_vittorio.grandi@alcatel-lucen=
t.it; diego.caviglia@ericsson.com; Rajan Rao; jdrake@juniper.net; IBryskin@=
advaoptical.com
Cc: CCAMP
Subject: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3

-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_=
search=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3
-------------------------------------------------------------------------

Authors, Contributors, (CCAMP)

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to draft-ietf-ccamp-gmpls-signaling-g=
709v3?

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please answer the abo=
ve by responding to this email regardless of whether or not you are aware o=
f any relevant IPR.  This document will not advance to the next stage until=
 a response has been received from each author and listed contributor.  NOT=
E: THIS APPLIES TO ALL 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 co=
ntributor, 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 s=
ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik=
i/IntellectualProperty.

Thank you,
CCAMP WG Chairs

PS Please include all listed in the headers of this message in your respons=
e.

From remi.theillaud@marben-products.com  Fri Sep 28 13:05: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 4E49121F85F0 for ; Fri, 28 Sep 2012 13:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZP1zLs0RpNi for ; Fri, 28 Sep 2012 13:05:00 -0700 (PDT)
Received: from bizpsie4.9services.com (bizpsie4.9services.com [84.96.93.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3667121F8504 for ; Fri, 28 Sep 2012 13:04:59 -0700 (PDT)
Received: from HP14316315.psie.local ([84.96.93.149]) by bizpsie4.9services.com with 9services id 4k501k0023DMWBY04k50Eb; Fri, 28 Sep 2012 22:05:01 +0200
X-VRSPAM-SCORE: -200.00
Received: from HP143HE2BE.psie.local (10.110.139.25) by HP14316315.psie.local (10.110.130.141) with Microsoft SMTP Server (TLS) id 8.2.254.1; Fri, 28 Sep 2012 22:03:04 +0200
Received: from HP1434V231.psie.local ([169.254.3.170]) by HP143HE2BE.psie.local ([10.110.139.25]) with mapi; Fri, 28 Sep 2012 22:03:04 +0200
From: =?Windows-1252?Q?R=E9mi_Theillaud?= 
To: Leeyoung 
Date: Fri, 28 Sep 2012 22:00:59 +0200
Thread-Topic: [CCAMP] FW: I-D	Action: draft-ietf-ccamp-general-constraint-encode-09.txt
Thread-Index: AQHNnXz+rwOL33XCC0OQLtwlTLQtJ5ef7ExwgABAryw=
Message-ID: <212380E0F4211647887B23912AF3C7FBD4F6E138F5@HP1434V231.psie.local>
References: <7AEB3D6833318045B4AE71C2C87E8E1729079F4F@dfweml511-mbx.china.huawei.com> <5065A596.5070407@marben-products.com>, <7AEB3D6833318045B4AE71C2C87E8E172907A30B@dfweml511-mbx.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172907A30B@dfweml511-mbx.china.huawei.com>
Accept-Language: en-US, fr-FR
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, fr-FR
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Bruno Cabon , CCAMP 
Subject: Re: [CCAMP] FW: I-D	Action: draft-ietf-ccamp-general-constraint-encode-09.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, 28 Sep 2012 20:05:01 -0000

Hi Young,

That would work for me, thanks.

Best regards,
Remi
________________________________________
From: Leeyoung [leeyoung@huawei.com]
Sent: Friday, September 28, 2012 6:14 PM
To: R=E9mi Theillaud
Cc: Greg Bernstein; Bruno Cabon; CCAMP
Subject: RE: [CCAMP] FW: I-D    Action: draft-ietf-ccamp-general-constraint=
-encode-09.txt

Hi Remi,

Thanks for your input.

Please see inline for my comment.

Best Regards,
Young

From: Remi Theillaud [mailto:remi.theillaud@marben-products.com]
Sent: Friday, September 28, 2012 8:27 AM
To: Leeyoung
Cc: Greg Bernstein; Bruno Cabon
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-general-constraint-en=
code-09.txt


Young,

Version -09 has not fixed the typo I reported earlier this week (minor issu=
e anyway):

 *   There is a typo in section 2.6.5: the first sentence says "In the case=
 of the SIMPLE_LABEL & CHANNEL_COUNT the format is given by:". I believe it=
 should say "In the case of the LINK_LABEL_EXCLUSIVITY the format is given =
by:"

YOUNG>> Yes, I agree and will correct this in v10.
Another typo I believe:

 *   In section 2.1 (Link Set Field). This section assigns value 1 to "Incl=
usive Range" (Action field). Note that this is not really consistent with t=
he value assigned to "Inclusive Range" (which is 2) for Label Set and RB Se=
t (this one in draft-ietf-ccamp-rwa-wson-encode-17.txt). The true problem i=
s that the text in section 2.1 says "Note that the Action field can
   be set to 0x02(Inclusive Range) only when unnumbered link identifier
   is used.
". It should says "... can be set to 0x01 (Inclusive Range) only ..."
YOUNG>> Yes, I agree. I can change =93Inclusive Range=94 to be 1 in WSON-en=
coding (v.18) to be consistent with Generic-encoding and change the set val=
ue for this to be 0x01=85 in Generic Encoding (v10). Would this make you ha=
ppy?
Regards,
Remi
-------- Original Message --------
Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-general-constraint-encode=
-09.txt
From: Leeyoung 
To: CCAMP 
Date: 27/09/2012 18:58

Hi



This update reflects all the agreements made since the last IETF meeting.

Among the changes made in this version are:



- Switching Capability and Encoding applied to all sub-cases for Port

   Label Restriction sub-TLV in Section 2.6. (per Rajan's input)



- Eliminated A (Availability) Bit from Available Labels Sub-TLV and

   Shared Backup Labels Sub-TLV. (Per Rajan's input)



- Added Appendix for illustration of how to use Priority Flags (per Giovann=
i's input)

- Priority bit remains 8 bits to be consistent with TDM, PSC encoding (e.g.=
, RFC 4090, etc.)



As Greg indicated, this draft is ready to WG LC.



Thanks.

Young



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

From: ccamp-bounces@ietf.org [mailto:ccamp-b=
ounces@ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: Thursday, September 27, 2012 11:42 AM

To: i-d-announce@ietf.org

Cc: ccamp@ietf.org

Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-09.=
txt





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 Work=
ing Group of the IETF.



  Title           : General Network Element Constraint Encoding for GMPLS C=
ontrolled Networks

  Author(s)       : Greg M. Bernstein

                          Young Lee

                          Dan Li

                          Wataru Imajuku

  Filename        : draft-ietf-ccamp-general-constraint-encode-09.txt

  Pages           : 31

  Date            : 2012-09-27



Abstract:

   Generalized Multiprotocol Label Switching can be used to control a

   wide variety of technologies. In some of these technologies network

   elements and links may impose additional routing constraints such as

   asymmetric switch connectivity, non-local label assignment, and

   label range limitations on links.



   This document provides efficient, protocol-agnostic encodings for

   general information elements representing connectivity and label

   constraints as well as label availability. It is intended that

   protocol-specific documents will reference this memo to describe how

   information is carried for specific uses.











The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-09



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco=
de-09





Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

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 internet-drafts@ietf.org  Fri Sep 28 15:59: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 838F521F85A0; Fri, 28 Sep 2012 15:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.506
X-Spam-Level: 
X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQS-bRa-oDxu; Fri, 28 Sep 2012 15:59:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081BB21F850B; Fri, 28 Sep 2012 15:59:45 -0700 (PDT)
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: 4.34
Message-ID: <20120928225945.10531.85649.idtracker@ietfa.amsl.com>
Date: Fri, 28 Sep 2012 15:59:45 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-10.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, 28 Sep 2012 22:59:45 -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 Work=
ing Group of the IETF.

	Title           : General Network Element Constraint Encoding for GMPLS Co=
ntrolled Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-general-constraint-encode-10.txt
	Pages           : 31
	Date            : 2012-09-28

Abstract:
   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies. In some of these technologies network
   elements and links may impose additional routing constraints such as
   asymmetric switch connectivity, non-local label assignment, and
   label range limitations on links.

   This document provides efficient, protocol-agnostic encodings for
   general information elements representing connectivity and label
   constraints as well as label availability. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco=
de-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Fri Sep 28 15:59: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 597CF21F85F3; Fri, 28 Sep 2012 15:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level: 
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFmq92lzbIM1; Fri, 28 Sep 2012 15:59:47 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2021F85AA; Fri, 28 Sep 2012 15:59:47 -0700 (PDT)
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: 4.34
Message-ID: <20120928225947.23959.47697.idtracker@ietfa.amsl.com>
Date: Fri, 28 Sep 2012 15:59:47 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-18.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, 28 Sep 2012 22:59:48 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Common Control and Measurement Plane Work=
ing Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Encoding f=
or Wavelength Switched Optical Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-rwa-wson-encode-18.txt
	Pages           : 38
	Date            : 2012-09-28

Abstract:
   A wavelength switched optical network (WSON) requires that certain
   key information elements are made available to facilitate path
   computation and the establishment of label switching paths (LSPs).
   The information model described in "Routing and Wavelength
   Assignment Information for Wavelength Switched Optical Networks"
   shows what information is required at specific points in the WSON.
   Part of the WSON information model contains aspects that may be of
   general applicability to other technologies, while other parts are
   fairly specific to WSONs.

   This document provides efficient, protocol-agnostic encodings for
   the WSON specific information elements. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses. Such encodings can be used
   to extend GMPLS signaling and routing protocols. In addition these
   encodings could be used by other mechanisms to convey this same
   information to a path computation element (PCE).





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-18

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-encode-18


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From leeyoung@huawei.com  Fri Sep 28 16:02:12 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 6A04921F8569 for ; Fri, 28 Sep 2012 16:02:12 -0700 (PDT)
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.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOB61Fbwlm25 for ; Fri, 28 Sep 2012 16:02:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C75621F8549 for ; Fri, 28 Sep 2012 16:02:11 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC93363; Fri, 28 Sep 2012 23:02:10 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 00:00:43 +0100
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 00:01:41 +0100
Received: from dfweml511-mbx.china.huawei.com ([169.254.16.239]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 16:01:35 -0700
From: Leeyoung 
To: CCAMP 
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-10.txt
Thread-Index: AQHNncz6sJ0sDfCOWU+YWIi4fYHyvpegXn5A
Date: Fri, 28 Sep 2012 23:01:34 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172907A4E5@dfweml511-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [CCAMP] FW: I-D Action:	draft-ietf-ccamp-general-constraint-encode-10.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, 28 Sep 2012 23:02:12 -0000

Hi,

The change here is per Remi's input to correct some Action values and other=
 editorial errors.=20

Thanks.
Young

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Friday, September 28, 2012 6:00 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-general-constraint-encode-10.=
txt


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 Work=
ing Group of the IETF.

	Title           : General Network Element Constraint Encoding for GMPLS Co=
ntrolled Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-general-constraint-encode-10.txt
	Pages           : 31
	Date            : 2012-09-28

Abstract:
   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies. In some of these technologies network
   elements and links may impose additional routing constraints such as
   asymmetric switch connectivity, non-local label assignment, and
   label range limitations on links.

   This document provides efficient, protocol-agnostic encodings for
   general information elements representing connectivity and label
   constraints as well as label availability. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-general-constraint-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-general-constraint-enco=
de-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From leeyoung@huawei.com  Fri Sep 28 16:07: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 F240E21F85F3 for ; Fri, 28 Sep 2012 16:07:10 -0700 (PDT)
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.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF8Kzud8V2YE for ; Fri, 28 Sep 2012 16:07:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 05DC321F849C for ; Fri, 28 Sep 2012 16:07:09 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC93537; Fri, 28 Sep 2012 23:07:09 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 00:03:21 +0100
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 00:04:08 +0100
Received: from dfweml511-mbx.china.huawei.com ([169.254.16.239]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Fri, 28 Sep 2012 16:04:05 -0700
From: Leeyoung 
To: CCAMP 
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-18.txt
Thread-Index: AQHNnc0kPPOqukcOhEmaysc2vC0KD5egXtYA
Date: Fri, 28 Sep 2012 23:04:03 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172907A4F2@dfweml511-mbx.china.huawei.com>
References: <20120928225947.23959.47697.idtracker@ietfa.amsl.com>
In-Reply-To: <20120928225947.23959.47697.idtracker@ietfa.amsl.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.114]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-18.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, 28 Sep 2012 23:07:11 -0000

Hi,

The correction was made for Action values to be consistent with Generic enc=
oding on inclusive range(s).=20
Contributors from Optical Interface Class drafts are added to the contribut=
or list.=20

I believe all pending issues have been resolved in this version.=20

Thanks,
Young

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Friday, September 28, 2012 6:00 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-wson-encode-18.txt


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 Work=
ing Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Encoding f=
or Wavelength Switched Optical Networks
	Author(s)       : Greg M. Bernstein
                          Young Lee
                          Dan Li
                          Wataru Imajuku
	Filename        : draft-ietf-ccamp-rwa-wson-encode-18.txt
	Pages           : 38
	Date            : 2012-09-28

Abstract:
   A wavelength switched optical network (WSON) requires that certain
   key information elements are made available to facilitate path
   computation and the establishment of label switching paths (LSPs).
   The information model described in "Routing and Wavelength
   Assignment Information for Wavelength Switched Optical Networks"
   shows what information is required at specific points in the WSON.
   Part of the WSON information model contains aspects that may be of
   general applicability to other technologies, while other parts are
   fairly specific to WSONs.

   This document provides efficient, protocol-agnostic encodings for
   the WSON specific information elements. It is intended that
   protocol-specific documents will reference this memo to describe how
   information is carried for specific uses. Such encodings can be used
   to extend GMPLS signaling and routing protocols. In addition these
   encodings could be used by other mechanisms to convey this same
   information to a path computation element (PCE).





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-encode

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-18

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-rwa-wson-encode-18


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

From gyzhang@sina.com  Fri Sep 28 17:52: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 2E62A21F8546 for ; Fri, 28 Sep 2012 17:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.899
X-Spam-Level: 
X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, FR_IMPORT_CSS=1.889,  HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4xgy93IeJze for ; Fri, 28 Sep 2012 17:52:50 -0700 (PDT)
Received: from smtp.sina.com.cn (mail7-217.sinamail.sina.com.cn [202.108.7.217]) by ietfa.amsl.com (Postfix) with ESMTP id E337721F84F2 for ; Fri, 28 Sep 2012 17:52:48 -0700 (PDT)
Received: from irxd5-201.sinamail.sina.com.cn (unknown [10.55.5.201]) by smtp.sina.com.cn (SINAMAIL) with ESMTP id B4E17ABCAB5 for ; Sat, 29 Sep 2012 08:52:45 +0800 (CST)
X-Originating-IP: [123.126.22.174]
X-Auth-ID: gyzhang
X-Rcptcnt: gt3
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjQSAKU/KE97fhau/3poAIFfICabeD54oD2GTIUSgQcEhk6JQ4RMijY
Received: from unknown (HELO X220) ([123.126.22.174]) by irxd5-201.sinamail.sina.com.cn with ESMTP; 29 Sep 2012 08:52:44 +0800
Date: Sat, 29 Sep 2012 08:52:41 +0800
From: "=?utf-8?B?Z3l6aGFuZw==?=" 
To: "=?utf-8?B?TG91IEJlcmdlcg==?=" , "=?utf-8?B?emhhbmdmYXRhaQ==?=" , "=?utf-8?B?c2VyZ2lvLmJlbG90dGk=?=" ,  "=?utf-8?B?ZGFuaWVsZS5jZWNjYXJlbGxp?=" ,  "=?utf-8?B?a3BpdGhld2Fu?=" , "=?utf-8?B?eWkubGlu?=" , "=?utf-8?B?eHV5dW5iaW4=?=" , "=?utf-8?B?cGlldHJvX3ZpdHRvcmlvLmdyYW5kaQ==?=" ,  "=?utf-8?B?ZGllZ28uY2F2aWdsaWE=?=" , "=?utf-8?B?cnJhbw==?=" , "=?utf-8?B?amRyYWtl?=" , "=?utf-8?B?SUJyeXNraW4=?=" 
References: <548842050.23540@mail.ritt.com.cn>
Message-ID: <201209290852407213207@sina.com>
X-mailer: Foxmail 6, 15, 201, 22 [cn]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====003_Dragon267245437807_====="
Cc: =?utf-8?B?Q0NBTVA=?= 
Subject: Re: [CCAMP] =?utf-8?q?Regarding_IPR_on_draft-ietf-ccamp-gmpls-signali?= =?utf-8?q?ng-g709v3?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 00:52:51 -0000

This is a multi-part message in MIME format.

--=====003_Dragon267245437807_=====
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit

No IPR.

best,
Guoying





Lou Berger 
2012-09-28  22:20:50 
zhangfatai; zhangguoying; sergio.belotti; daniele.ceccarelli; kpithewan; yi.lin; xuyunbin; pietro_vittorio.grandi; diego.caviglia; rrao; jdrake; IBryskin 
CCAMP 
Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3 
-------------------------------------------------------------------------
CCAMP: Please note there are IPR disclosures:
https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-ccamp-gmpls-signaling-g709v3
-------------------------------------------------------------------------
Authors, Contributors, (CCAMP)
As part of the preparation for WG Last Call:
Are you aware of any IPR that applies to
draft-ietf-ccamp-gmpls-signaling-g709v3?
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 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
PS Please include all listed in the headers of this message in your
response.

--=====003_Dragon267245437807_=====
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u
YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPFNUWUxFIHR5cGU9dGV4dC9jc3M+QGltcG9ydCB1cmwo
IEM6XFVzZXJzXHpoYW5nZ3VveWluZ1xBcHBEYXRhXExvY2FsXE1pY3Jvc29mdFxXaW5kb3dzXFRl
bXBvcmFyeSBJbnRlcm5ldCBGaWxlc1xzY3JvbGxiYXIuY3NzICk7DQo8L1NUWUxFPg0KDQo8TUVU
QSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiIGh0dHAtZXF1aXY9Q29udGVudC1U
eXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD0iTVNIVE1MIDkuMDAuODExMi4xNjQ1
MCI+DQo8U1RZTEU+QGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IOWui+S9kzsNCn0NCkBmb250
LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1m
YW1pbHk6IEDlrovkvZM7DQp9DQpAcGFnZSBTZWN0aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0
OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZw
dDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBURVhU
LUFMSUdOOiBqdXN0aWZ5OyBNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVz
IE5ldyBSb21hbiI7IEZPTlQtU0laRTogMTAuNXB0DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQt
SlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBURVhULUFMSUdOOiBqdXN0aWZ5OyBNQVJHSU46IDBj
bSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IEZPTlQtU0laRTogMTAu
NXB0DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsg
VEVYVC1BTElHTjoganVzdGlmeTsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJU
aW1lcyBOZXcgUm9tYW4iOyBGT05ULVNJWkU6IDEwLjVwdA0KfQ0KQTpsaW5rIHsNCglDT0xPUjog
Ymx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsN
CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7
DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNv
SHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5k
ZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9OVC1TVFlMRTogbm9ybWFsOyBGT05U
LUZBTUlMWTogVmVyZGFuYTsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtV0VJR0hUOiBub3JtYWw7
IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UN
Cn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0NClVOS05PV04gew0KCUZPTlQt
U0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9U
VE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1B
UkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRP
TTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgc3R5bGU9IkZPTlQtRkFNSUxZOiB2
ZXJkYW5hOyBGT05ULVNJWkU6IDEwcHQiPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9
MiBmYWNlPVZlcmRhbmE+Tm8gSVBSLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAw
MDA4MD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+YmVzdCw8
L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODA+R3VveWluZzwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5h
PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAgc2l6
ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+PC9ESVY+PEZPTlQgY29sb3I9IzAwMDA4MCANCnNpemU9
MiBmYWNlPVZlcmRhbmE+DQo8SFI+DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm
YWNlPVZlcmRhbmE+TG91IEJlcmdlciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm
YWNlPVZlcmRhbmE+MjAxMi0wOS0yOCZuYnNwOyAyMjoyMDo1MCA8L0ZPTlQ+PC9ESVY+DQo8RElW
PjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+emhhbmdmYXRhaTsgemhhbmdndW95aW5nOyBzZXJn
aW8uYmVsb3R0aTsgDQpkYW5pZWxlLmNlY2NhcmVsbGk7IGtwaXRoZXdhbjsgeWkubGluOyB4dXl1
bmJpbjsgcGlldHJvX3ZpdHRvcmlvLmdyYW5kaTsgDQpkaWVnby5jYXZpZ2xpYTsgcnJhbzsgamRy
YWtlOyBJQnJ5c2tpbiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRh
bmE+Q0NBTVAgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPlJl
Z2FyZGluZyBJUFIgb24gDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMg
PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LTwvRElWPg0KPERJVj5DQ0FNUDombmJzcDtQbGVhc2UmbmJzcDtub3RlJm5ic3A7dGhlcmUmbmJz
cDthcmUmbmJzcDtJUFImbmJzcDtkaXNjbG9zdXJlczo8L0RJVj4NCjxESVY+aHR0cHM6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9vcHRpb249ZG9jdW1lbnRfc2VhcmNoJmFtcDtk
b2N1bWVudF9zZWFyY2g9ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzPC9E
SVY+DQo8RElWPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPkF1dGhv
cnMsJm5ic3A7Q29udHJpYnV0b3JzLCZuYnNwOyhDQ0FNUCk8L0RJVj4NCjxESVY+PC9ESVY+DQo8
RElWPkFzJm5ic3A7cGFydCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7cHJlcGFyYXRpb24mbmJzcDtm
b3ImbmJzcDtXRyZuYnNwO0xhc3QmbmJzcDtDYWxsOjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+
QXJlJm5ic3A7eW91Jm5ic3A7YXdhcmUmbmJzcDtvZiZuYnNwO2FueSZuYnNwO0lQUiZuYnNwO3Ro
YXQmbmJzcDthcHBsaWVzJm5ic3A7dG88L0RJVj4NCjxESVY+ZHJhZnQtaWV0Zi1jY2FtcC1nbXBs
cy1zaWduYWxpbmctZzcwOXYzPzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SWYmbmJzcDtzbywm
bmJzcDtoYXMmbmJzcDt0aGlzJm5ic3A7SVBSJm5ic3A7YmVlbiZuYnNwO2Rpc2Nsb3NlZCZuYnNw
O2luJm5ic3A7Y29tcGxpYW5jZSZuYnNwO3dpdGgmbmJzcDtJRVRGJm5ic3A7SVBSJm5ic3A7cnVs
ZXM8L0RJVj4NCjxESVY+KHNlZSZuYnNwO1JGQ3MmbmJzcDszOTc5LCZuYnNwOzQ4NzksJm5ic3A7
MzY2OSZuYnNwO2FuZCZuYnNwOzUzNzgmbmJzcDtmb3ImbmJzcDttb3JlJm5ic3A7ZGV0YWlscyk/
PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO2xpc3Rl
ZCZuYnNwO2FzJm5ic3A7YSZuYnNwO2RvY3VtZW50Jm5ic3A7YXV0aG9yJm5ic3A7b3ImbmJzcDtj
b250cmlidXRvciZuYnNwO3BsZWFzZSZuYnNwO2Fuc3dlciZuYnNwO3RoZTwvRElWPg0KPERJVj5h
Ym92ZSZuYnNwO2J5Jm5ic3A7cmVzcG9uZGluZyZuYnNwO3RvJm5ic3A7dGhpcyZuYnNwO2VtYWls
Jm5ic3A7cmVnYXJkbGVzcyZuYnNwO29mJm5ic3A7d2hldGhlciZuYnNwO29yJm5ic3A7bm90Jm5i
c3A7eW91Jm5ic3A7YXJlPC9ESVY+DQo8RElWPmF3YXJlJm5ic3A7b2YmbmJzcDthbnkmbmJzcDty
ZWxldmFudCZuYnNwO0lQUi4mbmJzcDsmbmJzcDtUaGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDt3aWxs
Jm5ic3A7bm90Jm5ic3A7YWR2YW5jZSZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7bmV4dDwvRElWPg0K
PERJVj5zdGFnZSZuYnNwO3VudGlsJm5ic3A7YSZuYnNwO3Jlc3BvbnNlJm5ic3A7aGFzJm5ic3A7
YmVlbiZuYnNwO3JlY2VpdmVkJm5ic3A7ZnJvbSZuYnNwO2VhY2gmbmJzcDthdXRob3ImbmJzcDth
bmQmbmJzcDtsaXN0ZWQ8L0RJVj4NCjxESVY+Y29udHJpYnV0b3IuJm5ic3A7Jm5ic3A7Tk9URTom
bmJzcDtUSElTJm5ic3A7QVBQTElFUyZuYnNwO1RPJm5ic3A7QUxMJm5ic3A7T0YmbmJzcDtZT1Um
bmJzcDtMSVNURUQmbmJzcDtJTiZuYnNwO1RISVM8L0RJVj4NCjxESVY+TUVTU0FHRSdTJm5ic3A7
VE8mbmJzcDtMSU5FUy48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPklmJm5ic3A7eW91Jm5ic3A7
YXJlJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtDQ0FNUCZuYnNwO1dHJm5ic3A7ZW1haWwmbmJzcDts
aXN0Jm5ic3A7YnV0Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7bGlzdGVkJm5ic3A7YXMmbmJzcDth
biZuYnNwO2F1dGhvciZuYnNwO29yPC9ESVY+DQo8RElWPmNvbnRyaWJ1dG9yLCZuYnNwO3dlJm5i
c3A7cmVtaW5kJm5ic3A7eW91Jm5ic3A7b2YmbmJzcDt5b3VyJm5ic3A7b2JsaWdhdGlvbnMmbmJz
cDt1bmRlciZuYnNwO3RoZSZuYnNwO0lFVEYmbmJzcDtJUFImbmJzcDtydWxlczwvRElWPg0KPERJ
Vj53aGljaCZuYnNwO2VuY291cmFnZXMmbmJzcDt5b3UmbmJzcDt0byZuYnNwO25vdGlmeSZuYnNw
O3RoZSZuYnNwO0lFVEYmbmJzcDtpZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO2F3YXJlJm5ic3A7
b2YmbmJzcDtJUFImbmJzcDtvZjwvRElWPg0KPERJVj5vdGhlcnMmbmJzcDtvbiZuYnNwO2FuJm5i
c3A7SUVURiZuYnNwO2NvbnRyaWJ1dGlvbiwmbmJzcDtvciZuYnNwO3RvJm5ic3A7cmVmcmFpbiZu
YnNwO2Zyb20mbmJzcDtwYXJ0aWNpcGF0aW5nJm5ic3A7aW4mbmJzcDthbnk8L0RJVj4NCjxESVY+
Y29udHJpYnV0aW9uJm5ic3A7b3ImbmJzcDtkaXNjdXNzaW9uJm5ic3A7cmVsYXRlZCZuYnNwO3Rv
Jm5ic3A7eW91ciZuYnNwO3VuZGlzY2xvc2VkJm5ic3A7SVBSLiZuYnNwOyZuYnNwO0ZvciZuYnNw
O21vcmU8L0RJVj4NCjxESVY+aW5mb3JtYXRpb24sJm5ic3A7cGxlYXNlJm5ic3A7c2VlJm5ic3A7
dGhlJm5ic3A7UkZDcyZuYnNwO2xpc3RlZCZuYnNwO2Fib3ZlJm5ic3A7YW5kPC9ESVY+DQo8RElW
Pmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVj
dHVhbFByb3BlcnR5LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhhbmsmbmJzcDt5b3UsPC9E
SVY+DQo8RElWPkNDQU1QJm5ic3A7V0cmbmJzcDtDaGFpcnM8L0RJVj4NCjxESVY+PC9ESVY+DQo8
RElWPlBTJm5ic3A7UGxlYXNlJm5ic3A7aW5jbHVkZSZuYnNwO2FsbCZuYnNwO2xpc3RlZCZuYnNw
O2luJm5ic3A7dGhlJm5ic3A7aGVhZGVycyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2Um
bmJzcDtpbiZuYnNwO3lvdXI8L0RJVj4NCjxESVY+cmVzcG9uc2UuPC9ESVY+PC9GT05UPjwvRElW
PjwvQk9EWT48L0hUTUw+DQo=

--=====003_Dragon267245437807_=====--


From zhangfatai@huawei.com  Fri Sep 28 17:55: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 1B4BE21F845A for ; Fri, 28 Sep 2012 17:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VrqPZvrO6WK for ; Fri, 28 Sep 2012 17:55:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4821F8610 for ; Fri, 28 Sep 2012 17:55:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97348; Sat, 29 Sep 2012 00:55:21 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 01:52:49 +0100
Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 01:53:36 +0100
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.131]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 08:53:26 +0800
From: Fatai Zhang 
To: Lou Berger , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , Lidan 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
Thread-Index: AQHNnYRzHVtP4c0ioEKOul+9bdsfSZegfl3w
Date: Sat, 29 Sep 2012 00:53:26 +0000
Message-ID: 
References: <5065B22D.5050808@labn.net>
In-Reply-To: <5065B22D.5050808@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.72.232]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWw=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 00:55:25 -0000

SGkgYWxsLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm
dC1pZXRmLWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWwuDQoNCg0KQmVzdCBSZWdhcmRzDQoNCkZh
dGFpDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJl
cmdlckBsYWJuLm5ldF0gDQq3osvNyrG85DogMjAxMsTqOdTCMjjI1SAyMjoyMA0KytW8/sjLOiBz
ZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb207IHBpZXRyb192aXR0b3Jpby5ncmFuZGlA
YWxjYXRlbC1sdWNlbnQuY29tOyBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tOyBkaWVn
by5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IEZhdGFpIFpoYW5nOyBMaWRhbg0Ks63LzTogQ0NBTVAN
Ctb3zOI6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1jY2FtcC1vdG4tZzcwOS1pbmZvLW1v
ZGVsDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgKENDQU1QKQ0KDQpBcyBwYXJ0IG9mIHRoZSBw
cmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIg
dGhhdCBhcHBsaWVzIHRvDQpkcmFmdC1pZXRmLWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWw/DQoN
CklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF
VEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9y
ZSBkZXRhaWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3Ig
Y29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhp
cyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFu
eSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l
eHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1
dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwg
T0YgWU9VIExJU1RFRCBJTiBUSElTDQpNRVNTQUdFJ1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUg
b24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhv
ciBvcg0KY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRl
ciB0aGUgSUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUg
SUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFuIElFVEYgY29udHJp
YnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkNCmNvbnRyaWJ1
dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3Ig
bW9yZQ0KaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0K
aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0
dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkNDQU1QIFdHIENoYWlycw0KDQpQUyBQbGVhc2Ug
aW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3Vy
DQpyZXNwb25zZS4NCg0K

From zhangfatai@huawei.com  Fri Sep 28 17:55: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 EEE5321F861A for ; Fri, 28 Sep 2012 17:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj7wec76lRJv for ; Fri, 28 Sep 2012 17:55:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9195C21F8611 for ; Fri, 28 Sep 2012 17:55:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97354; Sat, 29 Sep 2012 00:55:22 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 01:53:08 +0100
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 08:53:55 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.131]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 08:53:44 +0800
From: Fatai Zhang 
To: Lou Berger , Lidan , "lihan@chinamobile.com" , "sergio.belotti@alcatel-lucent.it" ,  "daniele.ceccarelli@ericsson.com" , Hanjianrui , "malcolm.betts@huawei.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
Thread-Index: AQHNnYRz/FCXvXO3mEqr9iO77glfG5egfqiA
Date: Sat, 29 Sep 2012 00:53:43 +0000
Message-ID: 
References: <5065B228.1070701@labn.net>
In-Reply-To: <5065B228.1070701@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.72.232]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3Jr?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 00:55:27 -0000

SGkgYWxsLA0KDQpJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLg0KDQoNCg0KDQoNCkJlc3QgUmVnYXJk
cw0KDQpGYXRhaQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMb3UgQmVyZ2VyIFtt
YWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQq3osvNyrG85DogMjAxMsTqOdTCMjjI1SAyMjoyMA0K
ytW8/sjLOiBGYXRhaSBaaGFuZzsgTGlkYW47IGxpaGFuQGNoaW5hbW9iaWxlLmNvbTsgc2VyZ2lv
LmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuaXQ7IGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5j
b207IEhhbmppYW5ydWk7IG1hbGNvbG0uYmV0dHNAaHVhd2VpLmNvbQ0Ks63LzTogQ0NBTVANCtb3
zOI6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29y
aw0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIChDQ0FNUCkNCg0KQXMgcGFydCBvZiB0aGUgcHJl
cGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbDoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRo
YXQgYXBwbGllcyB0bw0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yaz8NCg0K
SWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVU
RiBJUFIgcnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3Jl
IGRldGFpbHMpPw0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBj
b250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlz
IGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55
IHJlbGV2YW50IElQUi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4
dA0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0
aG9yIGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBP
RiBZT1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBv
biB0aGUgQ0NBTVAgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9y
IG9yDQpjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVy
IHRoZSBJRVRGIElQUiBydWxlcw0Kd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJ
RVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mDQpvdGhlcnMgb24gYW4gSUVURiBjb250cmli
dXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueQ0KY29udHJpYnV0
aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gIEZvciBt
b3JlDQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQpo
dHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1
YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KQ0NBTVAgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBp
bmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIN
CnJlc3BvbnNlLg0K

From zhangfatai@huawei.com  Fri Sep 28 17:55: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 4593C21F8610 for ; Fri, 28 Sep 2012 17:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqEuk0Xp5shp for ; Fri, 28 Sep 2012 17:55:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2997E21F845A for ; Fri, 28 Sep 2012 17:55:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97375; Sat, 29 Sep 2012 00:55:45 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 01:54:24 +0100
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 01:54:57 +0100
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.131]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 08:54:45 +0800
From: Fatai Zhang 
To: Lou Berger , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , Lidan , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "rrao@infinera.com" , "kpithewan@infinera.com" , "jdrake@juniper.net" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYR0EA9IfMMwskuvuI+jpCn3aJegfs5w
Date: Sat, 29 Sep 2012 00:54:44 +0000
Message-ID: 
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.72.232]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLW9zcGYtZzcwOXYz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 00:55:47 -0000

SGkgYWxsLA0KDQpZZXM7IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWxyZWFkeS4NCg0KDQoNCkJl
c3QgUmVnYXJkcw0KDQpGYXRhaQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBMb3Ug
QmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQq3osvNyrG85DogMjAxMsTqOdTCMjjI
1SAyMjoyMQ0KytW8/sjLOiBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tOyBkaWVnby5j
YXZpZ2xpYUBlcmljc3Nvbi5jb207IEZhdGFpIFpoYW5nOyBMaWRhbjsgc2VyZ2lvLmJlbG90dGlA
YWxjYXRlbC1sdWNlbnQuY29tOyBwaWV0cm9fdml0dG9yaW8uZ3JhbmRpQGFsY2F0ZWwtbHVjZW50
LmNvbTsgcnJhb0BpbmZpbmVyYS5jb207IGtwaXRoZXdhbkBpbmZpbmVyYS5jb207IGpkcmFrZUBq
dW5pcGVyLm5ldA0Ks63LzTogQ0NBTVANCtb3zOI6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1vc3BmLWc3MDl2Mw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDQ0FNUDogUGxl
YXNlIG5vdGUgdGhlcmUgYXJlIElQUiBkaXNjbG9zdXJlczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvaXByL3NlYXJjaC8/b3B0aW9uPWRvY3VtZW50X3NlYXJjaCZkb2N1bWVudF9zZWFy
Y2g9ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1vc3BmLWc3MDl2Mw0KLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
DQpBdXRob3JzLCBDb250cmlidXRvcnMsIChDQ0FNUCkNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFy
YXRpb24gZm9yIFdHIExhc3QgQ2FsbDoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg
YXBwbGllcyB0bw0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1vc3BmLWc3MDl2Mz8NCg0KSWYgc28s
IGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg
cnVsZXMNCihzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFp
bHMpPw0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmli
dXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWls
IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2
YW50IElQUi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3Rh
Z2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFu
ZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1Ug
TElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUg
Q0NBTVAgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpj
b250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJ
RVRGIElQUiBydWxlcw0Kd2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlm
IHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mDQpvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24s
IG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueQ0KY29udHJpYnV0aW9uIG9y
IGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gIEZvciBtb3JlDQpp
bmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQpodHRwOi8v
dHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9w
ZXJ0eS4NCg0KVGhhbmsgeW91LA0KQ0NBTVAgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRl
IGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJlc3Bv
bnNlLg0KDQo=

From zhangfatai@huawei.com  Fri Sep 28 17:57: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 C337421F8611 for ; Fri, 28 Sep 2012 17:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7kJSmHTJOnJ for ; Fri, 28 Sep 2012 17:57:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2954B21F859B for ; Fri, 28 Sep 2012 17:57:48 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97465; Sat, 29 Sep 2012 00:57:47 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 01:54:29 +0100
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 08:55:09 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.131]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 08:54:56 +0800
From: Fatai Zhang 
To: Lou Berger , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" , "daniele.ceccarelli@ericsson.com" , "kpithewan@infinera.com" , Linyi , "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , "diego.caviglia@ericsson.com" , "rrao@infinera.com" , "jdrake@juniper.net" , "IBryskin@advaoptical.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: AQHNnYR3Bj3R3WiZOUKU+xNC6FNAtZegfwNw
Date: Sat, 29 Sep 2012 00:54:56 +0000
Message-ID: 
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.72.232]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djM=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 00:57:49 -0000

SGkgYWxsLA0KDQpZZXM7IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgYWxyZWFkeS4NCg0KDQoNCg0K
QmVzdCBSZWdhcmRzDQoNCkZhdGFpDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IExv
dSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANCreiy83KsbzkOiAyMDEyxOo51MIy
OMjVIDIyOjIxDQrK1bz+yMs6IEZhdGFpIFpoYW5nOyB6aGFuZ2d1b3lpbmdAbWFpbC5yaXR0LmNv
bS5jbjsgc2VyZ2lvLmJlbG90dGlAYWxjYXRlbC1sdWNlbnQuaXQ7IGRhbmllbGUuY2VjY2FyZWxs
aUBlcmljc3Nvbi5jb207IGtwaXRoZXdhbkBpbmZpbmVyYS5jb207IExpbnlpOyB4dXl1bmJpbkBt
YWlsLnJpdHQuY29tLmNuOyBwaWV0cm9fdml0dG9yaW8uZ3JhbmRpQGFsY2F0ZWwtbHVjZW50Lml0
OyBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IHJyYW9AaW5maW5lcmEuY29tOyBqZHJha2VA
anVuaXBlci5uZXQ7IElCcnlza2luQGFkdmFvcHRpY2FsLmNvbQ0Ks63LzTogQ0NBTVANCtb3zOI6
IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYz
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNDQU1QOiBQbGVhc2Ugbm90ZSB0aGVyZSBhcmUgSVBSIGRp
c2Nsb3N1cmVzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2VhcmNoLz9vcHRp
b249ZG9jdW1lbnRfc2VhcmNoJmRvY3VtZW50X3NlYXJjaD1kcmFmdC1pZXRmLWNjYW1wLWdtcGxz
LXNpZ25hbGluZy1nNzA5djMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQXV0aG9ycywgQ29udHJpYnV0
b3JzLCAoQ0NBTVApDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENh
bGw6DQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8NCmRyYWZ0LWll
dGYtY2NhbXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2Mz8NCg0KSWYgc28sIGhhcyB0aGlzIElQUiBi
ZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUgUkZD
cyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiB5b3Ug
YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5z
d2VyIHRoZQ0KYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg
d2hldGhlciBvciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gIFRoaXMg
ZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNw
b25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRy
aWJ1dG9yLiAgTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMN
Ck1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgQ0NBTVAgV0cgZW1haWwg
bGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpjb250cmlidXRvciwgd2Ug
cmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcw0K
d2hpY2ggZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUg
b2YgSVBSIG9mDQpvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4g
ZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueQ0KY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVs
YXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gIEZvciBtb3JlDQppbmZvcm1hdGlvbiwgcGxl
YXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQpodHRwOi8vdHJhYy50b29scy5pZXRm
Lm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsg
eW91LA0KQ0NBTVAgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4g
dGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJlc3BvbnNlLg0K

From zhangfatai@huawei.com  Fri Sep 28 18:04: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 F124921F8613 for ; Fri, 28 Sep 2012 18:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTEKRlCTxWMO for ; Fri, 28 Sep 2012 18:04:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E603921F8611 for ; Fri, 28 Sep 2012 18:04:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97740; Sat, 29 Sep 2012 01:04:01 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:00:43 +0100
Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:01:30 +0100
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.131]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 09:01:20 +0800
From: Fatai Zhang 
To: Fatai Zhang , Lou Berger , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , Lidan , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "rrao@infinera.com" , "kpithewan@infinera.com" , "jdrake@juniper.net" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYR0EA9IfMMwskuvuI+jpCn3aJegfs5wgAABM7A=
Date: Sat, 29 Sep 2012 01:01:20 +0000
Message-ID: 
References: <5065B232.1020908@labn.net> 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.72.232]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLW9zcGYtZzcwOXYz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 01:04:04 -0000

SGkgYWxsLA0KDQpJIHNob3VsZCByZXBocmFzZTogWWVzLCBJIGFtIGF3YXJlIG9mIHRoZSBJUFJz
IHRoYXQgaGF2ZSBiZWVuIGRpc2Nsb3NlZCBhcyBpbmRpY2F0ZWQgYnkgTG91Lg0KDQpodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP29wdGlvbj1kb2N1bWVudF9zZWFyY2gm
ZG9jdW1lbnRfc2VhcmNoPWRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMNCg0KDQoN
CkJlc3QgUmVnYXJkcw0KDQpGYXRhaQ0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBG
YXRhaSBaaGFuZyANCreiy83KsbzkOiAyMDEyxOo51MIyOcjVIDg6NTUNCsrVvP7IyzogJ0xvdSBC
ZXJnZXInOyBkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tOyBkaWVnby5jYXZpZ2xpYUBl
cmljc3Nvbi5jb207IExpZGFuOyBzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb207IHBp
ZXRyb192aXR0b3Jpby5ncmFuZGlAYWxjYXRlbC1sdWNlbnQuY29tOyBycmFvQGluZmluZXJhLmNv
bTsga3BpdGhld2FuQGluZmluZXJhLmNvbTsgamRyYWtlQGp1bmlwZXIubmV0DQqzrcvNOiBDQ0FN
UA0K1vfM4jogtPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLW9z
cGYtZzcwOXYzDQoNCkhpIGFsbCwNCg0KWWVzOyBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGFscmVh
ZHkuDQoNCg0KDQpCZXN0IFJlZ2FyZHMNCg0KRmF0YWkNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0N
CreivP7IyzogTG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6
IDIwMTLE6jnUwjI4yNUgMjI6MjENCsrVvP7IyzogZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29u
LmNvbTsgZGllZ28uY2F2aWdsaWFAZXJpY3Nzb24uY29tOyBGYXRhaSBaaGFuZzsgTGlkYW47IHNl
cmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50LmNvbTsgcGlldHJvX3ZpdHRvcmlvLmdyYW5kaUBh
bGNhdGVsLWx1Y2VudC5jb207IHJyYW9AaW5maW5lcmEuY29tOyBrcGl0aGV3YW5AaW5maW5lcmEu
Y29tOyBqZHJha2VAanVuaXBlci5uZXQNCrOty806IENDQU1QDQrW98ziOiBSZWdhcmRpbmcgSVBS
IG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMNCg0KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KQ0NBTVA6IFBsZWFzZSBub3RlIHRoZXJlIGFyZSBJUFIgZGlzY2xvc3VyZXM6DQpodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci9zZWFyY2gvP29wdGlvbj1kb2N1bWVudF9zZWFyY2gm
ZG9jdW1lbnRfc2VhcmNoPWRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCAoQ0NBTVApDQoNCkFzIHBhcnQg
b2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGw6DQoNCkFyZSB5b3UgYXdhcmUgb2Yg
YW55IElQUiB0aGF0IGFwcGxpZXMgdG8NCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5
djM/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3
aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm
b3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRo
b3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcg
dG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJl
IG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8g
dGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBl
YWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBU
TyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTDQpNRVNTQUdFJ1MgVE8gTElORVMuDQoNCklmIHlv
dSBhcmUgb24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu
IGF1dGhvciBvcg0KY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9u
cyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlm
eSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFuIElFVEYg
Y29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkNCmNv
bnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIu
ICBGb3IgbW9yZQ0KaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3Zl
IGFuZA0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50
ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkNDQU1QIFdHIENoYWlycw0KDQpQUyBQ
bGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBp
biB5b3VyDQpyZXNwb25zZS4NCg0K

From huawei.danli@huawei.com  Fri Sep 28 18:05: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 E3A0D21F861D for ; Fri, 28 Sep 2012 18:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smgBbAOlWEJX for ; Fri, 28 Sep 2012 18:05:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2DDD21F8618 for ; Fri, 28 Sep 2012 18:05:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALD61535; Sat, 29 Sep 2012 01:05:02 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:03:54 +0100
Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:04:42 +0100
Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.47]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 09:04:29 +0800
From: Lidan 
To: Lou Berger , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , Fatai Zhang 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-otn-g709-info-model
Thread-Index: AQHNnYRu2BeYq4D2VkCfPeU5OTx8h5eggZoQ
Date: Sat, 29 Sep 2012 01:04:28 +0000
Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A2E8FD785@szxeml538-mbx.china.huawei.com>
References: <5065B22D.5050808@labn.net>
In-Reply-To: <5065B22D.5050808@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.73.151]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWw=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 01:05:04 -0000

Tm8gSVBSLg0KDQpUaGFua3MsDQoNCkRhbg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL
OiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQq3osvNyrG85DogMjAxMsTq
OdTCMjjI1SAyMjoyMA0KytW8/sjLOiBzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5jb207
IHBpZXRyb192aXR0b3Jpby5ncmFuZGlAYWxjYXRlbC1sdWNlbnQuY29tOyBkYW5pZWxlLmNlY2Nh
cmVsbGlAZXJpY3Nzb24uY29tOyBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IEZhdGFpIFpo
YW5nOyBMaWRhbg0Ks63LzTogQ0NBTVANCtb3zOI6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0
Zi1jY2FtcC1vdG4tZzcwOS1pbmZvLW1vZGVsDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgKEND
QU1QKQ0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsOg0KDQpB
cmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvDQpkcmFmdC1pZXRmLWNjYW1w
LW90bi1nNzA5LWluZm8tbW9kZWw/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9z
ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3
OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQg
YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFi
b3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Ig
bm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdp
bGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJl
ZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5P
VEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTDQpNRVNTQUdFJ1Mg
VE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFy
ZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ug
b2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291
cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0K
b3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGlj
aXBhdGluZyBpbiBhbnkNCmNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91
ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3IgbW9yZQ0KaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhl
IFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAv
aWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkNDQU1Q
IFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJz
IG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg0K

From huawei.danli@huawei.com  Fri Sep 28 18:05: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 8843421F8618 for ; Fri, 28 Sep 2012 18:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id End9FMYmtDLC for ; Fri, 28 Sep 2012 18:05:39 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 835C121F8611 for ; Fri, 28 Sep 2012 18:05:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97810; Sat, 29 Sep 2012 01:05:29 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:04:07 +0100
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:05:05 +0100
Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.47]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 09:04:54 +0800
From: Lidan 
To: Lou Berger , Fatai Zhang , "lihan@chinamobile.com" , "sergio.belotti@alcatel-lucent.it" ,  "daniele.ceccarelli@ericsson.com" , Hanjianrui , "malcolm.betts@huawei.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-g709-framework
Thread-Index: AQHNnYRzqUcrlJqNeEu/GBKj6eFl9peggcVQ
Date: Sat, 29 Sep 2012 01:04:54 +0000
Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A2E8FD78C@szxeml538-mbx.china.huawei.com>
References: <5065B228.1070701@labn.net>
In-Reply-To: <5065B228.1070701@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.73.151]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3Jr?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 01:05:39 -0000

Tm8gSVBSLg0KDQpUaGFua3MsDQoNCkRhbg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7Iyzog
TG91IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6IDIwMTLE6jnU
wjI4yNUgMjI6MjANCsrVvP7IyzogRmF0YWkgWmhhbmc7IExpZGFuOyBsaWhhbkBjaGluYW1vYmls
ZS5jb207IHNlcmdpby5iZWxvdHRpQGFsY2F0ZWwtbHVjZW50Lml0OyBkYW5pZWxlLmNlY2NhcmVs
bGlAZXJpY3Nzb24uY29tOyBIYW5qaWFucnVpOyBtYWxjb2xtLmJldHRzQGh1YXdlaS5jb20NCrOt
y806IENDQU1QDQrW98ziOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt
ZzcwOS1mcmFtZXdvcmsNCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCAoQ0NBTVApDQoNCkFzIHBh
cnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMYXN0IENhbGw6DQoNCkFyZSB5b3UgYXdhcmUg
b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8NCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1m
cmFtZXdvcms/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp
YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQg
NTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu
dCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3Bv
bmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUN
CmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFu
Y2UgdG8gdGhlIG5leHQNCnN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQg
ZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQ
TElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTDQpNRVNTQUdFJ1MgVE8gTElORVMuDQoN
CklmIHlvdSBhcmUgb24gdGhlIENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVk
IGFzIGFuIGF1dGhvciBvcg0KY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxp
Z2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRv
IG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFu
IElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBh
bnkNCmNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3Nl
ZCBJUFIuICBGb3IgbW9yZQ0KaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVk
IGFib3ZlIGFuZA0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dp
a2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkNDQU1QIFdHIENoYWlycw0K
DQpQUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVz
c2FnZSBpbiB5b3VyDQpyZXNwb25zZS4NCg==

From huawei.danli@huawei.com  Fri Sep 28 18:08: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 5A9F121F85AC for ; Fri, 28 Sep 2012 18:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339,  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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8GWV8j-K2Pu for ; Fri, 28 Sep 2012 18:08:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6CE21F8496 for ; Fri, 28 Sep 2012 18:08:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC97938; Sat, 29 Sep 2012 01:08:12 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:06:38 +0100
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:07:36 +0100
Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.47]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 09:07:23 +0800
From: Lidan 
To: Lou Berger , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , Fatai Zhang , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , "rrao@infinera.com" , "kpithewan@infinera.com" , "jdrake@juniper.net" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYR13luwBiarv0CGB9ig+HKOp5eggeGA
Date: Sat, 29 Sep 2012 01:07:23 +0000
Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A2E8FD7A5@szxeml538-mbx.china.huawei.com>
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.73.151]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLW9zcGYtZzcwOXYz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 01:08:14 -0000

Tm8gSVBSLiBCdXQgSSBhd2FyZSBvZiBvdGhlciBjb21wYW5pZXMgaGFkIGRpc2Nsb3NlZCB0aGUg
SVBSLg0KDQpUaGFua3MsDQoNCkRhbg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTG91
IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6IDIwMTLE6jnUwjI4
yNUgMjI6MjENCsrVvP7IyzogZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNzc29uLmNvbTsgZGllZ28u
Y2F2aWdsaWFAZXJpY3Nzb24uY29tOyBGYXRhaSBaaGFuZzsgTGlkYW47IHNlcmdpby5iZWxvdHRp
QGFsY2F0ZWwtbHVjZW50LmNvbTsgcGlldHJvX3ZpdHRvcmlvLmdyYW5kaUBhbGNhdGVsLWx1Y2Vu
dC5jb207IHJyYW9AaW5maW5lcmEuY29tOyBrcGl0aGV3YW5AaW5maW5lcmEuY29tOyBqZHJha2VA
anVuaXBlci5uZXQNCrOty806IENDQU1QDQrW98ziOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWll
dGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ0NBTVA6IFBs
ZWFzZSBub3RlIHRoZXJlIGFyZSBJUFIgZGlzY2xvc3VyZXM6DQpodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2lwci9zZWFyY2gvP29wdGlvbj1kb2N1bWVudF9zZWFyY2gmZG9jdW1lbnRfc2Vh
cmNoPWRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djMNCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCAoQ0NBTVApDQoNCkFzIHBhcnQgb2YgdGhlIHByZXBh
cmF0aW9uIGZvciBXRyBMYXN0IENhbGw6DQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0
IGFwcGxpZXMgdG8NCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtb3NwZi1nNzA5djM/DQoNCklmIHNv
LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS
IHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRh
aWxzKT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJp
YnV0b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFp
bCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxl
dmFudCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0
YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBh
bmQgbGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9V
IExJU1RFRCBJTiBUSElTDQpNRVNTQUdFJ1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhl
IENDQU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0K
Y29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUg
SUVURiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBp
ZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9u
LCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkNCmNvbnRyaWJ1dGlvbiBv
ciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3IgbW9yZQ0K
aW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0KaHR0cDov
L3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJv
cGVydHkuDQoNClRoYW5rIHlvdSwNCkNDQU1QIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVk
ZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNw
b25zZS4NCg0K

From huawei.danli@huawei.com  Fri Sep 28 18:11: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 BEAC721F8643 for ; Fri, 28 Sep 2012 18:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSdcAtg6z5ST for ; Fri, 28 Sep 2012 18:11:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE0321F863F for ; Fri, 28 Sep 2012 18:11:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKC98032; Sat, 29 Sep 2012 01:10:11 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:07:38 +0100
Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 29 Sep 2012 02:08:25 +0100
Received: from SZXEML538-MBX.china.huawei.com ([169.254.4.47]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Sat, 29 Sep 2012 09:08:16 +0800
From: Lidan 
To: Lou Berger , Fatai Zhang , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" ,  "daniele.ceccarelli@ericsson.com" , "kpithewan@infinera.com" , Linyi , "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , "diego.caviglia@ericsson.com" , "rrao@infinera.com" , "jdrake@juniper.net" , "IBryskin@advaoptical.com" 
Thread-Topic: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: AQHNnYR+dAKJS3uX0kGIJiIjFKwmdJeggpxA
Date: Sat, 29 Sep 2012 01:08:15 +0000
Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A2E8FD7B1@szxeml538-mbx.china.huawei.com>
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.73.151]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP 
Subject: [CCAMP] =?gb2312?b?tPC4tDogIFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0?= =?gb2312?b?Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 01:11:52 -0000

WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZC4NCg0KVGhhbmtzLA0KDQpEYW4NCg0KDQot
LS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv
OmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTG91IEJlcmdlcg0Kt6LLzcqxvOQ6IDIwMTLE
6jnUwjI4yNUgMjI6MjENCsrVvP7IyzogRmF0YWkgWmhhbmc7IHpoYW5nZ3VveWluZ0BtYWlsLnJp
dHQuY29tLmNuOyBzZXJnaW8uYmVsb3R0aUBhbGNhdGVsLWx1Y2VudC5pdDsgZGFuaWVsZS5jZWNj
YXJlbGxpQGVyaWNzc29uLmNvbTsga3BpdGhld2FuQGluZmluZXJhLmNvbTsgTGlueWk7IHh1eXVu
YmluQG1haWwucml0dC5jb20uY247IHBpZXRyb192aXR0b3Jpby5ncmFuZGlAYWxjYXRlbC1sdWNl
bnQuaXQ7IGRpZWdvLmNhdmlnbGlhQGVyaWNzc29uLmNvbTsgcnJhb0BpbmZpbmVyYS5jb207IGpk
cmFrZUBqdW5pcGVyLm5ldDsgSUJyeXNraW5AYWR2YW9wdGljYWwuY29tDQqzrcvNOiBDQ0FNUA0K
1vfM4jogW0NDQU1QXSBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtc2ln
bmFsaW5nLWc3MDl2Mw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDQ0FNUDogUGxlYXNlIG5vdGUgdGhl
cmUgYXJlIElQUiBkaXNjbG9zdXJlczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXBy
L3NlYXJjaC8/b3B0aW9uPWRvY3VtZW50X3NlYXJjaCZkb2N1bWVudF9zZWFyY2g9ZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1zaWduYWxpbmctZzcwOXYzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkF1dGhv
cnMsIENvbnRyaWJ1dG9ycywgKENDQU1QKQ0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBm
b3IgV0cgTGFzdCBDYWxsOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz
IHRvDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djM/DQoNCklmIHNvLCBo
YXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1
bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxz
KT8NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0
b3IgcGxlYXNlIGFuc3dlciB0aGUNCmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCBy
ZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFu
dCBJUFIuICBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCnN0YWdl
IHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQg
bGlzdGVkDQpjb250cmlidXRvci4gIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJ
U1RFRCBJTiBUSElTDQpNRVNTQUdFJ1MgVE8gTElORVMuDQoNCklmIHlvdSBhcmUgb24gdGhlIEND
QU1QIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvcg0KY29u
dHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVU
RiBJUFIgcnVsZXMNCndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5
b3UgYXJlIGF3YXJlIG9mIElQUiBvZg0Kb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBv
ciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkNCmNvbnRyaWJ1dGlvbiBvciBk
aXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuICBGb3IgbW9yZQ0KaW5m
b3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0KaHR0cDovL3Ry
YWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVy
dHkuDQoNClRoYW5rIHlvdSwNCkNDQU1QIFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBh
bGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyDQpyZXNwb25z
ZS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FN
UCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2NjYW1wDQo=

From kpithewan@infinera.com  Fri Sep 28 22:17: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 26CF121F852B for ; Fri, 28 Sep 2012 22:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj1YnBjeY1+o for ; Fri, 28 Sep 2012 22:17:23 -0700 (PDT)
Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8698021F84A6 for ; Fri, 28 Sep 2012 22:17:23 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 22:17:22 -0700
From: Khuzema Pithewan 
To: Lou Berger , "zhangfatai@huawei.com" , "zhangguoying@mail.ritt.com.cn" , "sergio.belotti@alcatel-lucent.it" , "daniele.ceccarelli@ericsson.com" , "yi.lin@huawei.com" ,  "xuyunbin@mail.ritt.com.cn" , "pietro_vittorio.grandi@alcatel-lucent.it" , "diego.caviglia@ericsson.com" , Rajan Rao , "jdrake@juniper.net" , "IBryskin@advaoptical.com" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
Thread-Index: AQHNnYRzDVe3AbmbhEKHdHaIOJ/vx5egyAjI
Date: Sat, 29 Sep 2012 05:17:21 +0000
Message-ID: 
References: <5065B236.9080009@labn.net>
In-Reply-To: <5065B236.9080009@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.100.156.128]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 05:17:24 -0000

=0A=
Yes.   IPR has been disclosed already.=0A=
=0A=
Regards=0A=
Khuzema=0A=
=0A=
=0A=
________________________________________=0A=
From: Lou Berger [lberger@labn.net]=0A=
Sent: Friday, September 28, 2012 7:50 PM=0A=
To: zhangfatai@huawei.com; zhangguoying@mail.ritt.com.cn; sergio.belotti@al=
catel-lucent.it; daniele.ceccarelli@ericsson.com; Khuzema Pithewan; yi.lin@=
huawei.com; xuyunbin@mail.ritt.com.cn; pietro_vittorio.grandi@alcatel-lucen=
t.it; diego.caviglia@ericsson.com; Rajan Rao; jdrake@juniper.net; IBryskin@=
advaoptical.com=0A=
Cc: CCAMP=0A=
Subject: Regarding IPR on draft-ietf-ccamp-gmpls-signaling-g709v3=0A=
=0A=
-------------------------------------------------------------------------=
=0A=
CCAMP: Please note there are IPR disclosures:=0A=
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_=
search=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3=0A=
-------------------------------------------------------------------------=
=0A=
=0A=
Authors, Contributors, (CCAMP)=0A=
=0A=
As part of the preparation for WG Last Call:=0A=
=0A=
Are you aware of any IPR that applies to=0A=
draft-ietf-ccamp-gmpls-signaling-g709v3?=0A=
=0A=
If so, has this IPR been disclosed in compliance with IETF IPR rules=0A=
(see RFCs 3979, 4879, 3669 and 5378 for more details)?=0A=
=0A=
If you are listed as a document author or contributor please answer the=0A=
above by responding to this email regardless of whether or not you are=0A=
aware of any relevant IPR.  This document will not advance to the next=0A=
stage until a response has been received from each author and listed=0A=
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=0A=
MESSAGE'S TO LINES.=0A=
=0A=
If you are on the CCAMP WG email list but are not listed as an author or=0A=
contributor, we remind you of your obligations under the IETF IPR rules=0A=
which encourages you to notify the IETF if you are aware of IPR of=0A=
others on an IETF contribution, or to refrain from participating in any=0A=
contribution or discussion related to your undisclosed IPR.  For more=0A=
information, please see the RFCs listed above and=0A=
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.=0A=
=0A=
Thank you,=0A=
CCAMP WG Chairs=0A=
=0A=
PS Please include all listed in the headers of this message in your=0A=
response.=0A=

From kpithewan@infinera.com  Fri Sep 28 22:18: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 3409221F85EF for ; Fri, 28 Sep 2012 22:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0aR8ds+9RQq for ; Fri, 28 Sep 2012 22:18:02 -0700 (PDT)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 424FE21F84A6 for ; Fri, 28 Sep 2012 22:18:02 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 22:18:01 -0700
From: Khuzema Pithewan 
To: Lou Berger , "daniele.ceccarelli@ericsson.com" , "diego.caviglia@ericsson.com" , "zhangfatai@huawei.com" , "danli@huawei.com" , "sergio.belotti@alcatel-lucent.com" , "pietro_vittorio.grandi@alcatel-lucent.com" , Rajan Rao , "jdrake@juniper.net" 
Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
Thread-Index: AQHNnYRyaDDdT2Bs3kejkd0to1Ly0ZegyGsV
Date: Sat, 29 Sep 2012 05:18:01 +0000
Message-ID: 
References: <5065B232.1020908@labn.net>
In-Reply-To: <5065B232.1020908@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.100.156.128]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: CCAMP 
Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Sep 2012 05:18:03 -0000

=0A=
Yes.   IPR has been disclosed already.=0A=
=0A=
Regards=0A=
Khuzema=0A=
________________________________________=0A=
From: Lou Berger [lberger@labn.net]=0A=
Sent: Friday, September 28, 2012 7:50 PM=0A=
To: daniele.ceccarelli@ericsson.com; diego.caviglia@ericsson.com; zhangfata=
i@huawei.com; danli@huawei.com; sergio.belotti@alcatel-lucent.com; pietro_v=
ittorio.grandi@alcatel-lucent.com; Rajan Rao; Khuzema Pithewan; jdrake@juni=
per.net=0A=
Cc: CCAMP=0A=
Subject: Regarding IPR on draft-ietf-ccamp-gmpls-ospf-g709v3=0A=
=0A=
-------------------------------------------------------------------------=
=0A=
CCAMP: Please note there are IPR disclosures:=0A=
https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_=
search=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3=0A=
-------------------------------------------------------------------------=
=0A=
=0A=
Authors, Contributors, (CCAMP)=0A=
=0A=
As part of the preparation for WG Last Call:=0A=
=0A=
Are you aware of any IPR that applies to=0A=
draft-ietf-ccamp-gmpls-ospf-g709v3?=0A=
=0A=
If so, has this IPR been disclosed in compliance with IETF IPR rules=0A=
(see RFCs 3979, 4879, 3669 and 5378 for more details)?=0A=
=0A=
If you are listed as a document author or contributor please answer the=0A=
above by responding to this email regardless of whether or not you are=0A=
aware of any relevant IPR.  This document will not advance to the next=0A=
stage until a response has been received from each author and listed=0A=
contributor.  NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=0A=
MESSAGE'S TO LINES.=0A=
=0A=
If you are on the CCAMP WG email list but are not listed as an author or=0A=
contributor, we remind you of your obligations under the IETF IPR rules=0A=
which encourages you to notify the IETF if you are aware of IPR of=0A=
others on an IETF contribution, or to refrain from participating in any=0A=
contribution or discussion related to your undisclosed IPR.  For more=0A=
information, please see the RFCs listed above and=0A=
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.=0A=
=0A=
Thank you,=0A=
CCAMP WG Chairs=0A=
=0A=
PS Please include all listed in the headers of this message in your=0A=
response.=0A=
=0A=